[NOMRG] TransformsV2 TODOs

[NicolasHug]

Just keeping track of a bunch of TODOs following up on conversations with @pmeier and @vfdev-5 .

[pmeier]

This works out 🚀 Gonna send a PR soon.

[pmeier]

See #7084

[pmeier]

Most likely not. We only introduced them for internal convenience. Whenever you see something annotates with *JIT, you can basically look up the eager counterpart to see what is actually supported.

[pmeier]

For context, this was designed with the use case of other color spaces with the same number of channels. For example, #4029. Since we can always add this later on, I see no harm of removing it now. That being said, I would keep the ColorSpace enum for

vision/torchvision/prototype/transforms/functional/_meta.py

Line 331 in 035d99f

def convert_color_space(

which is a generalized replacement for

vision/torchvision/prototype/transforms/functional/_deprecated.py

Line 12 in 035d99f

def to_grayscale(inpt: PIL.Image.Image, num_output_channels: int = 1) -> PIL.Image.Image:

and

vision/torchvision/prototype/transforms/functional/_deprecated.py

Line 25 in 035d99f

def rgb_to_grayscale(

[pmeier]

While going through our source again, I noticed this:

vision/torchvision/prototype/transforms/functional/_meta.py

Lines 339 to 347 in 035d99f

	if isinstance(inpt, torch.Tensor) and (
	torch.jit.is_scripting() or not isinstance(inpt, (datapoints.Image, datapoints.Video))
	):
	if old_color_space is None:
	raise RuntimeError(
	"In order to convert the color space of simple tensors, "
	"the `old_color_space=...` parameter needs to be passed."
	)
	return convert_color_space_image_tensor(inpt, old_color_space=old_color_space, new_color_space=color_space)

As long as we can accurately identify the color space from the number of channels, we should either remove the old_color_space parameter completely or at least remove this error and set the value ourselves with

vision/torchvision/prototype/datapoints/_image.py

Line 39 in 035d99f

def _from_tensor_shape(shape: List[int]) -> ColorSpace:

[pmeier]

For context #6736

[pmeier]

We previously agreed that we should have a no-op datapoint that will never be transformed. There was some discussion to use the plain Datapoint class directly or add another thin wrapper subclass as suggested in #6663 (comment)

[NicolasHug]

Closing - we'll keep track of the progress in other places like #7217 (possibly coming back to this PR)