The codestream definition might indeed be frozen so you can decode it in the future, but people looking at this as a serious format alternative for their content need more features than this. There is more to photos than just pixels. For example, the libjxl API is still missing a way to store Exif/XMP metadata in your files (although this is coming very soon).
1 Like
there’s something
Since version 12.23, ExifTool supports reading JPEG XL metadata. ExifTool shows you the file size, image width, image height, image dimensions and number of Megapixels.
According to https://github.com/w3c/csswg-drafts/issues/4929#issuecomment-718849793: “If the optional Exif (or XMP) metadata says something that conflicts with what the codestream says, then a decoder has to ignore the Exif/XMP”
And
In practice, once the process reaches the FDIS stage, the spec is “frozen” and you can use JPEG XL for real.
Again, all of that falls just a bit short for now - metadata is not juts image dimensions and orientation… 
But as I said, it’s coming, we’ll just have to be patient - IMHO the next libjxl 0.7 will be the first version that’ll offer metadata writing and be worth considering for more serious work.
Age may not be on everyone’s side, but patience is a virtue — wait until at least 2023.
Oh very good point.
For me storing scans and other in between files, it’s all just about the pixels so I don’t notice this stuff.
There are commits in gitlab about storing exif blocks in October. So indeed , something is coming but it’s very recent.
"download up-to-date versions of the cjxl.exe encoder (Binaries "
This is version 0.7
On https://twitter.com/jonsneyers/status/1439488459362775042
I found information from one of the fathers of the format:
Jon Sneyers @jonsneyers
Jpg => cjxl -q 80 preserves metadata fine, but djxl wrote it to jpg incorrectly (will be fixed soon)
See also: https://github.com/libjxl/libjxl/pull/544#event-5645934507
I decided to convince myself of the correctness of the Metadata behaviour in the jxl file
To do this, I downloaded the file Loch Faskally, autumn colours
and I converted it first into: Convert to JPEG XL (JXL) Online | Compress Images | MConverter
result - all data stored
So to make sure, I converted this file in my computer and the result is identical. The EXIF metadata after conversion to jxl is preserved as long as the image file has it.
9.5 Exif box
The type of this box shall be given by the 4 bytes 0x45 0x78 0x69 0x66 (“Exif” in ASCII).
6 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC FDIS 18181-2:2021(E)
Figure 6 shows the contents of an Exif box, excluding the box header.
Figure 6 — Content of an Exif box
[6] [7]
The Exif payload is as described in JEITA CP-3451E or CP-3461B . The tiff header offset denotes, as
specified in JEITA CP-3451B, the number of bytes, counting from the first byte of Exif_payload to the
first byte of the TIFF header of the Exif metadata. The value is zero if the payload starts immediately
with the TIFF header.
NOTE 1 The content of this box is exactly ExifDataBlock as defined in ISO/IEC 23008-12:2017, A.2.
For any Exif fields that have equivalents within the codestream, a decoder shall consider the codestream
to take precedence. Encoders are encouraged to ensure the Exif and codestream fields are identical.
NOTE 2 Examples of such fields include orientation and pixe……
The official gitlab source repo lists changes and most releases there get a changelog of some sort.
On encore.su one or more of the people involved are quite involved and active on the forum.
I try not to download binaries from unknown sources. Version 0.7 is not yet released on github or gitlab.
Yes, I was already aware cjxl has a custom workaround for this for JPEGs only, and I am very much aware of the features listed in the specification, as I mentioned above.
All this time I’m talking about general support in the libjxl library that SW developers need to pick up and start using in 3rd party applications so this format gets wider adoption.
Since you like link sharing so much, here’s a couple more comments from the same person:
As of this moment, we’re not there yet, but will be soon.
·
The JPEG XL standard has now been formally approved: the Final Draft International Standard (FDIS) of ISO/IEC 18181-1 (the JPEG XL codestream spec) was approved unanimously; the International Standard will be published in January 2022. It’s done!
2 Likes
HDR Output (Technology Preview) 18 paź 2022
…
JPEG XL
The new JPEG XL format offers several advantages over JPEG, including higher bit depth support and smaller file sizes, making it a great choice for HDR photos.
When the HDR Output feature is enabled, Camera Raw 15 supports opening and saving photos using JPEG XL. You can use JPEG XL for other types of photos as well.
and ?
RAW to jxl …
2 Likes
A few tidbits I found while trying to investigate using .jxl files
Although it seems to be supported in several versions of Firefox, as of the current FF 106, it really is not. There is a flag to enable jxl support in Firefox, but it does nothing. You have to use Firefox Nightly to actually be able to display jxls, using the flag.
jxl is also supposedly supported in ffmpeg as of version 5.1. I have that installed in Arch Linux, but it doesn’t actually work there, either. I asked for support, and the answer was that jxl is not made into the ffmpeg that is in the Arch repositories. (Well, why not?) I would have to make and compile it myself, or there is a git version in the AUR that I could install, which requires many other dependencies. Ugh!
Finally, Image Magick does support jxl. I can use Image Magick to convert other format files to jxl, and I can use it to display a jxl in a desktop window. That doesn’t help much for everyday use cases, but at least it works.
1 Like
And, just as more and more apps were beginning to support it, Google suddenly decided to kill it, citing some dubious reasons such as “not enough interest from the entire ecosystem” (I guess small companies like Facebook/Instagram, Adobe, Intel, Shopify, etc… don’t really count? Right?)
https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84
Sources:
1 Like
Is this because they want to push webp?
Apparently they are working on WebP2 and use it as an image compression playground…
https://chromium.googlesource.com/codecs/libwebp2/
JXL seems like a good codec to standardize (compared to HEIC and even AVIF). Let’s hope with the pressure from people this can be circumvented somehow.
EDIT: also, there might be a push to adopt AVIF for convenience of AOM members, despite jxl being a bit better in certain scenarios (speed, quality, features).
2 Likes
I use windows binaries for the cjxl / djxl tools, and use them quite often.
On a few production websites where the content people upload insanely huge images, we store those images as JpegXL now.
The thing is, that those images never get served directly to web browsers. Depending on device and viewport, there is a smaller, cached version generated in the popular formats as webp/png/jpg, and that is what the browser receives.
But Jpeg XL for me is an archiving format (near-lossless / lossless 16bit). I never bothered to look at browser support to be honest. It looks that indeed, for both chrome and firefox, it’s required to enable a flag in the config (and yes, nightly).
edit:
- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
Oh my g… really? It beats other formats in basically everything except lossless mode. It has higher bit depth modes from the start and supported as default (and only up to 16bit and more, not just 10/12 bit). It’s HDR ready from the start. It doesn’t degrade in quality by over smoothing the image when the bits get starved. And it compressed and decompresses in a fraction of the processing time compared to things like webp/heic/avif. And it’s standardised and bitstream locked.
This seems short sighted from the devs. I hope the ‘alternative chromium’ browsers keep it in.
2 Likes
Is this because they want to push webp?
Apparently they are working on WebP2 and use it as an image compression playground…
It looks like WepP2 also got the axe one month ago (“WebP 2 will not be released as an image format but is used as a playground for image compression experiments”):
https://chromium.googlesource.com/codecs/libwebp2/+/1251ca748c17278961c0d0059b744595b35a4943^!/
- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
Yep, this is crazy… I am starting to wonder whether any of these next generation image formats will ever get widespread support in browsers.
I hope too, but unless some major industry player steps in and decides to maintain it, those forks probably won’t want to deal with an extra dependency (and the increased attack surface that comes with it).
1 Like
Yep. It’s a mind boggling argument by google.
But what is their plan then? just AVIF adoption?
1 Like
It seems Opera still supports it. I guess its down to just me and 7 other users worldwide 
1 Like
Google works in mysterious ways…
I hope they have a plan. But it is quite possible that they don’t care much about photo content. A good part of the discussion surrounding JXL seems to be around potential bandwidth savings, not high bit-depth/wide gamut/HDR (which in my opinion are its “killer features”). Maybe the cost/benefit ratio is not worth it to Google, who may not particularly care about high-quality photographic content.
On the other hand, maybe JXL can still have a more “niche” future outside the web, as some sort of TIFF replacement. If industry players like Adobe, open-source projects (and hopefully camera manufacturers at some point) keep pushing it, it might very well be the direction it’s headed. We’ll still need to convert to lower-bit-depth AVIF when publishing to the web but, then again, we already do that sort of lossy conversion when resizing to 1080px.
Opera is based on Chromium (like most browsers that are not Firefox or Safari), so unless the Opera developers decide to proactively maintain JXL support, it will likely get dropped.
1 Like
Exactly the opposite. Imagine the photo backup web storage savings Google would have if the phones switched to it.