Automatically picking bit-depth based on value seems dangerous, but a `guess_best_dtype(input_data: np.array) -> dtype` helper function would be useful.
Tom On Fri, Mar 30, 2018 at 10:10 AM Gregory Lee <grle...@gmail.com> wrote: > On Thu, Mar 29, 2018 at 1:46 PM, Juan Nunez-Iglesias <jni.s...@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 >> >> _______________________________________________ > scikit-image mailing list > scikit-image@python.org > https://mail.python.org/mailman/listinfo/scikit-image >
_______________________________________________ scikit-image mailing list scikit-image@python.org https://mail.python.org/mailman/listinfo/scikit-image
