26th
What they forgot to tell you about CM
Every advice about color management starts with the declaration that without a calibrated screen things will never quite work out. Well, hard to argue with that. And if screens were able to show all colors that the human eye is able perceive, or at least the subset that can be captured by digital cameras and scanners, starting out with a calibrated monitor should indeed make it possible to predict and control how our photos will look on other media (than our monitor).
Useless to say, most monitors have a gamut roughly that of sRGB, with cheap LCDs or laptop LCDs often even noticeably smaller than this and only the best monitors approaching Adobe RGB. Moreover, monitors are notoriously bad at displaying very dark blacks and have various other limitations (eg, maximum contrast or even 6 bit panels).
All this is well known, and color management is well equipped to deal with the shortcomings of display media, or rather it enables the users to deal with the shortcomings. It does this mainly by converting colors between different color spaces, most notably between that of an image (largely sRGB or Adobe RGB) and that of an output media (for anything on paper often of the CMYK type). It offers different rendering intents and on top the option of black point compensation (BPC) and a great deal is written about what this conversion entails.
A second type of conversion is usually given much less attention, the conversion from an image’s color space to that of the monitor. With raw conversion becoming ever more common, the mismatch between the color space in which images exist and are processed and the monitor color space can get quite large. However, information about how this gap is bridged is hard to find. By chance, I just stumbled upon a perfect test case which should provide us with some clues.
At http://regex.info/blog/2007-05-24/467, Jeffrey Friedl posted very recently an impressive photo of some very colorful flowers. Viewing the photo in a CM-aware application (eg, Photoshop, Preview, Aperture, etc.) an my 15” MacBook Pro (MBP) or my 20” Cinema display (CD) using the default Apple-supplied profiles shows strong colors with smooth gradients and almost no banding.
Using the profiles created by my monitor calibration device, the Huey, and CM-aware apps, reveals strong banding in the violet and pink flowers. Keeping the Huey profile, but using a non-CM-aware app (eg, Camino, Firefox), however, show very little banding. Comparing my Huey monitor profiles with sRGB (the one Jeffrey’s photo was defined in), reveals that both my MBP and CD have a smaller color space in respect to violet and pink tones than sRGB.
What is probably happening when using the Huey profile, is that the color management system (CMS), using relative colorimetric rendering intent, is clipping the out-of-gamut violet and pink tones, causing the posterization. Or, less likely in my view, using perceptive intent with a very agressive handling of out-of-gamut colors, CMS is compressing them into a very small range of tones which creates the appearance of posterisation and clipping.
The Apple-supplied profiles are for the violet and pink tones considerable larger than the Huey profiles and therefore do not require any or only very light clipping, assuming relative colorimetric rendering intent (and/or they entice the CMS to use perceptive). All profiles in question, one should note, have the tag ‘perceptual’ as preferred rendering intent. Using a non-CM-aware app, the monitor color profile is not used for any conversion, and the RGB values are sent straight to the graphic card, which also avoids the posterization.
Summarizing my conclusions and resulting questions:
1) At least with the Huey, color conversion from an image’s color space to the screen is done via relative colorimetric.
2) The Huey profiles have a smaller gamut than the default Apple ones. Any good reason why?
3) If true, working with images in huge color spaces (ie, when doing raw conversion) could on most screens very fast lead to posterization, although viewing the same photo on a high-gamut screen would not show it (and calibrating the screen with the Huey makes this worse). Or do raw converters work only internally with a huge color space but convert it down using some kind of perceptive rendering intent to a smaller one and then hand the result over to the OS’s CMS?
4) If the conversion from image to screen is done using relative colorimetric, is BPC enabled? I would guess so, but I would have to think that over (and hopefully come up with a test case to check it).
