Color theory may sound like a subject for the Art Department, not for developers. But we've all had the experience of choosing a color scheme using the property grid to select named colors and ending up with a really garish color scheme. In an ideal world it might be the case that only our software's functionality really mattered but, in the world that we actually live in, users are likely to prefer software with a sophisticated color scheme over software with an ugly color scheme.

Many small companies don't have an Art Department, while in medium sized companies, the Art Department is often a single person who simply doesn't have the time to help you choose colors. So often the developer is stuck choosing colors.

Now, choosing colors that go well together is a matter of taste, and while taste can be acquired and improved, it's not something that the average developer has ever spent much time on. Fortunately, color theory provides a developer-friendly way around the issue: a few simple principles govern not only how colors interact, but also what makes a color a good foreground color or a good background color.

The first thing you need to know about color theory is that the familiar RGB (Red-Green-Blue) model is really just a sort of implementation detail. RGB is not a very good way to think about color. (This will probably come as no surprise to anyone who's tried to tweak color by changing the RGB values and found that, say, decreasing the red component made the color look grayer, not more blue-green.) Intead, the HSB [Hue / Saturation / Brightness] model provides a much more realistic way of controlling color. This article summarizes the HSB model; introduce a few HSB-oriented rules for combining colors; and shows some code that uses the HSB model to generate random color schemes for simple bar charts.

As you know, RGB uses three numbers to describe any color. The Red, Green, and Blue components map directly to the number of red, green, and blue photons a given pixel is putting out. RGB is very close to the monitor's color-generation hardware.

HSB also uses three numbers to describe a color, but the Hue, Saturation, and Brightness components do not map directly to RGB. A small change in HSB might be a rather large change in RGB, and vice versa. The point of HSB is that it is very close to the human color-perception hardware. A modest change to a single RGB component can give you a totally different color, while even relatively large changes to a single HSB component can give you a related color. For example, changing Brightness while holding Hue and Saturation constant gives you what looks like a shadowed or highlighted version of the same color, which is particularly useful in gradients and 3D effects, as shown in this figure. (Click each figure in this article to see the full-size version. Also see the Highlights project in the sample code.)

The Hue component of HSB is measured in degrees (as in a circle), where 0 is red, 120 is green, 240 is blue, and 360 wrap back to red. Other colors are found in between these colors. 60 is yellow, and 300 is purple, for example. (See the ColorWheel sample project.) If you are thinking in terms of photons of different frequencies, it will seem strange to arrange colors on a wheel and put violet (the highest-frequency color) next to red (the lowest-frequency color) but, to human eyes, violet really does look similar to red, and yellow really is about as far from green as purple is from blue.

While Hue is measured in degrees (and thus represented as a polar coordinate), the Saturation and Brightness components are simple, Cartesian coordinates, running through the real numbers from 0 to 1. Unsaturated colors are mixed with gray, and when Saturation is 0, the color is gray, with no trace of the Hue; when Saturation is 1, the color has no gray, and is fully determined by the Hue and the Brightness. Highly saturated colors are vivid, and can be jarring. Interestingly, if you go outside and look towards the horizon, you'll see that distance haze mutes distant colors: The farther away something is, the grayer (less saturated) it looks. Because our brains interpret this muting as distance, low-saturation colors make good backgrounds. As you can see from these two figures, (found in the UnsaturatedBackgrounds sample project), even a relatively unsaturated foreground will stand out, as long as it is more saturated than the background.

As with Saturation, any color with a Brightness of 1 is white. Zero Brightness, however, is black, not gray. Legible text needs a certain amount of difference between foreground and background Brightness. As you can see from this image and the ForegroundBackground sample project, text is hard to read when the foreground and background Brightness differ by less than about 0.4, though you can get away with a bit less contrast when the Hue and Saturation are very different.

Brightness also affects the way we perceive color differences. The RelatedColors sample project draws pairs of colors in related hues, with semi-random Saturation and Brightness. As you can see from this image and the RelatedColors sample project, the darker and more saturated the color, the more the difference in Hue matters. Some of the dark and saturated pairs on the top rows are sort of garish and jarring, while none of the light pairs on the bottom rows clash, no matter the saturation and no matter the difference in Hue. This is why most walls are painted light colors: they're easy on the eyes, and they don't clash with anything. This is also why many websites use pastel color schemes: Any light color with a moderate saturation goes with any other light color with a moderate saturation.

Next: ' Coding with Color Theory ' >>

Discuss Color Theory for Developers   >>> Be the FIRST to comment on this article!

>>> More Using VS Articles          >>> More By Jon Shemitz