Hacker News Reader

Comment by shaicoleman | Hacker News Reader

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

View on HN

Thanks, that all sounds fairly reasonable then.

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

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

The ecosystem are the other browser vendors.

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

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

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.

> 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

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)

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.

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.

Firefox has it on Nightly. Not great either.

Reply on news.ycombinator.com