matplotlib-users Mailing List for matplotlib

Ben - 
You can see the image at http://www.surfguru.com/smc/TestRender.png . With a continuous level array [1 .. 18] the image looks like http://www.surfguru.com/smc/TestRender2.png
Thanks,
Steve
On Jul 14, 2010, at 4:12 PM, Benjamin Root wrote:
> Steve,
> 
> Could you please attach an example image of what you are seeing?
> 
> Ben Root
> 
> On Wed, Jul 14, 2010 at 5:52 PM, Steve McFarlin <st...@st...> wrote:
> Hello,
> 
> I am trying to create a color map that maps 18 colors across 50 levels. As an example let say I have three colors [r,g,b] and want everything between 1 an 2 to be r, 3 through 10 to be g, and 11 through 50 to be b. From what I can tell it does not seem to be possible. Currently this is what I have, but it does not seem to work as I assumed.
> 
> colorList = [[0.,0.,102./255.],[0,42./255.,217./255.],[0,110./255.,217./255.],[0,178./255.,217./255.],
> [0,212./255.,212./255.],[0,217./255.,166./255.],[0,217./255.,0],[149./255.,217./255.,0],
> [217./255.,217./255.,0],[217./255.,174./255.,0],[217./255.,131./255.,0],[217./255.,87./255.,0],
> [217./255.,0,0],[174./255.,0,0],[140./255.,0,0],[135./255.,0,0],
> [105./255.,0,0],[65./255.,0,0]]
> 
> levels = [1,2,3,4,5,6,7,8,9,10,12,15,20,25,30,35,40,50]
> cmap = matplotlib.colors.ListedColormap(colorList, name = 'theColorMap', N = len(colorList))
> ...
> m.contourf(x,y,z,cmap=cmap, levels=levels, extend='both')
> 
> If the levels array is continuous then it works as expected. With the above settings I get unexpected results, which includes 'ghost contour lines'. The data I am rendering is from a GRIB file from NOAA.
> 
> Is this possible?
> 
> 
> Thanks,
> Steve
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

Steve,
Could you please attach an example image of what you are seeing?
Ben Root
On Wed, Jul 14, 2010 at 5:52 PM, Steve McFarlin <st...@st...>wrote:
> Hello,
>
> I am trying to create a color map that maps 18 colors across 50 levels. As
> an example let say I have three colors [r,g,b] and want everything between 1
> an 2 to be r, 3 through 10 to be g, and 11 through 50 to be b. From what I
> can tell it does not seem to be possible. Currently this is what I have, but
> it does not seem to work as I assumed.
>
> colorList =
> [[0.,0.,102./255.],[0,42./255.,217./255.],[0,110./255.,217./255.],[0,178./255.,217./255.],
>
> [0,212./255.,212./255.],[0,217./255.,166./255.],[0,217./255.,0],[149./255.,217./255.,0],
>
> [217./255.,217./255.,0],[217./255.,174./255.,0],[217./255.,131./255.,0],[217./255.,87./255.,0],
> [217./255.,0,0],[174./255.,0,0],[140./255.,0,0],[135./255.,0,0],
> [105./255.,0,0],[65./255.,0,0]]
>
> levels = [1,2,3,4,5,6,7,8,9,10,12,15,20,25,30,35,40,50]
> cmap = matplotlib.colors.ListedColormap(colorList, name = 'theColorMap', N
> = len(colorList))
> ...
> m.contourf(x,y,z,cmap=cmap, levels=levels, extend='both')
>
> If the levels array is continuous then it works as expected. With the above
> settings I get unexpected results, which includes 'ghost contour lines'. The
> data I am rendering is from a GRIB file from NOAA.
>
> Is this possible?
>
>
> Thanks,
> Steve
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hello,
I am trying to create a color map that maps 18 colors across 50 levels. As an example let say I have three colors [r,g,b] and want everything between 1 an 2 to be r, 3 through 10 to be g, and 11 through 50 to be b. From what I can tell it does not seem to be possible. Currently this is what I have, but it does not seem to work as I assumed.
colorList = [[0.,0.,102./255.],[0,42./255.,217./255.],[0,110./255.,217./255.],[0,178./255.,217./255.],
 [0,212./255.,212./255.],[0,217./255.,166./255.],[0,217./255.,0],[149./255.,217./255.,0],
 [217./255.,217./255.,0],[217./255.,174./255.,0],[217./255.,131./255.,0],[217./255.,87./255.,0],
 [217./255.,0,0],[174./255.,0,0],[140./255.,0,0],[135./255.,0,0],
 [105./255.,0,0],[65./255.,0,0]]
levels = [1,2,3,4,5,6,7,8,9,10,12,15,20,25,30,35,40,50]
cmap = matplotlib.colors.ListedColormap(colorList, name = 'theColorMap', N = len(colorList)) 
...
m.contourf(x,y,z,cmap=cmap, levels=levels, extend='both')
If the levels array is continuous then it works as expected. With the above settings I get unexpected results, which includes 'ghost contour lines'. The data I am rendering is from a GRIB file from NOAA. 
Is this possible?
Thanks,
Steve

On 07/14/2010 11:41 AM, Stephen Evans wrote:
> Hi,
>
> While testing Psyco V2 to see if it would offer any speed improvements I
> tried it with some applications using matplotlib. Exceptions were raised
> that were easily resolved by replacing calls to min() and max() with
> their numpy equivalents numpy.amin() and numpy.amax() in the matplotlib
> code.
>
> Simply demonstrated by inserting at the beginning of, say, matplotlib's
> examples/api/barchart_demo.py :
>
> import psyco
> psyco.full()
>
> which caused:
>
> Traceback (most recent call last):
> File "barchart_demo.py", line 29, in<module>
> ax.set_xticks(ind+width)
> File "c:\python26\lib\site-packages\matplotlib\axes.py", line 2064,
> in set_xticks
> return self.xaxis.set_ticks(ticks, minor=minor)
> File "c:\python26\lib\site-packages\matplotlib\axis.py", line 1154,
> in set_ticks
> self.set_view_interval(min(ticks), max(ticks))
> File "c:\python26\lib\site-packages\psyco\builtin.py", line 75, in min
> return _min(*args)
> File "c:\python26\lib\site-packages\psyco\builtin.py", line 34, in _min
> if not iterable:
> ValueError: The truth value of an array with more than one element is
> ambiguous. Use a.any() or a.all()
>
>
> software used:
>
> Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import psyco
> >>> psyco.version_info
> (2, 0, 0, 'final', 0)
> >>> import numpy
> >>> numpy.version.version
> '1.4.1'
> >>> import matplotlib
> >>> matplotlib.__version__
> '0.99.3'
>
>
> Psyco V2 is available from: http://codespeak.net/svn/psyco/v2/dist/
>
> Should numpy.min()/numpy.amin() be used on array like objects within
> matplotlib, or is min() adequate ? Ditto max().
When short sequences are involved, min() is much faster than amin(). If 
min() is called only a few times per plot in such cases, using the 
slower function would cause a negligible slowdown. I'm reluctant to 
change mpl to work around a bug in psyco, though.
When you did make the substitution and do the test, was there a big speedup?
Eric
>
>
> Stephen Evans
>
> (Out of interest I came across numpy ticket #1286 while looking for this
> issue.)
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi,
While testing Psyco V2 to see if it would offer any speed improvements I 
tried it with some applications using matplotlib. Exceptions were raised 
that were easily resolved by replacing calls to min() and max() with 
their numpy equivalents numpy.amin() and numpy.amax() in the matplotlib 
code.
Simply demonstrated by inserting at the beginning of, say, matplotlib's 
examples/api/barchart_demo.py :
import psyco
psyco.full()
which caused:
Traceback (most recent call last):
 File "barchart_demo.py", line 29, in <module>
 ax.set_xticks(ind+width)
 File "c:\python26\lib\site-packages\matplotlib\axes.py", line 2064, 
in set_xticks
 return self.xaxis.set_ticks(ticks, minor=minor)
 File "c:\python26\lib\site-packages\matplotlib\axis.py", line 1154, 
in set_ticks
 self.set_view_interval(min(ticks), max(ticks))
 File "c:\python26\lib\site-packages\psyco\builtin.py", line 75, in min
 return _min(*args)
 File "c:\python26\lib\site-packages\psyco\builtin.py", line 34, in _min
 if not iterable:
ValueError: The truth value of an array with more than one element is 
ambiguous. Use a.any() or a.all()
software used:
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import psyco
 >>> psyco.version_info
(2, 0, 0, 'final', 0)
 >>> import numpy
 >>> numpy.version.version
'1.4.1'
 >>> import matplotlib
 >>> matplotlib.__version__
'0.99.3'
Psyco V2 is available from: http://codespeak.net/svn/psyco/v2/dist/
Should numpy.min()/numpy.amin() be used on array like objects within 
matplotlib, or is min() adequate ? Ditto max().
Stephen Evans
(Out of interest I came across numpy ticket #1286 while looking for this 
issue.)

I'm embedding a plot in a wxPython panel, and I'd like it to blend in as
much as possible, i.e. the area outside the plot itself should be
transparent. I can call figure.figurePatch.set_alpha(0.0) to do this under
normal circumstances, but in this case I'm also trying to redraw the plot
periodically in response to a background process. When I do this,
figure.clear() clears the plot area, but not the axes and labels, so I end
up with all of the old axes superimposed. Is there a way to completely
erase the background before redrawing?
thanks,
Nat

On 07/14/2010 06:49 AM, Daniel Welling wrote:
> Greetings.
>
> I've recently found that when I replace pcolor with pcolorfast, the
> image will not scale correctly when placed on an axis with a logarithmic
> scale. It will remain linear, thus not matching the axis range
> whatsoever. The pcolor plot will still fit nicely in the axis object,
> but the ticks and labels clearly do not match the data. I've tried
> several things, from changing the axis from linear to log before and
> after using pcolorfast, etc, but pcolorfast artist objects do not seem
> to respond to this. Again, pcolor acts as one would expect.
>
> Complicating this is that I have made two changes at once: upgrading
> from MPL 99 to 1.0 and switching from pcolor to pcolorfast. As such, I
> do not know if this a new or old issue (or if it is an issue at- perhaps
> this behavior is on purpose.)
>
> If anyone could shed some light on this, that would be great.
> Pcolorfast is preferable over pcolor because of the complexity of my
> plots and the speed up gained by using pcolorfast.
The problem is that I never quite finished pcolorfast; it probably needs 
a little more refinement in argument handling, and it needs to detect 
nonlinear axes. The latter never even occurred to me when I wrote it, 
since that case does not occur in the applications for which I use it.
For now, try using pcolormesh instead of pcolorfast. It will handle log 
axes, and although probably not quite as fast as pcolorfast could be if 
it correctly handled log axes, it will be *much* faster than pcolor.
Eric
>
> Thanks!
> -dw
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On 07/14/2010 01:29 AM, Georges Schutz wrote:
> Hi again,
> While looking for a solution for my autoscale issue (see 13/7/2010
> 16:50) I had a look at the matplotlib (1.0.0) source code and found
> something strange in axes.py
>
> In the Axes class the method margins()(Line 1651) the doc string says
> that using margins() with no arguments should return xmargin, ymargin.
>
> If I look at the code for that situation
> --- axes.py line (1686-1687)
> if not args and not kw:
> return self._ymargin, self._ymargin
> -----
> the ymargin is returned twice.
>
> I suppose that this is a bug and should be
>
> return self._xmargin, self._ymargin
Thank you. Fixed in 8549, 8550.
Eric
>
> Best regards
>
> Georges Schutz
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On 2010年07月14日 18:51:26 +0200, K.-Michael Aye said:
> On 2010年07月14日 18:45:35 +0200, John Hunter said:
> 
>> On Wed, Jul 14, 2010 at 11:38 AM, K.-Michael Aye
>> <kmi...@gm...> wrote:
>> 
>>> Out[12]: 1
>>> 
>>> In [13]: gc.collect()
>>> 
>>> Out[13]: 12
>> 
>> 
>> still not seeing a leak in your data -- you need to report_memory
>> after calling gc collect. Turn off hold, add an image, call collect,
>> report memory, the repeat several times, each time calling collect and
>> report memory, and report the results.
> 
> Was just following your example, you were nowhere calling collect.
> Here is what you requested:
> 
> In [1]: import gc
> 
> In [2]: import matplotlib.cbook as cbook
> 
> In [3]: data = ones((1500,1500,3))
> 
> In [4]: hold(False)
> 
> In [5]: imshow(data)
> 
> Out[5]: <matplotlib.image.AxesImage object at 0x1c43e50>
> 
> In [6]: gc.collect()
> 
> Out[6]: 12
> 
> In [7]: cbook.report_memory()
> 
> Out[7]: 174540
> 
> In [8]: imshow(data)
> 
> Out[8]: <matplotlib.image.AxesImage object at 0x1c59e90>
> 
> In [9]: gc.collect()
> 
> Out[9]: 0
> 
> In [10]: cbook.report_memory()
> 
> Out[10]: 253400
> 
> In [11]: imshow(data)
> 
> Out[11]: <matplotlib.image.AxesImage object at 0x1c603b0>
> 
> In [12]: gc.collect()
> 
> Out[12]: 0
> 
> In [13]: cbook.report_memory()
> 
> Out[13]: 333360
> 
> In [14]: imshow(data)
> 
> Out[14]: <matplotlib.image.AxesImage object at 0x1c60410>
> 
> In [15]: gc.collect()
> 
> Out[15]: 0
> 
> In [16]: cbook.report_memory()
> 
> Out[16]: 413296
> 
Here are the commands as macro form, for easy cut and paste into pylab:
import gc
import matplotlib.cbook as cbook
data = ones((1500,1500,3))
hold(False)
imshow(data)
gc.collect()
cbook.report_memory()
imshow(data)
gc.collect()
cbook.report_memory()
imshow(data)
gc.collect()
cbook.report_memory()
imshow(data)
gc.collect()
cbook.report_memory()
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first

On 2010年07月14日 18:45:35 +0200, John Hunter said:
> On Wed, Jul 14, 2010 at 11:38 AM, K.-Michael Aye 
> <kmi...@gm...> wrote:
> 
>> Out[12]: 1
>> 
>> In [13]: gc.collect()
>> 
>> Out[13]: 12
> 
> 
> still not seeing a leak in your data -- you need to report_memory
> after calling gc collect. Turn off hold, add an image, call collect,
> report memory, the repeat several times, each time calling collect and
> report memory, and report the results.
Was just following your example, you were nowhere calling collect.
Here is what you requested:
In [1]: import gc
In [2]: import matplotlib.cbook as cbook
In [3]: data = ones((1500,1500,3))
In [4]: hold(False)
In [5]: imshow(data)
Out[5]: <matplotlib.image.AxesImage object at 0x1c43e50>
In [6]: gc.collect()
Out[6]: 12
In [7]: cbook.report_memory()
Out[7]: 174540
In [8]: imshow(data)
Out[8]: <matplotlib.image.AxesImage object at 0x1c59e90>
In [9]: gc.collect()
Out[9]: 0
In [10]: cbook.report_memory()
Out[10]: 253400
In [11]: imshow(data)
Out[11]: <matplotlib.image.AxesImage object at 0x1c603b0>
In [12]: gc.collect()
Out[12]: 0
In [13]: cbook.report_memory()
Out[13]: 333360
In [14]: imshow(data)
Out[14]: <matplotlib.image.AxesImage object at 0x1c60410>
In [15]: gc.collect()
Out[15]: 0
In [16]: cbook.report_memory()
Out[16]: 413296

Greetings.
I've recently found that when I replace pcolor with pcolorfast, the image
will not scale correctly when placed on an axis with a logarithmic scale.
 It will remain linear, thus not matching the axis range whatsoever. The
pcolor plot will still fit nicely in the axis object, but the ticks and
labels clearly do not match the data. I've tried several things, from
changing the axis from linear to log before and after using pcolorfast, etc,
but pcolorfast artist objects do not seem to respond to this. Again, pcolor
acts as one would expect.
Complicating this is that I have made two changes at once: upgrading from
MPL 99 to 1.0 and switching from pcolor to pcolorfast. As such, I do not
know if this a new or old issue (or if it is an issue at- perhaps this
behavior is on purpose.)
If anyone could shed some light on this, that would be great. Pcolorfast is
preferable over pcolor because of the complexity of my plots and the speed
up gained by using pcolorfast.
Thanks!
-dw

On Wed, Jul 14, 2010 at 11:38 AM, K.-Michael Aye <kmi...@gm...> wrote:
> Out[12]: 1
>
> In [13]: gc.collect()
>
> Out[13]: 12
still not seeing a leak in your data -- you need to report_memory
after calling gc collect. Turn off hold, add an image, call collect,
report memory, the repeat several times, each time calling collect and
report memory, and report the results.
JDH

>> 6 : ax.images
>> 7 : im = imshow(data)
>> 8 : ax.images
>> 9 : ax.images.remove[0]
>> 10: del ax.images.remove[0]
> 
> Both of these lines are wrong. You either need to do
> 
> ax.images.remove(0) # note the parens, not square brackets
> 
> or
> 
> del ax.images[0]
*doh*, of course, me stupid. Sorry, it's very very hot here. :)
> 
> Also, you are mixing API calls, eg
> 
> ax = fig.add_subplot(111)
> 
> with pyplot call, eg
> 
> im = imshow(data)
> 
> While this isn't a bug in this case, it is not good form. The pyplot
> calls manage stateful information like current image and current axes,
> and you are safer using all pyplot or all api. So for pure pyplot:
> 
> subplot(111)
> imshow(data)
> 
> or pure API:
> 
> ax = fig.add_subplot(111)
> ax.imshow(data)
Yeah, sorry, i thought it wouldn't matter, as i did not need an image 
object for this demo.
> 
> 
>> Even so i set hold(False), and the ax.images array does not increase,
>> the memory consumption increases.
>> 
>> I used these commands:
>> 
>> 3 : fig = figure()
>> 4 : ax = fig.add_subplot(111)
>> 5 : imshow(data)
>> 6 : ax.images
>> 7 : hold(False)
>> 8 : imshow(data)
>> 9 : ax.images
>> 
>> At step 6 I had 1 image in the ax.images array, at step 9 still only 1,
>> but RealMem went up the approx same amount between 7 and 8 then it did
>> between 4 and 5.
> 
> 
> I don't see this -- try using gc.collect() if you think you see a leak
> and use cbook.report_memory to get a measure of consumed memory. If
> you still think you have a leak, try and build a complete
> free-standing script that replicates it.
I only can reproduce it inside a pylab session, as you see here:
IPython 0.10 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
 Welcome to pylab, a matplotlib-based Python environment.
 For more information, type 'help(pylab)'.
In [1]: import gc
In [2]: gc.collect?
Type:		builtin_function_or_method
Base Class:	<type 'builtin_function_or_method'>
String Form:	<built-in function collect>
Namespace:	Interactive
Docstring:
 collect([generation]) -> n
 With no arguments, run a full collection. The optional argument
 may be an integer specifying which generation to collect. A ValueError
 is raised if the generation number is invalid.
 The number of unreachable objects is returned.
In [3]: import matplotlib.cbook as cbook
In [4]: data = ones((1500,1500,3))
In [5]: imshow(data)
Out[5]: <matplotlib.image.AxesImage object at 0x1c57610>
In [6]: ax =gca()
In [7]: cbook.report_memory()
Out[7]: 175384
In [8]: hold(False)
In [9]: len(ax.images)
Out[9]: 1
In [10]: imshow(data)
Out[10]: <matplotlib.image.AxesImage object at 0x1416430>
In [11]: cbook.report_memory()
Out[11]: 254624
In [12]: len(ax.images)
Out[12]: 1
In [13]: gc.collect()
Out[13]: 12
Don't know what to do with the 12 though?
If I do the same with a script like this:
from matplotlib.pylab import *
import matplotlib.cbook as cbook
data = ones((1500,1500,3))
imshow(data)
ax = gca()
print cbook.report_memory()
print len(ax.images)
hold(False)
imshow(data)
print cbook.report_memory()
print len(ax.images)
imshow(data)
print cbook.report_memory()
print len(ax.images)
imshow(data)
print cbook.report_memory()
print len(ax.images)
imshow(data)
print cbook.report_memory()
print len(ax.images)
This is what happens:
81920
1
82028
1
82128
1
82128
1
82132
1
So it's fine here.
So what's wrong with my ipython/pylab? :(
BR,
Michael

On Wed, Jul 14, 2010 at 10:18 AM, K.-Michael Aye <kmi...@gm...> wrote:
> On 2010年07月14日 01:46:49 +0200, John Hunter said:
>
>> On Mon, Jul 12, 2010 at 5:06 PM, K.-Michael Aye
>> <kmi...@gm...> wrote:
>>> On 2010年07月12日 23:17:19 +0200, John Hunter said:
>>>
>>>> On Mon, Jul 12, 2010 at 4:06 PM, K.-Michael Aye
>>>> <kmi...@gm...> wrote:
>>>>> Dear all,
>>>>>
>>>>> I'm not sure if this is by design or a problem:
>>
>> It's by design and is not a leak. matplotlib supports multiple images
>> on the same axes, and can composite multiple images that overlap the
>> same space using transparency, so each call to imshow is adding
>> additional data to the axes.
>
> Understood, and of course quite useful. But see below.
>
>> You can inspect the ax.images list to
>> see the list of images is growing.
>>
>> If you have an Image object and want to remove it from the Axes, call
>>
>>  im.remove()
>
>
> This worked.
>
>> or you can manipulate the list of ax.images directly, eg
>>
>>  del ax.images[0]
>
> I tried this and got this error message:
>
> In [10]: del ax.images.remove[0]
> ---------------------------------------------------------------------------
> TypeError                 Traceback (most recent call last)
>
> /Users/aye/Documents/workspace/pyrise_saver_clone/src/<ipython console>
> in <module>()
>
> TypeError: 'builtin_function_or_method' object does not support item deletion
>
> Here my history of that session:
>
> 1 : from fan_finder import get_data
> 2 : data = get_data(2)
> 3 : fig = figure()
> 4 : ax = fig.add_subplot(111)
> 5 : im = imshow(data)
> 6 : ax.images
> 7 : im = imshow(data)
> 8 : ax.images
> 9 : ax.images.remove[0]
> 10: del ax.images.remove[0]
Both of these lines are wrong. You either need to do
 ax.images.remove(0) # note the parens, not square brackets
or
 del ax.images[0]
Also, you are mixing API calls, eg
 ax = fig.add_subplot(111)
with pyplot call, eg
 im = imshow(data)
While this isn't a bug in this case, it is not good form. The pyplot
calls manage stateful information like current image and current axes,
and you are safer using all pyplot or all api. So for pure pyplot:
 subplot(111)
 imshow(data)
or pure API:
 ax = fig.add_subplot(111)
 ax.imshow(data)
> Even so i set hold(False), and the ax.images array does not increase,
> the memory consumption increases.
>
> I used these commands:
>
> 3 : fig = figure()
> 4 : ax = fig.add_subplot(111)
> 5 : imshow(data)
> 6 : ax.images
> 7 : hold(False)
> 8 : imshow(data)
> 9 : ax.images
>
> At step 6 I had 1 image in the ax.images array, at step 9 still only 1,
> but RealMem went up the approx same amount between 7 and 8 then it did
> between 4 and 5.
I don't see this -- try using gc.collect() if you think you see a leak
and use cbook.report_memory to get a measure of consumed memory. If
you still think you have a leak, try and build a complete
free-standing script that replicates it.
In [220]: import matplotlib.cbook as cbook
In [221]: cbook.report_memory
Out[221]: <function report_memory at 0x87fd5a4>
In [222]: cbook.report_memory()
Out[222]: 81733
In [223]: hold(False)
In [224]: ax = gca()
In [225]: len(ax.images)
Out[225]: 1
In [226]: imshow(data)
Out[226]: <matplotlib.image.AxesImage object at 0xc7455ec>
In [227]: len(ax.images)
Out[227]: 1
In [228]: cbook.report_memory()
Out[228]: 81733
In [229]: imshow(data)
Out[229]: <matplotlib.image.AxesImage object at 0xd4752ac>
In [230]: len(ax.images)
Out[230]: 1
In [231]: imshow(data)
Out[231]: <matplotlib.image.AxesImage object at 0xe4ee72c>
In [232]: len(ax.images)
Out[232]: 1
In [233]: cbook.report_memory()
Out[233]: 81733
JDH

Dear all,
just a small tip for all who are creating many images by using 
something like this:
for param in range(10):
	data = get_data(param)
	fig = plt.figure()
	ax = fig.add_subplot(111)
	im = ax.imshow(data)
	fig.savefig('data_'+str(param)+'.png)
	# plt.close(fig)
Unfortunately, even so the objects are created inside the loop, it 
seems they don't vanish completely from loop to loop. So, without the 
currently commented 'plt.close(fig)' you will create a huge memory leak 
(well, depending on your image sizes) that grinds even your 4GB Macbook 
Pro to a complete halt. ;)
Hopefully that helps some people out.
BR,
Michael

On 2010年07月14日 01:46:49 +0200, John Hunter said:
> On Mon, Jul 12, 2010 at 5:06 PM, K.-Michael Aye 
> <kmi...@gm...> wrote:
>> On 2010年07月12日 23:17:19 +0200, John Hunter said:
>> 
>>> On Mon, Jul 12, 2010 at 4:06 PM, K.-Michael Aye
>>> <kmi...@gm...> wrote:
>>>> Dear all,
>>>> 
>>>> I'm not sure if this is by design or a problem:
> 
> It's by design and is not a leak. matplotlib supports multiple images
> on the same axes, and can composite multiple images that overlap the
> same space using transparency, so each call to imshow is adding
> additional data to the axes.
Understood, and of course quite useful. But see below.
> You can inspect the ax.images list to
> see the list of images is growing.
> 
> If you have an Image object and want to remove it from the Axes, call
> 
> im.remove()
This worked.
> or you can manipulate the list of ax.images directly, eg
> 
> del ax.images[0]
I tried this and got this error message:
In [10]: del ax.images.remove[0]
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
/Users/aye/Documents/workspace/pyrise_saver_clone/src/<ipython console> 
in <module>()
TypeError: 'builtin_function_or_method' object does not support item deletion
Here my history of that session:
1 : from fan_finder import get_data
2 : data = get_data(2)
3 : fig = figure()
4 : ax = fig.add_subplot(111)
5 : im = imshow(data)
6 : ax.images
7 : im = imshow(data)
8 : ax.images
9 : ax.images.remove[0]
10: del ax.images.remove[0]
11: hist%
12: _ip.magic("hist ")
data is a np.array
I found another funny thing:
Even so i set hold(False), and the ax.images array does not increase, 
the memory consumption increases.
I used these commands:
3 : fig = figure()
4 : ax = fig.add_subplot(111)
5 : imshow(data)
6 : ax.images
7 : hold(False)
8 : imshow(data)
9 : ax.images
At step 6 I had 1 image in the ax.images array, at step 9 still only 1, 
but RealMem went up the approx same amount between 7 and 8 then it did 
between 4 and 5.
> 
> or if you have a single image and want to update the data in it, you can do
> 
> im = ax.imshow(something)
> im.set_array(newdata)
I am using this way in a GUI I programmed and works very well there.
BR,
Michael
> 
> to update the array in the existing image.
> 
> JDH
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first

Hi again,
While looking for a solution for my autoscale issue (see 13/7/2010 
16:50) I had a look at the matplotlib (1.0.0) source code and found 
something strange in axes.py
In the Axes class the method margins()(Line 1651) the doc string says 
that using margins() with no arguments should return xmargin, ymargin.
If I look at the code for that situation
--- axes.py line (1686-1687)
 if not args and not kw:
 return self._ymargin, self._ymargin
-----
the ymargin is returned twice.
I suppose that this is a bug and should be
 return self._xmargin, self._ymargin
Best regards
Georges Schutz

Hi
I am trying to use autofmt_xdate() on graphs with more than 1 y-axis. But it
seems that even calling twinx() causes errors. On python 2.5 matplotlib 0.98
a call to twinx() seems to switch off the functioning of autofmt_xdate()
(and the labels are horizontal and mashed up). On python 2.6 and matplotlib
1.0.0 it causes a ValueError.
The following script illustrates the issue (in real life I obviously want to
do things with ax2, but it seems that even creating it causes problems). Is
there a simple working example of rotated data formats and twinx()?
robert
import datetime
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
date=[datetime.datetime(2010,1,1), datetime.datetime(2010,12,1)]
data=[1,2]
fig = plt.figure()
ax = fig.add_subplot(111)
# uncommenting the following line will lead to the problems
# ax2=ax.twinx()
ax.plot(date, data)
fig.autofmt_xdate(rotation=90)
fig.savefig("test3.png", dpi=400)

Hi JJ,
 Thanks for your reply. I can't access the svn for some network
reason. Will you please send me a copy of your patch about Text.draw?
 Regards,
David.shu
> It seems that there are at least two issues related with the text
>clipping.
> The first issue is that the Text.draw method does not properly set
> clip path. I think I fixed this in r8541 and r8542.
> 
> The second issue is that the agg backend does not seem to support a
> clip path yet for the text.
> 
> Also, your script need to be fixed.
> The patch need to be added to the axes (or its transform need to be
> set) before you call set_clip_path.
> 
> So, with the current svn, you can clip the text with an arbitrary path
> when you're using the backends that support it (I only tested with pdf
> backend, the attached is the pdf output converted to png).
> If you can install matplotlib from the svn, please test the patch.
> Also, it would be great if you file a bug in the SF tracker, so that
> other developer can fix it later.
> 
> Regards,
> 
> -JJ

Hey,
Im having some trouble embedding a figure into a larger cocoa app. i found
one old post that stated that this was not easily possible using the newish
macosx backend, but that perhaps the old cocoaagg backend would work.
Has any one done this? I cant switch GUI frameworks as the larger app is
cocoa based.
examples would be great.
- dan
the referenced post:
http://old.nabble.com/CocoaAgg-and-Macosx-backend-td28794477.html#a28795294

010/7/13 Isaac Salazar <if...@la...>
> I have read access to the directory and have an admin account, however, i'm not the user who set up the machine (084535)
> The home.ppm file and others in that directory show "Write only (Drop Box)" for admin.
> For everyone, the permissions are set to "No Access"
>
> I was able to add a new permission user for myself "Isaac (me)" and got passed the error on home.ppm and now get an error on back.ppm.
>
> What should I do to correct the permissions on the other files in the images directory?
> Are there other files that may have this same issue as I am using matplotlib in the future?
> Thanks.
You can use TinkerTool System Release 2. It's very powerful, has 5
free starts, and I think it's worth purchasing. Do you want to use
this program? http://www.bresink.com .
Also, it's certainly possibe to use the command line, but I personally
usually use TinkerTool System.
Friedrich