matplotlib-devel Mailing List for matplotlib

Hi Folks,
I can't seem to find Ken McIvor -- Ken are you here?
Anyway, here's a tiny patch of wxMPL to make it work with wxPython 2.9
-- the only change is here, around line 1126:
 ## the following changed according to Robin Dunn's advice for 2.9
 ## -- but it probably wasn't working right before!
 #topwin.Connect(wx.ID_ANY, self.GetId(), wx.wxEVT_ACTIVATE,
self.OnActivate)
 topwin.Connect(self.GetId(), wx.ID_ANY, wx.wxEVT_ACTIVATE,
self.OnActivate)
This change works fine with wxPython2.8, also.
Attached is the whole file.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R      (206) 526-6959  voice
7600 Sand Point Way NE  (206) 526-6329  fax
Seattle, WA 98115    (206) 526-6317  main reception
Chr...@no...

Hi,
In the last couple of days, the daily builds on Launchpad have been
choking on the docs. They get to "reading sources... [ 91%]
faq/howto_faq", then seemingly lock up until the queue manager aborts
the build. It claims there's 2h30 of inactivity before that happens,
so it looks like something really is wrong.
Example build log:
https://launchpadlibrarian.net/102978621/buildlog_ubuntu-precise-i386.matplotlib_1.1.0%2B6017%2B10%7Eprecise1_FAILEDTOBUILD.txt.gz
It appears to be this big commit which broke it (unless it was an
external factor like some change to Sphinx):
https://github.com/matplotlib/matplotlib/commit/76665d059523cf0b89695570dc311ce8b50d4a4b
Has anyone else seen this, or do you have any ideas what might be causing it?
Thanks,
Thomas
P.S. Apologies to anyone getting this twice.

On Tue, Apr 24, 2012 at 7:49 AM, Mike Kaufman <mc...@gm...> wrote:
> If mew=0, then the caps on errorbars are not drawn regardless of the
> setting of the "capsize" option. I don't think this should be the
> behavior, it certainly caught me off guard, since I had mew=0 set in
> rcParams.
>
> This is present as of 5b499f0180befea04fab7bfda17ba3ad7cf2380e
> (Mar 22nd master)
>
> M
>
>
This is indeed confusing and I have been meaning to do something about this
for a while now (yet another item in my todo list...). Keep in mind that
there is actually no discrepancy. The marker is turned onto its side. So
the marker edge width parameter actually effects the cap's thickness. So,
having a finite capsize, but a zero thickness should result in no cap being
drawn.
But it is totally unintuitive that mew should have anything to do with the
cap thickness and what should be done is introduce a new kwarg "capthick"
or "capheight" and eventually have it completely replace the responsibility
of mew in errorbars.
Ben Root

On Thu, Apr 19, 2012 at 3:04 AM, Jae-Joon Lee <lee...@gm...> wrote:
> I think what we may do is to make the default value of "scatterponts"
> to None, and if None, set it to the value of numpoints.
> But, I want to hear how others think about it.
>
> Regards,
>
> -JJ
>
>
I think that would be reasonable. And maybe put "scatterpoints" onto a
deprecation path?
Cheers!
Ben Root

yep, it works. Thanks for fixing it so quickly!
On 23.04.2012 23:34, Michael Droettboom wrote:
> Git bisect shows that this was introduced in f57dddc20625. Looking at
> the github comments for that commit:
>
> https://github.com/matplotlib/matplotlib/commit/f57dddc20625809436956675d23b09baddcc9e0e
>
>
> strange enough the problem and solution are already discussed, it just
> seems the solution never made it in.
>
> This should now be fixed in 48c31f7ff660
>
> Mike
>

If mew=0, then the caps on errorbars are not drawn regardless of the 
setting of the "capsize" option. I don't think this should be the 
behavior, it certainly caught me off guard, since I had mew=0 set in 
rcParams.
This is present as of 5b499f0180befea04fab7bfda17ba3ad7cf2380e
(Mar 22nd master)
M

Git bisect shows that this was introduced in f57dddc20625. Looking at 
the github comments for that commit:
https://github.com/matplotlib/matplotlib/commit/f57dddc20625809436956675d23b09baddcc9e0e
strange enough the problem and solution are already discussed, it just 
seems the solution never made it in.
This should now be fixed in 48c31f7ff660
Mike
On 04/23/2012 10:33 AM, Detlef Maurel wrote:
> Hi all,
>
> there is a problem in the font display in the newest trunk version of 
> matplotlib (git rev. 76665d059523cf)
>
> I ran a clean installation and the test script. You can see in the 
> attachment that the fonts are somehow screwed up. It seems to depend 
> on the graphics backend. In the screenshot, the title is broken. In 
> the png output, only the axis labels are broken. In the pdf, 
> everything looks fine.
>
> It looks like this bug has been introduced after tag v1.1.0 (I 
> switched back to the tag and the fonts look fine there).
>
> If you want me to run further tests, please let me know.
>
>
> Detlef
>
>
> ------------------------------------------------------------------------------
> 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

Hi all,
there is a problem in the font display in the newest trunk version of 
matplotlib (git rev. 76665d059523cf)
I ran a clean installation and the test script. You can see in the 
attachment that the fonts are somehow screwed up. It seems to depend on 
the graphics backend. In the screenshot, the title is broken. In the png 
output, only the axis labels are broken. In the pdf, everything looks fine.
It looks like this bug has been introduced after tag v1.1.0 (I switched 
back to the tag and the fonts look fine there).
If you want me to run further tests, please let me know.
Detlef

Yes, I am only a user not a developer.
the different names make me confused at the beginning, it's only last night
I realised this
after more than 1 years use of matplotlib.
New beginners would be less confused if a unified name is used.
Chao
2012年4月19日 Jae-Joon Lee <lee...@gm...>
> I think what we may do is to make the default value of "scatterponts"
> to None, and if None, set it to the value of numpoints.
> But, I want to hear how others think about it.
>
> Regards,
>
> -JJ
>
>
>
> On Fri, Mar 30, 2012 at 11:39 PM, Pim Schellart <P.S...@as...>
> wrote:
> > 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
> >
> >
> ------------------------------------------------------------------------------
> > 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
>
>
> ------------------------------------------------------------------------------
> 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
>
-- 
***********************************************************************************
Chao YUE
Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
UMR 1572 CEA-CNRS-UVSQ
Batiment 712 - Pe 119
91191 GIF Sur YVETTE Cedex
Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
************************************************************************************

I think what we may do is to make the default value of "scatterponts"
to None, and if None, set it to the value of numpoints.
But, I want to hear how others think about it.
Regards,
-JJ
On Fri, Mar 30, 2012 at 11:39 PM, Pim Schellart <P.S...@as...> wrote:
> 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
>
> ------------------------------------------------------------------------------
> 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

Ben,
That sounds great, especially regarding the test images. I don't know
how the image comparison tests work, that's why I kept it very
fundamental.
Thanks!
Jostein.
Den 14:59 17. april 2012 skrev Benjamin Root <ben...@ou...> følgende:
>
>
> On Tue, Apr 17, 2012 at 3:30 AM, Jostein Bø Fløystad
> <jos...@gm...> wrote:
>>
>> Hi Benjamin,
>>
>> and thanks for looking into this. The traceback you showed in your
>> post is the original one that I see before applying the second patch.
>> After applying the second patch, I do not see this traceback any more,
>> and I get the results I expect. In other words, I'm unable to
>> reproduce the behaviour you get (with the patches applied to current
>> master). Would it be possible for you to send the code in quickshow.py
>> that triggers this behaviour?
>>
>> You seemed uncertain that you had the full patch. The second patch
>> only changes a single line of code, namely line 1243 of image.py. An
>> excerpt of the patch:
>>
>> -  figsize = [x / float(dpi) for x in arr.shape[::-1]]
>> +  figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>>
>> For me, this is enough to make imshow work for MxNx3 (or 4).
>>
>> Cheers,
>>
>> Jostein.
>>
>
> Josten,
>
> Sorry for the noise. I forgot to install the patched version of mpl. Your
> second patch certainly does fix the bug and should be committed. As for the
> first patch that has the test, I think it would be better to actually create
> some test data and test image. I am working on creating such a test set for
> a related bug in imshow() and imsave(). Once I do that, I can make a pull
> request that can include both our patches.
>
> Cheers!
> Ben Root
>

On Tue, Apr 17, 2012 at 3:30 AM, Jostein Bø Fløystad <
jos...@gm...> wrote:
> Hi Benjamin,
>
> and thanks for looking into this. The traceback you showed in your
> post is the original one that I see before applying the second patch.
> After applying the second patch, I do not see this traceback any more,
> and I get the results I expect. In other words, I'm unable to
> reproduce the behaviour you get (with the patches applied to current
> master). Would it be possible for you to send the code in quickshow.py
> that triggers this behaviour?
>
> You seemed uncertain that you had the full patch. The second patch
> only changes a single line of code, namely line 1243 of image.py. An
> excerpt of the patch:
>
> - figsize = [x / float(dpi) for x in arr.shape[::-1]]
> + figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]
>
> For me, this is enough to make imshow work for MxNx3 (or 4).
>
> Cheers,
>
> Jostein.
>
>
Josten,
Sorry for the noise. I forgot to install the patched version of mpl. Your
second patch certainly does fix the bug and should be committed. As for
the first patch that has the test, I think it would be better to actually
create some test data and test image. I am working on creating such a test
set for a related bug in imshow() and imsave(). Once I do that, I can make
a pull request that can include both our patches.
Cheers!
Ben Root

On 16 April 2012 23:36, Damon McDougall <D.M...@wa...> wrote:
> On Monday, 16 April 2012 at 16:34, Kacper Kowalik wrote:
>
>
> On 16 Apr 2012 22:31, "Damon McDougall" <D.M...@wa...> wrote:
> >
> > Hi Kacper,
> >
> > Just to be clear, is it tri.Triangulation(x, y) that hangs, or is it
> plt.tricontour(...)?
>
> It's plt.tricontour that hangs, tri.Triangulation properly issues warning
> about duplicates.
> Cheers,
> Kacper
>
> > On Monday, 16 April 2012 at 14:28, Kacper Kowalik wrote:
>
> >>
> >> Hi,
> >> I haven't been able to pin point it exactly but following script:
> >>
> >> import matplotlib.pyplot as plt
> >> import matplotlib.tri as tri
> >> import numpy as np
> >> from numpy.random import uniform, seed
> >>
> >> seed(0)
> >> npts = 200
> >> x = uniform(-2,2,npts)
> >> y = uniform(-2,2,npts)
> >> z = x*np.exp(-x**2-y**2)
> >>
> >> y[1:3] = x[0] # 4 or more duplicate points make tricontour hang!!!
> >> x[1:3] = y[0]
>
> You should call z = x*np.exp(-x**2-y**2) _before_ changing the points
> you're triangulating.
> Having said that, I see the same behaviour even if I change the vertices
> before I compute z.
>
> >> triang = tri.Triangulation(x, y)
> >> plt.tricontour(x, y, z, 15, linewidths=0.5, colors='k')
> >>
> >> plt.show()
> >>
> >>
> >> causes infinite loop in _tri.so. It happens in matplotlib-1.1.0 as well
> >> as git HEAD.
> >> I understand that my input is not exactly valid, but I'd rather see MPL
> >> die than occupy my box for eternity ;)
> >> Best regards,
> >> Kacper
>
> I think the reason it's hanging is because you're trying to plot the
> contours of a function that is defined on an invalid triangulation (edges
> cross at points that are not in the vertex set). I think the best way to
> deal with this is to write a helper function to check the triangulation is
> valid. If it isn't, either tri.Triangulation(x, y) should fail, or the
> plotter should fail.
>
> Anybody else have any suggestions?
>
We can definitely do better here. I have created a issue request on github:
https://github.com/matplotlib/matplotlib/issues/838
and will investigate further.
Ian

Hi Benjamin,
and thanks for looking into this. The traceback you showed in your
post is the original one that I see before applying the second patch.
After applying the second patch, I do not see this traceback any more,
and I get the results I expect. In other words, I'm unable to
reproduce the behaviour you get (with the patches applied to current
master). Would it be possible for you to send the code in quickshow.py
that triggers this behaviour?
You seemed uncertain that you had the full patch. The second patch
only changes a single line of code, namely line 1243 of image.py. An
excerpt of the patch:
- figsize = [x / float(dpi) for x in arr.shape[::-1]]
+ figsize = [x / float(dpi) for x in (arr.shape[1], arr.shape[0])]
For me, this is enough to make imshow work for MxNx3 (or 4).
Cheers,
Jostein.
Den 23:00 16. april 2012 skrev Benjamin Root <ben...@ou...> følgende:
>
> On Sat, Apr 7, 2012 at 11:25 AM, Jostein Bø Fløystad
> <jos...@gm...> wrote:
>>
>> 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.
>>
>
> Jostein,
>
> That second patch certain fixes that part of the bug, but I still can't save
> an NxMx3 (or 4) array using imsave(). Are you sure this is all of the
> patch?
>
> I get the following exception:
>
> ```
> Traceback (most recent call last):
>  File "quickshow.py", line 106, in <module>
>   plt.imsave(stem + '.png', cm(d))
>  File
> "/home/broot/.local/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-linux-x86_64.egg/matplotlib/pyplot.py",
> line 1757, in imsave
>   return _imsave(*args, **kwargs)
>  File
> "/home/broot/.local/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-linux-x86_64.egg/matplotlib/image.py",
> line 1244, in imsave
>   fig = Figure(figsize=figsize, dpi=dpi, frameon=False)
>  File
> "/home/broot/.local/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-linux-x86_64.egg/matplotlib/figure.py",
> line 269, in __init__
>   self.bbox_inches = Bbox.from_bounds(0, 0, *figsize)
> TypeError: from_bounds() takes exactly 4 arguments (5 given)
> ```
>
> Cheers!
> Ben Root
>

On Monday, 16 April 2012 at 16:34, Kacper Kowalik wrote:
> 
> On 16 Apr 2012 22:31, "Damon McDougall" <D.M...@wa... (mailto:D.M...@wa...)> wrote:
> >
> > Hi Kacper,
> >
> > Just to be clear, is it tri.Triangulation(x, y) that hangs, or is it plt.tricontour(...)? 
> It's plt.tricontour that hangs, tri.Triangulation properly issues warning about duplicates.
> Cheers,
> Kacper 
> > On Monday, 16 April 2012 at 14:28, Kacper Kowalik wrote:
> >>
> >> Hi,
> >> I haven't been able to pin point it exactly but following script:
> >>
> >> import matplotlib.pyplot as plt
> >> import matplotlib.tri as tri
> >> import numpy as np
> >> from numpy.random import uniform, seed
> >>
> >> seed(0)
> >> npts = 200
> >> x = uniform(-2,2,npts)
> >> y = uniform(-2,2,npts)
> >> z = x*np.exp(-x**2-y**2)
> >>
> >> y[1:3] = x[0] # 4 or more duplicate points make tricontour hang!!!
> >> x[1:3] = y[0]
You should call z = x*np.exp(-x**2-y**2) _before_ changing the points you're triangulating.
Having said that, I see the same behaviour even if I change the vertices before I compute z.
> >> triang = tri.Triangulation(x, y)
> >> plt.tricontour(x, y, z, 15, linewidths=0.5, colors='k')
> >>
> >> plt.show()
> >>
> >>
> >> causes infinite loop in _tri.so. It happens in matplotlib-1.1.0 as well
> >> as git HEAD.
> >> I understand that my input is not exactly valid, but I'd rather see MPL
> >> die than occupy my box for eternity ;)
> >> Best regards,
> >> Kacper
I think the reason it's hanging is because you're trying to plot the contours of a function that is defined on an invalid triangulation (edges cross at points that are not in the vertex set). I think the best way to deal with this is to write a helper function to check the triangulation is valid. If it isn't, either tri.Triangulation(x, y) should fail, or the plotter should fail.
Anybody else have any suggestions?
 
--
Damon McDougall
d.m...@wa... (mailto:d.m...@wa...)
http://damon.is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Thanks to a patch a bit while back for ListedColormap that allowed for
alphas to be given, I should now be able to use imshow() and imsave() with
colormaps. However, I find that the results are not correct. Particularly,
the alpha values seem to be assigned incorrectly. I am still working on
making a stand-alone version to demonstrate the problem, but has anyone
else noticed this?
Note,
plt.imshow(d, cmap=cm)
produces an incorrect result while
plt.imshow(cm(d))
produces a correct result. However, due to a bug in imsave, I can't do the
latter as a work-around.
Thanks,
Ben Root

On Sat, Apr 7, 2012 at 11:25 AM, Jostein Bø Fløystad <
jos...@gm...> wrote:
> 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.
>
>
Jostein,
That second patch certain fixes that part of the bug, but I still can't
save an NxMx3 (or 4) array using imsave(). Are you sure this is all of the
patch?
I get the following exception:
```
Traceback (most recent call last):
 File "quickshow.py", line 106, in <module>
 plt.imsave(stem + '.png', cm(d))
 File
"/home/broot/.local/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-linux-x86_64.egg/matplotlib/pyplot.py",
line 1757, in imsave
 return _imsave(*args, **kwargs)
 File
"/home/broot/.local/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-linux-x86_64.egg/matplotlib/image.py",
line 1244, in imsave
 fig = Figure(figsize=figsize, dpi=dpi, frameon=False)
 File
"/home/broot/.local/lib/python2.7/site-packages/matplotlib-1.2.x-py2.7-linux-x86_64.egg/matplotlib/figure.py",
line 269, in __init__
 self.bbox_inches = Bbox.from_bounds(0, 0, *figsize)
TypeError: from_bounds() takes exactly 4 arguments (5 given)
```
Cheers!
Ben Root

Apologies if you receive this twice - I joined the mailing list with
one address, then posted from another. Mods, feel free to bin the
other copy of the post.
If you want to get more people testing the next version, I've set up a
PPA to build the development version of matplotlib nightly for Ubuntu
Precise. This includes building a Python 3 binary package - so it's
possible to get a basic scientific Python 3 environment without having
to compile anything locally.
Use it at your own risk, because I'm still learning the ropes of
packaging. I've checked that it imports and can display a simple plot.
If you want to improve the packaging stuff, launchpad 'merge
proposals' are welcome:
https://code.launchpad.net/~takluyver/matplotlib/debian-daily
Thanks,
Thomas

I started reading some of Adobe's documentation to find out if there's
something I've overlooked, and noticed that when I read the PDF
Reference in Preview.app, some example images have zoom-dependent
gridlines that look a lot like the output from pcolor. If even Adobe
creates PDF files that have this kind of artifacts, maybe it's a
rendering bug in the other viewers, or possibly the imaging model is
underspecified.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

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

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

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

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

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

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