[scikit-image] data types

[Ralf Gommers]

On Thu, Mar 29, 2018 at 10:46 AM, Juan Nunez-Iglesias <jni.soma at gmail.com>
wrote:

> I think maybe 50% of our bug reports/help requests have to do with image
> data types. Does anyone want to express an opinion about how we can fix
> things?
>
> My humble (really) suggestions, *to start* (ie more needs to be done than
> this):
>
> * If a 16-bit or higher image has no values above 4096 or below 0, treat
> the image as 12 bit. This is a very common image type for some reason.
>
> * If an integer image has no values above 255, treat it as an 8-bit image.
> This also happens a lot.
>
> * If a floating point image has values outside [0, 1], don’t croak, just
> accept it. (This might have already happened?) If it has values only in [0,
> 1/255], and the user wants to convert to uint8, use the input range as the
> range.
>
> Some of these, especially the last one, may appear too magical, and in
> some ways I think they are, but honestly, given the frequency of problems
> that we get because of this, I think it’s time to suck it up and really
> work on doing what most of our users want most of the time.
>

Do these things currently give warnings? If they'd say something like "this
is a 16-bit image format but from its values appears to be 12-bit; if this
is the case you can convert it with <utility function>"?

If the conversions do happen based on value, that will introduce new issues
that also will require warnings. E.g. if one has stacks of 16-bit images
and some of those are dark acquisitions for normalization (that used to be
my typical use case), only those will get converted to 12-bit which then
may introduce silent errors.

Ralf



> We don’t need to coddle the power users — they can be annoyed and
> micromanage the image range properly. To paraphrase a tweet I saw once
> (sorry, couldn’t find attribution): “edge cases should be used to check the
> design, not drive it.”
>
> Applied to this case, we shouldn’t scale a uint32 image by 2**(-32) just
> because we can come up with a test case where this is useful.
>
> Some of these problems would be alleviated by some consistent metadata
> conventions.
>
> Juan.
>
>
> _______________________________________________
> scikit-image mailing list
> scikit-image at python.org
> https://mail.python.org/mailman/listinfo/scikit-image
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20180329/10be7009/attachment.html>