Lossless was discounted due to webp, but doesn't webp lossless only use 8bit depth RGB? (I think it is important to have a separate file extension for lossless stuff anyway, otherwise it gets confusing quickly)

We have to apply some weight to the fact that one is open, one isn't, right?

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.

What do you think the best use cases for jxl are? Where does it still have an advantage over other formats?

I would argue that even if JPEG XL isn't the best choice for Web images, if browsers don't support it then that will widely hinder its adoption for its non-Web use cases. Would you agree?

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?

AVIF is royalty-free, with open-source implementations not developed by Google. Google's implementation is libaom; as you can see, SVT-AV1 beats it. SVT-AV1 is developed by a number of companies – historically Meta, Netflix, Intel, independent contractors, and others. I worked on SVT-AV1 myself. I don't see how this is a bad thing for everyone, even if Google drove standardization of AV1?

Worth noting that this progressive AVIF, when viewed in Chrome, has only two states: a "base layer" which pops in around 8KB, and the full image which appears 270KB later. The comparison JXL continues to refine during most of the download, so it winds up looking substantially better than the AVIF at around 95KB loaded, and looks pretty good (almost as good as the full 280KB AVIF) by 175KB. I suspect that there are a lot of knobs to turn for both progressive modes, but this particular case could definitely be cherry-picked to favour either codec.

Think about how many images large platforms deliver every day, and the benefits of saving bits on each of them.

I wonder if similar hacks apply to zlib and .png as well.

I’ve been shooting with semipro to pro cameras for decades across brands, and I haven’t came across a single camera that supports shooting JPEG XL.

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

Web publishers should definitely be stripping metadata at least, and transcoding isn't much harder. For anyone who cares about bandwidth, transcoding to efficient formats is non-negotiable; if you don't, then why do anything? Just ship PNG, who cares?

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.

There exist lossless use cases, for sure. I think most people would be well-served by high-fidelity lossy that saves a lot of bits while still looking perceptually identical. Whoever isn't served by that most likely doesn't care about size savings, and can stick with lossless PNG.

Lossy Modular isn't efficient enough to compete with even JPEG.

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

Does the difference matter?