-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
warp does not scale cval leading to unexpected (wrong?) behavior with preserve_range=False and non-zero cval #7336
Comments
Thanks for the bug report. Indeed this is likely a confusing part of our API. Perhaps an improvement to the documentation would suffice? You can make a PR making modifications to scikit-image/skimage/transform/_warps.py Line 833 in 21485b1
And the added explination will appear in jupyter notebooks and our online documentation |
It might be worth changing the behavior of
Requiring the user to manually scale cval might not be a good idea. It may not occur to many people to do this. Also it's a little bit involved to get the scaling behavior correct. The solution I'm currently using is cval_maybe_rescaled = img_as_float(np.array([cval]).astype(image.dtype)).item() which is a little bit ugly/involved for the user to do on their own. I would vote for option 1, but it might be worth getting other people's input on this. TradeoffsOption 1
Option 2
Option 2, default to automatic rescale
Option 2, default to current behavior with no rescale
Option 3
If we go with option 2/3 we could add a function to skimage |
I don't disagree with any of the core concepts you bring up, i'm just not sure a 1-2 year(+???) deprecation cycle is really what you want. The worst part for you, will likely be that you will have old code that requires an old version of scikit image (for whatever reason) that will just behave exactly in the way you do not expect. You'll end up writing your own compatibility shims to work with scikit-image 0.20.0 (1 year old) to today's version (0.22.0) through to the future versions where your proposals would end up being the default.
I'm trying to find where consensus along the core maintainers (myself included) has landed and the general idea is to set This is one comment that hints at that, but we had a larger discussion somewhere Option 1 and 2 are fine proposals, just given the bandwidth of the core maintainers, I don't think they will get implemented. The line between bug and feature is quite thin in this particular example, unfortunately, documenting this quirk in the behavior might be the fastest and most effective approach for all parties. |
I concur with @hmaarrfk. In a vacuum option 1 seems most intuitive to me. However, it also seems like something that changes output for the same input. We have a policy not to do that. Even if an intermediate deprecation would warn most users, some might miss it and might have trouble reproducing their results down the line. As Mark hinted at, we plan to remove automatic scaling in most cases by default in "skimage2". I'll add this as a problem to address in API changes for skimage2. In the meantime and in addition to documenting the behavior, we could raise a warning if the |
Got it -- that all makes sense. I'll put in a PR when I get a chance to come back to this! |
Description:
When you call warp with
preserve_range=False
. The values of the pixels in are usually scaled (e.g. if the input image were uint8 then 255 gets mapped to 1). Howeverwarp
does not also scale thecval
which is used to pad the image.In the example below the pixels in the non-padded part of the output image are all between 0 and 1, but the padded pixels are set to 255.
I think the most straightforward solution is to rescale cval if
preserve_range=False
.Way to reproduce:
1.0
255.0
Version information:
The text was updated successfully, but these errors were encountered: