matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] Bug in print_figure with bbox_inches='tight'? Plots in ipython notebook losing titles and labels...

[Fernando P. <fpe...@gm...>]

On Sun, Jan 29, 2012 at 10:30 AM, Fernando Perez <fpe...@gm...> wrote:
> And as Jeff Whitaker points out,
> all x and  y (longitude/latitude) labels also get clipped.

I meant to put at the end of that sentence: "in the basemap example".
The simple plot has no clipping issues with labels, only with the
suptitle.

Cheers,

f

Re: [matplotlib-devel] Bug in print_figure with bbox_inches='tight'? Plots in ipython notebook losing titles and labels...

[Nathaniel S. <nj...@po...>]

On Sun, Jan 29, 2012 at 7:42 AM, Benjamin Root <ben...@ou...> wrote:
> Not a bug.  There are only so many artist objects we assume for determining the tight bbox.  Suptitle is not one of them.

Why is this the desired behavior?

-- Nathaniel

Re: [matplotlib-devel] Bug in print_figure with bbox_inches='tight'? Plots in ipython notebook losing titles and labels...

[Fernando P. <fpe...@gm...>]

On Sun, Jan 29, 2012 at 10:22 AM, Nathaniel Smith <nj...@po...> wrote:
>> Not a bug.  There are only so many artist objects we assume for determining the tight bbox.  Suptitle is not one of them.
>
> Why is this the desired behavior?

I was just going to ask the same.   And as Jeff Whitaker points out,
all x and  y (longitude/latitude) labels also get clipped.

I can understand not considering the position of arbitrarily laid out
text that a user could have put in a random location.  But clipping
something that  is provided by a standard api call, such as a figure
title, does seem much more like a bug than a feature to me, I'm afraid.

Cheers,

f

Re: [matplotlib-devel] Bug in print_figure with bbox_inches='tight'? Plots in ipython notebook losing titles and labels...

[Jeff W. <js...@fa...>]

On 1/29/12 8:42 AM, Benjamin Root wrote:
>
>
> On Sunday, January 29, 2012, Fernando Perez <fpe...@gm... 
> <mailto:fpe...@gm...>> wrote:
> > Hi all,
> >
> > in ipython for the qtconsole and notebook, we send inline figures using
> >
> > fig.canvas.print_figure(bytes_io, format=fmt, bbox_inches='tight')
> >
> > as seen here:
> >
> > 
> https://github.com/ipython/ipython/blob/master/IPython/core/pylabtools.py#L104
> >
> > However, this produces truncated figure titles.  Consider this code:
> >
> > f, ax = plt.subplots()
> > ax.plot(rand(100))
> > ax.set_title('Axis title')
> > f.suptitle('Figure title');
> >
> > ###
> >
> > which produces this in the notebook:
> >
> > http://img546.imageshack.us/img546/5448/selection001c.png
> >
> > As you can see, the figure title gets truncated.
> >
> > We started using bbox_inches='tight' because otherwise in many cases
> > the images were coming back with insane amounts of white padding, and
> > Stefan vdW suggested this fix.  But it seems that in other cases it
> > actually loses data, which is even worse...
> >
> > A slightly more complicated example, using basemap, not only truncates
> > the title but also all the x and y labels:
> >
> > from mpl_toolkits.basemap import Basemap
> >
> > lon0, lat0, lon1, lat1 = (84.38, 26.22, 88.9, 29.8)
> > resolution = 'i'
> >
> > parallels = np.linspace(lat0, lat1, 5)
> > meridians = np.linspace(lon0, lon1, 5)
> >
> > f, ax = plt.subplots()
> > m = Basemap(lon0, lat0, lon1, lat1, resolution=resolution, ax=ax)
> > m.drawcountries(color=(1,1,0))  # country boundaries in pure yellow
> > m.drawrivers(color=(0,1,1))  # rivers in cyan
> > m.bluemarble()  # NASA bluemarble image
> > m.drawmeridians(meridians, labels=[0,0,0,1], fmt='%.2f')
> > m.drawparallels(parallels, labels=[1,0,0,0], fmt='%.2f')
> > f.suptitle('The Himalayas');
> >
> > #####
> >
> > produces:
> >
> > http://img192.imageshack.us/img192/986/selection002e.png
> >
> >
> > This looks like a matplotlib bug, but I have no idea how easy it is to
> > fix.  In the meantime, should we in ipython just revert back to not
> > using bbox_inches, or is there an alternative?
> >
> > Thanks!
> >
> > f
> >
>
> Not a bug.  There are only so many artist objects we assume for 
> determining the tight bbox.  Suptitle is not one of them.  However, If 
> you collect all of the artists that you want considered, you can pass 
> in a list of them to bbox_artists (IIRC) to have them considered as well.
>
> Now, with respect to the Basemap example, there might be a bug there, 
> but it can still be worked around by passing in the list of labels to 
> the kwarg.
>
> Cheers!
> Ben Root
The lat and lon labels in Basemap are axes.text objects, which 
apparently are not considered when computing the bbox either.

-Jeff

Re: [matplotlib-devel] Bug in print_figure with bbox_inches='tight'? Plots in ipython notebook losing titles and labels...

[Benjamin R. <ben...@ou...>]

On Sunday, January 29, 2012, Fernando Perez <fpe...@gm...> wrote:
> Hi all,
>
> in ipython for the qtconsole and notebook, we send inline figures using
>
> fig.canvas.print_figure(bytes_io, format=fmt, bbox_inches='tight')
>
> as seen here:
>
>
https://github.com/ipython/ipython/blob/master/IPython/core/pylabtools.py#L104
>
> However, this produces truncated figure titles.  Consider this code:
>
> f, ax = plt.subplots()
> ax.plot(rand(100))
> ax.set_title('Axis title')
> f.suptitle('Figure title');
>
> ###
>
> which produces this in the notebook:
>
> http://img546.imageshack.us/img546/5448/selection001c.png
>
> As you can see, the figure title gets truncated.
>
> We started using bbox_inches='tight' because otherwise in many cases
> the images were coming back with insane amounts of white padding, and
> Stefan vdW suggested this fix.  But it seems that in other cases it
> actually loses data, which is even worse...
>
> A slightly more complicated example, using basemap, not only truncates
> the title but also all the x and y labels:
>
> from mpl_toolkits.basemap import Basemap
>
> lon0, lat0, lon1, lat1 = (84.38, 26.22, 88.9, 29.8)
> resolution = 'i'
>
> parallels = np.linspace(lat0, lat1, 5)
> meridians = np.linspace(lon0, lon1, 5)
>
> f, ax = plt.subplots()
> m = Basemap(lon0, lat0, lon1, lat1, resolution=resolution, ax=ax)
> m.drawcountries(color=(1,1,0))  # country boundaries in pure yellow
> m.drawrivers(color=(0,1,1))  # rivers in cyan
> m.bluemarble()  # NASA bluemarble image
> m.drawmeridians(meridians, labels=[0,0,0,1], fmt='%.2f')
> m.drawparallels(parallels, labels=[1,0,0,0], fmt='%.2f')
> f.suptitle('The Himalayas');
>
> #####
>
> produces:
>
> http://img192.imageshack.us/img192/986/selection002e.png
>
>
> This looks like a matplotlib bug, but I have no idea how easy it is to
> fix.  In the meantime, should we in ipython just revert back to not
> using bbox_inches, or is there an alternative?
>
> Thanks!
>
> f
>

Not a bug.  There are only so many artist objects we assume for determining
the tight bbox.  Suptitle is not one of them.  However, If you collect all
of the artists that you want considered, you can pass in a list of them to
bbox_artists (IIRC) to have them considered as well.

Now, with respect to the Basemap example, there might be a bug there, but
it can still be worked around by passing in the list of labels to the kwarg.

Cheers!
Ben Root

[matplotlib-devel] Bug in print_figure with bbox_inches='tight'? Plots in ipython notebook losing titles and labels...

[Fernando P. <fpe...@gm...>]

Hi all,

in ipython for the qtconsole and notebook, we send inline figures using

fig.canvas.print_figure(bytes_io, format=fmt, bbox_inches='tight')

as seen here:

https://github.com/ipython/ipython/blob/master/IPython/core/pylabtools.py#L104

However, this produces truncated figure titles.  Consider this code:

f, ax = plt.subplots()
ax.plot(rand(100))
ax.set_title('Axis title')
f.suptitle('Figure title');

###

which produces this in the notebook:

http://img546.imageshack.us/img546/5448/selection001c.png

As you can see, the figure title gets truncated.

We started using bbox_inches='tight' because otherwise in many cases
the images were coming back with insane amounts of white padding, and
Stefan vdW suggested this fix.  But it seems that in other cases it
actually loses data, which is even worse...

A slightly more complicated example, using basemap, not only truncates
the title but also all the x and y labels:

from mpl_toolkits.basemap import Basemap

lon0, lat0, lon1, lat1 = (84.38, 26.22, 88.9, 29.8)
resolution = 'i'

parallels = np.linspace(lat0, lat1, 5)
meridians = np.linspace(lon0, lon1, 5)

f, ax = plt.subplots()
m = Basemap(lon0, lat0, lon1, lat1, resolution=resolution, ax=ax)
m.drawcountries(color=(1,1,0))  # country boundaries in pure yellow
m.drawrivers(color=(0,1,1))  # rivers in cyan
m.bluemarble()  # NASA bluemarble image
m.drawmeridians(meridians, labels=[0,0,0,1], fmt='%.2f')
m.drawparallels(parallels, labels=[1,0,0,0], fmt='%.2f')
f.suptitle('The Himalayas');

#####

produces:

http://img192.imageshack.us/img192/986/selection002e.png


This looks like a matplotlib bug, but I have no idea how easy it is to
fix.  In the meantime, should we in ipython just revert back to not
using bbox_inches, or is there an alternative?

Thanks!

f

Re: [matplotlib-devel] [Matplotlib-users] Problem with cachedRenderer

[Tony Yu <ts...@gm...>]

On Wed, Jan 25, 2012 at 7:14 AM, andi <and...@go...> wrote:

>  Hi Tony,
>
> thanks for your reply! I am not using the pdf backend, but the GTKAgg
> backend. Is it working with this backend in the development version?
>
> Cheers
> Andi
>

Hi Andi,

Unfortunately, I can't run the GTKAgg backend, but I checked your code
snippet on the backends I have on my system. It seems this behavior is
really inconsistent:

Works:
* agg
* qt4agg
* tkagg

Doesn't work:
* pdf
* macosx

To be honest, I don't understand the magical workings of the backends very
well. I've copied the developer list since the consistency of backends
seems like a relevant issue.

-Tony

P.S. Andi: Be sure to "reply all" since the mailing list doesn't
automatically do this for some reason.


>
> On 25/01/12 00:26, Tony Yu wrote:
>
>
>
> On Tue, Jan 24, 2012 at 12:53 PM, andi <and...@go...> wrote:
>
>> Hi all,
>>
>> I have some old custom code for generating videos from matplotlib (not
>> using the animation module). It used to work, but is now failing.
>> Here is what I am doing:
>>
>> -------------------
>> import matplotlib.pyplot as plt
>> import numpy as np
>>
>> fig = plt.figure()
>> ax = fig.add_subplot(111)
>> im = ax.imshow(np.zeros((100, 100)))
>> fig.canvas.draw()
>> ax.draw_artist(im)
>> ------------------
>>
>> ... and draw_artist from axes.py then gives me an AssertionError because
>> no renderer is found (assert self._cachedRenderer is not None).
>>
>> Right now I am using matplotlib 1.0.1 and I think that the above used to
>> work with older versions in matplotlib. See e.g.
>>
>> http://www.mail-archive.com/mat...@li.../msg06598.html
>>
>> Any ideas?
>>
>> Cheers
>> Andi
>>
>>
> Hi Andi,
>
> I'm running a development version of matplotlib, and your code runs
> without issue. That doesn't really solve your issue, but it means that it's
> not due to deprecation.
>
> On a hunch, I tried running the code with
> >>> import matplotlib
> >>> matplotlib.use('pdf')
> at the top of the file, and I got the same error. Not really sure why,
> though. Do you happen to have the pdf backend set as the default?
>
> -Tony
>
>

Re: [matplotlib-devel] "Data cursor" for matplotilb.widgets

[Tony Yu <ts...@gm...>]

On Tue, Jan 24, 2012 at 10:12 AM, Tony Yu <ts...@gm...> wrote:

>
>
> On Sun, Jan 22, 2012 at 5:58 PM, Joe Kington <jki...@ge...>wrote:
>
>> I've recently been playing around with a widget intended to be similar to
>> matlab's "data cursor".
>>
>> Would this be useful for inclusion into matplotlib.widgets?
>>
>> https://gist.github.com/1659108
>>
>> At the moment, it doesn't inherit from the base Widget class, but that's
>> easily changed.
>>
>> On the other hand, it doesn't fit the model of the rest of the widgets in
>> that it takes a sequence (or single) artist, instead of an axes instance.
>>
>> If folks think it would be useful, I can submit a pull request.
>>
>> Thanks,
>> -Joe
>>
>
> This is pretty cool. Any idea how much work it would take to add handling
> of images?
>
> -Tony
>

Just to clarify: by "handling images", I mean displaying the intensity
value at a point (it currently just displays the x, y coordinates).

-Tony

Re: [matplotlib-devel] "Data cursor" for matplotilb.widgets

[Tony Yu <ts...@gm...>]

On Sun, Jan 22, 2012 at 5:58 PM, Joe Kington <jki...@ge...>wrote:

> I've recently been playing around with a widget intended to be similar to
> matlab's "data cursor".
>
> Would this be useful for inclusion into matplotlib.widgets?
>
> https://gist.github.com/1659108
>
> At the moment, it doesn't inherit from the base Widget class, but that's
> easily changed.
>
> On the other hand, it doesn't fit the model of the rest of the widgets in
> that it takes a sequence (or single) artist, instead of an axes instance.
>
> If folks think it would be useful, I can submit a pull request.
>
> Thanks,
> -Joe
>

This is pretty cool. Any idea how much work it would take to add handling
of images?

-Tony

[matplotlib-devel] "Data cursor" for matplotilb.widgets

[Joe K. <jki...@ge...>]

I've recently been playing around with a widget intended to be similar to
matlab's "data cursor".

Would this be useful for inclusion into matplotlib.widgets?

https://gist.github.com/1659108

At the moment, it doesn't inherit from the base Widget class, but that's
easily changed.

On the other hand, it doesn't fit the model of the rest of the widgets in
that it takes a sequence (or single) artist, instead of an axes instance.

If folks think it would be useful, I can submit a pull request.

Thanks,
-Joe

Re: [matplotlib-devel] imread() in master branch doesn't work

[Michael D. <md...@st...>]

Ah.  That explains why I couldn't reproduce it -- I didn't realize the 
issue had already been closed.

Mike

On 01/17/2012 12:53 PM, Eric Firing wrote:
> Mike,
>
> Git bisect showed that the problem was your merge commit bca1fb0; you
> were merging a changeset relative to a very old version, and I'm pretty
> sure that you accidentally kept the old version of a line.  I switched
> it back to the new version:
>
> https://github.com/matplotlib/matplotlib/commit/c9cefdcf50742fd041636b20aa48d3a821d3299d
>
> Maybe your suggested patch below is still a good idea, but I think that
> is now an independent question.
>
> Eric
>
>
> On 01/17/2012 05:37 AM, Michael Droettboom wrote:
>> I can't confirm this on RHEL5 64-bit or Fedora 16 64-bit.
>>
>> Have you tried removing the build and installed directories and
>> rebuilding from scratch?
>>
>> I'm shooting in the dark, but does the attached patch resolve your issue?
>>
>> diff --git a/src/_png.cpp b/src/_png.cpp
>> index 9437c87..c17dec9 100644
>> --- a/src/_png.cpp
>> +++ b/src/_png.cpp
>> @@ -553,7 +553,7 @@ _png_module::_read_png(const Py::Object&   py_fileobj,
>> const b
>>
>>         if (PyErr_Occurred()) {
>>             Py_DECREF((PyObject *)A);
>> -        return NULL;
>> +        throw Py::Exception();
>>         } else {
>>             return (PyObject *)A;
>>
>> Mike
>>
>> On 01/14/2012 04:51 PM, Eric Firing wrote:
>>> On 01/14/2012 09:02 AM, Benjamin Root wrote:
>>>> Tried using plt.imread() today on a PNG file, and I am getting this
>>>> PyCXX error:
>>>>
>>>> Traceback (most recent call last):
>>>>       File "<stdin>", line 1, in<module>
>>>>       File "/home/ben/Programs/matplotlib/lib/matplotlib/pyplot.py", line
>>>> 1746, in imread
>>>>         return _imread(*args, **kwargs)
>>>>       File "/home/ben/Programs/matplotlib/lib/matplotlib/image.py", line
>>>> 1218, in imread
>>>>         return handler(fd)
>>>> TypeError: PyCXX: Error creating object of type N2Py6ObjectE from (nil)
>>>>
>>>> Using master branch on Python 2.7 on 32-bit Ubuntu Oneric.  Seems to
>>>> happen to both color and b&w images.  scipy.ndimage.imread() still works
>>>> fine, though.
>>>>
>>>> Ben Root
>>> I get the same thing with master on 64-bit ubuntu natty, but not with
>>> v1.1.x.  Mike did quite a bit of work on src/_png.cpp between those two.
>>>      The most recent commit to that file is not causing the problem, but I
>>> have not tracked it down beyond that.
>>>
>>> Eric
>>>
>>> ------------------------------------------------------------------------------
>>> RSA(R) Conference 2012
>>> Mar 27 - Feb 2
>>> Save $400 by Jan. 27
>>> Register now!
>>> http://p.sf.net/sfu/rsa-sfdev2dev2
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Re: [matplotlib-devel] imread() in master branch doesn't work

[Eric F. <ef...@ha...>]

Mike,

Git bisect showed that the problem was your merge commit bca1fb0; you 
were merging a changeset relative to a very old version, and I'm pretty 
sure that you accidentally kept the old version of a line.  I switched 
it back to the new version:

https://github.com/matplotlib/matplotlib/commit/c9cefdcf50742fd041636b20aa48d3a821d3299d

Maybe your suggested patch below is still a good idea, but I think that 
is now an independent question.

Eric


On 01/17/2012 05:37 AM, Michael Droettboom wrote:
> I can't confirm this on RHEL5 64-bit or Fedora 16 64-bit.
>
> Have you tried removing the build and installed directories and
> rebuilding from scratch?
>
> I'm shooting in the dark, but does the attached patch resolve your issue?
>
> diff --git a/src/_png.cpp b/src/_png.cpp
> index 9437c87..c17dec9 100644
> --- a/src/_png.cpp
> +++ b/src/_png.cpp
> @@ -553,7 +553,7 @@ _png_module::_read_png(const Py::Object&  py_fileobj,
> const b
>
>        if (PyErr_Occurred()) {
>            Py_DECREF((PyObject *)A);
> -        return NULL;
> +        throw Py::Exception();
>        } else {
>            return (PyObject *)A;
>
> Mike
>
> On 01/14/2012 04:51 PM, Eric Firing wrote:
>> On 01/14/2012 09:02 AM, Benjamin Root wrote:
>>> Tried using plt.imread() today on a PNG file, and I am getting this
>>> PyCXX error:
>>>
>>> Traceback (most recent call last):
>>>      File "<stdin>", line 1, in<module>
>>>      File "/home/ben/Programs/matplotlib/lib/matplotlib/pyplot.py", line
>>> 1746, in imread
>>>        return _imread(*args, **kwargs)
>>>      File "/home/ben/Programs/matplotlib/lib/matplotlib/image.py", line
>>> 1218, in imread
>>>        return handler(fd)
>>> TypeError: PyCXX: Error creating object of type N2Py6ObjectE from (nil)
>>>
>>> Using master branch on Python 2.7 on 32-bit Ubuntu Oneric.  Seems to
>>> happen to both color and b&w images.  scipy.ndimage.imread() still works
>>> fine, though.
>>>
>>> Ben Root
>> I get the same thing with master on 64-bit ubuntu natty, but not with
>> v1.1.x.  Mike did quite a bit of work on src/_png.cpp between those two.
>>     The most recent commit to that file is not causing the problem, but I
>> have not tracked it down beyond that.
>>
>> Eric
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Mar 27 - Feb 2
>> Save $400 by Jan. 27
>> Register now!
>> http://p.sf.net/sfu/rsa-sfdev2dev2
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] imread() in master branch doesn't work

[Michael D. <md...@st...>]

I can't confirm this on RHEL5 64-bit or Fedora 16 64-bit.

Have you tried removing the build and installed directories and 
rebuilding from scratch?

I'm shooting in the dark, but does the attached patch resolve your issue?

diff --git a/src/_png.cpp b/src/_png.cpp
index 9437c87..c17dec9 100644
--- a/src/_png.cpp
+++ b/src/_png.cpp
@@ -553,7 +553,7 @@ _png_module::_read_png(const Py::Object& py_fileobj, 
const b

      if (PyErr_Occurred()) {
          Py_DECREF((PyObject *)A);
-        return NULL;
+        throw Py::Exception();
      } else {
          return (PyObject *)A;

Mike

On 01/14/2012 04:51 PM, Eric Firing wrote:
> On 01/14/2012 09:02 AM, Benjamin Root wrote:
>> Tried using plt.imread() today on a PNG file, and I am getting this
>> PyCXX error:
>>
>> Traceback (most recent call last):
>>     File "<stdin>", line 1, in<module>
>>     File "/home/ben/Programs/matplotlib/lib/matplotlib/pyplot.py", line
>> 1746, in imread
>>       return _imread(*args, **kwargs)
>>     File "/home/ben/Programs/matplotlib/lib/matplotlib/image.py", line
>> 1218, in imread
>>       return handler(fd)
>> TypeError: PyCXX: Error creating object of type N2Py6ObjectE from (nil)
>>
>> Using master branch on Python 2.7 on 32-bit Ubuntu Oneric.  Seems to
>> happen to both color and b&w images.  scipy.ndimage.imread() still works
>> fine, though.
>>
>> Ben Root
> I get the same thing with master on 64-bit ubuntu natty, but not with
> v1.1.x.  Mike did quite a bit of work on src/_png.cpp between those two.
>    The most recent commit to that file is not causing the problem, but I
> have not tracked it down beyond that.
>
> Eric
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Re: [matplotlib-devel] imread() in master branch doesn't work

[Eric F. <ef...@ha...>]

On 01/14/2012 09:02 AM, Benjamin Root wrote:
> Tried using plt.imread() today on a PNG file, and I am getting this
> PyCXX error:
>
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/home/ben/Programs/matplotlib/lib/matplotlib/pyplot.py", line
> 1746, in imread
>      return _imread(*args, **kwargs)
>    File "/home/ben/Programs/matplotlib/lib/matplotlib/image.py", line
> 1218, in imread
>      return handler(fd)
> TypeError: PyCXX: Error creating object of type N2Py6ObjectE from (nil)
>
> Using master branch on Python 2.7 on 32-bit Ubuntu Oneric.  Seems to
> happen to both color and b&w images.  scipy.ndimage.imread() still works
> fine, though.
>
> Ben Root

I get the same thing with master on 64-bit ubuntu natty, but not with 
v1.1.x.  Mike did quite a bit of work on src/_png.cpp between those two. 
  The most recent commit to that file is not causing the problem, but I 
have not tracked it down beyond that.

Eric

[matplotlib-devel] imread() in master branch doesn't work

[Benjamin R. <ben...@ou...>]

Tried using plt.imread() today on a PNG file, and I am getting this PyCXX
error:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ben/Programs/matplotlib/lib/matplotlib/pyplot.py", line 1746,
in imread
    return _imread(*args, **kwargs)
  File "/home/ben/Programs/matplotlib/lib/matplotlib/image.py", line 1218,
in imread
    return handler(fd)
TypeError: PyCXX: Error creating object of type N2Py6ObjectE from (nil)

Using master branch on Python 2.7 on 32-bit Ubuntu Oneric.  Seems to happen
to both color and b&w images.  scipy.ndimage.imread() still works fine,
though.

Ben Root

Re: [matplotlib-devel] Test invitation: activate figure windows for non-interactive macosx backend

[Tony Yu <ts...@gm...>]

On Fri, Jan 13, 2012 at 6:32 PM, Gellule Xg <gel...@fr...> wrote:

> On 1/13/12 12:53 , Tony Yu wrote:
>
>>
>> On Thu, Jan 12, 2012 at 1:37 PM, Gellule Xg <gel...@fr...
>> <mailto:gel...@fr...>> wrote:
>>
>>    If you are a macosx backend user, you are welcomed to test the
>> following
>>    branch: https://github.com/gellule/**matplotlib<https://github.com/gellule/matplotlib>.
>> With the branch, when
>>    issuing a pylab.show() in non-interactive mode, the plot windows should
>>    appear in the foreground with focus, instead of appearing in the
>>    background. It should make things a little easier for you.
>>
>>
>> This works as advertised on my system (plot window grabs focus when
>> running scripts in MacVim, Terminal, and IPython when in non-interactive
>> mode). Unfortunately, I tend to use the QT4Agg backend, which also
>> leaves plot windows in the background. Maybe I'd switch to the macosx
>> backend with this addition.
>>
>
> Thanks!
>
>     I am also curious to know what people think of making pylab.show() also
>>    yield the focus to the plot windows in -interactive- mode? All the
>> other
>>    commands update the plot windows automatically, keeping the focus in
>> the
>>    python interpreter. So pylab.show() would only do that: yield the focus
>>    to the plot windows. That is not in the branch (yet).
>>
>>
>> I'd lean toward no: the plot window shouldn't grab focus in interactive
>> mode. I have some scripts that take command-line input in-between plot
>> calls. If the plot window grabbed focus, then I'd have to switch focus
>> back to enter input. This probably isn't a common use case, though.
>>
>
> But you don't use show() in interactive mode, do you? The focus grab would
> not happen until you call show().
>
> I other words, show() would always send the focus to the plot windows. But
> depending on how interactive is set, it would block or not. If you are in
> interactive mode and don't want to send the focus to the plot windows, you
> would have to not call show().
>
> -Julien
>

Good point: my scripts call draw(), instead of show(). Ignore what I said
earlier. :)

-Tony

Re: [matplotlib-devel] Test invitation: activate figure windows for non-interactive macosx backend

[Gellule Xg <gel...@fr...>]

On 1/13/12 12:53 , Tony Yu wrote:
>
> On Thu, Jan 12, 2012 at 1:37 PM, Gellule Xg <gel...@fr...
> <mailto:gel...@fr...>> wrote:
>
>     If you are a macosx backend user, you are welcomed to test the following
>     branch: https://github.com/gellule/matplotlib. With the branch, when
>     issuing a pylab.show() in non-interactive mode, the plot windows should
>     appear in the foreground with focus, instead of appearing in the
>     background. It should make things a little easier for you.
>
>
> This works as advertised on my system (plot window grabs focus when
> running scripts in MacVim, Terminal, and IPython when in non-interactive
> mode). Unfortunately, I tend to use the QT4Agg backend, which also
> leaves plot windows in the background. Maybe I'd switch to the macosx
> backend with this addition.

Thanks!

>     I am also curious to know what people think of making pylab.show() also
>     yield the focus to the plot windows in -interactive- mode? All the other
>     commands update the plot windows automatically, keeping the focus in the
>     python interpreter. So pylab.show() would only do that: yield the focus
>     to the plot windows. That is not in the branch (yet).
>
>
> I'd lean toward no: the plot window shouldn't grab focus in interactive
> mode. I have some scripts that take command-line input in-between plot
> calls. If the plot window grabbed focus, then I'd have to switch focus
> back to enter input. This probably isn't a common use case, though.

But you don't use show() in interactive mode, do you? The focus grab 
would not happen until you call show().

I other words, show() would always send the focus to the plot windows. 
But depending on how interactive is set, it would block or not. If you 
are in interactive mode and don't want to send the focus to the plot 
windows, you would have to not call show().

-Julien

Re: [matplotlib-devel] Test invitation: activate figure windows for non-interactive macosx backend

[Tony Yu <ts...@gm...>]

On Thu, Jan 12, 2012 at 1:37 PM, Gellule Xg <gel...@fr...> wrote:

> If you are a macosx backend user, you are welcomed to test the following
> branch: https://github.com/gellule/matplotlib. With the branch, when
> issuing a pylab.show() in non-interactive mode, the plot windows should
> appear in the foreground with focus, instead of appearing in the
> background. It should make things a little easier for you.
>

This works as advertised on my system (plot window grabs focus when running
scripts in MacVim, Terminal, and IPython when in non-interactive mode).
Unfortunately, I tend to use the QT4Agg backend, which also leaves plot
windows in the background. Maybe I'd switch to the macosx backend with this
addition.


> I am also curious to know what people think of making pylab.show() also
> yield the focus to the plot windows in -interactive- mode? All the other
> commands update the plot windows automatically, keeping the focus in the
> python interpreter. So pylab.show() would only do that: yield the focus
> to the plot windows. That is not in the branch (yet).
>

I'd lean toward no: the plot window shouldn't grab focus in interactive
mode. I have some scripts that take command-line input in-between plot
calls. If the plot window grabbed focus, then I'd have to switch focus back
to enter input. This probably isn't a common use case, though.

-Tony


>
> Cheers,
>
> -Gellule/Julien
>
>

[matplotlib-devel] Test invitation: activate figure windows for non-interactive macosx backend

[Gellule Xg <gel...@fr...>]

If you are a macosx backend user, you are welcomed to test the following 
branch: https://github.com/gellule/matplotlib. With the branch, when 
issuing a pylab.show() in non-interactive mode, the plot windows should 
appear in the foreground with focus, instead of appearing in the 
background. It should make things a little easier for you.

I am also curious to know what people think of making pylab.show() also 
yield the focus to the plot windows in -interactive- mode? All the other 
commands update the plot windows automatically, keeping the focus in the 
python interpreter. So pylab.show() would only do that: yield the focus 
to the plot windows. That is not in the branch (yet).

Cheers,

-Gellule/Julien

Re: [matplotlib-devel] should the ordering of clf() matter for AxesGrid?

[Mike K. <mc...@gm...>]

Ok, this was my bad. I was under the [mistaken] impression (and in 
retrospect I'm not sure why) that the AxesGrid call just set up the 
geometry and the plot calls actually created the axes.

Thanks for setting me straight.

M

On 1/11/12 9:05 PM, Paul Ivanov wrote:
> Hi Mike,
>
> Mike Kaufman, on 2012-01-11 19:30,  wrote:
>> Given the code snippet below with clf() #1 uncommented works like one
>> would expect - both plots are drawn. If #1 is commented out and #2 is
>> uncommented, then the figure is cleared and neither plot is drawn. Is
>> this the correct behavior? It seems like a bug to me.
>
> Seems to me like this is the intended behavior and not a bug. I'm
> not sure what you were expecting to happen with that second call
> to clf. You're clearing the whole figure, so even though the
> axes you have in the grid variable have references to f, f has
> disowned them!
>
>    In [39]: grid = AxesGrid(f, 111, (1,2))
>
>    In [40]: f.axes
>    Out[40]:
>    [<mpl_toolkits.axes_grid1.axes_divider.LocatableAxes at 0xb7c002c>,
>     <mpl_toolkits.axes_grid1.axes_divider.LocatableAxes at 0xb8948cc>,
>     <mpl_toolkits.axes_grid1.axes_grid.CbarAxes at 0xb810dac>,
>     <mpl_toolkits.axes_grid1.axes_grid.CbarAxes at 0xb97486c>]
>
>    In [41]: plt.clf()
>
>    In [42]: f.axes
>    Out[42]: []
>
> Perhaps you wanted to simply to clear the individual axes? You
> can do that with [g.cla() for g in grid] instead of your call to
> plt.clf()
>
> best,

Re: [matplotlib-devel] should the ordering of clf() matter for AxesGrid?

[Paul I. <piv...@gm...>]

Hi Mike,

Mike Kaufman, on 2012-01-11 19:30,  wrote:
> Given the code snippet below with clf() #1 uncommented works like one 
> would expect - both plots are drawn. If #1 is commented out and #2 is 
> uncommented, then the figure is cleared and neither plot is drawn. Is 
> this the correct behavior? It seems like a bug to me.

Seems to me like this is the intended behavior and not a bug. I'm
not sure what you were expecting to happen with that second call
to clf. You're clearing the whole figure, so even though the
axes you have in the grid variable have references to f, f has
disowned them!

  In [39]: grid = AxesGrid(f, 111, (1,2))
  
  In [40]: f.axes
  Out[40]: 
  [<mpl_toolkits.axes_grid1.axes_divider.LocatableAxes at 0xb7c002c>,
   <mpl_toolkits.axes_grid1.axes_divider.LocatableAxes at 0xb8948cc>,
   <mpl_toolkits.axes_grid1.axes_grid.CbarAxes at 0xb810dac>,
   <mpl_toolkits.axes_grid1.axes_grid.CbarAxes at 0xb97486c>]
  
  In [41]: plt.clf()
  
  In [42]: f.axes
  Out[42]: []

Perhaps you wanted to simply to clear the individual axes? You
can do that with [g.cla() for g in grid] instead of your call to
plt.clf()

best,
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

[matplotlib-devel] should the ordering of clf() matter for AxesGrid?

[Mike K. <mc...@gm...>]

Given the code snippet below with clf() #1 uncommented works like one 
would expect - both plots are drawn. If #1 is commented out and #2 is 
uncommented, then the figure is cleared and neither plot is drawn. Is 
this the correct behavior? It seems like a bug to me.

M


import numpy as np
import matplotlib.pyplot as plt
from mpl_toolkits.axes_grid1 import AxesGrid

f = plt.figure(1)
plt.clf() #1
grid = AxesGrid(f, 111, (1,2))
#plt.clf()  #2
grid[0].plot(np.arange(10))
grid[1].plot(np.arange(10))
plt.draw()

Re: [matplotlib-devel] documentation error at http://matplotlib.sourceforge.net/examples/api/fahrenheit_celcius_scales.html

[Paul I. <piv...@gm...>]

Paul Ivanov, on 2012-01-09 13:56,  wrote:
> kei...@bt..., on 2012-01-09 11:47,  wrote:
> > "Celsius" is spelled wrongly every time.
> 
> Thanks for the report, Keith, I'm taking care of this right now.

Done.
https://github.com/matplotlib/matplotlib/commit/e0cf45ed01a9a098a9acbde177812dd9ceee7ec9

-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

Re: [matplotlib-devel] documentation error at http://matplotlib.sourceforge.net/examples/api/fahrenheit_celcius_scales.html

[Paul I. <piv...@gm...>]

kei...@bt..., on 2012-01-09 11:47,  wrote:
> "Celsius" is spelled wrongly every time.

Thanks for the report, Keith, I'm taking care of this right now.

-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

[matplotlib-devel] documentation error at http://matplotlib.sourceforge.net/examples/api/fahrenheit_celcius_scales.html

[<kei...@bt...>]

"Celsius" is spelled wrongly every time.

Keith