Add api usage log to transforms

[kazhang]

• Call API usage log for every functional transforms.
• Call API usage log for all random transforms (e.g. RandomCrop), even though crop is logged in functional transforms, so that we could distinguish whether the crop is called from a random transform or used directly;
• transforms that are strictly mapped to a functional transforms are skipped. For example: ToTensor
  partially-close: API usage logging within TorchVision #5052
  partially-close: Add _log_api_usage_once() calls on remaining endpoints #4955

cc @vfdev-5 @datumbox

[facebook-github-bot]

💊 CI failures summary and remediations

As of commit 5d46f89 (more details on the Dr. CI page):

---

• 1/1 failures introduced in this PR

---

1 failure not recognized by patterns:

Job	Step	Action
cmake_linux_gpu	Build torchvision C++ distribution and test	🔁 rerun

---

1 job timed out:

• cmake_linux_gpu

---

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.

[kazhang]

Currently we can't log Compose because it breaks this test
test/test_transforms_tensor.py - test_composee.g., which asserts Compose is not scriptable, however, the torchscript type check error suppresses the origin runtime error.

IMO we could skip Compose because the wrapped transforms will be logged anyway. If we do want to log it, we could split _log_api_usage_once into _log_api_usage_once(api: str) and _log_instantiation_usage_once(obj: object) to make torchscript happy. Or we can delete this test, Compose is not scriptable anyway.

[datumbox]

@kazhang @fmassa The policy on whether the call should be added on a constructor VS functional part changes from area to area. On the operators, I believe Francisco opted for adding the call only once, carefully adding it mainly on functional and secondary on constructors (only for those Ops with no functional component). On the other hand Kai proposes to add it to all constructor and functions but excludes those that are too simple (like ToTensor). I think that this change of policy on different parts of the code can be confusing. Shall we align it everywhere? Personally I would favour a simple approach were we add the calls in every constructor and method call we want to log without any exceptions. Thoughts?

[kazhang]

Personally I would favour a simple approach were we add the calls in every constructor and method call we want to log without any exceptions. Thoughts?

Agree with this simple approach, log API is only called once and pretty lightweight. We could further dedup in the downstream if needed.
@fmassa WDYT?

[datumbox]

Thanks @kazhang, overall looks good. Just one comment, let me know what you think.

[datumbox]

LGTM, thanks @kazhang

[github-actions]

Hey @datumbox!

You merged this PR, but no labels were added. The list of valid labels is available at https://github.com/pytorch/vision/blob/main/.github/process_commit.py