By that logic WebP should have never got out of the door, because all non-Chromium browsers were explicitly reticent in implementing support for it and only finally started doing so with several years delay (in the case of Apple several years even more). But of course WebP was Google's own image format…
Yes, fair enough, parts of Google contributed to JPEG-XL, too. But the basic gist remains – for WebP they decided it was the greatest thing since slice bread and enabled it regardless of what the rest of the "ecosystem" thought, whereas now all of a sudden they're supposedly that much concerned, even though Chrome is by far and large the majority of that ecosystem, Apple prefers their own format choices anyway, and it's not as if it's not also a chicken-and-egg situation.
Things can change in 12 years. Google also killed off it's WEBP v2 development last month. Apple is all in on AVIF/AV1 but has shown little to no interest in JXL (might be burnt from back when they supported JP2).
AVIF, as an outgrowth of AV1, has support from every major browser publisher, with the possible exception of Microsoft (though they are a governing member of AOM) as they're the only one which isn't shipping AVIF support right now (and as of October): https://caniuse.com/?search=AVIF
Also cameras. Which either aren’t interested (no one really cares about non-RAW formats on DSLRs), or are going AVIF once hardware encoders land (Android phones)
DSLR market has pretty much stopped (rarely any new DSLR camera is released) as everyone shifted to mirrorless cameras. Camera manufacturers mostly added HEIF (Canon, Sony, Fuji) as the non-RAW image format, because they already have HEVC for video.
Camera with a lossy / lossless 12-bit, 14-bit JPEG XL would definitely be interesting for many photographers. Not everyone wants to be forced to do a complete post-processing with RAW. JPEG is to limited (8-bit only) and HEIF isn't much better, while not having much support (especially on the web) because of the patent situation.
Also good to know that Jpegli (a traditional jpeg codec within libjxl) allows for 16 bit input and output for '8-bit jpegs' and can deliver about ~12 bits of dynamics for the slowest gradients and ~10.5 bits for the usual photographs.
Jpegli improves existing jpeg images by about 8 % by doing decoding more precisely.
Jpegli allows for encoding jpeg images 30 % more efficiently by using JPEG XL adaptive quantization (by borrowing guetzli's variable dead zone trick), and the XYB colorspace from JPEG XL.
Together, you get about 35 % savings by using jpegli from the decoding + encoding improvements. Also, you get traditional JPEG that works with HDR.
Jpegli is predicted to be production ready in April or so, but can be benchmarked already.
At 100% depending on the platform. For years many have complained about Chrome moving too fast and shipping stuff without a consensus with the other vendors, this might signal a change from that.
Couldn't any interested parties just enable the flag for testing? That doesn't seem a insurmountable challenge, given that the code is, or was, already in there.
Well, I am interested in saving server bandwidth by delivering smaller image files at the same quality. I can't enable a flag on my user's browsers though. :)
