Re: [matplotlib-devel] Change to aspect ratio handling

[Mark B. <ma...@gm...>]

Eric -

Good to see you are taking aspect ratio handling to the next level.
Your proposed changes sound good.

Regarding the 'fixLimits', this was implemented as the aspect ratio handlin=
g
was
different when the axes limits were fixed or not. Having them fixed is
exceedingly useful,
and used by quite a few people, as far as I know. But I understand this wil=
l
still be possible.

The code never worked when the window was resized interactively. Am I
understaning you
correctly that the new code does this correctly? Across backends? That woul=
d
be very nice.

The set_aspect function is called from axis() in pylab.py and I think
somewhere in backend_basics after a zoom event.

Let me know when you uploaded stuff that is ready for testing and I'll give
it a try,

Mark

On 3/20/06, Eric Firing <ef...@ha...> wrote:
>
> John, Mark, Fernando, Nikolai,
>
> I decided to go ahead with the next stage: I committed a few more
> changes so that I think imshow will now work the way people would like.
>    To see the basic behavior most quickly, fire up ipython and do
>
> In [1]:z =3D rand(20,40)
>
> In [2]:imshow(z, aspect=3D'auto')
> Out[2]:<matplotlib.image.AxesImage instance at 0xb5be81ec>
>
> In [3]:imshow(z)
> Out[3]:<matplotlib.image.AxesImage instance at 0xb5c02c0c>
>
> In the first case, as you resize the window with the mouse, the aspect
> ratio will change with the window.  In the second case, the aspect ratio
> will be 1:1 regardless of what you do, including zooming.  I made the
> second case the default because it seems to me that an image normally is
> meant to be viewed with a 1:1 aspect ratio--with square pixels.  (I am
> assuming the display pixels are square, or close enough to it.)
>
> (You could also do imshow(z, aspect=3D23.7), for example; you can specify
> any stretch factor you want.)
>
> I left matshow with the 'auto' behavior, which is the default for
> ordinary axes, and which was its original behavior.  If you would prefer
> 'equal' (1:1), or following the rc['image.aspect'], I would be happy to
> make that change.
>
> Testing and comments are invited.
>
> Thanks.
>
> Eric
>
>
>
> John Hunter wrote:
> >>>>>>"Eric" =3D=3D Eric Firing <ef...@ha...> writes:
> >
> >
> >     Eric> All, Motivated in part by an old patch (1233294) submitted
> >     Eric> to sourceforge by Nikolai Hlubek, I took a look at how
> >     Eric> aspect ratio is handled in mpl, and concluded it wasn't
> >     Eric> quite right:
> >
> > Just a few quick comments since I haven't had a chance to look over
> > this in any detail.
> >
> >     Eric> 1) The aspect=3D'preserve' kwarg in image caused the image to
> >     Eric> retain its aspect ratio only with some resize events, not
> >     Eric> with all.  The implementation in the image.py code does not
> >     Eric> look right to me.
> >
> >
> >
> >     Eric> Therefore I have reworked the aspect-handling code in
> >     Eric> axes.py, and I think it is working reasonably well.  Indeed,
> >     Eric> I don't see any remaining need for an "aspect" kwarg in
> >     Eric> image.py, and I would like to take it out unless someone
> >     Eric> raises an objection.
> >
> > The aspect handling of images has been known to be broken from the
> > early days, but in those days we didn't even have aspect=3D'equal'
> > functionality, and so adding preserved aspect ratio proved to
> > daunting.  Noone has revisited the issue (until now) since Mark Bakkar
> > finally (mostly) got proper aspect handling in the axes.  So your
> > observations are on target, and the image aspect handling is an
> > anachronism that everyone quickly learned to ignore.
> >
> >     Eric>      def set_aspect(self, aspect=3D'auto', fixLimits=3DNone,
> >     Eric> aspect_adjusts=3D'position'): """ aspect: 'auto' - automatic;
> >     Eric> fill position rectangle with data 'normal' - same as 'auto';
> >     Eric> deprecated 'equal' - same scaling from data to plot units
> >     Eric> for x and y A - a circle will be stretched such that the
> >     Eric> height is A times the width. aspect=3D1 is the same as
> >     Eric> aspect=3D'equal'.
> >
> > Mark Bakkar wrote most of the aspect handling for the axes, and so he
> > can response most intelligently to these changes.  You should send him
> > your original post since he may not be on this list.  He's CCd above.
> >
> >     Eric> One question: is there an easy way to automatically trigger
> >     Eric> a redraw in an interactive backend (e.g. ipython with
> >     Eric> gtkagg) at the end of the set_aspect() method, for example?
> >     Eric> The way it works now is that one can make a plot, call the
> >     Eric> set_aspect() method on the resulting axes object, and the
> >     Eric> result will appear as soon as the window is manipulated with
> >     Eric> the mouse; but this manipulation is needed to trigger a
> >     Eric> redraw.
> >
> > You should be able to do something like
> >
> >   if rcParams['interactive']:
> >      self.figure.canvas.draw()
> >
> > where self is an Axes instance.  Untested, but I think it is valid
> > across backends.
> >
> > Thanks for the submission -- I look forward to testing it.
> >
> > JDH
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> > that extends applications into web and mobile media. Attend the live
> webcast
> > and join the prime developer group breaking into this new coding
> territory!
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>