Rescale intensity function [was: Asymmetric behavior in dtype conversion]

[Tony Yu]

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

>
>
> On Wed, Dec 21, 2011 at 9:15 AM, Christoph Gohlke <cjgohlke at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111229/8aa11c09/attachment.html>