Replace "jet" as the default colormap #875

Closed
endolith opened this Issue May 17, 2012 · 68 comments

Comments

Projects
None yet
@endolith
Contributor

endolith commented May 17, 2012

This is subjective: a matter of sane defaults vs consistency with matlab, but here are the arguments against jet as default:

Rainbow Color Map (Still) Considered Harmful:

Research has shown that the rainbow color map is rarely the optimal choice when displaying data with a pseudocolor map. The rainbow color map confuses viewers through its lack of perceptual ordering, obscures data through its uncontrolled luminance variation, and actively misleads interpretation through the introduction of non-data-dependent gradients.

Despite much published research on its deficiencies the rainbow color map is prevalent in the visualization community. We present survey results showing that the rainbow color map continues to appear in more than half of the relevant papers in IEEE Visualization Conference proceedings; for example, it appeared on 61 pages in 2005. Its use is encouraged by its selection as the default color map used in most visualization toolkits that we inspected. The visualization community must do better.
...
In the absence of feedback about the data or task, the best approach for situations where color is the only display technique is probably the black-body radiation spectrum, because of its perceptual ordering and use of color to avoid contrast effects.

So this would presumably mean using one of hot, afmhot, or gist_heat as the default colormap:

hot, afmhot, and gist_heat

How NOT to Lie with Visualization:

This rainbow hue colormap is widely used in visualization, but produces several well-documented artifacts (e.g., Lefkowitz and Herman [1992]; Robertson [1988]; Rogowitz, Ling and Kellogg [1992]). In this MRI image, for example, the colormap creates perceived contours which do not reflect discrete transitions in the data, structures in the data which fall within one of these artificial bands are not represented, and attention is drawn to the yellow areas because they are the brightest, not because they are in any way the most important.

Let’s talk colormaps:

What kind of insane colormap has the property that values spanning the extreme ends of the scale stand out less, and can’t be distinguished as easily as values in the noisy middle? Why, it’s MATLAB’s default colormap, of course!

The 'jet' colormap must die!:

The main issue here is that in grayscale representation, information about the 'height' of map regions gets lost. The center of the plot (where the highest intensity is found) has the same gray value as the border regions.

@cgohlke

This comment has been minimized.

Show comment Hide comment
@cgohlke

cgohlke May 17, 2012

Contributor

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.

Contributor

cgohlke commented May 17, 2012

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.

@endolith

This comment has been minimized.

Show comment Hide comment
@endolith

endolith May 17, 2012

Contributor

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

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

jet bump
hot bump

Contributor

endolith commented May 17, 2012

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

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

jet bump
hot bump

@endolith

This comment has been minimized.

Show comment Hide comment
@endolith

endolith May 17, 2012

Contributor

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.

Contributor

endolith commented May 17, 2012

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.

@ivanov

This comment has been minimized.

Show comment Hide comment
@ivanov

ivanov May 17, 2012

Member

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.

Member

ivanov commented May 17, 2012

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.

@efiring

This comment has been minimized.

Show comment Hide comment
@efiring

efiring May 27, 2012

Member

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.

Member

efiring commented May 27, 2012

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.

@WeatherGod

This comment has been minimized.

Show comment Hide comment
@WeatherGod

WeatherGod May 27, 2012

Member

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

Member

WeatherGod commented May 27, 2012

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

@endolith

This comment has been minimized.

Show comment Hide comment
@endolith

endolith May 31, 2012

Contributor

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?

off-center
centered

Contributor

endolith commented May 31, 2012

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?

off-center
centered

@efiring

This comment has been minimized.

Show comment Hide comment
@efiring

efiring May 31, 2012

Member

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.

Member

efiring commented May 31, 2012

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.

@endolith

This comment has been minimized.

Show comment Hide comment
@endolith

endolith Jun 4, 2012

Contributor

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.

Contributor

endolith commented Jun 4, 2012

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.

@endolith

This comment has been minimized.

Show comment Hide comment
@endolith

endolith Jun 4, 2012

Contributor

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)

Contributor

endolith commented Jun 4, 2012

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)

@efiring

This comment has been minimized.

Show comment Hide comment
@efiring

efiring Jun 4, 2012

Member

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.

Member

efiring commented Jun 4, 2012

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.

@endolith

This comment has been minimized.

Show comment Hide comment
@endolith

endolith Jun 5, 2012

Contributor

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

Contributor

endolith commented Jun 5, 2012

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

@efiring

This comment has been minimized.

Show comment Hide comment
@efiring

efiring Jun 5, 2012

Member

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.

Member

efiring commented Jun 5, 2012

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.

@WeatherGod

This comment has been minimized.

Show comment Hide comment
@WeatherGod

WeatherGod Jun 6, 2012

Member

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?

Member

WeatherGod commented Jun 6, 2012

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?

@efiring

This comment has been minimized.

Show comment Hide comment
@efiring

efiring Jun 6, 2012

Member

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.

Member

efiring commented Jun 6, 2012

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.

@pelson

This comment has been minimized.

Show comment Hide comment
@pelson

pelson Jun 13, 2012

Member

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.

Member

pelson commented Jun 13, 2012

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.

@endolith

This comment has been minimized.

Show comment Hide comment
@endolith

endolith Jun 18, 2012

Contributor

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

Contributor

endolith commented Jun 18, 2012

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

@efiring

This comment has been minimized.

Show comment Hide comment
@efiring

efiring Aug 13, 2012

Member

Closed after #921 merge

Member

efiring commented Aug 13, 2012

Closed after #921 merge

@efiring efiring closed this Aug 13, 2012

@endolith

This comment has been minimized.

Show comment Hide comment
@endolith

endolith Aug 13, 2012

Contributor

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

Contributor

endolith commented Aug 13, 2012

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

@tacaswell

This comment has been minimized.

Show comment Hide comment
@tacaswell

tacaswell Mar 10, 2013

Member

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

Member

tacaswell commented Mar 10, 2013

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

@franktoffel

This comment has been minimized.

Show comment Hide comment
@franktoffel

franktoffel Oct 12, 2014

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

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

@endolith

This comment has been minimized.

Show comment Hide comment
@endolith

endolith Oct 13, 2014

Contributor

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.

colormap_parula

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

Contributor

endolith commented Oct 13, 2014

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.

colormap_parula

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

@tacaswell

This comment has been minimized.

Show comment Hide comment
@tacaswell

tacaswell Oct 13, 2014

Member

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

Member

tacaswell commented Oct 13, 2014

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

@michaelaye

This comment has been minimized.

Show comment Hide comment
@michaelaye

michaelaye Oct 14, 2014

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 to jet these days? Is there something like the Kindleman set available? Do some of the new stylesheets already improve this?

@NelleV

This comment has been minimized.

Show comment Hide comment
@NelleV

NelleV Oct 14, 2014

Contributor

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

Contributor

NelleV commented Oct 14, 2014

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

@tacaswell

This comment has been minimized.

Show comment Hide comment
@tacaswell

tacaswell Oct 14, 2014

Member

👍 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

Member

tacaswell commented Oct 14, 2014

👍 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

@endolith

This comment has been minimized.

Show comment Hide comment
@endolith

endolith Oct 15, 2014

Contributor

could the default be different for different types of plots? bone for 2D heatmaps like imshow(), coolwarm or rainbow for 3D surfaces like plot_surface(), etc.?

Also see prettyplotlib, which tries to guess whether your data is diverging or sequential and chooses a colormap accordingly, either RdBu, Reds or Blues.

Contributor

endolith commented Oct 15, 2014

could the default be different for different types of plots? bone for 2D heatmaps like imshow(), coolwarm or rainbow for 3D surfaces like plot_surface(), etc.?

Also see prettyplotlib, which tries to guess whether your data is diverging or sequential and chooses a colormap accordingly, either RdBu, Reds or Blues.

@efiring

This comment has been minimized.

Show comment Hide comment
@efiring

efiring Oct 15, 2014

Member

@NelleV I very much doubt that a large proportion of mpl users would be happy to see a gray colormap as the default. Jet is not ideal, but I don't think that giving up on color entirely, or going to a single hue, is better.
@endolith I don't think it would be wise to put that level of complexity in the mpl core. PEP 20: "In the face of ambiguity, refuse the temptation to guess." No amount of logic and heuristics will be able to tell whether I am contouring velocity, for which a diverging red-blue color scale works well, or oxygen, for which a sequential scale might be more appropriate. Even if I am contouring temperature, for which a purist might say I should use a sequential map, I might legitimately choose a diverging map so as to have more visual range and resolution, and to give a clear sense of "warm" versus "cold".
If a new default is chosen, it should be chosen to be visually pleasing to a majority of people, and to be a tolerable compromise among all the competing criteria for a range of applications; it needs to work for new users and for quick interactive work. It looks like the Mathworks made a nice choice.

Member

efiring commented Oct 15, 2014

@NelleV I very much doubt that a large proportion of mpl users would be happy to see a gray colormap as the default. Jet is not ideal, but I don't think that giving up on color entirely, or going to a single hue, is better.
@endolith I don't think it would be wise to put that level of complexity in the mpl core. PEP 20: "In the face of ambiguity, refuse the temptation to guess." No amount of logic and heuristics will be able to tell whether I am contouring velocity, for which a diverging red-blue color scale works well, or oxygen, for which a sequential scale might be more appropriate. Even if I am contouring temperature, for which a purist might say I should use a sequential map, I might legitimately choose a diverging map so as to have more visual range and resolution, and to give a clear sense of "warm" versus "cold".
If a new default is chosen, it should be chosen to be visually pleasing to a majority of people, and to be a tolerable compromise among all the competing criteria for a range of applications; it needs to work for new users and for quick interactive work. It looks like the Mathworks made a nice choice.

@endolith

This comment has been minimized.

Show comment Hide comment
@endolith

endolith Oct 15, 2014

Contributor

@efiring by "complexity" do you mean the auto-guessing, or the different defaults for different functions?

Spectral_r is similar to jet, but without the bright bands. It's sort of diverging (symmetrical brightness) and sequential (color) at the same time.

7298887108_d8978791d0_o

Matlab's choice looks good too

Contributor

endolith commented Oct 15, 2014

@efiring by "complexity" do you mean the auto-guessing, or the different defaults for different functions?

Spectral_r is similar to jet, but without the bright bands. It's sort of diverging (symmetrical brightness) and sequential (color) at the same time.

7298887108_d8978791d0_o

Matlab's choice looks good too

@michaelaye

This comment has been minimized.

Show comment Hide comment
@michaelaye

michaelaye Oct 15, 2014

@efiring Please note, I believe @NelleV only answered to my question what's the most recommended colormap these days in general, independently of the question if or when to break the current standard. I tried to make that clear in the way I formulated the question, but maybe this would have been better on the mailing list or on another issue.

@efiring Please note, I believe @NelleV only answered to my question what's the most recommended colormap these days in general, independently of the question if or when to break the current standard. I tried to make that clear in the way I formulated the question, but maybe this would have been better on the mailing list or on another issue.

@michaelaye

This comment has been minimized.

Show comment Hide comment
@michaelaye

michaelaye Oct 15, 2014

@endolith I'm actually surprised that above's rainbow is relatively smooth compared to other rainbow cmaps I've seen in some articles, that over-emphasized green much more than here. Was it already designed with avoiding banding or non-iso-luminosity as good as possible?

@endolith I'm actually surprised that above's rainbow is relatively smooth compared to other rainbow cmaps I've seen in some articles, that over-emphasized green much more than here. Was it already designed with avoiding banding or non-iso-luminosity as good as possible?

@efiring

This comment has been minimized.

Show comment Hide comment
@efiring

efiring Oct 15, 2014

Member

On 2014/10/14, 5:28 PM, endolith wrote:

@efiring https://github.com/efiring by "complexity" do you mean the
auto-guessing, or the different defaults for different functions?

Both. The guessing idea is the worst, but I really don't see any sense
in different defaults for different functions, either--it's still a form
of guessing. Any given function involving a ScalarMappable can be used
in a wide variety of applications, with a corresponding variety of
suitable color maps.

Member

efiring commented Oct 15, 2014

On 2014/10/14, 5:28 PM, endolith wrote:

@efiring https://github.com/efiring by "complexity" do you mean the
auto-guessing, or the different defaults for different functions?

Both. The guessing idea is the worst, but I really don't see any sense
in different defaults for different functions, either--it's still a form
of guessing. Any given function involving a ScalarMappable can be used
in a wide variety of applications, with a corresponding variety of
suitable color maps.

@efiring

This comment has been minimized.

Show comment Hide comment
@efiring

efiring Oct 15, 2014

Member

Does anyone know how to figure out whether Matlab's perula is their IP? I suspect it is; it probably exists only in the form of their m-file (or compiled in the core or in a mexfile). It's a bit like our YlGnBu, but it has a yellower yellow end. Overall, it seems to take advantage of more hues.

Member

efiring commented Oct 15, 2014

Does anyone know how to figure out whether Matlab's perula is their IP? I suspect it is; it probably exists only in the form of their m-file (or compiled in the core or in a mexfile). It's a bit like our YlGnBu, but it has a yellower yellow end. Overall, it seems to take advantage of more hues.

@tacaswell

This comment has been minimized.

