release strategy and the color revolution

Development matplotlib-devel
1

For a long time there has been discussion of replacing the matplotlib default color map and color cycle, but we still haven't done it. We need a clear set of criteria, and a small set of good alternatives, leading to a decision, a PR, and a release. Now is the time.

Here is what I think is the most recent extensive thread:
http://comments.gmane.org/gmane.comp.python.matplotlib.devel/13122

Early in that thread Nathaniel Smith proposed the following criteria:

- sequential, not diverging
- perceptually uniform
- still perceptually uniform when converted to greyscale
- variation in hue is good
- colorblind-friendly
- hue ramp should work even without the luminance variation

I added:
- aesthetically pleasing

Probably not all of these can be met perfectly at once, but they seem like good goals. The one most likely to be controversial is the first. I propose that we not bother arguing about it, but just accept Nathaniel's recommendation.

For actual proposals:

1) A greyscale has been proposed; it satisfies several of the criteria very well, but misses by omitting hue entirely. It is proposed as a way to force users to choose something other than the default; I don't think this is a good *competitive* strategy.

2) YlGnBu or YlGnBu_r seems to me to be a viable candidate. It has the great advantage that we already have it. It seems to rate well by most of the criteria illustrated via Nathaniel's https://github.com/njsmith/pycam02ucs viscm() tool. (Perceptual distance is a little jumpy.)

Others?

Proposals for the new color cycle for line plots?

Proposed release strategy:
We will close the 1.4.x line with 1.4.3, in the process of being released now.
The next step is the color change release, 2.0, based on 1.4.3, but with any additional bug fixes and other reasonably non-risky changes that are ready to go.
Any substantial new features will then go in a subsequent point release.

Eric

2

Here is a proposal: we simply adopt seaborn's cycle.

Eric

···

On 2015/02/16 12:01 PM, Eric Firing wrote:

Proposals for the new color cycle for line plots?

3

Here is what I think is the most recent extensive thread:
http://comments.gmane.org/gmane.comp.python.matplotlib.devel/13122

...

1) A greyscale has been proposed; it satisfies several of the criteria
very well, but misses by omitting hue entirely. It is proposed as a way
to force users to choose something other than the default; I don't think
this is a good *competitive* strategy.

2) YlGnBu or YlGnBu_r seems to me to be a viable candidate. It has the
great advantage that we already have it. It seems to rate well by most
of the criteria illustrated via Nathaniel's
GitHub - njsmith/pycam02ucs: (Don't use this - use njsmith/colorspacious or matplotlib/viscm or both) viscm() tool. (Perceptual distance
is a little jumpy.)

Others?

Nathaniel's January 9 message in that thread (can't figure out how to link
to it in the archives) had a suggestion that I thought was very promising,
to do something similar to Parula but rotate around the hue circle the
other direction so that the hues would go blue - purple - red - yellow. I
don't think we've seen an example of exactly what it would look like, but I
reckon it would be similar to the middle colormap here

(from the elegant figures block series linked above), which I've always
found quite attractive.

···

On Mon, Feb 16, 2015 at 2:01 PM, Eric Firing <efiring@...229...> wrote:

4

Certainly it can be considered--but we have to have a real implementation.

···

On 2015/02/16 1:29 PM, Michael Waskom wrote:

Nathaniel's January 9 message in that thread (can't figure out how to
link to it in the archives) had a suggestion that I thought was very
promising, to do something similar to Parula but rotate around the hue
circle the other direction so that the hues would go blue - purple - red
- yellow. I don't think we've seen an example of exactly what it would
look like, but I reckon it would be similar to the middle colormap here
http://earthobservatory.nasa.gov/blogs/elegantfigures/files/2013/08/three_perceptual_palettes_618.png
(from the elegant figures block series linked above), which I've always
found quite attractive.

5

See here for a quick and dirty implementation that should get a general idea. This probably ins’t the best way to do it – anyone should feel free to build on this.

···

On Mon, Feb 16, 2015 at 3:38 PM, Eric Firing <efiring@…552…229…> wrote:

Nathaniel’s January 9 message in that thread (can’t figure out how to

link to it in the archives) had a suggestion that I thought was very

promising, to do something similar to Parula but rotate around the hue

circle the other direction so that the hues would go blue - purple - red

  • yellow. I don’t think we’ve seen an example of exactly what it would

look like, but I reckon it would be similar to the middle colormap here

http://earthobservatory.nasa.gov/blogs/elegantfigures/files/2013/08/three_perceptual_palettes_618.png

(from the elegant figures block series linked above), which I’ve always

found quite attractive.
On 2015/02/16 1:29 PM, Michael Waskom wrote:

Certainly it can be considered–but we have to have a real implementation.

6

Do remember that I have a PR to add linestyle cycling, which would greatly mitigate problems for colorblindness and non-color publications.

I also prefer it for slideshows as projectors at conferences tend to have crappy colors anyway (was at a radar conference when the projector’s red crapped out while the presenter was building up suspense about the really, really impressive radar image of a supercell on the next slide)

Ben Root

···

On Mon, Feb 16, 2015 at 3:38 PM, Eric Firing <efiring@…552…229…> wrote:

Nathaniel’s January 9 message in that thread (can’t figure out how to

link to it in the archives) had a suggestion that I thought was very

promising, to do something similar to Parula but rotate around the hue

circle the other direction so that the hues would go blue - purple - red

  • yellow. I don’t think we’ve seen an example of exactly what it would

look like, but I reckon it would be similar to the middle colormap here

http://earthobservatory.nasa.gov/blogs/elegantfigures/files/2013/08/three_perceptual_palettes_618.png

(from the elegant figures block series linked above), which I’ve always

found quite attractive.
On 2015/02/16 1:29 PM, Michael Waskom wrote:

Certainly it can be considered–but we have to have a real implementation.

7

2015-02-17 1:23 GMT+01:00 Michael Waskom <mwaskom@…552…22…>:

viscm_screenshot.png
viscm_screenshot.png1280×752 135 KB

···

See here for a quick and dirty implementation that should get a general idea. This probably ins’t the best way to do it – anyone should feel free to build on this.

This is very neat! Great job. Incidentally, when I stumbled upon the earthobservatory blog a while ago this particular colormap also caught my eye as a potential candidate, so I’m glad you suggested it as a starting point for a new matplotlib default.

Out of curiosity, I applied Nathaniel’s “viscm” function (from the previous thread) to the colormap from your notebook (screenshot attached). Interestingly, while it confirms that the lightness and hue angle increase more or less linearly, the “colourfulness” goes up and down in waves, even though you designed the chroma to increase linearly, too. I’m not sure whether this is because “colourfulness” and “chroma” are actually two different concepts, or whether it has to do with inaccuracies and/or clamping during the conversion between various colour spaces. It could also be the case that the colormath and pycam02ucs modules use different conversion formulas (in which case it would be good to know which is “more accurate”; not sure there is even an objective measure for “accuracy” in this case). Also, there seems to be something strange going on at the dark (blue) end of the colormap, but this could again be due to clamping.

I’d love to play a bit more with your example notebook but not sure I’ll be able to do so before the weekend (or early next week).

Cheers,

Max

8

The problem I have with hcl is that while it is technically “colorful” (or whatever the term may be), only the reds really come out because the other colors are only used when either really light or really dark. Perhaps squashing the brightness range a bit and let the natural lightness of yellow and the natural darkness of blue come through on their own. (does that even make any sense to anybody else? it makes sense in my head, but I am certainly am not an expert in color perception)

Ben Root

P.S. - Of course, my own color perception weirdness might be at play here and the colormap looks perfectly fine to everybody else…

···

On Wed, Feb 18, 2015 at 11:17 AM, Maximilian Albert <maximilian.albert@…149…> wrote:

2015-02-17 1:23 GMT+01:00 Michael Waskom <mwaskom@…22…>:

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server

from Actuate! Instantly Supercharge Your Business Reports and Dashboards

with Interactivity, Sharing, Native Excel Exports, App Integration & more

Get technology previously reserved for billion-dollar corporations, FREE

http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

See here for a quick and dirty implementation that should get a general idea. This probably ins’t the best way to do it – anyone should feel free to build on this.

This is very neat! Great job. Incidentally, when I stumbled upon the earthobservatory blog a while ago this particular colormap also caught my eye as a potential candidate, so I’m glad you suggested it as a starting point for a new matplotlib default.

Out of curiosity, I applied Nathaniel’s “viscm” function (from the previous thread) to the colormap from your notebook (screenshot attached). Interestingly, while it confirms that the lightness and hue angle increase more or less linearly, the “colourfulness” goes up and down in waves, even though you designed the chroma to increase linearly, too. I’m not sure whether this is because “colourfulness” and “chroma” are actually two different concepts, or whether it has to do with inaccuracies and/or clamping during the conversion between various colour spaces. It could also be the case that the colormath and pycam02ucs modules use different conversion formulas (in which case it would be good to know which is “more accurate”; not sure there is even an objective measure for “accuracy” in this case). Also, there seems to be something strange going on at the dark (blue) end of the colormap, but this could again be due to clamping.

I’d love to play a bit more with your example notebook but not sure I’ll be able to do so before the weekend (or early next week).

Cheers,

Max

9

My own reaction to it is that it seems like a nicely *functional* colormap, one I would want to have available and probably would sometimes use, but it is not particularly aesthetically *pleasing*. I think this is consistent with Olga's earlier post as well.

Eric

···

On 2015/02/18 6:31 AM, Benjamin Root wrote:

The problem I have with hcl is that while it is technically "colorful"
(or whatever the term may be), only the reds really come out because the
other colors are only used when either really light or really dark.
Perhaps squashing the brightness range a bit and let the natural
lightness of yellow and the natural darkness of blue come through on
their own. (does that even make any sense to anybody else? it makes
sense in my head, but I am certainly am not an expert in color perception)

Ben Root

P.S. - Of course, my own color perception weirdness might be at play
here and the colormap looks perfectly fine to everybody else...

10

Cool! I knew there had been some useful tools posted on the earlier thread
but didn't have time to dig them out.

Interesting observation about the colorfulness. I don't know enough about
all the transformations involved to full account for that, but I added some
stuff to the notebook to figure out how much of that might be caused by
straying out of gamut. It looks like the map I created does a pretty good
job and is only getting clamped at the very low end and near the high end,
so I don't think it's a complete explanation for the undulating
"colorfulness":
http://nbviewer.ipython.org/gist/mwaskom/6a43a3b94eca4a9e2e8b

By means of disclosure, I did this before having coffee, so it might be
wrong...

11

I've made a second notebook that uses the IPython interactive machinery to
let anyone play with the parameters and explore different ways of setting
them. you can download the notebook with that here:
http://nbviewer.ipython.org/gist/mwaskom/842d1497b6892d081bfb (I made it
using IPython 3.0rc1; I'm not certain if it will work on the 2.x series;
sorry if that is the case).

This stays with the general approach in the original notebook of using a
linear ramp for chroma, which again maybe is not what we want. But it
should let you get a better sense for the parameter space.

As I said in the email to Olga, I think (a) I would advocate fairly
strongly that matplotlib should design a custom colormap as its default,
and (b) I think this approach (a cubehelix-like map in Hcl space) is a
principled way of doing so (though maybe not optimal). But both of those
points are independent of whether you end up going with the particular
parameters that I used to generate the original proposal -- I have my own
domain on which to impose my personal aesthetic preferences, and I don't
need to take over matplotlib too :slight_smile:

(But I do think it's worth distinguishing the matplotlib default from the
matlab default.)

Michael

12

While I hate to promise vaporware, I actually was planning to have a
go at implementing such a colormap in the next few weeks, based on
optimizing the same set of parameters that viscm visualizes... FWIW.

Are we planning to make other default appearance changes at the same
time? The idea of changing the color cycle and/or dot-dash cycle has
already come up in this thread, and this earlier thread proposed
several more good ideas [1]:
  http://thread.gmane.org/gmane.comp.python.matplotlib.devel/13128/focus=13166

I agree that now is definitely the time to get serious about making
these changes, but it seems like there's enough to be worked out that
sticking to the original plan and keeping mainline quasi-frozen until
2.0 is ready might create frustration and hasty decisions. Maybe it
would be less stressful all around if we let mainline development
proceed at whatever pace makes sense while these things get sorted
out, and then once the appearance changes are ready make the call
about whether to cut a quick 1.5 first or not? Presumably these
defaults will stick around for many years so it's worth taking a few
months to get a complete proposal together, get feedback, etc., IMO.

In an ideal world version 1.last might even provide a
style.use("matplotlib2") command to preview what 2.0 will do, just
like 2.0 will presumably have a style.use("matplotlib1") command for
those who want to (temporarily) revert.

-n

[1] well I would think that wouldn't I :wink:

···

On Feb 16, 2015 3:39 PM, "Eric Firing" <efiring@...229...> wrote:

On 2015/02/16 1:29 PM, Michael Waskom wrote:

> Nathaniel's January 9 message in that thread (can't figure out how to
> link to it in the archives) had a suggestion that I thought was very
> promising, to do something similar to Parula but rotate around the hue
> circle the other direction so that the hues would go blue - purple - red
> - yellow. I don't think we've seen an example of exactly what it would
> look like, but I reckon it would be similar to the middle colormap here
> http://earthobservatory.nasa.gov/blogs/elegantfigures/files/2013/08/three_perceptual_palettes_618.png
> (from the elegant figures block series linked above), which I've always
> found quite attractive.

Certainly it can be considered--but we have to have a real implementation.

13

Nathaniel's January 9 message in that thread (can't figure out how to
link to it in the archives) had a suggestion that I thought was very
promising, to do something similar to Parula but rotate around the hue
circle the other direction so that the hues would go blue - purple - red
- yellow. I don't think we've seen an example of exactly what it would
look like, but I reckon it would be similar to the middle colormap here
http://earthobservatory.nasa.gov/blogs/elegantfigures/files/2013/08/three_perceptual_palettes_618.png
(from the elegant figures block series linked above), which I've always
found quite attractive.

Certainly it can be considered--but we have to have a real implementation.

While I hate to promise vaporware, I actually was planning to have a
go at implementing such a colormap in the next few weeks, based on
optimizing the same set of parameters that viscm visualizes... FWIW.

Do you think there is a way to make a sequential map that is more pleasing to those of us who are more comfortable with blues and greens than with the slightly muddy purples and browns in the initial attempt at HCL?

Are we planning to make other default appearance changes at the same
time? The idea of changing the color cycle and/or dot-dash cycle has
already come up in this thread, and this earlier thread proposed
several more good ideas [1]:
   http://thread.gmane.org/gmane.comp.python.matplotlib.devel/13128/focus=13166

My thought was to just change the color cycle, but other style aspects are by no means out of the question. Thank you for pointing out that thread.

I agree that now is definitely the time to get serious about making
these changes, but it seems like there's enough to be worked out that
sticking to the original plan and keeping mainline quasi-frozen until
2.0 is ready might create frustration and hasty decisions. Maybe it
would be less stressful all around if we let mainline development
proceed at whatever pace makes sense while these things get sorted
out, and then once the appearance changes are ready make the call
about whether to cut a quick 1.5 first or not? Presumably these
defaults will stick around for many years so it's worth taking a few
months to get a complete proposal together, get feedback, etc., IMO.

The problem is that we have years of experience of no change, no decisions, no convergence of opinion. More recently we have had general agreement that a change is in order, but we are sadly lacking in concrete proposals. I certainly don't want to see a bad decision made, but without considerable prodding, it seems most likely that this will drag on for years. We need to make a change that is good; "perfect" is unattainable.

In an ideal world version 1.last might even provide a
style.use("matplotlib2") command to preview what 2.0 will do, just
like 2.0 will presumably have a style.use("matplotlib1") command for
those who want to (temporarily) revert.

This is a good idea--but even for this, we need actual style files.

Eric

···

On 2015/02/18 2:39 PM, Nathaniel Smith wrote:

On Feb 16, 2015 3:39 PM, "Eric Firing" <efiring@...229...> wrote:

On 2015/02/16 1:29 PM, Michael Waskom wrote:

-n

[1] well I would think that wouldn't I :wink:

14

Just to be clear, Hcl is just a color space; you could in principle make
any number of colormaps using it. My particular proposal is to do something
cubehelix-like in Hcl space while aiming for around .5-.75 of a rotation
around the color wheel. What motivated the particular parameters in the
original proposal was two things:

a) Starting with blue and ending with yellow makes sense, because you can
get good saturation out of dark blues and light yellows
b) Once you have those endpoints, you can either go through green (this is
what matlab does with parula) or through purple and red. the latter has the
functional advantage of getting a bit more hue variation, and it also
distinguishes the colormap from parula. I think this was the argument
Nathaniel originally made.

Tastes differ, but I find the blue-purple-red-yellow colormap quite
attractive, (perhaps because it reminds me of the sunset. Actually, as an
aside, your speculation that your aesthetic preferences are driven by
positive associations by things that have those colors has some support in
the psych literature: http://www.pnas.org/content/107/19/8877.full)

Anyway, within the constraints of the "increase lightness and chroma
linearly while circling around the hue wheel", it's easy to create a
blue-green-yellow colormap:

​

And also more generally, once you have a way of making a colormap from a
few parameters, and some objective function for what makes a colormap
"good", you can optimize in more principled ways than just playing around
with the knobs of a widget. I believe this is what Nathaniel was proposing,
and it sounds like a good idea.

I would suggest that you folks (i.e. the matplotlib core developers) figure
out earlier, rather than later, how the actual decision is going to be
made. I think you can get pretty far with principled arguments, but
ultimately there's going to be an aesthetic aspect and the decision will
easily devolve some people thinking option A is "ugly" and other people
thinking option B is "ugly". And that will be annoying for everyone
involved, but particularly for the people who put time into developing
candidates.

Screenshot 2015-02-18 17.25.40.png

···

On Wed, Feb 18, 2015 at 5:23 PM, Eric Firing <efiring@...229...> wrote:

Do you think there is a way to make a sequential map that is more pleasing
to those of us who are more comfortable with blues and greens than with the
slightly muddy purples and browns in the initial attempt at HCL?

15

Hi,

For a long time there has been discussion of replacing the matplotlib
default color map [...]

I've started building a small interactive Lab point editor to build a
sequential colormap.

The main interest of it is the ability to quickly check that the points
stay in the sRGB gamut.

There are some colormap results I just got this afternoon with it in the
companion notebook
(Jupyter Notebook Viewer)

It feels there are indeed only two routes: the Blue-Green-Yellow and the
Blue-Red-Yellow one. Maybe it is possible to squeeze in a more "snaky"
path, but it might look weird.

best,
Pierre

···

Le 16/02/2015 23:01, Eric Firing a écrit :

16

Interesting choices, and I think we are on the right paths (no pun intended) through the two possible colors. However, I think the same problem arises that I noted before. Both ends of the colormap are nearly black to nearly white. IIRC, our perception of luminosity has a much greater range than it does for chroma. While it is nice to take advantage of that, I wonder if we are going too far in the luminosity range? Perhaps these colormaps would be better if the luminosity range wasn’t as full as it is here?

Ben Root

···

On Mon, Feb 23, 2015 at 12:36 PM, Pierre Haessig <pierre.haessig@…804…> wrote:

Hi,

Le 16/02/2015 23:01, Eric Firing a écrit :

For a long time there has been discussion of replacing the matplotlib

default color map […]

I’ve started building a small interactive Lab point editor to build a

sequential colormap.

https://github.com/pierre-haessig/lab-colormap-creator

The main interest of it is the ability to quickly check that the points

stay in the sRGB gamut.

There are some colormap results I just got this afternoon with it in the

companion notebook

(http://nbviewer.ipython.org/github/pierre-haessig/lab-colormap-creator/blob/master/test_plots.ipynb)

It feels there are indeed only two routes: the Blue-Green-Yellow and the

Blue-Red-Yellow one. Maybe it is possible to squeeze in a more “snaky”

path, but it might look weird.

best,

Pierre

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server

from Actuate! Instantly Supercharge Your Business Reports and Dashboards

with Interactivity, Sharing, Native Excel Exports, App Integration & more

Get technology previously reserved for billion-dollar corporations, FREE

http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

17

Ben,

I was noticing the same thing, except that at least on my screen, the problem is mainly at the dark end, and it varies with the actual set of control points. The very last one, for example (Purple Red Yellow L5-95) has what looks like a fairly linear ramp from end to end on my screen, while "Blue Green Yellow L10-90" lacks contrast on the dark end. I suspect all this will be quite dependent on the particular screen (or printer--including the whole chain of color conversions ending up in ink or toner dots) being used. It doesn't look to me like a problem with the luminosity range as such. We have a highly nonlinear problem here.

In any case, this looks like a nice tool. Maybe it can be combined with Nathaniel's code, which shows other aspects of the colormap?

Eric

···

On 2015/02/23 8:16 AM, Benjamin Root wrote:

Interesting choices, and I think we are on the right paths (no pun
intended) through the two possible colors. However, I think the same
problem arises that I noted before. Both ends of the colormap are nearly
black to nearly white. IIRC, our perception of luminosity has a much
greater range than it does for chroma. While it is nice to take
advantage of that, I wonder if we are going too far in the luminosity
range? Perhaps these colormaps would be better if the luminosity range
wasn't as full as it is here?

Ben Root

18

My eyes are definitely favoring the L20-80 over the L5-95 colormaps. Does Luminosity take into account human’s non-linearity in perceiving brightness? I remember a few years ago many of the open-source graphics tools (such as GIMP) had to be fixed because it assumed a linear brightness perception. IIRC, humans are better at perceiving brightness gradients on one end of the range than on the other end.

···

On Mon, Feb 23, 2015 at 1:30 PM, Eric Firing <efiring@…229…> wrote:

On 2015/02/23 8:16 AM, Benjamin Root wrote:

Interesting choices, and I think we are on the right paths (no pun

intended) through the two possible colors. However, I think the same

problem arises that I noted before. Both ends of the colormap are nearly

black to nearly white. IIRC, our perception of luminosity has a much

greater range than it does for chroma. While it is nice to take

advantage of that, I wonder if we are going too far in the luminosity

range? Perhaps these colormaps would be better if the luminosity range

wasn’t as full as it is here?

Ben Root

Ben,

I was noticing the same thing, except that at least on my screen, the

problem is mainly at the dark end, and it varies with the actual set of

control points. The very last one, for example (Purple Red Yellow

L5-95) has what looks like a fairly linear ramp from end to end on my

screen, while “Blue Green Yellow L10-90” lacks contrast on the dark end.

I suspect all this will be quite dependent on the particular screen

(or printer–including the whole chain of color conversions ending up in

ink or toner dots) being used. It doesn’t look to me like a problem

with the luminosity range as such. We have a highly nonlinear problem here.

In any case, this looks like a nice tool. Maybe it can be combined with

Nathaniel’s code, which shows other aspects of the colormap?

Eric

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server

from Actuate! Instantly Supercharge Your Business Reports and Dashboards

with Interactivity, Sharing, Native Excel Exports, App Integration & more

Get technology previously reserved for billion-dollar corporations, FREE

http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

19

Nathaniel's January 9 message in that thread (can't figure out how to
link to it in the archives) had a suggestion that I thought was very
promising, to do something similar to Parula but rotate around the hue
circle the other direction so that the hues would go blue - purple - red
- yellow. I don't think we've seen an example of exactly what it would
look like, but I reckon it would be similar to the middle colormap here
http://earthobservatory.nasa.gov/blogs/elegantfigures/files/2013/08/three_perceptual_palettes_618.png
(from the elegant figures block series linked above), which I've always
found quite attractive.

Certainly it can be considered--but we have to have a real implementation.

While I hate to promise vaporware, I actually was planning to have a
go at implementing such a colormap in the next few weeks, based on
optimizing the same set of parameters that viscm visualizes... FWIW.

It might be worth quite a bit--and the sooner, the better.

Are we planning to make other default appearance changes at the same
time? The idea of changing the color cycle and/or dot-dash cycle has
already come up in this thread, and this earlier thread proposed
several more good ideas [1]:
   http://thread.gmane.org/gmane.comp.python.matplotlib.devel/13128/focus=13166

Thank you for the link. The ideas certainly deserve review at this point. There is some danger in that the more things we try to change, the harder it might be to approach consensus.

I agree that now is definitely the time to get serious about making
these changes, but it seems like there's enough to be worked out that
sticking to the original plan and keeping mainline quasi-frozen until
2.0 is ready might create frustration and hasty decisions. Maybe it
would be less stressful all around if we let mainline development
proceed at whatever pace makes sense while these things get sorted
out, and then once the appearance changes are ready make the call
about whether to cut a quick 1.5 first or not? Presumably these
defaults will stick around for many years so it's worth taking a few
months to get a complete proposal together, get feedback, etc., IMO.

Good point; this can work provided we can keep the momentum up, so that we actually converge on a feasible proposal.

In an ideal world version 1.last might even provide a
style.use("matplotlib2") command to preview what 2.0 will do, just
like 2.0 will presumably have a style.use("matplotlib1") command for
those who want to (temporarily) revert.

I like this style-based preview idea.

Eric

···

On 2015/02/18 2:39 PM, Nathaniel Smith wrote:

On Feb 16, 2015 3:39 PM, "Eric Firing" <efiring@...229...> wrote:

On 2015/02/16 1:29 PM, Michael Waskom wrote:

-n

[1] well I would think that wouldn't I :wink:

20

If the goal is still to put all the appearance-related changes in a single release (to simplify changes to downstream unit tests), but nobody has stepped up to make changes except to the colors, might it be possible to just adopt the default seaborn style (except for colors, of course)? If anybody is strongly motivated to make changes they can, but if nobody does there would still be a good, modern, pleasant-looking style used by default.

···

On Feb 19, 2015 1:39 AM, “Nathaniel Smith” <njs@…503…> wrote:

On Feb 16, 2015 3:39 PM, “Eric Firing” <efiring@…229…> wrote:

On 2015/02/16 1:29 PM, Michael Waskom wrote:

Nathaniel’s January 9 message in that thread (can’t figure out how to
link to it in the archives) had a suggestion that I thought was very
promising, to do something similar to Parula but rotate around the hue
circle the other direction so that the hues would go blue - purple - red

Certainly it can be considered–but we have to have a real implementation.

While I hate to promise vaporware, I actually was planning to have a
go at implementing such a colormap in the next few weeks, based on
optimizing the same set of parameters that viscm visualizes… FWIW.

Are we planning to make other default appearance changes at the same
time? The idea of changing the color cycle and/or dot-dash cycle has
already come up in this thread, and this earlier thread proposed
several more good ideas [1]:
http://thread.gmane.org/gmane.comp.python.matplotlib.devel/13128/focus=13166