matplotlib-users Mailing List for matplotlib (Page 9)

I think the savefig() command calls draw() internally, doesn't it?
So, I guess the restore_region() command comes before the draw() call,
i.e., it has no effect for the saved figure.
One way I can think of is to save the agg buffer without redrawing it.
It seems work.


-----------------------

import matplotlib
matplotlib.use('Agg')

import matplotlib.pyplot as plt

fig1 = plt.figure(1)
ax1 = fig1.add_subplot(111)
ax1.grid()
fig1.canvas.draw()
background = fig1.canvas.copy_from_bbox(ax1.bbox)
fig1.savefig('figure1.png')


from matplotlib import _png
from matplotlib.cbook import is_string_like

def print_png(fig, filename_or_obj):
    canvas = fig.canvas
    renderer = canvas.get_renderer()
    if is_string_like(filename_or_obj):
        filename_or_obj = file(filename_or_obj, 'wb')
    _png.write_png(renderer._renderer.buffer_rgba(0, 0),
                   renderer.width, renderer.height,
                   filename_or_obj, canvas.figure.dpi)

fig1.clf()
fig1.canvas.restore_region(background)
print_png(fig1, 'figure2.png')


---------------------------

Somehow, the copy_from_bbox() needs to be called before the savefig().

This is just a quick hacky solution.
But I think it would be nice if we have this kind of functionality in
the mpl, ideally with zorder support. For example,

> ax1.add_background(background, zroder=2)

And, restore_region(background) is called within the draw() method
(with correct zorder).
Just a thought.

IHTH,

-JJ



On Mon, Nov 17, 2008 at 12:37 PM, John Hunter <jd...@gm...> wrote:
> On Mon, Nov 17, 2008 at 8:05 AM, Hrafnkell Pálsson <hr...@hi...> wrote:
>>
>> Hi
>>
>> I tried you suggestions but it didn't work out for me.
>> In the following code I try to save the axes and the grid from figure1 into
>> buffer and then restore it on figure2 but figure2.png turns out to be of an
>> empty canvas.
>>
>> #!/usr/bin/env /opt/python/bin/python
>> # encoding: utf-8
>> import matplotlib
>> if not matplotlib.get_backend()=='agg':
>>    matplotlib.use('Agg')
>> import pylab
>>
>> figure1 = pylab.figure(1)
>> axes1 = pylab.gca()
>> axes1.grid()
>> canvas1 = axes1.figure.canvas
>> background = canvas1.copy_from_bbox(axes1.bbox)
>> figure1.savefig('figure1.png')
>
> The only problem I could see with your code is that you need to force
> a draw before copying the background.  But when I added the draw, and
> then further simplified to reuse the same canvas, I still am not
> seeing the restored region.  I will need to do further digging to see
> what is going wrong, but the problem appears both on the maintenance
> branch and the trunk.  Here is my modified test script:
>
>    import matplotlib
>    matplotlib.use('Agg')
>
>    import matplotlib.pyplot as plt
>
>    fig1 = plt.figure(1)
>    ax1 = fig1.add_subplot(111)
>    ax1.grid()
>    fig1.canvas.draw()
>    fig1.savefig('figure1.png')
>    background = fig1.canvas.copy_from_bbox(ax1.bbox)
>
>    fig1.clf()
>
>
>    #figure2 = pylab.figure(2)
>    #canvas2 = figure2.canvas
>    fig1.canvas.restore_region(background)
>    fig1.savefig('figure2.png')
>
>
> JDH
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I found the last leak exercised by your example.  The window was keeping 
around a reference to the file selector dialog, creating a cyclical 
reference.  Cyclical references containing Gtk objects can not be 
cleaned up by the Python garbage selector.  By creating the file 
selector on-the-fly, it no longer leaks.  I've attached a pretty picture 
for those who like pretty pictures... ;)

My recommendation still stands to use the Agg backend for long-running 
offline batch processes, just for having fewer moving parts if nothing else.

Cheers,
Mike

D2Hitman wrote:
> Mike,
>
> Yes i'm using a more complicated program to batch produce images. Through
> more investigation i think it's not just the close function, any repeat call
> of pylab seems to have similar problem. Thanks for looking into it, i will
> try the Agg backend and see if that works out.
>
> Cheers,
> Jon.
>
>
> Michael Droettboom-3 wrote:
>   
>> I'm not at the bottom of this yet, but thought I'd share my progress so 
>> far -->
>>
>> It is leaking actual Python references (meaning len(gc.get_objects()) is 
>> increasing).  So it's not a malloc/free pair.
>>
>> Seems to be Gtk-specific.  (Both GtkAgg and Gtk).  Other backends are 
>> unaffected (Qt4 has some sort of leak of a much smaller magnitude).
>>
>> The proper way to destroy pygtk objects appears to be a little bit of a 
>> black art.  What's there now was pretty much arrived at by 
>> experimentation and seems very brittle.
>>
>> I know at one point it was working better than it is now.  My next step 
>> will be to try to revert to a state where the leak wasn't so bad.  Given 
>> the architecture of pygtk, I'm not sure it's possible to not leak at all 
>> when creating/destroying windows like this, but we should at least be 
>> able to reduce the leakage.
>>
>> If your use case is just generating a bunch of images in batch, I'd 
>> recommend using the Agg backend, rather than Gtk.  That doesn't leak for 
>> me.  If you really need to be opening and closing this many windows in 
>> succession, then we still don't have a good solution.
>>
>> Mike
>>
>> Michael Droettboom wrote:
>>     
>>> Ok.  Thanks, I'll look into it.  Just wanted to rule out that this 
>>> wasn't the known Gtk memory leak with old versions of Gtk before 
>>> devoting time to it.
>>>
>>> Cheers,
>>> Mike
>>>
>>> Eric Firing wrote:
>>>   
>>>       
>>>> Michael Droettboom wrote:
>>>>     
>>>>         
>>>>> Can you provide more information about the platform and backend that 
>>>>> you are using?
>>>>>       
>>>>>           
>>>> Mike,
>>>>
>>>> I was able to reproduce this with my ubuntu 8.10, gtkagg backend.  I 
>>>> ran  the code via cut and paste with the stock python interpreter, not 
>>>> ipython.  I did not measure the memory use carefully, but used the 
>>>> system monitor to observe memory for that process climbing, maybe 500k 
>>>> per cycle.
>>>>
>>>> Our usual memleak tester shows no problem, however.
>>>>
>>>> Eric
>>>>
>>>>     
>>>>         
>>>>> D2Hitman wrote:
>>>>>       
>>>>>           
>>>>>> I am getting a memory leak when i am using the pylab.close() 
>>>>>> function. I am
>>>>>> running matplotlib-0.98.3. It happens in a very simple script such as:
>>>>>>
>>>>>> #!/usr/bin/python
>>>>>> import time
>>>>>> import pylab
>>>>>>
>>>>>> while True:
>>>>>>     time.sleep(1)
>>>>>>     print 'calling pylab'
>>>>>>     pylab.box()
>>>>>>     pylab.close()
>>>>>>
>>>>>> Every close seems to store megabytes in physical memory. Any idea 
>>>>>> why this
>>>>>> happens?
>>>>>>
>>>>>> Cheers.
>>>>>>
>>>>>>
>>>>>>   
>>>>>>         
>>>>>>             
>>>   
>>>       
>> -- 
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>>     
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hello,

I am having a problem installing matplotlib 0.93.3 from egg on Mac OSX 
10.5.5.  Even though I have numpy 1.2.1 installed in 
/Library/Frameworks/..., the egg insists on using an older version of 
numpy (1.0.4) in /opt/local/lib/python2.5/site-packages (which must have 
been delivered with the OS).  How can I tell the egg where to find the 
proper version of numpy?  Thanks!

-- Jeff

On Mon, Nov 17, 2008 at 8:05 AM, Hrafnkell Pálsson <hr...@hi...> wrote:
>
> Hi
>
> I tried you suggestions but it didn't work out for me.
> In the following code I try to save the axes and the grid from figure1 into
> buffer and then restore it on figure2 but figure2.png turns out to be of an
> empty canvas.
>
> #!/usr/bin/env /opt/python/bin/python
> # encoding: utf-8
> import matplotlib
> if not matplotlib.get_backend()=='agg':
>    matplotlib.use('Agg')
> import pylab
>
> figure1 = pylab.figure(1)
> axes1 = pylab.gca()
> axes1.grid()
> canvas1 = axes1.figure.canvas
> background = canvas1.copy_from_bbox(axes1.bbox)
> figure1.savefig('figure1.png')

The only problem I could see with your code is that you need to force
a draw before copying the background.  But when I added the draw, and
then further simplified to reuse the same canvas, I still am not
seeing the restored region.  I will need to do further digging to see
what is going wrong, but the problem appears both on the maintenance
branch and the trunk.  Here is my modified test script:

    import matplotlib
    matplotlib.use('Agg')

    import matplotlib.pyplot as plt

    fig1 = plt.figure(1)
    ax1 = fig1.add_subplot(111)
    ax1.grid()
    fig1.canvas.draw()
    fig1.savefig('figure1.png')
    background = fig1.canvas.copy_from_bbox(ax1.bbox)

    fig1.clf()


    #figure2 = pylab.figure(2)
    #canvas2 = figure2.canvas
    fig1.canvas.restore_region(background)
    fig1.savefig('figure2.png')


JDH

Hi Folks!

I  created a matplotlib bar chart containing 85 element. Now I'd like to
add a legend -  but when I tired it this way:

plt.legend( (rect1[0], rect2[0],rect3[0]), ('1.00A_res_2.5tol',
'0.50A_res_1.5tol','0.25A_res_1.0tol') )

a huge legend legend covers large parts of my barchart.

Could anybody tell me how to shrink the entire  legend to a smaller size?

Thanks alot!

Hi

I tried you suggestions but it didn't work out for me.
In the following code I try to save the axes and the grid from figure1 into
buffer and then restore it on figure2 but figure2.png turns out to be of an
empty canvas.

#!/usr/bin/env /opt/python/bin/python
# encoding: utf-8
import matplotlib
if not matplotlib.get_backend()=='agg':
    matplotlib.use('Agg')
import pylab

figure1 = pylab.figure(1)
axes1 = pylab.gca()
axes1.grid()
canvas1 = axes1.figure.canvas
background = canvas1.copy_from_bbox(axes1.bbox)
figure1.savefig('figure1.png')

figure2 = pylab.figure(2)
canvas2 = figure2.canvas
canvas2.restore_region(background)
figure2.savefig('figure2.png')

Thanks for your efforts,
Hrafnkell
-- 
View this message in context: http://www.nabble.com/Save-a-plot-background-tp20519596p20539991.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hello,

I already opened a thread which was unfortunately misspelled.

In order to help other users finding this subject I correcr that.

After looking at the hints I received - thanks a lot folks! - I created a sample which works to some extend.

Four questions remain:

1. When I close my application I receive a meesage box.
I have to translate the message box from german so in english the text may differ.
Title: python.exe – Error in application
Text: statement “0x0166b07f” points on memory “0x00000000004”. Read could not be executed in memory.
How to avoid that?

2. When I start my application the crosshair cursor moves but the cursors initial position does not disappear until I leave the axes.

3. I there a better way to update the figure. I have to delete the axes object in order to get my colobar refreshed.

4. If this is found to be a useful sample, who decides whether this sample should be addes to the samples of matplotlib?

Please see the sample below. 

Cheers Reinhard

# -*- coding: UTF-8 -*-
from numpy import arange, sin, pi

import matplotlib

matplotlib.use('WXAgg')
from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg as FigureCanvas
from matplotlib.figure import Figure
from matplotlib.widgets import Cursor, SpanSelector
import pylab

import wx

class ContourFrame(wx.Frame):
    '''
        ContourFrame is a sample showing how to add a Matplotlib Figure to a
        wxPython application.
        It should demonstrate how to use a crosshair cursor to select certain lines 
        or rows in a contour plot.
        
        This frame contains a vertical box sizer holding 
        - The whole content is in sizerMain (m)
        - sizerMain is in posession of sizerVertical (v)
        - in the upper region of sizerVertical resides the Matplotlib figure canvas (C)
          in the lower region FlexGridSizer sizerHorizontal (f)
        - FlexGridSizer sizerHorizontal contains some wx control elements (1, 2, 3, 4, 5, 6)
        
        The sizers are thought to be set as follows
        mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
        m vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv m
        m v                                    v m
        m v CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC v m
        m v CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC v m
        m v CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC v m
        m v                                    v m
        m v ffffffffffffffffffffffffffffffffff v m
        m v f                                f v m
        m v f 11111111 222222222 33333333333 f v m
        m v f 11111111 222222222 33333333333 f v m
        m v f                                f v m
        m v f 44444444 555555555 66666666666 f v m
        m v f 44444444 555555555 66666666666 f v m
        m v f                                f v m
        m v ffffffffffffffffffffffffffffffffff v m
        m vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv m
        mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
    '''
    
        
    def __init__(self):
        '''
        construktor of frame object
        '''
        # 1. Call the constructor of the parent class
        wx.Frame.__init__(self, None, -1, 'contour sample with cursor') #, size=(655, 630))
        # create the wx status bar
        self.statusbar = self.CreateStatusBar()
        # Divide the status into three field.
        self.statusbar.SetFieldsCount(3)
        self.statusbar.SetStatusWidths([-1, -2, -3])
        self.statusbar.SetStatusText("Current Position:", 0)
        
        # 2. Lets create some data for contouring utilizing pylab functions (stolen from contourf_demo.py)
        delta = 0.025
        x = y = arange(-3.0, 3.01, delta)
        self.X, self.Y = pylab.meshgrid(x, y)
        Z1 = pylab.bivariate_normal(self.X, self.Y, 1.0, 1.0, 0.0, 0.0)
        Z2 = pylab.bivariate_normal(self.X, self.Y, 1.5, 0.5, 1, 1)
        self.Z = 10 * (Z1 - Z2)
        # these values are updated by the sliders
        self.factor = 1.0
        self.addon = 0.0 
        
        # 3. All the matplotlib stuff is done in the following lines. In the end we are in possession of
        #    a FigureCanvas which we can add to a sizer just like a widget.
        # the matplotlib-figure object
        self.figure = Figure() 
        # the matplotlib-axes object is obviously created here
        self.axes = self.figure.add_subplot(111)
        # annotations found in some web-sample
        # Red, Bold, 12pt
        self.axes.set_title('A contour plot generated with contourf', color='r', fontweight='bold', fontsize=12)
        # Green, `smaller' size
        self.axes.set_xlabel('This is the x axis', color='g', fontstyle='oblique', fontsize='greater')
        # Italic
        self.axes.set_ylabel('This is the x axis', color='b',fontstyle='italic')
        # method contourf of the axes objects also stolen from contourf_demo.py
        self.contourf = self.axes.contourf(self.X, self.Y, (self.factor * self.Z + self.addon),
                            cmap=pylab.cm.jet) 
                        
        self.colorbar = self.figure.colorbar(self.contourf, orientation='horizontal')
        # create a FigureCanvas which belongs to our frame and contains our figure object
        self.canvas = FigureCanvas(self, -1, self.figure)
        self.canvas.draw()
        self.cursor = Cursor(self.axes, useblit=True, color='red', linewidth=2 )
        # use the Matplotlib bind functionality to bind the cursor move
        self.canvas.mpl_connect('motion_notify_event', self.onmousemove)
        
        # 4. Now we are doing the wxpython user interface
        # the mainpanel holds all widgets
        self.mainpanel = wx.Panel(self, -1)
        # Lets create a control element - sliderMultiply
        self.sliderMultiply = wx.Slider(self.mainpanel, 100, 1.0, -5.0, 5.0, pos=(10, 10), size=(305, -1),
                                style=wx.SL_HORIZONTAL | wx.SL_AUTOTICKS | wx.SL_LABELS )
        self.sliderMultiply.SetTickFreq(5, 1)
        self.sliderMultiplyName = wx.StaticText (self.mainpanel, -1, 'multiply matrix with') 
        # and another control element sliderAdd
        self.sliderAdd = wx.Slider(self.mainpanel, 100, 0.0, -10.0, 10.0, pos=(10, 10), size=(305, -1),
                                style=wx.SL_HORIZONTAL | wx.SL_AUTOTICKS | wx.SL_LABELS )
        self.sliderAdd.SetTickFreq(5, 1)
        self.sliderAddName = wx.StaticText (self.mainpanel, -1, 'add matrix with') 
        
        # Checkboxes ae used to control the visibility of the crosshair cusor
        self.CheckBoxHorizontalCursor = wx.CheckBox(self.mainpanel, -1, "horizontal Cursor") 
        self.CheckBoxHorizontalCursor.SetValue(True)
        self.CheckBoxVerticalCursor = wx.CheckBox(self.mainpanel, -1, "vertical Cursor") 
        self.CheckBoxVerticalCursor.SetValue(True)
        
        # Bind the wx GUI events
        # Trigger when a slider or scrollbar change is finished  - All sliders and scrollbars are 
        # controlled by one bind. This is marvellous but thats the way it works.
        self.Bind(wx.EVT_SCROLL_ENDSCROLL, self.OnScroll)
        self.Bind(wx.EVT_CHECKBOX, self.OnCheckBoxHorizontalCursor, self.CheckBoxHorizontalCursor)
        self.Bind(wx.EVT_CHECKBOX, self.OnCheckBoxVerticalCursor, self.CheckBoxVerticalCursor)
        
        # Now we add the wx controls to a FlexGridSizer named sizerHorizontal
        self.sizerHorizontal = wx.FlexGridSizer(rows=2, cols=3, hgap=0, vgap=0)
        self.sizerHorizontal.Add(self.CheckBoxHorizontalCursor, 0, wx.ALL | wx.ALIGN_CENTER_HORIZONTAL | wx.ALIGN_TOP | wx.GROW, 10)
        self.sizerHorizontal.Add(self.sliderMultiplyName, 0, wx.ALIGN_CENTER )
        self.sizerHorizontal.Add(self.sliderAddName, 0, wx.ALIGN_CENTER)
        self.sizerHorizontal.Add(self.CheckBoxVerticalCursor, 0, wx.ALL | wx.ALIGN_CENTER_HORIZONTAL | wx.ALIGN_TOP | wx.GROW, 10)
        self.sizerHorizontal.Add(self.sliderMultiply, 0, wx.ALL | wx.ALIGN_CENTER_HORIZONTAL | wx.ALIGN_TOP | wx.GROW, 10)
        self.sizerHorizontal.Add(self.sliderAdd, 0, wx.ALL | wx.ALIGN_CENTER_HORIZONTAL | wx.ALIGN_TOP | wx.GROW, 10)
        # We add the matplotlib canvas and the horizontal sizer to a vertical BoxSizer
        self.sizerVertical = wx.BoxSizer(wx.VERTICAL)
        self.sizerVertical.Add(self.canvas, 0, wx.LEFT | wx.BOTTOM | wx.GROW)
        self.sizerVertical.Add(self.sizerHorizontal, 0, wx.GROW | wx.ALIGN_CENTER_HORIZONTAL)
        # the vertical BoxSizer belongs to the main panel
        self.mainpanel.SetSizer(self.sizerVertical)
        self.sizerVertical.Fit(self.mainpanel)
        self.sizerMain = wx.BoxSizer(wx.VERTICAL)
        # create sizerMain which holds all the stuff and fit our frame 
        self.sizerMain.Add(self.sizerVertical)
        self.SetSizer(self.sizerMain)
        self.Fit()

    def OnScroll(self, evt):
        # take the slider value
        self.factor = float(self.sliderMultiply.GetValue())
        self.addon = float(self.sliderAdd.GetValue())
        # clear the figure or delete the axes - I did not find an update for the color bar so I 
        # create everything again after clearing or deleting  it
        #self.figure.clf()
        self.figure.delaxes(self.axes)
        # Once again do all the axes stuff
        # the matplotlib-axes object is obviously created here
        self.axes = self.figure.add_subplot(111)
        # annotations found in some web-sample
        # Red, Bold, 12pt
        self.axes.set_title('A contour plot generated with contourf', color='r', fontweight='bold', fontsize=12)
        # Green, `smaller' size
        self.axes.set_xlabel('This is the x axis', color='g', fontstyle='oblique', fontsize='greater')
        # Italic
        self.axes.set_ylabel('This is the x axis', color='b',fontstyle='italic')
        self.contour = self.axes.contourf(self.X, self.Y, (self.factor * self.Z + self.addon))
        self.contourf = self.axes.contourf(self.X, self.Y, (self.factor * self.Z + self.addon),
                            cmap=pylab.cm.jet) 
        self.colorbar = self.figure.colorbar(self.contourf, orientation='horizontal')
        self.cursor = Cursor(self.axes, useblit=True, color='red', linewidth=2 )
        self.canvas.draw()

    def OnCheckBoxHorizontalCursor(self,event):
        # Show or hide the horizontal cursor
        boolHorizontalCursor = self.CheckBoxHorizontalCursor.GetValue()
        if boolHorizontalCursor == True:
            self.cursor.horizOn = True
        else:
            self.cursor.horizOn = False
        
    def OnCheckBoxVerticalCursor(self,event):
        # Show or hide the vertical cursor
        boolVerticalCursor = self.CheckBoxVerticalCursor.GetValue()
        if boolVerticalCursor == True:
            self.cursor.vertOn = True
        else:
            self.cursor.vertOn = False


    def onmousemove(self,event):
        # the cursor position is given in the wx status bar
        self.figure.gca()
        if event.inaxes:
            x, y = event.xdata, event.ydata
            self.statusbar.SetStatusText("x = %.2f" %x, 1)
            self.statusbar.SetStatusText("y = %.2f" %y, 2)

        
