Color management 2 – workflow, profiles

Below can be seen the devices that participate in the color management workflow. Every device has its own color profile, and are connected by the CMS (btw, the Crystal Diamond Icons of KDE, of wich I used a few to create the drawing below are simply beautiful)

Color management workflow

Images mostly are created by digital cameras and scanners. Theese devices (or a lot of theese devices) append the color profile of the color space the image is taken in to the image file.

Image files can live well without embedded color profiles, but in a color managed workflow they should have one, because without it, the CMS won’t know how to treat them (files without embedded profiles are assumed to be sRGB). I mean if you are opening an image in an editor, the CMS – already having your display profile – are to make a conversion on the picture to the display profile for your being able to see the exact colors.

Actually, it is a bit more complicated. There is the so-called working space. It is not related to any of the devices, but it is the color space the image is during edit.

The process is the following: The image is first to be converted from the camera’s (scanner’s) color space to the working space (depending on settings, it is usually automatically done by the CMS). Every time the image is displayed, it is converted to the monitor’s color space. When printing, it is converted to the printers color space (printers usually have many color spaces (for every paper that can be used in a given printer there is usually a printer profile for every printing quality)). When saving, it is up to the user to choose a color space to save the image in (and the profile for that color space is then appended to the image file).

Different outputs may require different color spaces. For instance, when saving an image for web the best practice is to save it in sRGB color space. sRGB is a standard color space in use today that serves as a profile for the “standard” desktop monitor. This is the color space used for most consumer digital cameras and most “non-professional” workstation monitors, and represents most of what you see on the web. In comparison with other color spaces, it’s gamut is slightly narrow. When saving an image for further editing, sRGB – because of its narrow gamut – may be a bad choice, because you can lost colors. Let’s see why.

Color spaces

There are three types of color spaces, according to their gamut.

Small-gamut spaces have gamuts comparable to CRT monitors. sRGB is the default color space for the www.

Medium-gamut spaces have gamuts somewhat larger than CRTs; comaprable to high quality (more than 4-color) inkjet printers. Adobe RGB (1998) is the most widely known.

Wide-gamut spaces have gamuts much larger than CRTs or inkjet printers, sometimes comprising colors the eye can’t see. ProPhoto RGB is an example. Since half or less of the total gamut can be reproduced on monitors or printers, using a wide-gamut space sacrifices bit depth. (in the case of ProPhoto RGB and 24 bit, the number of colors is 16,7M, but a few million of theese is outside the range that monitors and printers can reproduce. And even if future technologies can show you theese colors, you won’t see most of them, as they lie outside the visible range too).

Conversion methods

The heart of color management is the conversion or gamut mapping between color spaces. Gamut mapping is performed with one of the four rendering intents (gamut mapping algorithms) recognized by the ICC standard. The rendering intent determines how colors are handled that are present in the source but out of gamut in the destination.

Perceptual. The gamut is expanded or compressed during conversion between color spaces to maintain consistent overall appearance. Low saturation colors are changed very little. More saturated colors within the gamuts of both spaces may be altered to differentiate them from saturated colors outside the smaller gamut space. The only rendering intent that is at least mostly reversible. Generally recommended for photographic images.

Relative Colorimetric. Maps all out-of-gamut colors to the closest in-gamut color. The white point of the original gamut is moved to the white point of the output gamut and all colors maintain their relative position to the white point. Maps all out-of-gamut colors to the closest in-gamut color while maintains hue and lightness at the expense of saturation.

Absolute Colorimetric. Similar to Relative Colorimetric except that it does not necessarily map white in the source to white in the target.

Saturation. Maps the saturated primary colors in the source to saturated primary colors in the destination, neglecting differences in hue, saturation, or lightness. For block graphics; rarely of interest to photographers.

Working color space

Working space is the color space in what the image “lives” during processing. It has to match both the input and the output device’s color space.

A good option here is to choose a space that is comparable to (I mean, bigger, but not much bigger than) the color space of the output device.

For the input device, if it is a digital camera, than if you shoot jpegs, than the color profile of the images is most likely to be sRGB, or Adobe RGB (1998), so a medium gamut working space will do.

The situation is completely different, if you shoot raw. Raw is not a color managed format, but that does not mean that it wasn’t shot in a certain color space. It just does not contain it. Your digital camera has its own color space (or can has more, as image sensors behave differently under different lighting condition (fluorescent or tungsten)). At the input stage of your workflow, you should assign your raw images with the appropriate color profile of your camera. Noticed that I said “assign” and not conver to? It is because the file is – literally – already in your camera’s space (it was taken with your camera, wasn’t it?, just it does not contain any information about it), but the CMS won’t know it as long as you explicitly don’t tell it, by assigning the profile with the file. Raw converters usually do this automatically (they read the camera model from the EXIF metadata, and assign an appropriate profile (if have one)), so when your raw file gets converted to some other filetype wich can have an embedded color profile, it will be converted from the color space of the camera to the color space you choose.

But. CCD and CMOS image sensors usually has wide gamut color spaces, with parts that can’t be reproduced (and percieved). You can choose to convert it to another wide gamut color space, or to a medium gamut one. As I mentioned above, choosing a wide gamut color space for working space can lead to loosing information. But on the other hand, if the input is in a wide gamut space, converting it to a medium gamut space will lead to loosing info too. Web-wide arguments are going on on wether to use wide gamut spaces for working space or not. In my view, using wide gamut color spaces for working space only makes sense in the case of high bit depth images (and most raw files are 36 or 48 bit depth anyway, so why downsample them?). In the case of a 24 bit file, an image may suffer visible loss as the result of the conversion.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: