What's so wrong with HSV?

Well, the main problem is that the value component of HSV is just a measure for the physical lightness of color, but not for the perceived brightness. Thus, fully saturated yellow has the same "value" as blue. The same is true for the HSL color space. Here is a set of six colors of the same value to demonstrate this effect. The second row shows how the colors look after converting to grayscale via Photoshop.

Beside of this strong hue-dependency of brightness, there is also no linear brightness gradient within a single hue. For instance, in the following HSL color scale the brightness step between the second and the third red appears much bigger than the step between the 3th and 4th color. Even worse, this effect seems to differ across different hues, as the comparison to the blue scale shows.

After all, this should be enough reason to avoid equidistant HSV/HSL scales. But what options do we have instead?

For the lazy ones: Use ColorBrewer

So the question is, what shall we do about it? In the comments someone mentioned ColorBrewer, which is in fact a great solution for those who just want to get some colors without caring too much about the details. Here's a selection of sequential ColorBrewer scales.

One drawback of this solution is that you're limited to a fixed number of colors. For each color scale, the collection gives you variants from 3 to 9 colors. Another drawback is that sticking to a predefined set of colors means giving away some artistic freedom. Also, and most importantly, it's not half as fun to pick existing solutions, isn't it?

For the color geeks: Make friends with CIE L*a*b*

At this point, you better prepare yourself for some ultimate color geekyness. Thanks to the gentle introduction of David Dalrymple, I finally dared to enter the magic world of the CIE L*a*b* color space. To get a better understanding of this color model, I ported David's code to JavaScript and built a tiny Lab color selector. The vertical slider allows you to navigate through the space. Also you can change the x and y axis using the links next to the slider.

In general, the Lab color space has one component for Lightness and two bipolar color components a (yellow-blue) and b (green-magenta). While the lightness ranges from 0% to 100%, determining the valid ranges for a and b is somewhat tricky.

The problem is that CIE L*a*b* contains more colors than are available in RGB. For instance, the "valid" range for a depends on the lightness and the second color channel. Another problem is that it's hard to select colors by mixing four colors. To get around those issues, David Dalrymple suggests a fancy transformation of the Lab space.

CSL: Making CIE Lab more accessible

The trick is easy. You use the a and b components to compute a color angle (hue) and a radius (saturation). Because it's not exactly the same as hue in HSV, it's named c (for chroma). Basically this gives this us the CSL color space (although I'm not sure how this is named in vis science).

While the problem of non-existent colors still remains (especially if you increase saturation) this looks like something we can start to work with. For instance, if we take a look at equidistant CSL colors of the same lightness we get a much better result. Actually, if you'd convert this into grayscale again you get the exact gray value for all colors. Well, this is no big surprise, I bet Photoshop itself uses CIE L*a*b* for grayscale conversions.

Now, let's grab some colors..

This is where the fun begins, so I'm glad you made it up to here. To learn more about the difference of equidistant colors across color spaces, I visualized the linear gradient in the color selector. Feel free to experiment with them and check how the CSL color space compares to other spaces like LAB, HSV, HSL or RGB.

Also, it's interesting to directly compare the interpolated colors across different color spaces:

Nice! How do I get those colors?

To make things easy, I packed everything up in a small JavaScript library named chroma.js. It has a simple yet powerful API,check out the Github repository to learn more. Since this is still in early beta phase, l'd appreciate if you document bugs you may encounter.

// most simple interpolation in CSL space
chroma.interpolate("#383D41", "#EFEE69", 0.5, 'csl').hex(); 
// returns "#5C9A7C"
 
// also, you can instantiate CSL colors directly 
chroma.csl(60, .7, 1).hex();
// returns "#C6A860"

To be honest, the first time I saw this map I didn't thought much about it. Ok, poverty is highest in south central of the United States, especially near Mexican border. But recently I used the same data to demonstrate a choropleth map that I created from-scratch and I was really surprised to see a somewhat different picture:

Naturally, I wanted to know where the differences come from and spent some time to investigate. Actually, I think there are two big fails in the Guardian map (which was made using Google Fusion tables).

Don't mess around with your class limits

The values in the poverty data range from 6.6% to 22.7% and the map shows them divided into five classes. If one would compute the exact equidistant class limits between the minimum and maximum value one would come up with the following classes (the gray bar is used to indicate the data range):

I'm not sure if this is the default behaviour of Google Fusion Tables or the editors choice, but the Guardian map used the class limits 6-9%, 9-12%, 12-15%, 15-18% and 18-23%. Due to the round numbers one might think that they are easier to understand than the fractioned numbers above, but this comes at the high price of distorted class distribution:

Note that the fifth class (which shows the poorest states) is blown up while the first class is a bit under-represented. Given the highly political topic, I'd argue that while we're trying to map inequality, we should at least use equally distributed classes.

Don't mess around with your class colors

The second big failure of the map is the choice of colors. This colors were used for the Guardian map:

Obviously there's a large jump between the first and second class and an enormous jump between the fourth and fifth color. The fourth color looks like taken from a completely different gradient and is hardly distinguishable from the third color. Again, I'm not sure if this is some kind of default in Google Fusion tables, but maybe they were just hand-picked.

Instead, in my map I simply used equidistant colors from a HSV gradient:

But, as mentioned in the comments below, even equidistant HSV colors are not the best option. The problem is that humans perception of brightness differs from the arithmetical lightness of HSV colors.

To demonstrate this difference, let's compare the equidistant HSV colors to a hand-picked color scale from colorbrewer2.org:

Quite a different picture, isn't it?

And better think twice about your class count

Another question is why we should use five classes at all. It's kind of interesting to see how "dramatically" the picture changes if one changes the number of classes. Given the fact that we're living in the age of interactive maps that allow us to read data values from tooltips, there's no more reason to be stingy with colors. At least, I think a number of seven classes should be a better trade-of between correctness and color distinguishability.

Be careful when visualizing non-area-related data using choropleth maps

At the end I just want to mention another well-known problem of choropleth maps. The visual significance of a particular geographic region depends on the color value multiplied with the area of that region. Thus, a larger but equally colored region appears more important than a smaller one. Especially when you're dealing with non-area related data, like the poverty of human beings, this might cause additional mis-interpretations. One way to get around this is to use cartograms, which aim to resize geographic regions according to a measurement that has more relevance to the context of the data. For instance, in the next image you can see a Dorling cartogram (where circles represent regions) that sizes the states according to 2010 population. This way, we visually relate the poverty rates to the affected population instead of the affected area.

So, what to do next? For me, the clear answer is that we need better educated map makers and, perhaps more importantly, we need better open source tools for thematic mapping. That's what I'm kind of working on right now..

Update: Jorge Camoes wrote a kind of follow-up post to this one, called The same data, the same map, different stories. Make sure to check it out as well.

I bet the reason for the popularity of red-green color scales is that they are so easy to interpret (at least in my culture). Green means good, red means bad. For instance, the above map shows the income of private households for European regions. I used a diverging color scale to show the difference from the average income (bright yellow) with higher incomes in green and lower incomes in red. In fact, I picked the exact colors from good old flare visualization toolkit.

But there's some trouble with this scale. Firstly, as alluded to above, the meaning of red and green vary a lot in different cultures. According to this helpful collection of Color Meanings By Culture, green is negatively associated in some Eastern cultures like China or Indonesia while red is associated to love, happiness and a long life.

The second source of trouble comes in if you want to include dichromats aka color blind people in your audience. Here's a simulation of how someone with Deuteranope color blindness (aka green blindness) would see the red-green scale:

Almost the same problem for people with Protanope color blindness (aka red blindness):

For me, this is enough reason to simply forget about red-green color scales. Forever. Instead, I'll switch to blue-orange scales. After experimenting around a few minutes, I found that hue values of 220° (blue) and 30° (orange) work out fine:

To make a long story short, here are the Deuteranope and Protanope simulations:

Also everything fine with the third kind of Dichromacy called Tritanope or blue blindness.

At the end I want to recommend a perfect tool for on-the-fly simulation of color blindess which is called Sim Daltonism. Many thanks to Michel Fortin for this. If you've heard of a similar tool for Windows and Linux, please let me know.

Update:

Color Oracle is another great tool for turning the whole screen into a color blindness simulation. Also, there's an some research work coming with that tool, namely Color Design for the Color Vision Impaired by Jenny & Kelso, 2007. In short, they're going for purple-green instead of red-green:

Ausgangspunkt ist zunächst der RGB-Farbraum. Um verschiedene Farben zu erzeugen, können einfach zufällige Farben aus dem RGB-Raum ausgewählt werden. Die folgende Darstellung zeigt eine derart getroffene Auswahl von zehn verschiedenen Linienfarben (rechtsklicken um neue Zufallsfarben zu erzeugen):

Die Nachteile dieses Ansatzes sind offensichtlich und sind vor allem auch Nachteile des Farbmodells. Selbst eine gleichverteilte Auswahl von Farben im RGB-Raum würde mitunter zu nahezu identischen Farben führen. Daher habe ich mich im Folgenden auf den HSL-Farbraum konzentriert. Wie alle wahrnehmungsorientierten Farbräume enthält auch der HSL-Raum die Dimension Farbwert - ein Wert zwischen 0° und 360° der den Farbton bestimmt. Die folgende Darstellung zeigt die Auswahl von 10 Farben mit gleichem Abstand im Farbraum (in diesem Fall 36°):

Wie man sieht bekommt man dadurch 10 Ausschnitte aus dem Regenbogenspektrum. Bei genauerem Hinsehen fallen aber immer noch Nachteile auf: So sind vor allem die beiden Grün- und Blautöne schwer voneinander zu unterscheiden. Um eine mögliche Ursache dafür zu nennen mache ich einen kurzen Ausflug zur Wahrnehmungspsychologie. Auf unserer Netzhaut befinden sich zwei Typen von Rezeptorzellen, die sog. Stäbchen und Zapfen. Während die Stäbchen vor allem zum Sehen in der Dämmerung benutzt werden, dienen Zapfen zum Farbsehen. Nun gibt es unter den Zapfen-Zellen wiederum drei verschiedene Typen, wovon jeder zur Wahrnehmung bestimmter Farbfrequenzen geeignet ist. Um die Sache kurz zu machen, es gibt jeweils einen Zapfentyp für rote, grüne und blaue Farbfrequenzen. Und jetzt kommts: die Verteilung der Zapfenzellen ist in etwa 10:1:1 (rot zu grün zu blau). Daher fällt es Menschen naturgemäß leichter, Rottöne voneinander zu unterscheiden als Blau- oder Grüntöne.

Ich habe versucht, diesen Umstand über eine Transferfunktion für die Farbtöne auszugleichen. Die folgende Abbildung zeigt oben einen Farbwertverlauf ohne und unten mit Korrektur. Wie man sehen kann, habe ich einfach den Bereich für grüne und blaue Farbtöne "zusammengedrückt", um mehr Spielraum zwischen Rot und Gelb zu bekommen.

oben: normaler HSL-Verlauf, unten: HSL-Verlauf mit Farbtonkorrektur

Wählt man die 10 Zufallsfarben nun aus diesem, korrigierten Spektrum, erhält man folgendes Resultat:

Die Farbtonkorrektur hat etwas zur Unterscheidbarkeit der grünen und blauen Linien beigetragen. Für den günstigen Fall, das die Linienhelligkeit keine weitere Bedeutung in der Visualisierung hat, kann man die Unterscheidbarkeit der Linien weiter steigern, indem man abwechselnd helle und dunkle Linien verwendet:

Zur Erzeugung der Abbildungen habe ich die ActionScript-Klasse PerceptualColor verwendet. Die Farbwertkorrektur wird über die folgende Klasse HueCorrection gelöst. Ein- und Ausgabe für die Funktion correctHue ist ein Farbwinkel zwischen 0 und 360°.

public class HueCorrection
{
	private static var _tf:Array = [
		[10,5], [30,45], [50,70],
		[70,94], [110,100], [125,115],
		[145,148],[161,174], [182,179],
		[188,185],
		[210,225], [250,255]
	];
 
	public static function correctHue(hue:Number):Number {
		var h:uint = hue / 360 * 255;
		var new_hue:Number;
		var lx:Number = 0;
		var ly:Number = 0;
 
		for (var i:uint=0; i<_tf.length; i++) {
			if (h == _tf[i][1]) {
				new_hue = _tf[i][0];
				break;
			} else if (h < _tf[i][1]) {
				new_hue = lx + ((_tf[i][0] - lx) / (_tf[i][1] - ly)) * (h - ly);
				break;
			}
			lx = _tf[i][0];
			ly = _tf[i][1];
		}
		return new_hue / 255 * 360;
	}
}

Auch wenn das mein Problem damals prinzipiell gelöst hatte, hat dieser Weg einige Nachteile: Zum einen werden auch solche Farben verdunkelt, die man vorher ohne Probleme hätte lesen können. Damit verschenkt man gewissermaßen Farben, da aus einem dunkelrot schnell ein undefinierbares schwarzgraubraun wird. Zum anderen verlieren die Farben damit an Sättigung, der Gesamteindruck wird folglich farbloser (siehe abschließende Visualisierung, Spalte "+50% schwarz").

Diesmal wollte ich es also besser lösen und dazu die Farben in einen wahrnehmungsoptimierten Farbraum umrechnen. Besonders geeignet schienen mir das HSL und HSB-Modell, da dort die vielversprechende Komponente Farbhelligkeit vorkommt. Angenommen, die Helligkeit h ist bekannt, so kann ein einfacher Schwellwert β (= Lesbarkeitsschwelle) festgelegt werden:

Doch welches Modell ist nun besser geeignet? Die Modelle HSL und HSB unterscheiden sich vor allem in der Interpretation der Helligkeit. Bei HSL bezeichnet L die relative Helligkeit (lightness), im Gegensatz zur absoluten Helligkeit B (brightness) bei HSB¹. Schauen wir uns doch zuerst mal an, wie die lightness und die brightness aus einer RGB-Farbe berechtnet werden. Als relative Helligkeit wird einfach der Mittelwert aus der minimalen und maximalen Farbkomponente festgelegt, während die absolute Helligkeit durch eine affine Linearkombination aller dreier Farbkomponenten beschrieben wird²:

Die unterschiedliche Komponenten-Wichtung in der brightness-Berechnung hat den einfachen Grund, dass die Farbkomponenten tatsächlich unterschiedlich hell wahrgenommen werden. Diesen Effekt verdeutlicht die Abbildung 1: Obwohl alle drei Farben eine relative Helligkeit von 50% haben³ nehmen wir die gelbe Schrift eindeutig heller wahr als die blaue. Und eben dieser Unterschied spiegelt sich in den entsprechenden brightness-Werten wieder, bei denen unser blau mit 7%, das grün mit 72% und das gelb mit 93% abschneidet. Sieht ganz so aus, als hätten wir unser Lieblingsmodell gefunden!

Abb.1: Diese drei Farben haben dieselbe relative Helligkeit

Und wo bleibt die Visualisierung???

Um die Ergebnisse der theoretischen Analyse zu verifizieren, habe ich wieder eine kleine Demonstration zusammengebastelt. Auf der Visualisierung verteilt sich jede Menge Text, dessen Farbe sich von links nach rechts und dessen Helligkeit von oben nach unten ändert. Oben links kann man zwischen dem HSL- und HSB-Modell umschalten.

Erwartungsgemäß fällt sogleich der "Einknick" der Lesbarkeit HSL-Modell auf. Versucht man für die Helligkeit eine Schwelle β festzulegen, bis zu der der Text in jeder Farbe noch gelesen werden kann, so muss man sich wegen der schlechten Lesbarkeit des gelben Textes auf etwa 45% begrenzen. Im HSB-Modell kann man die Schwelle schon deutlich höher ansetzen, erst ab etwa 70% stört das grelle Cyan. Aus Neugier habe ich diesen Test anschließend noch auf schwarzem Hintergrund wiederholt, in der Erwartung hier würde sich ein ähnliches Ergebnis zeigen. Zuersteinmal war ich verwundert dass plötzlich der HSB-Raum chaotischer aussieht als der HSL-Raum und ich wollte daraus schon schlussfolgern, dass sich das HSB-Modell nur auf hellem Hintergrund besser eignet als HSL. Schaut man jedoch genauer hin, so findet man auch hier für den HSB-Raum eine bessere Lesbarkeitsschwelle von etwa 24% (im Gegensatz zu etwa 36% bei HSL, wo das dunkelblau sehr schlecht lesbar ist).

Ergebnisse

In der folgenden Visualisierung können die drei genannten Ansätze interaktiv ausprobiert werden.

Fazit

1. Zur Berechnung der Helligkeit von Text zur Feststellung seiner Lesbarkeit eignet sich das HSB-Modell besser als das HSL-Modell. Dies gilt sowohl auf hellem wie auch dunklem Hintergrund.
2. Farbiger Text lässt sich am Monitor angenehmer lesen, wenn er auf schwarzem Grund steht.

API

/*
 * Modes:
 * PerceptualColor.HSV, PerceptualColor.HSL, PerceptualColor.HSI
 */ 
 
var color:PerceptualColor;
 
// Konstruktoren
color = new PerceptualColor(mode:String = 'hsl');
color = PerceptualColor.fromInt(i:uint, mode = 'hsl');
color = PerceptualColor.fromHex(h:String, mode = 'hsl'); // format: "#RRGGBB"
color = PerceptualColor.fromRGB(r:uint, g:uint, b:uint, mode = 'hsl');
color = PerceptualColor.fromHSV(h:Number, s:Number, v:Number, mode = 'hsv');
color = PerceptualColor.fromHSL(h:Number, s:Number, l:Number, mode = 'hsl');
color = PerceptualColor.fromHSI(h:Number, s:Number, i:Number, mode = 'hsi');
 
// RGB-Setter (Getter äquivalent)
color.intValue = 0x00BBFF;
color.hexValue = "#00BBFF";
color.red = 0;
color.green = 125;
color.blue = 40;
color.setRGB(0, 125, 40);
 
// HSX-Setter (Getter äquivalent)
color.hue = 0;
color.saturation = 0.6;
// nur im HSV-Modus
color.value = 1;
color.setHSV(0, 0.6, 1);
// nur im HSL-Modus
color.lightness = 1;
color.setHSL(0, 0.6, 1);
 // funktioniert nur im HSV-Modus
color.intensity = 1;
color.setHSI(0, 0.6, 1);
 
// Modus ändern
color.mode = PerceptualColor.HSL;

Usage Examples

/*
 * Beispiel 1:
 * Einlesen einer Integer-Farbe, Sättigung auf 50% setzen, Hex-Farbe ausgeben
 */
var color:PerceptualColor = PerceptualColor.fromInt(0xFF0000);
color.saturation = 0.5;
trace(color.hexValue); // Ausgabe: "#BF3F3F"
 
/*
 * Beispiel 2:
 * Einlesen einer RGB-Farbe, Helligkeit auf 70% begrenzen, RGB-Were ausgeben
 */
color = PerceptualColor.fromRGB(220, 250, 180);
if (color.lightness > 0.7) color.lightness = 0.7;
trace(color.red, color.green, color.blue); // Ausgabe: "188 245 111"
 
/*
 * Beispiel 3:
 * Einlesen einer HSV-Farbe, Umwandlung in den HSL-Raum, Helligkeit auf 50% setzen,
 * zurück in den HSV-Raum umwandeln, Ausgabe
 */
color = PerceptualColor.fromHSV(0, .7, .9);
trace(color.hue, color.saturation, color.value); // Ausgabe: "0 0.7 0.9"
color.mode = PerceptualColor.HSL;
trace(color.hue, color.saturation, color.lightness); // Ausgabe: "0 0.755 0.582"
color.lightness = 0.5;
color.mode = PerceptualColor.HSV;
trace(color.hue, color.saturation, color.value); // Ausgabe: "0 0.861 0.874"

Download