Chrome still hasn't changed its opinion about dropping JPEG XL support
bugs.chromium.org
bugs.chromium.org
1. Someone comes up with a cool feature.
2. Browser developer refuses to incorporate it since "No one uses it!". Pushes developed in-house technology instead.
3. No one uses the feature as a result. "See no one wants it!"
4. Competitors start to implement the feature
5. ???
And no, pollyfill is again not the (right) solution.
The problem was that the UX sucked. The UX today still kind of sucks but it's infinitely better than what was available when QR codes were first around by being integrated into the camera app.
It was in fact invented in Japan:
I remember being frustrated that my non-smartphone flip-phone didn't support them (and no way to add support for them either).
https://www.nytimes.com/2023/05/22/dining/restaurant-qr-code...
For the price of eliminating underpaid waitstaff, the customer has a weird, slow ordering experience that cannot accommodate undocumented needs. The customer response is: fuck you.
Fast food is similar with order kiosks.
i'd be ok with them if i could place my usual order (sub and add onions)
but i can't so i always have to goto the counter
I think the problem here is that W3C is lagging on listing which image formats are standard and vendors are shipping their own in-house tech in the vaccuum (and that W3C is composed of browser vendors means Google, Apple, Microsoft, Mozila & whoever is there from the community can't agree).
Who cares if there's little adoption? Why not be feature complete? It's not like Google is some cash-strapped startup.
Heck, macOS ships with terminal definitions so you can log into a Mac using a Commodore B-128 as a serial terminal. It didn't have to, and that's certainly going to have less adoption than JPEG XL.
(/usr/share/terminfo/62/b-128, if you're curious.)
On GitHub if you rename your WebP file to "file.webp.png" it will upload just fine, and will use the correct Content-Type header when serving. It's really frustrating a simple \.(png|gif|jpe?g)$ check is preventing the uploading of these files. I found this is actually the case for a number of platforms.
Why is Adobe so bad at their job? GIMP added webp support about 5 years ago. Paint.NET added it 4 years ago.
> many websites still don't support uploading webp files.
4chan is the only such site I've heard of, and 4chan is notoriously bad at this sort of thing ever since they lost moot. It took them years to permit uploading of vp9/opus webms, for no good reason. 4chan's present administrators are incompetent, but 4chan is barely profitable (if at all) so that's not really unexpected.
But Adobe rakes in huge piles of cash, so what is Adobe's excuse?
Did they finally do that? I left permanently a couple years ago (after being there regularly since 2006) because the small "these kinds of threads are why I still hang around this place" threads got more and more infrequent and the regular users got more and more annoying and less fun. Most of the site just became a constant pool of angry racism, cynicism, and paranoia. I can handle seeing stupid racism, but the death of fun and the constant angry sarcasm just got old.
Anyway, I was constantly annoyed that I couldn't upload vp9 webms, and that apng was also not supported given how much better than gif it was. Webp would have been decent, too.
Because this code will be exposed on every single webpage you load, and historically these kind of parsers have had a number of security problems.
Something something memory safety, but this is the situation that currently exists.
"All the image parsers" would be a very bad idea. Years ago there was a bug in some Linux setups where all gstreamer codecs were exposed in Firefox, and it was a huge problem (similar: https://lwn.net/Articles/708196/ – although the one I remember is much older, around 2010 or so).
It's not really comparable to all the old terminfo entries from decades ago: the vendor controls those terminfo entries, not $random_websites. Maybe the ncurses terminfo parser actually does have some buffer overflow (there's an entire mini-programming language in terminfo), but if it does it's not really a huge acute problem.
By that logic, Chrome shouldn't ever add any new features. WebP is also an additional attack surface.
Behaving like there's no cost in such maintenance is just whack.
Compile it to wasm and run it in a sandbox? Or throw some rust groupies at it?
> Once released, it's pretty much impossible to rollback support for media formats on the web.
We must live in a time where flash still dominates short web animations, streaming providers use silver light and every enterprise user is stuck waiting for the companies 5GB Java applet to load right when IE6 suddenly pops up to kill everything with an ActiveX based Windows update that adds more video codecs instead of removing them from the system. The list goes on forever. Browsers are not above killing features and breaking things for security reasons or if they just feel like it.
If that's the case (and if the implementation is sufficient, rather than a leaky prototype) it would seem that the burden is quite low.
That world existed, in the 90s and early 2000s, and it was called "ActiveX". The codebase= attribute of the <object> element exists for that use case. It sucked, for two major reasons: first of all, it was a reliable way to get malware into user's machines (being "signed with a trusted cert" doesn't help when all you need for a trusted cert is money and/or hacking a trusted software publisher). Second, it was very Windows-specific, and a significant obstacle to the adoption of alternative operating systems, hardware architectures, and browsers.
This is one of those things that sound nice, but there's a lot of practical caveats, and in reality it would all be pretty complex. Who would provide the "trusted certs"? How do you decide between a "good and safe plugin" and "not so good and unsafe plugin"? How do you update these decoders? etc.
Also webp is 13 years old now or something since the initial release as compared with jpegxl which is quite new.
If after a decade no one really uses it, fine remove it - no one will care if it’s unused. But to kill it in its cradle is just BS. JPEGXL should have the same opportunities WebP had.
Now somebody is going to say that's bad because it will fragment the ecosystem, and people will rely on something that works on one platform but not another. But you know what, that's not much different from something that works in one browser and not in another. Just file a bug against your OS. There are only finitely many image formats in the world. I'm sure Qt, .NET, Cocoa, ... have every format that you could conceivably need, and if not it should be easy to add them once.
The idea behind standardization is precisely to not let that happen.
That doesn't always work. VLC became as popular as it is partly through bundling its own selection of codecs for its own use, when getting certain things to play in some places was quite a faf.
If doing it the right way is hassle to the end user, we'll often sidestep rather than campaigning for fixes where they should be made.
Windows has done this and is still doing this, but the decade-long track history so far is that this does not work well. It can work, in a very limited scope and if you have a lot of influence.
Sure, it's really nice if an 8K@60Hz HDR HEVC video plays perfectly straight in your browser or desktop app, but more often than not, it just won't. You don't have the right browser, the extension installed (due to license agreements), good enough graphics drivers or someone has forgotten a flag yet again.
And we haven't even gotten to the immense amount of variation each codec introduces or the potential attack surface.
How shit the situation is with just HEVC (and thus also basically HEIC): https://github.com/StaZhu/enable-chromium-hevc-hardware-deco...
> Just file a bug against your OS.
In the end that "just" carries a lot of burden, it can't be the users reporting these issues.
It's just way easier to leech off of ffmpeg and similar, and let it deal with all the formats. Instead of hoping that maybe you can leverage what the OS gives you, that it works and works correctly in all your edge-cases.
Though not everything is that gloomy, there are Vulkan extensions that might (in the future) simplify cross-platform image and video decoding (and HW acceleration).
https://twitter.com/jonsneyers/status/1665792517613256705 https://www.webkit.org/blog/14203/web-technology-sessions-at...
So, can we just get past this silly drama now and get JXL support back in Chromium?
Maybe let's wait for Apple to actually announce the details (which neither the cropped screenshot or the talk abstract have), and give the Chrome team some time to react and make a statement. Rather than have the 10th rehash of this on HN with an incendiary title.
I agree on giving the Chrome people some space, the title here is ridiculous.
I’m running iOS 17; JPEG XL doesn’t work in Chrome (or Brave). So there’s more going on.
What will be interesting: if Google will enable JPEG XL support in the next update of Chrome on iOS…
Huh? Up to that point I was expecting a joke about Chrome being the receiver of the exact same thing Google practices.
JPEG XL support has officially been removed from Chromium - https://news.ycombinator.com/item?id=33933208 - Dec 2022 (378 comments)
Chrome Responds "No" to JPEG XL - https://news.ycombinator.com/item?id=33563378 - Nov 2022 (55 comments)
The case for JPEG XL - https://news.ycombinator.com/item?id=33442281 - Nov 2022 (209 comments)
Removing the JPEG XL code and flag from Chromium - https://news.ycombinator.com/item?id=33412340 - Oct 2022 (42 comments)
Chrome drops JPEG XL, “not enough interest” - https://news.ycombinator.com/item?id=33404840 - Oct 2022 (4 comments)
Google set to deprecate JPEG XL support in Chrome 110 - https://news.ycombinator.com/item?id=33399940 - Oct 2022 (93 comments)
Google Chrome Is Already Preparing to Deprecate JPEG-XL - https://news.ycombinator.com/item?id=33383880 - Oct 2022 (20 comments)
This is politics, not a technical discussion.
YC is an US company, and its network is US-based.
One of the main JPEG XL contributors is a WebP contributor and a Google employee. If JPEG XL got shipped first you could make the opposite conspiracy from that!
The Web is not supposed to be a Katamari Damacy of codecs. It doesn't need multiple redundant or worse ways to do the same thing. There's a high cost of adopting a new format Web-wide, so it's rational to do it rarely and only when benefits outweigh the costs.
Even when gifs are now mostly replaced by webm and HTML5 viideo tag, the unification of image formats for both orthogonal uses (natural images vs. technical or generated images) is a big advantage.
A GIF? Looping video, maybe 3 seconds long.
A silent video? Hours and hours.
https://news.ycombinator.com/item?id=33399940 (2022-10-30, 146 points, 95 comments)
Also a few more submissions of issue 1178058:
https://news.ycombinator.com/item?id=33403430 (2022-10-31, 13 points, 2 comments)
https://news.ycombinator.com/item?id=33412340 (2022-11-01, 60 points, 42 comments)
https://news.ycombinator.com/item?id=33705725 (2022-11-23, 32 points, 1 comments)
For HEIC, I understand, but it's weird that they are the only ones supporting JPEG XL while it is a royalty free open standard and the open source browsers don't support it.
It's true, although it should be noted that this is the result of the Chromium team acting in bad faith and gaslighting the users.
These are the stated reasons for the removal of JPEG XL: https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
"Experimental flags and code should not remain indefinitely"
Why wasn't AVIF hidden behind an experimental flag?
"There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL"
This is gaslighting. The representatives of companies such as Adobe, Facebook, Intel, The Guardian or Shopify have voiced their support for the format. Not to mention the countless individuals. I don't recall AVIF getting anywhere near this level of interest.
"The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default"
Really? https://cloudinary.com/blog/the-case-for-jpeg-xl
BTW, this article doesn't even mention all of the JPEG XL's advantages. For instance, it doesn't mention the high resolution support. AVIF images are limited to 65536x65536, but images larger than 8192x4352 must be tiled, which results in border artifacts between the tiles. JPEG XL, on the other hand, has no problems with images up to 1073741823x1073741823.
I can't believe how soft the general consensus on Internet discussion has become. We will never get anything done if people consider this level of mild and sensible criticism obnoxious.
But by adding and then removing the feature, they've made it a competition. Now JPEG XL is building grass-roots support, and if/when Google relents and adds JPEG XL back, the feature will have much higher support than the boring way.
> The code has been removed from Chromium (comment #281), I'm closing this bug for now. If leadership revisits the decision [1] it can be reopened.
There you have it--the people making decisions are out-of-touch, likely-non-technical managers, not engineers. Engineers are the ones writing the code and shipping features. Why not empower them to make these decisions?
Maybe JPEG-XL is more important to technical users than chromes actual users?
https://www.webkit.org/blog/14205/news-from-wwdc23-webkit-fe...
As for browsers, this looks like the competition that's needed to convince Chrome. If it gains adoption and gives Safari a performance/quality edge that users notice, Chrome will have to follow.
For browser vendors, all web-exposed code is a maintenance cost, security risk, and compatibility risk, so they generally don't add stuff just because it's nice. But they do add stuff to beat their competitors.
Meanwhile there will be software options for authoring, e.g. Adobe Camera Raw.
For the web, the trade-offs between encode speed, compression , and fidelity consistency are quite clearly in jxl's favor. Avif still has the advantage in terms of support of course, but deploying jxl just for Safari already makes sense for many use cases. When Chrome follows, it will become a no-brainer.
JPEG has been hitting its limits for an extended period:
JPEG can only do 8-bit color depth, no HDR.
JPEG can only do lossy, with no lossless support
JPEG lacks good compression for graphics images
JPEG cannot do alpha transparency
JPEG cannot do animations
JPEG does not support multiple layers
JPEG compression efficiency is 30 years old and not as good
JPEG comes with annoying compression artifacts we all love
Banding, Noise, Blockiness, and more banding.
https://jpegxl.info/why-jxl.html
Basically lossy WebP and AVIF are video codecs, which are designed for the kind of quality you want when you can only see an image for 40 milliseconds or less. For still images, higher fidelity is usually desired but the video codecs tend to struggle to even keep up with the old JPEG at those operating points.
Similarly, video codecs are not designed for progressive decoding (rendering previews of a frame based on partial data), because that's a feature that doesn't make much sense for video. For still images on the web, progressive decoding is considered a desirable feature though to improve the user experience.
Of course there is. Better compression than WebP, and unlike AVIF, it supports progressive decoding, which is super important for users on a slow network. Although AVIF can sometimes produce 50% smaller size files than WebP, many site owners will opt for WebP anyway because it has progressive image decoding, so their website will display something while an image is nothing rather than nothing until the whole image is loaded. With that said, JXL achieves comparable compression to AVIF, and it suffers way less from generation loss, too.
- This can (in theory) be solved in other formats by improving the encoder, but the current jxl encoder is pretty much "set it and forget it" in terms of getting a good quality; other encoders are far more variable (e.g. I would use a different quality setting for B&W vs color and line-art vs photo).
- In others' testing (I don't use this feature) JXL has better lossless compression.
So, hopefully not too much longer!
If not, are you suggesting the article I posted is lying? There are a bunch of articles on this topic/flag, which were posted on the same day as the link I wrote earlier (17th of April).
I tried the suggestion in the article. It didn't work for me. Does it work for you?
Adding the format and maintaining it requires some work, but the potential for load speeds and data savings is huge. It's also finally a somewhat efficient format for bitmap animations after all these years of GIF and APNG. I've also run into the 16k size limit while converting some PNGs to WebP myself, to JPEG XL would be a nice way to losslessly compress those images more efficiently as well.
That said, so far WebP is serving me fine in most cases, I don't really care if it takes two weeks or two years for JPEG XL to make it into the mainstream.
If JPEG XL had been enabled by default in Chrome instead of removed, would HN be happy? Or would we be up in arms about how Google is trying to force yet another image format on the browser ecosystem?
A big complex format implemented in young C++ codebase is scary to deploy. Additionally, everyone using exact same code creates a risk of files being "bug-compatible" with that code, rather than conforming to the spec.
There are now multiple alternative implementations in the works, including in safer languages, so hopefully it will be easier to deploy in the near future.
But it doesn't look hostile. It's just random noise.
I’ve cultivated certain kinds of randomness for a long time, for instance you will not see me post a string of links to phys.org or world nuclear news to HN but rather mix it up. YOShInOn is my better half and is less hostile than I am even though eliminating hostility was not a primary goal, the source material it works from is low in hostility (probably the worst input is The Guardian) and my curation process (I look at 100% of everything it outputs) has a further cooling effect.
I am already bugged out by the angry p̶e̶o̶p̶l̶e̶ toots on Mastodon and seriously thinking about making a hostility filter.
The post by "@jaffathecake" reads like a truism. The main thread is indeed where the main thread business like (re-)layout happens, not just Javascript.
I have no idea why that would cause OP to act like a Texan boomer just spotted a gas station clerk wearing an N95.
I’m also pretty sure he knows how the Event Loop works in browsers https://vimeo.com/254947206
(He’s also on ‘gardening leave’ at the moment as he’s leaving Google)
I've been in the trenches for web development (and a little bit of web browser development) since 1995. I see the social factors around browser development (very little diversity) and the supporting software as having a direct link to the very difficult problem of a web browser not blocking the UI threads when it is updating a page from concurrent data sources including the net. Struggling to get a post-Netscape web browser to run on Solaris so our Sun Ray installation wouldn’t be useless…
I don't appreciate being quite literally dehumanized. It's the first step to the gas chamber.
Stupid browser/ego/chatgpt nonsense is nothing compared to what has happened back then.
At least people supporting Safari will be able to make use of the format for faster load times soon; the <picture> element makes the transition quite painless after all.
Actually, I just downloaded a JXL via Safari, and after confirming that it was still a JXL, I tried using it in a context where JXL isn't supported, and it automatically turned into a JPEG.
Google owns the license to another proprietary image format for large raster images (WEBP).
Google used to support JPEG XL in chromium, but dropped support for it. Many people believe this is specifically to manipulate a market advantage for WEBP.
No, they had an experimental implementation, behind a flag. No stable version of Chromium has ever supported JPEG XL.
(The claimed reasons for the removal: https://bugs.chromium.org/p/chromium/issues/detail?id=117805.... This is the last comment by an @chromium.org account.)
- Experimental flags and code should not remain indefinitely
- There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome
Yes. webp was finalized years ago and webp2 was cancelled in favor of everyone working together on AV1/AVIF.
Chrome never properly supported JPEG XL; it was hidden behind a feature flag, which of course almost no one enables. Their concerns are also valid: "we don't want to expose users to security-sensitive code without significant benefit for the users". Supporting as few as possible image formats is essentially a good thing for everyone; see e.g. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libpng
Google has banked on AVIF, which has quite a bit more traction. I do think that JPEG XL would be a good addition, but I also think it's reasonable to have a different opinion on that.
Everything about this post is wrong. The "many people who believe" this are engaging in nonsensical conspiratorial thinking without any evidence, which is pretty much what I've come to expect on HN about anything Google-related.
It's possible to sandbox these things. Firefox sandboxes some native libs, by compiling to WebAssembly, then back to C.
Lots of things are possible in principle; it's also possible to write rs-libjxl which would significantly reduce the problem. But there's a difference between "what's possible" and "what the reality is today", and in the context of what the situation is today it seems to me the concerns are valid.
This is a nonsense statement of opinion.
AVIF is severely more computationally expensive than JPEG XL (over 100 times worse at high bitrates), limited to 4k resolution, has worse compression, and is missing desirable features like progressive decoding and lossless recompression.
> There is just no incentive for Google to push for WebP: they have nothing to gain by it.
They have complete control over the standard. No one else can make changes to it without their approval. JPEG XL is governed by ISO.
https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
Apple adding JPEG XL was one of the happiest days in my life. Thank you Apple!
It also has to decode the image to a format supported by Chrome, which means you lose a lot HDR abilities. JpegXL can go to 32bit, but the supported formats max out at 12.
The TLDR version is AVIF is better at low bitrates/quality, JXL is better at higher bitrates/quality. And JXL has some other niches, like easier encoding/decoding, lossless conversion of JPEG, and support for some exotic formats that AVIF does not support.
In other words, we need both.
I find this article describes the differences and pluses/minuses incredibly well: https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...
TLDR in the article is that both technologies are valid and have a significant use case. I still work plenty with the browser and would _absolutely_ use JPEG XL as a replacement for WebP images, traditional JPEGs, and PNGs if I could.
It's a shame Google/Chrome is not supporting the tech. It would be a major improvement in the landscape.
https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...
The big one is that you can transcode existing JPEG files effectively and reversibly to JPEG XL without any additional loss. So you can get the benefits of the new format without having to re-sample your existing JPEG images.
On the other hand, JPEG XL is for static images only and is way better at rendering fine details. It has a bunch of specific features and optimizations. if you want to know more in details, check this post: https://cloudinary.com/blog/the-case-for-jpeg-xl
If it's important, someone should just implement support for it.
That mythical someone you speak of has done all the correct things already. This is squarely Google not wanting that feature.
I'm surprised that this is a problem at all.
Chrome can hold out but ultimately all they are doing is hurting their users.
We can't know how many are using jpeg xl since there is no available metrics to find out.
But for companies they should have two formats anyway: the original file and the optimized file.
Changing the optimized file should be an existing batch process
(For a large image collection you have some images that are heavily requested and most of the cost is network transfer, but you also have many images that are infrequently requested and for those the cost of storage in the dominant factor. I launched a large image collection in the late 2000's and many sites that did the same thing at the same time were ultimately crushed by running costs, Pinterest and Instagram were survivors, overall the economics of video collections turned up to be better than images.)
You could possibly also pre-populate cache - all new media files get sent to encoder and cached preemptively, and if they are popular enough they just stay there till they are not.
Please forgive the case study format, but I'm quite proud of what we did and this is the easiest way to back up my assertion with data: https://aws.amazon.com/solutions/case-studies/skyscanner-clo...
We're currently generating JPG, WebP, and PNG, depending on the source and the target. The problem with doing this on-demand is that formats that are great for delivery but slow to encode aren't useful. I did try to add AVIF, but the latency on the first request was too high for it to be practical.
But still, anything AV1 based just needs a lot performance to encode that just doesn't feel worth it at the moment. Our system to encode videos was tooled for that but developers eventually decided it's too slow/cpu hungry to bother. It was some time ago tho, encoders did get better...
Good thing JXL has the best progressive support of any image format available! [0, 1] Something which you can only find partially with incremental decoding in WebP and doesn't really exist in AVIF (just one of the many limitations of being bolted onto a video codec). You might often reconsider having both versions of a file with this capability. (which wasn't exploited much or at all with "dumber" and heavier progressive JPEGs)
0. https://opensource.googleblog.com/2021/09/using-saliency-in-...
1. https://jpegxl.io/articles/faq/#doesjxlsupportprogressivedec...?
What does this mean? Does chrome automatically convert images to webp when you click 'save as' on a jpeg image?
You can read more about it here: https://www.zdnet.com/article/how-to-get-around-chromes-new-...