matplotlib-devel Mailing List for matplotlib

I would be +1 on this as well. Various command-line text extraction tools
are near useless with the current state.

On Thu, Feb 19, 2015 at 9:42 AM, Benjamin Reedlunn <bre...@gm...>
wrote:

> I am in favor of such a change.  I also have rcParams['pdf.fonttype'] =
> 42, so I can use Adobe Illustrator to tweak my mpl generated plots.
> Changing a word in Illustrator becomes quite a pain when every glyph is a
> separate text box.
>
> -Ben Reedlunn
>
> On Feb 18, 2015, at 8:52 AM, Eric Moore <ew...@re...> wrote:
>
> Hi,
>
> I posted on the user list a while back about saving editable text using
> the postscript backend [1].  There I was informed that this was changed a
> few years ago to individually place glyphs.  It looks to me, that this
> change was about correctly supporting unicode in this backend [2].
>
> Would the project be open to changing this to produce text runs when all
> of the characters are ascii? This way, the general unicode case should
> still work but runs of text where the special handling is not necessary
> should result in editable text.  I'm happy to work up a patch, but I don't
> want to spend the time if there is no hope of it being merged.
>
> My use case is to be able to make some tweaks to figures post mpl.  In my
> case this tends to be to either combine figures from several sources into a
> single coherent figure or to adjust the figure size or spacing slightly so
> the final figure fits into the space available.  All of this can be done in
> mpl directly, but in terms of effective use of my time, opening the figure
> in Corel Draw, Inkscape or Illustrator is much faster since I can get the
> figure 90% of the way there quickly and easily using mpl.
>
> Eric
>
> 1. http://thread.gmane.org/gmane.comp.python.matplotlib.general/34816
> 2.
> https://github.com/matplotlib/matplotlib/commit/80321a3b489994748b79e41bc34a65f836a9a03f
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

I am in favor of such a change.  I also have rcParams['pdf.fonttype'] = 42, so I can use Adobe Illustrator to tweak my mpl generated plots.   Changing a word in Illustrator becomes quite a pain when every glyph is a separate text box.

-Ben Reedlunn

On Feb 18, 2015, at 8:52 AM, Eric Moore <ew...@re...> wrote:

> Hi, 
> 
> I posted on the user list a while back about saving editable text using the postscript backend [1].  There I was informed that this was changed a few years ago to individually place glyphs.  It looks to me, that this change was about correctly supporting unicode in this backend [2].
> 
> Would the project be open to changing this to produce text runs when all of the characters are ascii? This way, the general unicode case should still work but runs of text where the special handling is not necessary should result in editable text.  I'm happy to work up a patch, but I don't want to spend the time if there is no hope of it being merged.
> 
> My use case is to be able to make some tweaks to figures post mpl.  In my case this tends to be to either combine figures from several sources into a single coherent figure or to adjust the figure size or spacing slightly so the final figure fits into the space available.  All of this can be done in mpl directly, but in terms of effective use of my time, opening the figure in Corel Draw, Inkscape or Illustrator is much faster since I can get the figure 90% of the way there quickly and easily using mpl.  
> 
> Eric
> 
> 1. http://thread.gmane.org/gmane.comp.python.matplotlib.general/34816
> 2. https://github.com/matplotlib/matplotlib/commit/80321a3b489994748b79e41bc34a65f836a9a03f
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,

NumFOCUS has promotes and supports the ongoing research and development of
open-source computing tools including Matplotlib.

This year NumFOCUS want to try be a Google Summer of Code
"umbrella" mentoring organization,

    Umbrella organizations are mentoring organizations accepted into the Google
    Summer of Code program that have other open source organizations working
    "under" them. Sometime organizations that work very closely or have very
    similar goals or communities may get put together under an "umbrella."
    Google stills expects all organizations under the umbrella, whether accepted
    into the program under their title or not, to adhere to all the rules and
    regulations of the program.

    From https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page#umbrella_organization

To help promote and support Matplotlib.

We encourage Matplotlib to apply to Google Summer of Code under your own title
and will be very happy if you can also do with us.
If you are interested, please check https://github.com/swcarpentry/gsoc2015
and https://github.com/swcarpentry/gsoc2015/blob/master/CONTRIBUTING.md.

If you have any question, please email me directly.

Thanks in advance,
Raniere

On Wed, Feb 18, 2015 at 5:23 PM, Eric Firing <ef...@ha...> 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?


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.

On 2015/02/18 2:39 PM, Nathaniel Smith wrote:
> On Feb 16, 2015 3:39 PM, "Eric Firing" <ef...@ha...> 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.
>
> 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

>
> -n
>
> [1] well I would think that wouldn't I ;-)
>

On 2015/02/18 2:42 PM, Olga Botvinnik wrote:
> FYI the notebook isn't working for me in IPython 2.2.0
>
> I agree with Michael's sentiment that from a marketing perspective, a
> matplotlib-only colormap is advantageous to maintain a consistent brand.

