> rainbow palette for use in my data visualisations.
Indeed for her kind of data the rainbow palette works okay. But if you have to visualize more complex / denser data, beware of the pitfalls of the rainbow color palette. It is not always the best choice.
IBM did research back in the 90s on perceptually-based colormaps and how to best represent various types of data within the color dimensions of luminescence, saturation and hue [1]. For example, they found that,
(1) Hue was not a good dimension for encoding magnitude information, i.e. rainbow color maps are bad.
(2) The mechanisms in human vision responsible for high spatial frequency information processing are luminance channels. If the data to be represented have high spatial frequency, use a color map which has a strong luminance variation across the data range.
(3) For interval and ratio data, both luminance- and saturation-varying color maps should produce the effect of having equal steps in data value correspond to equal perceptual steps, but the first will be most effective for high spatial frequency data variations and the second will be most effective for low spatial frequency variations.
===
[1] the original link got removed from IBMs website. Back in the day it was under
A whole lot of work has been done more recently on "perceptually uniform" color palettes. See the Brewer color palette family, the "scientific colourmaps" by Crameri, and the Viridis color palette family, the latter of which was famously adopted by Matplotlib several years ago.
Note that most modern palettes are designed with various forms of color blindness in mind. For that purpose, they artificially restrict the range of colors, which in turn reduces the visual information they can carry for the vast majority of people who have normal color vision.
I'd be super interested to see a study that examines how color blindness-aware design affects people without color blindness. Such design often completely avoids red hues, which are of huge importance as visual cues to normally sighted people. It's hard to imagine this doesn't have a negative impact somehow, yet I've never seen this discussed anywhere.
My subjective experience is that good color palettes don't have too many colors anyway. Colorblind-friendliness tends to mean avoiding pairs of complementary colors that don't necessarily convey information well anyway.
Remember that we are talking about data visualization, not color palettes in general. Red is not particularly important in data viz.
Consider that many non-color-blind Dota players use the colorblind settings because they like the colors better.
Traditionally, red is used to indicate problematic or dangerous values. This is backed up by a long cultural history, at least in the Western cultural context, that associates red with danger.
I'd say this fact alone makes the color red extremely important in data visualization. The current trend of "but some people can't see red, so let's just use yellow and blue everywhere" seems utterly inadequate for addressing both the importance of red and the problem of color blindness.
They're designed with color blindness in mind for good reason. Prevalence in males is between 5-10% but in my experience it's higher in software industry, for whatever reason.
Of course restricting available colors affects the diversity of palettes, but often designs can accommodate both handily.
It's nearly 2023 and many, many charts are interactive. There's little excuse to at least having a color blind mode be opt-in for such things. If we're all looking at charts on our personal devices, then local accomodations render your entire argument moot.
Where is the research to back this up? While I've seen tons of articles that go into great detail on how to simulate and accommodate various forms of colorblindness, the idea that those accommodations have no negative impact on the rest of the population appears to be taken as an axiom that somehow requires no data to support it.
Most charts don't have a ton of data. Choosing four accessible colors is not challenging. Most UIs are monochromatic.
I'm not sure I need data, most interfaces or designs you see already accommodate color blindness via simplicity. Those that do not can almost always do so by adjusting the palette subtly, with almost no perceptual difference for those who are not colorblind.
Obviously simulating colorblindness on a general graphics level is less effective, and I don't think anyone is suggesting we apply such filters universally.
The center of my argument is that it is easy with software, which has consumed the information world, to simply offer alternative viewing modes, of which colorblind modes are not very complicated.
Aren't something like 1 in 20 or so people color blind? I'd hardly consider that as an edge case. That's roughly the odds of being over 6ft tall in the US.
This is ignorant and wrong. You are assuming that colorblind-friendly palettes are worse than others, but that isn't the case. In my experience, colorblind-friendly palettes actually tend to be nicer looking.
It's not wrongthink, but you might just be a jerk.
>Indeed for her kind of data the rainbow palette works okay. But if you have to visualize more complex / denser data, beware of the pitfalls of the rainbow color palette. It is not always the best choice.
There is already a trap in this palette, the first color looks awfully like the last. It's fine if you just want a palette for a bunch of lines but using it for heatmap could be a bit misleading in edge cases
> (1) Hue was not a good dimension for encoding magnitude information, i.e. rainbow color maps are bad.
Your inference doesnt follow from the first point. Hue is bad for magnitude because you dont see a different hue as 'more' or 'less' just 'different'. Hue is great for representing difference without defining one as a focus or preference over the other.
This is a whole area of research (as you probably know). I personally only like HSV colourmaps for visualisations of phase, as it has no boundaries at the edges and therefore when you wrap over 2π again you don't get a hard discontinuity. Often you're not actually interested in what the "number" is, but how quickly it is cycling – something that it gets across quite well.
I agree that trying to use hue for encoding magnatude information is not great, but man, how many times have I given up on someone's infographic that decided to use four different shades of blue and purple you can't tell apart when the markers are only eight or sixteen pixels on the screen.
I should hope the 12-bit rainbow palette would be adopted for those kinds of visualizations.
I have a pet theory that certain high spatial frequencies bleed into being perceived a colors anyway. The reason being that the red, green, and blue cones in the retina each have a different amount of space between them but are otherwise organized in the same pattern. Thus if the brain sees something with the same spacing as the blue cones, its going to assume that's caused by it being a blue object (rather than a black/white object which happened to have the same spatial freq as the blue cells). You seem to know the literature here, is there anything validating or invalidating my pet theory?
I've never noticed such happening by eyes, but I've definitely seen distant ocean reflections (tiny randomly-shifting specks of light) being misinterpreted as colors by Bayer matrix camera sensors.
full disclosure, this pet theory is entirely based on observations of people on LSD. High frequency spatial patterns consistently get distorted in colorful ways.
What is often needed in visualizations is showing several parameters next to each other. Think not color maps that showvariation of one value, like a heat map, but line or bar charts, or area maps with various pars marked.
I really like this, but FYI I do struggle to tell the difference between the first and last colour. There are probably others out there with this problem.
This test has as much to do with the monitor's gamma correction and color fidelity as anything else, IMO. Whenever I was unsure of the order, dragging the window over to a different monitor helped immensely. I was able to get a 0 by doing that, which I don't think I could have done on either monitor by itself.
Not really, they are just similar if you put it next to eachother (both are essentially shades of purple/violet) and as they are at different ends of scale it could get confusing if used as heatmap
> Attention! Please rotate your phone or view this test on a larger device for best results.
It doesn’t even let me dismiss that message. Who does this? Intentionally breaking your whole site because it might not look good. (This is an iPhone 14 max, so already a pretty big screen, and I’m in portrait orientation.)
I scored a 0, but I still find the first and last colors to be hard to tell apart at a glance (though they might be easier to distinguish if they were right next to each other).
On my laptop and phone I can tell the two apart both together and with some distance between them when in relatively isolated blocks with similar surroundings. I might struggle if one were surrounded by brighter colours than the other, though human visual perception had trouble with that anyway (hence the "those two colours are actually the same" optical illusions).
The screen I code/write/read on mainly is setup differently to be easier on the eye for long periods but is not as true in colour output, I think (I'm away from it right now so can't check) they may look nearer identical on there.
I suspect people reporting difficulty seeing the difference will be a mix of differences in their eyes and differences in they screen configuration (or screen quality: some things can't be configured around).
The Dutch artist Peter Struycken has made paintings with various rainbow palette, not using some kind of computer based method (although he is a prominent computer artist), but just his eyes. See: https://www.pstruycken.nl/EnS20.html (A computer program was used to design of the pattern being used in the paintings.)
I'm a color nerd and I love seeing how even with such an old concept (RGB is 162 years old), people are still interested in finding opportunities to innovate. I love this palette and will be adopting it. Thanks for sharing.
Eh, RGB is a particular abstraction which is about that old. The human eye is way weirder even before you throw in all the luminosity stuff, and by the time the brain actually computes the color data? Forget it.
Not the sRGB used in monitors and simple color-pickers, no? Might be wrong here, but I'm fairly certain that day-to-day RGB that most programmers are familiar with is a direct representation of the brightness of the various colors of pixel in a given region (modulo green). The CIE-XYZ color space is the one which tries to represent human vision. RGB isn't crazy far off, but the R, G, and B values certainly don't map directly onto the activation of the L, M, and S cones. (0,255,0) is legal RGB, and displays a particular color, even though such a combination of activations is clearly impossible in the human eye. So given that RGB is a simpler, more tractable representation of a more complicated system...I'd call that an abstraction.
They’re actually S, M, and L. While we can choose three primary colors such that a large gamut can be represented, it is impossible to choose 3 hues that will be able to represent the entire visible gamut.
Our color sensing cones and the brain processing behind them is more complicated than simple mixing of R, G, and B.
Cyan is a good example. It lives on a “hump” in the color space that cannot be reached by any general-purpose gamut.
S, M, and L are shorthands for short, medium, and long wavelengths. Guess what these wavelengths are commonly called? Red, green, and blue (though in inverse order, L=R, M=G, S=B).
Can you clarify your example of cyan? I'm perfectly capable of both seeing and producing cyan with my human eyes and RGB screen.
So what is called "Cyan" on a computer screen (#00ffff) is as close as you can get to the real color by mixing RGB.
In real life, Cyan would be a pure lightsource at, say, 490nm. When that light hits your retina, it will stimulate the S, M, and L receptors in different ways, and your brain will do the math on those differential signals to "rebuild" the color.
RGB is a hack we've come up with to stimulate each of the cones separately. But it cannot cover the whole gamut. Look at this diagram: [0]. The triangle is the gamut that results from choosing a particular set of 3 primaries. Only colors inside that triangle can be simulated by the mixing of those primaries. Colors that lie outside of the triangle cannot be created.
There are other gamuts that cover more visible colors, like the Adobe Wide Gamut [1]. Even this one still manages only 78% of the colors we're capable of seeing. And still no pure Cyan.
The thing we call "cyan" on our computer screens is desaturated. The mixing of the green and blue primaries that mimics pure 490nm unfortunately also stimulates the L cone too much. From [2]:
> No mixture of colors, however, can produce a response truly identical to that of a spectral color, although one can get close, especially for the longer wavelengths, where the CIE 1931 color space chromaticity diagram has a nearly straight edge. For example, mixing green light (530 nm) and blue light (460 nm) produces cyan light that is slightly desaturated, because response of the red color receptor would be greater to the green and blue light in the mixture than it would be to a pure cyan light at 485 nm that has the same intensity as the mixture of blue and green.
Kind of like our music system isn't actually harmonic, we've just learned to accept the small error (distributed evenly across notes, called equal temperament). But you try telling the masses they're actually listening to garbage, or getting musicians into just intonation and mathematically pure harmonics. It's impractical.
Similarly I fail to see the success in debating how truly cyan this or that tech can produce. It doesn't seem to invalidate my point of RGB being an old "invention" (of evolutionary process).
#00ffff is cyan. The fact that almost all devices fail to reproduce that color exactly is an implementation detail.
Fun trick, you can oversaturate your receptors by intensely staring at max red for a while, then close your eyes, and my understanding is that this perceptual illusion lets one briefly observe pure cyan.
What is the advantage of restricting the palette to a color depth of 12 bits, when every display device the colors are likely to be shown on supports much higher color depth, and printing yields much wider color ranges as well?
The only hint given in the article is
> so each colour requires only four characters when specified as a hexadecimal colour code in a CSS or SVG file
but surely this can't be the answer? Such a minor technical detail doesn't seem worth deviating even slightly from the "ideal" HCL values.
I think I understand why. I think the primary reason is that it's minimalist and very much empathise with such endeavours.
There are several advantages to such minimalism: easier to read and write in code, fewer bytes to store and transfer, and perhaps also satisfying one's ocd.
Let me flip this on you: why use 6 characters to specify colours when 3 will do fine? What exactly would your "ideal" HCL values be?
The post specifically mentions that "slight changes" to the constructed HCL values "must be made" in order to conform to the 12-bit color depth. So the author first derived certain values from theoretical/aesthetic considerations, then modified them for the sole purpose of fitting into 12 bits. This doesn't make sense to me except in very, very niche cases where saving 3 bytes (or even less, considering compression) actually matters more than visual quality.
But also it appears you missed that these changes aren't noticeable:
> Using a 12-bit colour depth limits the available colours, so slight changes to hue, chroma, and luminance must be made, but these are small enough not to be noticeable.
Again, I don't think it's about saving the disk/network the 3 characters. It's about minimalism and perhaps about developer experience: these colours are easier to read, write, and remember. Is that worth nothing?
Perhaps you use a CSS preprocessor and can define variables for your colours and don't need to write them down repeatedly. But perhaps other people don't. Or perhaps they're porting a colour scheme to many different applications. In these cases, three letter colour codes are superior to six letter ones.
This isn't 12-bit color depth. It's a 12 color palette, so its color depth is x if 2^x=12 or
ln(12)
------
ln(2)
Color depth (or bit depth) is the number of bits used to indicate the color of a single pixel. So 24-bit color depth produces 16,777,216 colors, 12-bit color depth produces 4096 colors, 8-bit color depth produces 256 colors, and 4-bit color depth produces 16 colors. A 12 color palette is 3.58496250…-bit color depth.
No, read it again more carefully. They’ve selected colours from the subset of RGB that is representable with 12-bits.
> The palette uses a 12-bit colour depth, so each colour requires only four characters when specified as a hexadecimal colour code in a css or svg file:
Four hexadecimal characters is twelve bits. The colours they’ve chosen can be represented precisely in a 12-bit colour space. Get what they mean?
It’s further confirmed again in the article:
> Using a 12-bit colour depth limits the available colours, so slight changes to hue, chroma, and luminance must be made, but these are small enough not to be noticeable.
How could it ‘limit the available colours’ unless this was their meaning?
Each hexadecimal digit is 4-bits, so a 4 digit hexadecimal number is 16-bits.
The number of colors defines the color depth. 16 colors is 4-bit color depth, so 12 colors is less than 4-bit and not 12-bit. I am satisfied that the author has misunderstood the meaning of color depth aka bit depth or invented a new meaning for it previously unknown to the world.
Yes, and they have selected these 12 colours out of a range of 4096 colours, so from a range with a colour-depth of 12-bits.
If they picked from the millions of colours expressible in CSV it'd be 24-bit colour-depth. But they didn't - they picked from a subset of 12-bit depth.
> so 12 colors is less than 4-bit and not 12-bit
From a range of 12-bit colours, is what they mean. From a range. Get it? I think you're confused that there are 12 colours, and it's from a range of 12-bit colours. The two things are unrelated.
> I am satisfied that the author has misunderstood the meaning of color depth
Don't know what else to say really - sorry you don't understand. See the every other comment in this thread saying exactly the same thing as me if you aren't sure.
Pretty sure you are wrong. They're actually using 3 hex digits (the first color is #817.) The 12 colors are selected from a 12-bit space (#000 through #fff.) Makes sense to me.
This was cool to read, because it indirectly taught me to understand HSV.
I've always had trouble understanding the colour spaces other than RGB. After reading that article, I understood a little more about the luminance due to the greyscale used. From there I searched for "rgb vs cmyk vs hsv" and found this: https://www.geeksforgeeks.org/difference-between-rgb-cmyk-hs... (with annoying "sign up with google" popovers)
So, if you're out there wondering if you should write that visualizer that you had a weird idea for, please, please do so. It may help some random internet person understand something :)
actually this probably already exists. 8 colors of equal perceived brightness and the same 8 colors at a higher but equal to each other perceived brightness.
Doesn't work because as you adjust the brightness, yellow turns brown before blue stops looking washed-out (or vice versa).
The problem is that yellow is, 1/255 increment for 1/255 increment, about 9 times brighter than blue, and the range of brightnesses that produce useful saturation just doesn't isn't wide enough to accomodate that difference.
The colors you get are a function of the brightness (also hue and saturation) you use. If you pick a fixed brightness and require yellow and blue to both be that bright, either the yellow is brown of the blue is washed out (or both) depending on which brightness you picked. As you adjust the brightness you're trying to design the palette for, it switches from one problem to the other.
so you are saying that one cannot choose colors which have the desired brightnesses and hues providing that it is within the range of colors that a monitor can display? like sRGB?
are you seriously telling me there is no way to produce both a yellow and a blue which have the same apparent brightness and also have the desired hues for an sRGB monitor? because that is not an informed opinion or you are not fully explaining what you are trying to say.
yes, if i naively pick a hue and a saturation and a brightness and change only brightness there may be color shifting associated with brightness changes owing to the particular display technology used, but if i author the colors, and remain within something like sRGB as i am suggesting, then i can author the colors so they appear with the intended apparent brightnesses and hues, which is exactly what the author of the linked article has done.
all i said was that i want a 16-color version of this palette, where all the darker colors have the same apparent brightness as each other, and all the brighter colors have the same, but higher, apparent brightness as each other, and that the brighter colors have the same apparent hue as the associated non-bright color in the palette. that is definitely possible unless you are measuring hues with a precise tool instead of an eyeball.
> one cannot choose colors which have the desired brightnesses and hues providing that it is within the range of colors that a monitor can display?
No, the problem is that you can't choose colors which have the desired brightnesses, hues, and saturation. If you start with a ideal #00F blue and try to make it lighter, you have to add red and green, which reduces the saturation. Conversely, if you start with a ideal #FF0 yellow and try to make it darker, you have to remove red and green, which also[0] reduces saturation. For most colors this reduction in saturation isn't too bad, but for dark yellow it produces a ugly (if you wanted yellow) shade of brown, and for light blue it produces a very washed out shade of blue (also ugly if you wanted a proper blue).
> a 16-color version of this palette [...] have the same apparent brightness as each other
TFA's palette doesn't have the same apparent brightness, and cites this problem specifically for why:
> > An HSL rainbow colour palette can be created by choosing fixed chroma and luminance values and varying the hue. However, the resulting palette looks unpleasant because yellow is darkened to brown, red is lightened to pink, and blue becomes very pale.
(You can fudge the red in practice (IME), but getting a properly saturated bright blue would require more photons than a white (fully-on) pixel has.)
Edit: 0: Well, saturation in the sense of distance-from-same-brightness-gray - depending on your color model, you might define saturation as angle from gray in color-vector-space, in which case dark yellow doesn't count since it's a scaled-down version of regular yellow. Not sure offhand which sense is more common, but GIMP at least seems to use angle, so feel free to suggest less-ambiguous terminology if you've got it.
"Thus in the case of a dark background colorscheme, the normal relationship for background and body text is base03:base0 (please note that body text is not base00)."
This was at the bottom, but even earlier in the blog when the codes were first shown, base0 and base00 just seemed kludgy to me on first sight. Then to see this note shows that I wasn't the only person to have issues with the naming. I know naming is hard and all, but this just seemed like low effort
Right. The very same palette can be done with usual 24- and 32- bit palette.
A palette is supposed to be a (chosen) subset of the whole color space. So this is a 12 colors palette over a (presumably) 24hbit color space.
A 12-bit palette should have 4096 different colors to be enumerated.
Each of the 8-bit channels is only allowed 16 different values, i.e. needs 4 bits to represent. I think it's reasonable to describe three 4-bit channels as 12-bit colour?
Every color in the palette exists in a 12-bit color space because each component can be stored in four bits, totaling 12 bits. As a result, each component can also be represented by one hexadecimal. It's nice to have a palette where the colors don't require 24 bits to be displayed correctly, and three hexadecimal digits are arguably easier to type out and remember than six.
If you really want to make sure people can read visualizations with this many colors, please use one of the many palettes designed for color blind/deficient readers. It doesn't detract from your graphs and makes them readable for everyone.
If you take a closer subjective inspection of the corrected palette you will notice that the luminance adjustments makes typical day colors bright and typical night colors dark. It looks like day and night adjusted now. Due to the color diffraction of our atmosphere when the sun is low the colors get filtered and the light gets lower and this new palette is a better representation of that daily change.
Bit when I create visualisations the info I need (can't guess myself or workout) is what it looks like with colour blindness. That's rather more common than not having access to colour.
I really like this palette. If I had one caution, it would be for using it for symmetric or diverging colour scales. i.e. for anomalies with 0 at the centre. Typically zero would be at the lightest greyscale which for this palette is the yellow, offset from centre. That said, in the example visualizations on their site, colour is used to indicate unique values, and are strikingly clear. So, all good!
"Yellow is given the highest luminance, as it only looks yellow when bright. After choosing two other colours — a red and a blue in this case — the luminance can then be calculated for the other hues."
Yeah I've been using HSV transform in feedback (in glsl shaders) to great effect lately (rotate hue a bit to get rainbow-color cycling) but only the other day I was wondering how the heck to make this rainbow better!? (essentially: more like real diffraction) If it passed through the colors in the article instead of going around the hsv-wheel that would be a huge improvement I reckon!
I'll brave the syntax and try to paste my current method:
vec3 rgb2hsv(vec3 c)
{
vec4 K = vec4(0.0, -1.0 / 3.0, 2.0 / 3.0, -1.0);
vec4 p = mix(vec4(c.bg, K.wz), vec4(c.gb, K.xy), step(c.b, c.g));
vec4 q = mix(vec4(p.xyw, c.r), vec4(c.r, p.yzx), step(p.x, c.r));
float d = q.x - min(q.w, q.y);
float e = 1.0e-10;
return vec3(abs(q.z + (q.w - q.y) / (6.0 * d + e)), d / (q.x + e), q.x);
}
I wish I knew more about what this code is really up to, I inherited it from somewhere, can't remember, and I'll admit I haven't tried to understand it yet.
I'm personally partial to 3 bit and sometimes 4 bit color because it can be easily implemented on an RGB LED and will be instantly recognizable to people as "subway map colors". The 4th bit variant just introduces "half power" option.
These look the same to approx 6% of the population, especially when not immediately next to each other or used for thin lines/bars. Accessibility is seemingly never considered
"Magnitude estimation a technique standardly applied in psychophysics to measure judgments of sensory stimuli (Stevens 1975). The magnitude estimation procedure requires subjects to estimate the magnitude of physical stimuli by assigning numerical values proportional to the stimulus magnitude they perceive. Highly reliable judgments can be achieved for a whole range of sensory modalities, such as brightness, loudness, or tactile stimulation."
Indeed for her kind of data the rainbow palette works okay. But if you have to visualize more complex / denser data, beware of the pitfalls of the rainbow color palette. It is not always the best choice.
IBM did research back in the 90s on perceptually-based colormaps and how to best represent various types of data within the color dimensions of luminescence, saturation and hue [1]. For example, they found that,
(1) Hue was not a good dimension for encoding magnitude information, i.e. rainbow color maps are bad.
(2) The mechanisms in human vision responsible for high spatial frequency information processing are luminance channels. If the data to be represented have high spatial frequency, use a color map which has a strong luminance variation across the data range.
(3) For interval and ratio data, both luminance- and saturation-varying color maps should produce the effect of having equal steps in data value correspond to equal perceptual steps, but the first will be most effective for high spatial frequency data variations and the second will be most effective for low spatial frequency variations.
===
[1] the original link got removed from IBMs website. Back in the day it was under
https://www.research.ibm.com/people/l/lloydt/color/color.HTM
A pdf copy is here:
https://github.com/frankMilde/interesting-reads/blob/master/...