Safari support for HDR JXL/AVIF seems to be on its way (at least the Feedback app now indicates a “Potential fix identified - For a future OS update”).
In the meantime, I have noticed (and reported) a few more issues: some performance issue (and possibly rendering bug) in Photos when using a PQ curve, and empty previews in Files.
That might be a good occasion to mention that Apple seems to prioritise popular reports as quantified by the “Recent Similar Reports”. So, if some of you have an HDR-enabled Apple device and can try one of the betas (possibly the upcoming public beta, which should be more stable that the developer beta), please file any JPEG XL-related issues in the Feedback app. It will increase their visibility and the probability that the issues get fixed.
They keep making it better. “If you build it, they will come” - Field of Dreams
I’m hopeful with the continued development, it becomes supported in more platforms. I would like to export/maintain my library in the JXL, but right now if I want to share an image with anyone, I have to export it in JPG to ensure they can see it.
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.
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.
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.”
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.
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”.
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.
From now on, I’ll turn off this software when editing photos.
