The section about our eyes doesn’t talk about something that I think is pretty wild: the reason L and M are so similar is not just optimisation for our environment, but a consequence of our messy evolutionary history. Mammals, sadly, lost two colours early on, otherwise we’d have four-colour vision (this was probably because colour vision isn’t very useful at night), and primates had to evolve trichromacy anew. We did this by… just copypasting the L gene and tweaking it a little bit.
There’s also this:
The reason green (#0F0) appears brighter than blue (#00F) is because of the way the yellowish-green-receiving M cone spans almost the entire visible spectrum, while the blue-and-purple S cone spans under half of it. A green light is going to activate more cone cells than a blue one, making that green appear brighter.
Which is a slightly iffy explanation. “A green light is going to activate more cone cells” is true, but it’s not because of the M cones’ wide spectrum. Unlike eyeballs, computer monitors were designed, and their design objective is to stimulate our cone cells. So green pixels emit almost all their light in the peak sensitivity region for the average human’s M cones; the rest of the M sensitivity spectrum is just not relevant to them. There are two reasons green light activates more cone cells:
L cones are somewhat sensitive to green light
The overwhelming majority (>90%) of our cone cells are L and M
PS. The article talks about “activating more cones” as if cones are either on or off, and I’ve done the same for convenience, but in reality they’re analogue, so we’re really talking about “activating more cones more strongly”.
I don’t like that shade of blue
Nobody does. But there are no universal solutions.
I’m curious, can’t you (i.e. xterm dev Thomas E. Dickey, linux fb console devs) set the default blue to something other than the blue nobody likes? Was it more visible on CRTs which is why we’re stuck with it?
Was it more visible on CRTs which is why we’re stuck with it?
It was, because the blue was 100% blue pixel. That 00F colour seems to have been translated to something close to 00007F which is at least half the brightness thus making it difficult to see.
I’ve found the dark blue is much more readable with bolder and thicker fonts. I suspect this was the case on many older machines and monitors; DPI has been slowly marching higher over time so this problem has slowly been getting worse.
Was it more visible on CRTs which is why we’re stuck with it?
Just speaking from my own experience of using PC text terminals since the 1980s, a lot of it is due to shrinking pixel sizes. However, it’s worth remembering that on older CRTs, the brightness and contrasts knobs were right there at your fingertips. I would frequently adjust my settings to have a higher brightness and lower contrast so that dark blue would be more visible. (And then adjust them back to defaults when e.g. playing a game.)
I’m surprised the colour chosen hasn’t been updated, or standardised.
Historically the blue was chosen due to how graphics worked in early computing history, they often only had so much memory available and using three bits per pixel allowed the computer to tell the monitor which of the three pixels should light up R, G or B, or none, or all three.
I am guessing here, but the blue originated as 00F, which wasn’t translated to 0000FF for modern systems, but instead translated to 00007F which is close to the dark blue we commonly see, it should in my mind be 0000FF to be equal to what it looked like on an actual CRT.
That makes sense, but I do seem to remember “use bright colors for bold” was a terminal option back in the CRT era. Pretty sure even under DOS (Telix). If dark or non-bright blue was 00F/0000FF, what was bright blue?
Excellent work. It looks like you made this in 2020? If this were around a few years earlier, I’d probably never have tried to solve it via “ML” (as described in my earlier comment) - not that I actually succeeded!
I’m not good at picking colors, so I’ve been using Reasonable Colors for everything.
In my terminal, $EDITOR, qutebrowser theme, everywhere. It’s nice to be able to pick things from there that seem okay, and then it looks nice with everything else that’s on screen.
The lone holdout seems to be PuTTY, which, despite regular updates, keeps using a colour scheme from the ’90s.
This is true but you are able to customize the colors in PuTTY (I used to run the Solarized scheme). The author mentions this but in their case they were not able to save the config.
BTW I love PuTTY but now Windows Terminal is far enough along that I didn’t bother to install it on my recent machine.
This, along with yellow on white, is one of the big reasons why I wrote my own terminal emulator. My solution was more than just changing the palette, but also using different palettes on different combinations. So if you print blue on black, it will use a different blue than if it is the same code on a white background, in order to ensure both can easily be seen.
Of course, I wrote it for me, so I just did what works for me without worrying about what palette others want or backward compatibility etc.
For the basic 16 colors, I put in some hand checks. Like if(foreground=x && background=y) foreground=z special cases. For 24 bit color, I quantize them back to a smaller palette and do a HSL contrast check which isn’t perfect but 24 bit color is useless and any application that uses it probably doesn’t deliver value to me anyway so i don’t really care if they don’t work quite right.
Note the “original” CGA palette used 0xAA for low intensity and 0xFF for high intensity colors. I’m still not sure where the 0x80 low intensity color palette came from - on the PC it happened some time around the move to GUI, which I’d assumed was because systems frequently had 16 colors total, so the command line had to stick with the GUI palette. The requirement to do that hasn’t existed since moving to 256 colors.
I recently switched back to using a CGA palette everywhere, and am impressed at just how much more beautiful everything is.
Some eyes are different than other eyes. E.g., I’m red & green color blind. As a result, I’m most comfortable supressing all colors in command line programs and using a white background and black (or very dark grey) text in the terminal itself. Everything else quickly ends up painful and confusing.
I guess my point is, please always provide a --no-color flag.
I prefer the --no-color flag, even though my eyes perceive the three colors. Sometimes it’s easier to read contents than struggling filtering out some attention grabbing highlighted keywords.
The problem of contrast between colors with the default xterm color scheme is even more apparent if you prefer a white background, as do I. Ideally terminals should switch the default scheme based on the users background color. I found these color schemes by Markus Weimar and they do a good job of optimizing for contrast and also offer two variants, one for white backgrounds and one for black backgrounds.
This is one of the first things I fix on a new machine – just did it a couple days ago! It makes sense that this would be a struggle for others as well but I’m not sure why I thought it was just a me thing :)
This article has some fun and geeky details on a common problem for all multi-platform terminal lovers. I cover color palettes in my dotfiles README here:
The way I personally solved this is by always looking for a “Tango color palette” in any given tool. Tango was “standardized” way back in the mid-2000s as part of the FreeDesktop.org initiative. Though it’s a bit of a footnote of history nowadays, it’s still a reference point that you tend to find lots of contributions around, aligning with the “standard”.
On the real thing, instead of an emulation, this isn’t so unreadble. The fonts don’t have such thin strokes, and the dark blue isn’t usually so dark (though that might depend on what you did with your brightness/contrast knobs).
Wow. Someone acknowledging an elephant in the room and I didn’t notice. I had a cheat sheet of registry commands or something that I used for Putty back in the day. The way you update Putty profiles or defaults is unbelievably clunky. There was a paid ssh client for windows that was better UX.
Yeah, I have a different substitute color for bold blue for every connection on every host because for each new connection I just pick anything bluish from the color palette.
Several years back, frustrated by this same problem and underlying constraints, I spent a weekend writing a machine-aided cost minification algorithm (aka what most startups call “advanced ML”) that used LAB and LUV to try and pick 2x8 colors (the eight colors in dark/bright configurations) where the cost was defined as
a) how far apart each of the color pairs was from one another (hue only),
b) how far apart each dark/bright color in a pair were from one another,
c) how high the contrast against a specific background color (provided as a parameter),
d) how far the perceived brightness of any “bright” color differed from the rest of the “bright” colors,
e) how far the perceived brightness of any “dark” color differed from the rest of the “dark” colors,
f) how far each of the 8 base colors strayed from a range that could passably be called the de facto colors mapped to each of the palette members (e.g. cyan, blue, black, white, etc) so that TUI apps using colors not to distinguish but to draw (expecting “blue” to be a shade of blue) would not be thrown off.
Unfortunately I never found the results to be pleasing to the eye. I also think there was something wrong in either the math of the individual cost function factors themselves or the weights assigned to each factor because I didn’t feel like the results were properly spaced out or representative of what even a local minima what look like if the math was all correct. I didn’t really want to put more time into it than I already had, but I’m convinced that it’s possible to generate a fixed set of 2x8 colors that meet these conditions for any given background color (at least one for a black or dark grey background and another palette for a white or off-white background).
I think I still have the MATLAB code somewhere. Maybe I’ll give it another gander if I ever get some time.
The section about our eyes doesn’t talk about something that I think is pretty wild: the reason L and M are so similar is not just optimisation for our environment, but a consequence of our messy evolutionary history. Mammals, sadly, lost two colours early on, otherwise we’d have four-colour vision (this was probably because colour vision isn’t very useful at night), and primates had to evolve trichromacy anew. We did this by… just copypasting the L gene and tweaking it a little bit.
There’s also this:
Which is a slightly iffy explanation. “A green light is going to activate more cone cells” is true, but it’s not because of the M cones’ wide spectrum. Unlike eyeballs, computer monitors were designed, and their design objective is to stimulate our cone cells. So green pixels emit almost all their light in the peak sensitivity region for the average human’s M cones; the rest of the M sensitivity spectrum is just not relevant to them. There are two reasons green light activates more cone cells:
PS. The article talks about “activating more cones” as if cones are either on or off, and I’ve done the same for convenience, but in reality they’re analogue, so we’re really talking about “activating more cones more strongly”.
That has always bothered me as well. Yeah it’s configurable to change indexed colors but WHY make this the default?
The linked xterm FAQ in the article says
I’m curious, can’t you (i.e. xterm dev Thomas E. Dickey, linux fb console devs) set the default blue to something other than the blue nobody likes? Was it more visible on CRTs which is why we’re stuck with it?
It was, because the blue was 100% blue pixel. That
00Fcolour seems to have been translated to something close to00007Fwhich is at least half the brightness thus making it difficult to see.Actually, it probably wasn’t 100% blue, because then bold blue wouldn’t have been able to be brighter.
(And yes, an alternative would have been to boost the red and green up, but I never saw a terminal that did that in its default settings.)
I’ve found the dark blue is much more readable with bolder and thicker fonts. I suspect this was the case on many older machines and monitors; DPI has been slowly marching higher over time so this problem has slowly been getting worse.
Just speaking from my own experience of using PC text terminals since the 1980s, a lot of it is due to shrinking pixel sizes. However, it’s worth remembering that on older CRTs, the brightness and contrasts knobs were right there at your fingertips. I would frequently adjust my settings to have a higher brightness and lower contrast so that dark blue would be more visible. (And then adjust them back to defaults when e.g. playing a game.)
I’m surprised the colour chosen hasn’t been updated, or standardised.
Historically the blue was chosen due to how graphics worked in early computing history, they often only had so much memory available and using three bits per pixel allowed the computer to tell the monitor which of the three pixels should light up R, G or B, or none, or all three.
I am guessing here, but the blue originated as 00F, which wasn’t translated to 0000FF for modern systems, but instead translated to 00007F which is close to the dark blue we commonly see, it should in my mind be 0000FF to be equal to what it looked like on an actual CRT.
That makes sense, but I do seem to remember “use bright colors for bold” was a terminal option back in the CRT era. Pretty sure even under DOS (Telix). If dark or non-bright blue was 00F/0000FF, what was bright blue?
Yes, exactly. My solution to choosing terminal colors: https://justinpombrio.net/archive/terminal-colors.html
Excellent work. It looks like you made this in 2020? If this were around a few years earlier, I’d probably never have tried to solve it via “ML” (as described in my earlier comment) - not that I actually succeeded!
I’m not good at picking colors, so I’ve been using Reasonable Colors for everything.
In my terminal,
$EDITOR, qutebrowser theme, everywhere. It’s nice to be able to pick things from there that seem okay, and then it looks nice with everything else that’s on screen.This is true but you are able to customize the colors in PuTTY (I used to run the Solarized scheme). The author mentions this but in their case they were not able to save the config.
BTW I love PuTTY but now Windows Terminal is far enough along that I didn’t bother to install it on my recent machine.
This, along with yellow on white, is one of the big reasons why I wrote my own terminal emulator. My solution was more than just changing the palette, but also using different palettes on different combinations. So if you print blue on black, it will use a different blue than if it is the same code on a white background, in order to ensure both can easily be seen.
Of course, I wrote it for me, so I just did what works for me without worrying about what palette others want or backward compatibility etc.
Interesting, how are the effective colors calculated?
For the basic 16 colors, I put in some hand checks. Like
if(foreground=x && background=y) foreground=zspecial cases. For 24 bit color, I quantize them back to a smaller palette and do a HSL contrast check which isn’t perfect but 24 bit color is useless and any application that uses it probably doesn’t deliver value to me anyway so i don’t really care if they don’t work quite right.Note the “original” CGA palette used 0xAA for low intensity and 0xFF for high intensity colors. I’m still not sure where the 0x80 low intensity color palette came from - on the PC it happened some time around the move to GUI, which I’d assumed was because systems frequently had 16 colors total, so the command line had to stick with the GUI palette. The requirement to do that hasn’t existed since moving to 256 colors.
I recently switched back to using a CGA palette everywhere, and am impressed at just how much more beautiful everything is.
Some eyes are different than other eyes. E.g., I’m red & green color blind. As a result, I’m most comfortable supressing all colors in command line programs and using a white background and black (or very dark grey) text in the terminal itself. Everything else quickly ends up painful and confusing.
I guess my point is, please always provide a
--no-colorflag.I prefer the
--no-colorflag, even though my eyes perceive the three colors. Sometimes it’s easier to read contents than struggling filtering out some attention grabbing highlighted keywords.The problem of contrast between colors with the default xterm color scheme is even more apparent if you prefer a white background, as do I. Ideally terminals should switch the default scheme based on the users background color. I found these color schemes by Markus Weimar and they do a good job of optimizing for contrast and also offer two variants, one for white backgrounds and one for black backgrounds.
This is one of the first things I fix on a new machine – just did it a couple days ago! It makes sense that this would be a struggle for others as well but I’m not sure why I thought it was just a me thing :)
This article has some fun and geeky details on a common problem for all multi-platform terminal lovers. I cover color palettes in my dotfiles README here:
https://github.com/amontalenti/home#terminal-and-editor-colors
The way I personally solved this is by always looking for a “Tango color palette” in any given tool. Tango was “standardized” way back in the mid-2000s as part of the FreeDesktop.org initiative. Though it’s a bit of a footnote of history nowadays, it’s still a reference point that you tend to find lots of contributions around, aligning with the “standard”.
At first I thought this was going to be about Motif blue, which I rather like, honestly.
On the real thing, instead of an emulation, this isn’t so unreadble. The fonts don’t have such thin strokes, and the dark blue isn’t usually so dark (though that might depend on what you did with your brightness/contrast knobs).
Wow. Someone acknowledging an elephant in the room and I didn’t notice. I had a cheat sheet of registry commands or something that I used for Putty back in the day. The way you update Putty profiles or defaults is unbelievably clunky. There was a paid ssh client for windows that was better UX.
Yeah, I have a different substitute color for bold blue for every connection on every host because for each new connection I just pick anything bluish from the color palette.
Several years back, frustrated by this same problem and underlying constraints, I spent a weekend writing a machine-aided cost minification algorithm (aka what most startups call “advanced ML”) that used LAB and LUV to try and pick 2x8 colors (the eight colors in dark/bright configurations) where the cost was defined as
a) how far apart each of the color pairs was from one another (hue only),
b) how far apart each dark/bright color in a pair were from one another,
c) how high the contrast against a specific background color (provided as a parameter),
d) how far the perceived brightness of any “bright” color differed from the rest of the “bright” colors,
e) how far the perceived brightness of any “dark” color differed from the rest of the “dark” colors,
f) how far each of the 8 base colors strayed from a range that could passably be called the de facto colors mapped to each of the palette members (e.g. cyan, blue, black, white, etc) so that TUI apps using colors not to distinguish but to draw (expecting “blue” to be a shade of blue) would not be thrown off.
Unfortunately I never found the results to be pleasing to the eye. I also think there was something wrong in either the math of the individual cost function factors themselves or the weights assigned to each factor because I didn’t feel like the results were properly spaced out or representative of what even a local minima what look like if the math was all correct. I didn’t really want to put more time into it than I already had, but I’m convinced that it’s possible to generate a fixed set of 2x8 colors that meet these conditions for any given background color (at least one for a black or dark grey background and another palette for a white or off-white background).
I think I still have the MATLAB code somewhere. Maybe I’ll give it another gander if I ever get some time.
What do you think of Solarized?