Colour management is a topic that continues to confuse, bewilder, confound, and even enrage all too many innocent users. This is due in part to misleading hype on the part of vendors that present it as a magic solution to all colour problems, and in equal part to software developers who insist on making their implementation of colour management different from everyone else's. But if you understand what colour management systems actually do, it's a lot easier to see through the hype -- and to decode the dialog boxes that pop up to annoy you in your favourite applications.
Colour management systems really do only two things: They describe the colour of pixels, and they change the values of pixels to keep the colour consistent across different devices. That sounds simple enough, but anyone who has played the great Japanese game of Go can tell you that very simple rules can create an extremely deep and complex set of behaviours. And so it is with colour management.
Colour management systems were designed to resolve issues like "why doesn't the image my scanner captures look like the original when I display it on my monitor?" and "why does the image displayed on my monitor look nothing like what comes out of my printer?" (If you've never suffered from either of these problems, you can skip the rest of this column, but we'd all like to know your secret!). To understand how colour management addresses these issues, we need to look at what causes them in the first place.
The Problem
Computers don't understand colour Fundamentally, they are adding machines that juggle ones and zeros on demand. When we started using those ones and zeros to represent colour on computers, we did so by creating digital equivalents of the RGB (red, green, blue) or CMYK (cyan, magenta, yellow, black) analogue signals used to control the various colour computer peripherals, such as scanners, monitors, printers, image setters, and plate setters.
RGB and CYMK are each systems that in essence allow three or four primary colours to be blended to create a desired colour The strength of each component signal determines how much of the corresponding primary colour is used. When we adapted RGB and CMYK for representing colours digitally, we simply used numbers (8-bit numbers, which allowed 256 levels) to represent the strength of each component value.
This system works fine when you simply want to make a specific device produce a colour Unfortunately, when you send the same set of RGB or CMYK values to different devices, they typically produce different colours RGB and CMYK represent control signals rather than specific colours, and each device responds differently to the control signals.
If you've ever watched a bank of televisions in an electronics store or peered down the length of a 757 during the no-doubt-engrossing inflight movie, you've probably seen this phenomenon in action: Multiple monitors, all receiving the same signal, produce different colours Why? RGB values modulate the strength of the electron beam that makes the monitor's phosphors glow, emitting light, and each monitor responds differently to the control signals. Different vendors use different phosphor sets, but that's only part of the problem. The phosphors wear unevenly, losing the ability to emit light, and the monitor's brightness and contrast controls, which are set by the user, have a huge influence on the colour the monitor displays. It's not unreasonable to say that each monitor is unique. (Which also means that the images used in this story to demonstrate my point will also appear different on your monitor than it does on mine, but even if the representations aren't exact, I think you'll get the idea.)
For slightly different reasons, the same holds true for all our other RGB and CMYK devices. Scanner and digital camera filters change with age and differ from model to model, as do the light sources they use. CMYK may be even more variable than RGB: There are many different formulations of CMYK inks, toners, waxes, and dyes, all differing in their colours, and when you bring the paper into the equation, you encounter another huge variable, given that different papers interact with the inks in very different ways.
You can think of RGB and CMYK as recipes for making colour, with the distinct R, G, B or C, M, Y, K values being the ingredients. As any cook can attest, ingredients vary, and that variation affects the final flavour of the dish. So it is with colour: Yes, you can be confident that, say, R255, G255, B50 will create a shade of yellow, but that shade will certainly be different on different devices.
RGB and CMYK are often called device-specific or device-dependent colour models, precisely because they really only produce predictable results for a given device. This is the fundamental problem that colour management seeks to address. The second, more-obvious problem stems from the first: Colour changes when we send our files from one device to another, so the colour the scanner sees doesn't look like the colour we see on the monitor, which in turn doesn't look like the colour that comes out of the printer.
Figure 1: The scanner sees the colour sample as R247 G160 B91. But when we send the same RGB values to the monitor, it's slightly darker and more saturated. When we send those same numbers to the printer, it's much darker and even more saturated
Colour management systems try to solve both these problems -- ambiguous colour and unstable colour -- using three components:
- A reference colour space that represents colour as we see it.
- Device profiles, which describe a device's colour behaviour.
- A colour engine, which is a piece of software that does the actual work of matching colour from device to device.
Each of these components plays a key role in keeping colours consistent across devices.
Reference Colour Space
- LAB is a straightforward mathematical equivalent of XYZ
- Both XYZ and LAB represent colour in terms of human perception, rather than in terms of the control signals we use to make a given device produce colour In other words, both colour spaces let us specify the colour a human with normal vision can see. As a result, XYZ and LAB values define colour unambiguously, unlike device-dependent colour models such as RGB and CMYK.
Device Profiles
Device profiles provide us with descriptions of the way our colour devices behave.
Profiles are useful in two ways:
- When we associate a device profile with a set of device-specific RGB or CMYK colour values, we can use the profile to determine what actual colour the values represent (in XYZ or LAB).
- When we know the actual colour we're trying to reproduce (in XYZ or LAB), we can look at the profile for the device on which we're trying to reproduce that colour, and we can determine what device-specific RGB or CMYK values the device needs to reproduce that colour
The Colour Engine
The colour engine -- also called the CMM, which has at various times stood for Colour Matching Method and Colour Management Module -- is the piece of software that actually changes the numbers in our files as we go from device to device, with the goal of keeping the colour consistent.
If we return to the example shown in Figure 1, the colour that the scanner saw as R247, G160, B91 has LAB values of L* 76, a* 19, b* 46. Through top secret means I'll never divulge, at least for a couple of paragraphs, I know that to make that same colour appear on my monitor, I need to change the RGB values to R250, G175, B100. To print that same colour on my Epson inkjet printer, I need to change the RGB values to R244, G192, B148.
Without a colour management system, the only way to determine these values would be expensive, time-consuming trial and error. With colour management, it's almost an automatic process. Here's how it works.
I ask the CMS (colour management system) to convert my colour from scanner RGB to monitor RGB by specifying a source profile (the scanner) and a destination profile (the monitor). The CMS looks first at the source profile and determines that the actual colour represented by scanner R247, G160, B91 is LAB 76, 19, 46. Then it looks at the destination profile and determines that a colour whose LAB values are 76, 19, 46 can be represented on the monitor by RGB values of R250, G175, B100. Then it converts the colour, changing the RGB values from source RGB R247, G160, B91 to destination RGB R250, G175, B100.
Figure 2: The CMS uses the scanner profile to determine that the actual colour represented by scanner RGB 247, 160, 91 is LAB 79, 19, 46. It uses the monitor profile to determine that the monitor needs RGB values of 250, 175, 100 to represent that same colour When we print, the CMS determines from the printer profile that the RGB values needed to print the colour are R244, G192, B148.
Of course, usually colour management systems operate on more than one colour at once: By specifying source and destinations profiles, you give the CMS the information it needs to make all the colours in the source files appear as true as possible on the target device. And that, in a nutshell, is all that colour management systems do: They change device-specific colour values from a source profile's colour space to a destination profile's colour space in such a way that the perceived colour remains consistent. You can, of course, make colour management systems do more complex operations -- for example, you can ask the CMS to show you on your monitor how an inkjet proof of a CMYK press will appear -- but when you break it down, the operations always boil down to converting from one profile's device-specific values to another profile's device-specific values.
It Takes Two
Colour management is easier to understand if you can keep one simple rule in mind: A single profile simply describes colour data; it always takes two profiles to change the numbers in a document. It's almost always a good idea to embed a profile in your documents, especially if you routinely send files to other folks or you hold onto them for any period of time (remember that as your monitor ages, its colours change). When you embed a profile in a document, you're attaching a description of what actual colours are represented by the numbers in the file, but you aren't changing the numbers themselves. When you ask the CMS to match the colour on a device, you need to specify two profiles, one representing where the colour came from, the other where the colour is going.
Without a profile embedded, a colour is simply a bunch of numbers open to very different interpretations, as we saw in Figure 1. When we embed profiles, the CMS can tell that the scanner's RGB 247, 260, 91, the monitor's RGB 250, 175, 100, and the printer's RGB 244, 192, 148 all represent the same pale orange with LAB values of 79, 19, 46.
There are many more ramifications to colour management, such as the issue of rendering intents, but if you keep the simple rule in mind -- you need one profile to describe the colour, you need two profiles to match the colour across two devices -- then you'll find that colour management makes sense, and saves a great deal of time and hassle.
Written by Bruce Fraser on June 20, 2001. He was the guru on all matters like this. His thoughts on sharpening are excellent.