P: Color artifacts in JPEG XL ProPhoto RGB
Copy link to clipboard
Copied
JPEG XL files with the ProPhoro RGB color space exported from Lightroom contain color compression artifacts. They appear in quality 100% and lower. Other color spaces do not have this problem.
Lightroom version 13.3.1
Windows 11 23H2 version 22631.3593
1 Pinned Reply
Update: Recommendations:
- If using lossy compression, prefer using JXL-native color spaces such as sRGB, Display P3, or Rec 2020.
- If you must use non-native color spaces such as Adobe RGB or ProPhoto, consider using Lossless (quality 13).
Copy link to clipboard
Copied
I see similar artifacts when exporting to JXL with these options in LR 13.3.1 / Mac OS 14.5:
Prophoto, 100%, 16 bits/component
Adobe RGB, 100%, 16 bits/component
I don't see the artifacts with these options:
Display P3, 100%, 16 bits/component
Rec 2020, 100%, 16 bits/component
Prophoto, Lossless, 16 bits/component
You can download the original DNG and exported JXLs from here -- the files are perspicuously named:
https://www.dropbox.com/s/93agakaa94zsns6/export-jxl-artifacts.2024-06-13.zip?dl=0
Copy link to clipboard
Copied
@Rikk Flohr: Photography, @Rick Spaulding -, please consider moving to bugs. I've uploaded a sample file that exhibits the problem (see above).
Copy link to clipboard
Copied
Update: Recommendations:
- If using lossy compression, prefer using JXL-native color spaces such as sRGB, Display P3, or Rec 2020.
- If you must use non-native color spaces such as Adobe RGB or ProPhoto, consider using Lossless (quality 13).
Copy link to clipboard
Copied
I'm seeing artifacts I've not seen before when exporting in the JPEG XL lossy format. (90%) quality)
These a red blocks (I think 8x8 pixels size) around a strong blue colored bird.
See areas indicated by yellow areas on the picture below.
I compared it to TIFF and JPEG (90%) of identical of identical size (pixels), both are looking fine.
Increasing the JPEG XL quality to 100% doesn't solve it. Going to Lossless does.
When I started using JPEG XL, I have evaluated it and saw superior quality compared to JPEG of similar file size. These artifacts are new to me.
I'm using LR 14.1.1, Windows 11 computer.
See attached picture at 300% for easy vieweing. Unfortunately the artifacts are visible at 100% too.
Is this normal for JPEG XL? Have I overlooked it in the past? Is the contents of my picture so specific and causing this? is it a bug ? Are a few of the questions I have.
Can share the DNG file if you like.
Copy link to clipboard
Copied
Looks like a bug to me.
As a test, try setting Preferences > Performance > Use Graphics Processor to Off. Do the artifacts occur? If so, try updating your graphics driver by going directly to the manufacturer's web site:
https://helpx.adobe.com/lightroom-classic/kb/troubleshoot-gpu.html#solution-4
If that doesn't help, please copy/paste here the entire contents of the LR menu command Help > System Info -- that will let us see exactly which versions of hardware and software LR thinks you're running.
Copy link to clipboard
Copied
Hi,
With Graphics processor off, restart LR gives the same result : artificacs as reported above for the JPEG XL
My system is / was up to date with the latest graphics driver from Nvidia : 566.36 (Dec.2024)
LR system info:
Copy link to clipboard
Copied
I forgot that there is an existing bug report about this from last June, acknowledged by Adobe, when exporting to JPEG XL with Prophoto or Adobe RGB color spaces:
A workaround is to use Display P3 or Rec 20202, or switch to AVIF.
LR also has bugs exporting JPEG XLs at sizes that are way too large:
Overall, I don't think LR export of JPEG XL is ready for prime time -- best to stay away from it until/if Adobe decides to fix the bugs.
Copy link to clipboard
Copied
Moderators, @Rikk Flohr: Photography, please merge with this Bug:
Copy link to clipboard
Copied
@Rikk Flohr: Photography, it looks like this thread was just moved from Bugs to Discussions (after I posted my last reply above). Are the artifacts now considered as-designed rather than as a bug?
Copy link to clipboard
Copied
@johnrellis
It is not as designed but rather a design limitation with the JPEG-XL. Comments from the engineers
"This is a quality limitation of JPEG XL when used with non-native color spaces in lossy mode."
I updated Rick Spaulding's post to reflect the correct workflow.
Copy link to clipboard
Copied
@Rikk Flohr: Photography after reading your commens from the engineers, the idea from @reproo2773183 might not be a bad idea:
would it be worth limiting the user's choices of color space when exporting from Lightroom. eg remove or grey-out AdobeRGB and ProPhoto, when selecting JXL lossy?
Ruud
Copy link to clipboard
Copied
Agreed that if there are going to be problems with using deprecated color spaces with JPEG XL export, LR should give some kind of warning. Prophoto in particular is a popular wide color space (not least because its primaries are the same as LR uses internally), so if that's not fully supported, LR should at a minimum warn the user.
Copy link to clipboard
Copied
[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]
I wrote, "Prophoto in particular is a popular wide color space (not least because its primaries are the same as LR uses internally)". LR itself tells users that "16-bit ProPhoto RGB is the recommended choice for best preserving color details from Lightroom":
So little wonder that people will try to use Prophoto with JPEG XL export!
Copy link to clipboard
Copied
This is exactly why I was using ProPhoto colour space.
Because most of my work is with converted negatives, I like to have a positive copy saved for editing work. TIFF is way too large and traditional JPEGs lose too much information for my liking. I was hoping JXL would be the answer for a space convenient 16bit file.
Copy link to clipboard
Copied
[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]
@Rikk Flohr: Photography: "It is not as designed but rather a design limitation with the JPEG-XL. Comments from the engineers: "This is a quality limitation of JPEG XL when used with non-native color spaces in lossy mode.""
@Rikk Flohr: Photography, the "cjxl" program from the libjxl JPEG XL reference implementation doesn't produce these artifacts with ProPhoto RGB and lossy mode. So this points to a bug in LR's implementation rather than a limitation of JPEG XL. It would be interesting to get the engineers' perspective on why "cjxl" doesn't generate the artifacts.
To demonstrate with LR 14.1.1 / Mac OS 15.2:
1. I used LR to export a denoised DNG to the file x.png.
2. I exported x.png to x.jxl, with the options Image Format: JPEG XL, Quality: 100, Color Space: ProPhoto RGB, Bit Depth: 16 bits/component.
3. I used "cjxl" to generate x-cjxl.png from x.png, with the option --quality=99:
cjxl x.png x-cjxl.jxl --quality=99
The screenshot below shows x.jxl, x.png, and x-cjxl.jxl. There is no visual difference between x.png and x-cjxl.jxl, though there are quite noticeable artifacts in x.jxl:
You can download a catalog with all the images from here:
https://www.dropbox.com/s/q2kssve7f16gpt4/jxl-artifacts.2025-01-24.zip?dl=0
The exact "cjxl" command:
$ cjxl x.png x-cjxl.jxl --quality=99
JPEG XL encoder v0.11.0 [NEON]
libpng warning: iCCP: profile 'ProPhoto RGB': 0h: PCS illuminant is not D50
Encoding [VarDCT, d0.190, effort: 7]
Compressed to 30494.7 kB including container (5.369 bpp).
5504 x 8256, 14.558 MP/s [14.56, 14.56], , 1 reps, 12 threads.
The "jxlinfo" command shows that the image is lossy and in ProPhoto:
$ jxlinfo x-cjxl.jxl
JPEG XL file format container (ISO/IEC 18181-2)
JPEG XL image, 5504x8256, lossy, 16-bit RGB
Color space: RGB, Custom, white_point(x=0.345705,y=0.358540), Custom primaries: red(x=0.734699,y=0.265302), green(x=0.159600,y=0.840399), blue(x=0.036597,y=0.000106)gamma(0.555315) transfer function, rendering intent: Perceptual
Brotli-compressed xml metadata: 3381 compressed bytes
The warning "PCS illuminant is not D50" arises because "cjxl" thinks the white point of x.png's colorspace has x=0.345705, whereas ProPhoto's D50 white point has x=0.345704 -- probably a rounding error somewhere.
But otherwise, "jxlinfo" shows the colorspace of x-cjxl.jxl is identical to Prophoto RGB.
Copy link to clipboard
Copied
Hi John,
Agree, the color artifacts on my small blue bird is similar to June bug report.
When I assign the Display P3 color profile, the artifacts are gone, so confirmed.
Sound advice to stay away from JPEG XL for critical work or archiving my finished edits, but I do believe that the JPEG XL compression is also the standard format for Lightroom merged panorama and HDR files?
No problems (expected)?
Ruud
Copy link to clipboard
Copied
@reproo2773183: "I do believe that the JPEG XL compression is also the standard format for Lightroom merged panorama and HDR files? No problems (expected)?"
That's a good question. There certainly haven't been any reports here about artifacts in Photo Merge DNGs since JPEG XL was introduced 1.5 years ago. But I don't know much about JPEG XL (the ISO foolishly charges hundreds of dollars for the privilege to read the specs). But the Photo Merge DNGs and exported JPEG XLs are much different beasts.
The DNGs produced by Photo Merge represent the merged photo as "linear raw", with the Bayer color-filter array pixels demosaiced into three separate RGB channels. But there's no change in the color space -- the values of the pixels are what comes from the camera's sensor (demosaiced). Those three channels are then compressed with lossy JPEG XL compression.
But an exported JPEG XL contains pixels rendered by the Camera Raw engine into the selected color space and then compressed. I don't know what it is about the JPEG XL standard that would cause these artifacts for some color spaces.
Copy link to clipboard
Copied
@johnrellis Thanks for clarifying, I learned something new!
Copy link to clipboard
Copied
That's a good question. There certainly haven't been any reports here about artifacts in Photo Merge DNGs since JPEG XL was introduced 1.5 years ago. But I don't know much about JPEG XL (the ISO foolishly charges hundreds of dollars for the privilege to read the specs). But the Photo Merge DNGs and exported JPEG XLs are much different beasts.
The DNGs produced by Photo Merge represent the merged photo as "linear raw", with the Bayer color-filter array pixels demosaiced into three separate RGB channels. But there's no change in the color space -- the values of the pixels are what comes from the camera's sensor (demosaiced). Those three channels are then compressed with lossy JPEG XL compression.
But an exported JPEG XL contains pixels rendered by the Camera Raw engine into the selected color space and then compressed. I don't know what it is about the JPEG XL standard that would cause these artifacts for some color spaces.
By johnrellis
My Thoughts: I think "linear raw" is the sensor values, possibly "Linear Light" or "intensity", there are 3 values but none of this is RGB.
A "camera profile" (dcm) converts the Linear Light values to RGB (Display Code Values) eventually but I think there has to be an interim step or two involving CIExyz.
RGB values are meaningless without a Colour Profile (icc). Lightroom is always dealing with its Working Space and your monitor's profile. When it comes to Export; Lightroom does not need to consider the Monitor Profile?
I also don't know where the Adobe engineers are hitting this limitation with "non native profiles". Perhaps its and HDR thing?
Its not likely to become any clearer since there are too many unknowns.
I can't remember which RGB Profiles are available to Affinity Photo when it Exports to JPEG XL but they are much smaller files and I've not seen any of these artifacts.
Copy link to clipboard
Copied
@reproo2773183: "I think "linear raw" is the sensor values, possibly "Linear Light" or "intensity", there are 3 values but none of this is RGB."
The term "RGB" has different meanings in different contexts, but it most definitely is used in the DNG spec to describe raw sensor values.
In the DNG spec, un-demosaiced sensor data from the camera's color filter arrays are stored in the DNG. This sensor data consists of red, green, and blue samples from the CFA, sometimes abbreviated as RGB. The spec variously calls these "native camera RGB values", "RGB camera values", "reference camera native space values". The values are in what the spec calls "camera color space", "camera native color space", "camera space", "same color space as the raw image data".
It's also common outside of the DNG spec to refer to color filter arrays samples as RGB:
https://en.wikipedia.org/wiki/Bayer_filter
DNGs store the output from Denoise as de-moasaiced raw data to which the denoise algorithm has been applied, using an alternate raw representation the spec calls LinearRaw. LinearRaw stores three "color planes" (channels) of red, green, and blue samples, in the same color space as the CFA representation ("camera color space").
It is the job of DNG camera profiles to map RGB values in the camera color space to the ICC color connection space and then to particular color profiles such as Prophoto RGB or Adobe RGB.
Copy link to clipboard
Copied
Thank you for your explanation and links.
When you say "In the DNG spec, un-demosaiced sensor data from the camera's color filter arrays are stored in the DNG" this is optional or always?
IF you have (DNG) output from DeNoise or Pano Merge which is de-mosaiced but still "camera color space" LinearRaw would you need the un-mosaiced?
from reading the DNG spec I think I get that its the de-mosaiced data that can be JPEG XL, I'm also thinking that this is still "camera color space" LinearRaw; so still has full flexibilty to be manipulated/converted by camera profiles the ICC color connection space.
So IF (Big IF) I have the above right, then When you Export Lightroom tries to go back to the de-mosaiced linear raw JPEG XL and convert that to JPEG XL (but unsupported ICC) its going wrong in a manner that doesn't go wrong when going through Lightroom's internal ProPhoto (D50) to screen.
I'm also wondering if for Adobe JPEG XL is limited to Linear Raw, which would explain why it opens in ACR rather than Photoshop?
Copy link to clipboard
Copied
@reproo2773183: "When you say "In the DNG spec, un-demosaiced sensor data from the camera's color filter arrays are stored in the DNG", this is optional or always?"
Raws coming straight from cameras always contain color-filter array samples (un-demosaiced).
DNGs produced by LR's Photo Merge and Enhance commands store the merged/enhanced image as linear raw (demosaiced). But they also store the original, unmodified CFA samples in a separate section of the file.
"If you have (DNG) output from DeNoise or Pano Merge which is de-mosaiced but still "camera color space" LinearRaw would you need the un- [de]mosaiced?"
As mentioned above, the DNGs produced by Photo Merge and Enhance also contain the original CFA samples (un-demosaiced), but I don't know of any parts of LR or Camera Raw that actually uses it. Adobe said a couple years ago they included the original CFA data in anticipation of possible future enhancements, though they haven't provided more details. If you retain the original from-the-camera raw, you'll still have access to the original, unmodified image.
"from reading the DNG spec I think I get that its the de-mosaiced data that can be JPEG XL, I'm also thinking that this is still "camera color space" LinearRaw; so still has full flexibilty to be manipulated/converted by camera profiles the ICC color connection space."
That's correct. The linear raw (demosaiced) pixels are still in camera color space. They are usually compressed using the JPEG XL compression algorithm, though they could also be compressed with JPEG compression or uncompressed, as allowed by earlier versions of the DNG spec. But only the compression algorithms of JPEG XL and JPEG are involved with linear raw data -- no other aspect of the JPEG XL or JPEG file formats are used with linear raw.
"When you Export Lightroom tries to go back to the de-mosaiced linear raw JPEG XL and convert that to JPEG XL (but unsupported ICC) its going wrong in a manner that doesn't go wrong when going through Lightroom's internal ProPhoto (D50) to screen."
The different uses of the term "JPEG XL" are causing confusion here.
The linear raw DNGs produced by Photo Merge and Enhance use JPEG XL compression to store the linear raw pixels (in camera color space), but they are full raws.
When you export any file to JPEG XL file format, the output file is in full JPEG XL format ("JXL") , and the output pixels are in the specific color space (e.g. sRGB or Prophoto), not in camera color space. The problem with artifacts in the output JXL file is, according to Adobe, caused by the use of certain color spaces (Prophoto and Adobe RGB), which are called "non-native" for as-yet unexplained reasons. The implication is that JPEG XL format doesn't really support those color spaces somehow. It's hard for me to learn more, since the ISO charges hundreds of dollars for the privilege of reading their specs.
"I'm also wondering if for Adobe JPEG XL is limited to Linear Raw, which would explain why it opens in ACR rather than Photoshop?"
When you open a DNG stored in linear-raw format in Photoshop, it opens in CR because the DNG is a full-fledged raw file.
But when you open a JXL exported from LR in Photoshop, it too opens in CR. I think that's a small Photoshop bug. Opening JXLs in PS should behave the same as opening JPGs.
Copy link to clipboard
Copied
I wrote, "But when you open a JXL exported from LR in Photoshop, it too opens in CR. I think that's a small Photoshop bug. Opening JXLs in PS should behave the same as opening JPGs."
After a little poking around, I think this is "as-designed" behavior. Photoshop proper can't read or write JXL files, but Camera Raw can read JXL files. So Adobe allows Photoshop to open JXL files by having them open first in Camera Raw, from which you can open the image in full Photoshop.
Copy link to clipboard
Copied
"The implication is that JPEG XL format doesn't really support those color spaces somehow."
Its only when you add in lossy compression that you get the artifacts.
I'm now thinking its during the conversion from the native space to the non-native space some of the maths/rounding doesn't allow for a number bigger than 1 or smaller than 0 and you get a blown or clipping artifact in one or more of the channels.
![](/skins/images/1A2984DC5E3889F4435E998DD71294F3/responsive_peak/images/icon_anonymous_message.png)
![](/skins/images/1A2984DC5E3889F4435E998DD71294F3/responsive_peak/images/icon_anonymous_message.png)