matplotlib-devel Mailing List for matplotlib

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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

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 <lee...@gm...> 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 <ben...@ou...> 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 <lee...@gm...>
> 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,  <PH...@ge...> 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:ada...@gm...]
> >> > 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
> >> > Mat...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >> >
> >> >
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Matplotlib-users mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

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 <ben...@ou...> 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 <lee...@gm...> 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,  <PH...@ge...> 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:ada...@gm...]
>> > 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
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

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 <lee...@gm...> 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,  <PH...@ge...> 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:ada...@gm...]
> > 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
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

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 <ben...@ou...> wrote:

>
>
> On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rm...@gm...> wrote:
>
>> On Mon, May 31, 2010 at 11:28 AM, Benjamin Root <ben...@ou...> 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
>

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 <ben...@ou...> 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 <ben...@ou...> 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
>>
>
>

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 <lee...@gm...> 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 <ben...@ou...> wrote:
> >
> >
> > On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rm...@gm...> wrote:
> >>
> >> On Mon, May 31, 2010 at 11:28 AM, Benjamin Root <ben...@ou...>
> 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
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
>

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 <ben...@ou...> wrote:
>
>
> On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rm...@gm...> wrote:
>>
>> On Mon, May 31, 2010 at 11:28 AM, Benjamin Root <ben...@ou...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rm...@gm...> wrote:

> On Mon, May 31, 2010 at 11:28 AM, Benjamin Root <ben...@ou...> 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

On Mon, May 31, 2010 at 11:28 AM, Benjamin Root <ben...@ou...> 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

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 <string>' 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

Hello,

I have developed a package that uses matplotlib.

To simplify installation and distribution I have used the setup tools 
package.

This is an excerpt from my setup.py:

    install_requires = ['biopython>=1.51', 'scipy>=0.7', 'numpy>=1.3.0', 
'matplotlib>=0.99.0']

However it fails on matplolib with the following reason:

Searching for matplotlib==0.99.0
Reading http://pypi.python.org/simple/matplotlib/
Reading http://matplotlib.sourceforge.net
Reading http://sourceforge.net/project/showfiles.php?group_id=80706
Reading 
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
Reading 
https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
Reading 
https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474
Reading 
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/
No local packages or download links found for matplotlib==0.99.0
error: Could not find suitable distribution for 
Requirement.parse('matplotlib==0.99.0')

I have also tried 0.99.1 but it also fails.

Does anyone have any ideas?

Regards

Mitchell Stanton-Cook