Basic colour theory for programmers(polymathprogrammer.com)
polymathprogrammer.com
Basic colour theory for programmers
http://polymathprogrammer.com/2008/08/04/basic-colour-theory-for-programmers/
8 comments
This is an old article, and so wrong and vague in so many aspects of digital colors. It contains not much more than simple device-dependent RGB/HSV colors.
To use colors correctly (not many programmers can do this, in fact Chrome/Firefox/Safari don't show the same color for same RGB value on my machine), programmer needs to consider color profiles, gamma correction, white point etc. The sad truth is that RGB is mostly misunderstood from intuition, and most graphic libraries don't deal with device-dependencies at all. Luckily, most engineers don't have to deal with colors outside sRGB.
The absolute best place to read about digital colors (or image processing in general) is efg's references: http://www.efg2.com/Lab/Library/Color/Science.htm. It contains overwhelmingly large amount of info, but they are good info and quite essential for professional work.
To use colors correctly (not many programmers can do this, in fact Chrome/Firefox/Safari don't show the same color for same RGB value on my machine), programmer needs to consider color profiles, gamma correction, white point etc. The sad truth is that RGB is mostly misunderstood from intuition, and most graphic libraries don't deal with device-dependencies at all. Luckily, most engineers don't have to deal with colors outside sRGB.
The absolute best place to read about digital colors (or image processing in general) is efg's references: http://www.efg2.com/Lab/Library/Color/Science.htm. It contains overwhelmingly large amount of info, but they are good info and quite essential for professional work.
I wish I could really upvote this as a disclaimer. I once worked in a color science lab of a printing company, and it took a long time for me to really get a grip on the topic, because it is a deep topic. It's a bit disheartening to see something passed on as truth that's got so many inaccuracies.
Some other points programmers should be familiar with (not an expert here, everyone feel free to correct me)
1. In typical situations, 256 shades of brightness of a single color hue are the most we can distinguish and will form a smooth gradient without banding. If you're dealing with Green and related colors in the RGB spectrum (i.e. yellows and blue-greens, and near-white colors) it can go a bit higher, to 512 shades- This is why many compression algorithms compress reds and blues more than greens, because it's less noticeable.
2. Many artists will use opposite colors on the color wheel to darken colors- So to make a darker yellow, they'll mix in purple paint (or use purple dithering, depending on the medium.) How this relates to color theory from a psychological standpoint is unclear, but using this approach in UI design (for instance, adding purple detail to the shadow of a yellow object in an icon) often gives clean, elegant results.
3. Sometimes, when designing something, you say to yourself, "I want a red here that is just as bright as the blue over there". However, the psychological basis as to when colors of different hues appear to have the same brightness is a very complex problem- You can't just add R+G+B intensities and think that will tell you that two different colors have the same brightness, perceptually. Your best bet is to just "eyeball" colors in this case, unless you have the time to go down some very deep rabbit holes.
4. If you are designing for paper printing, expect all colors in an RGB image to look much, much darker and less vibrant than on a monitor. Going from RGB->CMYK and getting perfect results is another really hard problem out of reach for most programmers (I actually think there's low hanging fruit for people to write libraries that help optimize this conversion- Everything I've personally seen that is designed for a layman, such as Photoshop's conversion process, seems to be sub-par at helping laymen do this well.)
5. There are exotic color spaces like the TSL color space that most programmers are completely unfamiliar with and are designed for better modelling of human perception of color. We programmers should probably be using these color spaces a lot more.
6. A good rule for UI design is to only use two colors at most (besides gray tones) on the screen at a single time and maybe one extra color in a very limited way. If you don't do this, you'll end with an "angry fruit salad" interface (http://www.urbandictionary.com/define.php?term=angry%20fruit...) Microsoft Metro and some of the new "flat UI" stuff is a major deviation from this rule, for better or worse.
7. When in doubt, leave the background of a website white. You should have a very, very good reason before using a black or dark green/blue/brown background on a website. (or so most UI designers will tell you, though of course you're free to ignore their advice.)
1. In typical situations, 256 shades of brightness of a single color hue are the most we can distinguish and will form a smooth gradient without banding. If you're dealing with Green and related colors in the RGB spectrum (i.e. yellows and blue-greens, and near-white colors) it can go a bit higher, to 512 shades- This is why many compression algorithms compress reds and blues more than greens, because it's less noticeable.
2. Many artists will use opposite colors on the color wheel to darken colors- So to make a darker yellow, they'll mix in purple paint (or use purple dithering, depending on the medium.) How this relates to color theory from a psychological standpoint is unclear, but using this approach in UI design (for instance, adding purple detail to the shadow of a yellow object in an icon) often gives clean, elegant results.
3. Sometimes, when designing something, you say to yourself, "I want a red here that is just as bright as the blue over there". However, the psychological basis as to when colors of different hues appear to have the same brightness is a very complex problem- You can't just add R+G+B intensities and think that will tell you that two different colors have the same brightness, perceptually. Your best bet is to just "eyeball" colors in this case, unless you have the time to go down some very deep rabbit holes.
4. If you are designing for paper printing, expect all colors in an RGB image to look much, much darker and less vibrant than on a monitor. Going from RGB->CMYK and getting perfect results is another really hard problem out of reach for most programmers (I actually think there's low hanging fruit for people to write libraries that help optimize this conversion- Everything I've personally seen that is designed for a layman, such as Photoshop's conversion process, seems to be sub-par at helping laymen do this well.)
5. There are exotic color spaces like the TSL color space that most programmers are completely unfamiliar with and are designed for better modelling of human perception of color. We programmers should probably be using these color spaces a lot more.
6. A good rule for UI design is to only use two colors at most (besides gray tones) on the screen at a single time and maybe one extra color in a very limited way. If you don't do this, you'll end with an "angry fruit salad" interface (http://www.urbandictionary.com/define.php?term=angry%20fruit...) Microsoft Metro and some of the new "flat UI" stuff is a major deviation from this rule, for better or worse.
7. When in doubt, leave the background of a website white. You should have a very, very good reason before using a black or dark green/blue/brown background on a website. (or so most UI designers will tell you, though of course you're free to ignore their advice.)
The original article didn't teach me anything new (perhaps because I've paid attention to color in the past... it's a minor interest of mine). But YOUR points here taught me several new things. Thanks!
Yeah, I think the article went in the wrong direction. It's easy to understand the basic mathematics of color. Understanding how to use color and how to avoid common pitfalls is a lot more valuable to me.
>1. In typical situations, 256 shades of brightness of a single color hue are the most we can distinguish and will form a smooth gradient without banding.
This is less true than you might think. You rarely have a gradient from pure black to pure white, so in practice a useful gradient will have much fewer than 256 shades in it, few enough that banding can be noticeable to a trained eye. Add in the fact that most consumer TN panels are actually 6-bits per component with temporal dithering (rapidly flickering between two colors, basically) to compensate, and it's even worse. A lot of AV enthusiasts have switched to 10-bit (1024 possible values) per channel encodings for this reason: it preserves subtle gradients which improves compression and allows them to be displayed with dithering on lesser displays.
>2. Many artists will use opposite colors on the color wheel to darken colors- So to make a darker yellow, they'll mix in purple paint (or use purple dithering, depending on the medium.) How this relates to color theory from a psychological standpoint is unclear
It's just a simple way to desaturate the darker tones. If saturation is the degree that a color's strongest components deviate from its weakest, then it follows that adding a bit of the opposite mix of components to a color will even the components out and thus reduce saturation. If you tried to do the same by mixing black or grey into it, you'd go beyond evening the components and also reduce what were the dominant ones, and get a much duller color than you probably intended. Beginning artists often do this with skin tones, where it looks dull and lifeless to the point of being disturbing.
>6. A good rule for UI design is to only use two colors at most (besides gray tones) on the screen at a single time and maybe one extra color in a very limited way. If you don't do this, you'll end with an "angry fruit salad" interface
Heh, I'll have to remember that one. Pretty much sums up how I feel about syntax highlighting.
This is less true than you might think. You rarely have a gradient from pure black to pure white, so in practice a useful gradient will have much fewer than 256 shades in it, few enough that banding can be noticeable to a trained eye. Add in the fact that most consumer TN panels are actually 6-bits per component with temporal dithering (rapidly flickering between two colors, basically) to compensate, and it's even worse. A lot of AV enthusiasts have switched to 10-bit (1024 possible values) per channel encodings for this reason: it preserves subtle gradients which improves compression and allows them to be displayed with dithering on lesser displays.
>2. Many artists will use opposite colors on the color wheel to darken colors- So to make a darker yellow, they'll mix in purple paint (or use purple dithering, depending on the medium.) How this relates to color theory from a psychological standpoint is unclear
It's just a simple way to desaturate the darker tones. If saturation is the degree that a color's strongest components deviate from its weakest, then it follows that adding a bit of the opposite mix of components to a color will even the components out and thus reduce saturation. If you tried to do the same by mixing black or grey into it, you'd go beyond evening the components and also reduce what were the dominant ones, and get a much duller color than you probably intended. Beginning artists often do this with skin tones, where it looks dull and lifeless to the point of being disturbing.
>6. A good rule for UI design is to only use two colors at most (besides gray tones) on the screen at a single time and maybe one extra color in a very limited way. If you don't do this, you'll end with an "angry fruit salad" interface
Heh, I'll have to remember that one. Pretty much sums up how I feel about syntax highlighting.
Regarding point #2, I've found it usually balances it a bit more and while keeping the same values, makes it more colorful. If working with a limited palette, a neutral grey can be used dually with warm or cool colors on the object to cast an opposite cool/warm shadow - which usually looks quite complementary, although I can't recall seeing a warm shadow cast from a cool-colored object very often - seems unnatural as shadows are generally cooler.
http://androidarts.com/art_tut.htm - this link touches a bit on color theory from a digital-painting standpoint, though it's pretty applicable. Color and Light for the Realist Painter by James Gurney is also a good book that has some info about creating unified palettes.
http://androidarts.com/art_tut.htm - this link touches a bit on color theory from a digital-painting standpoint, though it's pretty applicable. Color and Light for the Realist Painter by James Gurney is also a good book that has some info about creating unified palettes.
We find it pleasing to depict shadows as slightly cooler because the shadows we are most familiar with behave this way; those cast on a sunny day outside. Daylight from the sun is a strong source of yellow (warm color) while the remaining sky is a source of blue (cool color), and it is the sky's ambient light that you see when see a stark shadow cast by the sun, which makes the colors seem cooler in contrast with sunlight areas.
Professional artist whose work is very much about color here.
2. It's better to pick a single color to use to darken everything when shading; this gives a more unified feeling. Usually the best way to do this digitally is what most art programs call the "multiply" transparency mode, which I believe is simply r1xr2, g1xg2, b1xb2.
4. If you are designing for paper printing then work in the CMYK color gamut from the start. You will save yourself tons of headaches. That said modern high-end printers DO have a wider gamut than older ones, if you're going to be doing professional reproduction then talk to the people doing the printing and get color profiles.
5. Personally I do almost ALL my color choosing in HSV, it's a much better match for the way humans think about color than any other I've used. Hue: the color. Red orange yellow green purple. Saturation: how greyed out the color is. Pink is a low-saturation red, brown is a low-sat orange. Value: how dark it is. Poppy red vs. brick red. (HSV is also known as HLS, hue luminance saturation. IIRC there is a slight difference to this model, mathematically, but in practice it is much the same.)
The human eye is MUCH more drawn to contrasts in value than in hue. Two colors with the same value but different hues will vibrate uncomfortably when placed against each other. You can check for this by going to greyscale (in art programs, create a layer at the top of the stack, fill it with white or black, and set it to saturation mode); if two colors become the same grey then change one of them.
2. It's better to pick a single color to use to darken everything when shading; this gives a more unified feeling. Usually the best way to do this digitally is what most art programs call the "multiply" transparency mode, which I believe is simply r1xr2, g1xg2, b1xb2.
4. If you are designing for paper printing then work in the CMYK color gamut from the start. You will save yourself tons of headaches. That said modern high-end printers DO have a wider gamut than older ones, if you're going to be doing professional reproduction then talk to the people doing the printing and get color profiles.
5. Personally I do almost ALL my color choosing in HSV, it's a much better match for the way humans think about color than any other I've used. Hue: the color. Red orange yellow green purple. Saturation: how greyed out the color is. Pink is a low-saturation red, brown is a low-sat orange. Value: how dark it is. Poppy red vs. brick red. (HSV is also known as HLS, hue luminance saturation. IIRC there is a slight difference to this model, mathematically, but in practice it is much the same.)
The human eye is MUCH more drawn to contrasts in value than in hue. Two colors with the same value but different hues will vibrate uncomfortably when placed against each other. You can check for this by going to greyscale (in art programs, create a layer at the top of the stack, fill it with white or black, and set it to saturation mode); if two colors become the same grey then change one of them.
regarding, 2 and 3. check out the HSP color model [1], it works quite well for perceptual luminance matching.
[1] http://alienryderflex.com/hsp.html
[1] http://alienryderflex.com/hsp.html
Thanks leeoniya, I had been looking for exactly this kind of treatment on the subject for years, I'll be using the info from that link in several projects immediately.
i use it myself in a couple projects. mainly my quantizer lib [1]
[1] https://github.com/leeoniya/RgbQuant.js
[1] https://github.com/leeoniya/RgbQuant.js
About colour temperature:
Subjectively (or maybe culturally?), red tones are warm and blue tones are cool.
There's another definition of "colour temperature" (derived from a physical property, rated in Kelvin), in which blue-ish tones are warmer than red, white being the hottest. This is based on the light emission of very hot bodies (you can tell the temperature by the color it glows).
This second definition of "colour temperature" might be counter-intuitive but is used to rate light sources and in photography, so you have to know the context the term is used.
Subjectively (or maybe culturally?), red tones are warm and blue tones are cool.
There's another definition of "colour temperature" (derived from a physical property, rated in Kelvin), in which blue-ish tones are warmer than red, white being the hottest. This is based on the light emission of very hot bodies (you can tell the temperature by the color it glows).
This second definition of "colour temperature" might be counter-intuitive but is used to rate light sources and in photography, so you have to know the context the term is used.
Blue is hotter than white by the kelvin scale.
The hue attributed to black body radiation at a certain temperature represents the average color of the whole gamut of emitted frequency/intensities, which follows a curve with a peak that changes with the temperature (which is then perceived by the eye); this curve is a direct result of Planck's law.
At temperatures < 3000K, this is reddish At temperatures between 3000-6000K, it becomes orange and then yellow At temperatures around 6500K, it is white (this is close to sunlight, so the eye is tuned to this distribution and sees it as even) At above 6500, it becomes increasingly blue.
The hue attributed to black body radiation at a certain temperature represents the average color of the whole gamut of emitted frequency/intensities, which follows a curve with a peak that changes with the temperature (which is then perceived by the eye); this curve is a direct result of Planck's law.
At temperatures < 3000K, this is reddish At temperatures between 3000-6000K, it becomes orange and then yellow At temperatures around 6500K, it is white (this is close to sunlight, so the eye is tuned to this distribution and sees it as even) At above 6500, it becomes increasingly blue.
That's right, thanks for the correction.
Adding one important fact - computing color distance between two colors in order to identify similar colors doesn't work well in any color model (often matching colors with reduced vibrance). What you need to do is to define overlapping color regions (e.g. this is yellowish, that is greenish etc.) and treat this information as more important than the computed distance for similarity matching.
That's not quite true. That's what the Lab color space is intended to allow.
https://en.wikipedia.org/wiki/Lab_color_space
https://en.wikipedia.org/wiki/Lab_color_space
Yes, that's an attempt to solve this problem however if you try to use it for color matching you'd find problematic areas there as well, hence you still need to use color regions.
Something some might not know of is the great colour scheme designers available on the Web, I quite like colour scheme designer 3 [0] - hit triad, click around and then click the colour list tab for complementary colours for all three.
[0] http://colorschemedesigner.com/csd-3.5/
[0] http://colorschemedesigner.com/csd-3.5/
Neat!
On a related note, I recently helped write a "Color Theory Basics" guide for Thinkful (my current employer). Some of you might enjoy this: http://www.thinkful.com/learn/color-theory-basics/
This guide is more applicable towards branding and marketing.
On a related note, I recently helped write a "Color Theory Basics" guide for Thinkful (my current employer). Some of you might enjoy this: http://www.thinkful.com/learn/color-theory-basics/
This guide is more applicable towards branding and marketing.
> This is the traditional “adding” of colours together to produce new colours. (Said of RGB.)
But it's only "traditional" in computer graphics. Paint is subtractive, and so is printing. If your color background is one of these more traditional fields, then additive is most definitely not traditional.
But it's only "traditional" in computer graphics. Paint is subtractive, and so is printing. If your color background is one of these more traditional fields, then additive is most definitely not traditional.
> But it's only "traditional" in computer graphics.
And lighting.
And lighting.
* John the May guy - http://johnthemathguy.blogspot.com/ - Breaks down advanced color math/science concepts in very plain English. Complete with helpful charts and graphs. He's very approachable if you have questions. If you are in the print/GC industry, you'll probably run into him at trade shows.
* Bruce Lindbloom - http://www.brucelindbloom.com/ - Look past the tacky website and into the "Math" and "Calc" sub-sections. Tons of great theory, formulas, and calculators. Make sure you doublecheck the formulas against other sources, I did run into a small discrepancy or two (that I can't recall). I've also been able to get responses from him through email, which is nice.
* EasyRGB - http://www.easyrgb.com/index.php?X=MATH - More transform/delta E functions. Some of these are kind of crude, so I tend to look at Bruce Lindbloom or CIE directly when possible, but EasyRGB can sometimes fill in some gaps.
* python-colormath - http://python-colormath.readthedocs.org/ - And of course, I can't resist shamelessly plugging my Python color math module.
Color math is funky stuff, and at times very hard to get help with. There aren't many easily-reached people out there that have a deep understanding of it. But if you keep hammering your head against it, you'll learn through osmosis over time.
If this is something that interests you enough, RIT and I think Cal Poly both have color science degrees and certificates. Imaging companies eat these graduates up in a hurry.