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

Reply via email to