Is there a patent, copyright, or royalty reason why JPEG-XL isn't championed for the web? It would be awful to have another format that can't be used in certain Linux distros or browsers.
Or is it their desire to be slightly careful about which image formats they have to support in perpetuity? With AVIF you get to re-use a bunch of your AV1 decoding code too. And the reference JPEG-XL decoder is still on version 0.x, with no sign that they'll make a stable release any time soon.
Why everyone is all up in arms about the fact that the industry is finally standardizing on a good royalty-free image format is beyond me.
AVIF doesn't do everything, and a codec that's designed to encode video frames will always be limited compared to a pure image codec. It especially has trouble with lossless.
If we were picking a single royalty-free image codec for the 2018-2026 range, it should be JXL.
> AVIF doesn't do everything, and a codec that's designed to encode video frames will always be limited compared to a pure image codec.
Image encoding is a subset of video encoding, so any limits are mostly arbitrary, and in AV1's case image-only encoding was a consideration from the start. AVIF in particular supports color depths up to 12 bits, wide color gamuts, many color spaces and standards for color space signaling, etc., so I'm curious what aspect you consider limited.
This isn't true. There are a number of things that make sense for images but not videos.
1. Progressive rendering.
2. Big images (up to 2^30 by 2^30)
3. More channels (up to 4099) (this can be useful for transparency, depth, or tracking random other things for scientific purposes)
5. High bit depth (up to 32 bit) (this is mostly useful for sciency stuff)
4. Lossless encoding. Basically no one wants lossless video (it's way too big), but lossless images often make sense.
Also images use a wider range of resolutions. AV1 has a minimum 4x4 block size (compared to 2x2 for jpeg-xl) which will hurt it for small images (e.g. icons). For example, The ycombinator icon is 18 by 18 pixels which would make AVIF store a 20x20 image which is 23% more pixels. (I can't find a source but I think I remember hearing that AV1 actually has a minimum size of 64x64 but I can't find a source for that)
I can think of a few aspects where avif is limited.
12-bit is fine for delivery, but it's not enough for authoring. Cameras are typically 14-bit and during authoring you'll want some footroom on top of that.
Also avif is not usable for lossless: it is slower than png and often worse. Lossless is crucial for authoring workflows.
For high-fidelity lossy compression, avif can be worse than even jpeg.
Avif cannot do CMYK at all, so for printing use cases it is not usable.
Basically it is targeted at web delivery, but it's not really a general-purpose image format that can be applied in a broad range of use cases.
Seemingly half or so of images delivered anywhere currently are VP8-image (webp). You'd expect those to be AVIF instead in the coming years, which is obviously very much superior.
Forget lossless originals, this is about the average images that users see online, like 1000x1000 (or smaller) and 200kb (or so).
The key part is support for real-time hardware decoding. You can't have parts of images refer to far-off parts to save on redundant encoding, and your budget for calculation time and complexity is relatively small.
It's byte for byte identical once you expand to an array of pixels. The storage format uses more advanced (lossless) compression, but the pixels that come out are identical.
Sound more like a chicken and egg issue, look like "big tech" are mostly using the format for archival purpose.
As Mozilla put it, adopting a new format increase the attack surface ( that is already quite large ) of a browser, they can not simply take the reference decoder and integrate it into their codebase, they also have to use resources toward maintaining it. Firefox currently integrate jxl support behind an experimental flag, but that could mean the feature is in testing and could be deprecated in order to better allocate their resources.
Jxl can be byte for byte identical as the original jpeg at an around 80% iirc. Google isn’t interested in perfect archiving, they’d rather have lossy compression, which you can also do.
Why can’t they take the reference decoder?
As for the attack surface, why would their own codes be less vulnerable?
They don’t tend to support each other’s codecs either, not because of attack surface
Or: parts of the internets are salty, because Google didn't get the message that nowadays it is mandatory to support their shiny toy in Google's product.
Well, Chrome doesn't support bunch of things, and the world didn't end. The usual topic is, that is supports too many things actually, more than it should.
The bugreport even states: "There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL". Not sure on how Google "measured" that.
By looking at their developer which would have to do the work and those developers said "I'm not interested." Then looking at Mozilla developers which said "I'm not interested." Then looking at Safari developers which also said "I'm not interested."
Having developers decide they won't invest into your toy format forever is not FUD.
It's somewhat similar to H2 Push, which had similar justifications about adoption and interest. When frameworks finally started supporting it to some extent Google expressed their wish to kill the feature, that instantly dissuaded most developers finishing their implementations or from even considering it.
(Not to mention the fact that the developer tooling for H2 Push was terrible to say the least for a long time)
To me it seems Chromium/Google are somewhat out of touch on how slow the web and adoption of new things happens.
In this case, it was also behind an experimental flag, I don't know how the f** they expect people to show interest if it's practically not usable on the web.