Copy link to clipboard
Copied
By default, Lightroom uses the Pro Photo color space "with the same gamma curve as sRGB," according to something I read somewhere. Now Pro Photo is a very wide color space, wider than any monitor can display - even my wide-gamut (Adobe RGB) monitor. If I adjust the color in an image to very high saturation, then at some point in the adjustment I must reach a part of Pro Photo that cannot be displayed on my monitor so I would expect to stop seeing any changes after that point. Yet I continue to see changes all the way up to saturation 100. So this has something to do with the sRGB curve that is somehow mapping those out-of-gamut colors to something that can be displayed.
I'd appreciate some explanation of this process, or any useful links.
Thanks.
Copy link to clipboard
Copied
LR and ACR process data with ProPhoto primaries and a linear (TRC 1.0 gamma) encoding. The histogram and RGB percentage values use a 2.2 TRC (Melissa RGB).
In terms of the disconnect between the display gamut limit and the editing space, not much you can do. If you are editing by moving a slider and all of a sudden you stop seeing the edit affect the preview, back off, you are probably editing colors outside display gamut. Also keep in mind, there are ‘colors’ defined in ProPhoto RGB that are not visible (and technically can’t be called colors).
Copy link to clipboard
Copied
Thanks for the reply. The thing is I don't necessarily stop seeing the edit affect the preview. Here's an experiment I did - I imported a raw (Adobe RGB tagged) image of grass into LR. Recall that I have a monitor that basically covers all of Adobe RGB. I notice that as I move the saturation slider I can see changes in the green, including between saturation values from 50 to 100. If I soft-proof the image using the Adobe RGB profile, it indicates that basically the whole image is out-of-gamut already at a saturation value of 50. Yet I can continue to change the saturation beyond 50 with noticeable results.
I'm coming to the conclusion that LR continues to map the out-of-gamut colors down to Adobe RGB, using some particular rendering intent (Perceptual?). As the colors get more and more out-of-gamut, the mapping changes so the image changes. Make sense?
Copy link to clipboard
Copied
I'm not a Lightroom user, but…
B__R wrote:
…I imported a raw (Adobe RGB tagged) image of grass into LR…
That sounds like an oxymoron. If the image is truly raw, it has no color profile embedded, and cannot be "tagged".
____________
Wo Tai Lao Le
我太老了
Copy link to clipboard
Copied
B__R wrote:
…I imported a raw (Adobe RGB tagged) image of grass into LR…
He probably misunderstands the in-camera setting for color space, which as we both know applies only to camera-processed jpegs.
Copy link to clipboard
Copied
B__R wrote:
If I soft-proof the image using the Adobe RGB profile, it indicates that basically the whole image is out-of-gamut already at a saturation value of 50. Yet I can continue to change the saturation beyond 50 with noticeable results.
In LR 4, which gamut overlay are you looking at? The one on the left always shows OOG for Melissa RGB (yes, I know, seems odd, you would think it would take the gamut of the profile selected but it doesn’t). The overlay on the right shows the OOG for the internal raw processing color space versus the profile you select to soft proof.
Copy link to clipboard
Copied
I realize that a raw image has no embedded color profile and should not have confused the issue. BTW - my camera identifies the raw file with the in-camera setting for color space and my usual raw image processor (Capture NX2) uses that embedded profile to define the color space of the image, unlike LR which is always using Melissa RGB. It can be changed in NX2, but it uses the tag as the initial color space definition.
I was looking at the gamut overlay in the main image window that you invoke via the soft-proof panel on the top right of the program window. I did not realize that there was one on the "left" also. Will have to check that out tonight as I don't have LR here at work. Can you be more specific as to where that second gamut overlay is and how it is invoked?
Thanks.
Copy link to clipboard
Copied
The Left Gamut overlay is kind of useless IMHO. It compares the display gamut to Melissa RGB. The Right Gamut overlay compares Melissa RGB to whatever profile you select. More useful. The Left overlay could be more useful if it was based on the profile you select (show me how my sRGB-like display gamut compares to the gamut of a profile I just selected to make a print). But alas, it doesn’t do this. I’m trying to find out the logic of the current behavior. I feel it would be far more useful in Develop without a soft proof since you are editing in MelissaRGB (kind of, it is 1.0 TRC), and seeing how that color space is out of gamut compared to the display would be real useful.
Copy link to clipboard
Copied
Andrew Rodney wrote:
The Left Gamut overlay is kind of useless IMHO. It compares the display gamut to Melissa RGB. The Right Gamut overlay compares Melissa RGB to whatever profile you select. More useful. The Left overlay could be more useful if it was based on the profile you select (show me how my sRGB-like display gamut compares to the gamut of a profile I just selected to make a print). But alas, it doesn’t do this. I’m trying to find out the logic of the current behavior. I feel it would be far more useful in Develop without a soft proof since you are editing in MelissaRGB (kind of, it is 1.0 TRC), and seeing how that color space is out of gamut compared to the display would be real useful.
I think there is some misunderstanding here. I don't have Lightroom but have looked at Julieanne Kost's video on softproofing in LR4, and what you stated is not my understanding of how the softproofing overlays work. As I understand things, the overlay toggled by the icon on the left does not compare the gamut of Melissa to that of the monitor, in which case it would be useless as everything would be out of gamut. As discussed in a recent thread in LuLa, no monitor using three primaries can display the full gamut of ProPhotoRGB. Rather it displays colors in the image (which reside in Melissa, but usually do not occupy the full gamut of that space) which are out of gamut for the monitor. It is useful because it shows what colors in the image cannot be shown on the monitor and thus cannot be evaluated by softproofing.
The softproof toggled by icon on the right does not compare the gamut of Melissa to that of the output space, but rather the colors in the image (which resides in Melissa) which are out of gamut for the output device.
http://tv.adobe.com/watch/whats-new-in-lightroom-4-beta/soft-proofing-and-dng-enhancements/
Copy link to clipboard
Copied
Bill_Janes wrote:
I think there is some misunderstanding here. I don't have Lightroom but have looked at Julieanne Kost's video on softproofing in LR4, and what you stated is not my understanding of how the softproofing overlays work. As I understand things, the overlay toggled by the icon on the left does not compare the gamut of Melissa to that of the monitor
Yes it does, Eric Chan of Adobe had confirmed this in another thread on the beta4 forums and confirmed this behavior is a bug! It is supposed to compare the gamut of the display to the gamut selected in the soft proof mode. As for Kost’s video, the use of the gamut overlay appears to me (and at least a few others) in terms of editing to remove said overlay, a bad idea. See:http://digitaldog.net/files/LR4_softproof2.mov
As Eric states in the same thread where he confirms the bug, this is more educational than a useful means of editing. Let the ICC profile clip the gamut.
Copy link to clipboard
Copied
Andrew Rodney wrote:
Bill_Janes wrote:
I think there is some misunderstanding here. I don't have Lightroom but have looked at Julieanne Kost's video on softproofing in LR4, and what you stated is not my understanding of how the softproofing overlays work. As I understand things, the overlay toggled by the icon on the left does not compare the gamut of Melissa to that of the monitor
Yes it does, Eric Chan of Adobe had confirmed this in another thread on the beta4 forums and confirmed this behavior is a bug! It is supposed to compare the gamut of the display to the gamut selected in the soft proof mode. As for Kost’s video, the use of the gamut overlay appears to me (and at least a few others) in terms of editing to remove said overlay, a bad idea. See:http://digitaldog.net/files/LR4_softproof2.mov
As Eric states in the same thread where he confirms the bug, this is more educational than a useful means of editing. Let the ICC profile clip the gamut.
You didn't give a link to Eric's post, but I downloaded the Lightroom4 beta and checked out the softproofing for myself and compared the results to those obtained in with the gamut warning of Photoshop. I selected an image with out of gamut yellows for both my printer and monitor. I then edited the image so that no colors were clipping on my softproof of the Epson 3880, but there was still some clipping on my profiled monitor (NEC PA 241W) as shown the Lightroom monitor overlay and by Photoshop set to simulate the monitor. The two proofs were essentially identical, showing that the monitor overlay in Lightroom shows colors in the image that are out of gamut for the monitor. The out of gamut colors are well within the gamut of Mellisa and ProPhotoRGB. The behavior that you suggest would be more useful, since it would show colors that are within the gamut of the printer but out of the gamut of the monitor.
I agree that editing the image to remove clipping in the overlay is often a bad idea, since the resulting image may appear very unsaturated. It is better to let the colors clip as long as important textural deatil is not blown out.
Copy link to clipboard
Copied
Bill_Janes wrote:
You didn't give a link to Eric's post,
http://forums.adobe.com/thread/947403?tstart=30
The current behavior is a bug and will be fixed.
All you have to do is toggle differing profiles and you’ll see that the display OOG overlay doesn’t change a lick. That is because the profile you select isn’t being used along with the display profile for the OGG overlay. That is the bug.
Copy link to clipboard
Copied
Andrew Rodney wrote:
Bill_Janes wrote:
You didn't give a link to Eric's post,
http://forums.adobe.com/thread/947403?tstart=30
The current behavior is a bug and will be fixed.
All you have to do is toggle differing profiles and you’ll see that the display OOG overlay doesn’t change a lick. That is because the profile you select isn’t being used along with the display profile for the OGG overlay. That is the bug.
Thanks for the link, which clears up things as summed up by Jao vdL:
"Yeah I noted that above but I think we are using slightly different terminology so you might have misunderstood what I meant. The blue overlay appears to show where the source data (which is in melissaRGB of course) is out of the display's gamut. In my opinion, it should show the areas where after conversion to the destination profile the color is still out of display gamut. This is a subtlety but I think an important one."
The current monitor softproofing works as I thought: it shows colors of the original image (present in the Melissa space) that are out of the monitor gamut before any rendering intent has been applied. If no colors are out of this gamut, the softproof of the output device (printer) should be accurate, so this display is of some benefit. However, these out of monitor gamut colors may be clipped or compressed to the gamut of the printer by the rendering process. If they become within the gamut of the monitor, softproofing should be accurate. If, not the monitor will not be able to display a proper softproof, and this is what the monitor gamut warning should show, but doesn't.
The intended action of the monitor gamut warning is not available in Photoshop. If the softproof is set to simulate the printer, rendered colors outside of the printer gamut will be shown on the warning, but there is no way to determine if colors within the rendered gamut are displayable on the monitor. One can set the softproof to simulate the monitor so as to show colors in the original image that are outside of the gamut of the monitor, but there is no way to determine if the rendered image is within the gamut of the monitor.