Hi everyone, There has been a little discussion in #1945 about our range conversion and I think that we should try to avoid `img_as_float` in our functions as much as possible, unless really necessary for the correctness of the algorithm. In most cases, there is no reason to tinker around with the range of values of the input image. Some examples: skimage.filter.gaussian_filter skimage.transform.warp et al. skimage.filter.sobel et al. skimage.restoration.denoise_tv_chambolle What is your opinion? Best, Johannes
Hi, For what it's worth, I agree with you entirely. I process satellite imagery with scikit-image, and usually want to keep the values exactly how they are (as they represent actual physical measurements in SI units) - and so converting to an arbitrary range always causes me problems. (I'm probably not representative of the typical skimage user though - so don't take my opinion too seriously!) Robin On Wednesday, 17 February 2016 21:21:12 UTC, Johannes Schönberger wrote:
Hi everyone,
There has been a little discussion in #1945 about our range conversion and I think that we should try to avoid `img_as_float` in our functions as much as possible, unless really necessary for the correctness of the algorithm. In most cases, there is no reason to tinker around with the range of values of the input image. Some examples:
skimage.filter.gaussian_filter skimage.transform.warp et al. skimage.filter.sobel et al. skimage.restoration.denoise_tv_chambolle
What is your opinion?
Best, Johannes
Thanks for your feedback!
(I'm probably not representative of the typical skimage user though - so don't take my opinion too seriously!)
I am not sure if there is a typical skimage user... at least we don't have a good picture of what people are using the library at this point. Maybe we should do a survey at some point...
I agree with Robin that changing the range of values silently (if that's still the case) is a problem for users like us where the pixel values are actually some kind of physical measures and not just a RGB value of a photograph. One quick fix would be to be 'quite loud' about it and provide user feedback when it happens. I would welcome an effort to remove this where possible. Michael On Wednesday, February 17, 2016 at 3:39:57 PM UTC-7, Johannes Schönberger wrote:
Thanks for your feedback!
(I'm probably not representative of the typical skimage user though - so don't take my opinion too seriously!)
I am not sure if there is a typical skimage user... at least we don't have a good picture of what people are using the library at this point. Maybe we should do a survey at some point...
On 17 February 2016 at 15:36, Michael Aye <kmichael.aye@gmail.com> wrote:
I agree with Robin that changing the range of values silently (if that's still the case) is a problem for users like us where the pixel values are actually some kind of physical measures and not just a RGB value of a photograph. One quick fix would be to be 'quite loud' about it and provide user feedback when it happens. I would welcome an effort to remove this where possible.
I am not opposed to supporting range preservation, but we do have to think a bit about the implications: - what do you do when the data-type of values change? - what do you do when your operation due to, e.g., rounding issues push values outside the input range? - what do you do when you need to know the full potential range of the data? The ``preserve_range`` flag has allowed us to do whatever we do normally, unless the user gave explicit permission to change data types, ranges, etc. It also serves as a nice tag for "I, the developer, thought about this issue". Stéfan
participants (4)
-
Johannes Schönberger -
Michael Aye -
Robin Wilson -
Stéfan van der Walt