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 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/erics-RdBuGnYl_r.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 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 <nj...@po...> 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 > > 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/erics-RdBuGnYl_r.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 > > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
On Jun 16, 2015 7:31 PM, "Juan Nunez-Iglesias" <jni...@gm...> wrote: > > As long as A and B are included as named options, I have no objections to D as default. Yeah, all the colormaps will be available over way or another, it's just the default in question. -n
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?
On Jun 17, 2015 8:36 AM, "OceanWolf" <jui...@ya...> 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? 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 Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <nj...@po...> 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. 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 > > 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/erics-RdBuGnYl_r.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 > > 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 -- Nathaniel J. Smith -- http://vorpus.org
On 2015年07月01日 1:56 PM, Nathaniel Smith wrote: > On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <nj...@po...> 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
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.. :-P Ben Root On Wed, Jul 1, 2015 at 9:31 PM, Eric Firing <ef...@ha...> wrote: > On 2015年07月01日 1:56 PM, Nathaniel Smith wrote: > > On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <nj...@po...> 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 > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > 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...@ou...> To: Eric Firing <ef...@ha...> Cc: matplotlib development list <mat...@li...> 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.. :-P Ben Root On Wed, Jul 1, 2015 at 9:31 PM, Eric Firing <ef...@ha...> wrote: On 2015年07月01日 1:56 PM, Nathaniel Smith wrote: > On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <nj...@po...> 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 you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Matplotlib-devel mailing list Mat...@li... 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 you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Matplotlib-devel mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
On Jul 1, 2015 6:31 PM, "Eric Firing" <ef...@ha...> wrote: > > On 2015年07月01日 1:56 PM, Nathaniel Smith wrote: > > On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <nj...@po...> 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
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 <nj...@po...> wrote: > On Jul 1, 2015 6:31 PM, "Eric Firing" <ef...@ha...> wrote: > > > > On 2015年07月01日 1:56 PM, Nathaniel Smith wrote: > > > On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <nj...@po...> > 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 > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > 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 <tca...@gm...> 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 <nj...@po...> wrote: > >> On Jul 1, 2015 6:31 PM, "Eric Firing" <ef...@ha...> wrote: >> > >> > On 2015年07月01日 1:56 PM, Nathaniel Smith wrote: >> > > On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith <nj...@po...> >> 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 >> you need to offload your IT needs and focus on growing your business. >> Configured For All Businesses. Start Your Cloud Today. >> https://www.gigenetcloud.com/ >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> 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 > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >
