The JPEG XL Image Coding History, Features, Coding Tools, Design Rationale

https://arxiv.org/abs/2506.05987

by ksec • 1 year ago

94 44 1 year ago

arxiv.org

ekunazanu2• 1 year ago

JPEG XL had so much going for it. Kinda sad it was killed off just like that.

fc417fc802• 1 year ago

JPEG XL is alive and well (as is ublock origin as it happens).

MrAlex94• 1 year ago

As it currently stands there should be over a billion devices that natively support JPEG-XL, as it was introduced in all Apple OSs since September 2023[1].

On the web alone it should be close to a billion users with support for JXL due to Safari’s market share.

[1] https://cloudinary.com/blog/jpeg-xl-how-it-started-how-its-g...

ndriscoll2• 1 year ago

It's also supported in Windows, GNOME, KDE, pretty much all image editors/viewers, and pretty much every other relevant program except for chromium based browsers.

arp2422• 1 year ago

It wasn't "killed", it was always disabled by default in Chrome, and removed for really quite reasonable reasons: literally every other image decoder has had serious vulnerabilities. Enabling it by default would expose a gigantic attack surface that almost certainly will be exploited sooner or later.

This is also why Firefox doesn't support it by default (IIRC it doesn't even link against libjpegxl by default in release builds – only nightly ones).

There is nothing preventing the Chrome or Firefox people from revisiting all of this in the future.

It seems to me the Rust implementation of JPEG XL is by far the best path forward for broad JPEG XL support in Firefox, Chrome, and other browsers. While Rust is of course not a complete guarantee there will never be any security issues, it does eliminate virtually all of the major exploits that have targeted image decoders in the past. Both Firefox and Chrome have expressed interest in this.

badgersnake2• 1 year ago

And because they wanted to push WebP

OneDeuxTriSeiGo5• 1 year ago

JXL is still alive and well, it's just taking time to reach the prime time.

- Mac OS, iOS, and Safari support JPEG-XL

- Windows has first party JPEG-XL support as of this year (admittedly it's opt in rather than default)

- Essentially every major image processing app, editor, or drawing app supports JPEG-XL

- Firefox has preliminary support for JPEG-XL gated behind a feature flag and the nightly release.

- The JPEG-XL team is writing a direct port of the reference libjxl library into rust[1]. There already exists a third party rust port by some of the mainline contributors and it has ironed out a lot of the issues with the porting process prior to this mainline port. This first party rust port is intended to be gradually brought up to a hardened, production ready state.

- Mozilla has stated they have no objections to fully adopting JPEG-XL in Firefox once the rust port is production ready [2].

The last major barriers other than getting the rust code production ready will be chrome and android's first party support/adoption.

------

TLDR: JPEG-XL is very much not dead and instead people are nose down working hard to continue pushing its adoption forward.

------

1. https://github.com/libjxl/jxl-rs

2. https://github.com/mozilla/standards-positions/pull/1064

ekunazanu2• 1 year ago

To address this concern, the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox.

I was not aware of this. Also judging by this and the sibling comments, it looks like the momentum didn't die despite Google's apathy. Hopefully the fact that their own team is now developing the rust port, as well as the growing support in other platforms, is enough to make Google reconsider its choices.

donatzsky• 1 year ago

It wasn't killed off. Support was removed from Chrome, for what appears to be rather spurious reasons, but practically everyone else are busy implementing it.

jandrese• 1 year ago

Sadly removing support from Chrome is effectively the same as killing it off. And the reason is Google wants people to use webp instead.

JyrkiAlakuijala2• 1 year ago

killed off

my guesswork is that JPEG XL will likely outlive Chrome by 100+ years

Dwedit3• 1 year ago

There's nothing stopping you from using it in your own applications. Just not directly in the browser for now.

robertoandred• 1 year ago

It works in Safari and is coming to Firefox.

tristor• 1 year ago

I use JPEG XL / JXL all of the time, the fact it was "killed off" is news to me. I also use Firefox and not Chrome, so maybe that has something to do with it. If Google decides they want to divide the web by being stupid and failing to follow standards, we have very little path to change that, but it certainly does not create any form of consensus or resolute outcome. Google removing JPEG XL from Chrome because they want to force everyone to use a much worse standard they control (webp) doesn't mean anything about the future of JPEG XL.

_bent2• 1 year ago

This appears to be very well written and easy to understand even if you only know the basics of digital image encoding.

I found the parts about patching and frames with different blend modes very fascinating. I wonder if it would be possible to build a GUI DCC app that uses JpegXL as its project format. It seems that it could support layers, splines, symbols (transformed instances of layers), blend modes and animations without "baking" any of it to pixels

jonsneyers• 1 year ago

Thanks!

Yes, my hope is that jxl can become an interoperable format for layered images. It does not have all the functionality of image editor formats (PSD, XCF, etc), but it does have a very useful subset of that (named layers with basic blend modes). For interchange, it would be very suitable since it has state of the art compression (both lossy and lossless), does not force you to merge the layers before exporting, while the images can be viewed directly by any application that supports jxl — since the blending happens inside the decoder, the viewing application can be blissfully unaware that it even is a layered image, it will just get the merged image from the decoder if it doesn't ask for the individual layers.

The JPEG XL Image Coding History, Features, Coding Tools, Design Rationale

Related Stories