JPEG XL image format

[Schweinepriester]

Description

Same as last year, see #176.

Specification

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

Open Issues

No response

Tests

https://tests.caniuse.com/jpegxl
https://wpt.fyi/results/jpegxl

Current Implementations

• Blink
• Gecko
• WebKit

Standards Positions

mozilla/standards-positions#522

Browser bug reports

No response

Developer discussions

No response

Polls & Surveys

No response

Existing Usage

No response

Workarounds

No response

Accessibility Impact

No response

Privacy Impact

No response

Other

https://caniuse.com/jpegxl

[jensimmons]

Rather than only providing a link to a previous proposal, please make the case here. This issue is what will be considered and discussed.

[Schweinepriester]

I fear I won't make a proper case by Oct 5, apologies!
Perhaps the original poster @BearCooder has the time?

To post at least something, here's my very subjective view, even without sources, sorry:
It would appear that JPEG XL is well suited to become what JPEG currently is, one of the default image formats if not the one, not only for the web, but also beyond. With plenty of features - progressive decoding perhaps being the most important one for the web - and seemingly no real drawbacks.

Therefore I would hope with it being part of Interop to encourage all browsers to support it.

[gianni-rosato]

JPEG-XL is, in my opinion, the best currently available path forward for a true JPEG successor. Many other great image codecs based on video compression technology - like AVIF & WebP - have shown promise and are effective at compressing image data well, but do not have the features to compete properly with a codec as versatile as JPEG-XL. I'll explain my thoughts below by enumerating the areas in which an image codec must excel to be successful, and why JXL does so.

Lossless Compression

JPEG-XL offers excellent lossless compression capabilities. While lossless WebP was an improvement over PNG for 8-bit lossless image encoding, JPEG-XL manages not only to outdo lossless WebP in encoding efficiency but also be more versatile for bit depths greater than 8-bit (a category PNG previously dominated). 16-bit lossless imagery, especially HDR images that are becoming more popular & rarely utilize 8-bit color depth, are where JPEG-XL shines, and it is the only codec to compete with PNG in that regard while providing better coding efficiency.

Example: JPEG-XL compresses this 16-bit AdobeRGB PNG better than PNG. Using: cjxl 16bit.png 16bit.jxl -d 0.0 -e 9 -I 100 -g 3 -E 11

16-bit PNG: 1533373 bytes.
16-bit JXL: 1211029 bytes.

Lossy Compression

JPEG-XL is equally adept at lossy compression, especially at quality levels that we as humans care about. It promises to be around 60% better than JPEG. While video-based codecs like AVIF can be competitive when given lots of CPU time, JPEG-XL is both fast and efficient for medium to high fidelity photographic imaging. I've done a number of tests myself, which focus on high resolution, high fidelity, high effort encoding and medium resolution, low effort encoding designed for speed.

Supported Bit Depth(s)

JPEG-XL supports up to 32 bits per channel of bit depth, making it future proof for the increasingly popular HDR photos coming out of smartphones. There is essentially zero downside to encoding high bit depth with JXL relative to the resulting encode's size. Considering many smartphones take HDR photos now, JXL can offer a pipeline for them to make their way to the Web in the future especially as companies like Adobe & Apple have already embraced the new codec.

Progressive Decode

JPEG-XL provides actual progressive decode support that you can experiment with here on a supported browser like Safari, Waterfox, Thorium, Mercury, or any browser on iOS.

Progressive decode is a feature only JPEG is able to offer a real implementation of, rendering low frequency transform coefficients before the rest of the image arrives to allow an image to display before the entire thing has been sent over the network. Blurhashes do not replace this technology, but rather compliment it, allowing another layer of progressive decode that can be used even before the image begins to load progressively. This is an important feature to improve the user experience on websites featuring large images, or on any website if your Internet connection isn't strong.

Lossless JPEG Re-compression

An incredibly unique JPEG-XL feature that no other codec can currently offer competition to is lossless JPEG re-compression, or the ability to take a JPEG input and provide an output with a smaller filesize (on average, 20% smaller) that is pixel-for-pixel identical. This is why companies like Meta have endorsed JPEG-XL, as it offers a path forward for the existing JPEGs on the Internet.

Industry Support

From the JPEG-XL Wikipedia page:

Besides Cloudinary and Google originally, throughout JPEG XL's preliminary implementation in web browsers, various representatives of well-known industry brand names have publicly voiced support for JPEG XL as their preferred choice, including Facebook, Adobe, Intel and the Video Electronics Standards Association, The Guardian, Flickr and SmugMug, Shopify, the Krita Foundation, and Serif Ltd.

Apple also features ecosystem-wide JPEG-XL support as of iOS 17 & macOS Sonoma.

Other Features

JPEG-XL has the potential to replace popular formats like TIFF for authoring workflows due to its broad feature set. From the JXL Wikipedia, some additional features include:

• Image dimensions of over a billion (2^30−1) pixels on each side.
• Up to 4099 channels, including support for alpha transparency
• There can be multiple frames with zero duration, allowing support for layers in graphics software
• Animation support, allowing JXL to rival GIF
• Images can be stored in tiles to reduce the time needed to decode them.
• Graceful quality degradation across a large range of bitrates means quality loss isn't as abrupt as with older formats.
• Perceptually optimized reference encoder which uses a perceptual color space, adaptive quantization, and conservative default settings.
• Support for wide color gamut and HDR
• Efficient encoding and decoding without requiring specialized hardware: JPEG XL is about as fast to encode and decode as old JPEG using libjpeg-turbo and an order of magnitude faster to encode and decode compared to HEIC with x265. It is also parallelizable.
• Royalty-free format with an open-source reference implementation available on GitHub.

I am excited for the future of JPEG-XL, and I would like to see it take over on the Web & beyond to compliment the existing set of available codecs as well as compete with the legacy JPEG to hopefully someday take its place.

Sources:

• JXL Wikipedia
• JPEGXL.info: Why JXL
• Apple JXL Announcement
• JPEG XL: How It Started, How It’s Going
• The Case for JPEG XL
• Time for Next-Gen Codecs to Dethrone JPEG

Thank you for considering JPEG-XL!

[jonasnordlund]

I would very much enjoy seeing this because JPEG XL is a rare opportunity to finally gain a modern catch-all dedicated image format not only on the web but deep into various industries as well, helping immensely with consistent data interchange and staff costs from data conversions. I think it cannot be underestimated just how big of a deal this is. Here's my take on the main advantages of JPEG XL over competitors and some professional use examples.

Of course, there is always a very real issue of "codec overhead" and expanding the surface area for security holes as seen with the recent WebP security issue CVE-2023-4863, but in this case I think the benefits far outweigh these disadvantages where JPEG XL is positioned to be a "format for the decades":

1. It supports progressive decoding which allow an end-user of the WWW to see the image much earlier than it has finished downloading. This is important particularly in low bandwidth scenarios. Modern, competing formats such as AVIF or HEIF do not support this. This has been considered a good idea in web formats for decades and is often lost in debates.
2. It supports superior lossless performance compared to both dedicated formats such as PNG as well as competing high-compression formats such as AVIF or HEIF. Additionally, JPEG XL supports layers, CMYK and 32-bit floating point samples that makes it a serious competitor to TIFF.
3. It offers improved compression performance compared to AVIF thanks to far better compression speed and better preserved fidelity at comparative compression ratios.
4. It is backwards compatible with JPEG in that these images can be losslessly recompressed with compression ratio gains into JPEG XL. This is a unique property of JPEG XL and indicative of its pragmatic roots.
5. It has rich metadata support, making it an excellent choice for experts in a wide range of fields.
6. libjxl is a standard, easily deployable decoder that helps with industry-scale adoption and support overhead, and helps maintain consistent rendering across platforms.

Concrete field use examples:

Geological engineering: Since JPEG XL supports height maps in metadata along with high detail (going as far as 32-bit lossless, yet still not sacrificing high compression ratios), this would make JPEG XL excellent containers for this use.

Medical industry: Since MRI scans, X-rays and CT scans produce a very large amount of data often also in a wide gamut, hospitals and clinics could have substantial storage cost improvements if adopting JPEG XL without compromising fidelity. The unified format regardless lossy or lossless use without a change of file formats could also assist in training and documentation.

Field work: Since JPEG XL supports progressive decoding as well as high compression, scenarios with limited bandwidth would benefit greatly, such as mobile inspections and reports of utility pole damage following harsh weather conditions where damage is photographed and uploaded, or past photography of e.g. electrical cable cabinets is revisted (downloaded) as references in the field at later dates as inspections are made.

Photography, journalism, publishing: Thanks to its high 32-bit fidelity and CMYK support, it is a natural sucessor to various camera RAW and TIFF formats.

Sources:

• The Case for JPEG XL
• Wide Color Gamut in the NDS Ecosystem

[jonsneyers]

Some more points:

• JPEG XL is the first format that really has the potential to replace both JPEG and PNG: existing JPEG and PNG files can be losslessly converted to JXL with guaranteed compression gains; in terms of functionality JXL is a superset of both — this is not the case with earlier formats like WebP or AVIF that might look like they can replace both JPEG and PNG, but don't fully reach that goal since they're lacking some features (e.g. progressive decode and lossy 4:4:4 for WebP, 16-bit precision for both WebP and AVIF).
• JPEG XL is an international standard (ISO/IEC 18181), i.e. the specification is owned/maintained by the international community, not by a single company or business alliance. It is also royalty-free.
• Good, fast, secure FOSS implementations are readily available (e.g. libjxl).
• JPEG XL was designed with the web in mind: minimal header overhead, streaming and even progressive decoding, etc.
• It's not a web-only format though: it is designed for a variety of use cases (including authoring workflows, printing, etc). Web delivery was the primary use case to design for, but by no means the only use case to consider. This means adoption across the workflow (including authoring tools, OS-level support, etc) is likely to happen, which also is a Good Thing for the web platform: having formats that also 'exist' outside the web is always nicer than having web-specific formats that require web-specific tooling.
• JPEG XL is fully ready for HDR and wide gamut, and is future proof in this regard (it has no real limitations on the color precision).
• In terms of compression performance for still images, it is currently the best codec available. No other codec can deliver the same quality per byte at the same encode speed.

[madmanchan]

I believe JPEG XL is the best currently available option for compressing still images, especially for photography.

Adobe Photoshop, Lightroom, and Camera Raw will soon officially import, edit, and export photos in the JPEG XL format. This includes both Standard Dynamic Range (SDR) and High Dynamic Range (HDR) photos. There are several reasons we've added JPEG XL support, most of which have been covered by other posts in this thread (quality, speed, high bit depth, integer and floating-point, lossy and lossles, ease of tuning, lossless transcode from JPEG). These are also the same reasons we've added JPEG XL as a codec option in version 1.7 of Digital Negative (DNG).

Our customers use web galleries for a wide variety of imaging workflows, including sharing portfolios, collaborative workspaces, and data review. JPEG XL's high quality and versatility makes it an ideal choice for supporting these workflows.

I think browser support and interop for JPEG XL should be a top priority.

Eric Chan, Fellow, Adobe

[zcorpan]

https://tests.caniuse.com/jpegxl

This appears to be a single test that checks for support, which seems insufficient for measuring interop. Is there a conformance testsuite? Are there any tests checking integration with web APIs (img, 2d canvas, images in CSS, etc.)?

[mo271]

https://tests.caniuse.com/jpegxl

This appears to be a single test that checks for support, which seems insufficient for measuring interop. Is there a conformance testsuite? Are there any tests checking integration with web APIs (img, 2d canvas, images in CSS, etc.)?

There is https://github.com/libjxl/conformance and https://github.com/libjxl/bench, which are indented at testing decoder implementations. When Chromium was able to decode JPEG XL images, we had an extensive set of test images and blink tests for them. See https://chromium-review.googlesource.com/c/chromium/src/+/4255409 for the types of tests and images, for example also integration tests with the img-tag.
I think the most important aspects of such tests would be to make sure the following works:
Alpha, high-bit-depth/HDR, animation.
Less important, but nice to have would be progressive loading.

With that it should be straightforward to come up with a good test measuring interop. I'd be happy to help writing such a test!

I think the most important aspects of such tests would be to make sure the following works:
Alpha, high-bit-depth/HDR, animation.
Less important, but nice to have would be progressive loading.

[eeeps]

@zcorpan are you aware of any other format-specific Web API test suites that could be used as guidance?

I just searched wpt.fyi for "JPEG" and "WebP" and turned up an incomplete handful of things.

If a test suite like this doesn't exist yet, I guess this could be an opportunity to put one together.

[zcorpan]

There isn't a lot of coverage for other image formats in wpt I think, but a few tests for PNG/APNG:

https://wpt.fyi/results/png?label=experimental&label=master&aligned
https://wpt.fyi/results/apng?label=experimental&label=master&aligned

A list of web APIs that fetch an image can be deduced from Fetch Metadata destination being "image" (but also "embed" and "object" and "document"). A doc by @jugglinmike from a few years ago listing those (for web-platform-tests/wpt#25247) is at https://docs.google.com/document/d/1zyV4RzHnP8xqyxH4yHiNanrIoj7tjNYqQtligAgoPN4/edit#heading=h.s32xcig69wzc

Each such API probably has some tests in wpt.

[jyrkialakuijala]

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. Mozilla's JPEG XL interface code has been developed in their org, but we can help there too if needed. Our experience on the interface code is that it is about 6-8 weeks of calendar time for us to build from scratch.

[daxpedda]

FWIW: jxl-oxide exists.

[jonsneyers]

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.

[Schweinepriester]

https://bugs.chromium.org/p/chromium/issues/detail?id=1451807#c35:

@ChromiumDevs: During this years biggest performance meetup, PerfNow, at the pre-conference meetup, there was a very convincing song live played, called "Give JXL a Chance": https://www.youtube.com/watch?v=VJaa1Le4W7c. Please listen to it and consider taking action accordingly 🙏

[goodusername123]

Here is a small list of a few websites hosting JPEG XL images for various testing purposes, Hope these are helpful in some form even if just for very casual checking of support between browsers.

• https://jpegxl.info/test-page/ (basic test suite)
• https://saklistudio.com/jxltests/ (alternative longer test suite)
• https://people.csail.mit.edu/ericchan/hdr/hdr-jxl.php (HDR photography)
• https://google.github.io/attention-center/ (progressive decoding)
• https://jpegxl.info/art/ (collection of images with tiny file-sizes made with features of the JPEG XL bitstream such as MA trees)

Warning some of the servers hosting these sites improperly send over .jxl files as application/octet-stream instead of image/jxl when attempting to access files directly.

[RafaelLinux]

For me, it's clear. With JXL, we even don't need PNG (used for transparency), WEBP (transparency and compression) or JPG. WebP lacks of progressive load and JXL beats all them in lossless compression.
I'm converting all my TIFF 16bits images to JXL lossless compression and recovering gigabytes of storage in my drive.

[wpt-interop]

Thank you for proposing JPEG XL image format for inclusion in Interop 2024.

We wanted to let you know that this proposal was not selected to be part of Interop this year.

We did not have consensus to include this proposal. This should not be taken as a comment on the technology as a whole

For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2024!

Posted on behalf of the Interop team.

[Tristan971]

Is there a documented summary of the selection process’ deliberations with regards to this proposal?

Pointing to a vague lack of « consensus » (amongst whom and what were the votes?) and the generic process design is… very light.

Especially when this is, and by very far, the most demanded proposal and you self-describe (first paragraph of your own readme) with:

prioritized by user and web developer needs

[madmoizo]

amongst whom and what were the votes?

From the proposal selection process:

The positions of individual member organizations are confidential to the Interop Team.

chooses up to 40 proposals to nominate for consideration in Round 3. They submit their nominations to the Interop Team, where their choices remain confidential

An objection may come with a brief explanation to explain its reason, but this is not required. These lists and the resulting point assignments remain confidential to the team.

The official position of vendors was and still is:
Safari: Shipped
Firefox: Neutral
Chrome: Not interested 🙉

Edit: I'm not part of the interop team, I just add the reasons why we won't have any information about the decision

[johnyb0y]

There's always next year!

[Tristan971]

There's always next year!

Not if all avenues keep cosplaying chromium’s bug tracker like this (with a sprinkle of opacity by design).

[RafaelLinux]

There's always next year!

This was the year, it's January 2024 yet, and Google is more interested in webP.

[Schweinepriester]

rest assured I will propose it again for the next interop (unless already proposed by the time I try)!

[oofdere]

We did not have consensus to include this proposal.

That's it? That's the response to what is, by several times, the most requested feature in Interop 2024?

No explanation for rejecting the feature that got 4.5x more support than the runner-up? Really?

This isn't even about JPEG-XL, though its rejection does make me sad.

This is about the Interop project, which claims to work "for the benefit of users and web developers" failing to be accountable to the users and web developers that engaged with the project.

As someone who loves Interop and has been following its progress, the handling of this is extremely disappointing, and I know I'm not alone in that opinion. I really want to see Interop reach its fullest potential! I don't want people losing faith in something as cool as Interop! So please, be transparent and listen to the community!

Much love to everyone involved in the proposal and the project regardless <3

Hoping for a better structure next year, for the sake of Interop!

[RafaelLinux]

I fully understand your frustration. I came to this thread thinking that, as this proposal is so high in the rankings, it would be a priority for development, but I have been totally disappointed. It seems that - as has been the case for a decade in the KDE bug forum - "priorities" are relative because of unknown interests. These facts finally make you wonder why such a large group of users bother to participate in forums where you finally get the feeling that our (bug) reports, requests (as in this case) or suggestions are ignored? This is not pessimism or negativity, it is a verifiable reality. Curiously, this is more so in large projects than in small ones. It seems that in large projects, commitments or wills are diluted and nobody commits to resolving the issues.

[jonasnordlund]

An image format replacing JPEG, TIFF, PNG, HEIF, AVIF due to complete coverage of lossy, lossless, progressive and it can't be agreed on that it's obviously moving interop forward of all things. I really lost confidence in this organization's purpose now. Is this just pushing already agreed upon agendas from browser vendors with extra steps? I fail to understand why a community is involved if third parties have decisive powers - why not arrange regular meetings only with browser vendors.

[xangelix]

Situations like this, with JXL, were the exact situations I thought Interop was good for--stopping some singular rogue manager at a company from preventing all of the web from moving on. But instead this was just another development thread Google single-handedly stopped out of nothing but ego? This is incredibly disappointing.

[conradsrc]

If a proposal is denied due to the same "rationale" of "lack of consensus" with 1) very obvious and well-articulated advantages over existing formats, 2) wide industry support from Adobe to Facebook to Apple to evidently now Microsoft, and 3) FAR and away the most support from the community (more than 5 times as many votes as the second most popular issue this time around) then I really fail to see what the point of this public-facing repo even is. @jonasnordlund is right, why even bother pretending if the Chromium team can just veto it and none of their reasoning is even made public so that it can face any scrutiny?

This whole process just seems like a farce now. Especially considering that this very issue has proof that other parts of Google are actively developing for JXL. Not to mention that the original Chromium issues for flagging JXL for removal and the actual removal itself are authored and/or reviewed and approved by one of the 3 co-authors of WebP and the primary maintainer of libwebp.

Feels like an incredibly small group of people at Google abusing their position as maintainers of the browser engine with de facto control over web standards. Interop just gave everyone else another place to impotently scream their opinions into a pillow before giving a response as vague and suspect as Chromium's original "There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL" comment that set off everyone else in the industry. With recent moves from Microsoft looking to add JXL support to WIC, it seems we're fast approaching a state of "everyone who works with 2D raster images supports JXL except Google and, by abuse of their market position, the internet".

[jthoward64]

What exactly is the point of the interop project if it can't move the web forward? Just about every single thing on the list for this year is something browsers were already working on. Not even any info on what stage JXL was dropped is just insulting to the community that is pushing for it, those who developed it initially, and every group other than Google that is working on implementing it. I had hoped that Mozilla would so much as mention it, but clearly they are uninterested in anything beyond being almost Chrome. I have the utmost respect for those who work on the browsers we use every day, and a decision not to implement a feature is fine, albeit disappointing, but radio silence on why is simply disappointing.

[castarco]

@jthoward64 I'm also quite sad about this outcome, but regarding what you said about innovation:

I'd say that an interop group is (in essence) a sort of standardisation body, and standardisation always arrives "after the fact".

Its purpose is not to innovate or push for innovation, but to "solidify" the innovation that already took place, so we can start focusing on other problems (therefore releasing resources to innovate on other problem spaces), and also so we have good enough documentation about the thing that was "standardised".

Having said that, I also think that this decision was self-serving, and not technically motivated.

[BearCooder]

Hopefully Chrome reconsiders. Its not that just a couple people on github are demanding it. Its beeing talked a lot on socials too: https://twitter.com/t3dotgg/status/1754689598234722756

[Chealer]

Thank you for proposing JPEG XL image format for inclusion in Interop 2024.

We wanted to let you know that this proposal was not selected to be part of Interop this year.

We did not have consensus to include this proposal. This should not be taken as a comment on the technology as a whole

For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2024!

Posted on behalf of the Interop team.

Thank you for clarifying how this would have been "completed". Note that this is not a proposal for inclusion in Interop 2024. This is a request for inclusion in Interop, period.

[antermin]

@jyrkialakuijala

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.

Now that Mozilla's latest position is:

A safe, fast, and battle-tested Rust decoder from the original team could make that scenario much less likely, and so we’re using our leverage to encourage progress on this front.

A memory-safe decoder would reduce these costs considerably, and we are open to shipping one that meets our requirements.

(mozilla/standards-positions#1064)

Can we expect to see a Rust decoder from libjxl developers soon? If so, is there any ETA?

[jensimmons]

Note that this is not a proposal for inclusion in Interop 2024. This is a request for inclusion in Interop, period.

This issue submitted the idea to be considered for Interop 2024.

If folks want JPEG XL to be considered for Interop 2025, please be sure to submit a new proposal once the call for proposals has opened. This thread won't automatically be forwarded for consideration in the new year. You can link to this issue, calling out the passionate support, but a new proposal will be needed for Interop 2025.

[Chealer]

Note that this is not a proposal for inclusion in Interop 2024. This is a request for inclusion in Interop, period.

This issue submitted the idea to be considered for Interop 2024.

If folks want JPEG XL to be considered for Interop 2025, please be sure to submit a new proposal once the call for proposals has opened. This thread won't automatically be forwarded for consideration in the new year. You can link to this issue, calling out the passionate support, but a new proposal will be needed for Interop 2025.

This is not a proposal per se, but an issue report. Reports are not filed against each affected version, only 1 is needed. Implicitly, this is a request to solve the issue as soon as possible.

@Schweinepriester : It may clarify to title your ticket as an issue report (something like "No coverage of JPEG XL image format").

[jensimmons]

This is not a proposal per se, but an issue report. Reports are not filed against each affected version, only 1 is needed. Implicitly, this is a request to solve the issue as soon as possible.

This GitHub repo is not a general space for making requests of web browsers. If you want to make a request that Chrome, Edge or Firefox implement JPEG XL, I suggest going to each of the places where such requests are made.

This is a working space for the WPT Interop Project. This issue was opened as a proposal for a focus area to be included in Interop 2024.

After much debate and consideration of the 101 proposals received a year ago, Interop 2024 was defined to be a specific set of 17 focus areas. You can see them listed on the Interop 2024 dashboard. Interop 2024 is actively in progress. It will end at the end of 2024.

Soon, Interop 2025 will open a call for proposals. If you would like JPEG XL to be considered for Interop 2025, someone will need to create a new proposal. Simply declaring to the universe that you believe all the proposals that did not make it into Interop 2024 will be considered for Interop 2025 will not make that true. Proposals from 2021, 2022, 2023, and 2024 are not automatically considered a second time. Only proposals submitted during the Interop 2025 call for proposals, according to the Interop 2025 process will be considered.

In fact, the first two lines of this issue say:

Description
Same as last year, see #176.

That's because this proposal was a new one submitted for Interop 2024. There was a previous proposal submitted for Interop 2023.

It may clarify to title your ticket as an issue report (something like "No coverage of JPEG XL image format").

Doing so will not change what this is. This is an old proposal from the process last year. Which is now over. Much like applying for a scholarship, or a research grant, or an even applying to university — you have to submit a new application each year if you want to be considered each year.

[Chealer]

This is not a proposal per se, but an issue report. Reports are not filed against each affected version, only 1 is needed. Implicitly, this is a request to solve the issue as soon as possible.

This GitHub repo is not a general space for making requests of web browsers. If you want to make a request that Chrome, Edge or Firefox implement JPEG XL, I suggest going to each of the places where such requests are made.

This is not a "request of web browsers"[sic]. The Interop Project analyses weaknesses in WPT and ensures that its members are not too opposed to extending the metrics. For example, before JPEG XL support is tested, Interop would check if Google is opposed.

This is a working space for the WPT Interop Project. This issue was opened as a proposal for a focus area to be included in Interop 2024.

Issues are not "opened", they just exist. This ticket tracks the lack of a consensual plan for WPT to measure JPEG XL support.

After much debate and consideration of the 101 proposals received a year ago, Interop 2024 was defined to be a specific set of 17 focus areas. You can see them listed on the Interop 2024 dashboard. Interop 2024 is actively in progress. It will end at the end of 2024.

Soon, Interop 2025 will open a call for proposals. If you would like JPEG XL to be considered for Interop 2025, someone will need to create a new proposal. Simply declaring to the universe that you believe all the proposals that did not make it into Interop 2024 will be considered for Interop 2025 will not make that true. Proposals from 2021, 2022, 2023, and 2024 are not automatically considered a second time. Only proposals submitted during the Interop 2025 call for proposals, according to the Interop 2025 process will be considered.

You are the only one talking about proposals or Interop 2025, and I fail to see declarations to the universe here. What I do see is a question asking how this would have been "completed", which unfortunately remains unanswered.

In fact, the first two lines of this issue say:

Description
Same as last year, see #176.

That's because this proposal was a new one submitted for Interop 2024. There was a previous proposal submitted for Interop 2023.

You can read the whole descriptions, but in none will you find them described as proposals. This ticket is in an issue tracker. The database's entries are issue reports. Correspondingly, neither #176 nor this ticket said anything about 2023 or 2024.

[...] This is an old proposal from the process last year. Which is now over. Much like applying for a scholarship, or a research grant, or an even applying to university — you have to submit a new application each year if you want to be considered each year.

Neither the reporter nor anyone else asked to be considered here. As previously indicated, this is not a proposal. The Interop Project may opt to restart its evaluations from scratch every year or every month if it wishes, and letting the ITS know about failure to progress is fine, but governance internals must not complicate issue tracking.

[jensimmons]

@Chealer You might want to go look up who I am, and how deeply I've been involved with both getting JPEG XL on the web and in Interop 2022/23/24, before you so confidently declare me wrong. Don't let my gender confuse you.

I'm providing advice on how to succeed. A well-written proposal for Interop 2025 that makes a clear & helpful case (free from toxicity) and stands on its own (separate from previous proposals) is the best path forward.

[conradsrc]

@jensimmons I can do a new/updated proposal to submit once 2025 opens (if there are no objections). Reference the updated Firefox/Mozilla standards position, the Mozilla Connect submission for JXL support in Firefox, the issue on the Chromium tracker, etc. Or if anyone else beats me to it, hopefully they can flesh it out more and keep it civil.

[Chealer]

Hi @jensimmons,

@Chealer You might want to go look up who I am, and how deeply I've been involved with both getting JPEG XL on the web and in Interop 2022/23/24, before you so confidently declare me wrong. Don't let my gender confuse you.

I'm glad to read that , but if you think you were unduly "declared wrong", I suggest you explain where before bringing attention to your gender or history.

I'm providing advice on how to succeed.

Thanks anyway, but repeating the same work every year is not a great recipe for success, and nobody asked for such advice nor to drive people away. What was asked is to clarify how this would have been "completed".

A well-written proposal for Interop 2025 that makes a clear & helpful case (free from toxicity) and stands on its own (separate from previous proposals) is the best path forward.

This project is open. If you're willing to take part in such a proposal, feel free.

[jthoward64]

Can a mod just mark this exchange as off topic please?

[Tristan971]

@Chealer Stop already.

We all want JXL, but your being condescending and rude about it (especially to Jen Simmons from Webkit which has JXL support) is exceptionally annoying, and also makes the entire issue and all of us look bad by association.

[jgraham]

I'm going to lock this discussion now. As Jen said, any further discussion should be in the context of a proposal for Interop 2025 once the proposal period opens on the 17th.