Hi, We have found two problems with ndimage. I have filed a ticket #455 on the scipy trac page. The first problem can be seen with this example:
import numpy as n from scipy import ndimage as nd a = n.ones((10,5),dtype=n.float32) * 12.3 x = nd.rotate(a,90.0) x Out[17]: array([[ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 0. , 0. ], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019]], dtype=float32) }}}
Notice that the last two entries of the first row are now 0. The second problem has to do with the reversing of byte order if you have big-endian data on a little endian machine. Please see the example below:
a = N.ones ((2,3), dtype=N.float32) * 12.3 a = a.byteswap() a.dtype = a.dtype.newbyteorder (">") print a [[ 12.30000019 12.30000019 12.30000019] [ 12.30000019 12.30000019 12.30000019]] print ndimage.rotate (a, 90.) [[ 0.00000000e+00 -4.28378144e+08] [ 0.00000000e+00 -4.28378144e+08] [ -4.28378144e+08 -4.28378144e+08]]
I have taken a look at the ndimage python code and cannot find any explicit calls to byteswap. I'm guessing something is funny in one of the c-api calls. I haven't been able to track it down yet. Chris
Hi Chris On Tue, Jul 03, 2007 at 12:25:55PM -0400, Christopher Hanley wrote:
We have found two problems with ndimage. I have filed a ticket #455 on the scipy trac page. The first problem can be seen with this example:
import numpy as n from scipy import ndimage as nd a = n.ones((10,5),dtype=n.float32) * 12.3 x = nd.rotate(a,90.0) x Out[17]: array([[ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 0. , 0. ], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019]], dtype=float32) }}}
Notice that the last two entries of the first row are now 0.
This is due to a slight round-off error when calculating the affine transformation matrix. cos(pi/180 * angle) isn't exactly zero, so you find that elements that fall *just* outside the boundary gets converted to the cval (0). You can work around the problem in two ways. The first is to setup your own transformation matrix: nd.affine_transform(a,[[0,1],[-1,0]],offset=[0,4],output_shape=(5,10)) The second is to use 'mirror' boundary mode, instead of 'cval', thereby nudging those outliers back into place.
The second problem has to do with the reversing of byte order if you have big-endian data on a little endian machine. Please see the example below:
Thanks, I'll have a look at that. Regards Stéfan
Stefan van der Walt wrote:
Hi Chris
On Tue, Jul 03, 2007 at 12:25:55PM -0400, Christopher Hanley wrote:
We have found two problems with ndimage. I have filed a ticket #455 on the scipy trac page. The first problem can be seen with this example:
import numpy as n from scipy import ndimage as nd a = n.ones((10,5),dtype=n.float32) * 12.3 x = nd.rotate(a,90.0) x Out[17]: array([[ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 0. , 0. ], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019]], dtype=float32) }}}
Notice that the last two entries of the first row are now 0.
This is due to a slight round-off error when calculating the affine transformation matrix. cos(pi/180 * angle) isn't exactly zero, so you find that elements that fall *just* outside the boundary gets converted to the cval (0). You can work around the problem in two ways.
The first is to setup your own transformation matrix:
nd.affine_transform(a,[[0,1],[-1,0]],offset=[0,4],output_shape=(5,10))
The second is to use 'mirror' boundary mode, instead of 'cval', thereby nudging those outliers back into place.
The second problem has to do with the reversing of byte order if you have big-endian data on a little endian machine. Please see the example below:
Thanks, I'll have a look at that.
Regards Stéfan _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
Stefan. I have patched the second issue. The fix went out with the last release. Thank you for the solution to the first problem. Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338
The byteswapping issue was resolved in r3157. Chris
participants (2)
-
Christopher Hanley -
Stefan van der Walt