Colour (by )

Not a lot of people know this, but...

...computers these days handle colour really badly.

Now, most people are happy with computers representing a colour as 'levels of red, green, and blue light'. But this, as we shall see, is dreadfully imprecise...

For a start, there's two major things wrong with that approach.

  1. What are y0u using as your reference red, green, and blue? If a particular monitor used different colours for its primary colours, then everything would come out differently.
  2. How do you measure the "level" of light? As it turns out, the 'red'ness you feed to a monitor (be it a percentage, or from 0 to 255) isn't linearly converted to a wattage of light coming from the pixel.

The second point is quite complex. The human eye's response to the intensity of light is nonlinear; we can see smaller differences between less intense light sources than between more intense ones. And to make things worse, actual monitors have a nonlinear response too.

That's what all that talk of "gamma correction" is about.

But when we specify how much of a given colour of light we want a monitor to produce, we don't specify it in terms of real intensity - we specify it in terms of perceptual intensity, so if we go from 0% red to 100% red, it looks like a continuous smooth increase in brightness. The computer's colour management software will compensate for the combination of nonlinearity in the eye and nonlinearity in the monitor to try to create a uniform colour scale - if you're lucky enough to have a computer that bothers with gamma correction.

But until recently, computers didn't generally bother, meaning that image files written for a specific display didn't look the same on other displays with different nonlinearities - even aside from the issue of differing definitions of "red".

This was why the PNG image file format included within it a description of the gamma and the precise shades of primaries that an image file expects (the 'chromaticities'). As long as your computer knows the details of the monitor attached, it will be able to display a PNG file exactly as the producer of the file intended.

That, combined with the fact that Mac OS X and Windows now both come with colour management software built in to handle the differences between monitors, means things are getting better; but therer are still issues. For a start, HTML colours are still specified as red/green/blue levels without specification of gamma or chromaticities. So if one has an embedded accurate-colour PNG in a Web page, don't expect it to match the colour of the text reliably.

But there's worse. People preparing content for high-quality printing generally want to work with colours specified as levels of Cyan, Magenta, Yellow, and blacK (CMYK) rather than as red, green, and blue (RGB) - whereas with RGB colour the levels of light are added together (since RGB is based around the idea of controlling a glowing monitor), CMYK secifies levels of ink to be deposited, and the colour you see depends on the total amount of the illumination shed on the page that is reflected back; more ink will absorb more light and make the result darker.

And the relationship between the specified CMYK numbers and the absorption you get is complex, since what actually happens in the printer is that the CMYK numbers control the sizes of the dots of ink on the page - and the dots overlap each other in a complex way, causing significant nonlinearities in the relationship between CMYK numbers and visible light.

Converting from RGB to CMYK is not only mathemtically complex, it also depends on the colour of light you're going to be illuminating the page with. A monitor makes its own light from scratch, but a printed page just reflects a proportion of the light that shines on it; illuminate it with reddish light, and the result will look redder than if you'd used white light.

So to make sense of a given set of CMYK numbers, you need to know the details of the printing screens that overlay the dots on each other, as well as the precise contents of the inks used - not only so you know what colours they are, but so you can predict what colour will result when they are mixed together due to dots overlapping.

So for somebody to look at an image on a computer screen and to be able to make a printer product the same colours on paper, a lot of complicated information is needed, and a lot of maths needs to happen.

But there is an alternative to doing it that way - libraries of known "pre-worked" colours. such as Pantone. With a list of colours, printers can pre-calculate the precise amounts of different inks needed to produce each one - or even just have a dedicated ink per colour, if not too many colours will be used on the same page, for better colour reproduction.

Then one can work out how to display each Pantone colour on a given monitor, and produce a lookup table mapping those colour numbers to appropriate levels of R, G, and B.

This works well - but image formats like JPEG, GIF, and PNG don't support Pantone colours. Mainly because the Pantone system is the intellectual property of Pantone, Inc. (although a nice fellow has published a list of Pantone colour numbers along with approximate RGB representations, which I used when designing my business cards). And the other problem is that there are Pantone numbers for things like metallic inks, which just don't work on a computer monitor.

So, as is usual with my rantings about issues in computing, I will now propose a solution.

Pages: 1 2

No Comments

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

WordPress Themes

Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales
Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales