> Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons:
> - 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 increm ental 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
---
If I were to put on my tinfoil hat, I would imagine the people involved here are desperate to put 'Removed unused code and removed maintenance burden by X%' in there performance reviews for this year
Also AVIF is more performant for most cases. Lossless is not what matters on the web.
However, if the enthusiastic support in the Chromium bugtracker from Facebook, Adobe, Intel and VESA, Krita, The Guardian, libvips, Cloudinary, and Shopify is any indication, it seems baffling to conclude that there would be insufficient ecosystem interest.
That's why I assumed there was demand for JPEG XL.
Unlike AVIF, JPEG XL also has advanced progressive delivery features, which is useful for the web. And if you look at the testing described in the post, JPEG XL also achieved higher subjective quality per compressed bit, despite having a faster encoder.
You can see lossless benchmarks against other formats here:
https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQp...
If a new image format doesn’t have a hardware decoder it’s dead. The security surface of new formats is unacceptable if it’s going to be slow and power-hungry too.
Only problem with JPEG is the lack of HDR.
1) transfer JPEG XL,
2) decode the JPEG XL to DCT coefficients,
3) encode a new JPEG1 file
4) decode the new JPEG1 file
5) render pixels
JPEG XL as image format:
1) transfer JPEG XL
2) decode the JPEG XL to DCT coefficients
3) render pixels
Two additional coding steps (3 and 4) are needed in the HTTP Content Encoding approach. If we want to transfer lossless JPEG1s, it is less computation and a faster approach to add JPEG XL as an image codec.
If JPEG XL is too powerful and creates danger for AVIF, then one possibility is to remove features such as adaptive quantization, lossless encoding and larger (non-8x8) DCTs. This effectively makes JPEG XL as JPEG1 recompressor as an image codec.
Also, JPEG XL's reference implementation (libjxl) has a more accurate JPEG1 decoder than any other existing implementation. Asking someone else to paint the pixels leads to worse quality (about 8 % worse).
AVIF fails to deliver a consistent experience at 3+ BPP -- I'd hate to compress my family pictures at AVIF even at high BPP, some part is smudged in a weird way.
libjpeg-turbo and mozjpeg does deliver a consistent experience at 4 BPP
guetzli and jpegli delivers a consistent experience at 3 BPP
JPEG XL delivers a consistent experience at 1.7 BPP
Source? JPEG XL has already shown, over 10,000 sample size and over a wide variety of BPP to be better than AVIF, on latest JPEG And AVIF versions.
AVIF, on the other hand, has yet to shown anything similar.