Re: [matplotlib-devel] [Python-modules-team] Bug#585442: python-matplotlib: crashes when calling axis() after imshow()
On 06/22/2010 06:56 PM, Eric Firing wrote: > >> Unfortunately, this fix paves over the exception fixed earlier. Rather >> than getting an exception when the magnification is too high, it now >> silently just doesn't draw the image. I'm trying to figure out what the >> threshold is beyond which it fails in order to manually raise an >> exception, but not having much luck. I suspect it's somehow related to >> floating-point or even Agg's fixed-point rounding error. >> > "just doesn't draw" sounds like a pretty benign failure mode. It might > even be better than raising an exception. I was just imagining the frequent questions "my image disappears when I zoom in". I think it's preferable to have an exception (or at least a warning) saying something useful in that case. > An alternative might be to > use something like "nonsingular()" to block attempts to make the view > limits too small--once it is known how to calculate "too small". Yes. That's not a bad middle ground between raising an exception and doing nothing -- however this only applies to images, so nonsingular() or autoscale_view() etc. would have to become aware of when an image was on the axes. Not too difficult, I suppose. >Yet > another alternative, more complicated to implement, would be to clip the > array and then interpolate to a finer grid at the python level when > trying to zoom too far into a cell of the original grid. > Yes, perhaps. But that means reimplementing all of the interpolation algorithms we currently use Agg for at the Python level, right? Doing a simple nearest neighbor interpolation in Python and then one of the more involved interpolation methods in Agg would not be equivalent. Such effort might be worth it in the long run to support non-regular grids, quadmeshes etc., however. But that's a major project and would probably need to be implemented in C/C++ anyway, just not necessarily based on Agg. > It would be good if everything could be kept at the python or _image.cpp > level, so that the Agg code could be left unchanged. As far as I know, > your previous patch to raise the exception was the only mpl-specific > change that has been made to the Agg24 code. > There are other changes that have been made over time to keep it compatible with newer versions of compilers. As the upstream of the non-GPL version of Agg is basically dead (and AFAICT the GPL'd version is too), we're maintaining such changes ourselves. That said, the pulling of CXX classes into Agg is ugly, but it was the quickest solution (and one that will work for Debian as a basic patch against matplotlib 0.99.3). In the long run, the exception should be generic as far as Agg is concerned, and try/catch's need to be added around all calls into Agg from our Python wrappers. Mike > Eric > > > >> Mike >> >> On 06/22/2010 12:31 PM, Michael Droettboom wrote: >> >>> Ok. Attached is a corrected patch. >>> >>> Mike >>> >>> On 06/22/2010 12:26 PM, Michael Droettboom wrote: >>> Hold off, actually. This patch seems to have broken some thing inadvertently. Stay tuned... Mike On 06/22/2010 12:05 PM, Michael Droettboom wrote: > In r8454, I have a applied a fix that allows this C++ exception to > correctly percolate to the Python side -- the user will still get an > exception, but it will be a Python exception and the interpreter > itself does not crash. (It used to work, but recent changes to CXX > caused it to break.) I have attached this patch to the e-mail. > > As Eric suggests, fixing the underlying limitation (I even hesitate > to call it a bug because it is definitely a corner case) requires > understanding some pretty dark depths of the Agg renderer. > > Mike > > On 06/21/2010 10:57 PM, Eric Firing wrote: > >> On 06/21/2010 12:24 PM, Sandro Tosi wrote: >> >>> forwarded 585442 matplotlib-devel@lists.sourceforge.net >>> thanks >>> >>> Hello Matplotlib developers, >>> here below is a report a user of maplotlib sent to the Debian bug >>> tracker. I've verified and it happend also with 0.99.3: >>> >>> $ python -c "import matplotlib as p ; print p.__version__" >>> 0.99.3 >>> $ python mpl_crash.py >>> terminate called after throwing an instance of 'char const*' >>> Aborted >>> >>> Thanks for looking into it, >>> Sandro >>> >> Sandro, >> >> Thanks for reporting it. >> >> With the default interpolation, rendering gets extremely slow as the >> view limits decline to and below a single image pixel. I suspect the >> crash is related to this. Neither the slowdown nor the crash occurs >> with interpolation='nearest', although there is still an anomaly in >> which the image is blank when the viewlim region is too small. >> >> Like Ryan, I am not familiar with the
Re: [matplotlib-devel] [Python-modules-team] Bug#585442: python-matplotlib: crashes when calling axis() after imshow()
SVN r8457 has what I think is an ideal solution. Unbeknownst to me, the clipping I added to speed up rendering of highly magnified images was being done in integers. Agg does provide an option to do this in doubles, and using that seems to prevent the image from disappearing. It even renders the image with the very narrow range that nonsingular() currently enforces (+/- 0.001). Mike On 06/23/2010 08:37 AM, Michael Droettboom wrote: > On 06/22/2010 06:56 PM, Eric Firing wrote: > >> >>> Unfortunately, this fix paves over the exception fixed earlier. Rather >>> than getting an exception when the magnification is too high, it now >>> silently just doesn't draw the image. I'm trying to figure out what the >>> threshold is beyond which it fails in order to manually raise an >>> exception, but not having much luck. I suspect it's somehow related to >>> floating-point or even Agg's fixed-point rounding error. >>> >>> >> "just doesn't draw" sounds like a pretty benign failure mode. It might >> even be better than raising an exception. >> > I was just imagining the frequent questions "my image disappears when I > zoom in". I think it's preferable to have an exception (or at least a > warning) saying something useful in that case. > >>An alternative might be to >> use something like "nonsingular()" to block attempts to make the view >> limits too small--once it is known how to calculate "too small". >> > Yes. That's not a bad middle ground between raising an exception and > doing nothing -- however this only applies to images, so nonsingular() > or autoscale_view() etc. would have to become aware of when an image was > on the axes. Not too difficult, I suppose. > >> Yet >> another alternative, more complicated to implement, would be to clip the >> array and then interpolate to a finer grid at the python level when >> trying to zoom too far into a cell of the original grid. >> >> > Yes, perhaps. But that means reimplementing all of the interpolation > algorithms we currently use Agg for at the Python level, right? Doing a > simple nearest neighbor interpolation in Python and then one of the more > involved interpolation methods in Agg would not be equivalent. Such > effort might be worth it in the long run to support non-regular grids, > quadmeshes etc., however. But that's a major project and would probably > need to be implemented in C/C++ anyway, just not necessarily based on Agg. > >> It would be good if everything could be kept at the python or _image.cpp >> level, so that the Agg code could be left unchanged. As far as I know, >> your previous patch to raise the exception was the only mpl-specific >> change that has been made to the Agg24 code. >> >> > There are other changes that have been made over time to keep it > compatible with newer versions of compilers. As the upstream of the > non-GPL version of Agg is basically dead (and AFAICT the GPL'd version > is too), we're maintaining such changes ourselves. > > That said, the pulling of CXX classes into Agg is ugly, but it was the > quickest solution (and one that will work for Debian as a basic patch > against matplotlib 0.99.3). In the long run, the exception should be > generic as far as Agg is concerned, and try/catch's need to be added > around all calls into Agg from our Python wrappers. > > Mike > >> Eric >> >> >> >> >>> Mike >>> >>> On 06/22/2010 12:31 PM, Michael Droettboom wrote: >>> >>> Ok. Attached is a corrected patch. Mike On 06/22/2010 12:26 PM, Michael Droettboom wrote: > Hold off, actually. This patch seems to have broken some thing > inadvertently. Stay tuned... > > Mike > > On 06/22/2010 12:05 PM, Michael Droettboom wrote: > > >> In r8454, I have a applied a fix that allows this C++ exception to >> correctly percolate to the Python side -- the user will still get an >> exception, but it will be a Python exception and the interpreter >> itself does not crash. (It used to work, but recent changes to CXX >> caused it to break.) I have attached this patch to the e-mail. >> >> As Eric suggests, fixing the underlying limitation (I even hesitate >> to call it a bug because it is definitely a corner case) requires >> understanding some pretty dark depths of the Agg renderer. >> >> Mike >> >> On 06/21/2010 10:57 PM, Eric Firing wrote: >> >> >>> On 06/21/2010 12:24 PM, Sandro Tosi wrote: >>> >>> forwarded 585442 matplotlib-devel@lists.sourceforge.net thanks Hello Matplotlib developers, here below is a report a user of maplotlib sent to the Debian bug tracker. I've verified and it happend also with 0.99.3: $ python -c "import matplotlib as p ; print p.__version__" 0.99.3 $ pytho
