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

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

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 = rand(20,40)

In [2]:imshow(z, aspect='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=23.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" == 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='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='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='auto', fixLimits=None,
>     Eric> aspect_adjusts='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=1 is the same as
>     Eric> aspect='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=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel