JPEG XL image format

[Schweinepriester]

Description

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

Specification

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

Additional Signals

• https://caniuse.com/jpegxl
• Supported by Safari
• Firefox
  • JPEG XL mozilla/standards-positions#522
  • with recent addition Firefox will consider a Rust implementation of JPEG-XL mozilla/standards-positions#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

[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.