I very well understand that position, but at least where I compute (in GIMP, darktable, KDE Plasma), JPEG XL is well support. My file browser (Dolphin) shows thumbnails and the default image viewer (Gwenview) opens them. If support would be removed (very unlikely) I could losslessly convert them the back to a supported format.
5 Likes
I know that many people are sniffy about HDR and in particular those blinding highlights, but I genuinely think that photos that make good use of the extended range are better.
I set my Nikon to shoot HLG most of the time. I try to preserve the widest range of luminance and colors in postprocessing phase and it would be a pointless work if then everything has to be dumbed down to a limited jpg.
(And of course from a jpeg you cannot recover the lost information, if you want to upgrade to a jxl, you have to restart from the raw).
Added to that, at the same quality level jpg-xl are more space efficientā¦ itās an absolute no brainer, really.
If I have to share a pic with friends, either the sharing app already reduces it to a jpg, or converting to a jpg is a relatively easy task, which I donāt do very often any way.
Plus, even if they are not raws, jpeg-xls are much more flexible for further editing.
1 Like
Looks like we have a similar setting. Regarding Laptop and Desktop.
But I use as well a Sailfish smartphone. I doubt it would work there. The same counts for my Enigma2 Receiver. And what if I just want to send my parents or friends some picsā¦
1 Like
I was intrigued/confused by this, so I tested. The lossless mode gets a 14 MB Sony jpeg down to 11-12 MB. Not worth it. The āvisually losslessā mode (not lossless) is much better, around 3.5 MB. Still, I donāt feel safe doing a one way conversion that would increase file sizes and incur loss if I had to go back. Unlike ogg vorbis replacing mp3.
I run it with distance=1, which is more or less equivalent to a JPEG quality of 90% and is supposed to be visually lossless, which for me is good enough for non raw files. And of course, since JXL is protected from generational loss, you could re-encode these files with a bigger distance for more savings, sharing, etc, without any worries that you are re-encoding a lossy file, since it just ads more compression on top without re-compressing the whole thing.
This is the command I use:
for f in *.JPG; cjxl --compress_boxes=0 --lossless_jpeg=0 --distance=1 $f (basename $f .JPG).jxl; end
Yeah, in this case if you are in a situation where you might need to revert to another format, itās not worth it.
Ah, I see. My 10-20% gain was for lossless transcoding (i.e. if needed I can transcode back and have the exact same jpg again).
Btw: Do you know if the distance thing is some inherent feature of jxl or rather something implemented in the cjxl tool? I wonder how difficult it would be to add the distance setting as alternative to quality when exporting in darktable.
1 Like
Someone had a feature request around distance a few weeks back. I think we don need it. If anything a reference in the manual q=90, then distance =1
2 Likes
Oh, I wasnāt aware, that there is a fixed mapping between the two (I previously assumed that distance 1 might mean different quality based in image content). Then it is of course not needed. Thanks for clarifying!
This also means that I should probably reduce my setting from 95 to 90.
1 Like
I should correct myself here. Itās a free 20% savings, and I believe it can be converted back to jpeg at the original size and quality. It makes sense to convert if the programs I use can handle it.
1 Like
After processing, it was saved as a JPEG with a quality of 100% and a size of 13.2 MB
Then, using XL-Converter, they were saved as jpegli; Size: 1.29 MB
Do you see any major differences?
1 Like
Very nice photo, and I see no differences.
It is amazing how the research & algorithms for JPEG XL were backported for JPEG.
1 Like
The big difference in size would be a godsend for the internet. Is it widely supported in the various browsers ?
No, it is a diaster still: "jxl" | Can I use... Support tables for HTML5, CSS3, etc
However, with the footnote that:
- Safari does support JXL, expect for progressive images and animations.
- Google plans move the support from behind the feature flag sometime the coming moths.
- Firefox is also testing JXL, and it is currently behind a feature flag.
1 Like
It sounds like JXL has a lot of promise but it is still early days. I remember when Adobe hoped to convert ALL camera manufacturers to DNG but few engaged.
I think there is a misunderstanding here. JPEGLI is still JPEG, all browsers support it (I guess everyone can see both images?). The innovation is in exploiting the research done for JXL to make better JPEGs.
My understanding of the process is that instead of trying to invent the ābestā algorithm, the encoder minimizes size, constrained by a perceptual loss function. You either get much better-looking JPEGs, or much smaller ones, or both. But they are still JPEGs.
1 Like
By the way Reminder:
How to adds native support for JXL (JPEG XL) Windows 11 24H2 ?
To add native JPEG XL (.jxl) support in Windows 11 version 24H2, download the official JPEG XL Image Extension directly from the Microsoft Store. This plugin natively enables Windows appsālike File Explorer and Microsoft Photosāto decode and view JXL images
What to Expect
Native Thumbnail previews: File Explorer will now properly show thumbnails for your .jxl files.
System Integrations: You can natively open and view images, set JXL files as your desktop background, and use legacy apps like Windows Media Player Legacy.
Note: This native extension relies on Windows 11 24H2ās architecture and will throw an error if you attempt to install it on earlier Windows builds like 23H2 or Windows 10.
macOS and iOS: Apple includes native JXL file support across its ecosystem (macOS Sonoma and iOS 17 or later). JXL files will natively open in the Finder, Preview, and Photos apps.
Web Browsers
- Chrome: Native implementation is underway, but you can enable support today. Navigate to
chrome://flags/#enable-jxl-image-format, set the drop-down to Enabled, and relaunch your browser. - Firefox: Support is being tested, but you generally need a specialized third-party JXL viewer extension from the Firefox Add-ons Store to view
.jxlfiles inline
1 Like
There are two things going on:
-
JPEGLI is an effort to improve existing on the existing JPG system. That means that they are making better encoders but output still in the classic JPG format, so that the existing decoders be used. I used this a lot for the web, smaller image sizes but no change in handling the images themselves. Actually this gives me often comparable image sizes to webp. And the beauty is: everything that read jpg can display it.
-
JPG-XL is a kind of extension on JPG. It supports HDR, has no issues with re-encoding, and other niceness. And is even better in compression while retaining quality.This however does require both new encoders and new decoders. So software needs to be update to make it compatible.
3 Likes
Just bumping up this thread again, because thereās another aspect of this encoding technology which has not been discussed enough: the fact that raw files themselves can be reduced in size, significantly, with very little (if any, from a practical point of view) information loss.
Now, if you donāt mind the sponsor interlude, which can be skipped anyway, this guy is saying that jpg-xl encoding can already been used to compress raw files.
Unfortunately, the tool he uses in this video is Lightroom. Iām still trying to understand if there are other options and more importantly, if any open source raw editor would support this types of RAW.
I donāt use lossy compression for archiving purposes. You never know what you might lose in the process and regret later. I shoot in the lossless Sony RAW format and compress these files with bzip3 for long-term archiving. Itās a bit of a hassle, since I have to decompress them manually before using them again (no editing or viewing software does this automatically), but itās not a big problem in my workflow. This gives me files that are, on average, 1.8 times smaller, without any information loss.
2 Likes
If I were an artist who used editing techniques which would necessitate some particular information embedded into the raw files, I would certainly be interested in knowing if and to what extent that info is lost with jxl raw. And I would probably investigate and do some tests before a priori dismissing it. I reckon that Itās a big if because Iām not an artist dabbling with cutting edge technology.
On the other hand, I notice a knee-jerk reaction to the word ālossyā where the precautionary principle is invoked without even the curiosity of understanding whether anything is actually being lost. Itās more a prejudice than a rational stance.
In fact, there is always some hypothetical scenario where one day we might discover that there is a subset of data, that we didnāt think of as important, but which later we found out could be used to get something new and still perceivable by the human eye, in the final image. A final image which will always be (thankfully) ālossyā compared to the original raw data.
And either we will regret that we saved tons of images without that extra data, or weāll go back and improve our images thanks to that hypothetical data which, wisely, we didnāt dismiss.
For what is worth, my biggest hurdles, based on what I know, not what I fear, are:
- this jxl raw encoding is not freely available*
- itās not yet supported by the software I use (mainly darktable)
- thereās no camera that Iām aware of which saves the raw in jxl encoding, so you have to go the extra step of converting them manually before storage and backup
*Or is it? Adobe DNG Converter is not open source but itās currently free on 2 platforms, however itās not clear if it does the same thing that Alex shows in his video. If I save in Camera Raw 15.3 as he does in Lightroom, darktable is not able to open the DNG file. I need to choose at most 14.0.
1 Like