4 months later, Chrome still hasn't changed its opinion about supporting JPEG XL

4 months later, Chrome still hasn't changed its opinion about supporting JPEG XL(bugs.chromium.org)

10 points by ciccionamente 2 years ago | 7 comments

Related post on HN (2023-06-06): Chrome still hasn't changed its opinion about dropping JPEG XL support (https://news.ycombinator.com/item?id=36213330)

dang 2 years ago | |

Thanks! Macroexpanded:

Chrome still hasn't changed its opinion about dropping JPEG XL support - https://news.ycombinator.com/item?id=36213330 - June 2023 (234 comments)

Yes, that's a dupe by HN standards. This is in the FAQ: https://news.ycombinator.com/newsfaq.html.

ciccionamente 2 years ago | | |

Ok - sorry and thx for letting me know!

ajkjk 2 years ago |

I don't have an opinion on the issue, but reacting to the headline: yes, that's how decisions work.

scorpio241 2 years ago |

https://foolip.github.io/interop-reactions/ This is a list of Interop 2024 proposals sorted by number of reactions - JPEG XL definitely wins

aeurielesn 2 years ago |

Assuming Chrome wants to push a different technology and that's why they don't want to help the adoption of JPEG XL, what would be that alternative technology they want to push instead?

JyrkiAlakuijala 2 years ago | |

Chrome recommended focusing on improving old formats.

""" 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. We'll work to publish data in the next couple of weeks.

For those who want to use JPEG XL in Chrome, we believe a WebAssembly (Wasm) implementation is both performant and a great path forward. """

After this announcement Chrome themselves have added a new experimental image format into libavif 1.0, based on AV2. Libavif and AV2 are not WebAssembly, but native codecs. It is a full new format, not optimizing existing formats.

https://www.phoronix.com/news/libavif-1.0-Released

Jpeg xl team has ported according to the advice from Chrome the JPEG XL heuristics into an old format, the usual 8-bit Jpeg. This effort is called jpegli. Jpegli can do 10+ bits in the 8-bit formalism, which is great for HDR, and can compress 20-30 % more depending on which features and quality settings of the codec are used.