Color space conversion - a caution

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

Doug Kerr said:

Neither of these remap the colors so as to gracefully avert out-of-gamut clipping.

Click to expand...

I’m not sure I’d say that (at least that strongly). There’s nothing inherently ‘better’ or worse using a Perceptual intent over a RelCol. The general advise when those tables are accessible is to view both and pick the one you prefer visually. Profiles and their associated rendering intents don’t know squat about images. A black dog on coal, a white dog on snow, a very colorful scene; a rendering intent treats them the same. You have to make the decision here when a decision is possible.

There is no standard way to map perceptually! That is, you can have two profiles built identically but using different manufacturers and the Perceptual Intent will be different. Just like two E6 films, one Velvia and the other Ekatachrome have different renderings when exposed identically to the same scene. Those film manufactures built renderings based on what they thought users would prefer. Its not much different with Perceptual tables in ICC profiles.

The Absolute Colorimetric intent is different; it is absolute (or its supposed to be).

Lastly, by the time the secondary profile “gets” the data for conversion, it comes from the PCS (Profile Connection Space) and is generally in Lab. That profile has no idea if the data converted into Lab was originally sRGB or ProPhoto RGB. There are yet no smarts here (although the ICC V4 spec is supposed to account of for these kinds of things). That the V4 spec which is many years old is by and large sitting and rotting on the vine is another issue.

Hi, Andrew,

Andrew Rodney said:

I’m not sure I’d say that (at least that strongly). There’s nothing inherently ‘better’ or worse using a Perceptual intent over a RelCol.

Click to expand...

I didn't say there was. There are disadvantages to both (I think I mentioned that).

But as I understand it, RelCol does the transform to accommodate differences in white point and beyond that, it's every pixel for itself (ones that fall outside the new gamut just get plastered to the boundary).

Is that not so?

The Absolute Colorimetric intent is different; it is absolute (or its supposed to be).

Click to expand...

Yes, indeed. It basically doesn't do anything (other than figure out how to place out-of-gamut colors on the boundary of the new gamut, likely by just clipping the afflicted coordinates).

Lastly, by the time the secondary profile “gets” the data for conversion, it comes from the PCS (Profile Connection Space) and is generally in Lab.

Click to expand...

Well, for many of the ones I have looked at, the PCS is XYZ.

That profile has no idea if the data converted into Lab was originally sRGB or ProPhoto RGB. There are yet no smarts here (although the ICC V4 spec is supposed to account of for these kinds of things).

Click to expand...

I understand.

Thanks for your inputs.

Best regards,

Doug

Doug Kerr said:

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.

Click to expand...

I suppose one could do either of these:

• Do not convert the color space before generating the JPEG file; leave it tagged with the color space that actually applies (Adobe RGB, ProPhoto RGB, etc.) If the receiving application can benefit from that, good. If the receiving app treats all JPEG files as sRGB, that will "work".

• Do not convert the color space before generating the JPEG file; tag it as being sRGB (a lie). That will "work".

Best regards,

Doug

Hi, Andrew,

Doug Kerr said:

But as I understand it, RelCol does the transform to accommodate differences in white point and beyond that, it's every pixel for itself (ones that fall outside the new gamut just get plastered to the boundary).

Is that not so?

Click to expand...

Upon further research in "the literature", I find that perhaps that is not the definition of RelCol.

I'm not sure what the definition is.

I'll read some more.

Best regards,

Doug

Is this of any use to you?
http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm

And not only the sort of conversion matters, but also how the conversion handles (or does not handle) blackpoint compensation.

Hi, Joey,

Joachim Bolte said:

Is this of any use to you?
http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm

Click to expand...

Yes, that is an interesting presentation.

Thanks.

Best regards,

Doug

For what it's worth: I mostly use RelCol with BP compensation. Gives good results most of the time. In some cases (especially in print output) I switch to Perceptual without BP compensation.

Don't really know the physics about this, but is works... I'm more of the empirical type.

Well, after a very little further study of the literature, I come to the following conclusion regarding the relative colorimetric rendering intent.

• I will limit my discussion to the sRGB profile. Profiles such as printer profiles introduce media considerations that complicate the discussion.

• I will speak of the image flow in the "PCS-to-sRGB" direction. (The profiles are symmetrical, and can be used in both directions, but the discussion will be less complicated if we assume a certain direction.)

For the benefit of readers not familiar with the concept of the PCS (profile connection space), the ICC color management model contemplates that the transformation of an image from color space "P" to color space"Q" is done (at least conceptually) by first transforming the image from color space "P" to a standard intermediate color space (the "PCS") (under control of the profile for color space "P"), and then transforming it from PCS to color space "Q" (under control of the profile for color space "Q").

The PCS can either be a certain form of the L*a*b* color space or a certain form of the XYZ color space, depending on the profile.

If the "first stage" profile transforms the image to, say, the L*a*b* form of the PCS, and the "second stage" profile expects an input in the XYZ form of the PCS, the color management engine makes an on-the-fly transformation from L*a*b* to XYZ (the transform for which is fixed and well defined).

Now, in the sRGB profile, there is a table (the "single table" spoken of by Andrew) which guides the mapping of colors from an XYZ PCS representation to an sRGB representation, following the relative colorimetric rendering intent (as Andrew mentioned). In doing this, it takes into effect the fact that the reference white for the PCS (D50) differs from the reference white for the sRGB color space (D65).

For most of this table, there is no design decision needed: the transformation from an XYZ representation of a color to the sRGB representation of the same color is well-defined. (There is the question of which algorithm to use for the reference white adaptation; I think the ICC spec prescribes the Bradford.)

But there are colors (XYZ values) that do not map to valid sRGB colors (are out of the sRGB gamut); that is, their sRGB representation would have values of one of more of R, G, or B that were less than zero or greater than 255.

So for those, the table must map the XYZ color to a valid sRGB color (presumably one at the boundary of the sRGB space), and the ICC specification does not prescribe how to do that. The profile developer might, for example, just decide that if the basic equations led to a value of 260 for R, the table would just make R=255, and this would have no effect on the other "destination" coordinates for this XYZ color (if they were in the range 0-255, they be kept as calculated). But maybe something "trickier" is done.

The bottom line is that, based on my current understanding, I stand by my earlier characterization of the behavior of the relative colorimetric rendering intent.

Best regards,

Doug

Hi, Joey,

Joachim Bolte said:

For what it's worth: I mostly use RelCol with BP compensation.

Click to expand...

Can you tell me while you are doing what? Is this in connection with the printer profile when printing out of PS? Or in connection with converting to another color space for a file?

Best regards,

Doug

Both... and with printing I use adapted color profiles depending on what paper and ink is in my printer.

Hi, Joey,

Joachim Bolte said:

Both... and with printing I use adapted color profiles depending on what paper and ink is in my printer.

Click to expand...

But, with regard to conversion of color space for files, we now seem to know that the choice of rendering intent likely does nothing, so how is it that you feel one or the other seems to be better in certain situations?

Best regards,

Doug

Doug Kerr said:

But as I understand it, RelCol does the transform to accommodate differences in white point and beyond that, it's every pixel for itself (ones that fall outside the new gamut just get plastered to the boundary).
Is that not so?

Click to expand...

All out of gamut colors are plotted to the edge of the gamut of the destination profile. So its every pixel for itself outside that gamut. Again, why get caught up in the theory, look at the image with both Perceptual and RelCol (even perhaps Saturation) and pick the one that appears best? Every image will be different.

Hi, Andrew,

Andrew Rodney said:

All out of gamut colors are plotted to the edge of the gamut of the destination profile. So its every pixel for itself outside that gamut. Again, why get caught up in the theory, look at the image with both Perceptual and RelCol (even perhaps Saturation) and pick the one that appears best? Every image will be different.

Click to expand...

I'm not at all "caught up in the theory". I just like to know what things do.

And you've helped me do that.

Best regards,

Doug

Well, just as if I knew what I was doing, I downloaded the beta version of ICC's V4 sRGB profile and installed it. If you want to do the same, it is available here:

http://www.color.org/srgbprofiles.xalter

