Repository navigation
rainforest, a new perceptually uniform sequential colormap #14668
Description
My question is pretty simple: How can I add a colormap to Matplotlib?
Inspired by the viridis and cividis colormaps, I have made a new perceptually uniform sequential colormap called 'rainforest' (see below for the colormap and its viscm output).
I originally made this colormap specifically for my PRISM package as an alternative to viridis and cividis, as I felt that these colormaps did not have enough variation in color for what I wanted to use the colormap for.
However, I have been asked by a few people now if I am planning on adding the colormap to Matplotlib or release it as a standalone package, as they would like to use it.
For that reason, I am asking here how I can add it.
Can I do this simply by forking Matplotlib, adding the RGB data to the lib/matplotlib/_cm_listed.py file and opening a PR about it?
Thanks in advance.
EDIT: This colormap is now included in my CMasher package.
Activity
ImportanceOfBeingErnest commentedon Jul 1, 2019
You can check previous PRs that added a colormap, like e.g. #6254.
Here, we'd probably like to see some arguments for why this would be a useful addition to matplotlib. In particular, there is a pretty similar colormap
gist_earthpresent, so one would probably like to see how it compares to that. An output of your colormap inviscmwould probably be useful as well.1313e commentedon Jul 1, 2019
I have heard from several other people that it looks quite similar to
gist_earthas well, even though they have nothing to do with each other funnily enough.However, as can be seen on the Matplotlib page on colormaps, the
gist_earthcolormap is not perceptually uniform sequential.The output from
viscmlooks like below.I did actually try really hard while making it to make it as perceptually uniform as possible.
Seems it does have a very small part where it dips a little bit, which did actually not show up in any of my earlier testing.
The main reason why I made the colormap was simply because the two golden standards (viridis and cividis) both did not have enough variation in color to be used in sequences where small differences should be noticeable.
Added to that is that viridis and cividis do not utilize the full
0-100lightness range, which I felt might be partly to blame.anntzer commentedon Jul 1, 2019
I would suggest publishing the colormap as your own standalone package; see discussion at #6254 (comment) and #6033 (comment).
WeatherGod commentedon Jul 1, 2019
WeatherGod commentedon Jul 1, 2019
tacaswell commentedon Jul 1, 2019
Would it make sense to grab a new top-level namespace package (
mplcm? ) and then document how to create new-sub packages to add new color map sub-packages. I would be happy for both the top-level namespace and contributed packages to live in the matplotlib github org.At a minimum we should make a new section of the third-party tools page specifically for additional color maps.
@1313e I think the biggest advantage of doing a stand-alone package is that it is probably less than a day of work to get it packaged and on pypi so best-case you could have this in users hands tomorrow. If it goes into core matplotlib the best case is September / October.
1313e commentedon Jul 1, 2019
I agree, but making a stand-alone package for simply a single colormap sounds a bit stupid to me.
Plus, putting it into Matplotlib vastly increases the number of people that can use it (as it is much more popular).
I personally would not really mind having to wait a few months before it is published into core Matplotlib.
The colormap is theoretically speaking already available by installing my PRISM package or simply copying and reading its data file.
Uhm, yeah, it does look like it a bit.
I have never used MATLAB before, so never seen that one before.
As the base for the
rainforestcolormap wasjet, which used to be one of the most used colormaps, it does not surprise me that there are several colormaps out there that look somewhat similar.1313e commentedon Jul 1, 2019
Hmm, never thought about it that way.
I personally did need the full range, to maximize the variation in color, but I can see that it might indeed be very useful to be able to put annotation on top of a colormap.
WeatherGod commentedon Jul 1, 2019
jklymak commentedon Jul 1, 2019
I think the fundamental question is how many stock color maps will we support? It seems to me the extremes are “a few” and “hundreds”.
I support @tacaswell idea of a subpackage that has a low bar for entry of new colormaps but keeps them out of the basic list. If one of those becomes wildly popular, it can be moved to the main list.
1313e commentedon Jul 1, 2019
@WeatherGod But, my colormap has nothing to do with theirs.
I had never even seen or heard about it before you mentioned it.
I mean, they cannot really expect to ban any colormap that looks a little bit like one they have copyrighted, right?
WeatherGod commentedon Jul 1, 2019
1313e commentedon Jul 2, 2019
Yeah, I noticed that as well in the output.
It never showed up in any of my testing.
However, I can check if I can maybe solve this problem using
viscm.1313e commentedon Jul 5, 2019
So, next week, I have a conference, but the week after I can have a look and see if I can use
viscmto remove the weird spikes at the green-yellow transition.I have already spent quite some time on this colormap, so I don't mind spending some more on it to make it absolutely perfect.
1313e commentedon Jul 16, 2019
So, as the rainforest colormap was originally not made using
viscmbut withcmaputilinstead, it seems that it is also really hard to use it now to edit it.It seems that I (logically) need to know the locations of all the nodes.
I however don't really know these due to the way I made the colormap in the first place (which does not use nodes), so I am unsure how to get them.
Anybody some advice on how I can convert my RGB data into a file that I can use in
viscm?1313e commentedon Jul 16, 2019
Alright, instead of trying to figure out how to do this, I simply recreated the entire colormap in
viscm(which took me much less time than I thought it was going to take).I think I will make some very small adjustments to it, as I personally have a feeling that the green is not bright enough and there is maybe a bit too much purple, but I am not sure if that is possible while keeping the flat brightness slope.
I also noticed that when using the new spline method (CatmulClark), the perceptual color derivative always looks the way as in this plot, regardless of the actual colormap (I made a completely random one and it still looked the same).
Using the legacy method (Bezier) makes it absolutely flat, but as this forces the path through colorspace to be more circular, I cannot make it as green as I would like to.
I basically recreated the colormap as close as possible using both spline methods, so if required, I can use either one (or improve them a bit more).
1313e commentedon Jul 17, 2019
@tacaswell Any updates on the idea of adding an MPL subpackage specifically for colormaps?
gstorer commentedon Aug 8, 2019
For what its worth I would very much like a full range brightness and colour gamut map that is still perceptually uniform. I sometimes run into situations where I feel as though I don't quite have enough dynamic range to see all the features on my plots. Being able to quickly switch colour maps to fix this would be nice. At present I usually end up fiddling with the scale to truncate or otherwise modify the data (e.g. log scales) to try and get what I want to show up. I am not colour blind and most of my plots never escape a Jupyter notebook. I rarely have time or need to annotate them. The default colour map is a great for many reasons but sometimes I would like to get away from its compromises and use my eye's full range.
1313e commentedon Aug 8, 2019
@gstorer Currently, this colormap (and a new one I made a few days ago) is included in my e13Tools package.
Installing and importing the package automatically makes it available in MPL.
I would really like for the rainforest colormap to become available through MPL itself, as I think it is a great addition to it and it will have a much bigger reach, but for the time being I provide it through e13Tools.
tacaswell commentedon Aug 20, 2019
@1313e putting it in a stand-alone package would probably be better than a bigger tool package. I took a look at the source and I'm not seeing how it is made available.
If you use
matplotlib.cm.register_cmap(https://matplotlib.org/api/cm_api.html?highlight=register_cmap#matplotlib.cm.register_cmap) you can makeax.imshow(..., cmap='rainforest')work.1313e commentedon Aug 21, 2019
@tacaswell I am using the
e13tools.pyplot.import_cmaps()function in order to import all colormaps that are defined in the package, which is done whenever the module is imported.This automatically uses the
matplotlib.cm.register_cmap()function and also adds it as an attribute to thematplotlib.cmmodule.Yeah, putting it into its own package would maybe make it easier, but to make a package for simply a single colormap is kinda weird in my opinion.
Maybe, later on, when I have made a decent collection of colormaps, I will port all of them to a separate package.
However, having said that, currently, others would still require e13Tools and need to import it.
Obviously this is no problem for people I know, but given that the
rainforestcolormap provides characteristics that the other colormaps do not (uses all 3 major colors, uses full lightness range), I think it would be a great addition to MPL.1313e commentedon Sep 17, 2019
Now that the discussion on the
turbocolormap in #15091 is moving forward, I was wondering if this one can move forward as well?1313e commentedon Feb 18, 2020
Just for future references, this colormap (and many others) is now available in the CMasher package.