This format appears to be very new, and it doesn't look like there's wide support for it yet. It would be helpful to know the following:

1. Minimum ImageMagick version required
2. Does a Debian package exist for the reference library?
3. Are there alternative libraries?
4. What browsers, if any, support or plan to support this format?
5. Does common image generation and editing software support or plan to support this format?

1. Per https://github.com/ImageMagick/ImageMagick/commits/main/coders/jxl.c , first commit that introduces JPEG XL is on 2019-10-05 (release 7.0.8-68). The reference library is used from 2020-12-27 (release 7.0.10-54).
2. No Debian package in the repository yet, although sources are available on https://gitlab.com/wg1/jpeg-xl/-/tree/master/debian
3. ?
4. Google Chrome ships with experimental support at least on Windows/Linux/Mac/Android. Firefox is working on it.
5. GIMP plugin is already available with the reference library: https://gitlab.com/wg1/jpeg-xl/-/tree/master/plugins

I have very much been looking forward to JPEG XL support on Wikimedia Commons.
Currently the only way to publish wide gamut pictures (>8bits) is PNG (lossless completely inappropriate for natural content) or TIFF (also lossless and cannot be displayed in-browser), so in most cases I publish as sRGB JPEG and lose all the extra color information that current cameras capture.

all the extra color information that current cameras capture.

What about AVIF? What about ICC profiles?

In T270855#7055698, @VZpolodov wrote:

all the extra color information that current cameras capture.

What about AVIF? What about ICC profiles?

Whatever free modern format gets implemented is fine with me, so long as we finally get one. ICC profiles are everywhere but it doesn't help when JPEG has only 8-bit color depth; using a wider ICC profile with small bit depth results in more color banding.

Just FYI: 14 days ago ImageMagick already fixed JXL integration since in 0.5 version JXL now requires setting color space info. JXL can preserve JPEGs losslessly! https://github.com/ImageMagick/ImageMagick/pull/4064

As for AVIF, the biggest problem is that it does not yet have center chroma siting for 4:2:0 used in JPEG. At all. https://github.com/AOMediaCodec/av1-avif/issues/88

Also, please remember that AVIF needs nclx atom to be set correctly: for sRGB to transfer sRGB, primaries BT.709 and matrix that is in JPEG is full range BT.601. Very important.

Appreciate the heads-up, but I am pretty sure the very relevant follow-up would be: which version is Debian stale on? The hesitancy of the team to even backport testing/unstable source packages has been a persistent roadblock to us getting good things.

Debian 12 has libjxl 0.7 integrated into its repositories.

And Apple has recently announced support for the format in Safari 17, since the last time this issue has been commented on: Google has dropped support for jpeg xl in Chrome, Firefox's implementation is still not ready.

In T270855#8921612, @nathanielcwm wrote:

Debian 12 has libjxl 0.7 integrated into its repositories.

And Apple has recently announced support for the format in Safari 17, since the last time this issue has been commented on: Google has dropped support for jpeg xl in Chrome, Firefox's implementation is still not ready.

WMFs thumbnailing system, Thumbor, is on Version 10, Buster. There is an team working on getting to Version 11, Bullseye, but not version 12. For version 12 Thumbor needs an permanent maintainer, not just a working group like currently. This is blocked on T294484.

And as described in the https://www.mediawiki.org/wiki/Manual:Adding_support_for_new_filetypes you also need file format detection and a media handler. Thumbnailing via thumbor/imagemagick alone is not enough.

In T270855#11480101, @Adpocalyptic wrote:

Now that Adobe are integrating support for the format into their products services & the PDF Association have announced that support for JPG-XL will be integrated as part of their specs, And support in browsers such as Safari - with Mozilla Firefox & Chromium/Chrome reps recently expressing interest in following suit with rust-based implementations as they start reopening the filed issues regarding integrating support on their platforms, that were previously closed with a neutral stance and a Wont Fix-style state.
Alongside multiple mainstream operating systems (Linux Distros, macOS/iOS, MS Windows etc) integrating support. And apps, extensions, addons/plugins being available to work with the format already

...Is it now appropriate to discuss whether it might be worth it to start preparing for ".jxl" getting added as a valid option in terms of file formats that are openly accepted for processing/hosting? There is still support for (optional) progressive loading aswell as backwards compatibility & fallback options (Displays a standard JPG thumbnail if a user is unable to access the .jxl preview version for whatever reason)

And while people might not agree that the status of this should be bumped up to 'in-progress', I still hope that the status is kept open while reviewing the change in circumstances, like the ones I have listed that have occurred in the time since this proposals initial consideration.

I think the best thing you can do to push this forward is have a discussion on commons to gain consensus to accept this file format. Nobody will want to do the work before knowing if commons will want the result. Having a clear discussion establishing that if we make it, commons will use it, will make people more likely to work on this.

Change #1235043 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/core@master] MimeAnalyzer: Add support for JPEG XL

https://gerrit.wikimedia.org/r/1235043

In T270855#11480287, @Bawolff wrote:

In T270855#11480101, @Adpocalyptic wrote:

Now that Adobe are integrating support for the format into their products services & the PDF Association have announced that support for JPG-XL will be integrated as part of their specs, And support in browsers such as Safari - with Mozilla Firefox & Chromium/Chrome reps recently expressing interest in following suit with rust-based implementations as they start reopening the filed issues regarding integrating support on their platforms, that were previously closed with a neutral stance and a Wont Fix-style state.
Alongside multiple mainstream operating systems (Linux Distros, macOS/iOS, MS Windows etc) integrating support. And apps, extensions, addons/plugins being available to work with the format already

...Is it now appropriate to discuss whether it might be worth it to start preparing for ".jxl" getting added as a valid option in terms of file formats that are openly accepted for processing/hosting? There is still support for (optional) progressive loading aswell as backwards compatibility & fallback options (Displays a standard JPG thumbnail if a user is unable to access the .jxl preview version for whatever reason)

And while people might not agree that the status of this should be bumped up to 'in-progress', I still hope that the status is kept open while reviewing the change in circumstances, like the ones I have listed that have occurred in the time since this proposals initial consideration.

I think the best thing you can do to push this forward is have a discussion on commons to gain consensus to accept this file format. Nobody will want to do the work before knowing if commons will want the result. Having a clear discussion establishing that if we make it, commons will use it, will make people more likely to work on this.

Is there a specific page you can link to where I might be able to try testing consensus on a proposed 'main format' like this? Or atleast make the case/pitch the idea of everything being on JXL by default or converted into it.

There doesn't even seem to be one specific place where I can just edit in a section to discuss 'Would you guys agree with a proposal saying "JPG-XL should be added in as an officially supported format" for XYZ reasons?' that I can see atleast 😅 Many apologies in-advance if this is sidetracking, just thought I should ask while still on the topic

Change #1235043 merged by jenkins-bot:

[mediawiki/core@master] MimeAnalyzer: Add support for JPEG XL

https://gerrit.wikimedia.org/r/1235043

In T270855#11572020, @Adpocalyptic wrote:

Is there a specific page you can link to where I might be able to try testing consensus on a proposed 'main format' like this? Or atleast make the case/pitch the idea of everything being on JXL by default or converted into it.

I want to make a distinction here between INGESTION, (what this ticket is mostly about). And serving up jpegxl as a thumbnail format for itself, or for other file format. There is no ticket for this latter situation, because it wouldn't be desirable for a long time to come, as we tend to support up to 10 year old browsers/devices. For that reason we only use png and jpeg, with webp conditionally being served up for highly used images. This is not likely to change any time soon, as MORE formats simply causes less efficiency..

There doesn't even seem to be one specific place where I can just edit in a section to discuss 'Would you guys agree with a proposal saying "JPG-XL should be added in as an officially supported format" for XYZ reasons?' that I can see atleast 😅 Many apologies in-advance if this is sidetracking, just thought I should ask while still on the topic

When people say community support, they will mostly mean support from our image uploaders, generally centered around the Wikimedia Commons community. These discussion are generally held here: https://commons.wikimedia.org/wiki/Commons:Village_pump

These discussions cannot decide things, but they are needed to show that our communities will actually be using this. Without demand, prioritization is even less likely.

I've looked into jpeg xl a bit. First of all it is not supported by getID3. So we either need to make an implementation inside getID3 or we have to create our own parser.

It's also actually two formats. mostly raw bitstream jpegxl but also an optional ISO Base media format wrapping for adding additional metadata. This makes supporting it quite a bit harder actually.
The iso bmff aspect is interesting as it is also used by AVIF/HEIF and MP4. I've been thinking that it might be possible to move part of TimedMediaHandler's MP4 parser into a MediaWiki core library to facility all of these formats.

Overall the interpretation of jpeg xl is doable, but not trivial (as opposed to when it would have support in getID3)

If i recall jxl uses the same metadata as c2pa in jpeg which there is some interest in as well.

@bvibber do you have thoughts on moving part of TMHs iso parsing into core as a lib to build jpeg xl on vs implementing jpegxl support in id3 ??