Not used anywhere? E.g. Affinity Photo has support for JPEG XL, but not for AVIF. Not used in browsers because they are nearly controlled by Chromium, which is clearly biased toward AVIF.
https://en.wikipedia.org/wiki/JPEG_XL#Official_support
Official support:
Squoosh – In-browser image converter[42]
Adobe Camera Raw – Adobe Photoshop's import/export for digital camera images[43]
Affinity Photo – raster graphics editor[44]
Chasys Draw IES – raster graphics editor[45]
Darktable – raw photo management application[46]
ExifTool – metadata editor[47]
FFmpeg – multimedia framework, via libjxl[48]
GIMP – raster graphics editor[49]
gThumb – image viewer and photo management application for Linux[50]
ImageMagick – toolkit for raster graphics processing[51]
IrfanView – image viewer and editor for Windows[52]
KaOS – Linux distribution[53]
Krita – raster graphics editor[54][55]
libvips – image processing library[56][57]
vipsdisp – high-performance ultra-high-resolution image viewer for Linux[58]
Qt and KDE apps – via KImageFormats[59]
XnView MP – viewer and editor of raster graphics[60]
Pale Moon – web browser[61]
There's only one issue with this list - many of these applications also support AVIF, and were "sitting on the fence" over the issue, which should not be interpreted as a sign of JXL's success. And the ones that don't are very likely to fall in line after the Chromium decision.
> Not used anywhere? E.g. Affinity Photo has support for JPEG XL, but not for AVIF.
It also support PSDs. Should Chrome support PSDs?
> Not used in browsers because they are nearly controlled by Chromium, which is clearly biased toward AVIF.
Ah yes, Google, a major contributor to JXL, is "clearly biased towards AVIF".
I'm sure you'll find your saviours at Apple (governing member of AOM, shipped AVIF this year), Mozilla (governing member of AOM, shipped AVIF in June 2020, default-enabled in October 2021), or Microsoft (governing member of AOM).
> Ah yes, Google, a major contributor to JXL, is "clearly biased towards AVIF".
Why is it surprising to you? Many major companies are contributors to a bunch of standards that they don't end up supporting. Meanwhile Google is forcing device manufacturers to support its codecs in hardware on pain of sanctions and removing support and software. Guess which codec Google wants them to support (hint: AV1)
PSD is a pretty heavy format, and does not have the benefits for serving images to end users (e.g. good compression) that JPEG XL/AVIF have. So probably not. But there are still use cases for serving PSDs on the web in creative communities, so it would be pretty cool to have.
I linked https://cloudinary.com/blog/the-case-for-jpeg-xl in another comment which links to several big players requesting full JPEG XL support. It seems the reason why it wasn't adopted more broadly is that there was no full support for it in Chrome. I wouldn't even consider it a chicken and egg situation.
The reply by the Chromium engineer (from Google? - I'm not sure) to a long thread of people from several companies quantifying the benefits of JPEG XL and requesting that it be supported is just sad:
> 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
It contains 8 links to the Chromium bugtracker in this paragraph:
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.
JPEG XL implements lossless image compression, but that's definitely not the most interesting feature. It also implements lossless JPEG recompression. So your existing JPEGs can be served with ~20% less bandwidth, without quality loss.
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.
Lossless JPEG recompression, if it’s so good, can be done at the HTTP layer.
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.
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).
Nope. In my eyes AVIF is not more performance. It makes photos suffer and become blurry, especially so in highly saturated areas, skin, marble, vegetation. Once beautiful things start to look like cheap plastic.
Check the file size - anything will look bad if you set the compression too high. If you see AVIF images with some artifacting, find a JPEG of the same image and compare file sizes. An AVIF the same size as a JPEG will be better than the JPEG - an AVIF only 50% of the size will probably be visually undetectable to most people. An AVIF only 20% of the size... you'll tell. Same for JXL - if I set my JXL to compress to only 15% of the size of the JPEG, it's hardly a fair comparison.
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
JPEG XL was not used anywhere on the web because no browser shipped with JXL support. As soon as Google enabled it in Chrome, Mozilla in Firefox or Apple in Safari, we would've started to see adoption.
I don't know another, but Pale Moon does support it so your original statement is just false. And it can be actually a good way to test a proposed patch to Gecko---many issues were found and fixed after it first got JPEG XL.
It's not used anywhere because it is/was behind a feature flag so browsers didn't support it out of the box. IIUC, various companies like BBC, Facebook, and others were ready to deploy JPEG XL support.
If you take your approach, nothing new (including the webp standard that Google/Chrome pushed) would be released on the web because nothing is using it.
WebP should not have been released and no one should have used it. Google should stop letting individual employees invent new image formats as hobbies. (This happened _twice_. WebP lossless is a whole different codec from lossy.)
AVIF is a Netflix engineer quick-hacking a video format as an image format -- without actual experience in codec design, image compression or psychovisual research, without consulting such people to get the design right. When size and memory limitations were noticed, a tiled approach was proposed where globally spanning artefacts through the image will emerge. No one has been able to propose a fix for this and other kludges yet.
AVIF doesn't match WebP lossless in density, even given the 10 years more of compression research. AVIF doesn't even beat PNG at lossless, which itself was hacked together in a few months ~25 years earlier (primitive filtering, mixing filter bytes with image data, botched 16 bits compression, layering a primitive 1980's byte-compressor and filtering instead of designing a codec).
Isn't that circular reasoning? Chrome shouldn't support JPEG-XL because not enough consumers support it? Chrome is the number one consumer of images. If Chrome added support, suddenly 90% of people would be able to use the format.
(Also EOG and IrfanView are image viewers, not production tools.)
Yeah, to me this is another sign that Chrome's dominance is a menace to the open web. Whatever the best outcome is here, it's very concerning to me that a possibly important improvement can be blocked with so little meaningful explanation.
In what way does Google control WebP? They have frozen the format and nothing will be added to it. WebP2 was abandoned. Google is also involved with JPEG XL - actually some developers that worked on WebP now work on JPEG XL.
If someone controls something it is the Chromium/AOM/AVIF/AV1 team that controls and decides what multimedia formats go inside Chrome/Chromium thus controlling what is used on the web and ignoring what the web community has to say about it.
In that case WebP, CSS grid, CSS shadow DOM, HTML5, or any other new feature on the web would be untennable (esp. if deployed behind a feature flag first) because when those were created and implemented in browsers there was no uses/consumption of them.
