Hacker News new | past | comments | ask | show | jobs | submit login
Turbo, an Improved Rainbow Colormap for Visualization (googleblog.com)
494 points by polm23 60 days ago | hide | past | web | favorite | 121 comments

While arguments in the blogpost are mostly compelling (perhaps the most important to me is Jet/Turbo being far more high-contrast in the "colder" regions), I see Inferno as vastly superior still, mostly for the same reasons it was superior to Jet. All these colormaps are intended to represent one-dimensional gradient, as in "from hot to cold" and it is completely obvious when looking at Inferno. Jet & Turbo give a false impression of non-one-dimensionality. It might be a matter of being used to the colormap in question, but Jet is as old and common as it gets, and it still is not self-evident to me that the dark red is hotter than the very light yellow. I mean, obviously I know that, but I will tell you instantly without thinking what is the hottest and coldest regions on Inferno image, and I am significantly more likely to make a mistake when I'm tired with the Jet (and, presumably Turbo — for the same reasons).

I have to disagree.

If you want to represent a one-dimensional gradient where what is most important is "hot vs cold", i.e. the extremes, then you shouldn't be using a colormap (rainbow) in the first place, you should be using a direct gradient instead, whether grayscale or interpolated between two nearby colors (e.g. red/yellow).

Colormaps are for where highlighting local variation is important -- more important than indicating whether something is closer to one extreme or another. In the examples, this means being able to distinguish the patterns of the objects. In math plots, it means helping to see the shapes of curves. In weather maps, that means judging variation within your state, even while the map ranges from Alaska to Florida.

For this, it's most important to be able to maximize contrast in local differences but also have the perceptual rate of change be roughly comparable.

Rainbows maximize contrast using hue, because our eyes can simply distinguish so much more than with just brightness. Turbo makes the rate of change more constant than Jet. And Jet/Turbo most importantly double the resolution that Inferno has, going from dark-bright-dark rather than just dark-bright.

The ultimate in highlighting local variation is something like the Glasbey colourmap:



EDIT the "hue ramps" style of colormap is also quite interesting, although i can't find an example, and can't be bothered to create one:


One point to keep in mind is when you have maxima and minima next to each other then Jet/Turbo is not the colormap you want, since it's very hard to distinguish dark blue and dark red.

That's a very good point, and the converse as well: Jet/Turbo is good when maxima and minima are nonadjacent, such as in continuous functions.

It depends on the use case.

I find Inferno/Viridis perfectly good for representing one-dimensional gradients. They're easier to glance at then a single hue and show contrast between min/max better. Greyscale and single hue can also make it hard to notice small variations.

I can see Turbo being useful for heatmaps where you want to notice differences rather than variation between hot and cold.

In general though I would say that choice of colormap is subjective and there isn't a general rule for when to use which colormap. I usually plot the same image in multiple colormaps and choose the one which helps me the most for that usecase. Another person may choose differently.

I totally agree. Hard not to think about Edward Tufte when this comes up: "In color maps, use a single hue, Don't use up the entire color spectrum, or even all of a hue's levels. Particularly avoid Roy G. Biv (red, orange, yellow, green, blue, indigo, violet), the color spectrum of the rainbow. It's good physics, but poor human factors. Like all multi-hue color maps, the non-equidistant hue changes are perceived as especially important contours, which they usually are not. Furthermore, the lighter middle parts of the spectrum are often perceived as the higher values. Finally, one needs to constantly remind oneself which color means high vs. low values. Using a single hue with variations in intensity allows instant interpretation, multiple color maps without ambiguity, and leaves graphical space for layering and separation."

> “Like all multi-hue color maps, the non-equidistant hue changes are perceived as especially important contours, which they usually are not.”

That’s basically the objection this mapping is aiming to address.

Yeah, sorry, didn’t want to mess up the quote. But I should have mentioned it, you are of course right!

This is all true.

Where jet and other non-uniform maps are useful is in highlighting small fluctuations in the value. It's less about z1 > z2 and more about z1 != z2 across the image plane.

A similar problem happens with datashader in histogram normalisation mode. It's great for highlighting small variations in the underlying density and revealing detail that you'd otherwise never see, but worthless for trying to compare one density to another by eye.

Horses for courses.

I read your comment before reading the blog, and I was thinking "yeah, Inferno is probably better," until I started getting to images where distinguishing slight variation was clearly important. That was my "ah-ha" moment for Turbo.

Computers are already really good at dealing with large-scale details. The human eye can notice edge-case scenarios in a large dataset pretty rapidly. I'm sold on Turbo because it lets your eyes change scale on the fly. You can be looking at the large scale and rapidly focus in on particulars within a smaller band, and back out again, as needed.

For some use cases, the uniform colormaps are not the right approach in my opinion. They simply don't have have sufficient resolution.

I've tried inferno and viridis to visualize weather radar data, and... rainbow-like colormap simply works better. And this is true for most weather data like wind or temperature. With a uniform colormap, you wouldn't be able to see local variations, e.g. differences in temperature within the UK.

The fact that luminance peak, i.e. green, maps to the center of the input domain for Jet/Turbo is also very confusing and creates a strong emphasis for that region. It is unlikely to be a very desirable quality, especially when evaluating depth images like in their examples.

The luminance peak in the center is by design - that's clear in its parabolic gradient. Whether this is desirable or not depends on your use case.

On this point I don't see Turbo is being a do it all colormap. In the depth comparison images I still see Inferno and Viridis being superior and personally have no confusion between which spheres line up with which rings. Turbo in fact confuses me on this by introducing the false 2D color gradient.

Where I see Turbo being useful, as others have pointed out, is for heatmaps. I personally find Inferno's low end contrast being problematic and usually resort to Spectral for picking out details. If you can live with the fact that the lightest part of the chair in the test image is rendered darkly in Turbo (compare with Inferno), then Turbo is great for purely picking out detail (and taking brightness with a pinch of salt).

In the end, it depends on your usecase. Use a linear colormap when appropriate and vice versa.

This is why I liked their C2 approach

Do you want to see detail in the dark bits? That seems to be one area where the rainbow ones shine.

The cases where I find it most useful to display data with a rainbow-like color scale are where the data is in log-scale. In that case, I really want to convey the fact that there are enormous differences in the data in every small change of color.

If you have any interest in this topic, I’d strongly recommend watching this presentation at SciPy 2015 where Viridis and Inferno were first presented, when the developers of Matplotlib were coming up with a new default colormap to replace Jet:


I'd love to see Turbo analyzed in the same fashion.

The lightness plots midway through Google's blog post are made with CIECAM02-UCS, which is the same color space Matplotlib's video talked about using.

It looks like Turbo is just Jet, but plotted in CIECAM02-UCS (instead of Jet's HSV). It removes many disadvantages of Jet, while keeping Jet's advantage over Viridis/Inferno of making it easier to compare/contrast small differences.

The video and the blog post actually go over a lot of the same topics, like perceptual lightness and how Jet was found to lead to mistakes reading medical imaging.

I'm not sure what analysis you're looking for; the video's a good explanation of color theory, but its analysis of Viridis is mainly just "we plotted a line through CIECAM02-UCS color space and made it linear lightness". Turbo is the same, except the line is curvier and not linear lightness – and the blog post goes through the tradeoffs of that approach.

> making it easier to compare/contrast small differences

Unless they happen to be near the middle of the data range, at which point it becomes much harder to compare them. This makes an artificial (not from the data) visual artifact for the entire middle part of the data range.

Also visual contrast for data at one part of the data range is no longer remotely comparable to visual contrast for other parts of the data range. Finally, amount of perceived contrast is no longer proportional to differences in the data.

* * *

The specific comparisons done are misleading: they picked a test image with important low-contrast detail at one end of the data range and no important low-contrast detail near the middle of the data range, because they are promoting their color map which has very dramatic lightness contrast at the ends of the data range at the expense of almost no lightness contrast near the middle of the data range.

If you were expecting to be working with data like this frequently there are many other things you could do to improve contrast in the part of the data you are specifically interested in.

I'm not sure which test image you're talking about. This one seems to have low-contrast detail everywhere in the data range:



While it's true that Turbo/Jet have low lightness contrast in the middle range, it makes up for it with hue contrast.

While there are of course ways to improve contrast in specific parts of a data range, I like Turbo for having high contrast in general, to make it less necessary to "zoom in" on a specific range, and also to have even higher contrast after zooming in.

Hue contrast is not very salient to the human visual system. But while we’re at it there’s also not very much hue contrast in the middle of this color scheme. It goes from light bluish green to light yellowish green.

Yes that cherry-picked image. Their original data is some kind of (log-scaled?) distance map, where half (?) of the image is in the bottom 20% of the data range.

They put a bunch of apparently important data between values of like 0.00 and 0.05, but don’t have any substantial amount of important data between 0.45 and 0.55.

Their color scheme has very strong lightness contrast in the 0.0 to 0.05 range, and almost no lightness contrast in the 0.45 to 0.55 range.

If they had instead put a bunch of important low-contrast detail in the mid range, it would become nearly invisible compared to the old scheme.

If you really care about the data from 0.0 to 0.05, and don’t really care about the data from 0.45 to 0.55 you can apply some function (e.g. a power function, or inverse smoothstep or something) to your data beforehand.

Don't have any substantial amount of important data between 0.45 and 0.55? The biggest tree is in that range! How is that not low-contrast detail in the mid-range?



Look at the images again. 0.45 to 0.55 is green. Do the leaves on the front of the closest tree actually look harder to distinguish in Turbo than in Inferno?

It doesn't matter which function you apply to your data beforehand, it won't change that Turbo has more distinguishable steps than Viridis/Inferno. Turbo goes red-yellow-green-blue-black, Viridis goes yellow-green-black. Of course Turbo will be able to show more contrast.

> They put a bunch of apparently important data between values of like 0.00 and 0.05, but don’t have any substantial amount of important data between 0.45 and 0.55.

I don't think they chose the image to best present their colormap. It seems more likely that they designed their colormap to work well for a few images, including this image.

Call it a very weak form of Hanlon's Razor

Here’s a JavaScript implementation of the lookup table and polynomial approximation: https://observablehq.com/@mbostock/turbo

My first thought after reading the article was actually "I wonder how quickly Mike Bostock will publish an Observable notebook showing his d3 port...." In less than three hours apparently, hahaha

Anyway, as someone with protanomally: thank you! This looks so much better than Jet, and I just pinged my coworkers what they think about replacing our current rainbow map with this one. Having the d3 code already available makes that already low threshold even lower.

Thank you from this devops/sysadmin person. I didn't know about observable, it looks really useful!

Observable is awesome! Glitch.com is really swell, too, if you've not seen it! (No affiliation, I used it to teach JS / D3 last semester).

Thank you for the quick implementation and reference!

I'm surprised there was no mention of cubehelix [1] which has the advantage of directly mapping to grayscale.

1. http://www.mrao.cam.ac.uk/~dag/CUBEHELIX/

Cubehelix does deserve a mention if only for being the first to bring this idea to the "mainstream", but for the record: this is also true for Inferno, Viridis, Cividis, etc.

I wosh cube-helix had more saturated colors. It might be good for vizualizing, but it doesn't pop.

There are a few parameters you can adjust to get brighter colors. A nice online implementation is at >> http://www.mrao.cam.ac.uk/~dag/CUBEHELIX/cubetry.html

adjusting the hue parameter up to 1.4 will give more saturated colors

So grateful that colorblind is a first class citizen in their development. I drive a VW and their proximity sensor uses red on green background, I think.

While color vision deficiency was considered, I wouldn't go nearly as far as saying that it was a first class citizen in the development of this colormap, which is unfortunate.

Per my reading of the blog post, they ran some images through a random color vision deficiency simulation website and decided that they looked good enough; while lightness plots are displayed for normal color vision, no such plots are shown for simulated color vision deficiency. Also, best I can tell, the simulator they used is based on a 1988 paper [1] instead of more recent and accurate techniques [2].

For an example of where color vision deficiency was actually properly considered for the development of a colormap, see Cividis [3].

[1] https://doi.org/10.1109/38.7759 [2] https://doi.org/10.1109/TVCG.2009.113 [3] https://doi.org/10.1371/journal.pone.0199239

Thanks for pointing this out. I had actually read [2] and I think just assumed that's what 'the most used simulator' would be doing :\ Can you suggest a better alternative? (I can re-implement the paper, but I'd rather just use a known gold standard). Also the source image is there, in case you have a simulator you can run it through and post the results.

The method presented in Machado et al. (2009) is implemented in Colorspacious [1]. I'm generally in favor of a more quantitative approach than simply running an image through a simulator and looking at it, although as someone who is colorblind, I'm usually biased toward numbers over colors, since I'm less likely to misinterpret them.

I'm not convinced it's actually possible to create a colorblind-friendly rainbow colormap, particularly one without the shortcomings Jet presents for non-colorblind individuals. For all its faults, I find the banding in Jet to sometimes be a redeeming quality, since it makes it easier for me to match part of an image to the colorbar or other parts of the image. For example, in the image included in the blog post of the patio furniture and tree, I find that Turbo makes the tree appear deceptively close, due to my lack of differentiation in the green-orange part of the colormap; while the scene isn't shown with Jet, I suspect that the banding around yellow would make this misinterpretation less likely.

I may take a stab at analyzing the colormap for colorblind-friendliness, if I have time in the next few weeks. While the analysis in Nuñez et al. (2018) works well for sequential colormaps, I don't think it's the most appropriate for a rainbow colormap. For rainbow colormaps, I think the degree to which colors in non-adjacent parts of the colormap can be confused by colorblind individuals needs to be considered (it's the part of interpreting data presented with rainbow colormaps that causes me the most trouble). I'd have to think more about how to best construct a metric to evaluate this.

[1] https://colorspacious.readthedocs.io/en/latest/tutorial.html...

Here's an analysis of the colorblind-friendliness of Turbo and other colormaps: https://mpetroff.net/2019/08/discernibility-of-rainbow-color...

Thanks for the thorough evaluation and results! I was aware of colorspacious but I (wrongfully) assumed that it would be the same result as the other simulators (why would someone use ancient literature to make a modern tool...) Will definitely use it in the future instead.

I like your idea of measuring "distances to all other colors" as a litmus test for color confusion issues. It would have been great to see the spread/standard deviation along with the average, in order to see which color was particularly problematic, rather than simply 'weak' (like Twilight).

You're right that under this rubric it's probably not possible to create a colorblind-friendly rainbow map. I was aiming for the colors to be distinguishable, but not 'equally different', which is a much higher bar.

I am also not convinced that even CIECAM02-UCS can give a meaningful answer for 'long distances'. Once hues are different, I think psychologically we give that 'difference' much more weight than the shade. For example I would guess most people would consider Red and Yellow more different than Red and an (equally dE different) darker shade of Red. So surely this would make rainbows even more problematic.

At the end of the day, Turbo was basically designed to steer Jet-lovers to a somewhat better place, so it looks like by your metric it does accomplish that. I agree that making it truly colorblind-optimal was not accomplished, and would require significant changes (if it's even possible).

Including error bands on the plots unfortunately makes them extremely busy and difficult to interpret. The regions of a colormap that are particularly problematic can be seen as dips in the weighted average (except for linear colormaps, where problematic areas are deviations from the "V" shape).

I agree that CAM02-UCS is not necessarily accurate over "long distances." I'm also not completely convinced that using color vision deficiency simulation to shift colors and then using CAM02-UCS to estimate perceptual distance is all that accurate either, but it's the best approach using currently published models. It's my understanding that modern color appearance models were developed using matching experiments, e.g., asking a subject whether or not two colors are the same; for "long distances," it would probably be better to show two color pairs and ask which pair is more similar. If you're interested in how such appearance models have been developed, I'd recommend [1], which is fairly comprehensive (but also quite long).

By my metric and others, I agree that Turbo is certainly better than Jet. For normal color vision, the metric I developed is fairly flat across the colormap for Turbo, which is close to optimal as far as rainbow colormaps are concerned.

[1] Fairchild, Mark D. Color appearance models. John Wiley & Sons, 2013.

Yes I believe that's correct. My intuition is that since these matching experiments are very local, it's perfectly possible to have 'constant' distances integrate into non-linear curves (which are no longer 'the shortest path') or simply have error build up as you take 'finite steps'. Indeed I believe that's what caused the "blue turns purple" problem in CIELAB back in the day, since it was fairly constant locally but had non-straight hue lines.


CAM02 is certainly much more uniform than LAB (hence OS's using it to print these days) but I think the problem is still fundamentally there (especially once we start talking about 'appearance' given a 'surround' and so forth).

The Fairchild book is indeed a classic and a heavy hitter as you mentioned :) I can't claim to have read it cover to cover.

Another interesting (and somewhat unconventional) book is Jan Koenderink's "Color for the Sciences".

The simulation website they used [1] is terrible. The filters they put on the images changes the "brightness" of the colors, which is how I distinguish among colors that are similar to me, like green and brown, or purple and blue (things that IRL are brown or maroon I call dark green; things that IRL are purple I see as dark blue).

[1] https://www.color-blindness.com/coblis-color-blindness-simul...

The paper you mention in [3] is brilliant. Worth a read -- very good work they did.

With close to 8% of the male population being colorblind, it means that if they are able to support such group, they are more likely to fully tap into the market.

I see a possibility that UX can take a few steps forward : )

> I think

An interesting development, and a useful contribution to the field.

For those of you still looking for perceptually uniform colour maps, including rainbows, check out the work of Peter Kovesi [1].

Personally, I'm still on the lookout for the 'perfect' colourmap that allows me to plot line graphs with a moderate number of curves (up to, say, nine) such that they are all distinct (i.e., nicely 'spaced' in colour) but have identical lightness -- which I'm assuming is the same thing as greyscale equivalent -- so as not to emphasize any one curve over another. Of course, the curves would then be indistinguishable when printed out in greyscale, but that's not important to me.

A colleague of mine directed me to the work of Maureen Stone [2], but I get the feeling that those colours are not perceptually identical (not that I've checked...).

[1] https://peterkovesi.com/projects/colourmaps/ [2] http://ksrowell.com/blog-visualizing-data/2012/02/02/optimal...

In case the authors read HN:

In the case of Achromatopsia, the low and high ends are ambiguous. Since the condition affects 1 in 30,000 individuals (or 0.00003%), Turbo should be usable by 99.997% of the population.

1 in 30,000 is 0.003%, not 0.00003%.

Funny because they still got the 99.997% right

Yeah, because 0.003% is indeed 0.00003, they just put a % sign and forgot to fix the actual number.

Mystery solved

The author does! Much appreciated, will fix :)

For video monitors displaying depth images, another obvious thing to explore is time.


sending pulses of highlighted cross-sections backwards at constant speed

Or “tilting” depth effect, like iPhones lock screen, but automated circular tilting.

Their colormap is very similar to the Sinebow [1] from 2011

[1] https://basecase.org/env/on-rainbows

Sinebow is really nice and smooth, but I'd say there is a bit too much green, and the green that's there is way more saturated than the rest of the colors (perhaps save magenta). The yellow is very sad and desaturated looking. The 0.5 value is also a drab cyan, making it hard to identify. I purposefully didn't include magenta into Turbo, so it could be used as a 'marking' color. Sinebow is also cyclic, which we purposefully didn't want (so that you could tell max from min), but for a color wheel style application this is a plus.

Even closer if you crop it to the part from 0 degrees to 240 degrees.

Sinebow is also much simpler to compute.

The part which describes the development of Turbo is really cool. It shows off the value of having an interactive development setup that allows for fast and intuitive iteration.

As a Googler I'm surprised to see such an interface internally. Google systems have notoriously slow compile and test speeds for simple things (because the systems are optimized for very large projects). I think the difference between 500ms compilation and 10ms compilation is actually enormous.

Indeed, it's a bit 'against the grain', but definitely possible and the advantage is obvious.

This is very similar to the 'rainbow' colour map already available in many places, including matplotlib [1]. For people who are looking for maps with increased dynamic range, diverging colour maps already exist. There are even ones that are made up of _two_ linear colour maps, such as twilight.

This is some ok work by the folks at google, but screams of re-inventing the wheel 'because we're a silicon valley company and we innovate'.

[1] https://matplotlib.org/3.1.0/tutorials/colors/colormaps.html

The entire article including the very title explains that this is an improved version of Rainbow, of which they are very well aware and cite very clearly, and tweak for well explained reasons.

Sorry, my comment was unclear. They are comparing against jet, which is a colourmap that uses all the colours of the rainbow. They are not using the colourmap _called_ `rainbow`, to compare against.

You are right and I was wrong. The ‘rainbow’ map at the matplotlib link happens to be plotted next to ‘jet’ and the lack of perceptual banding in comparison is clear. Looks like the Google author came up with a similar idea.

Whoever gave the name ‘rainbow’ to their rainbow colormap?! It’s like naming a dog ‘dog’.

Yeah, it's not the best name. There is also the 'Spectral' colour map that is plotted in a different section, which imo is much better suited as being a diverging colour map as yellow looks more 'neutral' than bright green.

Indeed, we probably should have compared more directly to Rainbow, I got a bit of this flak on Twitter as well (with my rationale included): https://twitter.com/JamesABednar/status/1163978274361544704?...

The practical issue is that not many people really use Rainbow instead of Jet, for the reasons I mentioned in the article (it sacrifices too many of the 'good bits' of Jet). So instead I chose to compare to the more 'widely recommended' maps.

But you're right, I should have thrown rainbow into the mix, even if I didn't have the space to write about it.

Agree with you that the smoother shape leads to a more pleasing colour profile -- note that the `rainbow` cmap in matplotlib is different to the one you compared against, it's actually more similar to Turbo by looks. I would have also compared against other diverging colour maps, like Spectral and those available in `cmocean` (the latter are really beautiful).

All of this said, Turbo is quite pleasing to the eye :).

