Lightroom and color space issues

[cesdls]

I recently posted a short tutorial and video on my website at http://www.craigstocksarts.com/tutor...lor_gamut.html where I attempted to explain why Lightroom's output frequently doesn't match the input. The problem is that LR (and Camera Raw) work in very large color spaces, so you can't really trust that the histogram reflects the output.

It's an area I haven't seen much about. Most discussions end in an overly simply recommendation to either always use sRGB (since it's safe) or always use ProPhoto (to avoid throwing away information). It seems to me that the real answer is to understand the conversion issues and know how to use soft proofing (now part of Lightroom 4's public beta) to anticipate problem areas.

I started exploring this area because I found I was getting bit. Even when I carefully monitored the historgram in LR (or ACR) I'd find clipped colors when I opened the image in Photoshop, usually in Adobe RGB 1998. It was especially frustrating since I was foolishly relying on LR's histogram - something I won't do anymore.

Now, for serious work, I'll go to Photoshop in ProPhoto, and then check gamut warnings in my destination color space, and also check the image's gamut warning using my monitor's profile to make sure I'm not working blind in some areas. Then, I can deal with problem areas selectvely.

[andrewrodney]

Originally Posted by cesdls

Now, for serious work, I'll go to Photoshop in ProPhoto, and then check gamut warnings in my destination color space, and also check the image's gamut warning using my monitor's profile to make sure I'm not working blind in some areas. Then, I can deal with problem areas selectvely.

The OOG overlays are more educational than useful. There is nearly always going to be some gamut clipping in a color space conversion, certainly between simple shaped RGB working space and complex output color spaces. The profiels will do the job as best as the technology allows and with far more precision than you can do manually as illustrated here:

http://digitaldog.net/files/LR4_softproof2.mov

Working with color outside display gamut isn’t that difficult. IF you start moving a slider that alters saturation, even on a wide gamut display, and as you move the slider you stop seeing anything happening STOP and back off.

[cesdls]

After watching your video I have a question and an added comment. The question - in the video, you exported the image and converted into sRGB, then imported the result into LR. The gamut overlay implied that there were out of sRGB gamut colors in the sRGB file. How can that be? Does that imply some flaws in LR's gamut warning calulations?

Also, the problem I was facing was not just colors shifting. I was seeing situations where colors would clip so badly that I'd have blocks of solid color in output files or in prints. Since I do mostly landscape photography, I was seeing it in wispy, colorful clouds at sunset. All the wispy texture that was there in LR was being lost in an output PSD or JPEG, even though the LR histogram didn't indicate any clipping at all. I wouldn't mind if the colors just shifted, but the severe blocking up and loss of texture was a problem. That was the situation I tried to illustrate in my video.

[andrewrodney]

in the video, you exported the image and converted into sRGB, then imported the result into LR. The gamut overlay implied that there were out of sRGB gamut colors in the sRGB file. How can that be?

It is a bug in LR. There are a few in that build (the overlay for display gamut always using MelissaRGB is indeed a bug).

I was seeing situations where colors would clip so badly that I'd have blocks of solid color in output files or in prints.

Sounds like either a poorly built output profile or a poorly built perceptual rendering intent (which is profile building software specific). The original encoding color space could play a role too.


Simple matrix profiles of RGB working spaces when plotted 3 dimensionally illustrate that they reach their maximum saturation at high luminance levels. The opposite is seen with print (output) color spaces. Printers produce color by adding ink or some colorant, while working space profiles are based on building more saturation by adding more light due to the differences in subtractive and additive color models. To counter this, you need a really big RGB working space like ProPhoto RGB due to the simple size and to fit the round peg in the bigger square hole. RGB working spaces have shapes which simple and predictable. Then there is the issue of very dark colors of intense saturation which do occur in nature and we can capture with many devices. Many of these colors fall outside Adobe RGB (1998) and when you encode into such a space or smaller, you clip the colors to the degree that smooth gradations become solid blobs in print, again due to the dissimilar shapes and differences in how the two spaces relate to luminance. So the advantage of ProPhoto isn't only about retaining all those out-of-gamut colors it's also about maintaining the dissimilarities between them, so that you can map them into a printable color space as gradations rather than ending up as blobs. 
Might be what you are describing. Without having the original and the profile (or testing it with other profiles), hard to say for sure.

[cesdls]

Your comment about the quality of the profile or the conversion is a big part part of why I was surprised at the problems. The conversions were all plain vanilla - either output from LR to an sRGB jpeg, or converted in Photoshop CS5 using Convert to Profile. In PS, I stay in ProPhoto RGB 16 bit mode until after I resize, and convert to sRGB. Only then do I convert to 8 bit. I don't know if that's the best way, but it seems to make sense to me to keep 16 bit until I'm done transforming.

I had been using Adobe RGB 1998 as my Photoshop working color space, but I've since switched to ProPhoto.

Whether I'm working in LR or ProPhoto RGB in Photoshop, there's just no getting around the fact that at some point, I'm going to have to squeeze the image into a smaller color space, either the printer/paper profile or sRGB for the web. What surprises me is how poorly some images convert if you don't do some special hand-holding. And, before LR 4 beta, you couldn't rely on the LR histrogram since it reflects a huge color space.

[andrewrodney]

Originally Posted by cesdls

Whether I'm working in LR or ProPhoto RGB in Photoshop, there's just no getting around the fact that at some point, I'm going to have to squeeze the image into a smaller color space, either the printer/paper profile or sRGB for the web. What surprises me is how poorly some images convert if you don't do some special hand-holding.

And I see just the opposite.

[cesdls]

Andrew - you're certainly a respected expert in this field, so I'm hoping to learn something. But, I'm confused about what you don't agree with. Do you disagree that I get poor results with some images when I let Lightroom or Photoshop handle the conversion? Or am I doing something wrong in my workflow that yields poor results?

I've also posted larger versions of the conversions I used as examples at http://www.craigstocksarts.com/tutor...mut_large.html. To my eye, and on my monitor, the straight LR conversions to an sRGB jpeg looses detail in the brightest portions of the clouds. Is there a better way to convert to sRGB without loosing detail?

[andrewrodney]

What I am suggesting is that manually trying to put OOG colors into gamut using the overlay and tools (Sponge in PS, HSL in LR) is not a fine toolset and the profiles do a better job. But if you have some problematic images, and associated profiles, I’d be happy to look them over.

One issue with conversations to sRGB is there is no perceptual table available in this or any V2 profiles. There is a V4 profile floating around (try www.color.org) that in theory may help with some images because you can use a perceptual mapping.

[cesdls]

I appreciate your offer. I've added a link where you can download the PSD ProPhoto file at http://www.craigstocksarts.com/tutor...mut_large.html.

As far as the profiles, they are the standard sRGB and ProPhoto profiles used by Lightroom 3.6 and Photoshop CS5.1 - sRGB IEC61966-2.1 and ProPhoto RGB (no version listed). The sRGB profile shows a file date of 6/10/2009 and the ProPhoto profile shows a file date of 12/17/2010. Both LR and PS were installed from fresh downloads onto a new computer in November 2011.

[andrewrodney]

I don’t see anything really unusual in your files. Yes, the ProPhoto RGB image has colors OOG in the areas of the very saturated clouds. I’m viewing both on a wide gamut display using standard working space profiles in Photoshop. Side by side conversions appear quite similar, toggling on and off an overlay as you provide looks more dramatic but the bottom line is, you have OOG colors that have to map into the smaller sRGB space. Using the Overlay in Photoshop on the ProPhoto image, then selectively making it disappear using a Sponge Tool set to desaturate doesn’t provide a better conversion IMHO. And it takes more time.

What I did was setup sRGB as the soft proof, put the OOG overlay one. I set Sponge to desaturate at 20%. But I put a rectangle marquee over the OOG area so only part was affected. The idea was to see what the area manually desaturated looked like compared to an area not affected but converted into gamut by the profile. Like my video, I see more saturation in the area where the profile converted the data. I don’t see the lesser saturated and manually desaturated area have any more detail either.

[cesdls]

Thanks for the input.

Actually, I've never used the Sponge tool. In the example in the video, I used a combination of a Vibrance layer (in Saturation blending mode) and an applied layer of the Green channel in Multiply blending mode selectively applied through a layer mask. The Vibrance adjustment (admittedly a blunt tool) let me reduce over all saturation to address most of the OOG colors, then add vibrance to restore saturation to the less saturated colors. With some fiddling you can find a balance that reigns in most of the OOG colors while retaining or enhancing the saturation elsewhere. I then applied the Green (or you could use the Red) channel in Multiply mode hidden by a layer mask. By gradually painting in the multiply layer where there are still OOG colors, it has the effect of darkening and reducing saturation and also adds contrast to the wispy details. Perhaps it's cheating a bit since I'm fiddling with contrast locally as well as saturation, but I feel the effort gives me the best conversion.

Ultimately, the real point of my post is to encourage people to be aware of potential conversion problems. Whether by using soft proofing and/or OOG overlays, or simply checking the image after conversion (or output from LR).

The vast majority of my images convert and/or print just fine, but there are a few that benefit from special care. If I'm not watching for those problems, I won't catch the few with challenging areas. Once I'm aware of a problem, I can then choose how to address it, or even choose to not address it.

[John Wheeler]

Hi cesdls

Thanks for posting the information. Sounds like you are taking good steps to get the image you want through soft proofing and specific compensating techniques. A couple thoughts

- There was not too much talk about rendering intents. Not all spaces/profiles support all the rendering intents yet the different supported rendering intents can sometimes make a difference (especially looking at printer profiles the perceptual rendering intent will compress the channel information just a little less if supported).

- In your images, it is also useful to look at the histograms with a selection around the most affected areas instead of the whole image. Also, it is useful to look at the luminosity histogram and not just the color histogram. The amount of luminosity detail that is lost (what the eye mostly sees as detail) is not as much as the red channel compression would imply.

This is all IMHO and thanks for sharing - quite interesting and useful.