Support JPEG XL

[chi]

I think it's a great opportunity for Firefox to stand out by supporting JPEG XL before any other browser.

Imagine images served by Cloudflare and Cloudinary load faster and look better only with Firefox. Firefox was a pioneer of web technologies and it should win the title back, if Firefox just keep following Chrome without any differentiation, why would people choose Firefox?

If the decoder memory safety is a concern, maybe Mozilla can start a crowd funding campaign to sponsor a Rust decoder, even the campaign itself will attract reports and attentions for Firefox.

Mozilla argued AVIF was already supported as a same generation but clearly JPEG XL has many advantages:

• Much better encoding performance (AVIF is not suitable for realtime CDN optimization at all)
• lossless and better high fidelity (video codec based image format)
• HDR (there will be a billion of mobile devices with real good & bright screen in just a few years)
• Little generation loss (important for web)

Supports from Facebook, Adobe (they're adding export support), Intel and VESA, Krita, The Guardian, libvips, Cloudinary, Shopify

[Simile9041]

At least make the flag in "about:config" work in stable Firefox! That can't be so hard can it?

Forks like Waterfox or Floorp or even Pale Moon support JPEG XL out of the box with no complaints about bugs.

[conrad]

So now Apple supports it in macOS/iOS/Safari, Samsung has added support in its camera/gallery apps in the last couple weeks, we've seen evidence that Microsoft is adding it to WIC which effectively means Windows/Explorer will have complete native support, every Linux distro I've checked has libjxl available, every Qt-based program/viewer supports it or can trivially add support for it, I can save it in Affinity Photo 2, or Krita, or GIMP, or darkroom, or Paint.NET (and Adobe has added support to some of their products like Camera RAW, is actively working on adding it to PS, and recommends using it or AVIF for HDR images on their website). There's a C++ implementation, a Rust one, a Java one, and a JS+WASM polyfill. Companies like Shopify and Cloudinary are eagerly wanting support.

But Father Chromium doesn't want it and so I guess supposed-FOSS-advocate Firefox must sit here twiddling their thumbs (despite the fact that multiple forks of Firefox support it).

[RafaelLinux]

Simile9041, I can't believe what I'm reading. What's the matter with Mozilla?

[cmscy]

Mozilla has now a new CEO and she promised that they will double down on their core products and Firefox, so we pray they will hire developers, fix the colorspace issues, enable JXL, the new code, not the outdated from nightly, get better codec support, get HDR running(also needed for JXL because it is progressive lossless with animation and HDR support) and all those, before 2025, because firefox is dead, especially when Floorp and Waterfox already have JXL running, are in active development, and if they had more funding, you know the colorspace and HDR would had been patched and shipped by now

[RafaelLinux]

I wish that happens sooner than later, thanks for the info!!!!

[Yoochan]

as stated previously, using the patches applied by waterfox, the support of jpegxl should be a breeze

[Rez]

I'm curious if lack of support isn't a result of pressure from Google, who want to promote webp, considering the amount of funding Mozilla receives from Google/Alphabet.

[conrad]

@RezI think it's more likely that they don't want to expend limited development resources on a format that won't get widespread adoption on websites unless the browser engine with a de facto monopoly on the market decides everyone else is allowed to use it.

That said, I think there has been such overwhelming support from everywhere in the industry outside of web browsers (especially in the context of how long adoption of new formats normally takes, including the older formats of WebP and AVIF), combined with how much work has already been done between Firefox and its forks that they should move forward on this regardless.

The benefits of JXL have already been expounded upon a thousand times so I won't do it again, but it really seems like this is an issue with internal politics at Google:

1) Google itself has people in Google Research working on JXL decoders and such, so it's not even the entire company from the top down being opposed to its adoption.

2) There are multiple people on the Chromium team that were involved in the creation of WebP and/or AVIF, including the guy who approved removing the flag for JXL support and then authored the commit that tore out all of the JXL code. He's listed as one of the co-authors of WebP and is the primary contributor to libwebp.

The hardest parts of creating a new, feature-rich, royalty-free media format adopted have already been done, namely the creation of the standard itself, the creation of multiple decoders, and wide, ongoing industry support outside of the browser market. It would be criminal to let the internal politics of a single, publicly-traded ad company smother an excellent format in the crib in favor of their own repurposed-video-keyframe formats.

[Jarek]

https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html

"Introducing Jpegli: A New JPEG Coding Library (...) 35% compression ratio improvement at high quality compression settings." for the old JPEGs, beside recompression - in JPEG XL library we users of Firefox are still waiting for ...

[RafaelLinux]

Thanks Jarek. Just I read today that new and I understood why Google is no interested in promoting JXL. Instead of using and supporting a standard with incredible features and versatility, they release a standard "derived" from JXL that will need to rely on other libraries anyway. Nothing is mentioned about it providing anything more than compression. If we already had WebP as a standard available in all browsers, the sensible step would have been to gradually move away from JPG and WebP to JXL. But no, better to add more complexity to the tangle...

[Lumihauki]

Yes please, future should be JPEG XL

[kkthompson]

+1 for JXL. Seems like an easy and obvious win.

[Firepal3D]

JPEG XL support is a win for everyone involved.

It cuts bandwidth by about half compared to PNG, sometimes significantly more for flat assets.

The effort settings cover a wide gamut of applications, from a quick lossy encode on-device, to exhaustive optimization of pre-existing lossless images in a server environment, and everything in-between. 

The default quality setting JPEG XL provides has a good tradeoff between fidelity and filesize. 

It has transparency support. It has (lossless) animation support.

And lastly, it's finally a ne lossy format that's not a dumb video frame in an image's clothes. ;]

[Firepal3D]

@RafaelLinux Jpegli is just a JPEG encoder that uses some things from the result of JPEG XL's development... Not a new format.

It's really good (it's fast with MUCH better fidelity than classic JPEG encoders) but it's absolutely not JPEG XL, that's sure.

JPEG XL has a crazy-good lossless mode...

[conrad]

@RafaelLinux @Firepal3D Correct, jpegli is basically just another JPEG-compliant encoder that's a bit more efficient. Almost none of the benefits of JXL (e.g. progressive decode, transparency, overlays/layers, depth maps, much stronger generation loss resilience, much higher max res, 4099 additional channels, 32 bit depth max, etc.) are present, and it's not like the compression is even as good as JXL. I compressed a PNG capture of some text using jpegli using its visually-lossless mode vs. JXL's equivalent and the resulting JXL was both noticeably smaller AND looked better (typical JPEG artifacts were still obviously present around the edges of the text whereas JXL looked SIGNIFICANTLY better).

Really hoping the new CEO of Mozilla prioritizes this considering how much work has already been done and how much software already supports it outside of the Chromium-controlled browser market. They could probably get the JXL team AT Google Research to help out if they asked, because it really seems more like specifically the Chromium team that's blocking things and not Google as a whole.