The case against JPEG XL

GIF is there... because it will always be there because it's just a hit that will never go away. It's also lossless (when discounting colour depth).

The new formats are interesting webp, avif, JXL and so on.

Jpeg classic is the clear winner IMHO and will probably never be less relevant than the new fancier formats. JPG even does text and sharp edges, reds, and so on well if you tell your process to take into account chroma subsampling!

It's magic and it puts food on my table.

This is not a coincidence, but I don't think it was that devs looked at WebP and thought "huh, the lack of 4:4:4 and 10-bit support makes this less compelling for our product despite being all over the internet" – I think it was just a matter of not keeping up. Except for Apple, not sure why they took so long to implement it.

I suspect that eventually, the browser makers that are reluctant to add JpegXL support will do so, even if reluctantly, and so it will eventually "become useful on the web".

The reason why is Adobe added JpegXL as a compression format for PDF's, and as every browser maker wants their browser to also be a "PDF viewer", this means they must include a JpegXL decoder to be able to support PDF's going forward. If they must have a JpegXL decoder anyway, it is not that difficult to also add it as another supported format for the <img> tag.

HEIF is what is getting support in recent models; but JPEG still rules supreme for its compatibility.

I think one of the compelling use cases for camera manufacturers would be an interoperable format for editors. Since JXL has support for so many channels, you could load your image into an editor, edit it, add layers, etc., and export as JXL, which could be used for other things.

What exactly is "Fruit Company's format"?

I'm curious, where did you learn progressive AVIF works like this? Have you actually read the spec, or does your understanding comes from somewhere/someone else and never challenged the truthfulness of it? Progressive AVIF is truly "progressive" -- it never involves "loading a thumbnail" or "layering an image over another".

In reality, each pass (up to 4) can refine previous ones (thanks to AV1's inter-encoding toolset), avoiding storing redundant information between passes. The viewing environment doesn't need to render a given pass if a subsequent one has already been downloaded. Finally, scaling is configurable -- you can have your first pass already be at full res, just at a lower quality.

Hope this helps clarify how progressive AVIF actually works under the hood.

Unlike a thumbnail, higher-resolution layers can be predicted from the lower-resolution layer, so those bits are not wasted. That is not possible by layering <img> elements.

Yes, the format is not inherently progressive. But having the fine steps in progressive quality that JPEG-2000 and JPEG-XL have has less general usefulness than the amount of words complaining about it.

The preview in finder is still going to block. Im saying this as a MAC user speaking of experience browsing mounted drives that sometimes are slow and it feels like the window freezes up.

EDIT: Oh! Of course. AVIF is based on AV1. For some reason I was thinking HEIF the entire time I was reading the article. Man... withdrawn!

Really good read, btw. Very good points.

The scenario I'm thinking of is sending a photograph by email. Let's say Sally has just had her second baby, and wants to send baby pictures to her mother, the baby's grandmother. Neither Sally nor her mother are computer professionals, and they don't want to care about image formats. Sally wants to upload a file from her camera, attach it to an email, and send it. Her mother wants to click on the email and see pictures of her new grandchild. Neither one of them wants to have to convert the image themselves.

Let's say it's a few years in the future and Sally's camera produces JPEG XL files by default. (Which I don't think would happen if browsers didn't support it, for exactly the reason I'm about to articulate). If Sally's mother's browser doesn't support displaying JPEG XL, then although Sally (who uses a different browser than her mother) sees the picture in the email when she sends it, her mother writes back an email saying "the picture didn't show up, can you resend it?" And they spend a few back-and-forth emails before finally getting tech support from a friend who helps Sally convert the picture to old-school JPEG so her mother can see it.

If that's the experience for end-users, cameras would hesitate to switch to JPEG XL as a default format. Because nobody wants a hostile review from a user saying "My mother couldn't load my baby pictures, what kind of lousy camera are you making?"

So even if it's not the best format for the Web, I'm still persuaded that having universal browser support for a format intended for photos is an important factor, and devices like cameras will not switch to it as a default format until manufacturers are certain that browser support (and OS support, and electronic photo frame support, and so on) is nearly universal.

None of that takes away from the argument "Other image formats are better for saving space on the Web", which is the main thrust of your post. But I do disagree with the last line, "I'm just not personally convinced we need it in browsers any time soon." I believe that if browser adoption is lacking, adoption of the format in places where it makes lots of sense (like cameras) will also be slow.

What are your thoughts on that argument?

Also, look at the graphs – Iris-WebP beats JPEG XL.