Hi DxO team,
in the meantime a successor of JPG is available: JPX or JPG XL.
Please offer JPG XL / JPX as an export possibility for Photolab and of course also allow Photolab to open JPG XL / JPX files.
Thanks, Joerg
This is a good suggestion, and I am voting for it.
Just be aware that JPEG XL only has 13.5% worldwide device/software support.
This is seven times lower support than AVIF, which is based on the state-of-the-art HEIF/HEIC format.
JPEG XL was initially supported by Google, but after further evaluation and study by Google ( https://storage.googleapis.com/avif-comparison/index.html ) it was removed from being supported after Google’s studies found JPEG XL to be lacking in decoding speed, transcoding speed, and quality.
There was only one case (next to last graph) where JPEG XL was found superior, and that case only applies to its lossless mode (like 100% JPEG mode when compression is essentially turned off). In every other mode, quality, signal-to-noise ratio, SSIM, mean squared error, etc., are better for AVIF ( Should AVIF be the dominant image format on the web? - Tim Severien ).
Both support modern resolutions up to and higher than 60,000x60,000 pixels and are designed with a focus on utmost pure quality.
I think DxO should definitely support both of them and you have my vote.
But please also vote for my suggestion to support AVIF as part of HEIF / HEIC support as well.
1 Like
Useful, as JPG Xl is useful to support DNG decoding and encoding.
Microsoft Co-pilot wrote:
JPEG XL and DNG: A New Alliance
Yes, JPEG XL is becoming relevant for certain recent DNG encodings, especially with the DNG 1.7 specification. Here’s what you need to know:
- DNG 1.7 now allows JPEG XL as a compression codec for raw image data.
- This option is already supported by high-end devices like the iPhone 16 Pro and Samsung Galaxy S24.
- The goal is to improve lossless compression, replacing the older JPEG lossless (which was less efficient) with JPEG XL.
Why JPEG XL Is Useful in This Context
- More efficient compression: For example, a 48 MP ProRAW photo goes from 75 MB to 46 MB using JPEG XL — nearly a 40% reduction.
- Preserved quality: Even in lossy mode, JPEG XL maintains excellent fidelity and dynamic range.
- Modular mode: JPEG XL uses a modular compression mode for raw data, ideal for high-resolution images and RAW formats.
In Summary
JPEG XL isn’t strictly “required” for all DNG encodings, but it’s becoming highly recommended for newer formats aiming to optimize file size while preserving quality. If you’re working with DNG files from newer devices or software that support DNG 1.7, JPEG XL can be a major asset.
I don’t know ProRaw but if you want to compare compression you have to compare it with the in-memory rgb image or a tiff export.
Farewell Co-pilot.
George
I just installed the reference build of the JPEG-XL library and with a little scripting and automation I can losslessly convert any JPEG to JPEG-XL for a noticeable file size reduction. If I cared to I could build a TIFF converter, I am sure.
By the way, all Apple devices can display JPEG-XL as of last year.
Here are the detailed figures and reference for JPEG XL compression on 48 MP ProRAW images:
Compression Details
According to Apple’s internal estimates (as reported by 9to5Mac and Macworld):
| Format | Resolution | File Size |
|---|---|---|
| ProRAW (standard DNG) | 48 MP | ~75 MB |
| JPEG XL Lossless ProRAW | 48 MP | ~46 MB |
| JPEG XL Lossy ProRAW | 48 MP | ~20 MB |
This means:
- Lossless JPEG XL achieves a ~40% reduction compared to standard ProRAW.
- Lossy JPEG XL offers even greater savings, though with some quality trade-offs.
These options are available in the ProRAW settings on the iPhone 16 Pro, which supports JPEG XL natively for both lossy and lossless compression.
You can read more in Macworld’s coverage or 9to5Mac’s article.
I mean compression is done on the in-memory rgb raster image. Compression is output/input. The raw files are not the input. They have to be converted to a rgb raster image first. One can compare the file sizes but can’t say the difference is due to compression.
I wonder why the file size of the lossless jpeg-xl is nearly the same or even bigger in the small file size and about 40% of the larger file size.
I’ve no iPhone.
George
I think the 48Mpx original came from Quad Bayer CFA, while 12Mpx came from the same data with values in each “quad” averaged. Obviously you get better compression ratio (on average) for Quad Bayer pattern than for “emulated” standard Bayer CFA pattern.
Or a fixed size of metadata. More obvious with smaller sensors as with bigger sensors.
George
Despite the confusing name, Apple ProRaw is not a true RAW format. The output is a demosaiced linear DNG.
Prior to the iPhone 16 Pro, Apple used JPEG compression in outputting ProRaw. I 'm pretty sure the “ProRaw Standard DNG” referenced above is the ProRaw DNG with JPEG compression. That’s about the size of ProRaw files that output from my iPhone 15 Pro. The relatively huge size of these files has been thought to be a deterrent to more widespread usage. Hence, the introduction of JPEG XL compression. Of note, reviewers have claimed that the iPhone 16 Pro ProRaw lossy JPEG XL compression setting results in a visually lossless image.
1 Like
Metadata is usually much less than 1% of the file size, unimportant here. Thumbnails/previews take a bit more, but these are proportional (mostly).
The tests were for the same Quad Bayer sensor I presume. It was (in-camera) demosaicking which was different.
1 Like
Indeed, not much. Strange, the same picture but with 2 different dates.
George
Don’t forget to vote 
Exactly. That’s why it was even using JPEG at first in the “raw” file. There is also tons of computational stuff done before the ProRaw is made, so definitely not real raw.
I’ve been looking what that quad means. What I understood or didn’t understood is based on https://www.sony-semicon.com/en/technology/mobile/quad-bayer-coding.html
What I’m wondering off is that when the hardware can combine 4 sensels to one color how that behaves to a color filter array?
George
This is a great question, but probably off-topic to whether or not JPEG-XL support should be added.
If you copy and paste your post into a new thread, I’m sure someone would be happy to help!
For example, one way of doing quad-bayer coding would be to use one color filter over several hardware pixels, and then those pixels could be binned together for a lower resolution photos with regular bayer interpolation, or they could be decoupled for higher resolution with a more advanced type of interpolation.
Have you tried doing the same with some other image formats, too?
Is it the same size difference as published by Apple (for the lossless option)?
By the way, even though I mention the “lossless” option this is actually false information if you are beginning with a regular JPEG in the first place.
The original JPEG is not a lossless format, even at 100% quality, so if you converted a regular JPEG “losslessly” to a JPEG XL file, there still would be image information lost already, during the process of encoding the original JPEG, even if no additional information is lost by the conversion from the original JPEG into the JPEG XL format.