Don't ignore the fact that unlike WebP (lossless: missing grayscale | lossy: forced 4:2:0 chroma subsampling =x | both: missing metadata and progressive) and AVIF (lossless: worse than PNG in many cases, i.e. useless), it's both a very good PNG and JPEG replacement; only AVIF wins in my books are very low bpp lossy quality (not very interesting), hardware decoding support and dav1d being amazing.

I seriously see JXL as a "keep it for 50 years" codec to replace our aging tech.

WebP lossless as a format has two or three efficient ways of encoding grayscale (subtract green mode, palette, perhaps cross color decorrelation would work, too). Perhaps the libwebp APIs don't make it obvious. Density should be quite a bit better than with PNG.

Indeed, that wasn't obvious it was using tricks to improve the situation. But I do remember in my tests PNG beating Webp when using gray8 input.

I mean, Webp must store an RGBA tuple for each pixel, even for grayscale without alpha, right?

High quality progressive decoding at reduced filesizes is a big positive for me. There is no other format that supports that.

https://www.youtube.com/watch?v=UphN1_7nP8U

> High quality progressive decoding at reduced filesizes is a big positive for me.

This is really cool!

Honestly, I want to use regular progressive JPEGs for a current project of mine, but it seems that even that doesn't have support in all the tech stacks yet despite how long it's been around for, for example: https://github.com/SixLabors/ImageSharp/issues/449

Here's hoping that in the case of JPEG-XL this will be more commonplace! In combination with loading="lazy", it would surely make the experience of scrolling through modern sites with lots of content a bit less data intensive.

yeah, you are very much at the mercy of the libs you use if you want full feature parity with, for example, libjpeg-turbo in the case of JPEG.

In the browser where supported, I guess loading="lazy" probably already works (i havent tried). I think a more advanced version where you can choose maybe a "staged" loading type, or some mechanism to choose the pass/frame to pause the network activity at so that you can control it further via JS would be nice. At a minimum it would be a feature enabling a preview and a reduced download for the full version. I can see many usecases where that could be useful.

Ok, that looks better than Progressive JPEG, I'll give you that. ;-)

On the other hand: When your connection speed is 30 kb/s, images are probably the last problem with "modern" websites... ;-)

Oh yeah, definitely. For me the usecase is infinite scrolling, where you buffering offscreen images to allow you to continually flick through an image feed without having to "wait" for a preview to appear. Although you can do this without JXL, its a much more fluid experience with the progressive download - especially if you micromanage the behaviour of the network requests (i.e. progressive throttling of offscreen images past first frame). Lower filesize over JPEG is also a benefit there as you can more quickly resume the load of the higher fidelity frames when in view.

Current browser support where available is a lot more restrictive TBH, as you dont have any control over that behaviour. But outside the browser its solid gold.

The biggest advantage I can think about is transparency support.

Ok, but we got PNG for that. Photos usually don't contain transparencies, so why have several Megapixel/Megabyte large PNGs?

Because JPEG XL has smaller file sizes, which saves you money in the era of Managed NAT Gateway's 7 cents per gigabyte egressed.

Why not have one format good for everything image? There's zero reason to not have it now. Would you say 'We got GIF for that' if asked for animation?

I think animation is also part of the JXL spec, although may not be part of the reference implementation yet =)