Chrome Responds "No" to JPEG XL

> JPEG XL is a royalty-free raster-graphics file format that supports both lossy compression and lossless compression. It is designed to outperform existing raster formats and thus become their universal replacement.

> The bitstream was informally frozen on 24 December 2020 (...) The file format and core coding system were formally standardized on 13 October 2021 and 30 March 2022 respectively.

source: https://en.wikipedia.org/wiki/JPEG_XL

Rationale from thread:

> 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.

> Jim

I really like JPEG XL tech, seemed like the first format that could completely replace animated gif, png, jpeg with a simple upgrade path and backwards compatability story for lots of weird corner case usages.

I do have sympathy for the not adding lots of formats to the web argument though.

Disappointing. I'll have to figure out the JXL WASM polyfill. Maybe if I wait a few months someone else will do it for me?

There's https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/... that provides `JXLModule.decode(data: BufferSource): ImageData | null`, but for a polyfill I suspect you'd want a method to get the dimensions of the image and an IntersectionObserver to defer actually decoding the image until it scrolls into view. Having to load the image with XHR is annoying.

It was an opt-in feature, so what data did they weigh?