class App(wx.App):

    def OnInit(self):
        # 'Create the main window and insert the custom frame'
        frame = ContourFrame()
        frame.Show(True)

        return True

app = App(0)
app.MainLoop()

On Sun, Nov 16, 2008 at 9:26 PM, Joshua J. Kugler <jo...@ee...> wrote:

>> w/o seeing the code that generated the figure it is hard to know, but
>> the "bold look" probably arises from rendering the same tick labels
>> twice in the same location, eg if you have a twinx, as it appears you
>> do, but haven't made the ticks invisible (as per my earlier
>> suggestion) on one of the axes.  Perhaps we should make the ticks on
>> the "twin" axes invisible by default.
>
> Yup, that was it.  Woohoo! Thanks!

Great -- glad that worked.  Perhaps we should fix the default behavior though...

> Weird, in my mailer (K-Mail) I replied to my message, and it threaded it
> properly when it came back.  Maybe adding modifying the subject messed
> up some mailers?  I think K-Kmail threads based on the references in
> the headers, e.g.:


OK, my bad.  It's looks like it is just gmail that is mucking it up
(maybe other readers as well).  nabble is ggeting it right:

  http://www.nabble.com/Twin-axes-share-Formatters%2C-but-not-ticks-to20532903.html

No worries -- just wanted to make sure you were aware of the issue,
and it appears you are more on top of it than me :-)

JDH

On Sun, Nov 16, 2008 at 8:32 PM, B Clowers <clo...@ya...> wrote:
> I've been trying to set the linestyle of an ellipse with no success.  I keep
> getting an attribute error whether I try setting the property via accessing
> the ellipse instance directly or through the artist.  Any ideas?
>
> --if you uncomment the line containing the linestyle you should see the
> error--just paste into ipython -pylab.

The example with the ls='dashed' uncommented works fine for me in svn
head, and according to the CHANGELOG, support for linestyle was added
in

  r5645 | jdh2358 | 2008-06-23 09:46:13 -0500 (Mon, 23 Jun 2008) | 1 line

  commited olle's linestyle patch patch

This predates the 0.98.3 release, which was released at svn r5947.
I'm not sure what version you are on, but "linestyle" should work on
the latest mpl release.  If you are having trouble with "ls" on
0.98.3, see if "linestyle" works since it's possible support for the
alias was only added later.

 JDH

On Sunday 16 November 2008, John Hunter said something like:
> On Sun, Nov 16, 2008 at 8:38 PM, Joshua J. Kugler 
<jo...@ee...> wrote:
> > I am leaning toward this being a true bug.  If you take a look at
> > attached plot (the code for which is where I first noticed this
> > bug), you'll notice that the dates on the top graph (the one with
> > two axis) look a little "bold" while the dates on the bottom graph
> > look "normal." The top set of dates are the one where I have to let
> > font size (8) on two different sets of tick labels.
>
> w/o seeing the code that generated the figure it is hard to know, but
> the "bold look" probably arises from rendering the same tick labels
> twice in the same location, eg if you have a twinx, as it appears you
> do, but haven't made the ticks invisible (as per my earlier
> suggestion) on one of the axes.  Perhaps we should make the ticks on
> the "twin" axes invisible by default.

Yup, that was it.  Woohoo! Thanks!

> Also, when posting continuations related to a theme, eg your previous
> post on twin axes formatters, please try to keep them in the same
> thread by "replying" to yourself in the earlier thread.  This makes
> it easier for people following the thread to see everything in one
> place, particularly those using threaded mail readers, as well as the
> future generations of googlers who will pick this conversation up on
> mail archive websites like nabble.

Weird, in my mailer (K-Mail) I replied to my message, and it threaded it 
properly when it came back.  Maybe adding modifying the subject messed 
up some mailers?  I think K-Kmail threads based on the references in 
the headers, e.g.:

References: <200...@ee...>
	<200...@ee...>

And other mailers thread on subject, which might mess them up?  At any 
rate, sorry for glitching some people's mailers!

j

-- 
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/  ID 0xDB26D7CE

On Sun, Nov 16, 2008 at 8:38 PM, Joshua J. Kugler <jo...@ee...> wrote:
> I am leaning toward this being a true bug.  If you take a look at
> attached plot (the code for which is where I first noticed this bug),
> you'll notice that the dates on the top graph (the one with two axis)
> look a little "bold" while the dates on the bottom graph look "normal."
> The top set of dates are the one where I have to let font size (8) on
> two different sets of tick labels.

w/o seeing the code that generated the figure it is hard to know, but
the "bold look" probably arises from rendering the same tick labels
twice in the same location, eg if you have a twinx, as it appears you
do, but haven't made the ticks invisible (as per my earlier
suggestion) on one of the axes.  Perhaps we should make the ticks on
the "twin" axes invisible by default.

Also, when posting continuations related to a theme, eg your previous
post on twin axes formatters, please try to keep them in the same
thread by "replying" to yourself in the earlier thread.  This makes it
easier for people following the thread to see everything in one place,
particularly those using threaded mail readers, as well as the future
generations of googlers who will pick this conversation up on mail
archive websites like nabble.

Thanks,
JDH

On Sunday 16 November 2008, John Hunter said something like:
> When you share an axis, the formatters and locators are shared as
> well.  I'm not sure if this is idea, but this is the way it is.  If
> you want to turn off the tick labels for ax2, the trick is to make
> them invisible, because the tick properties are not shared.  So
> instead of using the NullLocator, do
>
> for label in ax2.get_xticklabels():
>     label.set_visible(False)

I figured it was something simple.

Thanks again!

j

-- 
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/  ID 0xDB26D7CE

On Sun, Nov 16, 2008 at 8:31 PM, Joshua J. Kugler <jo...@ee...> wrote:
> In opening: Thank you very much to Stan West and John Hunter for their
> help so far.
>
> OK, I've hit either a genuine bug in Matplotlib, or a serious gap in my
> understanding; probably the latter.  If I missed something in the docs,
> please point me that way.  Attached is a test case that shows what's
> going on, as well as the "bad" plots produced.
>
> I started with the two axis example.  After setting the formatters for
> ax1, I set the xmajor ticks labels' font size to 40, and plot it, as
> well as ax2.
>
> That gives me a set of large X labels, and a set of small X labels.  OK,
> I try setting ax2's major formatter to NullFormatter(), but that makes
> all the number disappear.
>
> As can be seen from the print statements, the instances of the
> formatters are the same for both ax1 and ax2, even though they are
> supposed to be different axis, BUT the instances of the tick labels are
> different, hence the disparity in font sizes.
>
> So, besides the work-around of setting font sizes on both sets of tick
> labels, what is the solution here?

When you share an axis, the formatters and locators are shared as
well.  I'm not sure if this is idea, but this is the way it is.  If
you want to turn off the tick labels for ax2, the trick is to make
them invisible, because the tick properties are not shared.  So
instead of using the NullLocator, do

for label in ax2.get_xticklabels():
    label.set_visible(False)

Hope this helps,
JDH

I am leaning toward this being a true bug.  If you take a look at 
attached plot (the code for which is where I first noticed this bug), 
you'll notice that the dates on the top graph (the one with two axis) 
look a little "bold" while the dates on the bottom graph look "normal."  
The top set of dates are the one where I have to let font size (8) on 
two different sets of tick labels.

j

-- 
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/  ID 0xDB26D7CE

I've been trying to set the linestyle of an ellipse with no success.  I keep getting an attribute error whether I try setting the property via accessing the ellipse instance directly or through the artist.  Any ideas?

--if you uncomment the line containing the linestyle you should see the error--just paste into ipython -pylab.

Cheers,

Brian


########################


from matplotlib.patches import Ellipse as E
plot_colors = ['#297AA3','#A3293D','#3B9DCE','#293DA3','#5229A3','#8F29A3','#A3297A',
'#7AA329','#3DA329','#29A352','#29A38F','#A38F29','#3B9DCE','#6CB6DA','#CE6C3B','#DA916C',
'#0080FF','#0000FF','#7ABDFF','#8000FF','#FF0080','#FF0000','#FF8000','#FFFF00','#A35229','#80FF00',
'#00FF00','#00FF80','#00FFFF','#3D9EFF','#FF9E3D','#FFBD7A']

ells = []
for i in xrange(3):
    ells.append(E((i, i), 2, 2))
    #ells.append(E((i, i), 1.9, 1.9, ls = 'dashed'))
    ells.append(E((i, i), 1.9, 1.9))
    ells.append(E((i, i), 2.2, 2.2))
    #Ellipse((x_loc, y_loc), prop_x, prop_y) 

a = subplot(111, aspect='equal')

for i,e in enumerate(ells):
    e.set_clip_box(a.bbox)
    e.set_alpha(0.1)
    e.set_facecolor(plot_colors[i])
    a.add_artist(e)

xlim(-2, 4)
ylim(-2, 4)

show()




      

In opening: Thank you very much to Stan West and John Hunter for their 
help so far.

OK, I've hit either a genuine bug in Matplotlib, or a serious gap in my 
understanding; probably the latter.  If I missed something in the docs, 
please point me that way.  Attached is a test case that shows what's 
going on, as well as the "bad" plots produced.

I started with the two axis example.  After setting the formatters for 
ax1, I set the xmajor ticks labels' font size to 40, and plot it, as 
well as ax2.

That gives me a set of large X labels, and a set of small X labels.  OK, 
I try setting ax2's major formatter to NullFormatter(), but that makes 
all the number disappear.

As can be seen from the print statements, the instances of the 
formatters are the same for both ax1 and ax2, even though they are 
supposed to be different axis, BUT the instances of the tick labels are 
different, hence the disparity in font sizes.

So, besides the work-around of setting font sizes on both sets of tick 
labels, what is the solution here?

Thanks!

j

-- 
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/  ID 0xDB26D7CE

On Saturday 08 November 2008, John Hunter said something like:
> On Sat, Nov 8, 2008 at 1:02 AM, Joshua J. Kugler 
> > Sorry, I wasn't so much reporting  a problem with matplotlib as I
> > was wondering if I was missing something.

Turns out I was missing something: it was the x minor tick labels that 
was being plotted, not the x major ticks. :) But at any rate, that 
brought up another issue, which is the subject of my next e-mail, and 
has a minimal test case! :)

j

-- 
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/  ID 0xDB26D7CE

