Mate, you're literally pulling something from your ass. Chrome engineers claim that they don't want JXL because it isn't good enough. Literally no one involved has said that it has anything to do with patents.
>There must be a more rational reason than that. I've not heard anything better than legal reasons. But do correct me if I'm wrong. I've worked in big companies, and patents can be a show stopper. Seems like a plausible theory (i.e. not a conspiracy theory)
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.
Doesn't make sense when they support GIF or animated WebP as images. Animated WebP in particular is just a purposely gimped WebM that should not exist at all and would not need to exist if we could use video files directly.
If you want a simple conspiracy theory, how about this:
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.
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. [...]
I try to make a bulletin point list of the individual concerns, the original statement is written in a style that is a bit confusing for a non-native speaker such as me.
* 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 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.
