Error on functional_pil.resize with accimage

[YosuaMichael]

🐛 Describe the bug

I think the PR #6191 broke the test_transforms.py test_accimage_resize. (detected on internal CI)

To reproduce, we should install accimage (see https://github.com/pytorch/accimage) and do the test using the following command:

pytest test_transforms.py -k test_accimage_resize

This will fail and produce stacktrace:

Traceback (most recent call last):
  File "/fsx/users/yosuamichael/repos/vision/test/test_transforms.py", line 187, in test_accimage_resize
    output = trans(accimage.Image(GRACE_HOPPER))
  File "/fsx/users/yosuamichael/repos/vision/torchvision/transforms/transforms.py", line 95, in __call__
    img = t(img)
  File "/fsx/users/yosuamichael/conda/envs/vision-c113/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1129, in _call_impl
    return forward_call(*input, **kwargs)
  File "/fsx/users/yosuamichael/repos/vision/torchvision/transforms/transforms.py", line 346, in forward
    return F.resize(img, self.size, self.interpolation, self.max_size, self.antialias)
  File "/fsx/users/yosuamichael/repos/vision/torchvision/transforms/functional.py", line 472, in resize
    return F_pil.resize(img, size=output_size, interpolation=pil_interpolation)
  File "/fsx/users/yosuamichael/repos/vision/torchvision/transforms/functional_pil.py", line 252, in resize
    return img.resize(size[::-1], interpolation)
SystemError: new style getargs format but argument is not a tuple

But strangely our current CI is green, does this mean we skip this test on our CI?

cc @vfdev-5 @datumbox

Versions

Collecting environment information...
PyTorch version: 1.12.0.dev20220419
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
CMake version: version 3.22.3
Libc version: glibc-2.27

Python version: 3.9.12 (main, Apr  5 2022, 06:56:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.4.0-1069-aws-x86_64-with-glibc2.27
Is CUDA available: False
CUDA runtime version: 11.1.105
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Probably one of the following:
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.0.5  
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.0.5  
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.0.5
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.0.5
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.0.5
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.1.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy==0.950
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.22.3
[pip3] pytorch-lightning==1.6.4
[pip3] pytorchvideo==0.1.5
[pip3] torch==1.12.0.dev20220419
[pip3] torchmetrics==0.9.1
[pip3] torchmultimodal==0.1.0a0
[pip3] torchvision==0.13.0a0+1316541
[conda] blas                      1.0                         mkl
[conda] cudatoolkit               11.3.1               h2bc3f7f_2
[conda] mkl                       2022.0.1           h06a4308_117
[conda] numpy                     1.22.3                   pypi_0    pypi  
[conda] pytorch                   1.12.0.dev20220419 py3.9_cuda11.3_cudnn8.3.2_0    pytorch-nightly
[conda] pytorch-lightning         1.6.4                    pypi_0    pypi  
[conda] pytorch-mutex             1.0                        cuda    pytorch-nightly
[conda] pytorchvideo              0.1.5                    pypi_0    pypi  
[conda] torchmetrics              0.9.1                    pypi_0    pypi  
[conda] torchmultimodal           0.1.0a0                   dev_0    <develop>
[conda] torchvision               0.13.0a0+1316541           dev_0    <develop>

[NicolasHug]

But strangely our current CI is green, does this mean we skip this test on our CI?

Yeah, we don't test against accimage on GH, just internally.

This kind of issue pop up rarely, but regularly. For example #5541 (comment):

This comment from @fmassa seems to suggest that we actually don't support accimage anymore

We don't have Travis (nor accimage) tests anymore, closing this.

That being said, we still claim on our README that accimage is part of the supported backends. Let's wait for @fmassa 's insights before we decide to fully remove it, or actually tests against it.

IIRC, the conclusion was to do nothing. Before completely removing accimage support we'd have to figure out whether people actually rely on it internally or not.

[YosuaMichael]

#6208 fix this issue