On Sat, Mar 24, 2007 at 03:25:38PM -0700, Zachary Pincus wrote: > If Lena is converted to floating-point before the rotation is > applied, and then the intensity range is clipped to [0,255] and > converted back to uint8 before saving, everything looks fine.
Thanks, Zachary! I can confirm that. > So, is this a bug? Well, I still think so. Given that small ringing > is going to happen on all but the very smoothest images, and given > that ndimage is going to be used on non-floating-point types, it > would be good if there were some explicit internal clipping to the > data type's range. Otherwise, the ndimage resampling tools are unfit > for use on non-floating-point data that resides near the edges of the > range of the data type. I agree. > Though I'm not quite sure how one would structure the calculations so > that it would be possible to tell when over/underflow happened... it > might not be possible. In which case, either the tools should use > floating-point math at some of the steps internally (as few as > possible) before clipping and converting to the required data type, > or explicit warnings should be added to the documentation. I think the spline interpolation already uses floating point math? Looks like we are seeing a type conversion without range checking: In [47]: x = N.array([1.2,200,255,255.6,270]) In [48]: x.astype(N.uint8) Out[48]: array([ 1, 200, 255, 255, 14], dtype=uint8) I'll have to go and take a look at the code, but this shouldn't be hard to fix -- clipping is fairly fast (don't we have a fast clipping method by David C now?), even for extremely large images. Regards Stéfan _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
