matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] Unavoidable gridlines in pcolor pdf output

[Jouni K. S. <jk...@ik...>]

Eric Firing <ef...@ha...> writes:

>> A different approach would be to output a raster image from pcolor and
>> render it with large pixels. I don't know how well that would work with
>> Agg, though.
>>
> I don't understand; wouldn't this wreck accuracy and defeat the purpose 
> of using pdf (scalability)?

I meant the same thing that happens when you do imshow(image,
interpolation='None') and save as pdf. Each rectangle becomes one pixel
in an embedded raster image object, which is rendered crisply by the
viewer.

Crisply, that is, if the viewer is Adobe Reader, ghostscript or xpdf. 
If you zoom in in Apple's Preview.app, the image looks blurry. But maybe
blurriness in one out of four renderers is better than white lines in
three out of four?

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Re: [matplotlib-devel] Saving animations

[Ryan M. <rm...@gm...>]

On Sun, Apr 8, 2012 at 9:13 AM, Tony Yu <ts...@gm...> wrote:
>
>
> On Sat, Apr 7, 2012 at 8:40 PM, Benjamin Root <ben...@ou...> wrote:
>>
>>
>>
>> On Sat, Apr 7, 2012 at 1:34 PM, Tony Yu <ts...@gm...> wrote:
>>>
>>> I've been using the animations subpackage since it was introduced, but I
>>> only recently tried to save an animation using the `save` method.
>>> Unfortnately, I get a RuntimeError whenever I try to use it:
>>>
>>> ...
>>>   File
>>> "/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_agg.py", line
>>> 4
>>> 52, in print_raw
>>>     renderer._renderer.write_rgba(filename_or_obj)
>>> RuntimeError: Error writing to file

It shouldn't be OS-dependent. In fact, as I keep being told "OSX is
practically unix!". (Sorry, I just get tired of being told that and
then having simple unix functionality fail spectacularly. I'm
better...I swear.)

Would it be possible to try the mencoder support instead? (If it's
possible to get that installed). Also, could you try the ffmpeg_file
"backend" which uses the temp files? It will be helpful to try to
narrow down whether the piping itself is making it angry or if
something is wrong with ffmpeg. You should just be able to do:

anim.save(..., writer='ffmpeg_file') or anim.save(..., writer='mencoder')

Also, can you run any/all of them with --verbose-debug? That might
help give a bit more error information.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Re: [matplotlib-devel] Unavoidable gridlines in pcolor pdf output

[Eric F. <ef...@ha...>]

On 04/09/2012 09:25 AM, Michael Gilbert wrote:
> On Mon, Apr 9, 2012 at 1:43 PM, Eric Firing<ef...@ha...>  wrote:
>>> Making the polygons overlap by one pdf unit (1/72 of an inch) seems to
>>> make the lines go away at least in Preview. Making them overlap by 0.1
>>> units does not help.
>>
>> Does it make them go away with alpha = 0.5, say?
>
> Setting alpha 0.5 didn't help.  It made the contours more transparent
> as expected, but the unwanted lines remain yet with the same amount of
> transparency.

Sorry, my point was that even if the 1/72 overlap "works" with some 
viewers with alpha = 1, I would expect it to cause trouble with non-unit 
alpha, with some if not with all viewers. I don't think there is any 
hack that works in general, and a 1/72 overlap sounds to me like a hack.

Eric

>
> Best wishes,
> Mike
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Unavoidable gridlines in pcolor pdf output

[Michael G. <mic...@gm...>]

On Mon, Apr 9, 2012 at 1:43 PM, Eric Firing <ef...@ha...> wrote:
>> Making the polygons overlap by one pdf unit (1/72 of an inch) seems to
>> make the lines go away at least in Preview. Making them overlap by 0.1
>> units does not help.
>
> Does it make them go away with alpha = 0.5, say?

Setting alpha 0.5 didn't help.  It made the contours more transparent
as expected, but the unwanted lines remain yet with the same amount of
transparency.

Best wishes,
Mike

Re: [matplotlib-devel] Unavoidable gridlines in pcolor pdf output

[Eric F. <ef...@ha...>]

On 04/09/2012 04:13 AM, Jouni K. Seppänen wrote:
> Benjamin Root<ben...@ou...>  writes:
>
>>> It seems that savig a pcolor plot to a pdf format always includes
>>> gridlines, which isn't true for other output formats like png.  The
>>> attached example demonstrates this problem.  I've only tested this on
>>> version 1.1.1rc1.
>>
>> I have reported something like this before, and it seems that it is
>> dependent upon the PDF viewer and i's settings.  Particularly, the
>> antialiasing settings.  I have seen this with gs-based viewers. Have you
>> tried others?
>
> I see gridlines in the resulting image in gs, xpdf Preview.app but not
> in Adobe Reader. When I zoom in Preview, the lines jump around a bit,
> and are always the same width on the screen regardless of zoom level.
>
> What gets drawn in this example is a lot of polygons, so that adjacent
> polygons share an edge with the exact same coordinates. The code fills
> the inside of each polygon, and apparently some rendering algorithms
> leave a minimal-width line between polygons.
>
> Making the polygons overlap by one pdf unit (1/72 of an inch) seems to
> make the lines go away at least in Preview. Making them overlap by 0.1
> units does not help.

Does it make them go away with alpha = 0.5, say?

