[matplotlib-devel] Some keys generate tracebacks in the GTK backend
Hi, Pressing tab, the "Windows" key or the right click key (and maybe others) on a plot with the GTKAgg or GTK backend causes the following traceback: Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", line 264, in key_press_event FigureCanvasBase.key_press_event(self, key, guiEvent=event) File "/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", line 1459, in key_press_event self.callbacks.process(s, event) File "/usr/lib/python2.5/site-packages/matplotlib/cbook.py", line 259, in process proxy(*args, **kwargs) File "/usr/lib/python2.5/site-packages/matplotlib/cbook.py", line 185, in __call__ return mtd(*args, **kwargs) File "/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", line 2079, in key_press if event.key in fullscreen_keys: TypeError: 'in ' requires string as left operand This happens because in these cases the key is None. The WXAgg backend doesn't have this bug (I haven't tested qt nor tk backends). Debian Squeeze (testing) using Python 2.5 and the latest mpl SVN (rev 8360). Regards, João Silva -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh
On Mon, May 31, 2010 at 11:28 AM, Benjamin Root wrote: > Markus, > > That is good to know that it has been fixed. As for the difference in > pcolor and pcolormesh, I think it has to do with the fact that pcolormesh is > composed of many lines while pcolor is composed of many polygons. It is > probably more efficient to rasterize polygons than lines. To be blunt, this makes no sense whatsoever. First, pcolormesh and pcolor differ in that it pcolor uses a generic PolyCollection to draw the quads, while pcolormesh uses a quadmesh object, which can be more efficient at the cost of generality, as it only needs to render a set of identical quads. Second, if you're talking rasterized drawing, in the end what gets written to a file is a 2D array of RGBA values. It doesn't matter what you use to produce the results: identical image on the screen -> identical array in file. It's possible that there are slight differences that you can't really see that produce different arrays, but that won't cause a factor of 8 difference in size. My guess is that pcolormesh isn't rasterizing properly. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh
On Tue, Jun 1, 2010 at 9:39 AM, Ryan May wrote: > On Mon, May 31, 2010 at 11:28 AM, Benjamin Root wrote: > > Markus, > > > > That is good to know that it has been fixed. As for the difference in > > pcolor and pcolormesh, I think it has to do with the fact that pcolormesh > is > > composed of many lines while pcolor is composed of many polygons. It is > > probably more efficient to rasterize polygons than lines. > > To be blunt, this makes no sense whatsoever. First, pcolormesh and > pcolor differ in that it pcolor uses a generic PolyCollection to draw > the quads, while pcolormesh uses a quadmesh object, which can be more > efficient at the cost of generality, as it only needs to render a set > of identical quads. Second, if you're talking rasterized drawing, in > the end what gets written to a file is a 2D array of RGBA values. It > doesn't matter what you use to produce the results: identical image on > the screen -> identical array in file. It's possible that there are > slight differences that you can't really see that produce different > arrays, but that won't cause a factor of 8 difference in size. My > guess is that pcolormesh isn't rasterizing properly. > > Indeed, you are right that lines aren't drawn. I have looked back at the images produced by my test script that I posted to this thread and I see where I got confused. The pcolormesh result in pdf and eps files have very faint white blocks around each quad. At high enough data resolution, the color part of the quads look like lines while the white lines look like dots. This happens regardless of using rasterized=True or not, and I don't think it is visible in png files (although I am testing some very high resolution png files to verify). Ben Root -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh
It seems that pcolormesh silently ignores some of the keyword parameters, and "rasterized" is one of them. And I'm not sure this is intended behavior or not and I hope other developers step in. In the meantime, use a member method explicitly. p2 = pcolormesh(arr) p2.set_rasterized(True) Regards, -JJ On Tue, Jun 1, 2010 at 12:05 PM, Benjamin Root wrote: > > > On Tue, Jun 1, 2010 at 9:39 AM, Ryan May wrote: >> >> On Mon, May 31, 2010 at 11:28 AM, Benjamin Root wrote: >> > Markus, >> > >> > That is good to know that it has been fixed. As for the difference in >> > pcolor and pcolormesh, I think it has to do with the fact that >> > pcolormesh is >> > composed of many lines while pcolor is composed of many polygons. It is >> > probably more efficient to rasterize polygons than lines. >> >> To be blunt, this makes no sense whatsoever. First, pcolormesh and >> pcolor differ in that it pcolor uses a generic PolyCollection to draw >> the quads, while pcolormesh uses a quadmesh object, which can be more >> efficient at the cost of generality, as it only needs to render a set >> of identical quads. Second, if you're talking rasterized drawing, in >> the end what gets written to a file is a 2D array of RGBA values. It >> doesn't matter what you use to produce the results: identical image on >> the screen -> identical array in file. It's possible that there are >> slight differences that you can't really see that produce different >> arrays, but that won't cause a factor of 8 difference in size. My >> guess is that pcolormesh isn't rasterizing properly. >> > Indeed, you are right that lines aren't drawn. I have looked back at the > images produced by my test script that I posted to this thread and I see > where I got confused. The pcolormesh result in pdf and eps files have very > faint white blocks around each quad. At high enough data resolution, the > color part of the quads look like lines while the white lines look like > dots. This happens regardless of using rasterized=True or not, and I don't > think it is visible in png files (although I am testing some very high > resolution png files to verify). > > Ben Root > > -- > > > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh
Confirmed. This might also explain some other behaviors I have noticed with pcolormesh and rasterized=True. Ben Root On Tue, Jun 1, 2010 at 11:18 AM, Jae-Joon Lee wrote: > It seems that pcolormesh silently ignores some of the keyword > parameters, and "rasterized" is one of them. And I'm not sure this is > intended behavior or not and I hope other developers step in. > > In the meantime, use a member method explicitly. > > p2 = pcolormesh(arr) > p2.set_rasterized(True) > > Regards, > > -JJ > > > On Tue, Jun 1, 2010 at 12:05 PM, Benjamin Root wrote: > > > > > > On Tue, Jun 1, 2010 at 9:39 AM, Ryan May wrote: > >> > >> On Mon, May 31, 2010 at 11:28 AM, Benjamin Root > wrote: > >> > Markus, > >> > > >> > That is good to know that it has been fixed. As for the difference in > >> > pcolor and pcolormesh, I think it has to do with the fact that > >> > pcolormesh is > >> > composed of many lines while pcolor is composed of many polygons. It > is > >> > probably more efficient to rasterize polygons than lines. > >> > >> To be blunt, this makes no sense whatsoever. First, pcolormesh and > >> pcolor differ in that it pcolor uses a generic PolyCollection to draw > >> the quads, while pcolormesh uses a quadmesh object, which can be more > >> efficient at the cost of generality, as it only needs to render a set > >> of identical quads. Second, if you're talking rasterized drawing, in > >> the end what gets written to a file is a 2D array of RGBA values. It > >> doesn't matter what you use to produce the results: identical image on > >> the screen -> identical array in file. It's possible that there are > >> slight differences that you can't really see that produce different > >> arrays, but that won't cause a factor of 8 difference in size. My > >> guess is that pcolormesh isn't rasterizing properly. > >> > > Indeed, you are right that lines aren't drawn. I have looked back at the > > images produced by my test script that I posted to this thread and I see > > where I got confused. The pcolormesh result in pdf and eps files have > very > > faint white blocks around each quad. At high enough data resolution, the > > color part of the quads look like lines while the white lines look like > > dots. This happens regardless of using rasterized=True or not, and I > don't > > think it is visible in png files (although I am testing some very high > > resolution png files to verify). > > > > Ben Root > > > > > -- > > > > > > ___ > > Matplotlib-devel mailing list > > Matplotlib-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] basemap domain changes on pyplot call
I have since switched over to the svn checkout of basemap, and this issue appears to be 'fixed'. While readshapefile() does still load all of the data, it appears that .set_axes_limits() automatically turns off autoscaling. This should cut down on much of the "odd" behaviors users would encounter. FWIW, I was using v0.99.2 from the Fedora repos. Ben Root On Fri, May 21, 2010 at 4:57 PM, Benjamin Root wrote: > I did some more digging and I think I have a hypothesis for what is > happening. > > There is only one main difference between a call to .drawstates() and > .readshapefiles() with respect to loading and plotting data. .drawstates() > loads *only* the line segments that coincide with the defined map > boundaries, while .readshapefiles() loads all of the data in the shapefile. > Therefore, the LineCollection that gets attached to the axis contains data > from outside the stated domain. > > In addition, the basemap versions of the plotting functions have the > benefit of finishing their calls with a call to .set_axes_limits(), which > keeps the axes in check. However, a non-basemap version would not call that > automatically, thereby having its axes automatically expanded to contain all > of the data in the LineCollection. > > I am not sure what exactly should be done about this. This is certainly > un-intuitive behavior, though. Maybe there could be a keyword option in > .readshapefile() to have only the data for the stated domain loaded? That > might solve the issue. > > Thanks, > Ben Root > > > On Fri, May 21, 2010 at 4:08 PM, Benjamin Root wrote: > >> Hello, >> >> I have been tracking down an annoying (but easily worked around) issue >> with Basemap. It seems that if you call .readshapefile() to create, for >> example, roads on your image, and then call any pyplot command afterwards >> for that axis, the axis will reset itself to the entire domain (I guess it >> would be the complete domain stated in the shapefile, maybe?). This does >> not happen if you call the equivalent function from the Basemap instance, >> though. Also, this does not happen with drawstates() and its ilk. >> >> I have made a test script and a couple of supporting shapefile in a tar.gz >> file to demonstrate the issue. It is available here: >> http://dl.dropbox.com/u/7325604/basemaptest.tar.gz >> >> >> I have also attached a png file showing the resulting image as it appears >> on my computer. I have no clue as to the cause and I hope that someone here >> might have an idea. >> >> Thanks, >> Ben Root >> > > -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh
Correction -- the problem with pcolormesh and the faint white lines are occurring for pdf and svg files, *not* eps files as I originally stated. I am also checking a number of display backends and found that the problem occurs for GTKCairo. I am sure it also happens for TkAgg, but I can not confirm that right now. I am unable to test the Mac backends, though. On a side note, when testing the backends, I noticed that GTKCairo was *slow* for displaying the figures. Also, the GTK backend produced misaligned titles. I can start a new thread about the misaligned titles, if someone wishes. Ben Root On Tue, Jun 1, 2010 at 11:05 AM, Benjamin Root wrote: > > > On Tue, Jun 1, 2010 at 9:39 AM, Ryan May wrote: > >> On Mon, May 31, 2010 at 11:28 AM, Benjamin Root wrote: >> > Markus, >> > >> > That is good to know that it has been fixed. As for the difference in >> > pcolor and pcolormesh, I think it has to do with the fact that >> pcolormesh is >> > composed of many lines while pcolor is composed of many polygons. It is >> > probably more efficient to rasterize polygons than lines. >> >> To be blunt, this makes no sense whatsoever. First, pcolormesh and >> pcolor differ in that it pcolor uses a generic PolyCollection to draw >> the quads, while pcolormesh uses a quadmesh object, which can be more >> efficient at the cost of generality, as it only needs to render a set >> of identical quads. Second, if you're talking rasterized drawing, in >> the end what gets written to a file is a 2D array of RGBA values. It >> doesn't matter what you use to produce the results: identical image on >> the screen -> identical array in file. It's possible that there are >> slight differences that you can't really see that produce different >> arrays, but that won't cause a factor of 8 difference in size. My >> guess is that pcolormesh isn't rasterizing properly. >> >> Indeed, you are right that lines aren't drawn. I have looked back at the > images produced by my test script that I posted to this thread and I see > where I got confused. The pcolormesh result in pdf and eps files have very > faint white blocks around each quad. At high enough data resolution, the > color part of the quads look like lines while the white lines look like > dots. This happens regardless of using rasterized=True or not, and I don't > think it is visible in png files (although I am testing some very high > resolution png files to verify). > > Ben Root > -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Is there a way to link axes of imshow plots?
On a related note, I have noticed an incompatibility between AxesGrid and
Basemap. It appears that Basemap will explicitly set adjustable='box' when
it calls ax.set_aspect(), but AxesGrid will error out, saying that it has to
be 'datalim'. What are the implications of using 'box-forced' instead of
'box' in Basemap?
Ben Root
On Thu, May 27, 2010 at 1:59 PM, Jae-Joon Lee wrote:
> ax1 = subplot(121)
> ax2 = subplot(122, sharex=ax1, sharey=ax1)
>
> ax1.set_adjustable("box-forced")
> ax2.set_adjustable("box-forced")
>
> arr1 = np.arange(100).reshape((10, 10))
> ax1.imshow(arr1)
>
> arr2 = np.arange(100, 0, -1).reshape((10, 10))
> ax2.imshow(arr2)
>
> Note the use of set_adjustable("box-forced").
> sharex and sharey does not get along with axes of aspect=1 &
> adjustable="box".
>
> -JJ
>
>
>
> On Thu, May 27, 2010 at 2:10 PM, wrote:
> > Do the “sharex” and “sharey” kwargs help?
> >
> >
> http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.axes
> >
> >
> http://matplotlib.sourceforge.net/examples/pylab_examples/shared_axis_demo.html
> >
> > -paul
> >
> >
> >
> > From: Adam Fraser [mailto:adam.n.fra...@gmail.com]
> > Sent: Thursday, May 27, 2010 10:44 AM
> > To: matplotlib-users
> > Subject: [Matplotlib-users] Is there a way to link axes of imshow plots?
> >
> >
> >
> > Suppose I have a figure canvas with 3 plots... 2 are images of the same
> > dimensions plotted with imshow, and the other is a scatterplot. I'd like
> to
> > be able to link the x and y axes of the imshow plots so that when I zoom
> in
> > one, the other zooms to the same coordinates, and when I pan in one, the
> > other pans as well.
> >
> >
> >
> > I started hacking my way around this by
> subclassing NavigationToolbar2WxAgg
> > (shown below)... but there are several problems here.
> >
> > 1) This will link the axes of all plots in a canvas since all I've done
> is
> > get rid of the checks for a.in_axes()
> >
> > 2) This worked well for panning, but zooming caused all subplots to zoom
> > from the same global point, rather than from the same point in each of
> their
> > respective axes.
> >
> >
> >
> > Can anyone suggest a workaround?
> >
> >
> >
> > Much thanks!
> >
> > -Adam
> >
> >
> >
> > from matplotlib.backends.backend_wxagg import NavigationToolbar2WxAgg as
> > NavigationToolbar
> >
> > class MyNavToolbar(NavigationToolbar):
> >
> > def __init__(self, canvas, cpfig):
> >
> > NavigationToolbar.__init__(self, canvas)
> >
> >
> >
> > # override
> >
> > def press_pan(self, event):
> >
> > 'the press mouse button in pan/zoom mode callback'
> >
> >
> >
> > if event.button == 1:
> >
> > self._button_pressed=1
> >
> > elif event.button == 3:
> >
> > self._button_pressed=3
> >
> > else:
> >
> > self._button_pressed=None
> >
> > return
> >
> >
> >
> > x, y = event.x, event.y
> >
> >
> >
> > # push the current view to define home if stack is empty
> >
> > if self._views.empty(): self.push_current()
> >
> >
> >
> > self._xypress=[]
> >
> > for i, a in enumerate(self.canvas.figure.get_axes()):
> >
> > # only difference from overridden method is that this one
> > doesn't
> >
> > # check a.in_axes(event)
> >
> > if x is not None and y is not None and a.get_navigate():
> >
> > a.start_pan(x, y, event.button)
> >
> > self._xypress.append((a, i))
> >
> > self.canvas.mpl_disconnect(self._idDrag)
> >
> >
> self._idDrag=self.canvas.mpl_connect('motion_notify_event',
> > self.drag_pan)
> >
> >
> >
> > def press_zoom(self, event):
> >
> > 'the press mouse button in zoom to rect mode callback'
> >
> > if event.button == 1:
> >
> > self._button_pressed=1
> >
> > elif event.button == 3:
> >
> > self._button_pressed=3
> >
> > else:
> >
> > self._button_pressed=None
> >
> > return
> >
> >
> >
> > x, y = event.x, event.y
> >
> >
> >
> > # push the current view to define home if stack is empty
> >
> > if self._views.empty(): self.push_current()
> >
> >
> >
> > self._xypress=[]
> >
> > for i, a in enumerate(self.canvas.figure.get_axes()):
> >
> > # only difference from overridden method is that this one
> > doesn't
> >
> > # check a.in_axes(event)
> >
> > if x is not None and y is not None and a.get_navigate() and
> > a.can_zoom():
> >
> > self._xypress.append(( x, y, a, i, a.viewLim.frozen(),
> > a.transData.frozen()))
> >
> >
> >
> > self.press(event)
> >
> >
> >
> >
> >
> >
> >
> >
> --
> >
> >
> > ___
> > Matplotlib-users mailing list
> > matplotlib-us...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/
Re: [matplotlib-devel] [Matplotlib-users] Is there a way to link axes of imshow plots?
If Basemap explicitly sets aspect=1 and adjustable="box" at the same
time, you cannot use this with any axes that shares its axis with
others (including the axes created by the AxesGrid).
You need to somehow avoid the set_aspect call with adjustable"box"
(you can set box-forced in stead).
-JJ
On Tue, Jun 1, 2010 at 2:45 PM, Benjamin Root wrote:
>
> On a related note, I have noticed an incompatibility between AxesGrid and
> Basemap. It appears that Basemap will explicitly set adjustable='box' when
> it calls ax.set_aspect(), but AxesGrid will error out, saying that it has to
> be 'datalim'. What are the implications of using 'box-forced' instead of
> 'box' in Basemap?
>
> Ben Root
>
> On Thu, May 27, 2010 at 1:59 PM, Jae-Joon Lee wrote:
>>
>> ax1 = subplot(121)
>> ax2 = subplot(122, sharex=ax1, sharey=ax1)
>>
>> ax1.set_adjustable("box-forced")
>> ax2.set_adjustable("box-forced")
>>
>> arr1 = np.arange(100).reshape((10, 10))
>> ax1.imshow(arr1)
>>
>> arr2 = np.arange(100, 0, -1).reshape((10, 10))
>> ax2.imshow(arr2)
>>
>> Note the use of set_adjustable("box-forced").
>> sharex and sharey does not get along with axes of aspect=1 &
>> adjustable="box".
>>
>> -JJ
>>
>>
>>
>> On Thu, May 27, 2010 at 2:10 PM, wrote:
>> > Do the “sharex” and “sharey” kwargs help?
>> >
>> >
>> > http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.axes
>> >
>> >
>> > http://matplotlib.sourceforge.net/examples/pylab_examples/shared_axis_demo.html
>> >
>> > -paul
>> >
>> >
>> >
>> > From: Adam Fraser [mailto:adam.n.fra...@gmail.com]
>> > Sent: Thursday, May 27, 2010 10:44 AM
>> > To: matplotlib-users
>> > Subject: [Matplotlib-users] Is there a way to link axes of imshow plots?
>> >
>> >
>> >
>> > Suppose I have a figure canvas with 3 plots... 2 are images of the same
>> > dimensions plotted with imshow, and the other is a scatterplot. I'd like
>> > to
>> > be able to link the x and y axes of the imshow plots so that when I zoom
>> > in
>> > one, the other zooms to the same coordinates, and when I pan in one, the
>> > other pans as well.
>> >
>> >
>> >
>> > I started hacking my way around this by
>> > subclassing NavigationToolbar2WxAgg
>> > (shown below)... but there are several problems here.
>> >
>> > 1) This will link the axes of all plots in a canvas since all I've done
>> > is
>> > get rid of the checks for a.in_axes()
>> >
>> > 2) This worked well for panning, but zooming caused all subplots to zoom
>> > from the same global point, rather than from the same point in each of
>> > their
>> > respective axes.
>> >
>> >
>> >
>> > Can anyone suggest a workaround?
>> >
>> >
>> >
>> > Much thanks!
>> >
>> > -Adam
>> >
>> >
>> >
>> > from matplotlib.backends.backend_wxagg import NavigationToolbar2WxAgg as
>> > NavigationToolbar
>> >
>> > class MyNavToolbar(NavigationToolbar):
>> >
>> > def __init__(self, canvas, cpfig):
>> >
>> > NavigationToolbar.__init__(self, canvas)
>> >
>> >
>> >
>> > # override
>> >
>> > def press_pan(self, event):
>> >
>> > 'the press mouse button in pan/zoom mode callback'
>> >
>> >
>> >
>> > if event.button == 1:
>> >
>> > self._button_pressed=1
>> >
>> > elif event.button == 3:
>> >
>> > self._button_pressed=3
>> >
>> > else:
>> >
>> > self._button_pressed=None
>> >
>> > return
>> >
>> >
>> >
>> > x, y = event.x, event.y
>> >
>> >
>> >
>> > # push the current view to define home if stack is empty
>> >
>> > if self._views.empty(): self.push_current()
>> >
>> >
>> >
>> > self._xypress=[]
>> >
>> > for i, a in enumerate(self.canvas.figure.get_axes()):
>> >
>> > # only difference from overridden method is that this one
>> > doesn't
>> >
>> > # check a.in_axes(event)
>> >
>> > if x is not None and y is not None and a.get_navigate():
>> >
>> > a.start_pan(x, y, event.button)
>> >
>> > self._xypress.append((a, i))
>> >
>> > self.canvas.mpl_disconnect(self._idDrag)
>> >
>> >
>> > self._idDrag=self.canvas.mpl_connect('motion_notify_event',
>> > self.drag_pan)
>> >
>> >
>> >
>> > def press_zoom(self, event):
>> >
>> > 'the press mouse button in zoom to rect mode callback'
>> >
>> > if event.button == 1:
>> >
>> > self._button_pressed=1
>> >
>> > elif event.button == 3:
>> >
>> > self._button_pressed=3
>> >
>> > else:
>> >
>> > self._button_pressed=None
>> >
>> > return
>> >
>> >
>> >
>> > x, y = event.x, event.y
>> >
>> >
>> >
>> > # push the current view to define home if stack is empty
>> >
>> > if self._views.empty(): self.push_current()
>> >
>> >
>> >
>> > self._xypress=[]
>> >
>> > for i, a in enumerate(self.canvas.figure.get_axes()):
>> >
>> > # only difference from overridden method is that this one
>> > doesn't
>> >
>> >
Re: [matplotlib-devel] [Matplotlib-users] Is there a way to link axes of imshow plots?
Right, that is sort of what I am asking. My thinking is that Basemap could
use 'box-forced' instead of 'box' for the adjustable parameter in order to
make it and AxesGrid compatible. Usually, if one wants to use AxesGrid,
they all should have the same domain and aspect ratio. I just have no clue
what sort of repricussions that has for other use cases.
So far, this has worked just fine for me, but I hardly represent the normal
use cases of Basemap and AxesGrid.
Ben Root
On Tue, Jun 1, 2010 at 5:20 PM, Jae-Joon Lee wrote:
> If Basemap explicitly sets aspect=1 and adjustable="box" at the same
> time, you cannot use this with any axes that shares its axis with
> others (including the axes created by the AxesGrid).
>
> You need to somehow avoid the set_aspect call with adjustable"box"
> (you can set box-forced in stead).
>
> -JJ
>
>
> On Tue, Jun 1, 2010 at 2:45 PM, Benjamin Root wrote:
> >
> > On a related note, I have noticed an incompatibility between AxesGrid and
> > Basemap. It appears that Basemap will explicitly set adjustable='box'
> when
> > it calls ax.set_aspect(), but AxesGrid will error out, saying that it has
> to
> > be 'datalim'. What are the implications of using 'box-forced' instead of
> > 'box' in Basemap?
> >
> > Ben Root
> >
> > On Thu, May 27, 2010 at 1:59 PM, Jae-Joon Lee
> wrote:
> >>
> >> ax1 = subplot(121)
> >> ax2 = subplot(122, sharex=ax1, sharey=ax1)
> >>
> >> ax1.set_adjustable("box-forced")
> >> ax2.set_adjustable("box-forced")
> >>
> >> arr1 = np.arange(100).reshape((10, 10))
> >> ax1.imshow(arr1)
> >>
> >> arr2 = np.arange(100, 0, -1).reshape((10, 10))
> >> ax2.imshow(arr2)
> >>
> >> Note the use of set_adjustable("box-forced").
> >> sharex and sharey does not get along with axes of aspect=1 &
> >> adjustable="box".
> >>
> >> -JJ
> >>
> >>
> >>
> >> On Thu, May 27, 2010 at 2:10 PM, wrote:
> >> > Do the “sharex” and “sharey” kwargs help?
> >> >
> >> >
> >> >
> http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.axes
> >> >
> >> >
> >> >
> http://matplotlib.sourceforge.net/examples/pylab_examples/shared_axis_demo.html
> >> >
> >> > -paul
> >> >
> >> >
> >> >
> >> > From: Adam Fraser [mailto:adam.n.fra...@gmail.com]
> >> > Sent: Thursday, May 27, 2010 10:44 AM
> >> > To: matplotlib-users
> >> > Subject: [Matplotlib-users] Is there a way to link axes of imshow
> plots?
> >> >
> >> >
> >> >
> >> > Suppose I have a figure canvas with 3 plots... 2 are images of the
> same
> >> > dimensions plotted with imshow, and the other is a scatterplot. I'd
> like
> >> > to
> >> > be able to link the x and y axes of the imshow plots so that when I
> zoom
> >> > in
> >> > one, the other zooms to the same coordinates, and when I pan in one,
> the
> >> > other pans as well.
> >> >
> >> >
> >> >
> >> > I started hacking my way around this by
> >> > subclassing NavigationToolbar2WxAgg
> >> > (shown below)... but there are several problems here.
> >> >
> >> > 1) This will link the axes of all plots in a canvas since all I've
> done
> >> > is
> >> > get rid of the checks for a.in_axes()
> >> >
> >> > 2) This worked well for panning, but zooming caused all subplots to
> zoom
> >> > from the same global point, rather than from the same point in each of
> >> > their
> >> > respective axes.
> >> >
> >> >
> >> >
> >> > Can anyone suggest a workaround?
> >> >
> >> >
> >> >
> >> > Much thanks!
> >> >
> >> > -Adam
> >> >
> >> >
> >> >
> >> > from matplotlib.backends.backend_wxagg import NavigationToolbar2WxAgg
> as
> >> > NavigationToolbar
> >> >
> >> > class MyNavToolbar(NavigationToolbar):
> >> >
> >> > def __init__(self, canvas, cpfig):
> >> >
> >> > NavigationToolbar.__init__(self, canvas)
> >> >
> >> >
> >> >
> >> > # override
> >> >
> >> > def press_pan(self, event):
> >> >
> >> > 'the press mouse button in pan/zoom mode callback'
> >> >
> >> >
> >> >
> >> > if event.button == 1:
> >> >
> >> > self._button_pressed=1
> >> >
> >> > elif event.button == 3:
> >> >
> >> > self._button_pressed=3
> >> >
> >> > else:
> >> >
> >> > self._button_pressed=None
> >> >
> >> > return
> >> >
> >> >
> >> >
> >> > x, y = event.x, event.y
> >> >
> >> >
> >> >
> >> > # push the current view to define home if stack is empty
> >> >
> >> > if self._views.empty(): self.push_current()
> >> >
> >> >
> >> >
> >> > self._xypress=[]
> >> >
> >> > for i, a in enumerate(self.canvas.figure.get_axes()):
> >> >
> >> > # only difference from overridden method is that this one
> >> > doesn't
> >> >
> >> > # check a.in_axes(event)
> >> >
> >> > if x is not None and y is not None and a.get_navigate():
> >> >
> >> > a.start_pan(x, y, event.button)
> >> >
> >> > self._xypress.append((a, i))
> >> >
> >> > self.canvas.mpl_disconnect(self._idDrag)
> >> >
> >> >
> >> > self._idDrag=self.canvas.
[matplotlib-devel] Passing errorbar width arguments to bar/barh ?
Hi all, I just spent some time digging through the matplotlib code, and I see that the errorbar line width argument isn't passed through to the underlying call. In axis.bar, we have this code: if xerr is not None or yerr is not None: if orientation == 'vertical': # using list comps rather than arrays to preserve unit info x = [l+0.5*w for l, w in zip(left, width)] y = [b+h for b,h in zip(bottom, height)] elif orientation == 'horizontal': # using list comps rather than arrays to preserve unit info x = [l+w for l,w in zip(left, width)] y = [b+0.5*h for b,h in zip(bottom, height)] self.errorbar( x, y, yerr=yerr, xerr=xerr, fmt=None, ecolor=ecolor, capsize=capsize) while errorbar has this signature: def errorbar(self, x, y, yerr=None, xerr=None, fmt='-', ecolor=None, elinewidth=None, capsize=3, barsabove=False, lolims=False, uplims=False, xlolims=False, xuplims=False, **kwargs): For a poster, we wanted thicker errorbars drawn and had to resort to: plt.rcParams['lines.markeredgewidth'] = 2 plt.rcParams['lines.linewidth'] = 2 and reverting back to normal width after making the errorbar calls. Should I file a ticket about this, or are such fine-tuning tasks considered as fair game for rcParams manipulations? I'm happy to file the ticket, I just don't want to create unnecessary noise if the rcparams is meant to be 'the way' to do it. Cheers, f -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?
On 06/01/2010 01:17 PM, Fernando Perez wrote: > Hi all, > > I just spent some time digging through the matplotlib code, and I see > that the errorbar line width argument isn't passed through to the > underlying call. In axis.bar, we have this code: > > if xerr is not None or yerr is not None: > if orientation == 'vertical': > # using list comps rather than arrays to preserve unit info > x = [l+0.5*w for l, w in zip(left, width)] > y = [b+h for b,h in zip(bottom, height)] > > elif orientation == 'horizontal': > # using list comps rather than arrays to preserve unit info > x = [l+w for l,w in zip(left, width)] > y = [b+0.5*h for b,h in zip(bottom, height)] > > self.errorbar( > x, y, > yerr=yerr, xerr=xerr, > fmt=None, ecolor=ecolor, capsize=capsize) > > while errorbar has this signature: > > def errorbar(self, x, y, yerr=None, xerr=None, > fmt='-', ecolor=None, elinewidth=None, capsize=3, > barsabove=False, lolims=False, uplims=False, > xlolims=False, xuplims=False, **kwargs): > > For a poster, we wanted thicker errorbars drawn and had to resort to: > > plt.rcParams['lines.markeredgewidth'] = 2 > plt.rcParams['lines.linewidth'] = 2 > > and reverting back to normal width after making the errorbar calls. > Should I file a ticket about this, or are such fine-tuning tasks > considered as fair game for rcParams manipulations? No, that seems like a terrible kluge--not at all what rcParams is for. bar, errorbar, hist could use some major refactoring. In the meantime, since bar simply calls errorbar, it seems to me that the solution is for bar to take a kwarg, say "errorkw", which is a dict that will be passed to errorbar via **errorkw, and that can have any valid errorbar kwargs in it. There is some precedent for this sort of thing, and I find it a useful way of keeping kwargs from getting out of control when one is making complicated compound plots. If there is no objection, I will do it. Eric > > I'm happy to file the ticket, I just don't want to create unnecessary > noise if the rcparams is meant to be 'the way' to do it. > > Cheers, > > f > > -- > > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?
I just took a look at bar() and errorbar(). bar() has linewidth and uses it properly (I believe), except in the case where one specifies yerr/xerr (it doesn't pass on kwargs nor does it apply the linewidth parameter). Then looking at errorbar(), there is a kwarg called 'elinewidth' which superceeds 'linewidth' if it is set. Yet, I see no other use of 'elinewidth', only 'linewidth' in a dict called lines_kw. I am not sure if I see the point in having a parameter called 'elinewidth' (unless one wanted to make a distinction between the width of the bar's lines and the width of the line for the caps?), but that might be a side-issue. I am not convinced that adding a dictionary argument to bar() would make much sense. Why not simply pass the kwargs to errorbar()? That way, if one wanted to use yerr/xerr, they could also include elinewidth and others if they wish (or, even better, let linewidth and other parameters go back through since those represent the user's intention in the first place). Just my two cents, Ben Root On Tue, Jun 1, 2010 at 6:35 PM, Eric Firing wrote: > On 06/01/2010 01:17 PM, Fernando Perez wrote: > > Hi all, > > > > I just spent some time digging through the matplotlib code, and I see > > that the errorbar line width argument isn't passed through to the > > underlying call. In axis.bar, we have this code: > > > > if xerr is not None or yerr is not None: > > if orientation == 'vertical': > > # using list comps rather than arrays to preserve unit > info > > x = [l+0.5*w for l, w in zip(left, width)] > > y = [b+h for b,h in zip(bottom, height)] > > > > elif orientation == 'horizontal': > > # using list comps rather than arrays to preserve unit > info > > x = [l+w for l,w in zip(left, width)] > > y = [b+0.5*h for b,h in zip(bottom, height)] > > > > self.errorbar( > > x, y, > > yerr=yerr, xerr=xerr, > > fmt=None, ecolor=ecolor, capsize=capsize) > > > > while errorbar has this signature: > > > > def errorbar(self, x, y, yerr=None, xerr=None, > > fmt='-', ecolor=None, elinewidth=None, capsize=3, > > barsabove=False, lolims=False, uplims=False, > > xlolims=False, xuplims=False, **kwargs): > > > > For a poster, we wanted thicker errorbars drawn and had to resort to: > > > > plt.rcParams['lines.markeredgewidth'] = 2 > > plt.rcParams['lines.linewidth'] = 2 > > > > and reverting back to normal width after making the errorbar calls. > > Should I file a ticket about this, or are such fine-tuning tasks > > considered as fair game for rcParams manipulations? > > No, that seems like a terrible kluge--not at all what rcParams is for. > bar, errorbar, hist could use some major refactoring. In the meantime, > since bar simply calls errorbar, it seems to me that the solution is for > bar to take a kwarg, say "errorkw", which is a dict that will be passed > to errorbar via **errorkw, and that can have any valid errorbar kwargs > in it. There is some precedent for this sort of thing, and I find it a > useful way of keeping kwargs from getting out of control when one is > making complicated compound plots. > > If there is no objection, I will do it. > > Eric > > > > > I'm happy to file the ticket, I just don't want to create unnecessary > > noise if the rcparams is meant to be 'the way' to do it. > > > > Cheers, > > > > f > > > > > -- > > > > ___ > > Matplotlib-devel mailing list > > Matplotlib-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > -- > > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?
On Tue, Jun 1, 2010 at 4:35 PM, Eric Firing wrote: > it seems to me that the solution is for > bar to take a kwarg, say "errorkw", which is a dict that will be passed > to errorbar via **errorkw, and that can have any valid errorbar kwargs > in it. There is some precedent for this sort of thing, and I find it a > useful way of keeping kwargs from getting out of control when one is > making complicated compound plots. That would be my suggessted approach as well, I've used it elsewhere. > If there is no objection, I will do it. Fabulous, many thanks! Cheers, f -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh
I have finally managed to test against TkAgg, and the faint white lines do not appear to occur. So, as far as I can tell (no clue about Macs), the GTKCairo, pdf and svg backends have this display bug. Shall I file a bug report for this and another for the misaligned title? Ben Root On Tue, Jun 1, 2010 at 1:07 PM, Benjamin Root wrote: > Correction -- the problem with pcolormesh and the faint white lines are > occurring for pdf and svg files, *not* eps files as I originally stated. I > am also checking a number of display backends and found that the problem > occurs for GTKCairo. I am sure it also happens for TkAgg, but I can not > confirm that right now. I am unable to test the Mac backends, though. > > On a side note, when testing the backends, I noticed that GTKCairo was > *slow* for displaying the figures. Also, the GTK backend produced > misaligned titles. I can start a new thread about the misaligned titles, if > someone wishes. > > Ben Root > > > On Tue, Jun 1, 2010 at 11:05 AM, Benjamin Root wrote: > >> >> >> On Tue, Jun 1, 2010 at 9:39 AM, Ryan May wrote: >> >>> On Mon, May 31, 2010 at 11:28 AM, Benjamin Root wrote: >>> > Markus, >>> > >>> > That is good to know that it has been fixed. As for the difference in >>> > pcolor and pcolormesh, I think it has to do with the fact that >>> pcolormesh is >>> > composed of many lines while pcolor is composed of many polygons. It >>> is >>> > probably more efficient to rasterize polygons than lines. >>> >>> To be blunt, this makes no sense whatsoever. First, pcolormesh and >>> pcolor differ in that it pcolor uses a generic PolyCollection to draw >>> the quads, while pcolormesh uses a quadmesh object, which can be more >>> efficient at the cost of generality, as it only needs to render a set >>> of identical quads. Second, if you're talking rasterized drawing, in >>> the end what gets written to a file is a 2D array of RGBA values. It >>> doesn't matter what you use to produce the results: identical image on >>> the screen -> identical array in file. It's possible that there are >>> slight differences that you can't really see that produce different >>> arrays, but that won't cause a factor of 8 difference in size. My >>> guess is that pcolormesh isn't rasterizing properly. >>> >>> Indeed, you are right that lines aren't drawn. I have looked back at the >> images produced by my test script that I posted to this thread and I see >> where I got confused. The pcolormesh result in pdf and eps files have very >> faint white blocks around each quad. At high enough data resolution, the >> color part of the quads look like lines while the white lines look like >> dots. This happens regardless of using rasterized=True or not, and I don't >> think it is visible in png files (although I am testing some very high >> resolution png files to verify). >> >> Ben Root >> > > -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