Thanks! Indeed there are a few 'rainbow' variants out there (in d3, matplotlib, matlab), and some of them are very pleasant (though I think lower contrast). I personally find it confusing to have 'pink' in a rainbow map. It's not in a real rainbow, and the way I recall the color order is by visualizing that so it trips me up :)

I like Spectral a lot as well. I think if you're not after mega contrast it's probably the best bread-and-butter map out there for this kind of work.

The article explicitly compares to the matplotlib colormaps and states the advantages of their contribution.

If you look at the post that I referenced in there (a matplotlib page detailing the colourmaps that are available in that library) there is one that is actually called `rainbow` that's very similar to the one proposed by the google team. They do compare against viridis and inferno, you're correct -- but comparing a high-contrast colour map directly to a perceptually uniform one is an unfair comparison. They should compare against, for instance, the rainbow one from there, cubehelix, or even the twilight ones that I suggested.

Of course it's always good to have other colour maps to choose from, but the similarity between this proposed one and the ones that already exist makes it seem like they've only quickly glanced at other work in the field.

They should contribute it to matplotlib

Off-topic, but I like how the page is almost completely empty when tracking protection is enabled in Firefox for iOS.

Seriously, Google, really?

You may want to open a Webcompat issue about that, since it’ll get the attention of both Firefox and Google once it’s triaged.

turbo is nice, but visualizing depth maps using a 1D color palette is always a bad idea. Much better to add some simple shading (lambertian or ambient occlusion). Then you can still use the color palette to provide absolute depth cues, but the shading is much easier to interpret visually.

Imagine if you have a non-linear function mapping to the height of the bars in a bar graph. For some input values, say, [0,25,50,75,100] we have a non-linear height function that calculates the heights of the bars, say [0px, 23px, 60px, 65px, 120px] - would you be ok with such a bar graph?

That's what Turbo or Jet or any of the perceptually non-linear colormaps are doing but on a chromatic scale. You are lying to your audience. It is beyond me that all this hoo haa about aesthetics, "highlighting differences" and other qualitative bullshit takes precedence over objective truthful representation of data. Sigh.

Turbo/Jet also doesn't care about colorblindness which Viridis, Inferno, Magma and Plasma does as part of the Matplotlib 2.0 spec.

I believe that I saw at the end of the article, some simulations of different colour blindness with Turbo.

The problem with the rainbow color map is having green in the middle; green is the highest contrast color and stands out from red and blue and so gives the impression of being “brighter”, undermining the red-green-blue ordering.

Personally I much prefer colormaps that contain any two primaries out of the three red/green/blue, but not all three. Chroma can be included (so mixing white and black). All the non-rainbow colormap pictures in the article can be described this way, and to my eyes the perceptual value is superior than all the rainbow-map images.

I found it a little strange that the blog post made a deal of calling out Jet for not being perceptually linear, and then announced that Turbo is not perceptually linear, just a bit smoother.

For a lot of practical applciations, this seems a great option. I get the arguments for viridis/inferno etc, but the fact that on a very light or dark background, you are always losing the ability to see one end of the spectrum is annoying. I do think though, that this is an area where you really ought to be doing usability testing with real humans to measure the impact of one choice over the other (while respecting accessibility of course).

D3 has a scheme like this too:


"like this"? Which one of the D3 color schemes is perceptually uniform and has an hue range which is as wide as Turbos?

See spectral and the one that's called `rainbow`

Subjectively, I went with plasma over other choices for my thesis (which I successfully defended yesterday!). I have used jet for many years for electrical test and measurement reports. For scientific writing, I felt there was a lot of value in colormaps that don't rely on chroma. I wish there was a jet-like colormap that used the entire color spectrum, but also was constantly increasing in brightness.

Ha - I did exactly this a decade ago in my Hypnocube products to avoid the tight bands on HSL color space. When animating colors along a hue cycle, the cyan and yellow would go by too fast. So I implemented piece-wise splines through the hue component, and I tune the parameter for each LED type we use to make them perceptually pleasing.

Nothing new under the sun and all...

You want colors to be meaningful, diverse, and stable. You also want the color map to scale gracefully (both in semantics as well as in code). Hash some meaningful value (e.g. class) to hue in HSV, and then you have your color. For distance, bucket by meter and lerp the hash-HSVs of the nearest bucket edges. Hash to color is the most flexible colormap.

NASA have a cool 6 part series on how to use colour for visualisations here: https://earthobservatory.nasa.gov/blogs/elegantfigures/2013/...

> Today we are happy to introduce Turbo, a new colormap that has the desirable properties of Jet while also addressing some of its shortcomings, such as false detail, banding and color blindness ambiguity.

What are the desirable properties of Jet? Why not use Viridis or Magma or any of the recent linear colormaps from matplotlib 2.0? These shortcomings were the exact reason why Viridis was created as exemplified in this brilliant talk: https://www.youtube.com/watch?v=xAoljeRJ3lU

I don't understand the point of Turbo.

> Turbo mimics the lightness profile of Jet, going from low to high back down to low, without banding. As such, its lightness slope is generally double that of Viridis, allowing subtle changes to be more easily seen. This is a valuable feature, since it greatly enhances detail when color can be used to disambiguate the low and high ends.

Why would anyone want low-to-high-to-low colormap?

> Viridis is a linear color map that is generally recommended when false color is needed because it is pleasant to the eye and it fixes most issues with Jet. Inferno has the same linear properties of Viridis, but is higher contrast, making it better for picking out detail. However, some feel that it can be harsh on the eyes. While this isn’t a concern for publishing, it does affect people’s choice when they must spend extended periods examining visualizations.

Personal taste vs scientific accuracy - I will take the latter unless we are doing plots for marketing materials. In my view this is not substantiated reason for going off and creating a more pleasant version of Jet; Turbo is still inaccurate and deceiving.

This is a deplorable attempt at creating a new colormap where the problem statement isn't clear in the first place.

> What are the desirable properties of Jet? Why not use Viridis or Magma

"The background in the following images is barely distinguishable with Inferno (which is already punchier than Viridis), but clear with Turbo." (and presumably also Jet)

> Why would anyone want low-to-high-to-low colormap?

I'm assuming because "it greatly enhances detail when color can be used to disambiguate the low and high ends" and "to make cases where low values appear next to high values more distinct".

> "The background in the following images is barely distinguishable with Inferno (which is already punchier than Viridis), but clear with Turbo." (and presumably also Jet)

This has to do with the dynamic range of the plot - if the author wants to show the difference in a small region (say foreground or background or some region of the plot), clip the plot to that specific region to show it in a smaller dynamic range. Using a non-linear colormap to highlight differences in a particular region of the colormap defeats the entire point of having a colormap - its purpose to display data with perceptual linearity.

Horses for courses, I think. Let's say you are plotting the pressure distribution on two different racing car wings (spoilers), side by side. If you're trying to say "this wing gives 2.4% more downforce than that one", you would use Viridis or Inferno. But if you are trying to say "look at how the F1 car wing is different to the Indy car wing", then something like Turbo is better suited.

Basically, I posit that sacrificing perceptual linearity for increased hue range can be worth it for conveying qualitative information.

I disagree. That’s still not a good way to show difference. Why not use a discrete color scheme for displaying differences? There is no reason to use a continuous color map, distort it and show qualitative differences - a continuous colormap is used for continuous variables.

The underlying data is continuous, and you want to give a qualitative impression. Why is that a bad idea?

It’s too bad you were down-voted. Your skepticism is pretty reasonable.

> What are the desirable properties of Jet?

Pretty much the only desirable property is that it used to be the Matlab default, and therefore has been used frequently and people are familiar with it.

Taking it as a starting point for a design is quite a poor choice. The design process here is pretty much just “we took jet and applied some blur to the apparent lightness”; this is not a principled or careful method, in my opinion.

One good use for this new color map might be: “My ignorant boss keeps insisting on using the jet color map even though it is terrible. I can drop this one in and he won’t notice the difference but it will be somewhat better, even if still problematical in many ways.”

> Why would anyone want low-to-high-to-low colormap?

This is sometimes called a “diverging” color map, and can be useful when e.g. you want to make choropleth map highlighting percentage of voters for Party A vs. Party B. You can make a 1/2:1/2 split of voters light and neutrally colored, and make the color get darker but with two different hues as the proportion gets more lopsided in favor of one party or the other.

But the lightness map on each side should still be more or less linear, and the obvious visual artifact created for the balance point has some concrete meaning.

Cf. https://www.kennethmoreland.com/color-maps/ https://www.kennethmoreland.com/color-advice/

> It’s too bad you were down-voted. Your skepticism is pretty reasonable.

It would be if all of the concerns were not actually addressed in the article. Nobody is taking inferno away from you, different scales are useful for different usages. Having an additional color dimension makes it easier to see gradients at a glance.

It’s not about whether someone is taking away Inferno or Viridis. It’s about what is effectively lying to your audience and what is accurate perceptually linear representation of the data - the latter triumphs over any aesthetic considerations. There are 4 different color maps from matplotlib 2.0 - you could use a different one if you don’t like the aesthetics.

If this article had come up with an original improvement to Viridis, I’d be praising it.

Also, Turbo doesn’t give a fuck about colorblind considerations whereas Inferno and Viridis does.

> lying to your audience

I am pretty sure the scale should be always put somewhere next to the heat map so the audience can make their own judgement. A rainbow colormap gives you more depth than a single or dual hue one, I think that both have their merit depending on the data to visualize.

> Also, Turbo doesn’t give a fuck about colorblind considerations whereas Inferno and Viridis does.

There is a whole section of the article dedicated to that.

> this is not a principled or careful method, in my opinion

This is what surprised me. I expected work from Google AI to be based on some sound and novel theory, but this is literally just "we tweaked it until it looked okay on our monitor at the time".

I think my comment was downvoted for the tone rather than content. I am just frustrated that according to HN, it’s ok to create random color scheme with no clear objective problem statement and perpetuate the Jet...uhhh Turbo. It took a tremendous effort to make Viridis a default matplotlib colormap.

Using Jet or Turbo is literally lying to your audience.

I doubt it. You're probably being downvoted because you quoted the answers from the article, and then typed those questions immediately below.

>The background in the following images is barely distinguishable with Inferno (which is already punchier than Viridis), but clear with Turbo.

Do I spy Dear Imgui used for one of the colormap control panels? Love using this for whipping together quick interfaces.


It looks like Processing to me

It's clearly dear imgui on those screenshots.

Dear ImGui indeed <3

Hi, I just hope you read this (as I'm posting after 12 days). But since this is not apparent from the Blog, what kind of license is applicable on this new 'Turbo' colormap? Can we use it in a professional application? Thanks!

Just happened to not close the tab yet :) The licence is Apache-2.0, which is permissive, similar to MIT.


I used to program the same type of colormap. It is a question of correct gamma correction.

Gamma correction and monitor settings usually go criminally unnoticed. I had problems just working with designers, I can't imagine what silent mistakes it produces in color-critical applications, like medical imaging. Some monitors are a finger brush away from auto-adjusting and messing up carefully selected settings.

From the blog post you have the impression the author was only allowed access to wikipedia.

Does someone smarter than myself see a downside of using Turbo for heatmap visualizations?

Well, it's kind of specific visualization's designer's choice, and my main complaint isn't something the authors of Turbo are unaware of (it's like that by design), but I think non-linearity of the light profile is far bigger downside than is being admitted. I'm not speaking about unable to print in greyscale or "people with the rare case of achromatopsia": it is actually harder for me to say at a glance what regions are hotter on non-ligh-linear image (or, more precisely, non-light-monotonic image). I will make mistakes when tired while working with Jet/Turbo images, which I won't make while working with Inferno.

So if you use one and only one colorspace for some heatmap visualization, I think I would greatly appreciate using Inferno (or Helix, or similar) instead of Turbo in the most cases.

Some time ago I looked into this topic, and in my opinion the blog post misses two points: (1) Conversion to gray scale won't be good because the scale is not linear, which is important for printing, and (2) In Jet (and also, Turbo), high and low values of a measurement don't map well to colors. This is well described in the paper introducing cividis [1] (check out [2] for code).

[1]: https://arxiv.org/ftp/arxiv/papers/1712/1712.01662.pdf [2]: https://github.com/marcosci/cividis

> the blog post misses two points: (1) Conversion to gray scale won't be good [...] important for printing

Covered: "When rendered in grayscale, the coloration will be ambiguous, since some of the lower values will look identical to higher values. Consequently, Turbo is inappropriate for grayscale printing and for people with the rare case of achromatopsia."

Do you need to use just a single one? It seems that interactively going through multiple scales and ranges might allow you to get a detailed view when needed.

Wouldn't a vector through CIELAB color space work too?

It's not defined as a vector through a perceptually uniform color space. They developed it manually, by tweaking parameters of a curve in sRGB until it looked good.

But if you plot it in CIELAB or CIECAM02-UCS, it's likely not a straight vector but rather a curved path. A vector would only interpolate between ~two hues (like Vidris, Inferno), whereas Turbo covers multiple hues. Have a look at the lightness profile plots in the post, it should give you a rough idea about how the vector must look in color spaces such as CIELAB.

Does this actually matter much?

I mean, we're just talking about a colour scale here right?

This sounds about as important as a debate over Helvetica Vs Times New Roman for research papers...

Does this actually matter much?

There are studies where doctors got to view MRI data under different color maps when screening for cancer. Using the 'right' map (which was different from their preferred choice) improved both the speed and accuracy of the diagnosis.

Basically changing color maps can radically change how you interpret the data being displayed.

> about as important as a debate over Helvetica Vs Times New Roman for research papers

That’s a reasonable discussion to have. In particular, Helvetica should not be used for setting long blocks of text.

The design choices in Helvetica make it an appropriate choice for posters, corporate logos, headings, ..., but not appropriate for research papers. Many other possible choices are more legible.

If a data presentation is easy to misread, is it not worth researching if there is a way to present the data without the confusion?

Mind blown, I now understand that I cannot start fathom all of the other vision systems, probably just on the property that are so alien to me that I can't even not understand them.

We could overlay very subtle queues in AR that effectively give the viewer super powers. Constructing the genie for the queues is the hard part.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact