There have been two related discussions on the [matplotlib-devel] mailing list: Another colormap and Implementation of cubehelix color scheme. Btw, the hot/heat colormaps perform poorly with 3D shading.

Btw, the hot/heat colormaps perform poorly with 3D shading.

In what way? Here's jet compared to hot:

That seems to be an objection against using it for 3D CAD? Can you even do things like that in matplotlib? I don't see anything like it in the gallery.

I agree with this comment from the mailing list:

I'd prefer a two-tone colormap as the default (two-distinct tones at the limits with a gradient in-between---dubbed "sequential" in the paper) instead of a three-tone colormap (three-distinct tones---dubbed "diverging" in the paper). (I think this is a more common use case, and I think using a "diverging" colormap effectively requires setting vmin/vmax.)

The coolwarm is meant for "diverging" data, with dark blue negative values, bright white middle 0 values, and dark red positive values (same dark-light-dark problem as jet, but not as bad), while the more common case is "sequential" data from dark zero to bright positive (which is why the first paper above recommends heat/hot when nothing else is known about the use case).

But obviously, nothing will be perfect for every case. Different maps are more appropriate for different situations. Unless there's a way to set different defaults for different types of plots, we just have to pick one that will work better than jet in the common types of plots where people don't change the defaults.

I'm +1 for changing colormap to something more sane than jet. Thanks to everyone for providing links to the relevant resources.

We probably have examples in the test suite that rely on the reference images being rendered in 'jet' - those reference images would have to either be changed, or the default cm switched to jet for testing, and back to the default again post testing.

It should be noted that the default colormap can currently be set via an rcParam. In your matplotlibrc just put:

image.cmap   : hot 

or

image.cmap   : bwr

etc...

If there are places in the code where this cmap setting is not respected (except for instances where it is explicitly specified), those should be considered bugs and should be filed as such.

I don't see any polite way to make such a change (different default colormap). Everyone is used to the nice, colorful jet popping up. I predict that if it is changed, there will be a lot of unhappy users. User code will not behave the way it used to, in a very obvious and major way. Instead of changing the default (at least initially), it would be better to change the gallery examples and documentation to explain and illustrate better colormap choices for various purposes. This can be done incrementally, without breaking any user code.

@efiring, I think that is an excellent idea. We might one day change the default, but this approach might begin the movement from within the userbase. Over time, we might even be able to figure out what a suitable default is.

I still think the default should be changed sooner than later, and that the user who doesn't care enough to change the default isn't going to care if the default changes, but improving the demos is a good idea, too.

It looks like it's not as simple as changing the cmap alone, though, since some have bipolar data and want a diverging colormap, but the colormap isn't currently centered. The seismic colormap highlights the midpoint well. I used this and it worked:

vmax = max( amax(Z), -amin(Z)), 
vmin = min(-amax(Z),  amin(Z)),

Is there a better way to center the colormap?

It is actually the norm, not the colormap, that is being centered. You raise a good question. There should be an automatic way (selected by a kwarg) to achieve what you are doing manually, but in general there isn't. I am working on a branch to take care of it, so I expect to have a pull request ready within a few days.

Ok, so actually instead of setting vmax vmin, I should be using something like norm=Normalize(-abs(Z1).max(), abs(Z1).max())?

What will be the syntax for your addition? If the data happens to vary from 4 to 10, and the defined midpoint is 5, we should be able to just say "the midpoint of the colormap is 5" and it will automatically use the extreme values to set the colormap range from 0 to 10.

These are some changes in the branch where I'm changing the example colormaps:https://github.com/endolith/matplotlib/compare/c6fac36ed3c5f14c2a9863d9c68f6a8fa068fcbc (Not sure how else to link to a branch)

On 06/04/2012 04:46 AM, endolith wrote:

Ok, so actually instead of setting vmax vmin, I should be using
something like norm=Normalize(-abs(Z1).max(), abs(Z1).max())?

Not necessarily; when vmin, vmax kwargs are available, they are being
passed internally to the norm, so there is no problem with using them as
you did. I was only trying to clarify the terminology, because this is
a somewhat subtle but important point--the distinction between the
actual colormap (cmap kwarg) and the norm, and the fact that they work
together to achieve color mapping.

What will be the syntax for your addition? If the data happens to
vary from 4 to 10, and the defined midpoint is 5, we should be able
to just say "the midpoint of the colormap is 5" and it will
automatically use the extreme values to set the colormap range from 0
to 10.

Yes, that is exactly what I have in mind. I have a branch started to do
this, but it is not ready yet. I am thinking of a kwarg called "vmid"
to go with "vmin" and "vmax", the idea being that if it is not None then
it expands any specified or autoscaled range in the manner you describe.

That sounds like a good keyword to me.

If you do include vmid and vmax, then vmin is vmid-(vmax-vmid)?

if you include all three, the scale is non-linear, normalized independently from the midpoint to the max point and from the midpoint to the min point? http://stackoverflow.com/q/7404116/125507

On 06/05/2012 05:18 AM, endolith wrote:

That sounds like a good keyword to me.

If you do include vmid and vmax, then vmin is vmid-(vmax-vmid)?

if you include all three, the scale is non-linear, normalized independently from the midpoint to the max point and from the midpoint to the min point?

No to both. It's much simpler than that. Think of it this way. First,
if either or both of vmin, vmax is provided, then they override the
previous values, which may have resulted from autoscaling. Second, the
upper or lower limit is moved outward as needed to center the scale on
vmid. That's all.

Just thinking out loud, I remember being able to specify just vmin or just vmax and let the autoscaling handle the unspecified end. Is that still the case?

On 06/06/2012 08:37 AM, Benjamin Root wrote:

Just thinking out loud, I remember being able to specify just vmin or
just vmax and let the autoscaling handle the unspecified end. Is
that still the case?

Yes.

Just wanted to note here that I have a SymmetricNorm class which auto-scales evenly around a centre point.
It sounds like it could do the trick (and potentially avoid mutually exclusive keywords) and I'd be happy to share.

Maybe the symmetric norm stuff should be added under #632?

Closed after #921 merge

(I'm still in favor of changing the default, for the record.) :)

I (very belatedly) add a vote for changing the default color map.

FYI, "jet" won't be the default colormap for MATLAB anymore. The new release has finally improved this and other related aspects. http://www.mathworks.es/products/matlab/matlab-graphics/#new_look_for_matlab_graphics

There is also a new default colormap in R2014b called parula [named after a similarly-colored bird?]. The colors in the parula colormap are ordered from dark to light and are perceptually uniform. Smooth changes in the data appear as smooth changes in color, while sharp changes in the data appear as sharp changes in color.

Well, at least someone is doing it. Hopefully open source projects copy this now instead of copying jet?

Regardless, changing the default color map is still an api break which we won't do until 2.0.

As this point was a bit lost in the discussion if to break the API, which of the MPL's colormaps would be considered as the best alternative to jet these days? Is there something like the Kindleman set available? Do some of the new stylesheets already improve this?

As this point was a bit lost in the discussion if to break the API,
which of the MPL's colormaps would be considered as the best
alternative these days?

Probably gray_r or gray

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

👍 on gray.

The style module does take care of this in principle via the image.cmap rcparam. mpl.style.use() can look up arbitrary paths, including URLs. A trick from @danielballan is to put a stlye-file in a gist: https://gist.github.com/danielballan/be066529de85e87a5fe7

Thanks Paul, I was wondering about the length of that URL...

Anyway, the tl;dr; of the video is that, yes, Lab space does measure color
distances better than XYZ, but Stefan and Nathanial didn't use XYZ. They
used newer model that had much lower errors for both nearby and far away
colors. They even show examples of parula having apparent gradients that
didn't really exist.

On Wed, Jul 15, 2015 at 3:13 PM, Paul Ivanov notifications@github.com
wrote:

(Ben, I took the liberty of updating your link to the direct youtube one -
google doesn't play nicely when you try to copy-link from search results)

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

@scottsievert: Is there text somewhere saying that XYZ space was used to calculate perceptual differences? If so it'd be good to know so we can correct it -- we used CAM02-UCS, which is a perceptually uniform space that improves on CIEL_a_b_. To get to either CAM02-UCS and CIEL_a_b_ space you have to pass through XYZ -- here's the transformation graph supported by colorspacious 0.1.0 --

but that's an implementation detail...

[Edit for clarify: CAM02-UCS is the J'a'b' node in the lower-right.]

Got it. In your talk mentioned above, you referred to the XYZ space more often and I assumed that's what you were using to calculate the perceptual differences. It's good to know otherwise and I'll trust you on this.

Ah, gotcha, right, that could definitely have been clearer. Something to
keep in mind if I end up giving the talk again :-)

On Wed, Jul 15, 2015 at 2:44 PM, Scott S. notifications@github.com wrote:

Got it. In your talk https://www.youtube.com/watch?v=xAoljeRJ3lU
mentioned above, you referred to the XYZ space more often and I assumed
that's what you were using to calculate the perceptual differences. It's
good to know otherwise and I'll trust you on this.

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

Nathaniel J. Smith -- http://vorpus.org

See also #4707

Is there something like the Kindleman set available? Do some of the new stylesheets already improve this?

@michaelaye I only noticed this comment of yours today.

I have a version of Kindleman linear lightness colormap in the second half of this notebook tutorial.

Using the same data and function in the notebook I also replicated his circular colormap. it's been sitting on my home computer for a while, I just uploaded it on GitHub here.

🌟 👯 🌟