On Wed, Dec 21, 2011 at 11:16 AM, Tony Yu <tsyu80@gmail.com> wrote:

On Wed, Dec 21, 2011 at 9:15 AM, Christoph Gohlke <cjgohlke@gmail.com>wrote:

...

On 12/21/2011 8:41 AM, Stéfan van der Walt wrote:

...

On Wed, Dec 21, 2011 at 1:30 AM, Tony Yu<tsyu80@gmail.com> wrote:

...

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

People very often represent images in signed integers, even though they only manipulate positive values, e.g. storing 0-255 in int8. So the conversion to signed should not spread those values over the entire range. However, I think you're right that we should add the clipping in 2 to avoid the conversion bias, along with a nice big warning.

Regards Stéfan

At this point it might be worth considering other cases that are currently not well handled by skimage dtype conversions. For example:

1) float images in the range 0.0 - 255.0 2) 1 bit images stored as (u)int 3) 10 and 12 bit images stored as uint16

Christoph

I've definitely been bit by example 1 many times.

I think we should check that float images are between 0 and 1 in ``util.dtype._convert`` (and either warn or raise an error), but we shouldn't have to worry about it elsewhere. That doesn't really solve the issue, so...

Presumably, the user would know that their data is in a slightly weird format (especially for examples 2 and 3), correct? If so, we could just add a function (maybe "rescale_intensity" or "stretch_intensity" or "normalize_intensity" or something similar) that takes the image and the input intensity range as inputs. For example: ``norm_intensity(image_u12, (0, 4096))``. Then, we could rescale the intensity to fit into the intensity range of the input dtype. We could also add special values [e.g. 1) 'uint8', 2) 'bool', 3) 'uint10'/'uint12'] for the second parameter, and these values could pull the associated range from a table.

Then, it would be the responsibility of the user to call this function before converting dtypes.

-Tony

I forget that not everyone gets notified when I post a pull request. In PR 107 <https://github.com/scikits-image/scikits-image/pull/107> I add a `rescale_intensity` function, which implements my earlier suggestion. Christoph: Does this solve (or at least mitigate) the problems with weird data types? I have yet to implement "special" input ranges---i.e. input range can be a dtype string and map that string to a range. The implementation is easy, but I'm not sure what data types should be supported: 1bit (or bool?), uint10, uint12,... Comments/suggestions? -Tony