Doug Kerr
Well-known member
Kevin Stecyk and I learned an important lesson recently in the area of color space conversion, and I wanted to discuss the issue for the benefit of others who may somehow have the same misconception Kevin and I did.
Suppose we have developed a raw file and are editing the image in Photoshop, holding it in an RGB color space with a larger gamut than sRGB (for example, Adobe RGB or ProPhoto RGB). Our central objective is to print the image out of Photoshop.
The image well exploits that color space, containing colors not in the gamut of sRGB.
However, we wish to also make an sRGB JPEG file, perhaps to post here. We ask Photoshop to do a color space ("profile") conversion to sRGB, selecting the perceptual rendering intent. Our thought is that a color space conversion under the perceptual rendering intent will map the entire source color space gamut "gracefully" into the destination color space gamut, avoiding any "clipping" of out-of-gamut colors (of course, at the expense of the "fidelity" of all colors in the image). [This is indeed the principal intent of the perceptual rendering intent.]
But in fact, this does not happen, and we end up with an sRGB JPG file in which there are a lot of pixels with one coordinate or another at 255 - jammed against the boundary of the (sRGB) gamut.
Andrew Rodney was kind enough to explain why. The reason is that the normal sRGB profile does not contain the tables needed to actually conduct mapping under the perceptual rendering intent. All it can support is absolute colorimetric and relative colorimetric rendering intents. Neither of these remap the colors so as to gracefully avert out-of-gamut clipping.
If we ask Photoshop to do the remapping under the perceptual rendering intent to a color space with such a profile, the relative colorimetric rendering intent is used instead.
Where then is the perceptual rendering intent actually supported? In output color space profiles (mostly for printers).
I am not skilled enough in image adjustment in Photoshop to make suggestions as to how one faced with the task I postulate above should best avert the problem. Others here will perhaps have suggestions in that regard.
Best regards,
Doug
Suppose we have developed a raw file and are editing the image in Photoshop, holding it in an RGB color space with a larger gamut than sRGB (for example, Adobe RGB or ProPhoto RGB). Our central objective is to print the image out of Photoshop.
The image well exploits that color space, containing colors not in the gamut of sRGB.
However, we wish to also make an sRGB JPEG file, perhaps to post here. We ask Photoshop to do a color space ("profile") conversion to sRGB, selecting the perceptual rendering intent. Our thought is that a color space conversion under the perceptual rendering intent will map the entire source color space gamut "gracefully" into the destination color space gamut, avoiding any "clipping" of out-of-gamut colors (of course, at the expense of the "fidelity" of all colors in the image). [This is indeed the principal intent of the perceptual rendering intent.]
But in fact, this does not happen, and we end up with an sRGB JPG file in which there are a lot of pixels with one coordinate or another at 255 - jammed against the boundary of the (sRGB) gamut.
Andrew Rodney was kind enough to explain why. The reason is that the normal sRGB profile does not contain the tables needed to actually conduct mapping under the perceptual rendering intent. All it can support is absolute colorimetric and relative colorimetric rendering intents. Neither of these remap the colors so as to gracefully avert out-of-gamut clipping.
If we ask Photoshop to do the remapping under the perceptual rendering intent to a color space with such a profile, the relative colorimetric rendering intent is used instead.
The difference between those two is that under the relative colorimetric rendering intent, the colors are remapped to take into account any differences between the white points of the source and destination color spaces; under the absolute colorimetric rendering intent, that is not done. The remapping for white point difference is done algebraically, and does not require any special table in the profile to guide it.
Where then is the perceptual rendering intent actually supported? In output color space profiles (mostly for printers).
Incidentally, the definition of the perceptual rendering intent is that it first remaps the colors to take into account difference in the white point of the source and destination color spaces, and then applies the "gamut compression" remapping to be certain that any color representable in the source color space has a credible home in the destination color space.
I am not skilled enough in image adjustment in Photoshop to make suggestions as to how one faced with the task I postulate above should best avert the problem. Others here will perhaps have suggestions in that regard.
Best regards,
Doug