matplotlib-users Mailing List for matplotlib

I have a colleague experiencing similar issues. There seem to be known issues with PySide 1.1.0, e.g.,

http://bugs.pyside.org/show_bug.cgi?id=1119

I tried overriding the call to QApplication.setOverrideCursor(), which customizes the cursor within the Matplotlib navigation toolbar, but he then encountered another Shiboken-related segfault. It has been very frustrating, so I would be interested if anyone has a solution before the PySide team issues another release.

Ray

On Mar 24, 2012, at 1:10 PM, Wes McKinney wrote:

> Has anyone had much luck with PySide + matplotlib 1.1.0+? With stock
> EPD 7.2 full on Ubuntu 10.04 which comes with PySide 1.1.0, a simple
> plot like plot(arange(10)) with IPython in pylab mode causes a
> segfault. Joy.
> 
> Thanks,
> Wes
> 
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 
Ray Osborn
Materials Science Division
Argonne National Laboratory
Argonne, IL 60439, USA
Phone: +1 (630) 252-9011
Email: RO...@an...

Has anyone had much luck with PySide + matplotlib 1.1.0+? With stock
EPD 7.2 full on Ubuntu 10.04 which comes with PySide 1.1.0, a simple
plot like plot(arange(10)) with IPython in pylab mode causes a
segfault. Joy.

Thanks,
Wes

A while ago I had exactly the same problem. I was running a script that 
create a lot of figures and saved them (as .png and .eps files) for 
viewing later (so not using the interactive viewing feature from 
pyplot). If I remember well, there was also a problem with the close() 
statement leaving some stuff in memory. Unfortunately I don't remember 
how the details went and how it got fixed. I guess I should have used 
the mailing list or created a bug report.

Anyway, when I need to generate a massive amount of figures these days I 
bypass the pyplot interface completely and go straight for the 
matplotlib API (at least as far as I understand this approach myself). 
When using pyplot, some figure tweaks did not persist upon saving, but 
that might as well have been due to my limited matplotlib knowledge. The 
procedure was inspired by this blog post: 
http://sjohannes.wordpress.com/2010/06/11/using-matplotlib-in-a-web-application/ 
and goes as follows:

from matplotlib.figure import Figure
# dependent on the backend you use
from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as 
FigCanvas
# set figure size, dpi and initiate a workable fig object
fig = Figure(figsize=(figsize_x, figsize_y), dpi=dpi)
canvas = FigCanvas(fig)
fig.set_canvas(canvas)
# tweak white spacings
fig.subplots_adjust(left=wsleft, bottom=wsbottom, right=wsright,
top=wstop, wspace=wspace, hspace=hspace)
# big main title
fig.suptitle(grandtitle, size='x-large')
# create a subplot
ax = fig.add_subplot(nr_rows, nr_cols, plot_nr)

# do all your plotting stuff here on ax

# save the figure and close
fig.savefig('/path/to/figure/figname.png')
canvas.close()
fig.clear()

If interested, I can give you a more elaborate and working example of 
which parameters I tune how exactly.

Regards,
David




On 23/03/12 19:45, Eric Firing wrote:
> On 03/23/2012 08:05 AM, Albert Kottke wrote:
>> I am having problems clearing figures from memory. After saving the
>> figure, I use pyplot.close() on the figure handle and then del all of
>> the data and figure, as shown here:
>>
>> fig.savefig('plots/%(record_id)05i' % recording)
>> plt.close(fig)
>>
>> del accel, fourier_amp, fig, time, disp
>> gc.collect()
>>
>> Despite this, the figures don't appear to be closing. I am trying to
>> make 30k plots and I have to kill script every couple thousand and
>> restart because I run out of memory.
>>
>> Any suggestions?
> You are running a standalone script, correct?  Make sure you are using
> only the agg backend.  Before the first import of pyplot, do
>
> import matplotlib
> matplotlib.use("agg")
>
> I don't know if that will help, but it can't hurt.
>
> You might find matplotlib.cbook.report_memory() to be useful in tracking
> down the problem.
>
> Eric
>
>>
>> Albert
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Fri, Mar 23, 2012 at 3:35 PM, Andrew Smart <and...@gm...>wrote:

> Hi,
> I'm running into this RuntimeError: Could not open facefile
> c:\Python32\lib\site-packages\matplotlib\mpl-data\fonts\ttf\Vera.ttf;
> Cannot_Open_Resource when I'm trying to save out a series of *.png files in
> a loop. It crashes on this error after many passes through the loop and
> successful files get created, but then always on the same pass it does
> this. The full traceback is here:
>
> I wonder if the solution is as simple as doing font caching at the class
level rather than instance level.  Andrew, could you try editing
matplotlib/backends/backend_agg.py and replace

class RendererAgg(RendererBase):
    """
    The renderer handles all the drawing primitives using a graphics
    context instance that controls the colors/styles
    """
    debug=1
    def __init__(self, width, height, dpi):
        if __debug__: verbose.report('RendererAgg.__init__',
'debug-annoying')
        RendererBase.__init__(self)
        self.texd = maxdict(50)  # a cache of tex image rasters
        self._fontd = maxdict(50)

with

class RendererAgg(RendererBase):
    """
    The renderer handles all the drawing primitives using a graphics
    context instance that controls the colors/styles
    """
    debug=1
    _fontd = maxdict(50)
    texd = maxdict(50)  # a cache of tex image rasters
    def __init__(self, width, height, dpi):
        if __debug__: verbose.report('RendererAgg.__init__',
'debug-annoying')
        RendererBase.__init__(self)


Does anyone see an issue with doing this caching at the class level?  If
this works, we should have *many* fewer font files parsed.

w/o modifying the src code, a related way to test this idea is to reuse the
same figure instance and clear it at the start of the loop.  Ie, rather than

for i in range(N):
    fig = plt.figure()
    ....plot_something
    fig.savefig(...)

do


fig = plt.figure()
for i in range(N):
    fig.clf()
    ....plot_something
    fig.savefig(...)

I would try the latter first, and if that works I would appreciate it if
you test the src code modification unless someone chimes in and tells us
that is a really bad idea.

JDH