All, Motivated in part by an old patch (1233294) submitted to sourceforge by Nikolai Hlubek, I took a look at how aspect ratio is handled in mpl, and concluded it wasn't quite right: 1) The aspect='preserve' kwarg in image caused the image to retain its aspect ratio only with some resize events, not with all. The implementation in the image.py code does not look right to me. 2) The aspect='equal' kwarg in axes.py did not respond to resize events at all. 3) I could not understand why there should be separate "aspect" kwargs for image and for axes. Therefore I have reworked the aspect-handling code in axes.py, and I think it is working reasonably well. Indeed, I don't see any remaining need for an "aspect" kwarg in image.py, and I would like to take it out unless someone raises an objection. I have also changed the aspect-related API to make it more flexible and self-explanatory: def set_aspect(self, aspect='auto', fixLimits=None, aspect_adjusts='position'): """ 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 A - a circle will be stretched such that the height is A times the width. aspect=1 is the same as aspect='equal'. aspect_adjusts: 'position' - change width or height of bounding rectangle; keep it centered. 'box_size' - as above, but anchored to lower left 'datalim' - change xlim or ylim fixLimits: deprecated; False is aspect_adjusts='datalim'; True is aspect_adjusts='position' ACCEPTS: ['auto' | 'equal' | aspect_ratio] ... def set_aspect_adjusts(self, aspect_adjusts = 'position'): """ Must be called after set_aspect. ACCEPTS: ['position' | 'box_size' | 'datalim'] ... Anticipating that some additional work will need to be done, I have not yet made an entry in the CHANGELOG or API_CHANGES. In addition to removing the aspect kwarg from image.py, I would like to take fixLimits out of set_aspect (above). No code in mpl or its examples depends on it, but this might break some user code, so for the present I have maintained compatibility. One question: is there an easy way to automatically trigger a redraw in an interactive backend (e.g. ipython with gtkagg) at the end of the set_aspect() method, for example? The way it works now is that one can make a plot, call the set_aspect() method on the resulting axes object, and the result will appear as soon as the window is manipulated with the mouse; but this manipulation is needed to trigger a redraw. Eric
>>>>> "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
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
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 > >
Mark, Go ahead and test the svn version now. I still need to write the CHANGELOG entry, I will probably take out the fixLimits kwarg (but leave its functionality), and there may be some other things that need tweaking; but the essential functionality is in place. Mark Bakker wrote: > 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 > handling 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 > will still be possible. Yes. The default when aspect ratio is not 'auto' is to maintain the aspect ratio by changing the screen dimensions of the axes box, but the option is available to do it by changing xlim and/or ylim instead. > > 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 > would be very nice. Yes, I think it does, but I have not tested it extensively. There is nothing backend-specific. The change that makes it work interactively is to put the aspect ratio calculations in a separate function and then call that function in axes.draw. I have not yet tried John's suggestion for triggering a redraw automatically after calling set_aspect. > > The set_aspect function is called from axis() in pylab.py and I think > somewhere in backend_basics after a zoom event. Thanks for pointing that out--I thought I had found everything, but I certainly had not. I will take a look at those calls; at the least, they will need to be changed slightly if I remove the fixLimits kwarg. I will try to make another pass through the code this evening. Eric > > 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... > <mailto: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 = 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... > <mailto: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 > <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642> > > _______________________________________________ > > Matplotlib-devel mailing list > > Mat...@li... > <mailto:Mat...@li...> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: >> The set_aspect function is called from axis() in pylab.py and I >> think somewhere in backend_basics after a zoom event. Eric> Thanks for pointing that out--I thought I had found Eric> everything, but I certainly had not. I will take a look at Eric> those calls; at the least, they will need to be changed Eric> slightly if I remove the fixLimits kwarg. One of the drawbacks of having pass through kwargs. grep isn't as useful as you'd like it to be. This is a docstring bug in pylab.axis, which should be updated to reflect the fixLimits kwarg (if it survives the refactor). JDH
Eric Firing wrote: > All, > > Motivated in part by an old patch (1233294) submitted to sourceforge > by Nikolai Hlubek, I took a look at how aspect ratio is handled in > mpl, and concluded it wasn't quite right: > > 1) The aspect='preserve' kwarg in image caused the image to retain its > aspect ratio only with some resize events, not with all. The > implementation in the image.py code does not look right to me. > > 2) The aspect='equal' kwarg in axes.py did not respond to resize > events at all. > > 3) I could not understand why there should be separate "aspect" kwargs > for image and for axes. > > Therefore I have reworked the aspect-handling code in axes.py, and I > think it is working reasonably well. Indeed, I don't see any > remaining need for an "aspect" kwarg in image.py, and I would like to > take it out unless someone raises an objection. > > I have also changed the aspect-related API to make it more flexible > and self-explanatory: > > def set_aspect(self, aspect='auto', fixLimits=None, > aspect_adjusts='position'): > """ > 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 > A - a circle will be stretched such that the height > is A times the width. aspect=1 is the same as > aspect='equal'. > > aspect_adjusts: > 'position' - change width or height of bounding rectangle; > keep it centered. > 'box_size' - as above, but anchored to lower left > 'datalim' - change xlim or ylim > > fixLimits: deprecated; False is aspect_adjusts='datalim'; > True is aspect_adjusts='position' > > ACCEPTS: ['auto' | 'equal' | aspect_ratio] > ... > > def set_aspect_adjusts(self, aspect_adjusts = 'position'): > """ > Must be called after set_aspect. > > ACCEPTS: ['position' | 'box_size' | 'datalim'] > > ... > > Anticipating that some additional work will need to be done, I have > not yet made an entry in the CHANGELOG or API_CHANGES. > > In addition to removing the aspect kwarg from image.py, I would like > to take fixLimits out of set_aspect (above). No code in mpl or its > examples depends on it, but this might break some user code, so for > the present I have maintained compatibility. > > One question: is there an easy way to automatically trigger a redraw > in an interactive backend (e.g. ipython with gtkagg) at the end of the > set_aspect() method, for example? The way it works now is that one > can make a plot, call the set_aspect() method on the resulting axes > object, and the result will appear as soon as the window is > manipulated with the mouse; but this manipulation is needed to trigger > a redraw. > > Eric Eric: It occurred to me that there are actually 9 possibilities for adjusting the location of the plot in the bounding box after fixing the aspect ratio. Here's a patch to this morning's svn axes.py that adds the other 7 possibilities. Does this make sense to you? If so, I can go ahead and apply it. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes: >> >> def set_aspect(self, aspect='auto', fixLimits=None, >> aspect_adjusts='position'): """ aspect: 'auto' - automatic; A minor nit: I'm not fond of underscores in kwargs, and prefer them to be as short and as easy to type as possible. I think "aspects" in "aspect_adjusts" is a bit redundant since the method is "set_aspect" and prefer "adjust" or something similarly simple. Also, perhaps we could take this opportunity while changing the API to replace fixLimits with fixlimits (if it survives the refactor). I think as a general matter, we should stick to strictly lowercase, no underscores for kwargs where possible. Granted not all kwargs work this way currently, but most do and I prefer this style. JDH
John Hunter wrote: >>>>>>"Jeff" == Jeff Whitaker <js...@fa...> writes: > > >> > >> def set_aspect(self, aspect='auto', fixLimits=None, > >> aspect_adjusts='position'): """ aspect: 'auto' - automatic; > > A minor nit: I'm not fond of underscores in kwargs, and prefer them to > be as short and as easy to type as possible. I think "aspects" in > "aspect_adjusts" is a bit redundant since the method is "set_aspect" > and prefer "adjust" or something similarly simple. Also, perhaps we > could take this opportunity while changing the API to replace > fixLimits with fixlimits (if it survives the refactor). > > I think as a general matter, we should stick to strictly lowercase, no > underscores for kwargs where possible. Granted not all kwargs work > this way currently, but most do and I prefer this style. > > JDH John, OK, no problem, I will change to your kwarg style; it makes sense. fixlimits will not survive in any case; "adjust" replaces it. Eric
Jeff, Jeff Whitaker wrote: > > Eric: It occurred to me that there are actually 9 possibilities for > adjusting the location of the plot in the bounding box after fixing the > aspect ratio. Here's a patch to this morning's svn axes.py that adds > the other 7 possibilities. Does this make sense to you? If so, I can > go ahead and apply it. > > -Jeff Thanks, but I think it would be better to hold off. This possibility did occur to me, but I originally left it out to keep things simple, both in the API and in the code. (My inclination was actually to make centering standard, and not even offer the corner-anchoring.) I think that perhaps this sort of positioning functionality should be factored out. Resizing and repositioning are more generally useful; for example, they are used in the colorbar function. I would like to take a look at this broader question before finalizing the axes aspect ratio handling. Eric
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> be factored out. Resizing and repositioning are more Eric> generally useful; for example, they are used in the colorbar Eric> function. I would like to take a look at this broader Eric> question before finalizing the axes aspect ratio handling. Eric, what is the status of the aspect code w/ respect to the presence of colorbars, or more generally, multiple axes? JDH
John Hunter wrote: >>>>>>"Eric" == Eric Firing <ef...@ha...> writes: > > Eric> be factored out. Resizing and repositioning are more > Eric> generally useful; for example, they are used in the colorbar > Eric> function. I would like to take a look at this broader > Eric> question before finalizing the axes aspect ratio handling. > > Eric, what is the status of the aspect code w/ respect to the presence > of colorbars, or more generally, multiple axes? John, Broken! I assumed it would be OK, but now I see that is not the case. I know why, and I can fix it easily on my next pass. But this does highlight the question of more complex positioning situations. Eric
Eric Firing wrote: > John Hunter wrote: > >> Eric, what is the status of the aspect code w/ respect to the presence >> of colorbars, or more generally, multiple axes? > > > John, > > Broken! I assumed it would be OK, but now I see that is not the case. > I know why, and I can fix it easily on my next pass. But this does > highlight the question of more complex positioning situations. Hi Eric, I don't know if you're aware of this, but Axes.set_position() seems to have broken in the last day or two, also. Cheers! Andrew
Andrew Straw wrote: > Eric Firing wrote: > > >>John Hunter wrote: >> >> >>>Eric, what is the status of the aspect code w/ respect to the presence >>>of colorbars, or more generally, multiple axes? >> >> >>John, >> >>Broken! I assumed it would be OK, but now I see that is not the case. >>I know why, and I can fix it easily on my next pass. But this does >>highlight the question of more complex positioning situations. > > > Hi Eric, > > I don't know if you're aware of this, but Axes.set_position() seems to > have broken in the last day or two, also. > > Cheers! > Andrew Andrew, Thanks--it makes sense that it would (and it is the reason for the colorbar problem), but I am embarrassed that I didn't spot it myself before committing changes. Eric
All, I think that aspect ratio handling in svn is now usable; I have checked simple uses of the pylab axis() function, together with interactive resizing, pan, and zoom of images, simple plots, and ganged plots. I have tried to keep the pylab interface pretty much unchanged for now; but if people have ideas as to how it could be improved, I would be happy to consider them. Personally, I find some of the options 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. Jeff, I haven't forgotten your patch to add anchoring options, but I still want to think about it in a slightly larger context; one way or another it will be done soon. Eric
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
Andrew, I did not get as far as I would have liked this evening, but Axes.set_position() is now working again in svn, as is the colorbar. I'm sorry for the disruption. This turned out to be more complicated than I thought. To be continued... Eric Andrew Straw wrote: > Eric Firing wrote: > > >>John Hunter wrote: >> >> >>>Eric, what is the status of the aspect code w/ respect to the presence >>>of colorbars, or more generally, multiple axes? >> >> >>John, >> >>Broken! I assumed it would be OK, but now I see that is not the case. >>I know why, and I can fix it easily on my next pass. But this does >>highlight the question of more complex positioning situations. > > > Hi Eric, > > I don't know if you're aware of this, but Axes.set_position() seems to > have broken in the last day or two, also. > > Cheers! > Andrew
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
On 3/31/06, Eric Firing <ef...@ha...> wrote:
> 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.
Hi,
from what I see, the axis command now works really well, excellent work!
the descriptions also look fine - I am not a native English speaker/writer
so I fail to see how to make them more precise without beeing much more ver=
bose.
thanks,
Helge
John Hunter wrote: >>>>>>"Eric" == Eric Firing <ef...@ha...> writes: > > > >> The set_aspect function is called from axis() in pylab.py and I > >> think somewhere in backend_basics after a zoom event. > > Eric> Thanks for pointing that out--I thought I had found > Eric> everything, but I certainly had not. I will take a look at > Eric> those calls; at the least, they will need to be changed > Eric> slightly if I remove the fixLimits kwarg. > > One of the drawbacks of having pass through kwargs. grep isn't as > useful as you'd like it to be. This is a docstring bug in pylab.axis, > which should be updated to reflect the fixLimits kwarg (if it survives > the refactor). > > JDH John, Yes, I will try to check all relevant docstrings on my next pass--this evening, if all goes well. At least some of the things I missed were greppable; I just didn't spend enough time to check everything carefully. Eric