fix prototype features and functional transforms after review

[pmeier]

Addresses #5375 and partially #5379.

[facebook-github-bot]

💊 CI failures summary and remediations

As of commit 621bbf7 (more details on the Dr. CI page):

---

• 1/2 failures introduced in this PR
• 1/2 broken upstream at merge base 1d748ae since Feb 04

---

🕵️ 1 new failure recognized by patterns

The following CI failures do not appear to be due to upstream breakages:

unittest_prototype (1/1)

Step: "Run tests" (full log | diagnosis details | 🔁 rerun)

�[31m============================== �[31m�[1m5 ...0.26s�[0m�[31m ===============================�[0m

    raise TypeError(f"{cls} is not a generic class")
TypeError: <class 'torch.utils.data.datapipes.iter.grouping.ShardingFilterIterDataPipe'> is not a generic class
------ generated xml file: /home/circleci/project/test-results/junit.xml -------
=========================== short test summary info ============================
ERROR test/test_prototype_builtin_datasets.py - TypeError: <class 'torch.util...
ERROR test/test_prototype_datasets_api.py - TypeError: <class 'torch.utils.da...
ERROR test/test_prototype_datasets_utils.py - TypeError: <class 'torch.utils....
ERROR test/test_prototype_models.py - TypeError: <class 'torch.utils.data.dat...
ERROR test/test_prototype_transforms_functional.py - TypeError: <class 'torch...
!!!!!!!!!!!!!!!!!!! Interrupted: 5 errors during collection !!!!!!!!!!!!!!!!!!!!
�[31m============================== �[31m�[1m5 errors�[0m�[31m in 0.26s�[0m�[31m ===============================�[0m


Exited with code exit status 2

---

🚧 1 ongoing upstream failure:

These were probably caused by upstream breakages that are not fixed yet.

• binary_win_wheel_py3.9_cu115 since Feb 04 (22f8dc4)
  • 🔁 rerun

---

This comment was automatically generated by Dr. CI (expand for details).

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

[NicolasHug]

[datumbox]

LGTM, thanks for cleaning up the stale code.

Only 1 question below:

[datumbox]

Should we be importing _F from functional or from functional_tensor?

[pmeier]

Somehow my comment got swallowed. @vfdev-5 asked me to do the exact opposite in #5295 (comment). I don't have any preference over one or the other. Is there a difference if we ever only use the them with tensors?

[datumbox]

Lol. That's what happens we you get too many cooks in one kitchen 😄 Let's not block this, feel free to merge and address later.

@vfdev-5 The new API doesn't support PIL and thus the Tensor API in the kernel we want (we also avoid redirections). Perhaps I'm missing something?

[pmeier]

As discussed offline, we can use functional_tensor here to avoid the extra redirection.

[pmeier]

After looking into this, I think we should stick with transforms.functional:

• The signature is not necessarily the same. For example functional.resize takes
  

  vision/torchvision/transforms/functional.py

  Line 370 in dad6e6a

  interpolation: InterpolationMode = InterpolationMode.BILINEAR,

  while functional_tensor.resize takes

  vision/torchvision/transforms/functional_tensor.py

  Line 489 in dad6e6a

  interpolation: str = "bilinear",

• Composite transforms such as functional.resized_crop have no equivalence in functional_tensor, since the primitives in functional already handle the dispatch

  vision/torchvision/transforms/functional.py

  Lines 594 to 598 in dad6e6a

  	if not torch.jit.is_scripting() and not torch.jit.is_tracing():
  	_log_api_usage_once(resized_crop)
  	img = crop(img, top, left, height, width)
  	img = resize(img, size, interpolation)
  	return img

• If the transform has only a tensor implementation, for example normalize and erase, the implementation lives in functional rather than functional_tensor

  vision/torchvision/transforms/functional.py

  Line 1258 in dad6e6a

  def erase(img: Tensor, i: int, j: int, h: int, w: int, v: Tensor, inplace: bool = False) -> Tensor:

  
  

  vision/torchvision/transforms/functional.py

  Line 320 in dad6e6a

  def normalize(tensor: Tensor, mean: List[float], std: List[float], inplace: bool = False) -> Tensor:

[datumbox]

Sounds good. As discussed offline, we should later fixe all these issues listed above, so that we can remove this intermediate layer.