Google Chrome/Chromium Goes Ahead In Removing JPEG-XL Support

[phoronix]

Phoronix: Google Chrome/Chromium Goes Ahead In Removing JPEG-XL Support

Back in October was the surprising move of Google deprecating JPEG-XL support in their Chrome/Chromium web browser. Google engineers argued there wasn't enough interesti n JPEG-XL and not sufficient enough benefits over existing formats. Their plan was to remove the JPEG-XL support in Chrome 110 and indeed that has now happened...

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

[TuesdayPogo]

Can someone point me the good points about jxl?

I tried comparing between WebP, JPEG-XL, AVIF, and HEIF recently. WebP got the smallest size, still has alpha channel, looks decent enough unless I pay really close attention, and most importantly has the most compatibility of them (not being able to drag-and-drop to Discord and displayed correctly makes some format a no-go for me) so that's what I'm using now for archive and screenshot format.

But I've heard some good things about jxl, though unfortunately my phone can't open it. I don't know what's the finer point of it was, though.

[RejectModernity]

What a fucking joke.

[xorbe]

Webp sucks because it forces 2x2 red channel, 92%+ jpeg (with best chroma) is still my standard although not best on file size. I got odd results out of the AVIF encoder using gimp, it looks good but there is a change in content. So I was looking forward to testing JPeg XL.

It's painful right now, so many motorcycle sites switched to webp and a high compression default. The images (quality) are so much worse than when they were using jpeg. So I have to temporarily force webp off to scrape a good jpeg if I want to save a particular motorcycle pic. And then a whole lotta vehicle forums don't accept webp, so then I have to manually convert webp to jpeg to post.

[Amaranth]

Can someone point me the good points about jxl?

I tried comparing between WebP, JPEG-XL, AVIF, and HEIF recently. WebP got the smallest size, still has alpha channel, looks decent enough unless I pay really close attention, and most importantly has the most compatibility of them (not being able to drag-and-drop to Discord and displayed correctly makes some format a no-go for me) so that's what I'm using now for archive and screenshot format.

But I've heard some good things about jxl, though unfortunately my phone can't open it. I don't know what's the finer point of it was, though.

The advantages of JPEG-XL are that you could feed a JPEG in to it and get a smaller image that is bit for bit identical on the output (and in fact could be converted back to the same original JPEG) and it was fairly cheap to do as you were only running the final step of the compression. The thought was this could allow you to set up a pipeline to eventually transition all your old things to JPEG-XL by letting you start with either format and convert on demand to depending on user agent support. So you start with all JPEGs and transparently upgrade to JPEG-XL for new browsers then once the authoring tools catch up you start storing JPEG-XLs and transparently downgrading them (so long as you saved them with the right options) to JPEG for older browsers. Or you take all your JPEGs and convert them to JPEG-XL at the start to save disk space and then downgrade when needed.

Other formats may have better compression or more functionality but so far none have been better enough to wipe out JPEG and JPEG-XL negates most of the advantages they have so seemed like a clear winner on a pragmatic basis.

[Termy]

Morons. That's about all that is to say about that decision....

Can someone point me the good points about jxl?

https://en.wikipedia.org/wiki/JPEG_XL#Features

Afaik there is no other format that offers all those options.
Of course there probably are formats that cater to one or two of those points on the same level or better than JXL, but none that cover such a wide base of applications and usecases.

[Calinou]

Webp sucks because it forces 2x2 red channel

WebP has lossless and near-lossless modes which feature full 4:4:4 RGB. That said, near-lossless is sometimes larger than lossless (with cwebp -z 9), so it's not always worth it in all situations.

I do think the default lossy quality settings are too aggressive (except for hiDPI images), but changing them at this point is considered compatibility-breaking.

[rene]

Sad. Uninspirational. No courage.

[abu_shawarib]

A developer published some tests comparing image codecs that shows JPEG-XL being mediocre, opposing most prior benchmarks from others:

http://storage.googleapis.com/avif-comparison/index.html

[sobrus]

I'm not surprised at all. Both AVIF and WebP (and AV1 too) are being developed by Google (among others) for internet/cloud/streaming usage and are optimized for their use cases, using patents they hold (all these codecs are derivatives of On2 VP8 and VP9).
Why should they support competing solutions?

JPEG XL is intended to replace JPEG, for offline, high fidelity, archival usage. Google has no point in supporting these use cases, you'd better use their cloud for everything. But since storage and bandwidth costs them money they will prefer formats excelling at low bpp like AV1 and AVIF.

I've found AV1 to be crap quality-wise, AVIF is better but it takes 2 minutes to export a single photo from Darktable to AVIF on my 5950x... (lower quality is faster, but still not fast, around 20secs for 50% quality, and that's with tiling enabled). And it takes around two seconds to decode it back with gThumb etc. Way too slow.

cjxl takes 2 seconds to encode this image (99% quality) and it's around 0.5 secs to decode it with gThumb. So I really don't know how these tests were made.

As soon as jxl reaches 1.0 and there's better software support for jxl (and brotli compressed exif), I'll probably convert all my jpg to jxl and save 20% space for free. There is possibility to reconstruct JPG exactly bit-to-bit as it came directly from camera, if needed.