Show comment Hide comment
@tacaswell

tacaswell Oct 16, 2014

Member
@tacaswell

This comment has been minimized.

Show comment Hide comment
@tacaswell

tacaswell Oct 19, 2014

Member

@tacaswell tacaswell removed this from the next major release milestone Feb 17, 2015

@gregcaporaso gregcaporaso referenced this issue in biocore/scikit-bio Feb 26, 2015

Open

ENH: add Alignment.heatmap method #816

@ivanov

This comment has been minimized.

Show comment Hide comment
@ivanov

ivanov Jun 3, 2015

Member

Here's a recent discussion on the mailing lists about this, with a proposal

Member

ivanov commented Jun 3, 2015

Here's a recent discussion on the mailing lists about this, with a proposal

@WeatherGod

This comment has been minimized.

Show comment Hide comment
@WeatherGod

WeatherGod Jun 3, 2015

Member

Paul, this is fantastic! A nice, well-organized page showing the three
proposed colormaps and a common set of graphs for each. We should get this
out onto the user list.

On Wed, Jun 3, 2015 at 12:41 AM, Paul Ivanov notifications@github.com
wrote:

Here's a recent discussion on the mailing lists
http://matplotlib.1069221.n5.nabble.com/RFC-candidates-for-a-new-default-colormap-td45652.html
about this, with a proposal http://bids.github.io/colormap/


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

Member

WeatherGod commented Jun 3, 2015

Paul, this is fantastic! A nice, well-organized page showing the three
proposed colormaps and a common set of graphs for each. We should get this
out onto the user list.

On Wed, Jun 3, 2015 at 12:41 AM, Paul Ivanov notifications@github.com
wrote:

Here's a recent discussion on the mailing lists
http://matplotlib.1069221.n5.nabble.com/RFC-candidates-for-a-new-default-colormap-td45652.html
about this, with a proposal http://bids.github.io/colormap/


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

@tacaswell

This comment has been minimized.

Show comment Hide comment
@tacaswell

tacaswell Jun 3, 2015

Member

@njsmith Can that page get integrated with/replace https://github.com/matplotlib/matplotlib/blob/color_overhaul/doc/devel/color_changes.rst so we have a record in the docs?

Member

tacaswell commented Jun 3, 2015

@njsmith Can that page get integrated with/replace https://github.com/matplotlib/matplotlib/blob/color_overhaul/doc/devel/color_changes.rst so we have a record in the docs?

@wernight

This comment has been minimized.

Show comment Hide comment
@wernight

wernight Jul 15, 2015

Would be nice to add also some of the alternatives on http://bids.github.io/colormap/ to matplotlib.

Would be nice to add also some of the alternatives on http://bids.github.io/colormap/ to matplotlib.

@njsmith

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Jul 15, 2015

Yep, that's the plan.

On Wed, Jul 15, 2015 at 3:22 AM, Werner Beroux notifications@github.com
wrote:

Would be nice to add also some of the alternatives on
http://bids.github.io/colormap/ to matplotlib.


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

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

njsmith commented Jul 15, 2015

Yep, that's the plan.

On Wed, Jul 15, 2015 at 3:22 AM, Werner Beroux notifications@github.com
wrote:

Would be nice to add also some of the alternatives on
http://bids.github.io/colormap/ to matplotlib.


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

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

@tacaswell

This comment has been minimized.

Show comment Hide comment
@tacaswell

tacaswell Jul 15, 2015

Member

