Compatibility layer between stable datasets and prototype transforms

[pmeier]

This is the proof of concept implementation for #6662. Let's keep the discussion there unless there is need for discussion on a technical issue of the proposal.

cc @vfdev-5 @bjuncek

[pmeier]

dbfac05 is a refactor of the internals. Here are the main points:

• Change the main entry point from the classmethod VisionDatasetDatapointWrapper.from_torchvision_dataset to a standalone function wrap_dataset_for_transforms_v2 (naming TBD). With this we can make the class private and thus users should have no touching points with the internals. On top of that it simplified the implementation quite a bit.
• Drop support for additional parameters of the wrapper to specify the dtypes of the wrapped objects, the bounding box format, and whether we want to keep images as PIL. See
  • Compatibility layer between stable datasets and prototype transforms #6663 (comment)
  • Compatibility layer between stable datasets and prototype transforms #6663 (comment)
  • Compatibility layer between stable datasets and prototype transforms #6663 (comment)
• Simplify the internal machinery. compatibility layer between stable datasets and prototype transforms? #6662 (comment) established that there is no easy way to provide standalone wrappers for the individual datapoints of a sample. Thus, there is no need to keep the bits that try to do so. This addresses Compatibility layer between stable datasets and prototype transforms #6663 (comment) although not as proposed with a standalone class for a task like classification. @NicolasHug PTAL and LMK if my new implementation is simple enough.

[NicolasHug]

Thanks Philip, I haven't looked at the individual wrappers in depth, but the overall design looks great (I appreciate the simplifications!). I left some comments / Qs below

[pmeier]

The latest commits add the following changes:

• Following introduce heuristic for simple tensor handling of transforms v2 #7170, we no longer need special handling for any non-image parts of the samples, since all our datasets fit the heuristic.

• Following remove categories metadata from (OneHot)Label datapoint #7171 (comment) we no longer use the datapoints.Label class. Together with the pass-through for PIL images, this means that this wrapper is a no-op for classification datasets. This also resolves all discussions regarding the categories, since they are no longer present.

• Instead of having a wrapper that takes the dataset as well as the sample as inputs, i.e.

  def wrapper(dataset, sample):
      ...
      return wrapped_sample

  the architecture was changed to a factory pattern:

  def wrapper_factory(dataset):
      def wrapper(sample):
          ...
          return wrapped_sample
  
      return wrapper

  In addition to making the wrapper more "natural", this also enables us to raise on unsupported behavior on wrapping rather than when the first sample is drawn. That should improve UX.

• I've added automated smoke tests to our datasets v1 tests to make sure wrapping and drawing samples doesn't raise anything.

[NicolasHug]

Thanks a lot Philip, LGTM. I just have minor comments (that we discussed offline and are probably already addressed) + one minor Q about wrap_target_by_type.

I'll admit I haven't taken a super deep look to the individual wrappers. We may have to do a bit of manual testing for those later.

[github-actions]

Hey @pmeier!

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