> JPEG XL is intended for high quality images, so it is not optimized for this kind of extremely low bitrate (~0.1 bpp) usage.

It's better than AVIF at low bitrates. I did a comparison of the latest builds 3 months ago, and was amazed that JPEG XL has more detail than AVIF at 0.05-0.1 bpp (~120KB 1080p). It's a bit subtle, but I could see it. Once browsers ship full support (at least Firefox + Chrome), I'll be on board.

> and was amazed that JPEG XL has more detail than AVIF at 0.05-0.1 bpp (~120KB 1080p)

bpp = bits per pixel, not bytes. At 1080p, "0.05-0.1 bpp" is 13-26 KB. Much smaller than what you were testing. Might want to recheck your sizes, if you are actually looking at 0.5 bpp it would not surprise me at all that you found JPEG XL superior.

At very small sizes like 0.1 bpp the results are debatable, but I think AVIF is a pretty clear winner if you aren't too bothered by blurring. Samples at 0.15 bpp:

https://afontenot.github.io/image-formats-comparison/#air-fo...

https://afontenot.github.io/image-formats-comparison/#citroe...

https://afontenot.github.io/image-formats-comparison/#festa-...

In the experimental Document-Policy HTTP header, "bpp" does seem to signify bytes per pixel.

Document-Policy explainer: https://github.com/wicg/document-policy/blob/main/document-p...

I tried it out on my own site, and through trial-and-error I found that Chromium does in fact treat the "max-bpp" Document-Policy directives as bytes-per-pixel.

I could be wrong; my memory has faded. Please correct me if this is the case.

I'm not sure what HTTP headers have to do with anything. Using "bpp" to mean bits per pixel is extremely common in image encoding. See e.g. https://en.wikipedia.org/wiki/Color_depth where an uncompressed image is often 24 bpp (8 bits per channel). It's also common to use bitrate (rather than byterate) in audio encoding, see e.g. https://wiki.hydrogenaud.io/index.php?title=Bitrate

Downsize the 3000x2000 to the dimensions it will be displayed at and you will be able to go below 100KB.

What if it will be displayed at 3000x2000? I mean that's the whole conversation here, we're talking about images that are the focus point of the page.

Yes, then 100KB is usually not enough.

I normally deal with 720P images for internet distribution. For 3000x2000 that would be around 230KB to 250KB.

You replied to a thread about a photography website. I don't think 720p images are the norm for that use case.

In any event, I don't think the AVIF result at 250 KB is acceptable for photography either: https://0x0.st/o93a.avif - There's a ton of smearing and blurring that's very obvious when you're viewing the image at full size.

3000x2000 basically means "fullscreen on a retina display @ full resolution". You can only reasonably show one picture like that at a time. So it's completely OK to have the currently displayed picture at that resolution/size.

But all photo should be loaded at a much lower size, initially, and only downloaded at full size the the user puts them in full screen.

I know lazy loading is in vogue, but as a user it only ever seems to create problems for me. I’d much rather the website download all the images ahead of time on page load, so I don’t have to wait for full quality versions each time I full screen a different image.

This is the restaurant equivalent of : "We are at an all you can eat buffet, let me take 10 plates even if I only realistically will eat 4, so that if I want any more I don't have to stand up again".

While the other way (loading each image as you view them, or lazy) is functionally equivalent to waiting in line for each separate dish, which isn't quite so fun.

Maybe gallery sites could consider offering a preference to load all images upfront if you intend to view them all.

A good example would be housing sites, where viewing higher quality photos of each listing is a primary use case.