How to move beyond JET as the default matplotlib colormap

Development matplotlib-devel
1

I am a bit wary of doing a 2.0 just to change the color map, but when every I try to write out why, they don’t sound convincing. We may end up with a 3.0 within a year or so due to the possible plotting API/pyplot work that is (hopefully) coming.

If we are going to do this, I think we should do the 1.4.3 release (scheduled for Feb 1, RCs in mid January), then put one commit to change the color map on top of that, tag 2.0 and then master turns into 2.1.x (targeted for right after scipy?).

There is also the thought to get the major c++ refactor work tagged and released sooner rather than later so maybe we want to do 1.4.3, 1.5.0 and 2.0 in Feb with 2.0 based off of 1.5 not 1.4.

···

On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pelson.pub@…149…> wrote:

Many of you will be aware of there has been an ongoing issue (#875, http://goo.gl/xLZvuL) which recommends the removal of Jet as the default colormap in matplotlib.

The
argument against Jet is compelling and I think that as a group who care
about high quality visualisation we should be seriously discussing how matplotlib can move beyond Jet.

There was recently an open letter to the climate science community
asking for scientists to “pledge” against using rainbow like colormaps (such as Jet), and there are similar initiatives in other scientific fields, as well as there being a plethora of well researched literature on the subject.

As such, it’s time to agree on a solution on how matplotlib can reach the end of the rainbow.

The two major hurdles, AFAICS, to replacing the three little characters which control the default colormap of matplotlib are:

  • We haven’t had a clear (decisive) discussion about what we should replace Jet with.
  • There are concerns about changing the default as it would change the existing widespread behaviour.

To
address the first point I’ll start a new mailinglist thread (entitled “Matplotlib’s new default colormap”) where new default colormap suggestions can be made. The thread should strictly avoid “+1” type comments, and generally try to stick to reference-able/demonstrable fact, rather than opinion. There will
be a difference of opinion, however the final decision has to come down
to the project lead (sorry Mike) who I know will do whatever is necessary to make the best choice for matplotlib.

The second point is a reasonable response when we consider that matplotlib as a project has no clear
statement on backwards compatibility. As a result, matplotlib is highly
change averse between minor releases (to use semantic versioning terms)
and therefore changing the default colormap is unpalatable in the v1.x release series. As a result I’d like to propose that the next release of
matplotlib be called 2.0, with the only major backwards-incompatible change be the removal of Jet as the default colormap.

As
a project matplotlib mustn’t get caught up in the trap of shying away from a major version release when the need arises, and in my opinion helping our users to avoid using a misleading colormap is a worthy cause for a v2.0.

Please try to keep this thread on the “how”, and not on the “what” of the replacement default colormap, for which there is a dedicated thread.

Thanks,

Phil

(#endrainbow)

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=157005751&iu=/4140/ostg.clktrk

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

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

2

Given the workload that making a release causes, is it necessary to put out a v1.4.3 at all? On a similar sounding argument, given that the removal of CXX doesn’t break user APIs, and has been on master for several weeks with fewer than anticipated side-effects, do we even need a v1.5? Essentially, what is the barrier from moving straight to a v2.0 in Feb?

What I’d like to avoid is this idea of “we’re talking about a making a major release so let’s fix everything that was ever broken” - my definition of a v2.0 release is really just v1.5+new default cmap. If there are other things that need fixing in a backwards incompatible way then we should discuss and plan how we are going to do that, and if there is developer appetite, there is no reason not to talk about releasing a v3.0 in 18-24 months (which is currently ~2 mpl minor release cycles).

···

On 21 November 2014 18:56, Thomas Caswell <tcaswell@…149…> wrote:

I am a bit wary of doing a 2.0 just to change the color map, but when every I try to write out why, they don’t sound convincing. We may end up with a 3.0 within a year or so due to the possible plotting API/pyplot work that is (hopefully) coming.

If we are going to do this, I think we should do the 1.4.3 release (scheduled for Feb 1, RCs in mid January), then put one commit to change the color map on top of that, tag 2.0 and then master turns into 2.1.x (targeted for right after scipy?).

There is also the thought to get the major c++ refactor work tagged and released sooner rather than later so maybe we want to do 1.4.3, 1.5.0 and 2.0 in Feb with 2.0 based off of 1.5 not 1.4.

On Fri Nov 21 2014 at 12:52:03 PM Benjamin Root <ben.root@…553…> wrote:

As a point of clarification, is this proposed 2.0 release different from the 1.5 release?

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=157005751&iu=/4140/ostg.clktrk_______________________________________________

Matplotlib-devel mailing list

Matplotlib-devel@…1041…sourceforge.net

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

On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pelson.pub@…149…> wrote:

Many of you will be aware of there has been an ongoing issue (#875, http://goo.gl/xLZvuL) which recommends the removal of Jet as the default colormap in matplotlib.

The
argument against Jet is compelling and I think that as a group who care
about high quality visualisation we should be seriously discussing how matplotlib can move beyond Jet.

There was recently an open letter to the climate science community
asking for scientists to “pledge” against using rainbow like colormaps (such as Jet), and there are similar initiatives in other scientific fields, as well as there being a plethora of well researched literature on the subject.

As such, it’s time to agree on a solution on how matplotlib can reach the end of the rainbow.

The two major hurdles, AFAICS, to replacing the three little characters which control the default colormap of matplotlib are:

  • We haven’t had a clear (decisive) discussion about what we should replace Jet with.
  • There are concerns about changing the default as it would change the existing widespread behaviour.

To
address the first point I’ll start a new mailinglist thread (entitled “Matplotlib’s new default colormap”) where new default colormap suggestions can be made. The thread should strictly avoid “+1” type comments, and generally try to stick to reference-able/demonstrable fact, rather than opinion. There will
be a difference of opinion, however the final decision has to come down
to the project lead (sorry Mike) who I know will do whatever is necessary to make the best choice for matplotlib.

The second point is a reasonable response when we consider that matplotlib as a project has no clear
statement on backwards compatibility. As a result, matplotlib is highly
change averse between minor releases (to use semantic versioning terms)
and therefore changing the default colormap is unpalatable in the v1.x release series. As a result I’d like to propose that the next release of
matplotlib be called 2.0, with the only major backwards-incompatible change be the removal of Jet as the default colormap.

As
a project matplotlib mustn’t get caught up in the trap of shying away from a major version release when the need arises, and in my opinion helping our users to avoid using a misleading colormap is a worthy cause for a v2.0.

Please try to keep this thread on the “how”, and not on the “what” of the replacement default colormap, for which there is a dedicated thread.

Thanks,

Phil

(#endrainbow)

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=157005751&iu=/4140/ostg.clktrk

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

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

3

We now have the style system in-place. I envision the 1.5 release as having the attempt at encoding the current visual style as “classic” (which would be default), and to put together a “bleeding” (or “trendy” or “hipster”) style that would encode many of the proposed changes to the defaults. Come mpl2.0, any remaining bugs in the style system should be ironed out, and we can canonicalize the “hipster” style into a “stable” style. We can even then utilize “hipster” as a playground of sorts to get feedback on proposed changes that would work their way into “stable”. Each release could also alias “stable” with a “mplX.Y” style. Another reason why I like this approach is that it gives us a way to explicitly deprecate various styles (with warnings and user notes) if an older style becomes a maintenance burden as matplotlib evolves.

I am also liking the argument that mpl2.0 should be focused on just visual changes. And logically organized styles will provide users with the needed “out” to hang onto most of the old visual styles (they would just need to add a single line to their programs or maybe a config file somewhere).

I am still not convinced that all of the CXX/AGG issues have been ironed out. While nominal situations seems to have been fairly straight-forward, I am concerned about error-handling in the interactive backends. As I have already discovered, the change did introduce a segfaulting error handling path that merely errored out previously (seems to be fixed now with the copy constructor fix). These sorts of things aren’t covered by our test suite and can be very backend-dependent.

Cheers!
Ben Root

···

On Sat, Nov 22, 2014 at 5:16 AM, Phil Elson <pelson.pub@…149…> wrote:

Given the workload that making a release causes, is it necessary to put out a v1.4.3 at all? On a similar sounding argument, given that the removal of CXX doesn’t break user APIs, and has been on master for several weeks with fewer than anticipated side-effects, do we even need a v1.5? Essentially, what is the barrier from moving straight to a v2.0 in Feb?

What I’d like to avoid is this idea of “we’re talking about a making a major release so let’s fix everything that was ever broken” - my definition of a v2.0 release is really just v1.5+new default cmap. If there are other things that need fixing in a backwards incompatible way then we should discuss and plan how we are going to do that, and if there is developer appetite, there is no reason not to talk about releasing a v3.0 in 18-24 months (which is currently ~2 mpl minor release cycles).

On 21 November 2014 18:56, Thomas Caswell <tcaswell@…149…> wrote:

I am a bit wary of doing a 2.0 just to change the color map, but when every I try to write out why, they don’t sound convincing. We may end up with a 3.0 within a year or so due to the possible plotting API/pyplot work that is (hopefully) coming.

If we are going to do this, I think we should do the 1.4.3 release (scheduled for Feb 1, RCs in mid January), then put one commit to change the color map on top of that, tag 2.0 and then master turns into 2.1.x (targeted for right after scipy?).

There is also the thought to get the major c++ refactor work tagged and released sooner rather than later so maybe we want to do 1.4.3, 1.5.0 and 2.0 in Feb with 2.0 based off of 1.5 not 1.4.

On Fri Nov 21 2014 at 12:52:03 PM Benjamin Root <ben.root@…553…> wrote:

As a point of clarification, is this proposed 2.0 release different from the 1.5 release?

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=157005751&iu=/4140/ostg.clktrk_______________________________________________

Matplotlib-devel mailing list

Matplotlib-devel@…1041…sourceforge.net

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

On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pelson.pub@…149…> wrote:

Many of you will be aware of there has been an ongoing issue (#875, http://goo.gl/xLZvuL) which recommends the removal of Jet as the default colormap in matplotlib.

The
argument against Jet is compelling and I think that as a group who care
about high quality visualisation we should be seriously discussing how matplotlib can move beyond Jet.

There was recently an open letter to the climate science community
asking for scientists to “pledge” against using rainbow like colormaps (such as Jet), and there are similar initiatives in other scientific fields, as well as there being a plethora of well researched literature on the subject.

As such, it’s time to agree on a solution on how matplotlib can reach the end of the rainbow.

The two major hurdles, AFAICS, to replacing the three little characters which control the default colormap of matplotlib are:

  • We haven’t had a clear (decisive) discussion about what we should replace Jet with.
  • There are concerns about changing the default as it would change the existing widespread behaviour.

To
address the first point I’ll start a new mailinglist thread (entitled “Matplotlib’s new default colormap”) where new default colormap suggestions can be made. The thread should strictly avoid “+1” type comments, and generally try to stick to reference-able/demonstrable fact, rather than opinion. There will
be a difference of opinion, however the final decision has to come down
to the project lead (sorry Mike) who I know will do whatever is necessary to make the best choice for matplotlib.

The second point is a reasonable response when we consider that matplotlib as a project has no clear
statement on backwards compatibility. As a result, matplotlib is highly
change averse between minor releases (to use semantic versioning terms)
and therefore changing the default colormap is unpalatable in the v1.x release series. As a result I’d like to propose that the next release of
matplotlib be called 2.0, with the only major backwards-incompatible change be the removal of Jet as the default colormap.

As
a project matplotlib mustn’t get caught up in the trap of shying away from a major version release when the need arises, and in my opinion helping our users to avoid using a misleading colormap is a worthy cause for a v2.0.

Please try to keep this thread on the “how”, and not on the “what” of the replacement default colormap, for which there is a dedicated thread.

Thanks,

Phil

(#endrainbow)

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=157005751&iu=/4140/ostg.clktrk

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

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