There is a discussion over names happening in a scikit-image PR thread (
scikit-image/scikit-image#1599)

There is a proposal for naming options A-C as {'ignis', 'ortus', 'fyrian'}
in some order.

Commenting here and copying the devel list so it gets some visibility.

On Wed, Jul 15, 2015 at 11:56 AM Nathaniel J. Smith <
notifications@github.com> wrote:

Yep, that's the plan.

On Wed, Jul 15, 2015 at 3:22 AM, Werner Beroux notifications@github.com
wrote:

Would be nice to add also some of the alternatives on
http://bids.github.io/colormap/ to matplotlib.


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

.

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


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

Member

tacaswell commented Jul 15, 2015

There is a discussion over names happening in a scikit-image PR thread (
scikit-image/scikit-image#1599)

There is a proposal for naming options A-C as {'ignis', 'ortus', 'fyrian'}
in some order.

Commenting here and copying the devel list so it gets some visibility.

On Wed, Jul 15, 2015 at 11:56 AM Nathaniel J. Smith <
notifications@github.com> wrote:

Yep, that's the plan.

On Wed, Jul 15, 2015 at 3:22 AM, Werner Beroux notifications@github.com
wrote:

Would be nice to add also some of the alternatives on
http://bids.github.io/colormap/ to matplotlib.


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

.

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


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

@stsievert

This comment has been minimized.

Show comment Hide comment
@stsievert

stsievert Jul 15, 2015

In the proposal, what's the motivation for using XYZ colorspace instead of the Lab colorspace (like Matlab) when calculating perceptual differences?

This question is motivated by Matlab's review of rainbow colorspaces. This includes

Color Map Construction Principles

Use these guidelines for building effective color maps:

  • Construct a perceptual color map by using smooth, equal-step interpolation in a perceptually uniform color space such as Lab*.
  • Use monotonic lightness (L*) to achieve perceptual ordering and assist color-impaired viewers.
  • Do not use lightness variation alone because of the problem of simultaneous contrast. Use hue or saturation variation in addition to lightness variation. (Hue variation can also improve the attractiveness of a color map.)

That perceptually uniform stuck out at me and I looked into it. From the Lab wikipedia page, the definition of perceptually uniform is

Perceptually uniform means that a change of the same amount in a color value should produce a change of about the same visual importance.

We want the default colormap in mpl to be perceptually uniform, correct? According to the same wiki page,

XYZ color space ... is not particularly perceptually uniform. [3]
...
the intention of both "Lab" color spaces is to create a space that can be computed via simple formulas from the XYZ space but is more perceptually uniform than XYZ. [4]

If mpl cares about perceptual uniformity, it sounds like it should us the Lab color space to calculate perceptual differences.

In the proposal, what's the motivation for using XYZ colorspace instead of the Lab colorspace (like Matlab) when calculating perceptual differences?

This question is motivated by Matlab's review of rainbow colorspaces. This includes

Color Map Construction Principles

Use these guidelines for building effective color maps:

  • Construct a perceptual color map by using smooth, equal-step interpolation in a perceptually uniform color space such as Lab*.
  • Use monotonic lightness (L*) to achieve perceptual ordering and assist color-impaired viewers.
  • Do not use lightness variation alone because of the problem of simultaneous contrast. Use hue or saturation variation in addition to lightness variation. (Hue variation can also improve the attractiveness of a color map.)

That perceptually uniform stuck out at me and I looked into it. From the Lab wikipedia page, the definition of perceptually uniform is

Perceptually uniform means that a change of the same amount in a color value should produce a change of about the same visual importance.

We want the default colormap in mpl to be perceptually uniform, correct? According to the same wiki page,

XYZ color space ... is not particularly perceptually uniform. [3]
...
the intention of both "Lab" color spaces is to create a space that can be computed via simple formulas from the XYZ space but is more perceptually uniform than XYZ. [4]

If mpl cares about perceptual uniformity, it sounds like it should us the Lab color space to calculate perceptual differences.

@WeatherGod

This comment has been minimized.

Show comment Hide comment
@WeatherGod

WeatherGod Jul 15, 2015

Member

Scott,

I would suggest watching this presentation which explains the limitations
of Lab space and exactly how the viridis colormap was constructed. It
certainly changed my mind about Lab:
https://www.youtube.com/watch?v=xAoljeRJ3lU

Ben Root

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

In the proposal http://bids.github.io/colormap/, what's the motivation
for using XYZ colorspace instead of the Lab colorspace (like Matlab) when
calculating perceptual differences?

This question is motivated by Matlab's review of rainbow colorspaces
http://www.mathworks.com/tagteam/81137_92238v00_RainbowColorMap_57312.pdf.
This includes

Color Map Construction Principles

Use these guidelines for building effective color maps:

  • Construct a perceptual color map by using smooth, equal-step
    interpolation in a perceptually uniform color space such as L_a_b*.

  • Use monotonic lightness (L*) to achieve perceptual ordering and
    assist color-impaired viewers.

  • Do not use lightness variation alone because of the problem of
    simultaneous contrast. Use hue or saturation variation in addition to
    lightness variation. (Hue variation can also improve the attractiveness of
    a color map.)

    That perceptually uniform stuck out at me and I looked into it. From the Lab
    wikipedia page https://en.wikipedia.org/wiki/Lab_color_space, the
    definition of perceptually uniform is

Perceptually uniform means that a change of the same amount in a color
value should produce a change of about the same visual importance.

We want the default colormap in mpl to be perceptually uniform, correct?
According to the same wiki page,

XYZ color space ... is not particularly perceptually uniform. [3
http://www.brucelindbloom.com/UPLab.html]
...
the intention of both "Lab" color spaces is to create a space that can be
computed via simple formulas from the XYZ space but is more perceptually
uniform than XYZ. [4 http://www.handprint.com/HP/WCL/color7.html#CIELUV]

If mpl cares about perceptual uniformity, it sounds like it should us the
Lab color space to calculate perceptual differences.


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

Member

WeatherGod commented Jul 15, 2015

Scott,

I would suggest watching this presentation which explains the limitations
of Lab space and exactly how the viridis colormap was constructed. It
certainly changed my mind about Lab:
https://www.youtube.com/watch?v=xAoljeRJ3lU

Ben Root

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

In the proposal http://bids.github.io/colormap/, what's the motivation
for using XYZ colorspace instead of the Lab colorspace (like Matlab) when
calculating perceptual differences?

This question is motivated by Matlab's review of rainbow colorspaces
http://www.mathworks.com/tagteam/81137_92238v00_RainbowColorMap_57312.pdf.
This includes

Color Map Construction Principles

Use these guidelines for building effective color maps:

  • Construct a perceptual color map by using smooth, equal-step
    interpolation in a perceptually uniform color space such as L_a_b*.

  • Use monotonic lightness (L*) to achieve perceptual ordering and
    assist color-impaired viewers.

  • Do not use lightness variation alone because of the problem of
    simultaneous contrast. Use hue or saturation variation in addition to
    lightness variation. (Hue variation can also improve the attractiveness of
    a color map.)

    That perceptually uniform stuck out at me and I looked into it. From the Lab
    wikipedia page https://en.wikipedia.org/wiki/Lab_color_space, the
    definition of perceptually uniform is

Perceptually uniform means that a change of the same amount in a color
value should produce a change of about the same visual importance.

We want the default colormap in mpl to be perceptually uniform, correct?
According to the same wiki page,

XYZ color space ... is not particularly perceptually uniform. [3
http://www.brucelindbloom.com/UPLab.html]
...
the intention of both "Lab" color spaces is to create a space that can be
computed via simple formulas from the XYZ space but is more perceptually
uniform than XYZ. [4 http://www.handprint.com/HP/WCL/color7.html#CIELUV]

If mpl cares about perceptual uniformity, it sounds like it should us the
Lab color space to calculate perceptual differences.


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

@ivanov

This comment has been minimized.

Show comment Hide comment
@ivanov

ivanov Jul 15, 2015

Member

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

Member

ivanov commented Jul 15, 2015

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

@WeatherGod

This comment has been minimized.

Show comment Hide comment
@WeatherGod

WeatherGod Jul 15, 2015

Member

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

Member

WeatherGod commented Jul 15, 2015

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

@njsmith

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Jul 15, 2015

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

colorspacious

but that's an implementation detail...

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

njsmith commented Jul 15, 2015

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

colorspacious

but that's an implementation detail...

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

@stsievert

This comment has been minimized.

Show comment Hide comment
@stsievert

stsievert Jul 15, 2015

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.

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.

@njsmith

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Jul 15, 2015

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

njsmith commented Jul 15, 2015

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

@jhamman jhamman referenced this issue in pydata/xarray Jul 18, 2015

Merged

Feature plotting #466

@stefanv

This comment has been minimized.

Show comment Hide comment
@stefanv

stefanv Jul 30, 2015

Contributor

See also #4707

Contributor

stefanv commented Jul 30, 2015

See also #4707

@mdboom mdboom modified the milestones: Color overhaul, next major release (2.0) Oct 8, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Nov 16, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Nov 17, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Nov 23, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Nov 23, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Nov 25, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Nov 27, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Nov 27, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Dec 14, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Dec 14, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Dec 14, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Dec 17, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Dec 31, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Dec 31, 2015

mdboom added a commit to mdboom/matplotlib that referenced this issue Jan 4, 2016

@mycarta

This comment has been minimized.

Show comment Hide comment
@mycarta

mycarta Jan 29, 2016

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.

mycarta commented Jan 29, 2016

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.

@tacaswell tacaswell closed this in 28c632f Feb 8, 2016

@njsmith

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Feb 9, 2016

🌟 👯 🌟

njsmith commented Feb 9, 2016

🌟 👯 🌟

@tbreloff tbreloff referenced this issue in JuliaPlots/Plots.jl Oct 20, 2016

Closed

Missing colorschemes in heatmap plot #542

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment