CHROMiX

High Gamut Monitor and sRGB Image Editing

Hi all,

I’ve done a fair bit of reading on color management but wanted to get some feedback on a workflow issue I am having.

I have a Dell 30" high gamut LCD display and a 17" Mac Book Pro Display, both of which have been Calibrated and profiled with a Gretag Eye-One. I use Lightroom to manage and adjust RAW photos taken with my D70 and CS3 for more compex editing. I use AdobeRGB as my working colorspace in CS3.

Most of my work I share online, so I save images using sRGB profiles. For years I used dual CRT Viewsonic monitors, which had a profile slightly larger than sRGB, so when I was editing in AdobeRGB the color clipping that occured when saving to sRGB was not too significant as the display itself could not display much more than sRGB.

The problem I am running into now is using my Dell high gamut Monitor. If you look at the gamut plot of this display, it is virually identical to AdobeRGB. This is great ,as you see a lot more of your image, but I’m finding it problematic when I save my images to sRGB as the color shift is so signficant the original color edits are vastly affected.

When I used my old CRTs, or if I use my MacBook Pro display which has a profile that is slightly smaller than sRGB, the workflow is relatively simple, as througout the entire process what you see and what you export for all intents is within the range of sRGB.

So my question is what is the best way to deal with this? The only solution I can come up with is to export from Lightroom to CS3, soft proof the image to MonitorRGB in CS3 and tweak the colors before saving out to a JPG with an embedded sRGB profile. Obviously the is far from ideal.

Any thoughts or suggestions would be greatly appreciated.

Cheers,
Jeff

Hi Jeff,
I suppose there are different ways to handle your situation.
If it were me, and I wanted to share my work online, when I bring it into Photoshop I would assign sRGB to the image, do my tweaking, and then save out to jpeg with the embedded sRGB profile. This sounds like it’s close to what you’re talking about. With the sRGB assigned to the image in PS, you can see what changes sRGB will do to the image, but will leave the actual colors of the image intact.

I’d also want to save this “online” version of my image separately from my original; give it a different name. Maybe add “_sRGB” to the end of the filename or something.

If the image I bring into PS from Lightroom was exported with the the aRGB profile and my working space is aRGB, am I wrong in converting to sRGB when I save the image for the web? I thought you only assigned a profile to untagged images when you know or are making assumptions about the meaning of the underlying color numbers.

I’ve been doing some more testing and so far these have been my findings. I’d be curious to know if I am approaching this correctly.

  1. When I work on my high gamut display and convert to sRGB I see a pretty large shift in colors. What I have been doing is to open the aRGB image, make a duplicate in PS, and then convert it to sRGB. I then softproof to MonitorRGB and then adjust the colors of the duplicate sRGB image to match the colors of the original aRGB image, or as close as possible, then save it out for the web.

  2. Although it completely defeats the purpose of color management, I’ve found if I untag my aRGB image or leave the aRGB profile intact, when I view it in a non-color managed application it looks perfect on my high gamut display, as the gamut is pretty close to aRGB. However, it also looks just as good on my macbook pro display. I do understand that leaving aRGB assigned is ignored by non-color managed applications, my point is simply the images seem to look better on all of my displays when not color mananged.

Have I missed anything or is my knowledge flawed somehow? I thought when an image is coverted, the rendering intent will either clip or remap out of gamut colors to the target color space. It seems however the higher gamut display is reading color differently and somehow doing its own conversion.

Cheers,
Jeff

Late to the party. (Happened before, will happen again :wink:)

When you convert from AdobeRGB to sRGB, Photoshop will always use Relative Colorimetric intent. So out of gamut colors will be clipped. Thus creating a color shift. No way around it.
No different with a wide gamut screen or a ‘normal’ screen. Only differenece is now you see it happening :wink:

Why the image looks good without embedded profile?
My guess would be you are using either a non color managed browser, or (with an untagged image) use Safari.
Safari will assume monitor profile with an untagged image. A non color managed browser will send the image data to the screen “as is” (essentially the same).
In both cases an AdobeRGB image will look good on a wide gamut screen, since that’s close to AdobeRGB gamut.

It will look “okay” on the MBP display, since there’s no clipping. The colors will look less “vibrant” then they should however.

Assigning sRGB to an AdobeRGB image in PS will not alter the RGB data in the image, so you’ll have no clipping. However, you won’t have any accurate colors either :stuck_out_tongue:

If you are really critical about the colors for web, either use sRGB throughout, or softproof for sRGB, and bring colors into gamut before converting…

Alternatively, use a table based profile (as opposed to the normal sRGB profile, which is matrix based), so you can use a perceptual rendering.

Frankly, I don’t get the “I then softproof to MonitorRGB and then adjust the colors of the duplicate sRGB image to match the colors of the original aRGB image, or as close as possible, then save it out for the web.” part.
Don’t use a non color managed browser if you use a wide gamut screen!
You are in the minority (still) by using a wide gamut screen. If an image looks good in a non CM application on your screen, it will look like crap on a ‘normal’ screen.

I always embed an sRGB ICC profile in the images for web, and use a color managed browser (FF3). That way I see the images correct. For the rest of the world: One can hope :wink: