
Turbo, an Improved Rainbow Colormap for Visualization - polm23
https://ai.googleblog.com/2019/08/turbo-improved-rainbow-colormap-for.html
======
krick
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).

~~~
crazygringo
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.

~~~
jmpeax
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.

~~~
91aintprime
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.

------
kbd
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:

[https://www.youtube.com/watch?v=xAoljeRJ3lU](https://www.youtube.com/watch?v=xAoljeRJ3lU)

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

~~~
Zarel
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.

~~~
jacobolus
> _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.

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

[https://1.bp.blogspot.com/-H-1I69V29VM/XVWeDrO7EPI/AAAAAAAAE...](https://1.bp.blogspot.com/-H-1I69V29VM/XVWeDrO7EPI/AAAAAAAAEdI/rc4kcJYaiNkTgazt-P1tJ7xCgeXBTuNFgCLcBGAs/s1600/image31.png)

[https://1.bp.blogspot.com/-6zVTINtwP60/XVWeKMWavuI/AAAAAAAAE...](https://1.bp.blogspot.com/-6zVTINtwP60/XVWeKMWavuI/AAAAAAAAEdM/VYew83Y03bI37wZDCXmqYaduNbLWAbSawCLcBGAs/s1600/image22.png)

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.

~~~
jacobolus
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.

~~~
Zarel
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?

[https://1.bp.blogspot.com/-H-1I69V29VM/XVWeDrO7EPI/AAAAAAAAE...](https://1.bp.blogspot.com/-H-1I69V29VM/XVWeDrO7EPI/AAAAAAAAEdI/rc4kcJYaiNkTgazt-P1tJ7xCgeXBTuNFgCLcBGAs/s1600/image31.png)

[https://1.bp.blogspot.com/-6zVTINtwP60/XVWeKMWavuI/AAAAAAAAE...](https://1.bp.blogspot.com/-6zVTINtwP60/XVWeKMWavuI/AAAAAAAAEdM/VYew83Y03bI37wZDCXmqYaduNbLWAbSawCLcBGAs/s1600/image22.png)

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.

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

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

~~~
leetrout
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).

------
itronitron
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/](http://www.mrao.cam.ac.uk/~dag/CUBEHELIX/)

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

~~~
itronitron
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](http://www.mrao.cam.ac.uk/~dag/CUBEHELIX/cubetry.html)

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

------
lighttower
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.

~~~
mpetroff
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](https://doi.org/10.1109/38.7759) [2]
[https://doi.org/10.1109/TVCG.2009.113](https://doi.org/10.1109/TVCG.2009.113)
[3]
[https://doi.org/10.1371/journal.pone.0199239](https://doi.org/10.1371/journal.pone.0199239)

~~~
antovsky
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.

~~~
mpetroff
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...](https://colorspacious.readthedocs.io/en/latest/tutorial.html#simulating-
colorblindness)

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

~~~
antovsky
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).

~~~
mpetroff
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.

~~~
antovsky
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.

[http://www.brucelindbloom.com/index.html?UPLab.html](http://www.brucelindbloom.com/index.html?UPLab.html)

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".

------
SJSque
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/](https://peterkovesi.com/projects/colourmaps/)
[2] [http://ksrowell.com/blog-visualizing-
data/2012/02/02/optimal...](http://ksrowell.com/blog-visualizing-
data/2012/02/02/optimal-colors-for-graphs/)

------
cperciva
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%.

~~~
melon_madness
Funny because they still got the 99.997% right

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

~~~
melon_madness
Mystery solved

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

Eg:

sending pulses of highlighted cross-sections backwards at constant speed

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

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

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

~~~
antovsky
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.

------
habosa
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.

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

------
JBorrow
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](https://matplotlib.org/3.1.0/tutorials/colors/colormaps.html)

~~~
robotresearcher
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.

~~~
JBorrow
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.

~~~
robotresearcher
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’.

~~~
JBorrow
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.

------
kzrdude
They should contribute it to matplotlib

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

Seriously, Google, really?

~~~
floatingatoll
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.

------
enriquto
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.

------
spectramax
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.

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

------
dahart
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.

------
thom
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).

------
d--b
D3 has a scheme like this too:

[https://observablehq.com/@d3/color-
schemes](https://observablehq.com/@d3/color-schemes)

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

~~~
haar
[https://observablehq.com/@mbostock/turbo](https://observablehq.com/@mbostock/turbo)

------
willis936
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.

------
choppaface
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.

------
ChrisLomont
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...

------
andyjpb
NASA have a cool 6 part series on how to use colour for visualisations here:
[https://earthobservatory.nasa.gov/blogs/elegantfigures/2013/...](https://earthobservatory.nasa.gov/blogs/elegantfigures/2013/08/05/subtleties-
of-color-part-1-of-6/)

------
spectramax
> 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](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.

~~~
jacobolus
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-maps/)
[https://www.kennethmoreland.com/color-
advice/](https://www.kennethmoreland.com/color-advice/)

~~~
yoz-y
> 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.

~~~
spectramax
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.

~~~
yoz-y
> 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.

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

[https://github.com/ocornut/imgui](https://github.com/ocornut/imgui)

~~~
moeffju
It looks like Processing to me

~~~
ocornut
It's clearly dear imgui on those screenshots.

~~~
antovsky
Dear ImGui indeed <3

~~~
piyush_soni
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!

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

~~~
piyush_soni
Thanks!

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

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

~~~
keiru
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.

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

~~~
kmundnic
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](https://arxiv.org/ftp/arxiv/papers/1712/1712.01662.pdf)
[2]:
[https://github.com/marcosci/cividis](https://github.com/marcosci/cividis)

~~~
zimpenfish
> 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."

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

~~~
wereHamster
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.

------
londons_explore
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...

~~~
dagw
_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.

------
sitkack
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.

