Re: [matplotlib-devel] Qt4 backend: critical bug with PyQt4 v4.6+
>
> On Wed, Nov 4, 2009 at 5:29 PM, Pierre Raybaut wrote:
>
>> > A simpler fix would be:
>> >
>> > ? ? ? ?class FigureWindow(QtGui.QMainWindow):
>> > ? ? ? ? ? ?def __init__(self):
>> > ? ? ? ? ? ? ? ?super(FigureWindow, self).__init__()
>> >
>> > ? ? ? ? ? ?def closeEvent(self, event):
>> > ? ? ? ? ? ? ? ?super(FigureWindow, self).closeEvent(event)
>> > ? ? ? ? ? ? ? ?self.emit(QtCore.SIGNAL('destroyed()'))
>> >
>> > and replacing QtGui.QMainWindow by FigureWindow in FigureManagerQT.
>>
>
> I am pretty sure this is not caused by matplotlib, but rather a
> regression in PyQt4 that will be fixed in the next release. There is a
> post on the PyQt mailing list titled "Regressions on destruction of
> objects?" and a note in the development snapshots changelog. If I try
> your example with PyQt4-4.5.4, it works fine, but it crashes with
> 4.6.1. I will revisit the issue once PyQt4-4.7 is released.
>
> Darren
>
I completely agree -- in the meantime I checked that despite the
QMainWindow instance has been destroyed, the 'destroyed()' signal is not
emitted, so the problem is definitely coming from PyQt4, not matplotlib.
However, to help unfortunate users of PyQt4 v4.6 and v4.6.1, I've added
the following workaround in Spyder (Spyder is monkey patching matplotlib
anyway, to integrate mpl dockable figures in Spyder's GUI) -- other
users may be interested to patch their matplotlib installation
(matplotlib/backends/backend_qt4.py):
# Add this before "FigureManagerQT" class
class FigureWindow(QMainWindow):
def __init__(self):
super(FigureWindow, self).__init__()
def closeEvent(self, event):
super(FigureWindow, self).closeEvent(event)
if PYQT_VERSION_STR.startswith('4.6'):
self.emit(SIGNAL('destroyed()'))
# Replace "QtGui.QMainWindow" by "FigureWindow" in "FigureManagerQT"'s
constructor
I hope this will be fixed in v4.6.2.
Cheers,
Pierre
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Error building docs from the source
Hello,
The latest check-out gives an error while trying to build the documentation.
Hitting "q" in pdb prompt resumes the execution and finishes the creation
successfully.
[gse...@ccn doc]$ python make.py all
Running Sphinx v0.6.2
loading pickled environment... done
animation, api, axes_grid, event_handling, misc, mplot3d, pngsuite,
pylab_examples, tests, units, user_interfaces, widgets,
building [html]: targets for 470 source files that are out of date
updating environment: 0 added, 13 changed, 0 removed
generating thumbnails... Exception occurred while building, starting
debugger:
Traceback (most recent call last):
File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/cmdline.py",
line 172, in main
app.build(all_files, filenames)
File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/application.py",
line 130, in build
self.builder.build_update()
File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py",
line 265, in build_update
'out of date' % len(to_build))
File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py",
line 285, in build
purple, length):
File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/builders/__init__.py",
line 131, in status_iterator
for item in iterable:
File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/environment.py",
line 527, in update_generator
app.emit('env-updated', self)
File
"/usr/lib/python2.6/site-packages/Sphinx-0.6.2-py2.6.egg/sphinx/application.py",
line 222, in emit
result.append(callback(self, *args))
File
"/home/gsever/Desktop/python-repo/matplotlib/doc/sphinxext/gen_gallery.py",
line 112, in gen_gallery
pool.map(make_thumbnail, thumbnails.iteritems())
File "/usr/lib/python2.6/multiprocessing/pool.py", line 148, in map
return self.map_async(func, iterable, chunksize).get()
File "/usr/lib/python2.6/multiprocessing/pool.py", line 422, in get
raise self._value
TypeError: PyCXX: Error creating object of type N2Py7SeqBaseINS_4CharEEE
from
> /usr/lib/python2.6/multiprocessing/pool.py(422)get()
-> raise self._value
(Pdb)
--
Gökhan
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Qt4 backend: critical bug with PyQt4 v4.6+
On Sat, Nov 7, 2009 at 9:53 AM, Pierre Raybaut wrote:
>>
>> On Wed, Nov 4, 2009 at 5:29 PM, Pierre Raybaut
>> wrote:
>>
>>>
>>> > A simpler fix would be:
>>> >
>>> > ? ? ? ?class FigureWindow(QtGui.QMainWindow):
>>> > ? ? ? ? ? ?def __init__(self):
>>> > ? ? ? ? ? ? ? ?super(FigureWindow, self).__init__()
>>> >
>>> > ? ? ? ? ? ?def closeEvent(self, event):
>>> > ? ? ? ? ? ? ? ?super(FigureWindow, self).closeEvent(event)
>>> > ? ? ? ? ? ? ? ?self.emit(QtCore.SIGNAL('destroyed()'))
>>> >
>>> > and replacing QtGui.QMainWindow by FigureWindow in FigureManagerQT.
>>>
>>
>> I am pretty sure this is not caused by matplotlib, but rather a
>> regression in PyQt4 that will be fixed in the next release. There is a
>> post on the PyQt mailing list titled "Regressions on destruction of
>> objects?" and a note in the development snapshots changelog. If I try
>> your example with PyQt4-4.5.4, it works fine, but it crashes with
>> 4.6.1. I will revisit the issue once PyQt4-4.7 is released.
>>
>> Darren
>>
>
> I completely agree -- in the meantime I checked that despite the QMainWindow
> instance has been destroyed, the 'destroyed()' signal is not emitted, so the
> problem is definitely coming from PyQt4, not matplotlib.
>
> However, to help unfortunate users of PyQt4 v4.6 and v4.6.1, I've added the
> following workaround in Spyder (Spyder is monkey patching matplotlib anyway,
> to integrate mpl dockable figures in Spyder's GUI) -- other users may be
> interested to patch their matplotlib installation
> (matplotlib/backends/backend_qt4.py):
>
> # Add this before "FigureManagerQT" class
> class FigureWindow(QMainWindow):
> def __init__(self):
> super(FigureWindow, self).__init__() def closeEvent(self,
> event):
> super(FigureWindow, self).closeEvent(event)
> if PYQT_VERSION_STR.startswith('4.6'):
> self.emit(SIGNAL('destroyed()'))
> # Replace "QtGui.QMainWindow" by "FigureWindow" in "FigureManagerQT"'s
> constructor
>
> I hope this will be fixed in v4.6.2.
Me too. And thank you for posting the report and a workaround.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imsave function
Hey all,
2009/2/10 Andrew Straw :
> 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
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
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imsave function
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 :
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
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
def imsave(fname, arr, vmin=None, vmax=None, cmap=None, format=None,
origin=None):
"""
Saves a 2D :class:`numpy.array` as an image with one pixel per element.
The output formats available depend on the backend being used.
Arguments:
*fname*:
A string containing a path to a filename, or a Python file-like object.
If *format* is *None* and *fname* is a string, the output
format is deduced from the extension of the filename.
*arr*:
A 2D array.
Keyword arguments:
*vmin*/*vmax*: [ None | scalar ]
*vmin* and *vmax* set the color scaling for the image by fixing the
values that map to the colormap color limits. If either *vmin* or *vmax*
is None, that limit is determined from the *arr* min/max value.
*cmap*:
cmap is a colors.Colormap instance, eg cm.jet.
If None, default to the rc image.cmap value.
*format*:
One of the file extensions supported by the active
backend. Most backends support png, pdf, ps, eps and svg.
*origin*
[ 'upper' | 'lower' ] Indicates where the [0,0] index of
the array is in the upper left or lower left corner of
the axes. Defaults to the rc image.origin value.
"""
from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
from matplotlib.figure import Figure
fig = Figure(figsize=arr.shape[::-1], dpi=1, frameon=False)
canvas = FigureCanvas(fig)
fig.figimage(arr, cmap=cmap, vmin=vmin, vmax=vmax, origin=origin)
fig.savefig(fname, dpi=1, format=format)
def newimsave(fname, arr, vmin=None, vmax=None, cmap=None, format=None,
origin=None):
from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
from matplotlib.figure import Figure
fig = Figure(figsize=arr.shape[:2][::-1], dpi=1, frameon=False)
canvas = FigureCanvas(fig)
fig.figimage(arr, cmap=cmap, vmin=vmin, vmax=vmax, origin=origin)
fig.savefig(fname, dpi=1, format=format)
import numpy as np
import matplotlib.pyplot as plt
from my_plottools import newimsave
arr = np.empty((20,20,3),dtype=np.uint16)
arr[...,0] = np.tri(20)*255/3
arr[...,1] = arr[:,::-1,0]
arr[...,2] = arr[::-1,:,0]
newimsave(r'd:\temp\test1.png', arr)
arr = np.empty((20,30,3),dtype=np.uint16)
arr[...,0] = np.outer(np.linspace(0,255,20), np.ones(30))
arr[...,1] = np.outer(np.ones(20), np.linspace(0,255,30))
arr[...,2] = np.outer(np.linspace(0,np.sqrt(255),20),
np.linsp
[matplotlib-devel] Circular references in Figure
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. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Circular references in Figure
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. > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Circular references in Figure
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 wrote: > From: Eric Firing > Subject: Re: [matplotlib-devel] Circular references in Figure > To: "Michiel de Hoon" > Cc: matplotlib-devel@lists.sourceforge.net > 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. > > > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
