On 12/21/2011 1:30 AM, Tony Yu wrote:

I noticed that---when converting unsigned integers to (signed) integers---the values of the uint are simply scaled to fit into the positive range of the int array. On the other hand, when converting from int to uint, the *full range* (i.e. negative and positive) values of the int array get scaled to fit into the uint. The result is asymmetric, and it can lead to drift when converting between types; e.g.:

#~~~ In [55]: skimage.img_as_ubyte(skimage.img_as_int(np.uint8([0]))) WARNING:dtype_converter:Possible sign loss when converting negative image of type int16 to positive image of type uint8. WARNING:dtype_converter:Possible precision loss when converting from int16 to uint8 Out[55]: array([128], dtype=uint8) #~~~

I think one of two things should happen:

1) [uint -> int]: expand uint to *full* range of int. [int -> uint]: unchanged (squeeze into range of uint)

2) [uint -> int]: unchanged (fill *positive* range of int) [int -> uint]: clip negative values from int

Thoughts? -Tony

P.S. This change would either have to wait for PR 99 <https://github.com/scikits-image/scikits-image/pull/99>, or it could be integrated into that pull request. (I haven't yet looked at what it would take to make this change.)

My original implementation of PR99 had 1) implemented but skimage tests failed. Christoph