Color Management in a Nutshell

Let’s start on Color Management (wiki) with having a look a the general principles. We’ll see how to put them in practice (on Linux) in other posts. While Color Management principles are not that hard to understand, the technicalities of implementation certainly are! And we won’t get there since I don’t know too much about it.

Did you ever saw a nice picture on your screen and found a green-yellowish output from your printer? Then carry on reading 🙂

The idea behind Color Management (CM) is to define colors in a device-independent way, that is: what you have on your screen would look (as much as possible) the same on someone else’s screen or printed on your printer. Think about the problem this way: the “most green” color on your screen can be quite different from the “most green” color on your printer, so how do we cope?

Well, in order to cope, CM uses “ICC profiles” – for International Color Consortium who defined the standard. This word really covers 2 different things:

1. a reference (or editing) profile – an “objective” way to describe color.
2. a device profile – a description of how one device (camera, screen, printer) sees color.

Since a picture is worth a thousand words, here is a little drawing of a typical amateur photographer’s CM flow:

I hope all of this starts so make some sense…

First, when you take a picture, your camera sensor sees colors in its own way – so the color output of the sensor is being converted to a reference profile (all this is done in camera) which can be either AdobeRGB or sRGB (you should find the switch somewhere in the menus).

sRGB is a relatively small reference profile in the sense that it doesn’t define a wide choice of colors – the “most green” is not “very green”, if you see what I mean. By the way, this “area of color defined” is called “gamut”. So sRGB has a relatively small gamut which corresponds to the color nuances that the average computer screen can show. You want to use sRGB for things like web-publishing.

For more serious photography, however, the best choice is AdobeRGB which has a wider gamut, especially in the green. AdobeRGB’s “most green” is a lot “more green” than sRGB’s “most green” – still see what I mean?

From there, you have your image in a reference profile, an “objective way to describe color”. When you get back home and show your image on your computer screen, the Color Management System (CMS) translates on the fly the image’s colors to show them as close as possible to their AdobeRGB values on your monitor. Now remember that AdobeRGB has a wider gamut than what your monitor can show, so there are some compromises there. And these compromises are defined in the screen’s icc device profile.

Well, not quite. Just to make matters a little bit more complicated, the screen’s ICC device profile only describes the screen’s gamut. The CMS has then “policies” which describe how the conversion is done – and you have two main policies to cope with translating the wider AdobeRGB gamut to your screen’s gamut:

1. perceptual – where basically you shrink every color of your image to make them fit into the smaller gamut. The advantage is that the color nuances are respected and the overall look of the image is as close as possible. The disadvantage is that you loose saturation – your image looks a bit flat because of the averaging.
2. relative – where you bring back all the colors that are outside the gamut to the nearest color inside the gamut. The advantage is that you keep the saturation. The disadvantage is that you can start seeing unaesthetic flat zones (without detail) in the most saturated areas.

Compromise means just that: you have to loose somewhere.

However and that’s the beauty of CM, when you make (color) changes to your image, you make theses changes in the “objective” AdobeRGB profile that is rendered as closely as possible on your monitor. If you change your monitor (or graphic card), your image is still in AdobeRGB, so all you have to do is change the rendition on the monitor – get a new monitor ICC profile (we’ll see how to do that in another post). And if you see your image on another computer, it won’t be b0rked either. How nice is that?

And where all of this brings tears in my eyes (almost) is when it comes to printing: just like the monitor, the printer has an ICC profile that describes its gamut. So when you print your image, the AdobeRGB defined image is being translated into your printer’s gamut (as defined by its ICC profile and the policy – just a test to see if you are still following) for the printing. You have an image that is as close as possible to your AdobeRGB original whether on your monitor or when printed. Yes, it matches, no more yellowish-greenish output 😀

Obviously, we do this conversion on a copy of the image (or on the fly in the printer driver). Our real image (the one we archive) is the AdobeRGB one. One last word about printing: a printer’s gamut is very small compared to AdobeRGB. So compromises here will hurt a lot more than on the screen 😦 We will see details about monitor and printer calibration (the art of producing valid ICC profile) on Linux in other posts, but be warned.

Hey, just before closing and because today was all about colors, here is a beautiful parrot from the Parc des oiseaux in France. Enjoy.