Colour (by alaric)
For a start, I think that using the RGB colour space just leads to problems. The reason it was originally used was that you could plug the RGB numbers straight into a video card, and the monitor would produce those light levels, subject to its own unique interpretation of the gamma and chromaticities. Nowadays we use RGB but specify the chromaticities and gamma, and the computer converts that to RGB as required for the particular monitor in question (or for CMYK, given details of the printer, the inks, and the light we want the result to look right under).
I think it's time we broke with tradition and made computers represent colours internally in a format that is not only device-independent - not needing gamma and chromaticities specified, since the colour representation is specified in terms of actual levels of real light - and easier to do useful things with.
The colour system I have in mind is known as Yu'v'. It is interesting, because it describes the colour as three values; Y, the "luminance", is the brightness (from 0 for black to 100% for maximum brightness; and adjusted for the eye's nonlinearity, so it looks like a smooth gradient inbetween) and u' and v' describe the actual colour.
So to make a Yu'v' colour half as bright, you just halve the Y value and leave u' and v' alone. To alter the hue but not the luminance, fiddle with u' and v' but leave Y alone. This actually makes image manipulation a little easier, as well as making the results looks slightly better; a hue shift in the Yu'v' colour space will look slightly more uniform across different hues than one implemented simply on top of RGB, due to the scaling of the U and V axes to make them closer to how the eye sees colour differences. (I have a very big technical book on this if you want more information; but take it from me, you probably don't)
Yu'v' can be easily converted to RGB for a given monitor, given details of the monitor; or CMYK, given details of the printer. And because Yu'v' is quite different to both, people will no longer need to become confused between the RGB values that make their monitor display the perfect shade of puce, and the RGB values they need to put into a Web page or image editor to make somebody else's monotor produce that perfect shade.
However, I think that as well as the Y, u', and v' 'channels' in an image file that specify the details of the colour, there should also be the option to specify the specular reflectivity of each pixel in a file - in other words, its shininess. When printing to paper, this can be used to control the mixing in of glossy and metallic inks. On screen, this can't easily be shown; perhaps the best rendition would be to overlay a faint texture on the shiny areas, to mimic glossy reflections of distant light sources.
This will be great for people doing 3D graphics - if they can include per-pixel shininess data in their textures, then it becomes easier to produce complex surfaces. For that matter, why not make the image file format extensible? Many image file formats today already support an optional "alpha channel" to represent the opacity of each pixel; how about we allow arbitrary named channels, to cater for shininess, opacity, and things like texture altitude for bump mapping?
But as well as specifying a pixel as a set of numbers for each channel, there should also be the option to deal with images specified in terms of a fixed palette. This used to be popular in computer graphics for technical reasons related to the economics of electronics; a 256-colour display, for example, would allow you to tell the video system about 256 different colours, then for each pixel on the screen you specify which of those 256 you want. This saved memory, but nowadays, it would be good for people working with print to actually manipulate images on a computer in terms of Pantone colour numbers (or, perhaps, a free alternative), or by using a custom set of inks; there might need to be a return to palette-based images, not for efficiency of storage, but due to the image file format allowing linking the palette to a standardised palette like Pantone.
When I am less overworked, I think I will have to write a nice C or Java library to do all this...
...and define my own clone of the Pantone system; without breaking the copyright law protecting it, somehow. Perhaps by asking an ink manufacturer for the details of their ink range, including the absolute colour data, and then producing my own catalogue of them, along with Yu'v' colours for each ink under a standard light source, to produce a lookup table that can be used to display them on a monitor.
If the ink manufacturer gives Pantone numbers for their inks, too, I might even be able to produce a mapping table to and from official Pantone colours, which would be great - because a new incompatible system of colours would take a long while to be adopted in the print industry, otherwise...
= References =
- http://www.poynton.com/ColorFAQ.html
- Section 5 of http://www.poynton.com/PDFs/coloureq.pdf
Pages: 1 2
Mon 10th Oct 2005 11:07 am 
Subscribe