The reasons stated are:

- Experimental flags and code should not remain indefinitely

- There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL

- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default

- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome

https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reason...

Thanks, that all sounds fairly reasonable then.

Not really. It was hidden behind a flag, so where should the "entire ecosystem" (who?) show interest?

The ecosystem are the other browser vendors.

By that logic WebP should have never got out of the door, because all non-Chromium browsers were explicitly reticent in implementing support for it and only finally started doing so with several years delay (in the case of Apple several years even more). But of course WebP was Google's own image format…

It took the other browsers up to a decade to support WebP, who wants to do that again?

JPEG-XL is based on the Google Pik proposal among other things and they were active in the spec'ing - there is no conspiracy here.

Yes, fair enough, parts of Google contributed to JPEG-XL, too. But the basic gist remains – for WebP they decided it was the greatest thing since slice bread and enabled it regardless of what the rest of the "ecosystem" thought, whereas now all of a sudden they're supposedly that much concerned, even though Chrome is by far and large the majority of that ecosystem, Apple prefers their own format choices anyway, and it's not as if it's not also a chicken-and-egg situation.

Yes, they recognize now that WebP was a mistake, which is why they won’t single-handedly force any more image formats upon the web.

(Safari learned this lesson earlier when they got stuck being the only browser to support JPEG2000, and Microsoft with JPEG-XR)

Have you heard about AVIF?

Things can change in 12 years. Google also killed off it's WEBP v2 development last month. Apple is all in on AVIF/AV1 but has shown little to no interest in JXL (might be burnt from back when they supported JP2).

> has shown little to no interest in JXL

I'm not aware that they've shown any interest in JXL, so "little" seems unnecessary.

> It took the other browsers up to a decade to support WebP, who wants to do that again?

Google, with AVIF

> Google, with AVIF

Google is a major contributor to JXL.

AVIF, as an outgrowth of AV1, has support from every major browser publisher, with the possible exception of Microsoft (though they are a governing member of AOM) as they're the only one which isn't shipping AVIF support right now (and as of October): https://caniuse.com/?search=AVIF

Huh? AVIF is an image format offspring of AV1 from the Alliance for Open Media which founding members include Apple, Mozilla and Google.

AV1 and AVIF is landing in all browsers. They get the AVIF support for free when they implement the AV1 decoder.

>They get the AVIF support for free when they implement the AV1 decoder.

No, it isn't free. You have to implement the support for the AVIF container. This is why libavif exists.

Also cameras. Which either aren’t interested (no one really cares about non-RAW formats on DSLRs), or are going AVIF once hardware encoders land (Android phones)

DSLR market has pretty much stopped (rarely any new DSLR camera is released) as everyone shifted to mirrorless cameras. Camera manufacturers mostly added HEIF (Canon, Sony, Fuji) as the non-RAW image format, because they already have HEVC for video.

Camera with a lossy / lossless 12-bit, 14-bit JPEG XL would definitely be interesting for many photographers. Not everyone wants to be forced to do a complete post-processing with RAW. JPEG is to limited (8-bit only) and HEIF isn't much better, while not having much support (especially on the web) because of the patent situation.

Fully agree with this sentiment.

Also good to know that Jpegli (a traditional jpeg codec within libjxl) allows for 16 bit input and output for '8-bit jpegs' and can deliver about ~12 bits of dynamics for the slowest gradients and ~10.5 bits for the usual photographs.

Jpegli improves existing jpeg images by about 8 % by doing decoding more precisely.

Jpegli allows for encoding jpeg images 30 % more efficiently by using JPEG XL adaptive quantization (by borrowing guetzli's variable dead zone trick), and the XYB colorspace from JPEG XL.

Together, you get about 35 % savings by using jpegli from the decoding + encoding improvements. Also, you get traditional JPEG that works with HDR.

Jpegli is predicted to be production ready in April or so, but can be benchmarked already.

jpeg xl can power raw formats and raw-like lossless formats, and is super interesting in that domain

another format that is limited to three channels or has bit depth limitations would not be similarly interesting

another format that is for example 50 % worse in lossless compression would not be interesting in this space

That's as useful as saying DNG can be powered by lossless JPEG. No standard lossless JPEG decoder can do anything useful with DNG files.

Most RAW formats are based on TIFF... no standard TIFF decoder can decode a RAW format either.

..who together compose what, like 10% of the browser market?

At 100% depending on the platform. For years many have complained about Chrome moving too fast and shipping stuff without a consensus with the other vendors, this might signal a change from that.

Waiting for consensus from other browsers while ignoring consensus from the broader software industry is not what most people meant.

Firefox has it on Nightly. Not great either.

Couldn't any interested parties just enable the flag for testing? That doesn't seem a insurmountable challenge, given that the code is, or was, already in there.

Well, I am interested in saving server bandwidth by delivering smaller image files at the same quality. I can't enable a flag on my user's browsers though. :)

you know, industry / browser people talk to each other. But not necessary on social media. Or publicly.

Yep, and they wanted support for JPEG XL

> Do we know why they chose to remove it?

Phoenix had an article on why Google decided to remove JPEG-XL.

https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reason...

The official justification seems to be a) experimental nature of JPEG-XL, b) lack of demand, c) maintenance burden.

Take it with a grain of salt. Personally I don't buy it.

>experimental nature of JPEG-XL

I wonder what exactly they mean by this because JPEG-XL is a ISO standard. So if it's already standardized, how the heck is still "experimental" ?

https://www.iso.org/standard/77977.html

JPEG XL was implemented in Chrome behind a flag.

Other than that there is nothing experimental in JPEG XL.

> I wonder what exactly they mean by this because JPEG-XL is a ISO standard.

I see there's some confusion. A specification might be formalized in an international standard, but implementations of said standard can and often are experimental.

You don't magically turn code production-ready by having a committee sign off on a document.

> I wonder what exactly they mean by this because JPEG-XL is a ISO standard.

So were JPEG-XR and MJPEG2000.

and neither of your examples is experimental

Seems to have been partly based on this: https://storage.googleapis.com/avif-comparison/index.html

At the bottom there's a link to a lossless comparison, which shows JPEG XL outperforming WebP, AVIF, and PNG on size (no metrics on decode speed).

Yes, and lossless JPEG doesn't matter, especially on the web.

lossless matters for lots of images on the web (like logos and other images with text). lossless jpeg recompression is also really useful because it allows CDNs to save bandwidth by replacing jpeg with jpeg-xl.

> lossless matters for lots of images on the web (like logos and other images with text)

Couldn't some make the point that SVG can be a better format for things like that, especially logos? After all, raster graphics will always have drawbacks when compared to vector graphics for things like logos and other non-photographic content.

On lower-DPI displays, which remain very widespread outside of mobile, vector graphics usually look worse than pixel graphics.

Even with losses it's better than WebP.

and AVIF

Thanks for the link. That does look quite damning, seems that the already-supported AVIF format is overall the better choice based on these metrics.

Actually, the results of the AVIF team's comparison do show the value of JPEG XL, if you look a bit further than the main page and dig into the actual plots. E.g. according to this plot, JXL is about 15% better than AVIF for 'web quality' images (around 1 bpp): https://storage.googleapis.com/avif-comparison/images/subset...

Here is a detailed analysis: https://cloudinary.com/blog/contemplating-codec-comparisons

I have a moderate sized selection of mostly B&W comics. JXL is the first format that out performs JPEG 2000 on them. It cleans AVIF's clock on them, in a rather unfair comparison of JXL's default settings vs hand tuned settings for AVIF with different settings for color and B&W comics.

It also far outperforms an optipng encoded PNG for lossless. I know either my corpus or my eyeball is different from the benchmarks used by AVIF but I do want to share this outlier.

Not sure about your comparison specifically, but in general the hard edges in comics should be an ideal case for AV1's spatial prediction. JPEG-XL eschewed that in favor of being inherently progressive; its splines promised to make up some of the difference but last I checked the encoder still doesn't use them.

Categorically, this is the main reason why even the main JPEG-XL dev agrees that AVIF is currently better with non-photo content [1]

[1] https://twitter.com/jonsneyers/status/1550161314961555457

I observe that it depends on which quality you aim to. At low quality AVIF does a good job with line drawings. I suspect much of it is because of the 8-color local palette mode. When you raise the quality/size a tiny bit (to need 9+ unique colors in an area), JPEG XL does an equal job with the edges, but starts getting all the subtleties, lonely faint dots, noisy or weak textures right, whereas it can be impossible to convince an AVIF encoder to store them at any quality setting.

Cartoon/anime collectors seem to be passionate about image quality and they may have observed the same as I have. At least I have learned a lot about image quality from anime fans during my image compression career.

Web devs don't care that much about quality, they are more looking into creating monetary savings in bandwidth and sometimes trying to lower the latencies. E-commerce is yet another thing, where the image quality may turn into revenue and becomes important again.

It's the stippling and hatching that most compression formats struggle with

Keep in mind that it's from the AVIF team though. :)

There are lots of questions about that data for example why was the testing carried out in Chrome 92?

https://mobile.twitter.com/jonsneyers/status/159877483772342...

Try to replicate it.

It was no longer unstable beta

It competes with WebP?

This seems vaguely familiar, I wonder where I've seen another dominant browser vendor engage in anticompetitive behaviour before?

Google has added AVIF.

In both cases the reason was that they've already invested in the video codec powering them, and the 1-frame-video-as-image format was almost free to add.

This "two for one" reasoning does have some downsides though. Here I listed ten of them:

https://twitter.com/jonsneyers/status/1596965036131426304?s=...