Hello Eric,
First of all: great job done with imshow()! works great!
When playing around with it we noticed a little problem propably due to a
rounding error. It is quite good to see when using a backend like GTK (axes
aren't antialiased there).
When running the code below you can see a white line at the bottom
which won't disappear even when moving the plot.
import matplotlib
matplotlib.use('GTKAgg')
from pylab import show, imshow, rand
z = rand(20,20)
imshow(z,aspect='auto')
show()
So again: great job with the aspectratio but I just wanted to state this one.
Nikolai and Martin
Sorry that I have not been involved much in the reworking of the
aspect ratio handling, but I have been travelling (I know, what
an excuse is that).
Regarding the options used, the 'equal' option mimics matlab, both
in functionality and in name. Besides, I think it is not a bad descriptor,
so my vote is to keep it.
The 'scaled' term I made up. It might be a bad word, but the functionality
is much more useful IMHO in that it keeps the limits on the axes
and it changes the size of the plotting area such that the axes are scaled.
The 'equal' option is surely a pain in the ass to use I think, as any time
you add something to the damn figure, it will reset the axes limits. But,
if former matlab users want it, I don't mind keeping it.
I'll try to find time to test Eric's new implementation soon. Thanks for
all the hard work,
Mark
Helge Avlesen wrote:
> On 3/22/06, Eric Firing <ef...@ha...> wrote:
>
>>unintuitive. Maybe we could find better names than 'equal' and
>>'scaled', for example. Even with the docstrings, I have a hard time
>>keeping track of which is supposed to do what.
>
>
> Hi,
> I think it would be nice if pylab "semantics" were kept close to matlab.
> Maybe for instance axis('scaled') could be renamed to axis('image'), and
> use similar wording as mathworks documentation in the docstrings?
>
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/axis.html
>
> Helge
Helge,
I understand the sentiment, but I don't always agree with it; while I
don't want to do things differently from Matlab just for the sake of
being different (except insofar is it may be necessary to avoid
violating copyright), neither do I want to slavishly follow Matlab.
Pylab/matplotlib can and should be better than Matlab. (And is in many
respects.)
In the case of Matlab's axis command, the Matlab documentation makes my
head spin, and the whole command strikes me as too complicated for
anyone's good. I don't think every possible capability should go into
the pylab interface; past a certain point, it is better to simply call
axis methods, etc.
For now, I have added an axis('image') mode, which is not quite the same
as 'scaled', and I have tried to improve the descriptions of the
options. Please try out the various axis modes, and see if you think
both the behavior and the descriptions make sense.
Eric
Mark,
Mark Bakker wrote:
> Sorry that I have not been involved much in the reworking of the
> aspect ratio handling, but I have been travelling (I know, what
> an excuse is that).
>
> Regarding the options used, the 'equal' option mimics matlab, both
> in functionality and in name. Besides, I think it is not a bad descriptor,
> so my vote is to keep it.
>
> The 'scaled' term I made up. It might be a bad word, but the functionality
> is much more useful IMHO in that it keeps the limits on the axes
> and it changes the size of the plotting area such that the axes are scaled.
> The 'equal' option is surely a pain in the ass to use I think, as any time
> you add something to the damn figure, it will reset the axes limits. But,
> if former matlab users want it, I don't mind keeping it.
I am getting more comfortable with 'scaled' now. The problem is that
neither 'equal' nor 'scaled' is as obvious as one would like. Both set
the data aspect ratio to 1, the first by changing the plot box
dimensions and the second by changing the data view limits, but this is
not obvious from the usage axis('equal') and axis('scaled'). It may be
the best we can do, so I don't mind leaving it. Both 'equal' and
'scaled' functionality have important uses.
The Axes.set_aspect method is more verbose and expressive:
def set_aspect(self, aspect, adjustable=None, anchor=None):
"""
aspect:
'auto' - automatic; fill position rectangle with data
'normal' - same as 'auto'; deprecated
'equal' - same scaling from data to plot units for x and y
num - a circle will be stretched such that the height
is num times the width. aspect=1 is the same as
aspect='equal'.
adjustable:
'box' - change physical size of axes
'datalim' - change xlim or ylim
anchor:
'C' - centered
'SW' - lower left corner
'S' - middle of bottom edge
'SE' - lower right corner
etc.
ACCEPTS: ['auto' | 'equal' | aspect_ratio]
"""
The kwargs also have their own set methods; the kwargs are included in
set_aspect so that it can be used to set everything in one line.
I see now that I need to add to the docstring the clarification that the
anchor kwarg is active only for adjustable=box.
Jeff,
This is where I put the plot-box location option. I used the Tk-style
"anchoring" terminology because it seems to me to be very compact,
expressive, and easy to remember. Unfortunately, it differs from what
is used in the legend command. If there is any sentiment that it would
be desirable, I could make legend understand it as well, for the sake of
consistency.
I have not tried to load the anchor options into the pylab axis command;
I think this would be making it too complicated, for no real benefit. I
consider pylab to be mainly for interactive use, for which the
simplicity/power tradeoff should be biased towards simplicity.
All,
I factored the plot box resizing and repositioning code out into a PBox
class ("Position Box", subclassed from list), presently in its own
pbox.py file, because I think it will be more generally useful; the
colorbar command is one such intended use. It may be helpful to make
Axes._position a PBox instance instead of an ordinary list.
I think that aspect-ratio handling is now reasonably solid and complete;
I have tested it with pan and zoom, with and without ganged axes. I had
to put in a couple of hacks in backend_bases to prevent exceptions.
(More careful analysis and fixing of the underlying causes would be
good.) Testing by other people would be very useful; you are likely
(maybe I should say 'certain') to try combinations of commands and
events I have not tested, which will turn up additional problems.
In case I failed to mention it in an earlier post: PolarAxes now uses
aspect-ratio handling to keep circles circular when windows are resized.
>
> I'll try to find time to test Eric's new implementation soon. Thanks for
> all the hard work,
Thank you, Mark, for the original work that made the changes possible.
Eric
>
> Mark
>
> Helge Avlesen wrote:
> > On 3/22/06, Eric Firing < ef...@ha...
> <mailto:ef...@ha...>> wrote:
> >
> >>unintuitive. Maybe we could find better names than 'equal' and
> >>'scaled', for example. Even with the docstrings, I have a hard time
> >>keeping track of which is supposed to do what.
> >
> >
> > Hi,
> > I think it would be nice if pylab "semantics" were kept close to matlab.
> > Maybe for instance axis('scaled') could be renamed to axis('image'), and
> > use similar wording as mathworks documentation in the docstrings?
> >
> > http://www.mathworks.com/access/helpdesk/help/techdoc/ref/axis.html
> >
> > Helge
>
> Helge,
>
> I understand the sentiment, but I don't always agree with it; while I
> don't want to do things differently from Matlab just for the sake of
> being different (except insofar is it may be necessary to avoid
> violating copyright), neither do I want to slavishly follow Matlab.
> Pylab/matplotlib can and should be better than Matlab. (And is in many
> respects.)
>
> In the case of Matlab's axis command, the Matlab documentation makes my
> head spin, and the whole command strikes me as too complicated for
> anyone's good. I don't think every possible capability should go into
> the pylab interface; past a certain point, it is better to simply call
> axis methods, etc.
>
> For now, I have added an axis('image') mode, which is not quite the same
> as 'scaled', and I have tried to improve the descriptions of the
> options. Please try out the various axis modes, and see if you think
> both the behavior and the descriptions make sense.
>
> Eric
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> I am getting more comfortable with 'scaled' now. The problem Eric> is that neither 'equal' nor 'scaled' is as obvious as one I think a mini-tutorial on aspect handling for axes and images, especially with screenshots that show the different effects, and a discussion of all the wild-and-wooly options would be a great addition to the wiki. JDH
>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
Eric> command. If there is any sentiment that it would be
Eric> desirable, I could make legend understand it as well, for
Eric> the sake of consistency.
I'm +1 on this. It only inconveniences power users.
Eric> I factored the plot box resizing and repositioning code out
Eric> into a PBox class ("Position Box", subclassed from list),
Eric> presently in its own pbox.py file, because I think it will
Eric> be more generally useful; the colorbar command is one such
Eric> intended use. It may be helpful to make Axes._position a
Eric> PBox instance instead of an ordinary list.
PBox appears to overlap matplotlib._transforms.BBox. Granted, the
mostly universal consensus is that mpl transforms are SNAFU-d (but
mostly work!), but is this increasing confusion by duplicating
functionality? In any case, you might consider simply extending BBox
(even if in python rather than extension code) or adding PBox to
transforms, cbook, or mlab, and describing what it does and how it is
different from BBox. It probably does not merit a separate module.
Eric> I think that aspect-ratio handling is now reasonably solid
Eric> and complete; I have tested it with pan and zoom, with and
For the record, this is a major and non-trivial step. I certainly
threw up my hands at attempting to fix it more than a year ago after
in-depth discussions with Perry about what was involved in making this
work in the presence of figure resizing, axes data limits, image
aspect ratios, etc. Thanks Eric and Mark for months of hard work.
This, plus prototype 3D, almost made me want to push for 1.0 :-).
Until, of course, I realized how much work still needs to be done on
the basics (Axis line handling and easy installation come to mind)
Eric> without ganged axes. I had to put in a couple of hacks in
Eric> backend_bases to prevent exceptions. (More careful analysis
Could you summarize these hacks here so we can look over them?
Eric> Thank you, Mark, for the original work that made the changes
Eric> possible.
Ditto.
JDH
John,
John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
>
>
> Eric> command. If there is any sentiment that it would be
> Eric> desirable, I could make legend understand it as well, for
> Eric> the sake of consistency.
>
> I'm +1 on this. It only inconveniences power users.
OK, I will put this on my mental list, but not at the top.
>
> Eric> I factored the plot box resizing and repositioning code out
> Eric> into a PBox class ("Position Box", subclassed from list),
> Eric> presently in its own pbox.py file, because I think it will
> Eric> be more generally useful; the colorbar command is one such
> Eric> intended use. It may be helpful to make Axes._position a
> Eric> PBox instance instead of an ordinary list.
>
> PBox appears to overlap matplotlib._transforms.BBox. Granted, the
> mostly universal consensus is that mpl transforms are SNAFU-d (but
> mostly work!), but is this increasing confusion by duplicating
> functionality? In any case, you might consider simply extending BBox
> (even if in python rather than extension code) or adding PBox to
> transforms, cbook, or mlab, and describing what it does and how it is
> different from BBox. It probably does not merit a separate module.
I agree, and have moved it to transforms and added documentation. I
originally considered putting it in transforms, but I decided to leave
it separate initially, since it is not integrated with transforms. I
also thought a little bit about integrating it, but expediency won
out--I wanted to make something work first, and figure out the finer
points, implications, and integrations later.
The topic of how to reduce overlap while increasing readability and/or
power is open.
>
> Eric> I think that aspect-ratio handling is now reasonably solid
> Eric> and complete; I have tested it with pan and zoom, with and
As usual, I have found some more things that needed to be fixed. I have
made those changes, and as you requested in another message I have moved
the axis command functionality to Axes.axis, so pylab.axis is a thin
wrapper.
>
> For the record, this is a major and non-trivial step. I certainly
> threw up my hands at attempting to fix it more than a year ago after
> in-depth discussions with Perry about what was involved in making this
> work in the presence of figure resizing, axes data limits, image
> aspect ratios, etc. Thanks Eric and Mark for months of hard work.
> This, plus prototype 3D, almost made me want to push for 1.0 :-).
> Until, of course, I realized how much work still needs to be done on
> the basics (Axis line handling and easy installation come to mind)
>
> Eric> without ganged axes. I had to put in a couple of hacks in
> Eric> backend_bases to prevent exceptions. (More careful analysis
>
> Could you summarize these hacks here so we can look over them?
>
The basic problem is that if axes.set_xlim or axes.set_ylim get
identical values, so that the data span of an axis is zero, it can cause
trouble in several places. Furthermore, it seems that ValueError can be
raised in the transform module when the data span is very small, not
just when it is zero. I first tried to solve the problem by adding a
little bit of code to set_xlim and set_ylim to prevent such singular and
near-singular values. For some reason, it did not solve all the
problems; I never figured out why. (In retrospect, perhaps I just did
not use a large enough threshold.) The problems all seemed to be
triggered by the button3 drag in zoom/pan, with axis('image'), so I put
most of the block into a try/except structure, and I added
singularity-checking to the arguments passed to set_xlim and set_ylim.
The relevant extract from backend_bases is below, with pointers added:
elif self._button_pressed==3:
try: # <-------
dx=(lastx-event.x)/float(a.bbox.width())
dy=(lasty-event.y)/float(a.bbox.height())
dx,dy=format_deltas(event,dx,dy)
alphax = pow(10.0,dx)
alphay = pow(10.0,dy)#use logscaling, avoid
singularities and smother scaling...
lastx, lasty = trans.inverse_xy_tup( (lastx, lasty) )
if a.get_xscale()=='log':
xmin = lastx*(xmin/lastx)**alphax
xmax = lastx*(xmax/lastx)**alphax
else:
xmin = lastx+alphax*(xmin-lastx)
xmax = lastx+alphax*(xmax-lastx)
if a.get_yscale()=='log':
ymin = lasty*(ymin/lasty)**alphay
ymax = lasty*(ymax/lasty)**alphay
else:
ymin = lasty+alphay*(ymin-lasty)
ymax = lasty+alphay*(ymax-lasty)
except OverflowError: # <---------
warnings.warn('Overflow while panning')
return
a.set_xlim(self.nonsingular(xmin, xmax)) # <--
a.set_ylim(self.nonsingular(ymin, ymax)) # <--
self.dynamic_update()
def nonsingular(self, x0, x1): # <=================
'''Desperate hack to prevent crashes when button-3 panning with
axis('image') in effect.
'''
d = x1 - x0
# much smaller thresholds seem to cause Value Error
# later in Transformation::freeze in axes.draw()
if abs(d) < 1e-10:
warnings.warn('Axis data limit is too small for panning')
x1 += 1e-10
x0 -= 1e-10
return (x0, x1)
What I don't understand at all is why this threshold (e.g., 1e-15 is too
small) is needed to prevent problems in the freeze method.
I think the try/except is reasonable, and some sort of
singularity-prevention is also reasonable, preferably inside set_xlim
and set_ylim; but I am not comfortable with this high an arbitrary
threshold.
Eric