Unexpected behavior in skimage.transforms.rescale() with image shape (x, y, 1)

[wwarriner]

Description

When using skimage.transforms.rescale() with 2D images with a single explicit channel, i.e. shape (x, y, 1), there is an error message I found unhelpful. I expected the function to "just work" with that shape, or at the very least warn that shape is not allowed/expected. Instead I received an OverflowError in the internal gaussian_filter1d() function.

I searched issues for "rescale overflow" and found nothing relating to this behavior.

Way to reproduce

import numpy as np
import skimage.transform

print("(100,100) works")
im = np.zeros(shape=(100, 100))
im = skimage.transform.rescale(image=im, scale=0.29)

print("(100,100,1) doesn't work")
im = np.zeros(shape=(100, 100, 1))
im = skimage.transform.rescale(image=im, scale=0.29)

Actual output

(100,100) works
(100,100,1) doesn't work
/home/$USER/.conda/envs/retina-gan/lib/python3.7/site-packages/skimage/transform/_warps.py:116: RuntimeWarning: divide by zero encountered in true_divide
  np.asarray(output_shape, dtype=float))
Traceback (most recent call last):
  File "downscale.py", line 10, in <module>
    im = skimage.transform.rescale(image=im, scale=0.29)
  File "/home/$USER/.conda/envs/retina-gan/lib/python3.7/site-packages/skimage/transform/_warps.py", line 293, in rescale
    anti_aliasing_sigma=anti_aliasing_sigma)
  File "/home/$USER/.conda/envs/retina-gan/lib/python3.7/site-packages/skimage/transform/_warps.py", line 148, in resize
    cval=cval, mode=ndi_mode)
  File "/home/$USER/.conda/envs/retina-gan/lib/python3.7/site-packages/scipy/ndimage/filters.py", line 299, in gaussian_filter
    mode, cval, truncate)
  File "/home/$USER/.conda/envs/retina-gan/lib/python3.7/site-packages/scipy/ndimage/filters.py", line 214, in gaussian_filter1d
    lw = int(truncate * sd + 0.5)
OverflowError: cannot convert float infinity to integer

Version information

3.7.9 (default, Aug 31 2020, 12:42:55) 
[GCC 7.3.0]
Linux-3.10.0-1062.9.1.el7.x86_64-x86_64-with-redhat-7.9-Maipo
scikit-image version: 0.18.1
numpy version: 1.19.1

[wwarriner]

I see that the "multichannel" parameter (and upcoming "channel_axis" parameter) can fix this issue, which works for now.

I understand this is a challenge when dealing with image structure intent, and each package has to define which axes are spatial, which are channels, which are hyper-spatial (for image stacks or sequences). Is the intent of scikit-image image structures written in the docs somewhere? Is the term "N-dimensional image" explicitly defined to mean "all axes are spatial unless otherwise indicated"? I ask because my intuition coming from other image-related packages is that the last axis is assumed to be channels (unless there are only 2 axes), but here it wasn't, to my surprise.

[grlee77]

We are in the process of deprecating the multichannel boolean and replacing it with a channel_axis integer (or channel_axis=None for no channels dimension). The 0.19 release will support both multichannel and the new channel_axis argument, but eventually multichannel will be dropped.

[grlee77]

I ask because my intuition coming from other image-related packages is that the last axis is assumed to be channels (unless there are only 2 axes), but here it wasn't, to my surprise.

Volumetric (3D) medical images or other forms of non-2D data are supported. Given this we don't want to try to guess what a user is providing and prefer to move to an API where it is made explicit. We do need to make sure we document this prominently.

Thank you for bringing this up as I see that I failed to update this page when adding the channel_axis support.

[wwarriner]

Hi @grlee77, I appreciate your time and comments. Your N-D generalized approach makes sense. I appreciate the link to the page, that helped me better understand how skimage works.. Thank you! My specific issue is resolved.

I'll leave it to your discretion whether to keep this issue open or closed in case it's a helpful bookmark for what you wanted to change about the overall user/developer experience.