On 25 Jul 2021, at 2:59 pm, Stefan van der Walt <stefanv@berkeley.edu> wrote:

On Sat, Jul 24, 2021, at 17:58, Juan Nunez-Iglesias wrote:
I'm very glad to hear from you, Josh 😊, but I'm 100% convinced that removing the automatic rescaling is the right path forward. Stéfan, "floats between [0, 1]" is easy enough to explain, except when it isn't (signed filters), or when we automatically rescale int32s in [0, 255] to floats in [0, 2**(-31)], or uint16s in [0, 4095] to floats in [0, 2**(-4)], etc. 

That's why I proposed not automatically scaling integer arrays, but erroring instead. 

I also don't understand what you mean by "excepted when it isn't (signed filters)". 

If a linear filter contains negative values, the output will not be in [0, 1] but in [-1, 1].

Can you motivate more carefully why our current approach is problematic and insufficient in some cases? 

Our current approach is to automatically rescale. You say fine, let’s make it an error when input isn’t float in [0, 1], and force people to rescale. That’s certainly better than the current situation, but it’s still not ideal — in many many cases, `.astype()` will do the job.

Let’s aim for the ideal situation. This isn’t the only silent change we are proposing, just the biggest. ie even if we do keep our [0, 1] limitation, we still need to change coordinate order in some APIs, change the return type of regionprops, rename a bunch of parameters, move a bunch of functions around.