The 12-bit rainbow palette
iamkate.com
iamkate.com
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/...
It’s just that you can do it with a hue and a non zero saturation if it suits the style you are looking for.
Plus sometimes you have more than on me set of data mixed and it’s useful to be able to distinguish both by using multiple colours.
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.
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.
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.
You can have your cake and eat it too.
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.
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.
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.
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
I should hope the 12-bit rainbow palette would be adopted for those kinds of visualizations.
> Best Score for your Gender -69420
> Worst Score for your Gender 1000000000
Someone doesn't sanitize their inputs?
> Best Score for your Gender -2147483648
> Worst Score for your Gender 2147483647
I mean, I can see _some_ difference but they are very very close, and I am not sure I could distinguish them in, say, a line plot.
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.)
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).
I know for sure I cannot complete a full ishihara plate test though so this one is on me.
He has created many colour palettes for specific buildings and applications. See: https://www.pstruycken.nl/EnDyn.html?Li,tag=q&w
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.
Can you clarify your example of cyan? I'm perfectly capable of both seeing and producing cyan with my human eyes and RGB screen.
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.
[0] https://commons.wikimedia.org/wiki/File:CIE_chromaticity_dia...
[1] https://en.wikipedia.org/wiki/Wide-gamut_RGB_color_space
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.
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.
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.
ln(12)
------
ln(2)
>> The palette uses a 12-bit colour depth
It is the author that has misunderstood.[1]
> 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.
> The number of colors defines the color depth.
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.
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)
From there I wondered if there was a visualizer for the HSV cone, and yes there is! https://color.lukas-stratmann.com/color-systems/hsv.html
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 :)
For whatever reason my brain considers it important enough I still remember $dff180 is the first color palette entry address. :-)
Amiga owners will also remember $bfe001, $dff01c, $dff09a... but mainly $4 :P
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.
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
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.
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.
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.
Here is one I use ( in Terminator)
palette = "#000000:#cc0000:#408600:#c4a000:#204a87:#75507b:#06839a:#d3d7cf:#555555:#ef2929:#8ae234:#fce94f:#729fcf:#ad7fa8:#34bae2:#eeeeec"These look fantastic as demoed here: https://grid.iamkate.com
That one is a 4-bit palette.
I have to admit I was expecting 4096 colors too, the "rainbow" of Amiga's HAM6 graphics mode: https://commons.m.wikimedia.org/wiki/File:Amiga_500-3000_HAM...
Shows realtime and historic energy generation data for the uk.
Recently been updated to include price history and other stuff.
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.
> The resulting palette has evenly-spaced hues, only small variations in chroma, and smoothly increasing and decreasing luminance:
IMO the palette does not have decreasing luminance. To my eye, on a color corrected monitor, luminance seems to peak at yellow.
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);
}
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
By which I mean, is there any objective measure of human perceived luminance?
"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."