Just noticed today that Finder, Quick Look and Preview (in macOS 14.3.1) have all added initial support for HDR when viewing JPEG XL files.
EDIT: nope, a bug related to some auto-brightness software (Lunar) seemed to incorrectly have triggered the HDR mode, and made the images “look HDR” by pushing the contrast, while highlights were still clipped 
From now on, I’ll turn off this software when editing photos.
For anyone that’s interested:
In FireFox, the link takes me here:
https://d2x313g9lpht1q.cloudfront.net/original/3X/3/9/398e428f37ad54cb2a36a6631c199cfbe433dacd.png
which has no text.
This three year old post is probably it, not “new” though:
Oops - just noticed how old this thread is, duh …
If you run Firefox Nightly, and you have the jpeg xl infrastructure installed, and you set the Firefox options to use it, you can display jpeg xl in Firefox. I have two of these (I’m not running Firefox Nightly), and I still can’t display them.
Sounds like a lot of work, though.
[edit] .jxl is not available in RawTherapee 5.8, but the GIMP 2.10.34 just opened one![/edit]
Didn’t know what that was, so, if anyone else is interested:
Earlier, after a long period of testing, its support in Google’s Chrome browser was abandoned due to “lack of significant benefits and community interest.”
https://giannirosato.com/blog/post/jpegli/
Google has published the JPEG encoder and decoder implementation for Jpegli on GitHub, for anyone interested in testing the new and advanced JPEG coding library.
libjxl v0.10.2 in Release v0.10.2 · libjxl/libjxl · GitHub
Those interested in testing can do so using:
XL Converter 0.9.9 XL Converter – Code Poems (2024-04-05)
XnView MP v 1.7.1
Interesting.
May I ask if you are/were involved personally with Jpegli’s development?
From a few other comments I’ve seen, part of the reason for this disparity is because the Google Research and Google Chrome teams are in completely separate organizations, and jpegli comes from Google Research.
Classic corporate “right hand doesn’t know what the left is doing”.
HaHaHa
If at 90 years of age you can be involved in something, then only in well-being
OK. At 84, I understand!
To become part of the specification for the web, it needs to go via W3C and they need to convince multiple vendors to use it. There’s not much point having a web image format that only one vendor has implemented.
JPEG XL? Only for the web? It’s an ISO Standard since 2022. This file format with its capabilities is obviously quite underestimated.
For example I would like to say that camera manufacturers could finally deal more intensively with it as replacement for the outdated 8-Bit JPEG. For an easy and consistent high-bit image editing workflow or a space-saving and still loss-free archiving, it would have only advantages (also away and independend from DNG and cameranative RAWs). Apart from this, it is open source and free from patents, so it can be used everywhere at low cost.
The only problem is the great resistance of individual players with a large lobby, patents and otherwise the restraint in standard implementation in favor of users.
The comment was related to its withdrawal from Chrome not a comment on JPEG XL’s overall efficiency or usage.
Also, JPEG XL is most definitely not free from Patents. It is available with a royalty free licence from the Patent holders who have declared an interest. That doesn’t mean if doesn’t infringe other patents for which a user would be liable.
For example, from the reference implementation: libjxl/PATENTS at main · libjxl/libjxl · GitHub
ISO standard doesn’t mean anything for web usage unless it’s a W3C standard too.
It looks like JXL’s niche is going to be as an intermediate exchange format. I think DNG 1.7 is going to be JXL’s “killer app”
Especially since at this point, the only forward progress on a common standard for HDR and wide gamut that is being adopted by multiple browsers (with Safari the only holdout so far…) is JPEG MPF with a gainmap. Aka Google’s “Ultra HDR” although it’s a format that Adobe originally developed. The big advantage there being backwards compatibility with SDR and narrow-gamut displays with the content author being able to control the tonemapping.
OK, thanks.
You are right, but the idea for JPEG XL was to let it be free as possible.
Shure 
With JPEG XL on board 
DNG had only caused me problems since the beginnings. Be it due to lack of support of the different version levels or any required conversion into this format. Somewhere it was always without advantages for my workflow and then required further image formats to be maintained. I completely forgot it. JPEG XL, with its basic features, and without the other formats underlying video compressions, represents an acceptable archive format for broadly fanned and different image data that could be stored in a space-saving manner regardless of the size or bit depth without further quality losses. For this purpose, DNG seems to me simply too bulky and too incomparable in handling, since JPEG XL can still provide a previous 8-bit JPEG without problems.
I see and need JPEG XL not as a substitute for special RAW file formats but as an easy-to-use image that offers similar advantages in a wide range.
But I limit that this file format comes very close to my own workflow and handling of image data. The best would be, if this format would be the same from the camera, then it could be used throughout without intermediate conversion up to a possible preparation and conversion for certain purposes. I come from the publishing area and already appreciate the media-neutral handling up to an issue for a specific purpose.
DNG is just a TIFF with appropriate metadata that provides a raw processor with the information it needs to properly postprocess an image. There’s nothing bulky about it - just tens of bytes of metadata tags. A TIFF can be converted to a DNG with only a few tags using exiftool.
DNG 1.7’s big addition is support for storing image data in JXL format.
Not a rebuttal but we should bear in mind that there is more than one variety of DNG and more that one of TIFF.
For example, the Sigma sd Quattro H puts out about a whopping 150MB DNG but only about a 50MB raw X3F.
And currently my GIMP outputs layered TIFFs that my FastStone Viewer won’t open as an image.
Never simple, eh?
