You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't think that discussion said we'd never ship another colormap, just that there should be a strong argument as to why a colormap is worth including in the core library.
Indeed. One thing that I have personally felt should be a requirement for
inclusion is that the colormap is published in some form. It gives it a
sense of "finality". We required this for the last colormap that got
included, and a good thing too because that review process triggered some
last tweakings to the colormap. This would also help keep the growth of
matplotlib's colormap library in check. Meanwhile, facilitating the use of
third-party colormaps is also useful for colormaps that may or may not meet
our thresholds for inclusion, but are still useful for a particular
community. One example I have thought of are colormaps for land-use maps,
which I feel would be too specific to be included in matplotlib. but would
be very valuable for the geospatial community at large.
On Tue, Aug 20, 2019 at 4:26 PM Jody Klymak ***@***.***> wrote:
I don't think that discussion said we'd never ship another colormap, just
that there should be a strong argument as to why a colormap is worth
including in the core library.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#15091?email_source=notifications&email_token=AACHF6GPNM6OTVJKCAXIRYTQFRHPPA5CNFSM4IN4IEO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4XRV3Q#issuecomment-523180782>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AACHF6HSHNJHC66GXPDX33TQFRHPPANCNFSM4IN4IEOQ>
.
I'm not saying we shouldn't include turbo (at first glance it certainly looks nice); I just think it may be a good idea to have some criteria laid out for doing so.
@mikhailov-work in the account that owns that gist, if turbo goes in I would prefer it be via a PR from someone at google, but that is a weak preference.
I agree having a documented threshold is a good idea, @WeatherGod 's suggestion of at least "published" is good (I think the blog post surpasses that threshold). Not sure what else we should consider?
My current thinking is in favor of including 'turbo'. It seems to be well reasoned and I suspect that it will get picked up by other tools pretty quickly. Also in favor of waiting for 3.3 (~March 2020) rather than squeezing it in for 3.2 (this month) in case there are any tweaks after the first round of publicity.
I'm happy to submit a PR if that makes things easier :)
Indeed, the map looks a bit freaky through viscm. Perceptual lightness derivative could probably be cleaned up while keeping it pretty, maybe I'll give that a go, and see what impact it has on the general perceptual derivative as a byproduct.
I refrained from going too color-science-heavy in the blog, but basically I attempted to make a rainbow map with the constraint of "some kind of analytic curve through CIECAM02-UCS" but it never looked very good or performed well in the field. So in the end I ended up tuning sRGB curves manually (while keeping an eye on color blind acceptability). It's no surprise then, that the perceptual characteristics are a bit wonky. Maybe now that I've got a result I'm happy with by eye, I can go back and use that as a guide to create something more 'principled' and get the best of both worlds.
If anyone has any suggestions I'm certainly all ears as well!
Reacted by Egor Panfilov, M Bussonnier, Paul Willot, dankal444 and endolith
I am also excited about adding turbo to matplotlib.
I spoke at SciPy in 2018 about data viz for analysis, including talking about why rainbow colormaps are a valuable tool for analysis due to their high overall perceptual differentiation.
So, it's great to see this colormap that provides a lot of the value of jet, while mitigating the unnecessary weaknesses.
I'm getting really confused here.
Can somebody tell me why everybody jumps on the turbo hype train, while nothing is really happening with the rainforest colormap (#14668)?
@1313e Not everybody jumps on the turbo. But of course you only see those in favour commenting here. Adding a colormap to matplotlib has always been a cumbersome process. The last colormap ("twilight") that was added took around two years from its initial PR to its release. This is partly due to unclear qualilty standards (and a good portion of hypocrisy in some of the arguments). And I guess until the process of adding colormaps follows an objective criteria catalog, this will not change.
However, an alternative, which was suggested at various places, also in #14668, would be to create a separate package, hosted by the matplotlib organization, that would accept new color(map)s at a higher rate with potentially lower standards. Noone has volonteered to set such package up yet.
The reasoning from my point of view is that jet is a super useful colormap that has seen extremely wide use. I would argue that use has not just been because it was the default of various packages. It works as either sequential or diverging, it has lots of hues so you can tell 0.4 out of 1 from 0.6 out of 1, and it looks good. However it has well known perpetual flaws that make it undesireable for some types of plots. Turbo ameliorates those flaws considerably yet maintains the diverging aspect and a broad range of hues. Hence I think it, or something similar, should be offered as a good jet replacement.
With respect to rainforest, we have five “perceptually uniform” colormaps already so adding another with the same perceptual characteristics and different hues faces a higher bar to acceptance in my opinion. The perceptually uniform colormaps all have the same feel to me, and I think that 90% of the time the sequential data they represent would be better represented as grey (our eyes are really good at greyscale). So I’m not generally in favour of adding more unless one can be shown to be substantially better esthetically than those five.
I agree that "turbo" is especially interesting because solving a problem not addressed by perceptually uniform colormaps.
That said, I would also be interested in adding more perceptually uniform colormaps like "rainforest". Five good colormaps is not very many choices for visualization.
The very short answer is because the idealized version of meritocracy is a lie and programing is fundamentally a human/social activity, but that is getting a bit off topic.
And I guess until the process of adding colormaps follows an objective criteria catalog, this will not change.
I am not convinced that such "objective" criteria for accepting / rejecting color maps exist. viridis, inferno, magma, and plasma are all very different looking color maps that were all trying to maximize the same constraints (perceptually unifrom, colorblind safe). I can think of several levels of applying objective constrains (for luminosity: isolumen, linear and monotonic, linear and diverging, montonic but non-linear, diverging but non-linear, cyclic), but even that ends up subjective because you have to pick a model. At the root, color maps are picking a 1D path through a 3D space and (modulo the fact that we are quantizing colors to 24bits and 256 samples) there are effectively an infinite number of valid color maps for any objective constraint (and again, picking the constraints is a subjective activity).
For any given colormap we will have to make a judgement call if this colormap with this name is worth putting into Matplotlib. Is it a good name? Does it "look nice? Is there an audience for this color map? Is it well thought through / motivated? Does it add something that we are currently lacking? Is it "done"? Will users expect a color map with this name?
In this case, as @jklymak argued, turbo is filling a space that there is a demand for (some people really really like rainbow color maps 🤷♀️ if we can give them one that is less bad that seems like a win), there is a long and well written blog post explaining why they made it and the choices the made, and it sounds like there may still be some fine tuning.
and a good portion of hypocrisy in some of the arguments
I'm not sure what hypocrisy you are talking about. Including a colormap is fundamentally a judgement call. As people talk through that judgement in a public forum it is important for people to feel safe "thinking out loud" and if it is a close issue argue both sides at different points even if it is . It is also critical that we assume everyone is working in good faith (or the whole thing falls apart).
I previously suggested that we should make a namespace package for color maps, but at the time I had forgotten about register_cmap. I no longer think we need such a package as it is easy for third-party packages to register their own color maps on import (seabon, cmocean, palettable, and colorcet all do this). Might still be worth looking into an entry-point based plugin system, but I don't think that is worth waiting for.
Given @shoyer and @mikhailov-work 's comments I am going to stand by asking this go in no earlier than 3.3 to give it time to anneal a bit and would appreciate a PR from @mikhailov-work .
Reacted by Jody Klymak, Ryan May, mikhailov-work and Ellert van der Velden
Reacted by Egor Panfilov, Stephan Hoyer, Evan Bolyen and mikhailov-work
With respect to rainforest, we have five “perceptually uniform” colormaps already so adding another with the same perceptual characteristics and different hues faces a higher bar to acceptance in my opinion. The perceptually uniform colormaps all have the same feel to me, and I think that 90% of the time the sequential data they represent would be better represented as grey (our eyes are really good at greyscale). So I’m not generally in favour of adding more unless one can be shown to be substantially better esthetically than those five.
@jklymak The rainforest colormap was made specifically to use as many colors as possible, creating the same effect as jet does (where values are very easily distinguishable from each other), but without all the problems jet comes with.
I basically made it to be the replacement for using jet (the original incarnation of rainforest even used a modified jet), intending for it to live alongside viridis as the standard choice.
Hi @tacaswell, I think the map discussion has stabilized. I took some attempts at making the lightness derivatives more smooth/linear, but it substantially alters the feel of the map (some for better, some for worse), and so I think those will have to be topics for a future work :)
I have a PR ready but you mentioned before that I should add it to 3.3. I didn't see a branch for that yet, should I just hang on till that's available?
I have a PR ready but you mentioned before that I should add it to 3.3. I didn't see a branch for that yet, should I just hang on till that's available?
No, every PR should target the master branch. Developpers will then make sure that it's tagged with "v3.3" (and backported if that branch exists already). Nothing to worry about for you, just create the PR for master once you feel you're ready.
By the way, for posterity, here are the results of my attempt to "linearize" turbo to some degree:
(thanks @shoyer for running it through viscm)
The lightness derivative is decently linear, but in the end I doubt it will help address people's concerns about perceptual uniformity (since it would need to be constant, not linear). The perceptual derivative is still pretty wild. It also introduces a 'pinkish-orange' color which I think doesn't fit the spectral ordering well.
Ultimately changing it further will just make a very different map and likely lose the advantages discussed in the post. Perhaps most clearly, the low-high-low lightness profile is the source of both the main strength (higher contrast) and the weakness (slightly less contrast at center 'green' and bw ambiguity). So since changing the broader profile is outside of scope of 'tweaking', I'm just going to call this one done and leave improvements for a future date :)
Thus, while Turbo and Rainbow improve upon some of Jet’s shortcomings, neither is colorblind-friendly.
Finally, a funny quote from one user about why one would use the turbo colormap:
“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.”
I like @mpetroff 's analysis, because it at least makes clear the advantages of colormaps like jet, even though they have issues for colour-blind folks.
Indeed, even after the 'scathing review' I had great follow up chats with @mpetroff and Joshua :)
Replacing jet for people who won't let go of jet (for valid or invalid reasons) is ultimately the main purpose of this map, so if that means getting around a grumpy boss then I'm all for it! This is a surprisingly common 'real world' issue :\
Activity
anntzer commentedon Aug 20, 2019
See #14668 for discussion about shipping new colormaps.
jklymak commentedon Aug 20, 2019
I don't think that discussion said we'd never ship another colormap, just that there should be a strong argument as to why a colormap is worth including in the core library.
WeatherGod commentedon Aug 20, 2019
anntzer commentedon Aug 20, 2019
I'm not saying we shouldn't include turbo (at first glance it certainly looks nice); I just think it may be a good idea to have some criteria laid out for doing so.
tacaswell commentedon Aug 20, 2019
@mikhailov-work in the account that owns that gist, if turbo goes in I would prefer it be via a PR from someone at google, but that is a weak preference.
I agree having a documented threshold is a good idea, @WeatherGod 's suggestion of at least "published" is good (I think the blog post surpasses that threshold). Not sure what else we should consider?
As I just mentioned on the 'rainforest' PR, there is existing public API to register a named color map (see https://matplotlib.org/api/cm_api.html )
My current thinking is in favor of including 'turbo'. It seems to be well reasoned and I suspect that it will get picked up by other tools pretty quickly. Also in favor of waiting for 3.3 (~March 2020) rather than squeezing it in for 3.2 (this month) in case there are any tweaks after the first round of publicity.
shoyer commentedon Aug 20, 2019
I'm also very enthusiastic about this!
I ran turbo through viscm:

This highlights some potential room for improvement -- perhaps the perceptual derivative could be a bit smoother?
mikhailov-work commentedon Aug 20, 2019
I'm happy to submit a PR if that makes things easier :)
Indeed, the map looks a bit freaky through viscm. Perceptual lightness derivative could probably be cleaned up while keeping it pretty, maybe I'll give that a go, and see what impact it has on the general perceptual derivative as a byproduct.
I refrained from going too color-science-heavy in the blog, but basically I attempted to make a rainbow map with the constraint of "some kind of analytic curve through CIECAM02-UCS" but it never looked very good or performed well in the field. So in the end I ended up tuning sRGB curves manually (while keeping an eye on color blind acceptability). It's no surprise then, that the perceptual characteristics are a bit wonky. Maybe now that I've got a result I'm happy with by eye, I can go back and use that as a guide to create something more 'principled' and get the best of both worlds.
If anyone has any suggestions I'm certainly all ears as well!
zanarmstrong commentedon Aug 21, 2019
I am also excited about adding turbo to matplotlib.
I spoke at SciPy in 2018 about data viz for analysis, including talking about why rainbow colormaps are a valuable tool for analysis due to their high overall perceptual differentiation.
So, it's great to see this colormap that provides a lot of the value of jet, while mitigating the unnecessary weaknesses.
1313e commentedon Aug 22, 2019
I'm getting really confused here.
Can somebody tell me why everybody jumps on the
turbohype train, while nothing is really happening with therainforestcolormap (#14668)?ImportanceOfBeingErnest commentedon Aug 22, 2019
@1313e Not everybody jumps on the turbo. But of course you only see those in favour commenting here. Adding a colormap to matplotlib has always been a cumbersome process. The last colormap ("twilight") that was added took around two years from its initial PR to its release. This is partly due to unclear qualilty standards (and a good portion of hypocrisy in some of the arguments). And I guess until the process of adding colormaps follows an objective criteria catalog, this will not change.
However, an alternative, which was suggested at various places, also in #14668, would be to create a separate package, hosted by the matplotlib organization, that would accept new color(map)s at a higher rate with potentially lower standards. Noone has volonteered to set such package up yet.
jklymak commentedon Aug 22, 2019
The reasoning from my point of view is that jet is a super useful colormap that has seen extremely wide use. I would argue that use has not just been because it was the default of various packages. It works as either sequential or diverging, it has lots of hues so you can tell 0.4 out of 1 from 0.6 out of 1, and it looks good. However it has well known perpetual flaws that make it undesireable for some types of plots. Turbo ameliorates those flaws considerably yet maintains the diverging aspect and a broad range of hues. Hence I think it, or something similar, should be offered as a good jet replacement.
With respect to rainforest, we have five “perceptually uniform” colormaps already so adding another with the same perceptual characteristics and different hues faces a higher bar to acceptance in my opinion. The perceptually uniform colormaps all have the same feel to me, and I think that 90% of the time the sequential data they represent would be better represented as grey (our eyes are really good at greyscale). So I’m not generally in favour of adding more unless one can be shown to be substantially better esthetically than those five.
shoyer commentedon Aug 22, 2019
I agree that "turbo" is especially interesting because solving a problem not addressed by perceptually uniform colormaps.
That said, I would also be interested in adding more perceptually uniform colormaps like "rainforest". Five good colormaps is not very many choices for visualization.
tacaswell commentedon Aug 22, 2019
The very short answer is because the idealized version of meritocracy is a lie and programing is fundamentally a human/social activity, but that is getting a bit off topic.
I am not convinced that such "objective" criteria for accepting / rejecting color maps exist. viridis, inferno, magma, and plasma are all very different looking color maps that were all trying to maximize the same constraints (perceptually unifrom, colorblind safe). I can think of several levels of applying objective constrains (for luminosity: isolumen, linear and monotonic, linear and diverging, montonic but non-linear, diverging but non-linear, cyclic), but even that ends up subjective because you have to pick a model. At the root, color maps are picking a 1D path through a 3D space and (modulo the fact that we are quantizing colors to 24bits and 256 samples) there are effectively an infinite number of valid color maps for any objective constraint (and again, picking the constraints is a subjective activity).
For any given colormap we will have to make a judgement call if this colormap with this name is worth putting into Matplotlib. Is it a good name? Does it "look nice? Is there an audience for this color map? Is it well thought through / motivated? Does it add something that we are currently lacking? Is it "done"? Will users expect a color map with this name?
In this case, as @jklymak argued, turbo is filling a space that there is a demand for (some people really really like rainbow color maps 🤷♀️ if we can give them one that is less bad that seems like a win), there is a long and well written blog post explaining why they made it and the choices the made, and it sounds like there may still be some fine tuning.
I'm not sure what hypocrisy you are talking about. Including a colormap is fundamentally a judgement call. As people talk through that judgement in a public forum it is important for people to feel safe "thinking out loud" and if it is a close issue argue both sides at different points even if it is . It is also critical that we assume everyone is working in good faith (or the whole thing falls apart).
I previously suggested that we should make a namespace package for color maps, but at the time I had forgotten about
register_cmap. I no longer think we need such a package as it is easy for third-party packages to register their own color maps on import (seabon, cmocean, palettable, and colorcet all do this). Might still be worth looking into an entry-point based plugin system, but I don't think that is worth waiting for.Given @shoyer and @mikhailov-work 's comments I am going to stand by asking this go in no earlier than 3.3 to give it time to anneal a bit and would appreciate a PR from @mikhailov-work .
mikhailov-work commentedon Aug 22, 2019
Thanks, giving it 'time to anneal' sounds like a good idea. I'll submit a PR in the next few weeks and it can sit there whenever you're ready :)
1313e commentedon Aug 26, 2019
@jklymak The
rainforestcolormap was made specifically to use as many colors as possible, creating the same effect asjetdoes (where values are very easily distinguishable from each other), but without all the problemsjetcomes with.I basically made it to be the replacement for using
jet(the original incarnation ofrainforesteven used a modifiedjet), intending for it to live alongsideviridisas the standard choice.mikhailov-work commentedon Sep 16, 2019
Hi @tacaswell, I think the map discussion has stabilized. I took some attempts at making the lightness derivatives more smooth/linear, but it substantially alters the feel of the map (some for better, some for worse), and so I think those will have to be topics for a future work :)
I have a PR ready but you mentioned before that I should add it to 3.3. I didn't see a branch for that yet, should I just hang on till that's available?
Thanks!
ImportanceOfBeingErnest commentedon Sep 16, 2019
No, every PR should target the master branch. Developpers will then make sure that it's tagged with "v3.3" (and backported if that branch exists already). Nothing to worry about for you, just create the PR for master once you feel you're ready.
mikhailov-work commentedon Sep 16, 2019
Ah ok, thank you! Here it is #15275.
mikhailov-work commentedon Sep 16, 2019
By the way, for posterity, here are the results of my attempt to "linearize" turbo to some degree:

(thanks @shoyer for running it through viscm)
The lightness derivative is decently linear, but in the end I doubt it will help address people's concerns about perceptual uniformity (since it would need to be constant, not linear). The perceptual derivative is still pretty wild. It also introduces a 'pinkish-orange' color which I think doesn't fit the spectral ordering well.
Ultimately changing it further will just make a very different map and likely lose the advantages discussed in the post. Perhaps most clearly, the low-high-low lightness profile is the source of both the main strength (higher contrast) and the weakness (slightly less contrast at center 'green' and bw ambiguity). So since changing the broader profile is outside of scope of 'tweaking', I'm just going to call this one done and leave improvements for a future date :)
ImportanceOfBeingErnest commentedon Sep 17, 2019
Further discussion on the turbo colormap is found in
https://news.ycombinator.com/item?id=20754364
There is a twitter story by a NASA data visualization pro in
https://twitter.com/jscarto/status/1164190471222116352
Also, a detailed analysis of the colorblind-friedlyness is done by @mpetroff in
https://mpetroff.net/2019/08/discernibility-of-rainbow-colormaps/
concluding in
Finally, a funny quote from one user about why one would use the turbo colormap:
jklymak commentedon Sep 17, 2019
I like @mpetroff 's analysis, because it at least makes clear the advantages of colormaps like jet, even though they have issues for colour-blind folks.
mikhailov-work commentedon Sep 17, 2019
Indeed, even after the 'scathing review' I had great follow up chats with @mpetroff and Joshua :)
Replacing jet for people who won't let go of jet (for valid or invalid reasons) is ultimately the main purpose of this map, so if that means getting around a grumpy boss then I'm all for it! This is a surprisingly common 'real world' issue :\
bergkvist commentedon Dec 16, 2019
By copy-pasting the following snippet into your code you can use
cmap='turbo'until it is officially added to matplotlib:I copy-pasted the
turbo_colormap_datafrom the original gist by Anton Mikhailov.QuLogic commentedon Apr 30, 2020
Added in #15275.