Provided we can find a good colormap for that purpose; right now the 
only sequential proposals are gray, YlGnBu, and Michael's new HCL. 
Aesthetically, I find boring old YlGnBu the most pleasant of this small 
set.  I agree with Michael's point that its yellow end might be lighter 
than optimum.  To me, the HCL map is not downright ugly, but its 
definitely not appealing, either.  My guess is that the prevalence of 
blues and greens in nature makes it easier for many people, myself 
included, to react favorably to large expanses of those colors for long 
periods of time.

>
> Will these colormaps also be used for non-imshow/colormesh/pcolormesh
> data, as in for line colors as well? I think that's a great idea! It'll
> make the black and white versions easier to understand since the
> changing colors will monotonically increase/decrease in darkness rather
> than randomly changing.

I think that the line color cycling default should not match the default 
colormap at all; instead, it is in the "categorical" category, with 
visual ordering being secondary.  All colors should be highly visible 
and distinguishable whether on a computer screen, paper, or projected by 
a poor projector in an overly lit room.

Eric

@Nathaniel I think developing the color-overhaul as a maintenance release
is a decent compromise.  All non-color changes get directed at the master
branch and we can cherry-picked back bug-fixes as needed.
The next feature release is planned for July/August,  I _really_ hope
sorting out the colors does not take that much longer. if we start to Paint
a Bike Shed that just needs to be shut down.

I am not sure how I feel about a _default_ non-trivial style-cycle.  +1 on
providing the machinery and rcparams to do it and agnostic which branch it
goes on.

@Olga  I think there are two separate issues, the default color map used by
ScalarMappable and the default color cycle that `ax.plot` and company use.
I think both should be up for discussion and do not _need_ to use the same
colors.

Tom

On Wed Feb 18 2015 at 7:43:31 PM Olga Botvinnik <obo...@uc...> wrote:

> FYI the notebook isn't working for me in IPython 2.2.0
>
> I agree with Michael's sentiment that from a marketing perspective, a
> matplotlib-only colormap is advantageous to maintain a consistent brand.
>
> Will these colormaps also be used for non-imshow/colormesh/pcolormesh
> data, as in for line colors as well? I think that's a great idea! It'll
> make the black and white versions easier to understand since the changing
> colors will monotonically increase/decrease in darkness rather than
> randomly changing.
>
> RE: Nathaniel - I'm not as much of a fan of changing line styles in
> addition to colors, but that's my personal preference for plotting lines
> specifically. When plotting scatters, I think it does make sense, since the
> room to perceive a change in color is so small, that a change in shape
> helps too.
>
> On Wed Feb 18 2015 at 9:40:00 AM Michael Waskom <mw...@st...>
> wrote:
>
>> 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 :)
>>
>> (But I do think it's worth distinguishing the matplotlib default from the
>> matlab default.)
>>
>> Michael
>>
> ------------------------------------------------------------
>> ------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> ------------------------------------------------------------
> ------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Wed, Feb 18, 2015 at 4:42 PM, Olga Botvinnik <obo...@uc...> wrote:

> FYI the notebook isn't working for me in IPython 2.2.0
>

Oops, sorry.


> I agree with Michael's sentiment that from a marketing perspective, a
> matplotlib-only colormap is advantageous to maintain a consistent brand.
>

Just to be clear, I wasn't suggesting *matplotlib only* in the (legal)
sense that parula is matlab only, just that it should be identifiably "the
matplotlib colormap".


> Will these colormaps also be used for non-imshow/colormesh/pcolormesh
> data, as in for line colors as well? I think that's a great idea! It'll
> make the black and white versions easier to understand since the changing
> colors will monotonically increase/decrease in darkness rather than
> randomly changing.
>

I wasn't really thinking the plt.plot line cycle, more about plt.scatter,
plt.contour, etc. and other places that accept a cmap argument but don't
draw an "image-like" plot. Though, having a default colormap that can be
used when you want to encode a quantitative value in the color of lines,
e.g. the figures here:
http://www.machenslab.org/publications/machens_etal_2010.pdf, would be good
too. That's somewhere you often find people using jet.

FYI the notebook isn't working for me in IPython 2.2.0

I agree with Michael's sentiment that from a marketing perspective, a
matplotlib-only colormap is advantageous to maintain a consistent brand.

Will these colormaps also be used for non-imshow/colormesh/pcolormesh data,
as in for line colors as well? I think that's a great idea! It'll make the
black and white versions easier to understand since the changing colors
will monotonically increase/decrease in darkness rather than randomly
changing.

RE: Nathaniel - I'm not as much of a fan of changing line styles in
addition to colors, but that's my personal preference for plotting lines
specifically. When plotting scatters, I think it does make sense, since the
room to perceive a change in color is so small, that a change in shape
helps too.

On Wed Feb 18 2015 at 9:40:00 AM Michael Waskom <mw...@st...>
wrote:

> 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 :)
>
> (But I do think it's worth distinguishing the matplotlib default from the
> matlab default.)
>
> Michael
> ------------------------------------------------------------
> ------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Feb 16, 2015 3:39 PM, "Eric Firing" <ef...@ha...> 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.

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 ;-)