matplotlib-devel Mailing List for matplotlib

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

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?

I think I mean that before we cherrypicked from master to colouroverhaul, as we only wanted a few things from master to go out in the next release, but now if I understand correctly we want most of master to go out in the next release, so we have to uncherrypick out the stuff we don't want, and I fear that such a branch won't have had the rigorous testing that the current color-overhaul branch has had.  Metaphorically speaking we have a mixture of different fluids that have settled into clear stratified layers, now we plan to give that mixture a good shake and hope we don't break everything.

Meh, perhaps I just act too overcautious.

________________________________
From: Thomas Caswell <tca...@gm...>
To: OceanWolf <jui...@ya...>; "mat...@li..." <mat...@li...> 
Sent: Wednesday, 17 June 2015, 6:04
Subject: Re: [matplotlib-devel] Release schedule



I am not sure what you mean by cherry-picking/uncherry picking.  I just looked at what is on `color_overhaul` which is not in master and it is: changes that should be discarded (changes to cxx / changes to _tri.* that rely on cxx), one change related to mathtext layout (and conflicts due to mathext_*68 being added on both branches) which we do not want to cherry pick, and documentation about pkg-config and a minor doc which will be easy to cherry-pick (I am going to do in now).

There is documentation about the coming color change in master, but that is probably ok to include in a point release (as it is just plans).


In either case the 2.0 release will contain _only_ style related API breaks and will be based on what ever the last point release was.

Tom




On Tue, Jun 16, 2015 at 9:15 AM OceanWolf <jui...@ya...> wrote:

The only concerns on doing 1.5 -> 2.0 come from the huge amount of extra work in uncherrypicking recherrypicking.  Given the amount of testing that both master and color-overhaul have gone through by us devs and other interested people, I feel it perhaps better to keep the release schedule as it was.
>
>From the perspective of working on MEP22/27 it would feel nice to do a 1.5 and then depreciate (or fully-remove) in 2.0, but personally I opt for safety over nicety (plus it gives us more time to get MEP22/27 completed and have time for more people to test it, find bugs, though I doubt we will have any O:)).
>
>
>Best,
>OceanWolf
>

I am not sure what you mean by cherry-picking/uncherry picking.  I just
looked at what is on `color_overhaul` which is not in master and it is:
changes that should be discarded (changes to cxx / changes to _tri.* that
rely on cxx), one change related to mathtext layout (and conflicts due to
mathext_*68 being added on both branches) which we do not want to cherry
pick, and documentation about pkg-config and a minor doc which will be easy
to cherry-pick (I am going to do in now).

There is documentation about the coming color change in master, but that is
probably ok to include in a point release (as it is just plans).

In either case the 2.0 release will contain _only_ style related API breaks
and will be based on what ever the last point release was.

Tom

On Tue, Jun 16, 2015 at 9:15 AM OceanWolf <jui...@ya...>
wrote:

> The only concerns on doing 1.5 -> 2.0 come from the huge amount of extra
> work in uncherrypicking recherrypicking.  Given the amount of testing that
> both master and color-overhaul have gone through by us devs and other
> interested people, I feel it perhaps better to keep the release schedule as
> it was.
>
> From the perspective of working on MEP22/27 it would feel nice to do a 1.5
> and then depreciate (or fully-remove) in 2.0, but personally I opt for
> safety over nicety (plus it gives us more time to get MEP22/27 completed
> and have time for more people to test it, find bugs, though I doubt we will
> have any O:)).
>
>
> Best,
> OceanWolf
>

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

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
>

As a heads up, there is now a `pyplot` and a `pylab` packages on pypi.

I have created an issue with the pypi folks
https://sourceforge.net/p/pypi/support-requests/512/
and with both projects
https://github.com/javipalanca/pylab/issues/1
https://github.com/sirrice/pyplot/issues/2

I found both of these via SO questions so I suspect that there is a coming
wave of confused new users who did `pip install pyplot` or `pip install
pylab`.

Tom

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