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.
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.
If we were picking a single royalty-free image codec for the 2018-2026 range, it should be JXL.
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.
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.
Forget lossless originals, this is about the average images that users see online, like 1000x1000 (or smaller) and 200kb (or so).
As the head of tech for a site with a few tb of user-supplied jpeg files (which are thumbnailed), I can see the appeal…
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.
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
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.
Having developers decide they won't invest into your toy format forever is not FUD.
"uncertainty, doubt": "not enough interest from the entire ecosystem to continue experimenting"
"fear": "By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome"
The news about it being rejected increased JXL's profile tenfold and there's a lot more interest now.
(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.