Please help me understand color!

wellman · May 14, 2009

I once saw color management referred to as a black hole. I think I agree now...

OK, some background. I process my RAW files in Lightroom 2.3 running on 32-bit Vista. I view things on a Huey-calibrated LCD. Other than the Huey, there's nothing "extra" going on color-wise on my machine.

Now for the image... In the questions below, I'll discuss the photos by number, with #1 being the upper left photo.

Things to note...

Photo #4 is the view I get from LR. This (on my monitor anyway) is my intended develop.
Photos #1-3 are LR JPG exports in sRGB, Adobe RGB, and ProPhoto RGB, respectively. They're being displayed in Windows Photo Gallery, which appears to be color-managed.
- Notice how the red jacket is quite muted in #1. I assume this is due to sRGB's reduced gamut in reds?
- The Adobe RGB shot (#2) is closer to the LR view.
- The ProPhoto RGB shot (#3) is, to my eye, the same as the LR view.
Now notice the three thumbnails below (images #4-7). These are the thumbnails for images #1-3. A few interesting things...
- They look the same! I perceive no difference among them.
- They're super-saturated in comparison with the color-managed Windows Photo Gallery views.
When I view images #1-3 in Firefox with color management enabled (via the gfx.color_management.enabled option in about:config), all three images show up properly - they look like the images from Windows Photo Gallery.
When I view images #1-3 in Firefox with color management disabled (the default):
- Image #1 (sRGB) looks like the thumbnail - way oversaturated
- Image #2 (Adobe RGB) looks flatter than Image #1 - we all know this happens when Adobe RGB is interpreted as sRGB.
- Image #3 (ProPhoto RGB) looks horrid, as expected w/o CM enabled.

So, my big question...

I get that Adobe RGB and ProPhoto RGB are wider than sRGB, and that's why the red jacket has more color fidelity in those images when viewed through a CM-enabled viewer. However, I don't understand why even sRGB images have to be viewed through a CM-enabled viewer to render properly. Again, the sRGB output above looks very close to LR (#4) when viewed through Windows Photo Viewer or CM-enabled FF3. But it looks super-duper saturated (and with messed up skin tones) when viewed as a thumbnail, through non-CM-enabled FF3, or even in a non-CM'd viewer like FastStone. What gives? Why do I need CMS to see an sRGB image properly on a calibrated monitor? Because I know my friends/family don't have CM-enabled FF, much less a calibrated monitor. (Have I beat that horse sufficiently?

)

One more caveat... Depending on your setup, my screenshot may not show the colors I intend. (The differences between colors are still there, but the baselines differ.) Viewed through non-CM'd FF, the screenshot looks OK. Viewed through CM'd FF, it looks yellowed, as if it's been doubly CM'd.

Help!:huh And thanks...:D

jfriend · May 14, 2009

wellman wrote:

I once saw color management referred to as a black hole. I think I agree now...

...

I get that Adobe RGB and ProPhoto RGB are wider than sRGB, and that's why the red jacket has more color fidelity in those images when viewed through a CM-enabled viewer.

However, I don't understand why even sRGB images have to be viewed through a CM-enabled viewer to render properly. Again, the sRGB output above looks very close to LR (#4) when viewed through Windows Photo Viewer or CM-enabled FF3. But it looks super-duper saturated (and with messed up skin tones) when viewed as a thumbnail, through non-CM-enabled FF3, or even in a non-CM'd viewer like FastStone. What gives? Why do I need CMS to see an sRGB image properly on a calibrated monitor? Because I know my friends/family don't have CM-enabled FF, much less a calibrated monitor. (Have I beat that horse sufficiently? )

Help! And thanks...:D

Very simple. Your monitor is not sRGB (none are). In fact, today's wide gamut monitors are even further from sRGB than some older monitors. Calibirating a monitor does NOT make it into an sRGB monitor. Instead, it profiles the colors that the monitor actually displays when given various inputs and puts those into the monitor profile so that color managed software can use those mappings to display accurate color. It is a common misconception that "calibrating" your monitor makes it so that even non-color-managed software displays accurate color. This is not the case.

Thus, when a non-color-managed app just dumps the sRGB bits to the monitor with no color profile transformations, you are essentially displaying your image in the color space of your monitor which is not sRGB. Thus, you do not get accurate color. The further apart your monitor colorspace is from the actual colorspace of the image, the worse off the non-color-managed view will look.

Accurate color will only come when you have an appropriately color-space tagged image being displayed on an accurately profiled monitor by color-managed software.

wellman · May 18, 2009

John,

Thanks for the lengthy reply. I've been ruminating over your points, and I think I'm starting to understand.

Now one more question for you... Why do my "Exports" from Lightroom (Library module) have a different color cast than "Prints to JPG" (Print module)? Both are being output to sRGB. Thanks.

-Greg

jfriend · May 18, 2009

wellman wrote:

John,

Thanks for the lengthy reply. I've been ruminating over your points, and I think I'm starting to understand.

Now one more question for you... Why do my "Exports" from Lightroom (Library module) have a different color cast than "Prints to JPG" (Print module)? Both are being output to sRGB. Thanks.

-Greg

I don't know. When I compare my own image with Export and with Print to File, I also see a difference. The Print to File image is less saturated. Both are JPEG. My guess is that print to file is doing something additional to prepare the file for printing that isn't being done in a straight export. I notice that Print to File gives you control over rendering intent whereas Export does not. I never use print to file. The only reason I could imagine doing so is if I wanted to prepare a proof sheet as a JPEG or something like that.

pathfinder · May 18, 2009

The rendering intent will remap the color to fit within the gamut of the printer's inkset, won't it? Export to jpg does not include any rendering intent.

I do not use print to file either, I print directly from Lightroom so I haven't really noticed this, but I suspect the rendering intent is what is going on.

jfriend · May 18, 2009

pathfinder wrote:

The rendering intent will remap the color to fit within the gamut of the printer's inkset, won't it? Export to jpg does not include any rendering intent.

I do not use print to file either, I print directly from Lightroom so I haven't really noticed this, but I suspect the rendering intent is what is going on.

I was thinking something like that too except that even converting to sRGB JPEG in the Export function has to involve a rendering intent. It's ProPhotoRGB inside of LR and that can contain colors that an sRGB JPEG cannot contain so it has to have a rendering intent too, even though it doesn't appear to be exposed to the user. A few Google searches imply that LR uses the Perceptual rendering intent upon export, but nobody seems to know for sure. I'm still not sure why the two are different.

pathfinder · May 18, 2009

Yes, I can see that there must be something done to convert the ProPhoto data down to sRGB, so there would be some sort of conversion going on.

That would not necessarily mean the rendering engine is the same when the file is dedicated to the printer though, does it?

jfriend · May 18, 2009

pathfinder wrote:

Yes, I can see that there must be something done to convert the ProPhoto data down to sRGB, so there would be some sort of conversion going on.

That would not necessarily mean the rendering engine is the same when the file is dedicated to the printer though, does it?

Yeah, but as best I can tell "print to file" doesn't really have anything to do with a printer. There does not appear to be any specification of what printer it's going to so it appears to me to just be "save this layout that you would have printed to a JPEG" so you can post it online or print it later using other printing software. I think it's just a hack so that the layouts available in the print module can be saved to JPEG and either sold online or printed through a commercial printer.

Thunder Rabbit · May 18, 2009

Howdy.

Greg wrote:

Now one more question for you... Why do my "Exports" from Lightroom (Library module) have a different color cast than "Prints to JPG" (Print module)? Both are being output to sRGB. Thanks.

I'm a color management knucklehead, and I may be talking through my hat here, but I've had a similar problem, and the solution had nothing to do with my color management. Or lack thereof.

I noticed that my jpgs exported from Lr were looking over saturated and in some cases over sharpened. But only when I viewed the images in Lr or Bridge/ACR. When I viewed them in Windows Photo Gallery, they looked fine.

As it turns out, this had to do with my XMP settings. If you export as jpg and don't minimize the XMP data, the develop settings are exported with the jpg. And if you view the jpg in an application set to read XMP file car files, in this case Lr or Bridge/ACR, they reapply the develop settings to the preview, even though they have already been applied when the jpg was rendered on export from Lr. They looked funny because my develop settings had been applied twice.

When you "print to jpg", there is no opportunity to apply the settings twice. It doesn't export XMP data with the jpg. And they will look different from "export to file". Which will apply them twice, since my file preferences are set to read XMP files.

I just ignore it, because I know the original jpg file is fine. It's just that Lr is stupid enough to do just what I told it to do. It sees the XMP file and applies it to the preview. It has no way of knowing that they've already been applied during the rendering of the jpg on export. When you export from Lr, if you check the "minimize embedded metadata" box, this doesn't happen. Lr doesn't see an XMP file, and renders the jpg normally.

This may have nothing to do with your problem, but you might check it out.

wellman · May 18, 2009

Thunder Rabbit wrote:

Howdy.

I'm a color management knucklehead, and I may be talking through my hat here, but I've had a similar problem, and the solution had nothing to do with my color management. Or lack thereof.

I noticed that my jpgs exported from Lr were looking over saturated and in some cases over sharpened. But only when I viewed the images in Lr or Bridge/ACR. When I viewed them in Windows Photo Gallery, they looked fine.

As it turns out, this had to do with my XMP settings. If you export as jpg and don't minimize the XMP data, the develop settings are exported with the jpg. And if you view the jpg in an application set to read XMP file car files, in this case Lr or Bridge/ACR, they reapply the develop settings to the preview, even though they have already been applied when the jpg was rendered on export from Lr. They looked funny because my develop settings had been applied twice.

When you "print to jpg", there is no opportunity to apply the settings twice. It doesn't export XMP data with the jpg. And they will look different from "export to file". Which will apply them twice, since my file preferences are set to read XMP files.

I just ignore it, because I know the original jpg file is fine. It's just that Lr is stupid enough to do just what I told it to do. It sees the XMP file and applies it to the preview. It has no way of knowing that they've already been applied during the rendering of the jpg on export. When you export from Lr, if you check the "minimize embedded metadata" box, this doesn't happen. Lr doesn't see an XMP file, and renders the jpg normally.

This may have nothing to do with your problem, but you might check it out.

Thanks for this info - definitely good to know. However, it's not explaining this particular issue. Minimized XMP or not, I'm still seeing a different JPG when I export versus when I print to file from the Print module.

Here's why this matters to me... I may be using a LR layout to build a book. Here's a potential example page. It just bothers me to see different colors in the exported image than what I see in LR itself. (For what it's worth, images look the same throughout LR's modules.)

Any other ideas? Thanks for the good discussion.

wellman · May 18, 2009

wellman wrote:

John,

Thanks for the lengthy reply. I've been ruminating over your points, and I think I'm starting to understand.

Now one more question for you... Why do my "Exports" from Lightroom (Library module) have a different color cast than "Prints to JPG" (Print module)? Both are being output to sRGB. Thanks.

-Greg

Just an FYI... Here's an example of the difference between exported JPG and "print to file" JPG...

Exported (looks like in LR):

Printed to file (looks different - more pink):

Thunder Rabbit · May 18, 2009

Howdy.

Well, it was worth a shot. It must be something that John and Pathfinder were talking about.

All I know about color management is how to spell it. (It is spelled right, isn't it?) But, out of curiosity, I exported an image out of Lr and then printed it to file out of Lr (rendering intent set to "Perceptual"), and they were identical when viewed in any application I tried. Including Windows Photo Gallery. But you and John do get a difference. This tells us something, but I don't know what.

Anyway, that's all I got.

wellman · May 19, 2009

Another data point... If I select my monitor's ICC profile as the export profile when printing to JPG from the Print module, the resulting JPG looks exactly like the LR view and the sRGB export from the Library module. What do you think?

wellman · May 19, 2009

Thunder Rabbit wrote:

Howdy.

Well, it was worth a shot. It must be something that John and Pathfinder were talking about.

All I know about color management is how to spell it. (It is spelled right, isn't it?) But, out of curiosity, I exported an image out of Lr and then printed it to file out of Lr (rendering intent set to "Perceptual"), and they were identical when viewed in any application I tried. Including Windows Photo Gallery. But you and John do get a difference. This tells us something, but I don't know what.

Anyway, that's all I got.

What platform are you on?

arodney · May 19, 2009

IF the device that's building the profile for the display is building a V4, not V2 profile, that's the issue with Lightroom. It has issues with the newer V4 spec. Test this by substituting a canned display profile from the OS if possible (under OS X, you can roll your own with the display calibration software in the system preferences). Don't keep that profile, you want an instrument based profile. But I suspect the product you're using is building a V4 profile (as the manufacturer).

Thunder Rabbit · May 19, 2009

Howdy.

I'm running Windows Vista, 32 bit.

wellman · May 19, 2009

Thunder Rabbit wrote:

Howdy.

I'm running Windows Vista, 32 bit.

OK, me too.

wellman · May 19, 2009

arodney wrote:

IF the device that's building the profile for the display is building a V4, not V2 profile, that's the issue with Lightroom. It has issues with the newer V4 spec. Test this by substituting a canned display profile from the OS if possible (under OS X, you can roll your own with the display calibration software in the system preferences). Don't keep that profile, you want an instrument based profile. But I suspect the product you're using is building a V4 profile (as the manufacturer).

Not sure whether this is what you're talking about, but I found something interesting... Printing to JPG with the default sRGB option gives different results compared with selecting sRGB IEC61966-2.1. The latter gives results identical to the sRGB export from the Library module.

Examples: http://wellman.smugmug.com/gallery/8259878_yVqye#540446901_utAfo

Please help me understand color!

Comments