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_earth present, so one would probably like to see how it compares to that. An output of your colormap in viscm would probably be useful as well.

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_earth present, so one would probably like to see how it compares to that. An output of your colormap in viscm would probably be useful as well.

I have heard from several other people that it looks quite similar to gist_earth as 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_earth colormap is not perceptually uniform sequential.

The output from viscm looks 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-100 lightness range, which I felt might be partly to blame.

I would suggest publishing the colormap as your own standalone package; see discussion at #6254 (comment) and #6033 (comment).

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

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.

This looks similar to mathwork's parula, doesn't it? https://www.mathworks.com/help/matlab/ref/parula.html

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 rainforest colormap was jet, 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.

By the way, there is a reason why the viridis and friends colormaps don't fully use the brightness scale. This makes it possible for annotations in black or white to appear on top of a colormapped image.

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.

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.

@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?

I do still have concerns about your colormap based on the output from viscm showing some perceptual discontinuities, particularly those yellows.

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.

So, next week, I have a conference, but the week after I can have a look and see if I can use viscm to 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.

So, as the rainforest colormap was originally not made using viscm but with cmaputil instead, 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?

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

@tacaswell Any updates on the idea of adding an MPL subpackage specifically for colormaps?

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.

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

@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 make ax.imshow(..., cmap='rainforest') work.

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

@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 the matplotlib.cm module.

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 rainforest colormap 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.

Now that the discussion on the turbo colormap in #15091 is moving forward, I was wondering if this one can move forward as well?

Just for future references, this colormap (and many others) is now available in the CMasher package.