# What's the deal with terminal colors?

There are 256 terminal color escapes available:

• 8 "system" colors (0 - 7)
• 8 "bright" system colors (8 - 15)
• 216, or 6*6*6 "RGB" colors (16 - 231)
• 24 "grayscale" colors (232 - 255)

The "RGB" colors are what I'm wondering about.

The first six colors, from 16 to 21, map to the following hex RGB values:

• 16: 000000
• 17: 000054
• 18: 000087
• 19: 0000af
• 20: 0000d7
• 21: 0000ff

Now the blue values only, in decimal:

• 16: 0
• 17: 84
• 18: 135
• 19: 175
• 20: 215
• 21: 255

In other words, the RGB value goes up by 84, then 51 (84 + 51 = 135), then 40 the rest of the way.

This cycle of 6 values from 0 to 255 is repeated 36 times, first with blue, then green, then red, eventually forming our "cube" of 216 terminal colors:

My question is: Why?

Does anyone know if there is a historical/technical reason for this, or was it just an arbitrary decision made by whoever had to decide what the color codes meant? Did this mapping come to exist before RGB was such a universal convention? Why not go up by 42, 42, 42, 43, 43, 43?

• For me, color number 17 is #00005F (tested in xterm, gnome-terminal, konsole, terminology, st). That is, it goes up by 95, and then 5 times by 40. Still doesn't make too much sense, though. Apr 25, 2015 at 21:38
• "Why not go up by 42, 42, 42, 43, 43, 43?" You did the math incorrectly. 6x6x6 cube means 5 steps from one end to the other, not 6. That is, you should increment by 51 in each step. I'm really not sure though that that'd look evenly distributed to the human eye. Apr 25, 2015 at 21:39
• Just for reference, let's mention that several terminal emulators (e.g. gnome-terminal, konsole, st) support arbitrary #rrggbb colors via escape sequences. Alas, support from applications is quite poor. Apr 25, 2015 at 21:41
• To me, the big question is not why the 6x6x6 color cube looks like this. To me, the big question is why palette-free direct RGB hasn't taken over yet, and why developer are not pushing hard for this. Apr 25, 2015 at 21:45

In the sense suggested, it was "arbitrary": a developer chose to split up the set of 256 colors by reserving the first 16 colors to match existing usage, and then noticed that he could get a cube after discounting a conveniently-sized grayscale ramp. Neither of the developers (256 or 88) referred to human-factors publications. They simply chose the steps of color for convenience in computation and what "looked nice".

The technical details as such are in the xterm FAQ Can I set a color by its number?

In a course that I took in college, it was said to me that the human eye can detect about 256 shades of any one color [or so close that a byte can effectively match that], so 256 of each of the three primary colors allows for all of the colors that the human eye can see. The rest I am unsure of.

• Found this on wikipedia: en.wikipedia.org/wiki/Web_colors#Web-safe_colors "A set of colors was needed that could be shown without dithering on 256-color displays; the number 216 was chosen partly because computer operating systems customarily reserved sixteen to twenty colors for their own use; it was also selected because it allows exactly six equally-spaced shades of red, green, and blue (6 × 6 × 6 = 216), each from 00 to FF (including both limits)." Jul 16, 2014 at 1:33
• The color mapping has me intrigued. Jul 16, 2014 at 1:34
• They're not equally spaced, though--the first two go up by 84 and 51, then the rest by 40. It's entirely possible that the decision was totally arbitrary, but I'm just terribly fascinated as to the potential reasoning if it wasn't. Jul 16, 2014 at 14:43
• The base 16 system colors are most likely throwbacks that never got changed when 256 color VGA entered int the picture (that really wasn't meant as a play on words :) Jul 16, 2014 at 16:28

egmont's comment gives a hint:

I'm really not sure though that that'd look evenly distributed to the human eye.

Below is a comparison of the web-safe color palette to the terminal color.

Try to trace the color from bottom left (absolute green) to top right (absolute blue). If you find that the terminal palette blends the color more naturally, you might be right. In case you find it difficult to see how the color changes due to the surrounding colors, I've prepared two rows of black-blue gradient on the bottom left, and green-blue gradient on the bottom right. The top row corresponds to linear RGB value, while the bottom row is what the terminal palette uses (Note: I'm using the palette specified in the question).

The choice of the values in the terminal palette is actually grounded on gamma correction. You may want to check out Minute Physics' video on this topic. Basically, we are able to better perceive increase in brightness in the dark regions compared to the bright regions. Therefore, instead of assigning brightness values linearly to actual light intensity, a mapping is done so that dark colors cover a larger range of values when saving the color as data.

Looking at the black-blue gradient in the image, we see that the top row is biased towards dark shades of blue, while the bottom row is more evenly spread. Meanwhile, the top row in the green-blue gradient seems to be darker in the middle compared to the edges, while in the bottom row the transition seems more smooth.