[docs] RandomResizeCrop signature quirks

1. Why do we need to have so much precision: 1.333333333333? 1.3 would suffice and be more readable
2. <InterpolationMode.BILINEAR: 'bilinear'>. It’s not clear from this if the enum should be preferred or the constant (and it’s also not copy-pastable in the code). It’s also not clear which type is used for InterpolationMode, especially given that for a long time only PIL.Image.InterpolationMode was supported, hence even new codebases are using the legacy PIL types: https://github.com/facebookresearch/dino/blob/58aabc0/main_dino.py#L420
3. Why does InterpolationMode live in torchvision.transforms.functional whereas the type using it lives in torchvision.transforms? This enum is basic enough to deserve placement in torchvision.transforms directly IMHO.
4. The doc text mentions torchvision.transforms.InterpolationMode, but it’s incorrect since the type currently lives in transforms.functional: https://pytorch.org/vision/master/transforms.html?highlight=randomresizedcrop#torchvision.transforms.functional.InterpolationMode

[vadimkantorov]

I propose to also have strings supported as interpolation mode (as Kornia does)…

[fmassa]

These interpolation modes naming are quite standard across opencv / pil / kornia

Well, each of those libraries have different names / conventions for each method, but both PIL and OpenCV use some sort of enums (and not strings) for representing the mode. From this perspective, using a proper Python enum seems adapted to me. But I would be ok making it support a string as well (which is what TF does for tf.image.resize )

So some clearness / examples would be great - and copy-pasteability, that is the enum type should be fully qualified (despite being verbose)

That sounds ok to me.

Probably also to just be supporting exactly the same interface as F.interpolate does, to not force users have different interoplate mode typing in different parts of pytorch

This is something which is worth further discussion. Now that torchvision transforms support both Tensor and PIL, there is indeed a question on wether we should follow PIL (BC) or lean towards PyTorch.

IMO, the current situation with PyTorch interpolate is a bit messy, with interpolation modes being linear / bilinear / trilinear / etc, while only one single option actually works for a given input shape. I would lean towards not following what PyTorch does wrt that, but instead focus on providing more generic abstractions in PyTorch for interpolating over any arbitrary number of dimensions, which is what I proposed in https://github.com/pytorch/pytorch/issues/10482 and that we are slowly getting there by unifying the CPU implementations of all those methods, see https://github.com/pytorch/pytorch/pull/54500