Multi-pretrained weight support - FasterRCNN ResNet50

[datumbox]

Resolves #4671

Example usage:

from torchvision.io.image import read_image
from torchvision.utils import draw_bounding_boxes
from torchvision.transforms.functional import to_pil_image
from torchvision import prototype as P


img = read_image("test/assets/encode_jpeg/grace_hopper_517x606.jpg")

# Initialize model
weights = P.models.detection.FasterRCNNResNet50FPNWeights.Coco_RefV1
model = P.models.detection.fasterrcnn_resnet50_fpn(weights=weights)
model.eval()

# Initialize inference transforms
preprocess = weights.transforms()

# Apply inference preprocessing transforms
batch = [preprocess(img)[0]]
prediction = model(batch)[0]

# Use meta to get labels
labels = [weights.meta["categories"][i] for i in prediction["labels"]]
box = draw_bounding_boxes(img, boxes=prediction["boxes"],
                          labels=labels,
                          colors="red",
                          width=4, font_size=30)
im = to_pil_image(box.detach())
im.show()

cc @datumbox @pmeier @bjuncek

[datumbox]

Some clarification comments below:

[datumbox]

Unfortunately I'm forced to copy the whole function just to change the pretrained to weights param. I refactored to minimize copy-pasted code.

[datumbox]

Removed the standalone transform to avoid introducing a new class here.

[datumbox]

Inherit as much as possible. The changes below will be moved on the existing files once we move to torchvision.

[datumbox]

This default value is to align with the old logic, NEVERTHELESS it's not necessary for BC (due to the way I handled the pretrained param below).

Personally I don't like that we have hardcoded an OLD set of weights here. If we set the default value to None and force the user to choose, we will eliminate future BC considerations if these weights become too old and not-optimal.

This can be addressed on a follow up PR.

cc @fmassa

[datumbox]

I'm going to set this to None, happy to review if someone has a strong opinion.

[prabhat00155]

Thanks @datumbox! Few minor comments.

[fmassa]

LGTM, thanks!

[fmassa]

We should probably raise an error / warning if the user modifies the num_classes and passes a weights argument. Otherwise they might silently think that we are doing magic inside

[datumbox]

Sounds good. I'll add this check to resnet as well.

[datumbox]

I thought about this and it's a bit problematic. The num_classes parameter has a default value in all of our model builders. So to see i it was modified, we need to see if the default value was changed which can lead to messy code. An alternative approach could be to throw a warning if the num_classes != len(weights.meta["categories"]) but still overwrite it to make the life of users easier.

Because it's not clear how this should be handled, I'm going to merge the PR to unblock the work but I'm happy to discuss the policy here and update everywhere in a follow up PR.

[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