Readit Newsotherwise the same
Nothing really supports it. Latest Safari at least has support for it not feature-flagged or anything, but it doesn't support JPEG XL animations.
To be fair, nothing supports a theoretical PNG with Zstandard compression either. While that would be an obstacle to using PNG with Zstandard for a while, I kinda suspect it wouldn't be that long of a wait because many things that support PNG today also support Zstandard anyways, so it's not a huge leap for them to add Zstandard support to their PNG codecs. Adding JPEG-XL support is a relatively bigger ticket that has struggled to cross the finish line.
The thing I'm really surprised about is that you still can't use arithmetic coding with JPEG. I think the original reason is due to patents, but I don't think there have been active patents around that in years now.
First, there's Lossy WEBP, based on VP8 video compression. It is better than JPEG, but mediocre by today's standards. Lossy AVIF and Lossy JXL greatly outclass lossy WEBP.
Second, there's Lossless WEBP, which is not in any way based on VP8. Lossless WEBP is a stellar image format that not only compresses very well, but also decompresses very quickly. Its biggest competition is Lossless JXL, which usually compresses to a smaller file, but decoding that image is slow enough to be annoying. Sometimes lossless WEBP produces a smaller file than lossless JXL.
Disclaimer: I am the designer of WebP lossless and Jpegli.
my guesswork is that JPEG XL will likely outlive Chrome by 100+ years
Unrelated, I'd also be curious to know how their initial data transformation varies from that of your TIFF scheme.
"In principle, JPEG XL supports having one main image and up to 255 sub-images, which sounds like a good match for c0 and f1, . . . , fn−1. Unfortunately, the current implementation in libjxl does not allow us to tweak the compression ratio and subsampling on a per-sub-image basis. Due to these limitations, we currently use one JPEG XL file per channel so that we have full control over the compression parameters."
This follows a general trend in modern codecs where the format itself allows for many different tools, and the job of the encoder is to make good use of them. See "Encoder Coding Tool Selection Guideline" for a nice chart of the possibilities: https://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf
But usually exotic things are easier to engineer if you do them outside of the container, then you don't need to figure out how the standard works.
It's a really excellent software. Its default output quality is storage quality, while the file size is acceptable for mobile data and cloud storage of pictures in most countries. It producing progressive pictures by default still helps when quickly swiping through a whole album of vacation pictures stored on cloud storage, and its progressive output actually reduces size rather than add to it. And it's compatible with everything so now I just throw everything lossy I produce through its default settings until JXL becomes natively supported in Chrome and Windows.
