JPEG XL image format

[Schweinepriester]

Description

Same as last year, see https://github.com/web-platform-tests/interop/issues/430 and the year before https://github.com/web-platform-tests/interop/issues/176.

Specification

https://jpeg.org/jpegxl/documentation.html; ISO/IEC 18181

Additional Signals

• https://caniuse.com/jpegxl
• Supported by Safari
• Firefox
  • https://github.com/mozilla/standards-positions/issues/522
  • with recent addition https://github.com/mozilla/standards-positions/pull/1064
• Chrome: https://chromestatus.com/feature/5188299478007808
• WPT Tests: https://wpt.fyi/results/jpegxl

[Mouvedia]

see also https://issues.chromium.org/issues/40168998 and https://connect.mozilla.org/t5/ideas/support-jpeg-xl/idi-p/18433

[conradsrc]

Here's a different, related Chromium ticket with a lot of activity about reopening the JXL issue.

I'll also copy a comment I recently left there that summarizes some recent coordination between the JPEG-XL team at Google Research, the Firefox team at Mozilla, and the jxl-oxide maintainer.

Adding onto the recent news that Mozilla is considering a Rust implementation of JPEG-XL, here's a comment from someone on the Google Research JPEG-XL team from last October's Interop discussion where they confirm that they could make a high-quality Rust decoder within several months, as well as the fact that they've already made the Chromium interfacing code for the C++ reference implementation.

If having a high quality Rust decoder implementation would arise as the only gating factor for choosing JPEG XL into interop 2024, the JPEG XL developer team in Google Research can deliver such by the end of Q2 2024. We have been successfully developing and maintaining Brotli and WOFF2 codecs for almost 10 years and would be able to do this too, safely and professionally, as well as supporting for the HDR needs there (such as ultra HDR, PQ, HLG and others).

We can also create the interfacing code for the browsers, including Chrome, Edge and Mozilla. We already have a version of C++ JPEG XL reference implementation interface code for Chrome and Edge ready for deployment, and could do the same for the possible Rust version.

Here's a follow-up comment 3 weeks later from Jon Sneyers, the JPEG-XL lead. Jon confirms the already-existing jxl-oxide Rust decoder fully confirms to the spec and passes all conformance tests:

We have tested conformance of the jxl-oxide decoder (which is implemented in Rust) and it is a fully conforming alternative implementation of JPEG XL. It correctly decodes all conformance test bitstreams and passes the conformance thresholds described in ISO/IEC 18181-3.

Three days ago, the owner of jxl-oxide confirmed they were coordinating with the core JPEG-XL devs to figure out how to potentially incorporate his project/efforts:

I'm in contact with some of the core devs in the JPEG XL community Discord server, and whether to use jxl-oxide as a base for the support in Firefox is yet to be decided (more work is needed, especially to match performance requirements, at least).

Meanwhile, Apple has continued to develop its JXL support on their product lines. Earlier today, Apple confirmed iPhone 16 Pros will be able to use JPEG-XL compression for ProRAW photos:

Apple and its various software iterations have supported JPEG XL for at least a year, including in Finder, Preview, Final Cut Pro, Pages, Photos, Mail, Safari, and more. Adobe has also supported the format for a while, including in Adobe Camera Raw and Lightroom Classic.

As for why it is including JPEG XL in the iPhone 16 Pro, Apple tells PetaPixel that the format promises two primary benefits over standard JPEG format: improved image quality and better compression performance. If there’s a 32MB JPEG image, that same photo will be 24MB in lossless JPEG XL and, even more impressively, about five megabytes in perceptually lossless format.

Apple has wrapped JPEG XL photos inside a DNG container, enabling ProRAW files to retain their flexibility while being significantly smaller — up to nearly five times smaller.

[hachahbar]

This year we must demand an explanation if the proposition is turned down again. No more backroom shenanigans.

[gordonfreeman01]

This year we must demand an explanation if the proposition is turned down again. No more backroom shenanigans.

Agreed, unless there's a valid explanation for this format not being accepted through this platform (which is unlikely), its rejection after clearing due process is wholly unacceptable.

[andrews05]

As much as I would love to see Chrome forced to implement JPEG XL, I'm afraid these comments making "demands" are based on a misunderstanding of who and what Interop is. The Interop team is based on voluntary participation from the browser makers and has no authority to force anyone to do anything. If the Interop team approves a proposal that a browser maker has no intention of implementing, then it still won't be implemented and the process serves no purpose.

See the Team Charter for more info. A key quote:

The team makes decisions based on consensus. A decision has consensus if it has support from at least two participating organizations and no opposition.

Basically, if Chrome opposes JPEG XL then it won't be approved, period.

[hachahbar]

How do we know that Chrome blocks the adoption of JPEG XL within Interop? We don't know for sure who blocks it because the whole thing is opaque for us plebeians, so you can only assume. This is what I am talking about. We need transparency, if the chrome team blocks JXL, it needs to be known. The more a company abuses its position the more likely for it to be considered a monopoly and broken up. Last month, Google's search engine was found to be an illegal monopoly and the judge is considering forcing Google to spin off the Chrome browser. Another anti-trust lawsuit will look into Google's ad business this month. Hopefully this will knock some sense into them.

[Patronics]

Description

Same as last year, see #430 and the year before #176.

Given some comments last year suggested including the description in that comment thread, rather than just linking to a previous discussion, perhaps someone should do the same this year, ensuring there's a clear explanation of what JPEG-XL is and why it matters, allowing this proposal to stand on its own?

As a start I'll note that JPEG-XL's interop proposal for 2024 received far more community support than any other proposals, with nearly 700 "👍" reactions on the proposal's first message. Combined with the over 200 "👍" reactions from this year's proposal, accumulated over just the last 3 days, it's clear that the developer community is very interested in this proposal.

[BearCooder]

During last years biggest performance meetup, PerfNow, at the pre-conference meetup, there was a very convincing song live played. Give JXL a Chance - https://www.youtube.com/watch?v=VJaa1Le4W7c

Also unrelated to the song I think this sums it up pretty good:

[jyrkialakuijala]

Dear JPEG XL and Interop communities, let's focus on the future of JPEG XL in Interop 2025. I have two suggestions to help move forward:

1. Focus on solutions, not blame: The Interop team works hard within their process. Let's not dwell on last year's decision.
2. Provide context for newcomers: Copy relevant information from last year's discussions and other sources for those unfamiliar with the issue. Describe JPEG XL benefits broadly, especially those functions that are not covered by existing modern solutions. Feel free to reuse my old positions.

Since the reason for excluding JPEG XL in Interop 2024 is "We did not have consensus to include this proposal." and not a more precisely communicated specific issue, we need a general overview of the format, its benefits and its current positioning and future plans in browsers and other digital platforms (including the slight adjustment in Mozilla's position) rather than to address a specific technical issue.

There might be a connection to the Rust decoder issue we discussed last year. To address this, and Mozilla's recently adjusted position on JPEG XL, volunteers and the JPEG XL developers at Google are working on jxl-rs, a new Rust-based decoder.

Key Points:

• We want to be constructive in moving forward with JPEG XL for Interop 2025.
• Broad and detailed background information will be helpful for those new to the discussion.
• A new Rust decoder is under development by the JPEG XL team at Google, which could be relevant to Interop 2025.

[mtom55]

To the JPEG XL community:

One of the key issues that affect JPEG XLs inclusion is the lack of transparency in the Interop process. We (Open Web Advocacy) believe that we should require this transparency.

We are pushing for transparency via this issue Interop Lack of Transparency & Accountability

[o-t-w]

Firefox’s reservations sound entirely reasonable. I don’t see any point in making JPEG XL part of Interop until the new Rust decoder is proven to be a success. https://github.com/mozilla/standards-positions/pull/1064

[jacob-willden]

As far as Rust decoders for JPEG-XL go, there's not only jxl-rs, but also jxl-oxide. I'm not sure which one is more complete at this point, but it appears that either could be used in the future by Mozilla to support JPEG-XL.

[conradsrc]

DICOM, or Digital Imaging and Communications in Medicine is a worldwide standard for the storage and transfer of medical imaging data, with "a near universal level of acceptance among medical imaging equipment vendors and healthcare IT organizations". They just updated their standard to adopt JPEG-XL as a payload codec.

Here are some slides covering the decision. Some snippets:

• Ability to forward migrate into JPEG XL without any loss of fidelity with existing JPEG, as a safe migration option with full backwards compatibility
• As DICOMweb response is multiframe at much higher quality than gif
• As lossless web response, is much smaller than PNG and easier to decode
• Works well for both natural and synthetic images
• No visual difference from what is seen, with 50-60% smaller
• Profiling results show that JPEG XL is fast enough for decoding/encoding, but is not as fast as JPEG
• WSI scanner vendors are interested in trying to generate JPEG XL directly
• Reduction in artifacts is important for algorithms processing, and is better with JPEG XL
• Streaming of data to both algorithms and viewers is important and better with JPEG XL
• Can render portions of a tile that are important first (progressive)
• May well be able to reduce quality to reduce size further without reducing machine or user quality as JPEG XL has lots of options with very few artifacts
• JPEG XL is a logical extension to baseline JPEG, especially if easily supported in browsers.

They of course mention that incomplete web browser support is a downside but have gone ahead anyway. And based on what we've heard from Mozilla recently (detailed above), there's a fair chance that the "incomplete" support will be "most Chromium-based browsers" in the near future.

Also of note from the standard:

A JPEG Baseline image losslessly re-coded to JPEG XL is not a derived image unless the original JPEG image was a derived image.

Here's an IEEE proposal from a conference in June 2023 that was advocating for DICOM to adopt JXL's lossless compression as "a universal replacement for medical file size reduction."

[tif-calin]

Mozilla's concern is stated clearly

the increased attack surface of the reference decoder (currently behind a pref in Firefox Nightly), which weighs in at more than 100,000 lines of multithreaded C++

Chrome's position is also often misrepresented/reduced to just "not enough interest" (blatantly false ofc), but also

The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default

I think Mozilla's position is entirely reasonable. They are working with Google to develop a rust-based decoder that could resolve their concerns. I don't think it's fair to push them when they're actively looking into a solution that addresses their concerns

Chrome's position needs further elaboration and could probably be argued against.

[Best-HeyGman]

This issue is even more important than people commonly think. There will be a successor to JPEG, but JPEG-XL is the only candidate that allows a lossless transcoding from JPEG to JPEG-XL with a ~20% size reduction (according to my own tests).

Images on the web have already degraded due to generation loss from recompression. With WEBP, AVIF or HEIC you don't have any other choice than to recompress again with a loss, if you want to get any size reduction when switching to these formats.

I do think we owe it to the people that come after us to choose the successor to JPEG wisely and to consider the impact that our choice has on the preservation of images that already exist right now. It would be a shame to see them reduced to a porridge of pixels by the time they would be used to teach history lessons.

[AngelaDMerkel]

Images on the web have already degraded due to generation loss from recompression. With WEBP, AVIF or HEIC you don't have any other choice than to recompress again with a loss, if you want to get any size reduction when switching to these formats.

One of the advantages of JXL is that even in JXL to JXL recompression, the standard is designed to limit generation loss as we see in the JPEG to JPEG recompression. This is a huge advantage in some kinds of web communities