In the last chapter we went through the basic theories of managing colour in a digital imaging workflow.
We discussed what we want, versus what we normally get – and discussed why this problem occurs. It’s all about the numbers in the digital files and the fact that they lack any real meaning if the files are untagged – each device will just reproduce those numbers as they see fit, and because each device is using different colorants to produce its colour, the colours all come out differently on different devices.
So we then introduced the concept of colour spaces – dictionaries for colour that translate from the numbers in a file into absolute real colours – (where absolute colours are specific colours under a specific light source - and all have value in the LAB colour space which defines the gamut of the human eye).
So, at this stage we know that all pixels are just RGB number triplets like
(128,128,128). And we know that colour spaces give real meaning to those numbers (i.e. define a translation between the numbers and absolute LAB values).
We also know that there are two types of colour spaces – those that are device dependent (based on measuring the physical properties of a device) and those that are deliberately device independent (theoretical colour spaces that abstract colour away from individual devices). We use the device independent colour spaces specifically because we don’t want our colours to depend on the mood of our inkjet on a particular day – we want to talk about what colours we want in absolute terms, and then get those colours out of our devices.
We went into some detail of the anatomy of a colour space – that each colour space has 3 defining characteristics – namely the colorants (primaries) used to mix all the other colours, the black/white points, and the tone characteristic curves.
We considered colour spaces as boundaries for colour – they define what all the numbers from 0 to 255 mean for each colour, and there is no -1 and 256. So by defining the end points we are defining the maximum achievable gamut in that colour space. If we’re talking about a device profile – that is measured – i.e. we measure the most saturated colours, the darkest black, the brightest white, and all the colours in-between to come up with the profile. In an abstract colour space, we choose what the end points are. We’ll get into more detail about this today, and really convert all this theory into working practice.
Making it work in practice
This chapter is all about making colour management work in practice. Even if all the theory makes your head spin and you can’t quite get your head around it, the actual USE of colour management is actually pretty simple. You’ll probably find the theory becomes more understandable as you consider how it works in practice, and we’ll go over several examples to make sure it all makes sense.
It’s worth looking briefly at some real world measurements now, to give you a stronger idea of what we’re talking about.
The image below is a plot (seen from above, looking down on the whitepoint) of the gamuts of a high quality Eizo LCD monitor (the wire-frame graph) versus the measured gamut of an Epson 7800 inkjet printer using Hahnemuehle Photo Rag paper.
You can see how the monitor’s gamut extend much deeper into the red, greens and blues than the printers – not surprising because a monitor is inherently an RGB based device (its colorants are red, green and blue). The printer’s gamut extends more heavily into the cyans, magentas, and yellows – again not that surprising since the colorants of the device are CMY.
The graph shows clearly one of the fundamental problems of colour management – what we can see on our screens is vastly different to what we can print. There’s a whole range of saturated yellows our printer can achieve that we can’t see on screen, and vast numbers of blues, greens and reds that we can see on our screen that we can’t print.
Notice that these plots only really show you gamut volume – i.e. These plots only really show you the edges of the gamut, the most saturated colours that exist for the profile. These plots don’t really tell you anything about what is going on inside of a profile.
Here’s a plot of the gamut of a modern-ish digital camera (Canon EOS 1DS MK2) versus the Epson 7800 – as you can see the gamut of the camera far exceeds what is printable on paper.
These images are really here just to remind you that all this theory has a very practical context – profiles clearly define the range of colours a device can produce. And abstract spaces clearly define the total gamut of colours you can work with in your files. And clearly, these two gamuts are not the same!
A device profile is like a map of a device’s behaviour across its entire gamut. Your ability to take advantage of that gamut is totally determined by the accuracy of that map. But the map reflects the true behaviour of the device as measured, and it may not be a pretty thing. It certainly isn’t a great place, in general, to work with colour.
The device profile may well reflect all sorts of things you don’t expect/desire – one very obvious and common issue is that devices rarely have linear, neutral grey scales. That is, if you’re working in the device’s colour space, you can’t rely on all equal value RGB triplets (
20,20,20 etc) being a neutral grey, like you can in a well behaved working space. Device profiles also reflect the actual gamma of that device, which may differ considerably from the standard 2.2 used to reflect the gamma of a print (i.e. tone curve from shadow to highlight). So actually working within a device profile may (will) mean you get unexpected results with both colour and density.
We’ll talk more about this when we talk about Early Binding Vs Late Binding – the key point to take on board is that device profiles reflect the real world chemistry of inks, or the real world physics of phosphors, so they’re not necessarily nice, neat things, and they don’t always behave like we might logically expect.
In practice, colour management works like this:
RGB values are created by a camera or scanner. These colours are converted by the scanner profile into the closest matching colours available in our working space. Then, just before we send these colour numbers to the printer, the printer profile translates those numbers into the best matching colours the printer can produce.
To break that down, we’re going to look at how it all works, from capture to output, for just one single pixel in a file.
The easiest way to really work out what is going on is to imagine the life of a single pixel all the way from capture to output – that is, how is the colour on just one pixel managed (kept consistent) all the way from initial capture all the way to final output.
If we can manage the colour of one pixel all the way through the chain, then all we have to do is follow exactly the same formula for all the pixels in our file and we’ll have successfully managed colour from capture to output.
We’re going to start at the print and work our way back to the original colour in the original scene. This is because its always easier to work towards something if you know exactly what it is you are working towards – this is true whether we’re talking more generally about pre-visualisation of your final image, or just the specifics of the colour of one tiny dot on a page.
Here’s our goal – we want to produce the absolute colour as defined in LAB as:
(20,-15,25) – a leafy green colour.
We want to produce a single dot of this absolute colour on a nice piece of fibre based Hahnemuehle Photo Rag paper – that is, we want to lay down some mixture of ink, that when viewed under a standardised light source (D50), appears as that absolute colour.
So how do we get there? How do we get the printer to produce this colour?
Well, first we have to know if the colour is in our printer’s gamut at all – that is, is there anyway to tell the printer to produce this colour at all? If the colour is not achievable on the printer at all, then we’ve failed – the best thing we can do is lay down the closest thing to this colour, and hope it is close enough to be convincing. If the colour IS in the printer’s gamut, then we just want to send the printer the right numbers to get it to produce this colour.
It’s the printer profile that tells us whether or not a particular colour is in a printer’s gamut (remember the printer’s profile is a device dependent colour space created by measuring the printer’s total gamut). The printer profile tells us what RGB values we need to send to the printer to get the printer to actually print that colour. In this case, the printer profile tells us that to get this particular shade of leafy green on to paper, we have to send the printer the following numbers:
....the colour numbers the printer actually needs to receive to trigger it to produce leafy green
So, to achieve this colour on the printer, we have to send the printer a single RGB pixel with those numbers.
We’ve just taken one step back from our goal, and worked out how to achieve that goal.
How do we get to
We have to send our printer
RGB (71,100,14) to achieve the leafy green that we want, but how do we get to this number?
Well, we’re photographers and we create images by capturing light with a sensor. Whether that sensor is a digital camera or film, it doesn’t really matter. Either way, the sensor in question generates RGB colour numbers to represent the colours of the real world. Problem is, all the sensors generate different colour numbers. Could we just tell our camera to always record colours as our printer sees those colours? Well, we could, but we’d be forever tied to that particular printer – and we know that printers can’t reproduce a lot of colours of the real world. We really want to take full advantage of the complete abilities of our camera (which are already pretty feeble) and not limit our camera’s ability to record the world based on our printer. Especially since there is almost certainly a printer in the near future that will be able to produce a wider gamut.
Hopefully you can see we need an independent step in the middle. That is, take the best possible colour we can record at the input end, and translate that into the best possible colour we can achieve at the output end.
In this case, imagine we are taking a photograph of a plant. This plant, when we shoot it, contains the same leafy green we want to reproduce – the absolute colour
LAB(20,-15,25). We’ll shoot this image on film and scan it, to keep things simple for now.
We know the scanner produces RGB values, not LAB values. In this case, the scanner produces the values of
(30,70,25) for the same shade of green. If we sent this directly to the printer, we wouldn’t get the same green – we’d get the printer’s version of
(30,70,25) which is a completely different green. So we have to translate from the scanner’s green, to the printer’s green. Which is pretty easy – we just convert
(30,70,25) from the scanner into the printer’s equivalent green
(71,100,14) and we’re done.
In reality, it is Photoshop that sits in the middle and does these conversions. To do these conversions, it looks at the RGB <-> LAB tables in each profile, and it basically works like this:
Scanner (30,70,25) = LAB (20,-15,25) LAB (20,-15,25) = Printer (71,100,14)
So you can see how profiles are being used to translate between different device dependent RGB values by converting those numbers into universal, absolute colours in LAB.
A printer profile is really just a big table of these match-ups – to print such and such a LAB colour, the printer requires such and such RGB.
The scanner profile is just the same – a big table that says, for each colour, when the scanner generates such and such RGB, it really means such and such LAB.
So we go from RGB -> LAB -> RGB.
This works, and if you have complete tables representing the gamuts of the scanner and the printer, it is sufficient if all we want to do is send files directly from the scanner to the printer – the colours will be consistent across these devices and the job of colour management is done.
We’ve just discussed the life of a single pixel from capture by scanner through to final print on fibre based paper. And we’ve succeeded in translating colour between devices by using profiles (our colour dictionaries). This is a great leap forward, but not yet nearly enough. All this isn’t much good to us if we can’t actually see and edit our files along the way.
So far, we have three different values for the colour we want to achieve –
The LAB absolute colour: LAB(20,-15,25) The RGB colour our scanner generates for this absolute colour: RGB (30,70,25) The RGB colour our printer needs to be given to print this colour: RGB (71,100,14)
Your monitor is also an RGB device, and it too has its own colour response. So it too needs to be sent an RGB colour that causes it to display its best match for the same absolute LAB colour. In this case it is your monitor’s profile that supplies the RGB values that best match the LAB colour we want to achieve, and the results is:
RGB (49, 24, 5)
So, for just this one pixel, we have a pretty complicated situation, which looks like this:
The result of all this?
One single pixel of a leafy green colour that is consistent from capture, through visualisation, to print. Multiply by several million and you have yourself a fully colour managed workflow! At this point we can capture the colour, see the colour on our screens, and print the colour. But what if we want to actually edit that colour?
Fine printing is very much about managing tonal relationships between pixels in your files – and for that we need Photoshop.
From all this, we can see LAB is pretty important. It sits in the middle of all the devices and acts as the universal language that translates from RGB numbers into consistent, absolute colours. Photoshop actually does all of its maths in LAB. As PS converts colours from one device to another, it uses the tables in profiles to convert LAB values to RGB. This is why LAB is called the Profile Connection Space.
Why don’t we always use LAB then?
If we have a universal language that defines all the colours the human eye can see, why don’t we just make all our devices use LAB directly, and why don’t we just work on our files in Photoshop in LAB mode rather than RGB mode in Photoshop?
It is in fact quite possible to work in LAB, and many people regularly do, for a variety of reasons. However for general purpose usage, LAB isn’t a great place to be because it makes colour harder to understand than the RGB model.
Using RGB (and the digital colour wheel) is conceptually simple – by isolating the colours and clearly identifying the primaries and their opposites – this is much easier than trying to manipulate colours in the language of A and B. Also, RGB working colour spaces generally have a neutral axis – that is from 0,0,0 through 128,128,128 to 255,255,255 we have from black, through shades of neutral grey, to white. So RGB (the language of light) is a very convenient and conceptually simple place in which to work.
LAB isn’t so friendly and obvious. You can try it for yourself – convert one of your files into LAB and attempt to edit the colours. You will find strange things happen. It’s not really important why this is the case, just that it IS the case.
So working in LAB is no good to us.
Instead of working directly in LAB, which doesn’t make much conceptual sense, we (generally) choose to work in RGB, because RGB is the language of light, the language of the human eye, and the language of most of our devices, so it’s the easiest one to understand and use.
This means we need yet another translation to occur, from the LAB colours in the middle of all this, to the working RGB space. We’ll use a popular working space called AdobeRGB as an example, and later on we’ll discuss popular working spaces in general.
In this example, the AdobeRGB values for our leafy green are
From Scanner to working space it goes like this:
The scanner colour:
(30, 70 , 25)
is generated by the scanner when it sees the absolute colour
which is converted to the equivalent working space colour
From working space to screen it goes like this:
is converted to
which is converted to the monitor’s RGB:
From working space to printer it goes like this:
is converted to
which is converted to the printer’s RGB
…and thus all the devices, finally, are producing the same colour because profiles are converting the actual absolute colour to the RGB numbers that correspond to that actual colour, and we’ve also got our file into an easy to understand abstract working space for editing.
In summary: Ignore LAB!
While LAB is the colour model used in the background, and it is very useful to understand what it is, for the most part, you can ignore it. You’ll probably only ever work with RGB files and think in RGB values for a good long while until your understanding of this deepens over time.
In the end, in practice, colour management looks like this:
The end of the journey
Using accurate device profiles, we have translated the colours between devices and abstract working spaces, all the while keeping the colour consistent – even though all our devices use different numbers to represent the same colours, we get the same colour on each device – which is what colour management is all about.
So there are two major components to a colour managed workflow:
Good colour management is all about getting/making good device profiles and making informed decisions about working spaces. So that is what we’ll talk about next.
One More Thing!
The above example shows us what happens when everything works nicely – but of course in practice there are always some glitches in the system. Not only are there glitches in the system, but there are some inherent limits in the system – and we’ve already seen one major reason why (the gamuts of devices do not match up nearly as much as we might like).
The first thing to achieve is to get colour management working perfectly in simple situations – like reproducing one, in gamut, colour that all the devices in the chain can comfortably deal with. Once we’ve achieved that, we can look at solving the problems when we inevitably run into them. And in reality, even with the flaws in the system that remain, we're well on our way to good results.
By popular demand, you can now buy eBook versions of the Fundamentals of Digital for easier off-line reading.
You gain access to all three eBook versions - PDF (A4, print ready), ePub and Mobi.