# Colormap survey results

Greetings, matplotliberators!

I've counted up the various "votes" people made regarding the
different colormap options at
https://bids.github.io/colormap
including the ones in the matplotlib-devel and -users threads and
elsewhere (private email, twitter), etc.

There were two phases -- some people saw A/B/C, and some saw A/B/C/D,
so I'll separate the votes into those two groups. It's a bit
complicated to break down, also, because people expressed preferences
with different degrees of specificity ("I like X" vs total order vs
partial order...).

----------- Round 1 votes -----------

For those comparing A/B/C, the number of people with different preferences were:

First choice A: 6 votes
Of which:
A > C > B got 1 vote
A > B > C got 2 votes

First choice B: 8 votes
Of which:
B > A > C got 3 votes
B > C > A got 1 vote

First choice C: 7 votes
Of which:
C > A > B got 1 vote
C > B > A got 4 votes

----------- end of round 1 votes -----------

Then we added option D.

----------- Round 2 votes -----------

For those comparing A/B/C/D, the number of people with different
preferences were:

First choice A: 0 votes

First choice B: 2 votes
Of which:
B > A > C/D got 1 vote

First choice C: 1 votes
Of which:
C > D > A/B got 1 vote

First choice D: 12 votes
Of which:
D > C > A/B got 1 vote
D > A > C > B got 1 vote

----------- end of round 2 votes -----------

It seems that voting works better in some cases than others.

So the next question is where we go from here. We need to pick a color
for this bikeshed at some point. One theory is that the next step is
to propose a bunch of variations on option D and have another round of
voting etc. Another is that we should just call it a day and decide
now :-).

For reference, here's option D:
https://bids.github.io/colormap/images/screenshots/option_d.png

My personal feeling is that all these alternatives are basically
reasonable colormaps, but compared to option D I find them kinda ugly,
and, more importantly, substantially worse for colorblind users, which
IMO should outweigh a marginal/debateable improvement for the rest of
us.

So if it were up to me I'd be inclined to declare we've reached the
point of diminishing returns and go with D, but I don't know how
everyone else is feeling. Shall we just go for it?

-n

···

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

As long as A and B are included as named options, I have no objections to D as default. (From a branding perspective though, I preferred being closer to GNUPlot than Matlab, but whatevs. Show MPL’s roots I guess! =)

Juan.

···

On Wed, Jun 17, 2015 at 12:14 PM, Nathaniel Smith <njs@…503…> wrote:

Greetings, matplotliberators!

I’ve counted up the various “votes” people made regarding the

different colormap options at

https://bids.github.io/colormap

including the ones in the matplotlib-devel and -users threads and

elsewhere (private email, twitter), etc.

There were two phases – some people saw A/B/C, and some saw A/B/C/D,

so I’ll separate the votes into those two groups. It’s a bit

complicated to break down, also, because people expressed preferences

with different degrees of specificity (“I like X” vs total order vs

partial order…).

----------- Round 1 votes -----------

For those comparing A/B/C, the number of people with different preferences were:

First choice A: 6 votes

Of which:

`````` A > C > B got 1 vote

A > B > C got 2 votes
``````

First choice B: 8 votes

Of which:

``````B > A > C got 3 votes

B > C > A got 1 vote
``````

First choice C: 7 votes

Of which:

``````C > A > B got 1 vote

C > B > A got 4 votes
``````

----------- end of round 1 votes -----------

Then we added option D.

----------- Round 2 votes -----------

For those comparing A/B/C/D, the number of people with different

preferences were:

First choice A: 0 votes

First choice B: 2 votes

Of which:

``````  B > A > C/D got 1 vote
``````

First choice C: 1 votes

Of which:

``````  C > D > A/B got 1 vote
``````

First choice D: 12 votes

Of which:

``````  D > C > A/B got 1 vote

D > A > C > B got 1 vote
``````

----------- end of round 2 votes -----------

It seems that voting works better in some cases than others.

So the next question is where we go from here. We need to pick a color

for this bikeshed at some point. One theory is that the next step is

to propose a bunch of variations on option D and have another round of

voting etc. Another is that we should just call it a day and decide

now :-).

For reference, here’s option D:

``````[https://bids.github.io/colormap/images/screenshots/option_d.png](https://bids.github.io/colormap/images/screenshots/option_d.png)
``````

And here are the other greenish colormaps that have been mentioned:

``````[https://bids.github.io/colormap/images/screenshots/fake_parula.png](https://bids.github.io/colormap/images/screenshots/fake_parula.png)

[https://bids.github.io/colormap/images/screenshots/erics-RdBuGnYl_r.png](https://bids.github.io/colormap/images/screenshots/erics-RdBuGnYl_r.png)

[https://bids.github.io/colormap/images/screenshots/erics-RdBuGnYl_r_v2.png](https://bids.github.io/colormap/images/screenshots/erics-RdBuGnYl_r_v2.png)

[https://bids.github.io/colormap/images/screenshots/joes-blu_grn_pnk2.png](https://bids.github.io/colormap/images/screenshots/joes-blu_grn_pnk2.png)
``````

My personal feeling is that all these alternatives are basically

reasonable colormaps, but compared to option D I find them kinda ugly,

and, more importantly, substantially worse for colorblind users, which

IMO should outweigh a marginal/debateable improvement for the rest of

us.

So if it were up to me I’d be inclined to declare we’ve reached the

point of diminishing returns and go with D, but I don’t know how

everyone else is feeling. Shall we just go for it?

-n

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

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

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

Yeah, all the colormaps will be available over way or another, it’s just the default in question.

-n

···

On Jun 16, 2015 7:31 PM, “Juan Nunez-Iglesias” <jni.soma@…149…> wrote:

As long as A and B are included as named options, I have no objections to D as default.

Ooh, I do like Eric's v2, I see much more of a fall off in the sample images, so I would say v2 > D > ?

Any chance of the galaxy animation with v2?

Another question, why does a reason exist why the colour-maps start at yellow and go to blue, either anti-clockwise, or clockwise? What about a rotation of 90deg rather than just a mirror inverse on the a' b' plane?

Colorblind users can reliably distinguish blue/yellow and dark/light, but that’s all, so an accessible colormap has to use those for its dominant axis. And then you have to do dark+bluish and light+yellowish if you want something colorful, because it just turns out that the way the brain works, there is no such thing as a saturated light blue or a saturated dark yellow.

-n

···

On Jun 17, 2015 8:36 AM, “OceanWolf” <juichenieder-nabb@…705…> wrote:

Another question, why does a reason exist why the colour-maps start at yellow and go to blue, either anti-clockwise, or clockwise? What about a rotation of 90deg rather than just a mirror inverse on the a’ b’ plane?

[...snip discussion of how option D was the favorite of 80% of people
in the survey...]

So the next question is where we go from here. We need to pick a color
for this bikeshed at some point. One theory is that the next step is
to propose a bunch of variations on option D and have another round of
voting etc. Another is that we should just call it a day and decide
now :-).

For reference, here's option D:
https://bids.github.io/colormap/images/screenshots/option_d.png

My personal feeling is that all these alternatives are basically
reasonable colormaps, but compared to option D I find them kinda ugly,
and, more importantly, substantially worse for colorblind users, which
IMO should outweigh a marginal/debateable improvement for the rest of
us.

So if it were up to me I'd be inclined to declare we've reached the
point of diminishing returns and go with D, but I don't know how
everyone else is feeling. Shall we just go for it?

So it's been 2 weeks with no real followup on this. I don't really
care where we end up (though I selfishly would somewhat prefer if
there is a decision before our SciPy talk next week, just so we can
tell people what it is :-)), but we need to resolve this somehow.
What's the plan?

Michael, Thomas, I see from the credits page that you're the Official
Lead Developers :-), so given the intrinsic bikeshedditude of this
topic I suspect it may come down to you taking a deep breath and
making a decision (or at least declaring some specific concrete
process for making the decision)?

-n

···

On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <njs@...503...> wrote:

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

One thing we need to do is get some of these maps into _cm.py via PR. I would prefer not to have them go in as huge tables if they can be made more compact, either by being function-generated or by using the LinearSegmentedColormap mechanism with a moderate number of breakpoints.

Suggestions?

(We will also need a naming scheme.)

Eric

···

On 2015/07/01 1:56 PM, Nathaniel Smith wrote:

On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <njs@...503...> wrote:

[...snip discussion of how option D was the favorite of 80% of people
in the survey...]

So the next question is where we go from here.

I have been thinking a bit about naming. We could always go the route of “Heinz 57”, “Chanel No. 5”, or “Preparation H”. Not saying that “MPL-d” is a catchy name or not, but…

Ben Root

···

On Wed, Jul 1, 2015 at 9:31 PM, Eric Firing <efiring@…229…> wrote:

On 2015/07/01 1:56 PM, Nathaniel Smith wrote:

On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <njs@…503…> wrote:

[…snip discussion of how option D was the favorite of 80% of people

in the survey…]

So the next question is where we go from here.

One thing we need to do is get some of these maps into _cm.py via PR.

I would prefer not to have them go in as huge tables if they can be made

more compact, either by being function-generated or by using the

LinearSegmentedColormap mechanism with a moderate number of breakpoints.

Suggestions?

(We will also need a naming scheme.)

Eric

Don’t Limit Your Business. Reach for the Cloud.

GigeNET’s Cloud Solutions provide you with the tools and support that

Configured For All Businesses. Start Your Cloud Today.

https://www.gigenetcloud.com/

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

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

Not my cup of tea, but to get the ball rolling, how about “Truncated Rainbow”? [Red, Orange, Yellow, Green, Blue, Indigo, Violet][2:]

···

From: Benjamin Root <ben.root@…553…>
To: Eric Firing <efiring@…229…>
Cc: matplotlib development list matplotlib-devel@lists.sourceforge.net
Sent: Thursday, 2 July 2015, 4:19
Subject: Re: [matplotlib-devel] Colormap survey results

I have been thinking a bit about naming. We could always go the route of “Heinz 57”, “Chanel No. 5”, or “Preparation H”. Not saying that “MPL-d” is a catchy name or not, but…

Ben Root

On Wed, Jul 1, 2015 at 9:31 PM, Eric Firing <efiring@…229…> wrote:

On 2015/07/01 1:56 PM, Nathaniel Smith wrote:

On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <njs@…503…> wrote:

[…snip discussion of how option D was the favorite of 80% of people

in the survey…]

So the next question is where we go from here.

One thing we need to do is get some of these maps into _cm.py via PR.

I would prefer not to have them go in as huge tables if they can be made

more compact, either by being function-generated or by using the

LinearSegmentedColormap mechanism with a moderate number of breakpoints.

Suggestions?

(We will also need a naming scheme.)

Eric

Don’t Limit Your Business. Reach for the Cloud.

GigeNET’s Cloud Solutions provide you with the tools and support that

Configured For All Businesses. Start Your Cloud Today.

https://www.gigenetcloud.com/

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

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

Don’t Limit Your Business. Reach for the Cloud.
GigeNET’s Cloud Solutions provide you with the tools and support that
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/

Matplotlib-devel mailing list
Matplotlib-devel@…1035…orge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[…snip discussion of how option D was the favorite of 80% of people
in the survey…]

So the next question is where we go from here.

One thing we need to do is get some of these maps into _cm.py via PR.

We’ve been a bit distracted getting the software and talk together ahead of scipy, but PR (with names) will follow within the next week or so. The decision part is pretty orthogonal though I think? It’s not like matplotlib 2.0 is going to branch between now and scipy :-).

I would prefer not to have them go in as huge tables if they can be made
more compact, either by being function-generated or by using the
LinearSegmentedColormap mechanism with a moderate number of breakpoints.

Suggestions?

Depends on how you define “moderate”, but my guess is that linear segmented is the best approach – the exact colormaps have a pretty terse representation as bezier control points, but using this at runtime would require pulling in the full colorspace apparatus as a dependency. Which I guess has points in its favor for other reasons, but nonetheless.

These kinds of details can be worked out in the PR review process, though. The blocking issue is that we need a decision :-).

-n

···

On Jul 1, 2015 6:31 PM, “Eric Firing” <efiring@…229…> wrote:

On 2015/07/01 1:56 PM, Nathaniel Smith wrote:

On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <njs@…503…> wrote:

We would like to tag 1.5 around scipy and it would be nice to get the new color maps out, even if they are not yet the default.

···

On Wed, Jul 1, 2015, 11:13 PM Nathaniel Smith <njs@…503…> wrote:

On Jul 1, 2015 6:31 PM, “Eric Firing” <efiring@…229…> wrote:

On 2015/07/01 1:56 PM, Nathaniel Smith wrote:

On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <njs@…503…> wrote:

[…snip discussion of how option D was the favorite of 80% of people
in the survey…]

So the next question is where we go from here.

One thing we need to do is get some of these maps into _cm.py via PR.

We’ve been a bit distracted getting the software and talk together ahead of scipy, but PR (with names) will follow within the next week or so. The decision part is pretty orthogonal though I think? It’s not like matplotlib 2.0 is going to branch between now and scipy :-).

I would prefer not to have them go in as huge tables if they can be made
more compact, either by being function-generated or by using the
LinearSegmentedColormap mechanism with a moderate number of breakpoints.

Suggestions?

Depends on how you define “moderate”, but my guess is that linear segmented is the best approach – the exact colormaps have a pretty terse representation as bezier control points, but using this at runtime would require pulling in the full colorspace apparatus as a dependency. Which I guess has points in its favor for other reasons, but nonetheless.

These kinds of details can be worked out in the PR review process, though. The blocking issue is that we need a decision :-).

-n

Don’t Limit Your Business. Reach for the Cloud.

GigeNET’s Cloud Solutions provide you with the tools and support that

Configured For All Businesses. Start Your Cloud Today.

https://www.gigenetcloud.com/_______________________________________________

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

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

For what it is worth, if D were made the default colormap, I would be very happy.

···

On 1 July 2015 at 22:35, Thomas Caswell <tcaswell@…149…> wrote:

We would like to tag 1.5 around scipy and it would be nice to get the new color maps out, even if they are not yet the default.

On Wed, Jul 1, 2015, 11:13 PM Nathaniel Smith <njs@…503…> wrote:

On Jul 1, 2015 6:31 PM, “Eric Firing” <efiring@…229…> wrote:

On 2015/07/01 1:56 PM, Nathaniel Smith wrote:

On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <njs@…503…> wrote:

[…snip discussion of how option D was the favorite of 80% of people
in the survey…]

So the next question is where we go from here.

One thing we need to do is get some of these maps into _cm.py via PR.

We’ve been a bit distracted getting the software and talk together ahead of scipy, but PR (with names) will follow within the next week or so. The decision part is pretty orthogonal though I think? It’s not like matplotlib 2.0 is going to branch between now and scipy :-).

I would prefer not to have them go in as huge tables if they can be made
more compact, either by being function-generated or by using the
LinearSegmentedColormap mechanism with a moderate number of breakpoints.

Suggestions?

Depends on how you define “moderate”, but my guess is that linear segmented is the best approach – the exact colormaps have a pretty terse representation as bezier control points, but using this at runtime would require pulling in the full colorspace apparatus as a dependency. Which I guess has points in its favor for other reasons, but nonetheless.

These kinds of details can be worked out in the PR review process, though. The blocking issue is that we need a decision :-).

-n

Don’t Limit Your Business. Reach for the Cloud.

GigeNET’s Cloud Solutions provide you with the tools and support that

Configured For All Businesses. Start Your Cloud Today.

https://www.gigenetcloud.com/_______________________________________________

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

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

Don’t Limit Your Business. Reach for the Cloud.

GigeNET’s Cloud Solutions provide you with the tools and support that