Removing the JPEG XL code and flag from Chromium
bugs.chromium.org
bugs.chromium.org
Arguably the best image format to come out since JPEG:
- High-fidelity lossy image compression
- Best lossless image compression
- Progressive decoding
- Lossless JPEG transcoding
(Google has demonstrably the code to render this. If they decide to stay outside for political reasons, well, so be it.)
(Webkit seems to have basic integration ready, but to be still working on color profile decoding and animations [1]; Firefox seems to be fairly complete. What other Chromium-based browsers are going to do, remains to be seen. I hope, they will decide to patch the code to support JPEG XL.)
[1] Webkit has a quite dedicated declaration on its related ticket, "JPEG XL is the future of all image formats." https://bugs.webkit.org/show_bug.cgi?id=208235
----
P.S.: If this was meant as a snarky remark on market shares, well… (I'd be happy to see the bias towards Chrome somewhat diminishing, especially in developer communities. If folks would start developing in other browsers according to web standards and then test with Chrome, some common perceptions may shift.)
It was.
I'm a Firefox user, and web developer. Features live and die based on their caniuse profile.
I'd love to deploy JXL but I can't if Chrome Devs hold this attitude. Doesn't really matter what other browsers do at this point.
Compared to all of JPEG XL, Brunsli is less code, and the adoption story is more compelling: you need CDNs/infra to support recompression, but don't need the entire ecosystem to change formats. Content-Encodings can be dropped if there isn't uptake--there's precedent with SDCH--so you could roll it out without a flag once it's well tested and give sites a reason to add support, avoiding a chicken and egg problem.
I don't think AVIF makes it irrelevant because 1) JPEG-to-Brunsli is a far smaller step than JPEG-to-AVIF, since Brunsli is far faster to encode than AVIF (especially in software) and adds no loss beyond the initial JPEG encode, and 2) even if AVIF and HEIC are widely adopted, there's a mind-boggling quantity of JPEGs (exabytes?) that won't go away. Dropping JXL as an image format makes the Content-Encoding more relevant, since the lossless recompression it provides is no longer going to be available by other means.
A star expressing interest in 1109698 couldn't hurt the chances (though I suspect they're slim). They haven't closed the bug, so I don't think they've officially said they'll never do it, though the current language does assume third_party/jpegxl exists.
I think voting up the issue is probably a quicker chance of getting a satisfactory resolution (simply supporting jxl). Alternately, perhaps a WASM based polyfill might be possible, and hope that if at least one other browser adopts it natively and a polyfill is available, that chrome will reconsider.
Worst case - if this turns out to be irreversible - even then I think it's more strategic to let the inevitable dust this will cause settle, and then start picking up the pieces afterwards - the discussions in the interim might reveal more of the chromium teams reason for blocking this, which might inform future steps.
The case for a Brunsli filter in the meantime is legacy JPEG content is never going away, and there will also be a long "meantime" where we know AVIF is the endpoint but it's still impractical for many because of SW encoding cost. Brunsli saves ~20%, so it's not nothing, and it's CPU-cheap.
A WASM polyfill would kind of be cool. Someone did it for Bellard's "BPG" (HEIC in a different container) in a ServiceWorker, and one just doing JPEG1 transcoding would be even lighter (and, unlike this PNG-making polyfill, would save reasonably small JPG files if the user right-clicks): https://sequentialread.com/better-portable-graphics-bpg-on-t...
(As I understand it – and this is not much –, libjxl returns a bitmap and an ICC profile, which then has to be matched against the color space of the display. How is this going to work in a WASM decoder inside the browser? Or does it just render in sRGB, hoping for the best?)
[0]: https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
Baring in mind that turning on jpegxl means exposing yet another image format parser to the web and the security track record of image formats has not been stellar.
IMO the killer feature of JPEG XL is its ability to losslessly transcode already existing JPEG images.
See also these articles for a more detailed comparison:
https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...
https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...
(disclaimer: they were written by one of the authors of JPEG XL)
It's a nice transitory feature, but I think improved progressive decoding is even more worthwhile.
Features that actually matter to normal users are what is important.
In that area progressive display seems like it would arguably be more useful, though I think it would still be dependent on what the image size is - websites now routinely require megs of JS to display anything at all, because net speeds are now fast enough that huge amounts of data are needed to get to a “noticeable” latency that would warrant display of incomplete data.
WEBP has blurry chroma, looking like it's subsampled then upscaled. The chroma on JPEG-XL is trying to be full resolution, and if you look at the chroma in isolation, it looks a bit blocky, but it's not blurry at all.
The lossless recompression of existing .jpg content and faster software encoding for its native VarDCT format seem to provide immediate benefits in contexts where AVIF doesn't fit well now, either because AVIF encoding is slow or because AVIF would require a lossy reencoding of a lossily compressed source.
Although I do wonder how much value this would add for most sites. WEBP is pretty good and well supported today. Plus internet speeds are fast enough now that images tend to be much lighter than all the various tracking libraries and frontend frameworks that the browser needs to load anyway. Unless you run a very image heavy site the performance impact here would probably be negligible over WEBP and in many cases it might not even be worth the dev effort to switch to JPEG XL even if you're still using JPG.
That's not to say I think it should be removed, but just an acknowledgment that there's probably point of dismissing return here in which it doesn't make sense to support a slightly better image format, because the effort to support it exceeds the negligible benefits.
JXL, AVIF and HEIC use next-gen compressors and are about half the size of JPEG and WebP at the same quality. HEIC has a range of terrible patent problems, so the current choice is AVIF vs JXL.
AVIF has wider industry support and is likely to get hardware decode. JXL is technically more interesting and more flexible, and far better CPU encode/decode performance.
- 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
It's nonsense -- how can they claim "not enough interest" when we can't enable the feature on a public website (our visitors won't be able to see images).
That doesn't seem like a lot of interest as far as anyone can tell. The main interest has been from Facebook and Adobe, afaik.
If it's wrong it can be redone later. It isn't a blood oath never to reimplement it.
The way this gets fixed for real, at least to me, is to get mozilla/apple to have skin in the game.
As for killing the format - Google maintains libjxl, the jpeg-xl reference impl, and has for years.
But like, if the people maintaining the reference impl for years really want to kill the format, maybe we should at least understand why? They've been in the thick of it, after all.
Controlling an image format is basically worthless for a company like Google. Especially since they are always royalty free so far.
The cost to Google in bandwidth/storage/etc of images is much greater than than they could ever make off control.
(Unlike, say, Adobe or someone)
There are two reasons why you would use a higher compressing image format.
(1) To save network bandwidth, (2) to save storage.
Adding AVIF, WebP, and JPEG XL to a JPG file help with (1). To help with (2) you have to be able to replace the JPG with something new. Supporting more than one new file format is counterproductive.
It took me years to decide WebP was well-supported enough to be worth using but until very recently it still got a major caveat
that "Safari 14.0 – 15.6 has full support of WebP, but requires macOS 11 Big Sur or later."
With new image formats Apple decides it is a reason why you should buy a new machine and decides not to add a decoder to the library that works with older processors.
Ecosystem doesn't mean a few fans on HN, in this context they mean "people building browsers".
The post’s linked ticket tracks the feature from when it was introduced to Chrome.