From: Colm Buckley (colm at domain tuatha.org)
Date: Fri 03 Sep 1999 - 16:38:07 IST
Paul Curtayne (in a private mail), writes:
> See, what I am confused about, is if RGB value is enough to fully
> define a colour, and so is (hue/lum/sat), why do we use both, or is
> that wrong??
There is a mapping between the RGB and HSV spaces, as my code shows.
RGB is used for luminous output devices such as CRTs, as it corresponds
neatly to the hardware capabilities of these devices (and, indeed, to
the reception mechanism in the eyes). However, it's not a good space
for defining colours in - which is where HSV and HLS come in (not quite
the same thing, as I'll explain shortly); HSV is designed as an
"intuitive" colour picker, when you can say things like "a slightly
stronger red" (increase saturation) or "a slightly more yellowish green"
(modify hue) - experience has shown that people find it easier to pick
the colours they want from a HSV picker than from an RGB picker.
RGB space is a cube, with R, G and B axes each ranging from 0 to 1 (or 0
to 255, in standard 24-bit colour notation). HSV is a cone, with V
ranging from 0 at the point of the cone to 1 at the disc face, S
indicating "distance from the major axis" (0 == on the axis, 1 == on the
surface) and H indicating the angle around the cone (0° = red, 120° =
green, 240° = blue). Note that H is undefined if you're actually *on*
the axis.
"Hue" in HSV space corresponds to a pure colour space, rotating from red
through yellow (red+green) through green through cyan (green+blue)
through blue through magenta (blue+red) and back to red.
"Saturation" ranges from 1 (fully saturated colour) to 0 (totally
unsaturated - ie: black, white or grey)
"Value" ranges from 0 (black) through 1 (maximum brightness). It's not
quite the same as luminosity, where 1 represents "white" - an HSV spec
of (H = 0°, S = 1, V = 1) is pure red. Black is at the point of the
cone (S = 0, V = 0, H = undef), and White is in the centre of the disc
face (S = 0, V = 1, H = undef).
... which brings us to HLS space (Hue, Luminosity, Saturation). In this
case, Hue and Saturation mean the same as they do in HSV space, but
instead of specifying Value, ranging from Black up to "maximum
brightness", we specify Luminosity, ranging from 0 (black) up to 1
(white). In this model, "pure" colours all have a luminosity value of
0.5 - higher luminosities indicate "pastel" versions of the colours
(added white), and lower luminosities indicate "shadow" versions of them
(added black).
HLS space looks like a double cone (two cones joined together at the
disc faces), with black (H = undef, L = 0, S = 0) at one point, and
White (H = undef, L = 1, S = 0) at the other point. Around the "rim" in
the middle, we have the fully-saturated versions of the colour wheel,
ranging from red through yellow through green through cyan through blue
through magenta and back to red.
This is hard to explain without diagrams... but the code I mailed
earlier should, with a little unpicking, make it clear...
Classically, the ranges of the various spaces are defined as:
0 <= R, G, B <= 1
0 <= S, L, V <= 1
0° <= H < 360°
... but it's just a matter of picking units.
> This colour thing is confusing as I'm a physicist! I think of colour
> as frequency. Can you uniquely associate a given RGB with a
> frequency?
Two problems. Firstly, the eye can perceive colours which are not
representable by a single frequency of light - superimpose a
single-frequency red and a single-frequency blue light, and you get a
magenta which is *not* the same as any single-frequency... there is a
mapping from frequency to RGB, which I have somewhere, but the reverse
isn't necessarily true - RGB has a higher dimensionality.
Second problem is that the gamut of the RGB/HSV/HSL space isn't nearly
as large as either the colour gamut which can be produced in print, or
as large as the gamut which can be perceived by the eye. There are
other colourspaces, into which RGB/HSV/HSL can be converted, which are
larger and designed to correspond more closely to what is obtainable in
print, or visible to the human eye. Clearly, as these colourspaces are
larger than the RGB/HSV/HSL space (which all have the same gamut,
designed to correspond with the range of colours which are produceable
on a CRT monitor), an attempt to represent them in RGB will result in
"clipping" - consider, for example, trying to represent the face of the
sun on a CRT screen; you can only make pixels so bright...
> Of course, the hex colours used in websites are uniquely associated
> with RGB only right? and hence can be uniquely associated with
> hue/saturation/lum via your code?
Yes. The Web colour specification is to use #RRGGBB in hex, or to use
one of the colours from the standard X11 colour sheet
(/usr/X11R6/lib/X11/rgb.txt on most X11 installations).
The best reference for all this is "Computer Graphics : Principles and
Practice" by Foley et al. The 2nd ed. came out in 1996, which is what I
have. The chapter on colour theory is excellent.
Hope this helps - here endeth the lesson...
Colm
-- Colm Buckley B.A. B.F. # colm at domain tuatha.org colm.buckley at domain tcd.ie colm at domain computer.org Department of Computer Science # +353 87 2469146 # whois cb3765 Trinity College, Dublin 2, Ireland. # http://www.tuatha.org/~colm/ Why is there only one Monopolies Commission?
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:04:32 GMT