Offhand, this sounds like a reasonable idea; but how many maps do you think you would be able to modify this way? For monocolor maps like this, is there a nice function that could be applied more generally?
I don't think that renaming 'jet' as 'legacy_jet' is a good idea, though, unless you can generate something that is plausible as an improved jet. Code that specifies 'jet' should not be broken.

👍 Having a perceptual basis where we can have it is a good thing. Would this also work for ones like RdBu?

Just to record my opinion on this. I am not against creating better
versions of existing colormap, but I am against renaming any of the
existing colormap. Renaming colormap is different from changing style
defaults. When we change the defaults, we are not changing any semantic
meanings. Dotted will still produce the same ugly dotted lines, linewidths
will still be in units of points, and red will still be red.

Yada, yada, yada,... Cats and dogs living together, mass hysteria!
On Jul 13, 2015 7:59 PM, "Kristen Thyng" notifications@github.com wrote:

Based on evolving conversations in the scipy community (particularly
during the SciPy conference last week), I'm proposing to update the
colormaps structure in matplotlib. I've remade the Blues colormap as an
example, in this PR. The new structure would emphasize good colormap
practices and would break some backward compatibility. (I suspect most
people won't notice their colormaps changing if they have specifically
called for 'Blues' since they look similar, but if they were specifically
calling for 'jet' in the new structure, it wouldn't know where to find it
since it would instead be 'legacy_jet'.) This would be in support of the
default colormap change.

I've replaced the colormap definition dictionary for 'Blues' with a
colormap I remade using the viscm tool from @njsmith
https://github.com/njsmith and @stefanv https://github.com/stefanv
for creating perceptually uniform colormaps. I moved the old Blues
dictionary to 'legacy_Blues' so that people can still access it if they so
choose. The new colormap is slightly improved to have uniform perceptual
increases in the colormap in cam02ucs colorspace, but is also intended to
look similar to the old colormap. You'll notice that the gradient through
the colormap is more even in the new colormap as compared with the old. For
example, the light and dark end of the proposed 'Blues' colormap have
similar perceived differences between steps, whereas in the current
colormap, the light end appears to have smaller gradients (for the same
quantitative step) than the darker end.
Current:
[image: legacy_blues]
https://cloud.githubusercontent.com/assets/3487237/8663415/401bb8dc-2990-11e5-8b3e-38a5ef09ec83.png

Proposed:
[image: blues]
https://cloud.githubusercontent.com/assets/3487237/8663420/4800ed9c-2990-11e5-9743-5bde63d1dd5a.png

My proposal would be to do something similar for the other sequential and
diverging colormaps: updating them and burying the previous version under
'legacy_*'. I would also plan to create another page for the documentation
to showcase the "approved" colormaps which would have subpages to show the
legacy colormaps as well as others that won't be replaced but that we don't
recommend using (like jet). So, all colormaps and more would still be
available, but the colormaps would be slightly different for some, and
access would decrease for others.

You can test the colormaps in this PR by making your favorite pcolor plot
using cmap='Blues' to try the new colormap and cmap='legacy_Blues' to
compare with the old/current colormap. This colormap could be adjusted
using the viscm tool; it was just what I came up with from some fiddling.

I think @efiring https://github.com/efiring, @tacaswell
https://github.com/tacaswell, @WeatherGod
https://github.com/WeatherGod, @dmcdougall
https://github.com/dmcdougall, @mdboom https://github.com/mdboom,
@jenshnielsen https://github.com/jenshnielsen, @pwolfram

https://github.com/pwolfram, and others might have input.

You can view, comment on, or merge this pull request online at:

#4681
Commit Summary

• updated Blues colormap and demoted old Blues to legacy_Blues

File Changes

• M lib/matplotlib/_cm.py
  https://github.com/matplotlib/matplotlib/pull/4681/files#diff-0 (86)

Patch Links:

• https://github.com/matplotlib/matplotlib/pull/4681.patch
• https://github.com/matplotlib/matplotlib/pull/4681.diff

—
Reply to this email directly or view it on GitHub
#4681.

@WeatherGod makes a good point; now I am not at all sure that this renaming is a good idea---or perhaps when it is and when it isn't. Maps like RdBu from ColorBrewer, for example, probably should not be renamed; if an improved RdBu-like map is constructed, it should have a different name--maybe just adding a very short prefix.

I am in agreement with @kthyng. @WeatherGod makes an important point we should take very seriously. There is a great need for perceptual uniformity, in so much as it is possible. However, we don't want to break anyone's existing code to disenfranchise existing matplotlib users. I'm throwing out this one possible solution, adapted from @efiring (others should suggest theirs for discussion):

1. One approach to maintain backwards compatibility would be to have a prefix or suffix, say pc_* or *_pc added to each colorbar where pc stands for perceptual consistency or some such. This would ensure existing code does not get broken and it would be easy to have an option that selects all these pc colorbars because they all have a specific and unique beginnings or ending.

In cases where the changes are small I think I am in favor changing the color maps in place. I suspect (and am not sure how to prove) that the variation between monitors/projectors can be of the same degree as the difference between these two maps.

My concern with tacking pc_* onto the front of all the color maps is that they will not get used as people will not know about them. I think we should accept the possible inconvenience to a very small number of user for the pay off of getting better color maps into the hands of many more users.

This ties back to the requests to change the RGBA values of the single character colors (ex 'r', 'b', 'g', ...) and the default on/off pattern of --. We have already accepted that we are going to break API and I think all three of these things should be in the set of things we consider to change.

This particular proposal looks to have picked up a greenish tint to me which I am not a huge fan of.

I am still in favor of actually changing what certain colormaps mean, like
Blues. If we can have a better definition, perceptually, of the colormap, I
think it is better to use it as the standard. But, as @efiring implied,
having a standardized way of fixing them would be best probably. This would
require a reworking of the viscm tool. @stefanv mentioned that he (I think)
had or could update the tool to make it "fix" a colormap automatically in
some manner, though I think choices are still being made in the process
about what to optimize with respect to.

I'm ok with backing off on demoting colormaps that aren't being replaced
behind "legacy_*". We could still try to represent in documentation which
colormaps are most recommended.

I agree with @tacaswell that the new colormaps probably won't be used if
they are under a different name, except if people look at the documentation
just mentioned.

On Tue, Jul 14, 2015 at 10:18 AM, Thomas A Caswell <notifications@github.com

wrote:

In cases where the changes are small I think I am in favor changing the
color maps in place. I suspect (and am not sure how to prove) that the
variation between monitors/projectors can be of the same degree as the
difference between these two maps.

My concern with tacking pc_* onto the front of all the color maps is that
they will not get used as people will not know about them. I think we
should accept the possible inconvenience to a very small number of user for
the pay off of getting better color maps into the hands of many more users.

This ties back to the requests to change the RGBA values of the single
character colors (ex 'r', 'b', 'g', ...) and the default on/off pattern of
--. We have already accepted that we are going to break API and I think
all three of these things should be in the set of things we consider to
change.

This particular proposal looks to have picked up a greenish tint to me
which I am not a huge fan of.

—
Reply to this email directly or view it on GitHub
#4681 (comment)
.

Kristen M. Thyng
Assistant Research Scientist
Department of Oceanography
Texas A&M University
Eller O&M 618
http://kristenthyng.com

I suppose one option would be to add a Boolean rc value "legacy_colormaps"
that toggles which map you get off you just request "blues". So by default
you would get the improved version, but after style.use("matplotlib1") you
get the old version.
.
Not sure how this would interact with accessing colormaps as objects
instead of strings, though. I suppose we could make attribute access match
string lookup...
On Jul 14, 2015 11:22, "Kristen Thyng" notifications@github.com wrote:

I am still in favor of actually changing what certain colormaps mean, like
Blues. If we can have a better definition, perceptually, of the colormap, I
think it is better to use it as the standard. But, as @efiring implied,
having a standardized way of fixing them would be best probably. This would
require a reworking of the viscm tool. @stefanv mentioned that he (I think)
had or could update the tool to make it "fix" a colormap automatically in
some manner, though I think choices are still being made in the process
about what to optimize with respect to.

I'm ok with backing off on demoting colormaps that aren't being replaced
behind "legacy_*". We could still try to represent in documentation which
colormaps are most recommended.

I agree with @tacaswell that the new colormaps probably won't be used if
they are under a different name, except if people look at the documentation
just mentioned.

On Tue, Jul 14, 2015 at 10:18 AM, Thomas A Caswell <
notifications@github.com

wrote:

In cases where the changes are small I think I am in favor changing the
color maps in place. I suspect (and am not sure how to prove) that the
variation between monitors/projectors can be of the same degree as the
difference between these two maps.

My concern with tacking pc_* onto the front of all the color maps is that
they will not get used as people will not know about them. I think we
should accept the possible inconvenience to a very small number of user
for
the pay off of getting better color maps into the hands of many more
users.

This ties back to the requests to change the RGBA values of the single
character colors (ex 'r', 'b', 'g', ...) and the default on/off pattern
of
--. We have already accepted that we are going to break API and I think
all three of these things should be in the set of things we consider to
change.

This particular proposal looks to have picked up a greenish tint to me
which I am not a huge fan of.

—
Reply to this email directly or view it on GitHub
<
https://github.com/matplotlib/matplotlib/pull/4681#issuecomment-121279758>
.

Kristen M. Thyng
Assistant Research Scientist
Department of Oceanography
Texas A&M University
Eller O&M 618
http://kristenthyng.com

—
Reply to this email directly or view it on GitHub
#4681 (comment)
.

That is an idea. I am just about done with the "classic" style. It would be
possible to throw in that param so that users have a simple way to switch
when they are ready.
On Jul 14, 2015 6:34 PM, "Nathaniel J. Smith" notifications@github.com
wrote:

I suppose one option would be to add a Boolean rc value "legacy_colormaps"
that toggles which map you get off you just request "blues". So by default
you would get the improved version, but after style.use("matplotlib1") you
get the old version.
.
Not sure how this would interact with accessing colormaps as objects
instead of strings, though. I suppose we could make attribute access match
string lookup...
On Jul 14, 2015 11:22, "Kristen Thyng" notifications@github.com wrote:

I am still in favor of actually changing what certain colormaps mean,
like
Blues. If we can have a better definition, perceptually, of the
colormap, I
think it is better to use it as the standard. But, as @efiring implied,
having a standardized way of fixing them would be best probably. This
would
require a reworking of the viscm tool. @stefanv mentioned that he (I
think)
had or could update the tool to make it "fix" a colormap automatically in
some manner, though I think choices are still being made in the process
about what to optimize with respect to.

I'm ok with backing off on demoting colormaps that aren't being replaced
behind "legacy_*". We could still try to represent in documentation which
colormaps are most recommended.

I agree with @tacaswell that the new colormaps probably won't be used if
they are under a different name, except if people look at the
documentation
just mentioned.

On Tue, Jul 14, 2015 at 10:18 AM, Thomas A Caswell <
notifications@github.com

wrote:

In cases where the changes are small I think I am in favor changing the
color maps in place. I suspect (and am not sure how to prove) that the
variation between monitors/projectors can be of the same degree as the
difference between these two maps.

My concern with tacking pc_* onto the front of all the color maps is
that
they will not get used as people will not know about them. I think we
should accept the possible inconvenience to a very small number of user
for
the pay off of getting better color maps into the hands of many more
users.

This ties back to the requests to change the RGBA values of the single
character colors (ex 'r', 'b', 'g', ...) and the default on/off pattern
of
--. We have already accepted that we are going to break API and I think
all three of these things should be in the set of things we consider to
change.

This particular proposal looks to have picked up a greenish tint to me
which I am not a huge fan of.

—
Reply to this email directly or view it on GitHub
<

https://github.com/matplotlib/matplotlib/pull/4681#issuecomment-121279758>

.

Kristen M. Thyng
Assistant Research Scientist
Department of Oceanography
Texas A&M University
Eller O&M 618
http://kristenthyng.com

—
Reply to this email directly or view it on GitHub
<
https://github.com/matplotlib/matplotlib/pull/4681#issuecomment-121295847>
.

—
Reply to this email directly or view it on GitHub
#4681 (comment)
.

If you are going to change them, use "CB_Blues" or "ColorBrewer_Blues" instead of "legacy_Blues", since that's where they are from.

Also I've been meaning to check that the values in _cm.py are actually consistent with the original ColorBrewer Excel sheet. I think they were originally copied from somewhere else in an interpolated form and then had some of the redundant linearly-interpolated values removed? If the original 9 points specified in the original are smoothly interpolated in a perceptual colorspace (without clipping), I think that could remain under the original names, since it still passes through the same points? Could make them slightly better, but I'm not sure how noticeable it would be.

Update: I went through and converted all the ColorBrewer maps to RGB format, taken directly from the Excel spreadsheet in this commit: endolith@411d0b3 in this PR: #3973

I agree with Michael on this. What would be cool is to have a "palette"
option that could act as a sort of namespace for colormaps.

On Sat, Jan 23, 2016 at 4:27 PM, Michael Waskom notifications@github.com
wrote:

I'm not sure if this PR is stale or not, but it is referenced in the style
change PR.

FWIW, I think that (a) having more mono-hue perceptually-uniform colormaps
in matplotlib would be great and (b) it doesn't make sense to replace a
small set of colorbrewer cmaps with new ones and keep the names.

For better or worse, "Blues", "BuGn", etc. mean something relatively
specific across a number of packages. It seems extra confusing that a
colorbrewer name could sometimes return a perceptually-uniform colormap or
sometimes return a "legacy" colorbrewer map depending on exactly which one
the user asks for.

My suggestion would be to only replace the colorbrewer names if all
colorbrewer cmaps are replaced. And, even then, I think it is preferable to
just use new names for the new colormaps.

—
Reply to this email directly or view it on GitHub
#4681 (comment)
.

After the discussion here we have decided to not change the color maps returned by an existing name.

Instead we would like to add a new name space for color maps which are derived from the perceptually uniform model. Given that this will not break any user code, this can be punted to 2.1.

That makes sense to me — thanks for the all the useful comments!

On Mon, Jan 25, 2016 at 3:30 PM, Thomas A Caswell notifications@github.com
wrote:

After the discussion here we have decided to not change the color maps
returned by an existing name.

Instead we would like to add a new name space for color maps which are
derived from the perceptually uniform model. Given that this will not break
any user code, this can be punted to 2.1.

—
Reply to this email directly or view it on GitHub
#4681 (comment)
.

Kristen M. Thyng
Assistant Research Scientist
Department of Oceanography
Texas A&M University
Eller O&M 608
http://kristenthyng.com

I think we missed the window for this with 2.0 😞 Sorry @kthyng

Thank you for your work on this!

For people who come across this issue in the future see https://matplotlib.org/cmocean for more great color maps.