This sRGB profile supports the perceptual rendering intent (maybe the saturation one as well - I'm not sure yet).

SO I'm taking a file in the Adobe RGB color space and converting it to sRGB using the various rendering intents supported by teh ICC V4 (beta) profile.

It should be fun.

Of course, the first observation is that for my file (which has a lot of red at the top of the histogram in the Adobe RGB space), when I convert it to sRGB under the perceptual rendering intent, the red does not "pile up".

Best regards,

Doug

Doug Kerr said:

Hi, Andrew,
I'm not at all "caught up in the theory". I just like to know what things do.

Click to expand...

Understood. But the key points to keep in mind is we are dealing with math that affects individual pixels (and in terms of Perceptual rendering, the math can vary a lot because there are no rules so to speak). We humans see color in context. The color science upon which current ICC color management exists was never really built to deal with images and at the time, Photoshop would have been considered science fiction. We need real appearance models to get closer to the goal of dealing with images as more a whole. So while its useful to understand how things work, in the end, you just have to look at that big pile of pixels of differing color values and decide what rendering intent you prefer. That’s one reason we have soft proofing.

IF you have a workflow where you cannot pick a rendering intent, then the discussion could move towards which intent should be used. Personally, with the profiles I build and with the images I work with, I usually prefer the RelCol intent but I’m happy I can occasionally pick Perceptual.

Here is the Photoshop histogram of the JPEG file still in the Adobe RGB color space:



Here is the histogram with the JPEG file converted to the sRGB color space using the relative colorimetric rendering intent* (ICC V4 sRGB profile beta):



Here is the histogram with the JPEG file converted to the sRGB color space using the perceptual rendering intent (ICC V4 sRGB profile beta):



Just about what we might expect.

Way cool!

Best regards,

Doug

Doug Kerr said:

Way cool!

Click to expand...

Agreed Doug, great work!

Doug Kerr said:

Here is the Photoshop histogram of the JPEG file still in the Adobe RGB color space

Click to expand...

But which rendering of the image do you prefer?

Hi, Andrew,

Andrew Rodney said:

But which rendering of the image do you prefer?

Click to expand...

For this particular file (if we limit ourselves to renderings into sRGB), with respect to the background wall, I prefer the perceptual rendering intent, as it does not lead to "R channel blowout"!

But as for the model and the bench, I prefer the medium-relative colorimetric rendering intent.

Overall, I prefer it left in Adobe RGB.

Best regards,

Doug

Andrew Rodney said:

But which rendering of the image do you prefer?

Click to expand...

Hi Andrew,

I understand what you are saying, it's the result that counts. However, why would anybody prefer e.g. clipped Reds instead of a more accurate tonal representation? Human vision is all about relative differences, which is exactly what perceptual tries to achieve.

IMHO the question should be (from the point of understanding the mechanism); How does the perceptual rendering intent change the in gamut colors when out of gamut (OOG) colors are detected, and when there are no OOG colors detected?.

In that light, the Granger rainbow chart and the "RGB16Million" file can help to get a feeling of where the troubles are waiting for us.

Cheers,
Bart

Andrew Rodney said:

Understood. But the key points to keep in mind is we are dealing with math that affects individual pixels (and in terms of Perceptual rendering, the math can vary a lot because there are no rules so to speak). We humans see color in context. The color science upon which current ICC color management exists was never really built to deal with images and at the time, Photoshop would have been considered science fiction. We need real appearance models to get closer to the goal of dealing with images as more a whole. So while its useful to understand how things work, in the end, you just have to look at that big pile of pixels of differing color values and decide what rendering intent you prefer. That’s one reason we have soft proofing.

IF you have a workflow where you cannot pick a rendering intent, then the discussion could move towards which intent should be used. Personally, with the profiles I build and with the images I work with, I usually prefer the RelCol intent but I’m happy I can occasionally pick Perceptual.

Click to expand...

Andrew

Nice to see you around again. I hope that you are well.

I too tend to prefer relcol for my printer profiles and use soft proofing as well as out of gamut colours can do ugly things with some profiles/intents.

However, my thought here is that this is actually a complex issue that is analagous to the compression of the real world dynamic range into a monchrome print (this applies in colour too, but then we often get away with flattening the dynamic range and replacing with colour contrast I think). When the dynamic range is compressed if we do so in a linear fashion we justend up with a flat print. As a result we often allow blacks to be crushed and (even - sorry Ansel!) whites to blow out. This gives us better mid tone contrast. A next step however is the careful use of increased local contrast in highlight and shadow areas to retain local separation even though the absolute levels may overlap midtones elsewhere in the image. This is a non-linear and image dependent process and cannot easily be automated - look at the flickr evidence on HDR tomemapping if you have any doubt. Applying this thinking to colour gamuts:

- automated profile conversion approaches are very unlikely to be optimum often
- sometimes all will give ugly outcomes - this often needs to be managed by local work on the image
- perceptual may well tend to compress colour gamuts and saturation if your working space is much bigger than output. You might not see this if your monitor doesn't have a wide gamut.
- there could be case that raw conversion into the intended output space would allow more efficient image optimisation
- Perhaps relcol is preferred by workers whose image gamuts are not much bigger (if at all) than their output (printer/ink/paper) gamut. I find the gamut on Ilford Gold Fibre Silk is sufficient for much of my colour work.
- Work in black and white avoids much of the problem

Mike

Bart_van_der_Wolf said:

Hi Andrew,

I understand what you are saying, it's the result that counts. However, why would anybody prefer e.g. clipped Reds instead of a more accurate tonal representation?

Click to expand...

Why are the reds clipped in the first place?

At least in ACR when processing from raw, you can see if the current encoding space will clip all primaries and even a combo of two. If so, change the encoding color space or alter the sliders if clipping is an issue.

If the image was shot JPEG in Adobe RGB (1998), and the colors are clipped, then they are clipped (shot raw).

Bart_van_der_Wolf said:

Hi Andrew,

I understand what you are saying, it's the result that counts. However, why would anybody prefer e.g. clipped Reds instead of a more accurate tonal representation? Human vision is all about relative differences, which is exactly what perceptual tries to achieve.

IMHO the question should be (from the point of understanding the mechanism); How does the perceptual rendering intent change the in gamut colors when out of gamut (OOG) colors are detected, and when there are no OOG colors detected?.

In that light, the Granger rainbow chart and the "RGB16Million" file can help to get a feeling of where the troubles are waiting for us.

Cheers,
Bart

Click to expand...

Missed this post Bart.

That was part of what I was driving at. It's easy enough to map a big space to a smaller space by simply compressing the gamut. Of course, there may well be some quantisation error, but it's unlikely to be an issue in practical terms if working with 16 (15) bit data. The net result is a desaturation of the whole image, but maintenance of some sort of relative difference.

A step further is to detect the colours that are actually out of gamut and use these to determine the maount of compression required to smoothly map the bigger (image gamut) into the smaller space. You might want to modify this to ensure that the colour balance isn't distorted - say weak reds and strong blues and green in Doug's example.

However, there could well be other situations where the less saturated colours are important and we need to map the out of gamut colours into the outer part of the smaller space non-lineraly. By increasing the colour contrastof these colours before compressing, and by compressing locally, you might achieve a visually better result. It would also be necessary to consider areas of image adjacent to the out of gamut areas and perhaps modify that, and then it could get very image dependent...

Mike


PS I'll probably play with some (photographic) chemicals this weekend. I feel some cyanotype coming on

Andrew Rodney said:

Why are the reds clipped in the first place?

Click to expand...

They aren't, but the conversion to sRGB clips them.

Look at the histogram of an image with lots of color in ProPhoto RGB or AdobeRGB, and convert to regular sRGB (e.g. for web publishing). Now look at the histogram (extremes) again ...

Doug showed an example allready.

The reason is obvious, clipping of OOG colors by the relative colorimetric intent default, but unwanted.

Cheers,
Bart

Bart_van_der_Wolf said:

They aren't, but the conversion to sRGB clips them.

Click to expand...

The top Histogram, labeled “Here is the Photoshop histogram of the JPEG file still in the Adobe RGB color space:“ appears to be.

Andrew Rodney said:

The top Histogram, labeled “Here is the Photoshop histogram of the JPEG file still in the Adobe RGB color space:“ appears to be.

Click to expand...

I'll give you another example, with pictures ;-):



The colorspace conversion, obviously clipped the OOG colors. You can guess which one is more accurate ...

It doesn't surprise me, but it's a pain having to work around it.

Cheers,
Bart

Andrew Rodney said:

The top Histogram, labeled “Here is the Photoshop histogram of the JPEG file still in the Adobe RGB color space:“ appears to be.

Click to expand...

Indeed. 0.05% of the pixels have R values of 255, our usual forensic hint as to clipping.

Best regards,

Doug

Hi, Bart,

Bart_van_der_Wolf said:

You can guess which one is more accurate

Click to expand...

And certainly, we can reasonably adjudge any transform to a gamut not supporting all the original colors as "less accurate" than the original. The most accurate way to transform is not at all.

But I think the theme of this thread (of late) is on the relative "merits", when for whatever reason we are impelled to convert to a color space not accommodating the source gamut, of:

• Mapping all colors exactly, except for pixels whose colors will not fit the destination gamut, and "plaster those pixels on the ceiling".

vs.

• "Compressing" the gamut, so that no pixels are "plastered on the ceiling", but none retain their original color either.

Best regards,

Doug

I have issue with the term “accurate” unless we are defining colors colorimetrically which I’m not sure this covers. In terms of the scene itself, nothing we’ve done after capture and raw conversion is accurate from this respect. Its hopefully pleasing to the image creator.

• Mapping all colors exactly, except for pixels whose colors will not fit the destination gamut, and "plaster those pixels on the ceiling".

vs.

• "Compressing" the gamut, so that no pixels are "plastered on the ceiling", but none retain their original color either.

Click to expand...

Yup, its ultimately an judgement call of which the image creator has to make (or ignore).

There is no question that having V4 working space profiles that provide options would be a good thing! And it would be useful if the process had some more smarts about what the PCS was given in the first place. My understanding is that at least with Perceptual renderings, the secondary profile has to be built with some assumptions as to the original color gamut, even when feed XYZ or Lab. The V4 spec introduces something called PRMG (In general, the PRMG, Perceptual Reference Medium Gamut is a reference gamut for rendering to and from conversions). Current conversions using a perceptual intent are not well defined with respect to the source gamut prior to making its way into the PCS, this is supposed to be a less ambiguous color space. One issue, one I suspect has held all this up for years and years (if you understand how long it takes committees to finalize stuff) the PRMG tag is optional. Its unknown if any of the current profile building solutions have the tag on or off or how they define the PRMG. Worse, current V4 output profiles have been problematic for users due to bugs in certain areas (using a V4 profile today in OSX with some applications produces ugly results on paper white).