The case against JPEG XL

It seems to me that AV1 (the codec used in AVIF) has seen a lot more development in recent years, by virtue of being widely adopted for video. JPEG XL has not seen comparably massive adoption, perhaps owing in large part to Chrome rejecting it on dubious grounds (in spite of eagerly forcing the adoption of both WebP and AVIF earlier on). The pace of the reference implementation’s development has grown very slow, and most of the modest attention it’s been getting seems to have recently moved to the new Rust decoder, once the browsers finally made up their mind that’s what they wanted from the devs.

That considered, I don’t think it’s a fair comparison between the codecs. JPEG XL used to be far more impressive than AVIF; it’s great people (author included) have managed to push AVIF forward, but until similar efforts have been made for JPEG XL in earnest, I don’t feel like a comparison between their encoders says much about the codecs themselves. The author does take a guess on how much the JXL encoder could be improved, but that’s just that: a guess. It won’t be know until it’s been tried. And especially given the whole unfortunate history, I think JPEG XL really, really deserves a try.

"For non-photographic images, the argument that “they should be vector images” doesn't hold up because many images could be vector images but aren't, and they can't be vectorized perfectly. “The world should be different” is not a justifiable defense against optimizing for the way the world actually is."

This is a good paragraph. I see people forget to apply that last sentence all the time.

That JPEG XL prime computation is a pretty ugly DoS. Just selecting it in Finder, with the preview pane open, maxed out every core on my Mac inside a QuickLookSatellite that also ate 4GB of RAM while doing so - for a good 15 seconds. Not bad for a 2KB picture. It seems like Apple did not set sane limits on their JXL previewer.

It is, however, an incredibly cool demo of what the format is capable of. I'm not completely sure if an image format should be that flexible, but I'm impressed nonetheless.

> Progressive rendering (which AVIF supports) decodes a low-fidelity rendition before the full image arrives. AVIF didn't support progressive rendering for a while, and during that time I believe it was deeply oversold. Now that libavif has implemented it (it was always possible), the conversation appears to be over.

This is false. AVIF does not support progressive decoding/rendering. What the author is referring to here is image layering. A lower resolution image layered below the full resolution image, which is loaded and rendered first. That is not progressive decoding/rendering. It is a thumbnail.

Unlike AVIF's false advertising, JXL truly supports progressive decoding/rendering. With JXL, you do not first load a thumbnail before loading the actual image. The lower-quality image that JXL shows while decoding is derived from the data of the actual, full-resolution image.

If JPEG XL doesn’t become useful on the web, is it really likely to become popular with camera manufacturers, professional image editing tools, etc?

What does it offer there that existing workflows can’t support? Do those advantages make up for the transcoding that every web publisher would need to do to make the outputs useful on the web?

I wasn't really sold on the argument initially, given they admit there's some real lossless usecases, but this is a good bit from the conclusion:

> Not to mention an additional compatibility headache now exists for anyone just trying to download an image from the Internet and use it somewhere – it was hard enough to get widespread WebP adoption, and I don't think it's worth doubling the pain by having to climb the same hill for AVIF and JPEG XL. Especially when JPEG XL doesn't appear to add anything to the Web platform.

It is very annoying downloading an image for the web and then trying to upload it somewhere else also on the web during these transition periods.

We all know these aren't purely technical reasons, it's to break the monopoly of one Internet Company's decoder format portfolio. You can't let one Fruit Company's format be the thing either, so it's basically a L for engineering but a W for pleasing everyone TBF.

Much like WEBP, JPEG-XL is two different codecs in one. There's VARDCT mode, and Modular Mode. Modular Mode is normally used for lossless, but it can also be used for lossy as well. When you use Lossy Modular Mode, you get different kinds of compression artifacts than what you'd see in a JPEG file.

For Lossless: JPEG-XL wins, then WEBP, then PNG. (Sometimes lossless WEBP wins)

For Lossy: AVIF wins, then JPEG-XL, then WEBP, then JPEG.

I'm the author if anyone has questions – AMA

I didn't realize progressive AVIF was a thing recently either; the comparison between that and jxl was pretty surprising.

All my photos are HEIC. Why not just use what I have and not translate?