Different behavior of skimage.transform.resize across operating systems.

[mcquin]

skimage.transform.resize appears to have different behavior between operating systems. Specifically, Ubuntu 14.04/16.04 and OS X 10.11.6 (I haven't tested on Windows, yet, but I am curious).

Steps to reproduce:

import numpy
import skimage.transform

labels = numpy.zeros((20, 20), dtype=numpy.uint8)
labels[2:8, 2:8] = 1
labels[0:8, 12:18] = 2
labels[12:18, 0:8] = 3
labels[12:20, 12:20] = 4

downsized = skimage.transform.resize(
    labels,
    (10, 5),
    order=0,
    mode="edge",
    preserve_range=True
)

I've created a Jupyter notebook with the code to reproduce the error.

Here is the input image:

Here is the output on OS X:

Here is the output on Ubuntu:

Version information (I have checked that is consistent across platforms):

• scikit-image==0.13.0
• scipy==0.19.0
• numpy==1.12.1

My Python version is 2.7.12 on OS X. I've used on 2.7.3 and 2.7.9 on Ubuntu 12.04 and 14.04 (via Travis), and 2.7.12 on Ubuntu 16.04 (my own box, at work).

[mcquin]

Here it is on Windows (same dependency versions):

[soupault]

Hi @mcquin ! This looks very suspicious...
I've just merged #1522 which brings several major improvements to rescale and resize functions.
Could you, please, (if you have a little of time) try to use the version from master, and check if the plots are still different? If not, I could manage to do this in a couple of days.
Thanks!

[mcquin]

@soupault I see the same results on OS X and Ubuntu 16.04 using scikit-image==0.14dev

[grlee77]

Interesting. I get the same as you on OS X in Python 2.7. However, I get the following on OS X in Python 3.5 (looks like your Windows result above):

I have nominally the same numpy/scipy/skimage on both although 2.7 was using the condo-forge numpy/scipy while 3.5 is using the one from defaults.
In 2.7:

numpy                     1.12.1          py27_blas_openblas_200  [blas_openblas]  conda-forge
scipy                     0.19.0          np112py27_blas_openblas_200  [blas_openblas]  conda-forge
scikit-image 0.14dev

In 3.5:

numpy                     1.12.1                   py35_0  
scipy                     0.19.0              np112py35_0  
scikit-image 0.14dev

[grlee77]

Revisiting the above with numpy/scipy from the conda-forge defaults channel changes the Python 2.7 result to match the 3.5 result. So, it seems to be related to floating point precision. There are tiny floating point differences in the params matrix of the AffineTransform for these two different BLAS/LAPACK builds of numpy/scipy.

If you change the order to 1, I think you will see a very similar result for all platforms/versions. I think it is a matter of floating point rounding errors causing which is the "nearest" neighbor to go one way or the other. I am not sure what a good solution to that is yet.

[grlee77]

perhaps the dest_corners coordinates in resize need to have a small additional shift on the order of machine epsilon to avoid this corner case.

[mcquin]

I suspect rounding differences as well. I can give your suggestion a try first thing tomorrow morning (US Eastern).

…

On Apr 20, 2017 18:05, "Gregory R. Lee" ***@***.***> wrote: perhaps the dest_corners coordinates in resize need to have a small additional shift on the order of machine epsilon to avoid this corner case. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2629 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEgMW0prPxiB_6gvUv6z-7v4EV7rnMR5ks5rx9a1gaJpZM4NDenY> .

[mcquin]

I'm still just starting to look into this, and I have tried adjusting dst_corners (here) by machine epsilon with no effect.

I wonder if it is scikit-image's responsibility to adjust for these machine-level differences.

[mcquin]

For what it's worth, scipy.ndimage.zoom produces output that is consistent with Windows and @grlee77's 3.5 result. Maybe the issue is in the AffineTransform or skimage.transform.warp.

[mcquin]

@soupault This is beyond my understanding of scikit-image internals and roundoff errors. Do you (or someone on the team) have time to take this on?

I have a workaround with scipy.ndimage.zoom so it's not an urgent, personally.

[grlee77]

@mcquin. I just revisited this and had success when adjusting dst_corners, but I had to use a shift of approximately 40 times machine epsilon for it to take effect. E.g. using negative shift of 100*(machine epsilon) gives a result consistent with scipy's ndimage.map_coordinates across both OpenBLAS and MKL-based numpy. will make a PR for this shortly

[mcquin]

Great! Thanks for the update!

…

On May 3, 2017 9:33 PM, "Gregory R. Lee" ***@***.***> wrote: @mcquin <https://github.com/mcquin>. I just revisited this and had success when adjusting dst_corners, but I had to use a shift of approximately 40 times machine epsilon for it to take effect. E.g. using negative shift of 100*(machine epsilon) gives a result consistent with scipy's ndimage.map_coordinates across both OpenBLAS and MKL-based numpy. will make a PR for this shortly — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2629 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEgMW-YMdU_fbUs2CWxqZrGSVZoNyUJcks5r2SrngaJpZM4NDenY> .

[rfezzani]

👀 Looks even worst with current version:

3.7.3 (default, Mar 27 2019, 22:11:17) 
[GCC 7.3.0]
Linux-4.15.0-158-generic-x86_64-with-debian-buster-sid
scikit-image version: 0.19.0.dev0
numpy version: 1.17.4

[grlee77]

Hey @rfezzani, I think this issue was submitted back on scikit-image 0.13 or so when there was no anti-aliasing prefilter in resize. If you modify the example to set anti_aliasing=False, you should get something similar to the results above. Otherwise, the gaussian smoothing step will make things look substantially different.

[rfezzani]

🤦 your right @grlee77, thank you!
Is this bug reproducible?