Color Management: A Question of Intent
A Color Management System's job in life is to translate between color spaces by means of their associated color profiles. Whether we are talking about an input profile for a film scanner, a display profile for your monitor or an output profile for a device such as your printer, the profile lets the Color Management System know everything it needs to about the characteristics of the color spaces it is converting between. It doesn't have information in it for every possible color since this would make the profile file well over one gigabyte in size, but it does have information on enough significant points that the CMS can interpolate the rest.
So long as all colors in the source will fit within the gamut of the target space, everything works out as you would expect. All the CMS has to do is to pick the target RGB values that correspond to each source color. A particular red may have different numerical values in each color space, but so long as it exists in both, no problem.
Things get a bit more complicated though when things don't fit. Suppose the source space is something like Adobe RGB 1998 that has a fairly wide color gamut, but you are converting to a color space with a much more restricted range of colors such as sRGB for web display. We have to make some compromises. And thus the question of Intent come up. Rendering Intent, that is.
The concept of Rendering Intent is fairly straightforward, but the terminology gets a bit confusing. Put simply, an ICC-compliant Color Management System knows four different strategies for dealing with situations where not all the colors will fit. Rendering Intent is the name we give to those various strategies, and each of the four has its own somewhat confusing name. In their ICM implementation, Microsoft has attempted to give them more descriptive names, but personally I'd suggest sticking with the standard names since that's what the rest of the world uses. Of these four, you will likely find that only two of them are all that useful for photographic work, but it's good to understand what all four do, if for no other reason than it lets you impress your friends at parties. Well, perhaps not. Still, let's look at all four in turn:
Relative Colorimetric Intent will map all out-of-gamut colors to the closest in-gamut color. Regardless, all in-gamut source colors will remain unchanged (visibly unchanged that is — the actual RGB numbers will change of course). Thus, colors beyond the gamut will "build up" at the edges of the gamut. So long as there are no critical tonal gradations that would thus be lost, and so long as there is not a significant amount of such colors, the resulting image will be a close match to the source image. If you do have a lot of out-of-gamut colors, you can end up with a "banding" effect in colors at the edges of the gamut. Relative Colorimetric is often an excellent choice since it preserves as many of the original colors as possible. It is known as the Proof Intent by Microsoft.
Perceptual Intent does things rather differently. If it needs to deal with colors outside the gamut, it will remap all colors to essentially "compress" the overall gamut across the entire image. Thus colors that were inside the gamut will become less saturated as everything shrinks inward towards neutral and away from the saturated colors that are at the edges of the target gamut. This will have the effect of preserving all tonal gradations and avoid the potential banding problem of the RC Intent, but at the cost of desturating the entire image to a degree. Sometimes people convert with Perceptual Intent and then pump up the saturation to compensate for the loss of punch they see in the results. This might work if done very selectively, but more often than not they end up blowing out some of the gamut "edge" colors, creating the same banding problem that Relative Colorimetric would have given them in the first place. Microsoft has decided that Picture Intent is a better name, but I really can't see how.
Absolute Colorimetric Intent (known by Microsoft as Match Intent) is similar to Relative Colorimetric except that it does not necessarily map white in the source to white in the target. If the source color space had a relatively cool white point, then blue/cyan is actually added to white in the result to keep white the same color. Since our eyes naturally adapt to the white of the target space though, adding this extra color artificially limits the range of possible colors in the result with little benefit. If you are proofing your image on one printer when it will ultimately be printed on another, this may actually be useful. For regular desktop printing though, stil with Relative Colorimetric or perhaps Perceptual.
Lastly, Saturation Intent is a strategy sometimes used for business graphics that primarily need vibrant colors, even if those colors aren't the ones originally intended. It attempts to preserve the saturation of input colors, even at the expense of hue and lightness and is thus not very useful for photography. Microsoft has decided to confuse the world by referring to it as the Graphic Intent.
If every color in your source will fit within the target, every Intent should give the same results (barring minor differences such as the white point for Absolute Colorimetric that is). The only way in which they differ is in how they deal with images that have colors that won't fit in the target. Suffice it to say, if you have an image that contains a large amount of extremely saturated colors, no matter which Intent you choose you are in for an exercise in frustration as the CMS will have a hard time dealing with mapping source colors into a smaller target gamut. Your best bet is to never get into that situation in the first place if you can avoid it. This is one of the main reasons why a large gamut working space such as Adobe RGB 1998 comes in handy.
Current versions of both Microsoft Windows and Apple Mac OS include bundled color management capabilities. Color Sync has been around on the Mac for some while now. Under Windows, ICM is somewhat newer but does all the same things as ColorSync does. If you use Adobe Photoshop to edit your images, you also have a CMS built in to it so you may actually have two Color Management Systems to choose from. All of these Color Management Systems should be ICC-compliant so it shouldn't matter too much which one you choose. Things can be a bit confusing though since this often results in having more than one choice in how you do things. Even though all these color management systems may be ICC-compliant and thus capable of doing the same things, that's no guarantee that they do things the same way, if you get my meaning.
Next week, we'll look at some practical examples to help address which of these various options is most useful.