[flagged]
In your first comment, you stated as a fact that "lawyers pulled the emergency brakes". Despite literally no one from Google ever saying this, and Google giving very different reasons for the removal.
And now you act as if something you made up in your mind is the default theory and the burden of proof is on the people disagreeing with you.
The person responsible for AVIF works on Chrome, and is responsible for choosing which codecs Chrome ships with. He obviously prefers his AVIF to a different team's JPEG-XL.
It's a case of simple selfish bias.
---cut---
Helping the web to evolve is challenging, and it requires us to make difficult choices. We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), and we’re very much aware that these costs are borne by those outside of Google. When we evaluate new media formats, the first question we have to ask is whether the format works best for the web. With respect to new image formats such as JPEG XL, that means we have to look comprehensively at many factors: compression performance across a broad range of images; is the decoder fast, allowing for speedy rendering of smaller images; are there fast encoders, ideally with hardware support, that keep encoding costs reasonable for large users; can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it?
After weighing the data, we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment. [...]
From: https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
* Chrome's browser partners say JPEG XL adds monetary or hardware costs.
* Chrome's device partners say JPEG XL adds monetary or hardware costs.
* Does JPEG XL work best for the web?
* What is JPEG XL compression performance across a broad range of images?
* Is the decoder fast?
* Does it render small images fast?
* Is encoding fast?
* Hardware support keeping encoding costs reasonable for large users.
* Do we need it at all or just optimize existing formats to meet new use-cases?
* Do other browsers and OSes support JPEG XL?
* Can it be done sufficiently well with WASM?
We could perhaps create a GoFundMe page for making it cost neutral for Chrome's partners. Perhaps some industry partners would chime in.
* Does JPEG XL work best for the web?
Yes.
* What is JPEG XL compression performance across a broad range of images?
All of them. The more difficult it is to compress, the better JPEG XL is. It is at its best at natural images with noisy textures.
* Is the decoder fast?
Yes. See blog post.
* Does it render small images fast?
Yes. I don't have a link, but I tried it.
* Is encoding fast?
Yes. See blog post.
* Hardware support keeping encoding costs reasonable for large users.
https://www.shikino.co.jp/eng/ is building it based on libjxl-tiny.
* Do we need it at all or just optimize existing formats to meet new use-cases?
Jpegli is great. JPEG XL allows for 35 % more. It creates wealth of a few hundred billion in comparison to jpegli, in users' waiting times. So, it's a yes.
* Do other browsers and OSes support JPEG XL?
Possibly. iOS and Safari support. DNG supports. Windows and some androids don't support.
* Can it be done sufficiently well with WASM?
Wasm creates additional complexity, adds to load times, and possibly to computation times too.
Some more work is needed before all of Chrome's questions can be answered.