remove spatial_size

[pmeier]

The term "spatial size" was introduced together with v2 and is somewhat ambiguous. Its meaning is

• .shape[-2:], i.e. height and width, for images, videos and masks
• .shape[-2:], i.e. height and width, of the corresponding image, video, or mask for bounding boxes

TL;DR: This PR removes it.

• Rename the BoundingBox.spatial_size attribute as well as all of the spatial_size parameters in our bounding box kernels, e.g.

  vision/torchvision/transforms/v2/functional/_geometry.py

  Lines 54 to 56 in 08c9938

  	def horizontal_flip_bounding_box(
  	bounding_box: torch.Tensor, format: datapoints.BoundingBoxFormat, spatial_size: Tuple[int, int]
  	) -> torch.Tensor:

  to canvas_size. That term is not perfect as well, but I feel it easier to interpret than spatial_size. Another candidate is reference_size. LMK if you prefer that.

• Rename F.get_spatial_size and query_spatial_size to F.get_size and query_size. There is a semantic slip in that name in the sense that it still returns the canvas_size for bounding boxes. However, this is the same as before, where F.get_spatial_size returned the size for images, masks, and videos.

• Remove the .spatial_size, .num_channels, and .num_frames properties from the image, mask, and video datapoint classes. They were exclusively used in the F.get_* functions. The functionality was moved there. They provided little convenience in the first place and keeping them public also clashes with make datapoint methods private #7733.

• Revert part of the changes that extract make_* functions out of make_*_loader #7717 introduced to the testing function make_bounding_box. The function no longer takes a size as positional and a spatial_size as optional keyword argument, but only canvas_size as positional argument. Meaning, the role that size previously filled was removed, since we never used that.

cc @vfdev-5

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/vision/7734

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 23 New Failures

As of commit 276701f:

NEW FAILURES - The following jobs have failed:

• bc (gh)
• linux (linux.12xlarge, cpu) / linux-job (gh)
• macos (macos-12) / macos-job (gh)
• macos (macos-m1-12) / macos-job (gh)
• unittests-linux (3.10, linux.12xlarge, cpu) / linux-job (gh)
• unittests-linux (3.11, linux.12xlarge, cpu) / linux-job (gh)
• unittests-linux (3.8, linux.12xlarge, cpu) / linux-job (gh)
• unittests-linux (3.8, linux.g5.4xlarge.nvidia.gpu, cuda, 11.8) / linux-job (gh)
• unittests-linux (3.9, linux.12xlarge, cpu) / linux-job (gh)
• unittests-macos (3.10, macos-12) / macos-job (gh)
• unittests-macos (3.11, macos-12) / macos-job (gh)
• unittests-macos (3.8, macos-12) / macos-job (gh)
• unittests-macos (3.8, macos-m1-12) / macos-job (gh)
• unittests-macos (3.9, macos-12) / macos-job (gh)
• unittests-prototype (3.10, linux.12xlarge, cpu) / linux-job (gh)
• unittests-prototype (3.11, linux.12xlarge, cpu) / linux-job (gh)
• unittests-prototype (3.8, linux.12xlarge, cpu) / linux-job (gh)
• unittests-prototype (3.9, linux.12xlarge, cpu) / linux-job (gh)
• unittests-windows (3.10, windows.4xlarge, cpu) / windows-job (gh)
• unittests-windows (3.11, windows.4xlarge, cpu) / windows-job (gh)
• unittests-windows (3.8, windows.4xlarge, cpu) / windows-job (gh)
• unittests-windows (3.9, windows.4xlarge, cpu) / windows-job (gh)
• windows (windows.4xlarge, cpu) / windows-job (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[NicolasHug]

Thanks Philip, LGTM if green. Admittedly I didn't review every single line but the summary makes sense to me.

We still have a bunch of occurrences of "spatial_size" in the tests (e.g. in the utils). I assume these will be gone once we finish porting the V2 tests to their new version?