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. 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.
On Thu, Mar 29, 2018 at 10:46 AM, Juan Nunez-Iglesias <jni.soma@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@python.org https://mail.python.org/mailman/listinfo/scikit-image
On Thu, Mar 29, 2018 at 1:46 PM, Juan Nunez-Iglesias <jni.soma@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.
One common source for 12-bit is the DICOM standard used by industry for medical imaging. * 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.
I am in favor of accepting arbitrarily scaled floats unless the algorithm depends on values being within a particular range (not sure if we have many of these?). We do already allow unscaled floats in some places (e.g. compare_nrmse, etc), but it is not very consistent. For example, I recently noticed that denoise_wavelet enforces floats to be in [0, 1] (or [-1, 1]), but it would work equally well for unscaled data.
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. 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@python.org https://mail.python.org/mailman/listinfo/scikit-image
participants (3)
-
Gregory Lee -
Juan Nunez-Iglesias -
Ralf Gommers