On Saturday 08 November 2008, John Hunter said something like:
> On Sat, Nov 8, 2008 at 1:02 AM, Joshua J. Kugler 
<jo...@ee...> wrote:
> > On Friday 07 November 2008, John Hunter said something like:
> >
> > http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#repo
> >rt-a-problem
> >
> > Sorry, I wasn't so much reporting  a problem with matplotlib as I
> > was wondering if I was missing something.  I'll try to extract a
> > free-standing example, but it might be hard...there's a lot of code
> > interacting here.  I'll work on that when I get a chance.
> >
> > Thanks!
>
> The point about making a free standing example is that often there is
> some other problem with your code, and the problem is not in the part
> you are posting or asking about.  And we can't help with the part we
> can't see.  In stripping your example down to a free standing
> example, often you will find the problem goes away. Then you will
> ask: what is different about from free the standing example and my
> real code, and in doing so find the real problem.
<snip>
> By not doing the extra work to make a simple example that we can run,
> you are asking us to do so.
<snip>
> I'm not trying to be snippy, it's just that the matplotlib mailing
> list gets a lot of traffic, and in addition to trying to help you
> with your problems, we are trying to fix bugs, add new features,
> solve platform issues and distribution issues, put out releases, and
> we all have jobs and families.

John (and all):

Thanks for your detailed reply.  I understand the need for a 
free-standing example, and understand why I should do it.  And if/when 
I find a problem, I certainly will do that.  The question I was asking 
was, in effect, "Is there another setting I should try to accomplish 
what I want to do."  I just wanted to know if I was missing something 
in the docs, not so much "Matplotlib isn't working."  I'm going to work 
on the problem some more today (and play around with the date graph 
example you suggested) and see if I can figure out anything.

j

-- 
Joshua Kugler
Part-Time System Admin/Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/  ID 0xDB26D7CE

On Sat, Nov 15, 2008 at 3:23 PM, Hrafnkell Pálsson <hr...@hi...> wrote:
>
> Hi
> I haven't managed to save a plot background into buffer to be able to
> restore it later.
> I use matplotlib to draw weather maps (see www.belgingur.is), and though the
> weather constantly changes the outlines of the countries are the same for
> every picture.
> Currently I plot the coastlines anew for every picture, which is kinda *not
> smart*.

Have you tried the "copy from bbox" / "restore_region" methods.  Draw
just what you want to save, and use "copy_from_bbox".  Later when you
want to plot something new, do a "restore_region" onto a clean canvas
and then plot the new stuff on top:

* background = canvas.copy_from_bbox(ax.bbox) - copy the region in
ax.bbox into a pixel buffer and return it in an object type of your
choosing. bbox is a matplotlib BBox instance from the transforms
module. background is not used by the matplotlib frontend, but it
stores it and passes it back to the backend in the restore_region
method. You will probably want to store not only the pixel buffer but
the rectangular region of the canvas from whence it came in the
background object.


* canvas.restore_region(background) - restore the region copied above
to the canvas.


* canvas.blit(bbox) - transfer the pixel buffer in region bounded by
bbox to the canvas.

Search the examples for "copy_from_bbox" on the web site
http://matplotlib.sourceforge.net/search.html

If you are still having troubles, let me know and I can give more help.

JDH

Hi
I haven't managed to save a plot background into buffer to be able to
restore it later.
I use matplotlib to draw weather maps (see www.belgingur.is), and though the
weather constantly changes the outlines of the countries are the same for
every picture.
Currently I plot the coastlines anew for every picture, which is kinda *not
smart*.

I got some promising results when using an interactive background but have
had no luck with the Agg background which I'd like to use.

Best regards, Hrafnkell 
-- 
View this message in context: http://www.nabble.com/Save-a-plot-background-tp20519596p20519596.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Mike,

Yes i'm using a more complicated program to batch produce images. Through
more investigation i think it's not just the close function, any repeat call
of pylab seems to have similar problem. Thanks for looking into it, i will
try the Agg backend and see if that works out.

Cheers,
Jon.


Michael Droettboom-3 wrote:
> 
> I'm not at the bottom of this yet, but thought I'd share my progress so 
> far -->
> 
> It is leaking actual Python references (meaning len(gc.get_objects()) is 
> increasing).  So it's not a malloc/free pair.
> 
> Seems to be Gtk-specific.  (Both GtkAgg and Gtk).  Other backends are 
> unaffected (Qt4 has some sort of leak of a much smaller magnitude).
> 
> The proper way to destroy pygtk objects appears to be a little bit of a 
> black art.  What's there now was pretty much arrived at by 
> experimentation and seems very brittle.
> 
> I know at one point it was working better than it is now.  My next step 
> will be to try to revert to a state where the leak wasn't so bad.  Given 
> the architecture of pygtk, I'm not sure it's possible to not leak at all 
> when creating/destroying windows like this, but we should at least be 
> able to reduce the leakage.
> 
> If your use case is just generating a bunch of images in batch, I'd 
> recommend using the Agg backend, rather than Gtk.  That doesn't leak for 
> me.  If you really need to be opening and closing this many windows in 
> succession, then we still don't have a good solution.
> 
> Mike
> 
> Michael Droettboom wrote:
>> Ok.  Thanks, I'll look into it.  Just wanted to rule out that this 
>> wasn't the known Gtk memory leak with old versions of Gtk before 
>> devoting time to it.
>>
>> Cheers,
>> Mike
>>
>> Eric Firing wrote:
>>   
>>> Michael Droettboom wrote:
>>>     
>>>> Can you provide more information about the platform and backend that 
>>>> you are using?
>>>>       
>>> Mike,
>>>
>>> I was able to reproduce this with my ubuntu 8.10, gtkagg backend.  I 
>>> ran  the code via cut and paste with the stock python interpreter, not 
>>> ipython.  I did not measure the memory use carefully, but used the 
>>> system monitor to observe memory for that process climbing, maybe 500k 
>>> per cycle.
>>>
>>> Our usual memleak tester shows no problem, however.
>>>
>>> Eric
>>>
>>>     
>>>> D2Hitman wrote:
>>>>       
>>>>> I am getting a memory leak when i am using the pylab.close() 
>>>>> function. I am
>>>>> running matplotlib-0.98.3. It happens in a very simple script such as:
>>>>>
>>>>> #!/usr/bin/python
>>>>> import time
>>>>> import pylab
>>>>>
>>>>> while True:
>>>>>     time.sleep(1)
>>>>>     print 'calling pylab'
>>>>>     pylab.box()
>>>>>     pylab.close()
>>>>>
>>>>> Every close seems to store megabytes in physical memory. Any idea 
>>>>> why this
>>>>> happens?
>>>>>
>>>>> Cheers.
>>>>>
>>>>>
>>>>>   
>>>>>         
>>
>>   
> 
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 

-- 
View this message in context: http://www.nabble.com/pylab.close%28%29-tp20486589p20515461.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Fri, Nov 14, 2008 at 5:20 PM, Gael Varoquaux
<gae...@no...> wrote:
> On Fri, Nov 14, 2008 at 11:12:14AM -0800, Benjamin J. Racine wrote:
>>    I use pause in matlab to cycle through an interactive do-loop and view a
>>    bunch of plots in interactively...
>
>>    Don't bother reproducing it here, but I am just wondering if this is
>>    possible in ipython/matplotlib
>
> pylab.waitforbuttonpress will do what you want.
>
> Gaël
>


waitforbuttonpress immediately returns for any keyboard or mouse event
(from the gui canvas).
If you want to examine the plot (pan, zoom, etc) with mouse, a quick
solution would be to use a loop

while not waitforbuttonpress():
    pass

The loop stops only for a key press.
Also, take a look at ginput().

-JJ

On Fri, Nov 14, 2008 at 11:12:14AM -0800, Benjamin J. Racine wrote:
>    I use pause in matlab to cycle through an interactive do-loop and view a
>    bunch of plots in interactively...

>    Don't bother reproducing it here, but I am just wondering if this is
>    possible in ipython/matplotlib

pylab.waitforbuttonpress will do what you want.

Gaël

I've had the same problem.  You can write a pause function using the
python input() function but it hangs the GIL and as a result your
window becomes unresponsive.  If anyone knows a GIL friendly way to
pause i would also be very interested.


On Fri, Nov 14, 2008 at 1:12 PM, Benjamin J. Racine
<bjr...@gl...> wrote:
> I use pause in matlab to cycle through an interactive do-loop and view a
> bunch of plots in interactively...
>
> Don't bother reproducing it here, but I am just wondering if this is
> possible in ipython/matplotlib
>
> Many thanks,
>
> Ben Racine
> _______________________________________________
> IPython-user mailing list
> IPy...@sc...
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
>
>

I'm not at the bottom of this yet, but thought I'd share my progress so 
far -->

It is leaking actual Python references (meaning len(gc.get_objects()) is 
increasing).  So it's not a malloc/free pair.

Seems to be Gtk-specific.  (Both GtkAgg and Gtk).  Other backends are 
unaffected (Qt4 has some sort of leak of a much smaller magnitude).

The proper way to destroy pygtk objects appears to be a little bit of a 
black art.  What's there now was pretty much arrived at by 
experimentation and seems very brittle.

I know at one point it was working better than it is now.  My next step 
will be to try to revert to a state where the leak wasn't so bad.  Given 
the architecture of pygtk, I'm not sure it's possible to not leak at all 
when creating/destroying windows like this, but we should at least be 
able to reduce the leakage.

If your use case is just generating a bunch of images in batch, I'd 
recommend using the Agg backend, rather than Gtk.  That doesn't leak for 
me.  If you really need to be opening and closing this many windows in 
succession, then we still don't have a good solution.

Mike

Michael Droettboom wrote:
> Ok.  Thanks, I'll look into it.  Just wanted to rule out that this 
> wasn't the known Gtk memory leak with old versions of Gtk before 
> devoting time to it.
>
> Cheers,
> Mike
>
> Eric Firing wrote:
>   
>> Michael Droettboom wrote:
>>     
>>> Can you provide more information about the platform and backend that 
>>> you are using?
>>>       
>> Mike,
>>
>> I was able to reproduce this with my ubuntu 8.10, gtkagg backend.  I 
>> ran  the code via cut and paste with the stock python interpreter, not 
>> ipython.  I did not measure the memory use carefully, but used the 
>> system monitor to observe memory for that process climbing, maybe 500k 
>> per cycle.
>>
>> Our usual memleak tester shows no problem, however.
>>
>> Eric
>>
>>     
>>> D2Hitman wrote:
>>>       
>>>> I am getting a memory leak when i am using the pylab.close() 
>>>> function. I am
>>>> running matplotlib-0.98.3. It happens in a very simple script such as:
>>>>
>>>> #!/usr/bin/python
>>>> import time
>>>> import pylab
>>>>
>>>> while True:
>>>>     time.sleep(1)
>>>>     print 'calling pylab'
>>>>     pylab.box()
>>>>     pylab.close()
>>>>
>>>> Every close seems to store megabytes in physical memory. Any idea 
>>>> why this
>>>> happens?
>>>>
>>>> Cheers.
>>>>
>>>>
>>>>   
>>>>         
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA