improve UX for v2 Compose

[pmeier]

The way Compose is currently implemented always passes the input "packed" t the individual transforms. Meaning, if one passes Compose([...])(image, label) individually (on "unpacked"), the transforms inside the Compose receive (image, label), i.e. the individual inputs packed into a tuple.

For our builtin transforms this makes no difference, since we operate on arbitrary input structures anyway. However, this becomes relevant as soon as a user wants to add a custom transform into the same pipeline. Assuming the user doesn't want to bother with our whole protocol and knows the sample structure exactly, they like want to write something like

class MyTransform(nn.Module):
    def forward(self, image, label):
        ...

However, dropping this into a Compose would not work when passing image and label individually, due to the packing behavior described above. Instead the user would have to write

class MyTransform(nn.Module):
    def forward(self, sample):
        image, label = sample
        ...

This is somewhat awkward, since the input of the individual transform no longer conforms to the input of the Compose.

This transform fixes this behavior. This means, if the inputs to the Compose are unpacked, they also have to be unpacked in the signature of the individual transform. Same is true for the other way around: if the input to the Compose is packed, the individual transform also needs to take a packed input.

cc @vfdev-5

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/vision/7758

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• 6-7 hour queue times caused by GPU instances not being available

❌ 8 New Failures

As of commit f8c326e:

NEW FAILURES - The following jobs have failed:

• c-source / linux-job (gh)
• linux (linux.g5.4xlarge.nvidia.gpu, cuda, 11.8) / linux-job (gh)
• unittests-linux (3.11, linux.12xlarge, cpu) / linux-job (gh)
• unittests-linux (3.8, linux.g5.4xlarge.nvidia.gpu, cuda, 11.8) / linux-job (gh)
• unittests-prototype (3.8, linux.g5.4xlarge.nvidia.gpu, cuda, 11.8) / linux-job (gh)
• unittests-windows (3.10, windows.4xlarge, cpu) / windows-job (gh)
• unittests-windows (3.9, windows.4xlarge, cpu) / windows-job (gh)
• windows (windows.g5.4xlarge.nvidia.gpu, cuda, 11.8) / windows-job (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[NicolasHug]

Why not call this transform_class ?

[pmeier]

It would have to be transform_classes, since it is a list of classes. And since we use cls for singular, I'm usually just append an s to it. I'll leave it up to you.

[NicolasHug]

Should we just error in init? I dont know if it's super valuable to special-case this?

[pmeier]

Depends. The old Compose works as a no-op in case you don't put any transforms in. However, this doesn't sound like a valid use case. So I'm ok in putting this into the constructor.

[pmeier]

I went with the error. LMK if you want the no-op behavior back.

[NicolasHug]

LGTM if green, thank you!