internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: pytorch/vision

Issue:
PascalVOC 2009 wrong hash
### 🐛 Describe the bug

There is a wrong checksum defined for PascalVOC year 2009

```bash
$ wget -q http://host.robots.ox.ac.uk/pascal/VOC/voc2009/VOCtrainval_11-May-2009.tar
$ md5sum VOCtrainval_11-May-2009.tar
a3e00b113cfcfebf17e343f59da3caa1  VOCtrainval_11-May-2009.tar
```

However, that's not a hash that is defined in a PascalVOC dataset file
https://github.com/pytorch/vision/blob/0db67d857d612b8b5f196d1b9e1314d07b8a7a29/torchvision/datasets/voc.py#L37-L42

This can be tested with:
```python
>>> import torchvision
>>> torchvision.datasets.VOCSegmentation('.', year='2009', download=True)
...
RuntimeError: Dataset not found or corrupted.
```

### Versions

```
Collecting environment information...
PyTorch version: 1.10.2+cu113
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 21.10 (x86_64)
GCC version: (Ubuntu 11.2.0-7ubuntu2) 11.2.0
Clang version: Could not collect
CMake version: version 3.18.4
Libc version: glibc-2.34

Python version: 3.9.7 (default, Sep 10 2021, 14:59:43)  [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.13.0-28-generic-x86_64-with-glibc2.34
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: GPU 0: NVIDIA GeForce GTX 950M
Nvidia driver version: 510.47.03
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.2
[pip3] torch==1.10.2+cu113
[pip3] torchaudio==0.10.2+cu113
[pip3] torchvision==0.11.3+cu113
[conda] Could not collect
```


Discussion:

Resolving patch:
diff --git a/torchvision/datasets/voc.py b/torchvision/datasets/voc.py
--- a/torchvision/datasets/voc.py
+++ b/torchvision/datasets/voc.py
@@ -37,7 +37,7 @@
     "2009": {
         "url": "http://host.robots.ox.ac.uk/pascal/VOC/voc2009/VOCtrainval_11-May-2009.tar",
         "filename": "VOCtrainval_11-May-2009.tar",
-        "md5": "59065e4b188729180974ef6572f6a212",
+        "md5": "a3e00b113cfcfebf17e343f59da3caa1",
         "base_dir": os.path.join("VOCdevkit", "VOC2009"),
     },
     "2008": {


Test patch:
Repository: pytorch/vision

Issue:
transforms.{RandomAdjustSharpness,RandomPosterize}: `p` parameter 
### 📚 The doc issue

The docstring of parameter `p` for [RandomAdjustSharpness](https://pytorch.org/vision/stable/generated/torchvision.transforms.RandomAdjustSharpness.html#torchvision.transforms.RandomAdjustSharpness) says:

> p ([float](https://docs.python.org/3/library/functions.html#float)) – probability of the image being color inverted. Default value is 0.5 

### Suggest a potential alternative/fix

> p ([float](https://docs.python.org/3/library/functions.html#float)) – probability of the image being **sharpened**. Default value is 0.5 

Also for RandomPosterize, RandomSolarize, but RandomSolarize actually performs a color inversion so it's OK there.


Discussion:
Thanks this is probably due to copy-pasting the docstring. Would you be interested in sending a PR to fix it?

Resolving patch:
diff --git a/torchvision/transforms/transforms.py b/torchvision/transforms/transforms.py
--- a/torchvision/transforms/transforms.py
+++ b/torchvision/transforms/transforms.py
@@ -1894,7 +1894,7 @@ class RandomPosterize(torch.nn.Module):
 
     Args:
         bits (int): number of bits to keep for each channel (0-8)
-        p (float): probability of the image being color inverted. Default value is 0.5
+        p (float): probability of the image being posterized. Default value is 0.5
     """
 
     def __init__(self, bits, p=0.5):
@@ -1927,7 +1927,7 @@ class RandomSolarize(torch.nn.Module):
 
     Args:
         threshold (float): all pixels equal or above this value are inverted.
-        p (float): probability of the image being color inverted. Default value is 0.5
+        p (float): probability of the image being solarized. Default value is 0.5
     """
 
     def __init__(self, threshold, p=0.5):
@@ -1960,7 +1960,7 @@ class RandomAdjustSharpness(torch.nn.Module):
         sharpness_factor (float):  How much to adjust the sharpness. Can be
             any non negative number. 0 gives a blurred image, 1 gives the
             original image while 2 increases the sharpness by a factor of 2.
-        p (float): probability of the image being color inverted. Default value is 0.5
+        p (float): probability of the image being sharpened. Default value is 0.5
     """
 
     def __init__(self, sharpness_factor, p=0.5):


Test patch:
Repository: pytorch/vision

Issue:
ColorJitter> adjust_hue>_rgb2hsv lack of proper documentation.
### 📚 The doc issue

Following up on #3110, it seems that lack of proper documentation on `ColorJitter`, and specifically its underlying transform `adjust_hue` which uses `_rgb2hsv` is causing issues for more and more people. https://github.com/pytorch/vision/issues/3110#issuecomment-1009688670 https://github.com/pytorch/vision/issues/3110#issuecomment-1064918900

I remember back in 2020, it took me days to track down this issue, which was causing my training pipeline to fail while a simple documentation of input requirements could have saved the day.

### Suggest a potential alternative/fix

The docstrings of this functions need to be updated with the information about some characteristics of the input image, and potential preprocessing that can cause these functions fail, like certain way of normalization and interpolation.


Discussion:
Thanks @drbeh if you send a PR that updates the documentation to add clarifications, I'll be happy to review it.

Resolving patch:
diff --git a/torchvision/transforms/functional.py b/torchvision/transforms/functional.py
--- a/torchvision/transforms/functional.py
+++ b/torchvision/transforms/functional.py
@@ -880,6 +880,9 @@ def adjust_hue(img: Tensor, hue_factor: float) -> Tensor:
             If img is torch Tensor, it is expected to be in [..., 1 or 3, H, W] format,
             where ... means it can have an arbitrary number of leading dimensions.
             If img is PIL Image mode "1", "I", "F" and modes with transparency (alpha channel) are not supported.
+            Note: the pixel values of the input image has to be non-negative for conversion to HSV space;
+            thus it does not work if you normalize your image to an interval with negative values,
+            or use an interpolation that generates negative values before using this function.
         hue_factor (float):  How much to shift the hue channel. Should be in
             [-0.5, 0.5]. 0.5 and -0.5 give complete reversal of hue channel in
             HSV space in positive and negative direction respectively.
diff --git a/torchvision/transforms/transforms.py b/torchvision/transforms/transforms.py
--- a/torchvision/transforms/transforms.py
+++ b/torchvision/transforms/transforms.py
@@ -1156,6 +1156,9 @@ class ColorJitter(torch.nn.Module):
         hue (float or tuple of float (min, max)): How much to jitter hue.
             hue_factor is chosen uniformly from [-hue, hue] or the given [min, max].
             Should have 0<= hue <= 0.5 or -0.5 <= min <= max <= 0.5.
+            To jitter hue, the pixel values of the input image has to be non-negative for conversion to HSV space;
+            thus it does not work if you normalize your image to an interval with negative values,
+            or use an interpolation that generates negative values before using this function.
     """
 
     def __init__(self, brightness=0, contrast=0, saturation=0, hue=0):


Test patch:
Repository: pytorch/vision

Issue:
Mypy job failing due to incorrect return-value from upstream
The latest, freshest mypy time waster

https://app.circleci.com/pipelines/github/pytorch/vision/17366/workflows/a475b8b1-1463-4159-bf00-be2d82030c0b/jobs/1405650

Caused by https://github.com/pytorch/pytorch/pull/74171

I think we just need to wait for https://github.com/pytorch/pytorch/pull/76895 to be in the nightlies

```
torchvision/models/_api.py:64: error: Incompatible return value type (got
Module, expected "OrderedDict[Any, Any]")  [return-value]
            return load_state_dict_from_url(self.url, progress=progress)
                   ^
Found 1 error in 1 file (checked 209 source files)

Exited with code exit status 1

CircleCI received exit code 1
```


Discussion:

Resolving patch:
diff --git a/torchvision/models/_api.py b/torchvision/models/_api.py
--- a/torchvision/models/_api.py
+++ b/torchvision/models/_api.py
@@ -1,7 +1,6 @@
 import importlib
 import inspect
 import sys
-from collections import OrderedDict
 from dataclasses import dataclass, fields
 from inspect import signature
 from typing import Any, Callable, Dict, cast
@@ -60,7 +59,7 @@ def verify(cls, obj: Any) -> Any:
                 )
         return obj
 
-    def get_state_dict(self, progress: bool) -> OrderedDict:
+    def get_state_dict(self, progress: bool) -> Dict[str, Any]:
         return load_state_dict_from_url(self.url, progress=progress)
 
     def __repr__(self) -> str:


Test patch:
Repository: pytorch/vision

Issue:
PIL version check for enum change appears to break SIMD versions
### 🐛 Describe the bug

This change appears to break current Pillow-SIMD version #5898 

```
    if tuple(int(part) for part in PIL.__version__.split(".")) >= (9, 1):
  File "/home/.../lib/python3.10/site-packages/torchvision/transforms/_pil_constants.py", line 7, in <genexpr>
    if tuple(int(part) for part in PIL.__version__.split(".")) >= (9, 1):
ValueError: invalid literal for int() with base 10: 'post1'
```

Amusingly enough, I warned against this approach in a users PR in `timm` https://github.com/rwightman/pytorch-image-models/pull/1256

Would be nice to have it fixed before 1.12 is finalized, I just hit this trying out the RC

### Versions

PT 1.12 RC, TV 0.13.0


Discussion:
The version string for Pillow-SIMD 
```
pillow-simd               9.0.0.post1              pypi_0    pypi
```

We should definitely use `from packaging.version import Version` instead of manual parsing:
```python
from packaging.version import Version

v = Version("9.0.0.post1")
v > Version("9.1.0")
# False
```

However, the main drawback with `packaging` is that it is not a built-in package :(

Resolving patch:
diff --git a/torchvision/transforms/_pil_constants.py b/torchvision/transforms/_pil_constants.py
--- a/torchvision/transforms/_pil_constants.py
+++ b/torchvision/transforms/_pil_constants.py
@@ -1,10 +1,9 @@
-import PIL
 from PIL import Image
 
 # See https://pillow.readthedocs.io/en/stable/releasenotes/9.1.0.html#deprecations
 # TODO: Remove this file once PIL minimal version is >= 9.1
 
-if tuple(int(part) for part in PIL.__version__.split(".")) >= (9, 1):
+if hasattr(Image, "Resampling"):
     BICUBIC = Image.Resampling.BICUBIC
     BILINEAR = Image.Resampling.BILINEAR
     LINEAR = Image.Resampling.BILINEAR


Test patch:
diff --git a/test/test_transforms.py b/test/test_transforms.py
--- a/test/test_transforms.py
+++ b/test/test_transforms.py
@@ -1522,10 +1522,10 @@ def test_ten_crop(should_vflip, single_dim):
     five_crop.__repr__()
 
     if should_vflip:
-        vflipped_img = img.transpose(Image.FLIP_TOP_BOTTOM)
+        vflipped_img = img.transpose(_pil_constants.FLIP_TOP_BOTTOM)
         expected_output += five_crop(vflipped_img)
     else:
-        hflipped_img = img.transpose(Image.FLIP_LEFT_RIGHT)
+        hflipped_img = img.transpose(_pil_constants.FLIP_LEFT_RIGHT)
         expected_output += five_crop(hflipped_img)
 
     assert len(results) == 10
Repository: pytorch/vision

Issue:
bug in transforms.py
### 🐛 Describe the bug

### location:
https://github.com/pytorch/vision/blob/112accf95631660d55fc3761e8133f1c4bc6ae89/torchvision/transforms/transforms.py#L631
### fix:

`if h + 1 < th or w + 1 < tw:`  ==>`if h < th or w < tw:`



cc @vfdev-5 @datumbox


Discussion:
@fenneishi thanks for reporting.

@vfdev-5 I see this was introduced at #2816. For `h=100, th=101` this will lead to `101<101` which seems wrong. Do you remember if there was a specific reason for adding the +1s or you think it's a bug?
Yes, it is a bug. The condition `if h + 1 < th or w + 1 < tw:` was derived wrongly from`torch.randint(0, h - th + 1, size=(1,))` as we need to generate a random int value. `h - th + 1` is the upper non-inclusive boundary.

It should be `h - th + 1 >= 2` -> `h + 1 >= th + 2` -> `h >= th + 1` or `h > th`. We also need to take into account that `h == th`. Thus, obviously correct condition is `if h < th: raise error`

Resolving patch:
diff --git a/torchvision/prototype/transforms/_geometry.py b/torchvision/prototype/transforms/_geometry.py
--- a/torchvision/prototype/transforms/_geometry.py
+++ b/torchvision/prototype/transforms/_geometry.py
@@ -443,7 +443,7 @@ def _get_params(self, sample: Any) -> Dict[str, Any]:
             if height < output_height:
                 height += 2 * (output_height - height)
 
-        if height + 1 < output_height or width + 1 < output_width:
+        if height < output_height or width < output_width:
             raise ValueError(
                 f"Required crop size {(output_height, output_width)} is larger then input image size {(height, width)}"
             )
diff --git a/torchvision/transforms/transforms.py b/torchvision/transforms/transforms.py
--- a/torchvision/transforms/transforms.py
+++ b/torchvision/transforms/transforms.py
@@ -628,7 +628,7 @@ def get_params(img: Tensor, output_size: Tuple[int, int]) -> Tuple[int, int, int
         _, h, w = F.get_dimensions(img)
         th, tw = output_size
 
-        if h + 1 < th or w + 1 < tw:
+        if h < th or w < tw:
             raise ValueError(f"Required crop size {(th, tw)} is larger than input image size {(h, w)}")
 
         if w == tw and h == th:


Test patch:
diff --git a/test/test_transforms.py b/test/test_transforms.py
--- a/test/test_transforms.py
+++ b/test/test_transforms.py
@@ -1670,7 +1670,7 @@ def test_random_crop():
     assert result.size(1) == height + 1
     assert result.size(2) == width + 1
 
-    t = transforms.RandomCrop(48)
+    t = transforms.RandomCrop(33)
     img = torch.ones(3, 32, 32)
     with pytest.raises(ValueError, match=r"Required crop size .+ is larger than input image size .+"):
         t(img)
Repository: pytorch/vision

Issue:
Swapped width and height in DefaultBoxGenerator
In the DefaultBoxGenerator module, the image sizes in the image_size argument are given as (height, width) by SSD model but the code assumes (width, height).

https://github.com/pytorch/vision/blob/15a9a93b9e0e6173b936691a2cddced0ecfd271f/torchvision/models/detection/anchor_utils.py#L216-L217

I think this has gone unnoticed because the images are usually resized into squares.

cc @datumbox


Discussion:

Resolving patch:
diff --git a/torchvision/models/detection/anchor_utils.py b/torchvision/models/detection/anchor_utils.py
--- a/torchvision/models/detection/anchor_utils.py
+++ b/torchvision/models/detection/anchor_utils.py
@@ -213,8 +213,8 @@ def _grid_default_boxes(
         for k, f_k in enumerate(grid_sizes):
             # Now add the default boxes for each width-height pair
             if self.steps is not None:
-                x_f_k = image_size[0] / self.steps[k]
-                y_f_k = image_size[1] / self.steps[k]
+                x_f_k = image_size[1] / self.steps[k]
+                y_f_k = image_size[0] / self.steps[k]
             else:
                 y_f_k, x_f_k = f_k
 


Test patch:
Repository: pytorch/vision

Issue:
SBU download is failing
This is happening since roughly a month (first detection in #6274), but was masked by #6268. 

http://www.cs.virginia.edu/~vicente/sbucaptions/

The server is still up, but the path is no longer valid. I'll reach out to the author to see if this can be fixed. In the meantime we should probably disable the test.

cc @pmeier @YosuaMichael


Discussion:
I've contacted the author of the paper and the new link is 

https://www.cs.rice.edu/~vo9/sbucaptions/

Will send a PR to update our sources.
The author provided me a link to the actual image archive rather than just an URL list. The website reads

> Alternatively, if you're interested in the image collection for research purposes please email vicenteor@rice.edu

I'm checking back if it is ok for us to publish that link. That would simplify the download by quite a bit and would mean the discussion in #5706 is moot for now.

Resolving patch:
diff --git a/torchvision/datasets/sbu.py b/torchvision/datasets/sbu.py
--- a/torchvision/datasets/sbu.py
+++ b/torchvision/datasets/sbu.py
@@ -22,7 +22,7 @@ class SBU(VisionDataset):
             downloaded again.
     """
 
-    url = "http://www.cs.virginia.edu/~vicente/sbucaptions/SBUCaptionedPhotoDataset.tar.gz"
+    url = "https://www.cs.rice.edu/~vo9/sbucaptions/SBUCaptionedPhotoDataset.tar.gz"
     filename = "SBUCaptionedPhotoDataset.tar.gz"
     md5_checksum = "9aec147b3488753cf758b4d493422285"
 


Test patch:
diff --git a/test/test_datasets_download.py b/test/test_datasets_download.py
--- a/test/test_datasets_download.py
+++ b/test/test_datasets_download.py
@@ -447,6 +447,7 @@ def make_parametrize_kwargs(download_configs):
             omniglot(),
             phototour(),
             sbdataset(),
+            sbu(),
             semeion(),
             stl10(),
             svhn(),
@@ -470,7 +471,6 @@ def test_url_is_accessible(url, md5):
     **make_parametrize_kwargs(
         itertools.chain(
             places365(),  # https://github.com/pytorch/vision/issues/6268
-            sbu(),  # https://github.com/pytorch/vision/issues/6390
         )
     )
 )
Repository: pytorch/vision

Issue:
Don't hardcode 255 unless uint8 is enforced
Across our transformations we sometimes hardcode the value `255`. This is justified if we make sure that point only `torch.uint8` images are allowed, like

https://github.com/pytorch/vision/blob/788ad12e5dcec1dffc7d6311e59a2be2792799b8/torchvision/transforms/functional_tensor.py#L471-L472

However, there are a few instances where uint8 is implied but never enforced:

https://github.com/pytorch/vision/blob/788ad12e5dcec1dffc7d6311e59a2be2792799b8/torchvision/transforms/functional_tensor.py#L266-L267

https://github.com/pytorch/vision/blob/788ad12e5dcec1dffc7d6311e59a2be2792799b8/torchvision/transforms/functional_tensor.py#L778-L779

https://github.com/pytorch/vision/blob/788ad12e5dcec1dffc7d6311e59a2be2792799b8/torchvision/transforms/functional_tensor.py#L852

Instead of hardcoding `255` here, we should either use `_max_value(dtype)` instead or if uint8 is actually required, enforce it.


cc @vfdev-5 @datumbox


Discussion:

Resolving patch:
diff --git a/torchvision/prototype/transforms/functional/_color.py b/torchvision/prototype/transforms/functional/_color.py
--- a/torchvision/prototype/transforms/functional/_color.py
+++ b/torchvision/prototype/transforms/functional/_color.py
@@ -313,7 +313,8 @@ def posterize(inpt: features.InputTypeJIT, bits: int) -> features.InputTypeJIT:
 
 
 def solarize_image_tensor(image: torch.Tensor, threshold: float) -> torch.Tensor:
-    if threshold > _FT._max_value(image.dtype):
+    bound = 1 if image.is_floating_point() else 255
+    if threshold > bound:
         raise TypeError(f"Threshold should be less or equal the maximum value of the dtype, but got {threshold}")
 
     return torch.where(image >= threshold, invert_image_tensor(image), image)
@@ -466,7 +467,7 @@ def invert_image_tensor(image: torch.Tensor) -> torch.Tensor:
     if image.dtype == torch.uint8:
         return image.bitwise_not()
     else:
-        return _FT._max_value(image.dtype) - image  # type: ignore[no-any-return]
+        return (1 if image.is_floating_point() else 255) - image  # type: ignore[no-any-return]
 
 
 invert_image_pil = _FP.invert


Test patch:
Repository: pytorch/vision

Issue:
Toasted CI due to attempt at installing numpy-1.25.0rc1 which requires 3.9
Most CI jobs are red due to an installation issue (https://github.com/pytorch/vision/pull/5009)

```
  Searching for numpy
  Reading https://pypi.org/simple/numpy/
  Downloading https://files.pythonhosted.org/packages/26/de/437a60a69f7fd0c79264530a97787b2ac7394616e3661236201518f8a47d/numpy-1.25.0rc1.tar.gz#sha256=224e8862a1cd357eede831b270b9e6c51d2cbc2bb5cc2e2b8d0c76d52cbd1edc
  Best match: numpy 1.25.0rc1
  Processing numpy-1.25.0rc1.tar.gz
  Writing /tmp/easy_install-387ykuae/numpy-1.25.0rc1/setup.cfg
  Running numpy-1.25.0rc1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-387ykuae/numpy-1.25.0rc1/egg-dist-tmp-9r05yq36
  Traceback (most recent call last):
    File "/opt/conda/envs/ci/lib/python3.8/site-packages/setuptools/sandbox.py", line 156, in save_modules
      yield saved
    File "/opt/conda/envs/ci/lib/python3.8/site-packages/setuptools/sandbox.py", line 198, in setup_context
      yield
    File "/opt/conda/envs/ci/lib/python3.8/site-packages/setuptools/sandbox.py", line 259, in run_setup
      _execfile(setup_script, ns)
    File "/opt/conda/envs/ci/lib/python3.8/site-packages/setuptools/sandbox.py", line 46, in _execfile
      exec(code, globals, locals)
    File "/tmp/easy_install-387ykuae/numpy-1.25.0rc1/setup.py", line 22, in <module>
      return get_distribution(pkgname)
  RuntimeError: Python version >= 3.9 required.
```


@pmeier do you mind taking a look? Not sure what's causing it but we should look into why it's trying to install a RC instead of a stable numpy version.


Discussion:
This happens because the really outdated `easy_install` that we are still using internally, does not care about required Python versions. `numpy` released `1.25.0rc1` today, which no longer has a wheel for Python 3.8. However, it has a `.tar.gz` version so it tries to compile from source. But instead of discarding the tarball as soon as it realizes the Python version is not supported, it bails out.

In contrast, doing the same with `pip` in a clean Python 3.8 environment gives

```
❯ python -VV
[GCC 11.3.0]
Python 3.8.16 | packaged by conda-forge | (default, Feb  1 2023, 16:01:55) 
❯ pip install --pre numpy
Collecting numpy
  Using cached numpy-1.24.3-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (17.3 MB)
Installing collected packages: numpy
Successfully installed numpy-1.24.3
```

Without `--pre`, `pip` ignores the pre-releases completely. 


Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -57,8 +57,10 @@ def write_version_file():
 if os.getenv("PYTORCH_VERSION"):
     pytorch_dep += "==" + os.getenv("PYTORCH_VERSION")
 
+numpy_dep = "numpy" if sys.version_info[:2] >= (3, 9) else "numpy < 1.25"
+
 requirements = [
-    "numpy",
+    numpy_dep,
     "requests",
     pytorch_dep,
 ]


Test patch:
Repository: pytorch/vision

Issue:
bug when using PIL backend in classification references
### 🐛 Describe the bug

When I try to train a model using the train.py script under references/classification with the PIL backend, I encounter an error:
```bash
ValueError: backend can be 'tensor' or 'pil', but got pil
```

To reproduce this issue, you can write:
```bash
git clone https://github.com/pytorch/vision && cd vision
conda create -n vision_env python=3.9
conda activate vision_env
pip install torch==1.13.1 torchvision
cd references/classification/
python train.py --data-path "path-to-dataset" --test-only --backend pil
```

### Versions

[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.24.3
[pip3] torch==1.13.1
[pip3] torchvision==0.14.1
[conda] numpy                     1.24.3                   pypi_0    pypi
[conda] torch                     1.13.1                   pypi_0    pypi
[conda] torchvision               0.14.1                   pypi_0    pypi


Discussion:

Resolving patch:
diff --git a/references/classification/presets.py b/references/classification/presets.py
--- a/references/classification/presets.py
+++ b/references/classification/presets.py
@@ -69,11 +69,10 @@ def __init__(
         backend="pil",
     ):
         trans = []
-
         backend = backend.lower()
         if backend == "tensor":
             trans.append(transforms.PILToTensor())
-        else:
+        elif backend != "pil":
             raise ValueError(f"backend can be 'tensor' or 'pil', but got {backend}")
 
         trans += [


Test patch: