Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

The cost model of images is such that you only get the full benefits of a new compression system if it is so widely used you can abandon old formats. That’s because the cost of images includes storage, transfer, plus handling and processing costs. If you have to maintain a large number of different formats, say JPEG, WEBP, AVIF,and JPEG-XL it’s just awful.

I can’t really use a new format until Safari supports it on mobile and mac at the very least. My take up of WEBP was considerably delayed because Apple was slow to get it in Safari on older Intel macs (one of which i have.)

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#4

Post by webmobdev » Thu, Apr 13, 2023, 4:35 PM UTC

I think currently the only browser that supports JPEG-XL is PaleMoon - http://www.palemoon.org/ - a hard fork of Firefox.

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#5

Post by scorpio241 » Thu, Apr 13, 2023, 5:29 PM UTC

webmobdev wrote: post #4

I think currently the only browser that supports JPEG-XL is PaleMoon - http://www.palemoon.org/ - a hard fork of Firefox.

Also Thorium: https://thorium.rocks/

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#6

Post by netol » Thu, Apr 13, 2023, 6:29 PM UTC

"Google's deprecation of the JPEG-XL image format in February in favor of its own patented AVIF format might not end the web in the grand scheme of things, but it does highlight, once again, the disturbing amount of control it has over the platform generally."

I thought AVIF was royalty-free.

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#7

Post by bick_nyers » Thu, Apr 13, 2023, 6:35 PM UTC

I really wanted (and still want) JPEG-XL to succeed.

Not sure how feasible this is, but one thing that could of helped with .jxl is allowing it to be read by a jpeg decoder. Let me explain. JPEG-XL has a feature that allows you to pull out a fully compliant jpeg, if you could somehow send the entire .jxl payload, and the browser's jpeg decoder just decoded the jpeg part, I feel adoption would be significantly easier, because then there is very minimal risk to just serving JPEG-XL with or without browser support.

Edit: Changing jpeg decoders around the world is not the approach I'm suggesting, but rather a carefully done "byte hack". Put the JPEG at the head of the binary blob, and stop decoding when the JPEG ends. If JPEG decoders only stop at the end of the byte stream, then another approach would be required.

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#8

Post by overstay8930 » Thu, Apr 13, 2023, 6:38 PM UTC

I like how this article conveniently left out the fact that Google also created JPEG-XL, and implies AVIF is a Google proprietary format.

Can't believe how far FSF has fallen if they have to resort to straight up lying to people to get their message across.

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#9

Post by Jasper_ » Thu, Apr 13, 2023, 6:42 PM UTC

netol wrote: post #6

"Google's deprecation of the JPEG-XL image format in February in favor of its own patented AVIF format might not end the web in the grand scheme of things, but it does highlight, once again, the disturbing amount of control it has over the platform generally." I thought AVIF was royalty-free.

The specification of AVIF is also publicly available, while you would have to pay a little under $500 to purchase all five of the ISO/IEC 18181 specifications for JPEG-XL. Not a monumental cost, but something prohibitive for a hobbyist:

https://www.iso.org/standard/77977.html?browse=tc https://www.iso.org/standard/81554.html?browse=tc https://www.iso.org/standard/80617.html?browse=tc https://www.iso.org/standard/80618.html?browse=tc https://www.iso.org/standard/80619.html?browse=tc

Re: Google's decision to deprecate JPEG-XL emphasizes the need for browser choice

#10

Post by Jasper_ » Thu, Apr 13, 2023, 6:43 PM UTC

bick_nyers wrote: post #7

I really wanted (and still want) JPEG-XL to succeed. Not sure how feasible this is, but one thing that could of helped with .jxl is allowing it to be read by a jpeg decoder. Let me explain. JPEG-XL has a feature that allows you to pull out a fully compliant jpeg, if you could somehow send the entire .jxl payload, and the browser's jpeg decoder just decoded the jpeg part, I feel adoption would be significantly easier,…

What value does this provide over serving a .jpg file?