>
> I don't think this can be fixed purely in the pdf backend; it just gets
> a path collection and draws each polygon. I suppose pcolor would need to
> pad the polygons a little, but could it cause problems with other
> backends or use cases? (E.g. if you use alpha blending, neighboring
> rectangles might get gridlines of a darker color where they overlap.)

I'm very skeptical about attempted workarounds such as padding; I would 
be amazed if any of them work over the full range of cases--backends, 
alpha, antialiasing, viewers--while maintaining accuracy of plot element 
placement.

Has cairo solved this problem?  Anyone else?

>
> I wonder if drawing zero-width lines between neighboring rectangles,
> e.g. taking the color always from the left or the upper rectangle, would
> work. In matplotlib a line of zero width means no line at all, but in
> the pdf file format it means a line of the smallest possible width,
> which might work well for filling in a missing line of that same
> width. This would need some kind of special-casing in the graphics
> context (because linewidth=0 means to not draw a line) so it's not
> completely trivial to try it out.

Problems occur not just with rectangles but with all patch boundaries, 
such as in contourf.  The problem may be most severe with rectangles, 
though.

We have gone around in circles with this problem before.

>
> A different approach would be to output a raster image from pcolor and
> render it with large pixels. I don't know how well that would work with
> Agg, though.
>
I don't understand; wouldn't this wreck accuracy and defeat the purpose 
of using pdf (scalability)?

Eric

Re: [matplotlib-devel] Unavoidable gridlines in pcolor pdf output

[Jouni K. S. <jk...@ik...>]

Benjamin Root <ben...@ou...> writes:

>> It seems that savig a pcolor plot to a pdf format always includes
>> gridlines, which isn't true for other output formats like png.  The
>> attached example demonstrates this problem.  I've only tested this on
>> version 1.1.1rc1.
>
> I have reported something like this before, and it seems that it is
> dependent upon the PDF viewer and i's settings.  Particularly, the
> antialiasing settings.  I have seen this with gs-based viewers. Have you
> tried others?

I see gridlines in the resulting image in gs, xpdf Preview.app but not
in Adobe Reader. When I zoom in Preview, the lines jump around a bit,
and are always the same width on the screen regardless of zoom level.

What gets drawn in this example is a lot of polygons, so that adjacent
polygons share an edge with the exact same coordinates. The code fills
the inside of each polygon, and apparently some rendering algorithms
leave a minimal-width line between polygons.

Making the polygons overlap by one pdf unit (1/72 of an inch) seems to
make the lines go away at least in Preview. Making them overlap by 0.1
units does not help.

I don't think this can be fixed purely in the pdf backend; it just gets
a path collection and draws each polygon. I suppose pcolor would need to
pad the polygons a little, but could it cause problems with other
backends or use cases? (E.g. if you use alpha blending, neighboring
rectangles might get gridlines of a darker color where they overlap.)

I wonder if drawing zero-width lines between neighboring rectangles,
e.g. taking the color always from the left or the upper rectangle, would
work. In matplotlib a line of zero width means no line at all, but in
the pdf file format it means a line of the smallest possible width,
which might work well for filling in a missing line of that same
width. This would need some kind of special-casing in the graphics
context (because linewidth=0 means to not draw a line) so it's not
completely trivial to try it out.

A different approach would be to output a raster image from pcolor and
render it with large pixels. I don't know how well that would work with
Agg, though.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Re: [matplotlib-devel] Saving animations

[Tony Yu <ts...@gm...>]

On Sat, Apr 7, 2012 at 8:40 PM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Sat, Apr 7, 2012 at 1:34 PM, Tony Yu <ts...@gm...> wrote:
>
>> I've been using the animations subpackage since it was introduced, but I
>> only recently tried to save an animation using the `save` method.
>> Unfortnately, I get a RuntimeError whenever I try to use it:
>>
>> ...
>>   File
>> "/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_agg.py", line
>> 4
>> 52, in print_raw
>>     renderer._renderer.write_rgba(filename_or_obj)
>> RuntimeError: Error writing to file
>>
>>
>> This can be reproduced with any animation example, e.g. simple_anim.py<http://matplotlib.sourceforge.net/examples/animation/simple_anim.html>, by
>> replacing `plt.show()` with `ani.save('simple_anim.avi')`. The actual error
>> is from a shell call to ffmpeg, which roughly boils down to:
>>
>> #~~~~
>>     import subprocess
>>     import matplotlib.pyplot as plt
>>
>>     fig, ax = plt.subplots()
>>     ax.plot([0, 1])
>>     command = ['ffmpeg', '-f', 'rawvideo', '-vcodec', 'rawvideo',
>>                '-s', '800x600', '-pix_fmt', 'rgba', '-r', '5.0',
>>                '-i', 'pipe:', '-vcodec', 'mpeg4', '-y', 'test.avi']
>>     proc= subprocess.Popen(command, shell=False, stdout=subprocess.PIPE,
>>                            stderr=subprocess.STDOUT,
>> stdin=subprocess.PIPE)
>>     fileobj = proc.stdin
>>     fig.savefig(fileobj, format='rgba', dpi=100)
>> #~~~~
>>
>> (I just copied the ffmpeg command from an example run, so the option
>> values may vary on other systems.) The error here is the same, and,
>> unfortunately, not very informative. Is this saving functionality platform
>> dependent? (I'm on osx.)
>>
>> Thanks,
>> -Tony
>>
>>
> Tony,
>
> The animation saving feature has be completely rewritten by Ryan recently
> and is in master.  Could you give that a try?
>
> Ben Root
>
> Hey Ben,

This is error is using the current master, actually. I think the previous
implementation saved images and read them with ffmpeg (or some other
utility) instead of piping directly to ffmpeg.

-Tony

(Ben: sorry for the duplicate emails. Forgot to "reply-all")

Re: [matplotlib-devel] Saving animations

[Benjamin R. <ben...@ou...>]

On Sat, Apr 7, 2012 at 1:34 PM, Tony Yu <ts...@gm...> wrote:

> I've been using the animations subpackage since it was introduced, but I
> only recently tried to save an animation using the `save` method.
> Unfortnately, I get a RuntimeError whenever I try to use it:
>
> ...
>   File
> "/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_agg.py", line
> 4
> 52, in print_raw
>     renderer._renderer.write_rgba(filename_or_obj)
> RuntimeError: Error writing to file
>
>
> This can be reproduced with any animation example, e.g. simple_anim.py<http://matplotlib.sourceforge.net/examples/animation/simple_anim.html>, by
> replacing `plt.show()` with `ani.save('simple_anim.avi')`. The actual error
> is from a shell call to ffmpeg, which roughly boils down to:
>
> #~~~~
>     import subprocess
>     import matplotlib.pyplot as plt
>
>     fig, ax = plt.subplots()
>     ax.plot([0, 1])
>     command = ['ffmpeg', '-f', 'rawvideo', '-vcodec', 'rawvideo',
>                '-s', '800x600', '-pix_fmt', 'rgba', '-r', '5.0',
>                '-i', 'pipe:', '-vcodec', 'mpeg4', '-y', 'test.avi']
>     proc= subprocess.Popen(command, shell=False, stdout=subprocess.PIPE,
>                            stderr=subprocess.STDOUT, stdin=subprocess.PIPE)
>     fileobj = proc.stdin
>     fig.savefig(fileobj, format='rgba', dpi=100)
> #~~~~
>
> (I just copied the ffmpeg command from an example run, so the option
> values may vary on other systems.) The error here is the same, and,
> unfortunately, not very informative. Is this saving functionality platform
> dependent? (I'm on osx.)
>
> Thanks,
> -Tony
>
>
Tony,

The animation saving feature has be completely rewritten by Ryan recently
and is in master.  Could you give that a try?

Ben Root

[matplotlib-devel] Saving animations

[Tony Yu <ts...@gm...>]

I've been using the animations subpackage since it was introduced, but I
only recently tried to save an animation using the `save` method.
Unfortnately, I get a RuntimeError whenever I try to use it:

...
  File
"/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_agg.py", line
4
52, in print_raw
    renderer._renderer.write_rgba(filename_or_obj)
RuntimeError: Error writing to file


This can be reproduced with any animation example, e.g.
simple_anim.py<http://matplotlib.sourceforge.net/examples/animation/simple_anim.html>,
by
replacing `plt.show()` with `ani.save('simple_anim.avi')`. The actual error
is from a shell call to ffmpeg, which roughly boils down to:

#~~~~
    import subprocess
    import matplotlib.pyplot as plt

    fig, ax = plt.subplots()
    ax.plot([0, 1])
    command = ['ffmpeg', '-f', 'rawvideo', '-vcodec', 'rawvideo',
               '-s', '800x600', '-pix_fmt', 'rgba', '-r', '5.0',
               '-i', 'pipe:', '-vcodec', 'mpeg4', '-y', 'test.avi']
    proc= subprocess.Popen(command, shell=False, stdout=subprocess.PIPE,
                           stderr=subprocess.STDOUT, stdin=subprocess.PIPE)
    fileobj = proc.stdin
    fig.savefig(fileobj, format='rgba', dpi=100)
#~~~~

(I just copied the ffmpeg command from an example run, so the option values
may vary on other systems.) The error here is the same, and, unfortunately,
not very informative. Is this saving functionality platform dependent? (I'm
on osx.)

Thanks,
-Tony

[matplotlib-devel] PATCH: Accept color/alpha in imsave

[Jostein Bø F. <jos...@gm...>]

I've had problems saving MxNx3 (RGB) numpy arrays as images using
imsave. It fails with an exception, and the problem seems to be line
1243 in image.py:

figsize = [x / float(dpi) for x in arr.shape[::-1]]

The purpose of arr.shape[::-1] seems to be to reorder the height and
width dimensions. It works as intended for MxN arrays, but not NxMx3
arrays -- they cause a function to complain about an argument too
many.

I have modified the above line to use (arr.shape[1], arr.shape[0])
instead of arr.shape[::-1], and that solves the problem for me, and I
get the output I expect (and the code still passes all tests it should
pass). However, there could very well be subtleties in the codebase
that I don't know about.

The attached patches add a simple test case, the above mentioned
change and a few updates to the documentation of imsave.

Best,

Jostein.

Re: [matplotlib-devel] Unavoidable gridlines in pcolor pdf output

[Benjamin R. <ben...@ou...>]

On Friday, April 6, 2012, Michael Gilbert wrote:

> Hi,
>
> It seems that savig a pcolor plot to a pdf format always includes
> gridlines, which isn't true for other output formats like png.  The
> attached example demonstrates this problem.  I've only tested this on
> version 1.1.1rc1.
>
> Thanks,
> Mike
>

I have reported something like this before, and it seems that it is
dependent upon the PDF viewer and i's settings.  Particularly, the
antialiasing settings.  I have seen this with gs-based viewers. Have you
tried others?

Ben Root

Re: [matplotlib-devel] 1.1.1rc RuntimeError: underlying C/C++ object has been deleted

[Benjamin R. <ben...@ou...>]

On Wed, Mar 28, 2012 at 2:36 PM, John Hunter <jd...@gm...> wrote:

>
>
> On Wed, Mar 28, 2012 at 1:22 PM, Neal Becker <ndb...@gm...> wrote:
>
>>
>> > import matplotlib
>> > matplotlib.use('pdf')
>> >
>> > It looks like you are inadvertently importing the qt library in a
>> headless
>> > script run.
>> >
>> > JDH
>>
>> Thanks, but should that cause a (scary looking) error?  Or is there a real
>> problem?
>>
>>
>> It's just a clean up error in the qt destructors I  think.  You are
> basically in an unsupported use case: using a gui backend, but not raising
> the figures with show, so our initialization code doesn't get run properly,
> which means the clean up may not be properly configured.  Our work is hard
> enough supporting all the GUI toolkits across multiple operating systems --
> I don't know that we want to get into trying to support *unsupported* use
> cases.
>
> JDH
>
>
True that this is probably an unsupported use-case, but I don't see it as a
totally unreasonable one.  For example, in many of my scripts in one of my
projects, I have command-line options to determine if I am going to save
the figure to a file and another option to determine if I am going to show
the figure as well.  I could run these scripts with or without showing a
figure.  By the time I process the command-line arguments, I have already
imported matplotlib.  Of course, it isn't very difficult to recode it to
import and select a backend according to the command-line arguments, it
would be a more convoluted script that way.

Note, I have not noticed any issues with this approach while using TkAgg
and GTKAgg.  I guess it could probably be made into a low-priority TODO
item in PyQt4 to see if the destructor is being over-zealous.  Neal, your
best bet would be to file a wishlist item and tag it as such.  Again, low
priority, but maybe someone will notice something obvious at a later time.

Cheers!
Ben Root

[matplotlib-devel] Drawing arbitrary Axis on a plot

[Phil E. <phi...@ho...>]

Before I dive too far down a rabbit hole, I wanted to sound out a few
questions related to adding custom Axis & associated gridlines to a
plot.


I want to be able to put an arbitrary axis on top of a plot in some
other projection (a simple, but not necessarily useful example, is a
pair Cartesian axes at the centre of a polar plot).
Some of my requirements are:

 * The Axis should represent a known transform, without the transform
necessarily being transData (a non-affine transformation from the
former to the latter is known).

 * The Axis is likely to be curved, and gridlines will not always
reach the edges of the background patch (I appreciate that the fact
that the gridlines not always crossing the background patch makes it
harder to identify the domain of the required Axis and accept that it
may be necessary to provide some additional information to help this
case).

 * The API should be consistent with standard mpl Axis objects (i.e.
Locators, Formatters, and all the expected control of
colour/visibility/size etc.) although access to the Axis itself is
understandably going to be different (i.e. I do not expect
ax.get_xaxis() to work).

 * Features such as interactive zooming + panning should be supported.

 * The Axis should be happy to live on Axes subclasses (e.g. Polar)
and "clip" the labels in the appropriate place according to the given
Axes/background-patch (in much the same way that AxisArtist can with a
rectilinear plot).

 * For bonus points the Axis should be able to break into multiple
lines/spines after transformation (see example 5 below for an example
of this), although this is very much a nice to have.



As far as I can see the AxisArtist toolkit is my best hope, although I
am concerned that it does not sit well with some of my requirements
(consistency of API; Axes subclass support; using transforms directly;
some bugs with non-rectilinear gridlines;).



I haven't thought about these issues in too much detail so there are
probably a whole host of problems that I have over-simplified/missed.
To aid discussion some concrete examples which demonstrate the kind of
thing that I am trying to achieve:

 #1. Putting a "latitude" (y) axis on a Robinson map
(http://en.wikipedia.org/wiki/Robinson_projection) at -180 degrees
longitude and a "longitude" (x) axis on the same map at 0 degrees
latitude.

 #2. Putting a "longitude" (x) axis on a Robinson map which follows
the top and bottom "edge"/spine.

 #3. Putting a "latitude" (y) axis on an Azimuthal equidistant map
(http://en.wikipedia.org/wiki/Azimuthal_equidistant_projection) at 0
degrees longitude and a "longitude" (x) axis on the equator (0 degrees
latitude). [Note: because of zooming, it is possible that 0 degrees
longitude may never be visible, in which case draw along the nearest
edge to the 0 degrees longitude line]

 #4. Putting a "longitude" (x) axis on the outside edge of an
Azimuthal equidistant map (arbitrary zooming is allowed, hence the
"edge" may be any shape. It is sufficient to imagine it as a half
circle representing the western hemisphere).

 #5. Putting a "longitude" (x) axis on a Goode homolosine map
(http://en.wikipedia.org/wiki/Goode_homolosine_projection) at -60
latitude. (this is an example of the bonus problem of splitting the
axis artists into multiple lines where appropriate!).

It appears to me that these examples are tangible, and I am fairly
confident I could draw them on a piece of paper, which suggests that
they might be achievable programatically.



I guess the questions I'm asking are:

 * Is there a silver bullet which gives me this functionality already?
 * If not, are my requirements so far away from matplotlib.axis.Axis /
AxisArtist that I need to consider implementing my own "Axis" artist?
 * Have I missed something which makes this a far harder problem than
I am describing?


I would like to get a discussion going on this topic, so would really
appreciate posts from anyone with any insight, prior experience,
similar problems or simply general thoughts on the matter.

Many thanks in advance,

Re: [matplotlib-devel] soliciting feedback on proposed user survey

[Paul I. <piv...@gm...>]

Ok, added a question about backends. Hopefully I didn't miss one.

Which backends do you use? (check all that apply, note that there is a
"I don't know. What's a backend?" option)

    Agg
    Cairo
    FLTKAgg
    GDK
    GTK
    GTKAgg
    GTKCairo
    macosx
    PDF
    PS
    QTAgg
    QT4Agg
    SVG
    TkAgg
    WX
    WXAgg
    I don't know. What's a backend?

-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

[matplotlib-devel] Inconsistent naming of legend points

[Pim S. <P.S...@as...>]

Dear all,

there is an inconsistency in the naming of the variable that describes
the number of points to display in the legend.
For `plt.plot` and `plt.errorbar` it is called "numpoints" but for
`plt.scatter` it is called "scatterpoints".
It would be less confusing if both could be set with a simple
"numpoints" in the legend function.
Please let me know what you think.

Kind regards,

Pim Schellart

Re: [matplotlib-devel] soliciting feedback on proposed user survey

[Benjamin R. <ben...@ou...>]

On Thursday, March 29, 2012, Michael Droettboom wrote:

> This is a great idea.  A question that might be worth adding is what
> backends are being used.  I'd be interested to find out which ones are
> most heavily used.
>
> A related question (though I don't know how easy it would be to be
> complete on) would be what plot types are used.
>
> Thanks for doing this!
>
> Mike


For the backend question, add a "don't know (what's a backend?)" option.
 Maybe ask about which mpl_toolkits that get used, (axes_grid1, mplot3d,
Basemap, etc)?

Ben Root

P.S. - No, I am not really back, just have free wifi today at this hotel
and some down time. I have no clue when my new place will get Internet
turned on.

Re: [matplotlib-devel] soliciting feedback on proposed user survey

[Michael D. <md...@st...>]

This is a great idea.  A question that might be worth adding is what 
backends are being used.  I'd be interested to find out which ones are 
most heavily used.

A related question (though I don't know how easy it would be to be 
complete on) would be what plot types are used.

Thanks for doing this!

Mike

On 03/28/2012 08:27 PM, Paul Ivanov wrote:
> Paul Ivanov, on 2012-03-28 17:22,  wrote:
>> Hey everyone,
>>
>> with 1.1.1 just around the corner, I thought it'd be nice to put
>> together an MPL user survey, similar to what Thomas Kluyver
>> organized for IPython last year [1].
>>
>> Here's what I've got so far [2], and here's the response one gets
>> upon filling out the form:
>>
>> -----
>> Thanks for your feedback.
>>
>> As promised, here are the details of how to do various things:
>>
>> the official documentation is at:
>>      http://matplotlib.sourceforge.net/
>>
>> to run the test suite:
>>      python -c "import matplotlib; matplotlib.test()"
>>
>> file bug reports and submit pull requests here:
>>      https://github.com/matplotlib/matplotlib
>>
>> to post to the matplotlib-users list, subscribe here:
>>      https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> -----
>>
>> with an additional link at the bottom to look at the summary of previous
>> respondents, which looks like [3].
>>
>> How does this look to everyone? Any changes before I distribute
>> this more widely? (Preferably not just via list, but also add a
>> link to it on the main page, which is what IPython folks also did
>> for a while).
>>
>> 1. http://ipython.org/usersurvey2011.html
>> 2. https://docs.google.com/spreadsheet/viewform?formkey=dHpQS25pcTZIRWdqX0pNckNSU01sMHc6MQ
>> 3. https://docs.google.com/spreadsheet/viewanalytics?formkey=dHpQS25pcTZIRWdqX0pNckNSU01sMHc6MQ
> Me again, just decided to inline the survey text, so that
> suggestions can be more readily made here, without having to
> following links, etc.
>
>
> matplotlib user survey 2012
>
> Stand up and be counted, matplotlib developers want to hear from you! All
> questions are optional, we look forward to your feedback.
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> What country are you from? [                    ]
>
> How long have you been using matplotlib?
>
>    • (*) about a month
>    • ( )<  6 months
>    • ( ) about a year
>    • ( ) 2 to 4 years
>    • ( ) more than 4 years
>
>
> What operating system do you run matplotlib on? (check all that apply)
>
>    • [ ] *BSD (FreeBSD, NetBSD, OpenBSD, etc)
>    • [ ] GNU/Linux (Ubuntu, Debian, Fedora, RHEL, OpenSUSE, Arch, Gentoo, etc)
>    • [ ] Mac OS X
>    • [ ] Windows
>    • [ ] Other: [                    ]
>
>
> What version of python do you use matplotlib on? (check all that apply)
>
>    • [ ] 2.4
>    • [ ] 2.5
>    • [ ] 2.6
>    • [ ] 2.7
>    • [ ] 3.0
>    • [ ] 3.1
>    • [ ] 3.2
>
>
> You use matplotlib for: (check all that apply)
>
>    • [ ] Academic development (research, publication graphics, etc.)
>    • [ ] Commercial development
>    • [ ] Personal hobby / recreationally
>
>
> You *primarily* use matplotlib for: (check all that apply)
>
>    • ( ) Academic development (research, publication graphics, etc.)
>    • ( ) Commercial development
>    • ( ) Personal hobby / recreationally
>
>
> How do you use matplotlib?
> [                                                                           ]
> [                                                                           ]
> [                                                                           ]
>
> How frequently do you *RUN* code which uses matplotlib?
>
>    • ( ) daily
>    • ( ) a few times per week
>    • ( ) a few times per month
>    • ( ) less frequently
>
>
> How frequently do you *WRITE* code which uses matplotlib?
>
>    • ( ) daily
>    • ( ) a few times per week
>    • ( ) a few times per month
>    • ( ) less frequently
>
>
> For the matplotlib project, do you know how to ... (check all that apply,
> you'll get all the answers after you hit the submit button)
>
>    • [ ] locate and navigate the official documentation
>    • [ ] run the test suite
>    • [ ] file bug reports on GitHub
>    • [ ] post to the matplotlib-users list
>    • [ ] submit patches / pull requests
>
>
> In the past year, have you... (check all that apply)
>
>    • [ ] accessed the official documentation
>    • [ ] run the test suite
>    • [ ] filed a bug report on GitHub
>    • [ ] posted to the matplotlib-users list
>    • [ ] submitted a patch / pull request
>
>
> How do you get matplotlib on your machine? (check all that apply)
>
>    • [ ] compile and install directly from source (zip / tarball / git checkout)
>    • [ ] use official packages provided by matplotlib team
>    • [ ] use packages provided by my operating system (.deb, .rpm, ports, etc)
>    • [ ] Enthought Python Distribution (EPD) http://enthought.com/products/epd.php
>    • [ ] Python(X,Y) http://code.google.com/p/pythonxy/
>    • [ ] Sage http://sagemath.org/
>    • [ ] Other: [                    ]
>
>
> What other plotting libraries do you use and why?
> [                                                                           ]
> [                                                                           ]
> [                                                                           ]
>
> How would you like matplotlib to improve in the future?
> [                                                                           ]
> [                                                                           ]
> [                                                                           ]
>
> best,

Re: [matplotlib-devel] soliciting feedback on proposed user survey

[Paul I. <piv...@gm...>]

Paul Ivanov, on 2012-03-28 17:22,  wrote:
> Hey everyone,
> 
> with 1.1.1 just around the corner, I thought it'd be nice to put
> together an MPL user survey, similar to what Thomas Kluyver
> organized for IPython last year [1].
> 
> Here's what I've got so far [2], and here's the response one gets
> upon filling out the form:
> 
> -----
> Thanks for your feedback.
> 
> As promised, here are the details of how to do various things:
> 
> the official documentation is at: 
>     http://matplotlib.sourceforge.net/
> 
> to run the test suite:
>     python -c "import matplotlib; matplotlib.test()"
> 
> file bug reports and submit pull requests here: 
>     https://github.com/matplotlib/matplotlib
> 
> to post to the matplotlib-users list, subscribe here:
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> -----
> 
> with an additional link at the bottom to look at the summary of previous
> respondents, which looks like [3].
> 
> How does this look to everyone? Any changes before I distribute
> this more widely? (Preferably not just via list, but also add a
> link to it on the main page, which is what IPython folks also did
> for a while).
> 
> 1. http://ipython.org/usersurvey2011.html
> 2. https://docs.google.com/spreadsheet/viewform?formkey=dHpQS25pcTZIRWdqX0pNckNSU01sMHc6MQ
> 3. https://docs.google.com/spreadsheet/viewanalytics?formkey=dHpQS25pcTZIRWdqX0pNckNSU01sMHc6MQ

Me again, just decided to inline the survey text, so that
suggestions can be more readily made here, without having to
following links, etc.


matplotlib user survey 2012

Stand up and be counted, matplotlib developers want to hear from you! All
questions are optional, we look forward to your feedback.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

What country are you from? [                    ]

How long have you been using matplotlib?

  • (*) about a month
  • ( ) < 6 months
  • ( ) about a year
  • ( ) 2 to 4 years
  • ( ) more than 4 years


What operating system do you run matplotlib on? (check all that apply)

  • [ ] *BSD (FreeBSD, NetBSD, OpenBSD, etc)
  • [ ] GNU/Linux (Ubuntu, Debian, Fedora, RHEL, OpenSUSE, Arch, Gentoo, etc)
  • [ ] Mac OS X
  • [ ] Windows
  • [ ] Other: [                    ]


What version of python do you use matplotlib on? (check all that apply)

  • [ ] 2.4
  • [ ] 2.5
  • [ ] 2.6
  • [ ] 2.7
  • [ ] 3.0
  • [ ] 3.1
  • [ ] 3.2


You use matplotlib for: (check all that apply)

  • [ ] Academic development (research, publication graphics, etc.)
  • [ ] Commercial development
  • [ ] Personal hobby / recreationally


You *primarily* use matplotlib for: (check all that apply)

  • ( ) Academic development (research, publication graphics, etc.)
  • ( ) Commercial development
  • ( ) Personal hobby / recreationally


How do you use matplotlib? 
[                                                                           ]
[                                                                           ]
[                                                                           ]

How frequently do you *RUN* code which uses matplotlib?

  • ( ) daily
  • ( ) a few times per week
  • ( ) a few times per month
  • ( ) less frequently


How frequently do you *WRITE* code which uses matplotlib?

  • ( ) daily
  • ( ) a few times per week
  • ( ) a few times per month
  • ( ) less frequently


For the matplotlib project, do you know how to ... (check all that apply,
you'll get all the answers after you hit the submit button)

  • [ ] locate and navigate the official documentation
  • [ ] run the test suite
  • [ ] file bug reports on GitHub
  • [ ] post to the matplotlib-users list
  • [ ] submit patches / pull requests


In the past year, have you... (check all that apply)

  • [ ] accessed the official documentation
  • [ ] run the test suite
  • [ ] filed a bug report on GitHub
  • [ ] posted to the matplotlib-users list
  • [ ] submitted a patch / pull request


How do you get matplotlib on your machine? (check all that apply)

  • [ ] compile and install directly from source (zip / tarball / git checkout)
  • [ ] use official packages provided by matplotlib team
  • [ ] use packages provided by my operating system (.deb, .rpm, ports, etc)
  • [ ] Enthought Python Distribution (EPD) http://enthought.com/products/epd.php
  • [ ] Python(X,Y) http://code.google.com/p/pythonxy/
  • [ ] Sage http://sagemath.org/
  • [ ] Other: [                    ]


What other plotting libraries do you use and why? 
[                                                                           ]
[                                                                           ]
[                                                                           ]

How would you like matplotlib to improve in the future? 
[                                                                           ]
[                                                                           ]
[                                                                           ]

best,
-- 
Paul Ivanov
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

[matplotlib-devel] soliciting feedback on proposed user survey

[Paul I. <piv...@gm...>]

Hey everyone,

with 1.1.1 just around the corner, I thought it'd be nice to put
together an MPL user survey, similar to what Thomas Kluyver
organized for IPython last year [1].

Here's what I've got so far [2], and here's the response one gets
upon filling out the form:

-----
Thanks for your feedback.

As promised, here are the details of how to do various things:

the official documentation is at: 
    http://matplotlib.sourceforge.net/

to run the test suite:
    python -c "import matplotlib; matplotlib.test()"

file bug reports and submit pull requests here: 
    https://github.com/matplotlib/matplotlib

to post to the matplotlib-users list, subscribe here:
    https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-----

with an additional link at the bottom to look at the summary of previous
respondents, which looks like [3].

How does this look to everyone? Any changes before I distribute
this more widely? (Preferably not just via list, but also add a
link to it on the main page, which is what IPython folks also did
for a while).

1. http://ipython.org/usersurvey2011.html
2. https://docs.google.com/spreadsheet/viewform?formkey=dHpQS25pcTZIRWdqX0pNckNSU01sMHc6MQ
3. https://docs.google.com/spreadsheet/viewanalytics?formkey=dHpQS25pcTZIRWdqX0pNckNSU01sMHc6MQ

best,
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

Re: [matplotlib-devel] 1.1.1rc RuntimeError: underlying C/C++ object has been deleted

[John H. <jd...@gm...>]

On Wed, Mar 28, 2012 at 1:22 PM, Neal Becker <ndb...@gm...> wrote:

>
> > import matplotlib
> > matplotlib.use('pdf')
> >
> > It looks like you are inadvertently importing the qt library in a
> headless
> > script run.
> >
> > JDH
>
> Thanks, but should that cause a (scary looking) error?  Or is there a real
> problem?
>
>
> It's just a clean up error in the qt destructors I  think.  You are
basically in an unsupported use case: using a gui backend, but not raising
the figures with show, so our initialization code doesn't get run properly,
which means the clean up may not be properly configured.  Our work is hard
enough supporting all the GUI toolkits across multiple operating systems --
I don't know that we want to get into trying to support *unsupported* use
cases.

JDH

Re: [matplotlib-devel] 1.1.1rc RuntimeError: underlying C/C++ object has been deleted

[Neal B. <ndb...@gm...>]

John Hunter wrote:

> On Wed, Mar 28, 2012 at 8:57 AM, Neal Becker
> <ndb...@gm...> wrote:
> 
>> qt-x11-4.8.0-7.fc16.x86_64
>> PyQt4-4.8.6-1.fc16.x86_64
>>
>> But interestingly, I'm not actually using the display in this script.  I'm
>> using
>> pdfpages.
> 
> 
> At the beginning of your script (before importing pylab/pyplot) you should
> be doing
> 
> import matplotlib
> matplotlib.use('pdf')
> 
> It looks like you are inadvertently importing the qt library in a headless
> script run.
> 
> JDH

Thanks, but should that cause a (scary looking) error?  Or is there a real 
problem?

Re: [matplotlib-devel] 1.1.1rc RuntimeError: underlying C/C++ object has been deleted

[John H. <jd...@gm...>]

On Wed, Mar 28, 2012 at 8:57 AM, Neal Becker <ndb...@gm...> wrote:

> qt-x11-4.8.0-7.fc16.x86_64
> PyQt4-4.8.6-1.fc16.x86_64
>
> But interestingly, I'm not actually using the display in this script.  I'm
> using
> pdfpages.


At the beginning of your script (before importing pylab/pyplot) you should
be doing

import matplotlib
matplotlib.use('pdf')

It looks like you are inadvertently importing the qt library in a headless
script run.

JDH

Re: [matplotlib-devel] 1.1.1rc RuntimeError: underlying C/C++ object has been deleted

[Neal B. <ndb...@gm...>]

qt-x11-4.8.0-7.fc16.x86_64
PyQt4-4.8.6-1.fc16.x86_64

But interestingly, I'm not actually using the display in this script.  I'm using 
pdfpages.

The basic outline is:
At the start:

        from matplotlib.backends.backend_pdf import PdfPages
        self.pdf = PdfPages(file_name)

Then at the start of each page I do:
        self.prop = mpl.font_manager.FontProperties(size='xx-small')

        self.fig = fig = plt.figure() 
        self.ax = fig.add_subplot(111)
        fig.subplots_adjust(bottom=0.2)
        self.colors = itertools.cycle(['r','g','b','c','y','m','k']) 
        self.markers = itertools.cycle(['o','s','v']) 

Then at the start of each plot on a page I do:
        
	self.ax.semilogy (esno, [e for e in per], c=self.colors.next(), 
marker=self.markers.next(), label='iter=%s'%n_iter)

Finally, to finish each page:

        plt.title (...)
        plt.grid(which='major', linestyle='solid')
        plt.grid(which='minor', linestyle='dashed')
        plt.legend(prop=self.prop, loc='best')
        self.ax.set_xlabel ('${E_s}/N_0$')
        self.ax.set_ylabel ('per')
        plt.figtext (0, 0, res['carriers'].values, horizontalalignment='left', 
verticalalignment='bottom', size=5)
        self.pdf.savefig (self.fig)
        plt.close()

Then when all pages are done:
        self.pdf.close()

It looks like I'm getting one of these error messages for each page.


Michael Droettboom wrote:

> Can you provide more detail about how to reproduce this?
> 
> I can deduce you're using the Qt4Agg backend -- but running
> simple_plot.py, zooming around, and then closing the window does not
> seem to reproduce the error here.
> 
> What version of Qt/PyQt/PySide are you running.  What platform?
> 
> Mike
> 
> On 03/28/2012 08:34 AM, Neal Becker wrote:
>> I'm getting these messages, which did not occur with 1.1:
>>
>> Traceback (most recent call last):
>>    File "/home/nbecker/.local/lib/python2.7/site-
>> packages/matplotlib/backends/backend_qt4.py", line 151, in<lambda>
>>      lambda: self.close_event())
>>    File "/home/nbecker/.local/lib/python2.7/site-
>> packages/matplotlib/backend_bases.py", line 1564, in close_event
>>      self.callbacks.process(s, event)
>> RuntimeError: underlying C/C++ object has been deleted
>>
>>
>> 
------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure

Re: [matplotlib-devel] 1.1.1rc RuntimeError: underlying C/C++ object has been deleted

[Michael D. <md...@st...>]

Can you provide more detail about how to reproduce this?

I can deduce you're using the Qt4Agg backend -- but running 
simple_plot.py, zooming around, and then closing the window does not 
seem to reproduce the error here.

What version of Qt/PyQt/PySide are you running.  What platform?

Mike

On 03/28/2012 08:34 AM, Neal Becker wrote:
> I'm getting these messages, which did not occur with 1.1:
>
> Traceback (most recent call last):
>    File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/backends/backend_qt4.py", line 151, in<lambda>
>      lambda: self.close_event())
>    File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/backend_bases.py", line 1564, in close_event
>      self.callbacks.process(s, event)
> RuntimeError: underlying C/C++ object has been deleted
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.1.1rc does not fix tight_layout for figtext?

[Neal B. <ndb...@gm...>]

If I have to manually add room, I guess I might as well just keep using this, 
which I had used with version 1.1:

fig.subplots_adjust(bottom=0.2)

Jae-Joon Lee wrote:

> I'm afraid that, unfortunately, it won't be fixed soon (if ever, as
> far as I can tell).
> What "tight_layout" does is to adjust the *subplot parameters* of the
> figure so that the "subplots" fit in. Artists created with figtext
> command is not affected by the subplot parameters, i.e. there is not
> much thing we can do for these artists within the current
> implementation. It would be better if some warning is printed in such
> case (there are lots of cases that tight_layout will fail), but this
> is not currently done.
> 
> Depending on your need, you may leave out some area for figtext when
> you call "tight_layout". This is only supported for gridspec though.
> 
> import matplotlib.pyplot as plt
> import matplotlib.gridspec as gridspec
> 
> fig = plt.figure()
> 
> gs1 = gridspec.GridSpec(2, 2)
> ax_list = [fig.add_subplot(ss) for ss in gs1]
> 
> fig.text (02, 0, "test", horizontalalignment='left',
>           verticalalignment='bottom', size=5)
> fig.text (0.5, 1, "01", horizontalalignment='left',
>           verticalalignment='top', size='x-small')
> 
> gs1.tight_layout(fig, rect=[0, 0.03, 1, 0.97]) # adjust rect parameter
> to make some room for figtext.
> 
> 
> Regards,
> 
> -JJ
> 
> 
> On Wed, Mar 28, 2012 at 9:17 PM, Neal Becker <ndb...@gm...> wrote:
>> I just tried 1.1.1rc to see if it fixed the tight_layout for figtext.
>>
>> I have a semilogy plot, and add  some lines of text on the bottom (and top):
>>
>> plt.figtext (0, 0, res['carriers'].values, horizontalalignment='left',
>> verticalalignment='bottom', size=5)
>> plt.figtext (0.5, 1, self.pageno, horizontalalignment='left',
>> verticalalignment='top', size='x-small')
>> ##plt.tight_layout(pad=1.0)
>> plt.tight_layout()
>>
>> The text on the bottom is overprinting the x axis - the same as happened 
>> with the previous release.
>>
>>
>> 
------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel