Open opoplawski opened 1 year ago
It seems that we are hitting bugs in Pillow (which we use to dispatch image loading: skimage->imageio->pillow)
as we drill down into this, do you know how to skip certain tests?
Sorry to ask you to read templating code, but you can see what we do for conda-forge releases: https://github.com/conda-forge/scikit-image-feedstock/blob/main/recipe/meta.yaml#L125
We use the -k
flag
https://docs.pytest.org/en/6.2.x/usage.html#specifying-tests-selecting-tests
I hope this helps move your builds forward while we debug the tests
Looks like we have pillow 9.5.0. Yes, I can disable tests if needed to move forward, thanks.
I'm not sure how motivated you are to get to the bottom of this, but I suspect it will be difficult for us to craft a minimum reproducing example, but I expect it will be rather short. once we reproduce, we could work with pillow to fix it.
Pillow documentation mentions:
I;16B (16-bit big endian unsigned integer pixels)
https://pillow.readthedocs.io/en/stable/handbook/concepts.html
so it seems that we may have an endienness problem in that test
@opoplawski Would you check whether this test failure is appearing with imageio 2.31.0 or an earlier version of imageio?
Beautiful (and annoying) xD
TestSave.test_imsave_roundtrip[shape1-uint16]
is most likely a big-endian vs little-endian issue. You are passing an array of uint16 (big-endian) integers to pillow, and it complains/fails because it's PNG plugin can't save that. What's ironic about this is that PNG internally stores data as big-endian so (in theory) this should be easy to do.
I don't own a system that has a big-endian architecture (nor does GH actions afaik), so it is hard for me to do any concrete investigation beyond looking at the log you've shared. Based on the test name though, my guess is that skimage (via ImageIO) is loading a PNG into machine-native 16-bit and then fails to save it later because pillow doesn't know how to save uint16 big-endian as PNG.
(this is likely a bug in pillow with a simple fix)
test_all_mono
appears to have a problem with img_as_uint
. Since it only fails on s390x only, I think it could also be worth checking if this is a big/little endian problem. (I don't know the test, but I assume that this is unrelated to pillow)
test_analytical_moments_calculation[3-1-float32]
is a numerics problem - again probably not caused by pillow. This could trace back to changes in how moment calculations are implemented, or it could be platform-specific differences in numerical accuracy (I don't know s390x beyond that it is big-endian). If it is related to changes in implementation the test should pass in an earlier version of skimage, if it is platform-specific it will fail in any case and debugging will become a bit more complicated...
I'd just like to mention that we have the same problem in Debian. Current PIL version is 0.10.0, imageio version is 2.31.1. It seems that GH actions can (slowly) run s390x; see the weekly actions in astropy.
Hello scikit-image core devs! There hasn't been any activity on this issue for more than 180 days. I have marked it as "dormant" to make it easy to find. To our contributors, thank you for your contribution and apologies if this issue fell through the cracks! Hopefully this ping will help bring some fresh attention to the issue. If you need help, you can always reach out on our forum If you think that this issue is no longer relevant, you may close it, or we may do it at some point (either way, it will be done manually).
Description:
Working on updating the Fedora scikit-image package to 0.21.0 I'm getting the following test failures on s390x only:
Way to reproduce:
Version information: