matplotlib-devel Mailing List for matplotlib

So I think the change I suggested takes care of the floating point case, 
except that the vmin and vmax values don't default to 0.0 and 1.0. I 
wonder whether this is enough of a surprise to warrant some logic to set 
 vmin and vmax in some cases, such as iff all array values are floats 
in the range 0.0-1.0 and neither vmin nor vmax have been specified as 
arguments, then use vmin=0.0 and vmax=1.0. Should we aim to replicate 
the scipy imsave behaviour exactly? Another possible problem with the 
current behaviour is that single bit plane arrays currently get saved as 
RGB - I don't know if this can be changed easily.
Gary
Stéfan van der Walt wrote:
> Hi Gary
> 
> Sorry, I didn't even read the docstring since I have been using
> SciPy's "imsave" so far.
> 
> 2009年11月8日 Gary Ruben <gr...@bi...>:
>> This may be all you need. My tests (in the attached test.py) appear to
>> work. However, I don't think it's what you want. By default, figimage
>> even expects NxMx3 and NxMx4 arrays to be float arrays nominally ranging
>> from 0-1. What you probably want is a raw RGB mapping where pixel planes
>> are unsigned 8 bit values. I thought calling figimage with a
>> norm=no_norm(0,255) instance achieved this but it doesn't work as I
>> expect. So the first question is, what is the expected behaviour here,
>> and a follow-up is does anyone here understand how to do the colour
>> mapping to achieve it?
> 
> We assume that arrays of dtype uint8 represent intensities 0 through
> 255, and that floating point arrays are between 0-1.
> 
> Regards
> Stéfan
> 

Hi Gary
Sorry, I didn't even read the docstring since I have been using
SciPy's "imsave" so far.
2009年11月8日 Gary Ruben <gr...@bi...>:
> This may be all you need. My tests (in the attached test.py) appear to
> work. However, I don't think it's what you want. By default, figimage
> even expects NxMx3 and NxMx4 arrays to be float arrays nominally ranging
> from 0-1. What you probably want is a raw RGB mapping where pixel planes
> are unsigned 8 bit values. I thought calling figimage with a
> norm=no_norm(0,255) instance achieved this but it doesn't work as I
> expect. So the first question is, what is the expected behaviour here,
> and a follow-up is does anyone here understand how to do the colour
> mapping to achieve it?
We assume that arrays of dtype uint8 represent intensities 0 through
255, and that floating point arrays are between 0-1.
Regards
Stéfan

I guess you're right... I misunderstood the result of gc.collect() as the number of objects that could not be freed. The good news is that after fixing the bug I was looking at, there are no more objects that cannot be freed (gc.garbage is empty).
Thanks!
--Michiel.
--- On Sun, 11/8/09, Eric Firing <ef...@ha...> wrote:
> From: Eric Firing <ef...@ha...>
> Subject: Re: [matplotlib-devel] Circular references in Figure
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: mat...@li...
> Date: Sunday, November 8, 2009, 1:43 AM
> Michiel de Hoon wrote:
> > Hi everybody,
> > 
> > I was looking at this bug about a memory leak:
> > 
> > https://sourceforge.net/tracker/?func=detail&atid=560720&aid=2889570&group_id=80706
> > 
> > While this bug is now essentially fixed, I noticed
> that the Figure class contains some circular references that
> prevent it from being cleaned up by the garbage collector,
> which is effectively a memory leak. At least, for this
> code:
> > 
> >>>> from matplotlib.figure import Figure
> >>>> fig = Figure()
> >>>> del fig
> > 
> > the garbage collector reports 76 unreachable objects.
> This seems to be independent of which backend is being
> used.
> > 
> > Is it worthwhile to look deeper into it? Or should we
> accept that it is unavoidable that a library of the size of
> matplotlib will have circular references?
> > 
> 
> The purpose of the garbage collector is to handle the case
> of circular references--and mpl is full of circular
> references. When there are no circular references,
> then reference counting suffices. The garbage
> collector fails to handle circular references when an object
> has a __del__ method. I don't think we have that
> problem.
> 
> I am not actually seeing the result you describe,
> though. Using python from the interactive prompt--no
> ipython--when I do gc.collect() and then gc.get_count() I
> get back to the count from before instantiating the Figure.
> 
> >>> gc.get_count()
> (4, 0, 0)
> >>> gc.get_count()
> (5, 0, 0)
> >>> gc.get_count()
> (5, 0, 0)
> >>> gc.get_count()
> (5, 0, 0)
> >>> fig = Figure()
> >>> gc.get_count()
> (128, 0, 0)
> >>> del(fig)
> >>> gc.get_count()
> (128, 0, 0)
> >>> gc.collect()
> 76
> >>> gc.get_count()
> (4, 0, 0)
> >>> gc.get_count()
> (5, 0, 0)
> 
> Eric
> 
> > 
> > --Michiel.
> > 
> 
 

Michiel de Hoon wrote:
> Hi everybody,
> 
> I was looking at this bug about a memory leak:
> 
> https://sourceforge.net/tracker/?func=detail&atid=560720&aid=2889570&group_id=80706
> 
> While this bug is now essentially fixed, I noticed that the Figure class contains some circular references that prevent it from being cleaned up by the garbage collector, which is effectively a memory leak. At least, for this code:
> 
>>>> from matplotlib.figure import Figure
>>>> fig = Figure()
>>>> del fig
> 
> the garbage collector reports 76 unreachable objects. This seems to be independent of which backend is being used.
> 
> Is it worthwhile to look deeper into it? Or should we accept that it is unavoidable that a library of the size of matplotlib will have circular references?
> 
The purpose of the garbage collector is to handle the case of circular 
references--and mpl is full of circular references. When there are no 
circular references, then reference counting suffices. The garbage 
collector fails to handle circular references when an object has a 
__del__ method. I don't think we have that problem.
I am not actually seeing the result you describe, though. Using python 
from the interactive prompt--no ipython--when I do gc.collect() and then 
gc.get_count() I get back to the count from before instantiating the Figure.
 >>> gc.get_count()
(4, 0, 0)
 >>> gc.get_count()
(5, 0, 0)
 >>> gc.get_count()
(5, 0, 0)
 >>> gc.get_count()
(5, 0, 0)
 >>> fig = Figure()
 >>> gc.get_count()
(128, 0, 0)
 >>> del(fig)
 >>> gc.get_count()
(128, 0, 0)
 >>> gc.collect()
76
 >>> gc.get_count()
(4, 0, 0)
 >>> gc.get_count()
(5, 0, 0)
Eric
> 
> --Michiel.
> 

Hi everybody,
I was looking at this bug about a memory leak:
https://sourceforge.net/tracker/?func=detail&atid=560720&aid=2889570&group_id=80706
While this bug is now essentially fixed, I noticed that the Figure class contains some circular references that prevent it from being cleaned up by the garbage collector, which is effectively a memory leak. At least, for this code:
>>> from matplotlib.figure import Figure
>>> fig = Figure()
>>> del fig
the garbage collector reports 76 unreachable objects. This seems to be independent of which backend is being used.
Is it worthwhile to look deeper into it? Or should we accept that it is unavoidable that a library of the size of matplotlib will have circular references?
--Michiel.
 

Currently imsave (implemented in the image.py file) only deals with 
greyscale single-plane images, i.e. 2D arrays, and in my defence, it's 
in the docstring, so I wouldn't call it a bug. However, it's a 
reasonable expectation that it support rgb and rgba since it is 
basically a thin wrapper around figimage.
My first try at this was to change the line
fig = Figure(figsize=arr.shape[::-1], dpi=1, frameon=False)
to
fig = Figure(figsize=(arr.shape[1],arr.shape[0]), dpi=1, frameon=False)
since we just want to take the first two shape values.
(note figsize=arr.shape[:2][::-1] also works)
This may be all you need. My tests (in the attached test.py) appear to 
work. However, I don't think it's what you want. By default, figimage 
even expects NxMx3 and NxMx4 arrays to be float arrays nominally ranging 
from 0-1. What you probably want is a raw RGB mapping where pixel planes 
 are unsigned 8 bit values. I thought calling figimage with a 
norm=no_norm(0,255) instance achieved this but it doesn't work as I 
expect. So the first question is, what is the expected behaviour here, 
and a follow-up is does anyone here understand how to do the colour 
mapping to achieve it?
Gary
Stéfan van der Walt wrote:
> Hey all,
> 
> 2009年2月10日 Andrew Straw <str...@as...>:
>> Gary Ruben wrote:
>>> Hi Andrew,
>>>
>>> I don't have commit access. If you would check it in, that would be great.
>> Committed to the trunk in r6899... Thanks!
>>
>> And, sheesh, SourceForge's SVN server is slooow today for me, although
>> it seems to have finally improved.
> 
> While trying to write a matplotlib plugin for scikits.image, we
> noticed that `imsave` isn't currently working (that goes for the one
> in Ubuntu [0.99 I think] as well as the latest SVN):
> 
> Traceback (most recent call last):
> File "test_imsave.py", line 6, in <module>
> plt.imsave('test.jpg', img)
> File "/Users/stefan/lib/python2.6/site-packages/matplotlib/pyplot.py",
> line 1412, in imsave
> return _imsave(*args, **kwargs)
> File "/Users/stefan/lib/python2.6/site-packages/matplotlib/image.py",
> line 1025, in imsave
> fig = Figure(figsize=arr.shape[::-1], dpi=1, frameon=False)
> File "/Users/stefan/lib/python2.6/site-packages/matplotlib/figure.py",
> line 180, in __init__
> self.bbox_inches = Bbox.from_bounds(0, 0, *figsize)
> TypeError: from_bounds() takes exactly 4 arguments (5 given)
> 
> The commands needed to reproduce the error are:
> 
> import matplotlib.pyplot as plt
> import numpy as np
> 
> img = np.ones((50, 50, 3), dtype=np.uint8)
> 
> plt.imsave('test.jpg', img)
> 
> Regards
> Stéfan
>