Comment by peppermint_gum
3 years ago
>To fix this, you'd need to convince Google, and other large companies that would be exposed to law suits related to these patents (Apple, Adobe, etc.), that these patent holders are not going to insist on being compensated.
Apple has implemented JPEG XL support in macOS and iOS. Adobe has also implemented support for JPEG XL in their products.
Also, if patents were the reason Google removed JXL from Chrome, why would they make up technical reasons for doing so?
Please don't present unsourced conspiracy theories as if they were confirmed facts.
[flagged]
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.
People who look after Chrome’s media decoding are an awkward bunch, they point blank refuse to support <img src=*.mp4 for example
Seems entirely reasonable, considering that <img> is for images, whereas mp4 is for videos, no?
1 reply →
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.
It's a case of simple selfish bias.
Why not take Chrome's word for it:
---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...
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 other browsers and OSes support JPEG XL?
* Can it be done sufficiently well with WASM?
1 reply →