[RFC] YOLO v5

[oke-aditya]

🚀 Feature

Implement YOLO v5 from torch.hub.
This library removes such dataset abstraction and aims to provides a clean modular interface to models.

Some key points to note: -

1. YOLO Achieves SOTA using Mosiac transforms as @zhiqwang mentioned.
2. We don't need to define the model/weights/backbones, we can load using torch hub.
3. We should provide an easy to use model definition, a simple train_step, val_step, fit API and a lightning trainer. Datasets, augmentations, transforms are not needed.

Note that none of quickvision models can achieve SOTA, limitations being torchvision's implementations and not using transforms/datasets. But they are faster, easier and flexible to train. Something which torchvision too does.

With this context, we can start adding YOLO v5.

Depedencies: -

1. Avoid opencv-python at all costs. Opencv is not like PIL a library for image reading. It is huge and has lot of subdependencies. Keeping library light will enable us to use PyTorch Docker containers and directly infer using torchserve.

Evaluation mode: -
. We don't need .fuse() .eval()such methods. We only need to load the model fromtorch.hub.
Currently, we do not have inference scripts for any models, but surely in future #2 . So right now let's focus on training.

[zhiqwang]

Hi @oke-aditya , Recently, I refactor ultralytics's yolov5 following the philosophy of torchvision's here. Now the inference part looks similar to torchvision's retinanet. The inference part is done. And I plan to use quickvision's API (train_step, val_step, fit and etc.) to implement the training part.

[zhiqwang]

If we totally use torch.hub to implement ultralytic's in quickvision, it's difficult to obtain the intermediate features.

[oke-aditya]

True, but that reduces codebase significantly to maintain. I would love a custom implementation though, it would need some testing and weights etc.

[oke-aditya]

Just saw your implementation. That's great. Really nice and so complete.

[zhiqwang]

And the difference of the model weights between my implementation and ultralytics's is just some keyname, you can check the model weights converting script here.

[oke-aditya]

That's absoltely fine!.
Just one small doubt. Will using GeneralizedRCNNTransform detoriate the results ?
P.S> I'm not super expert in these models or scratch implementing them.

[zhiqwang]

Just one small doubt. Will using GeneralizedRCNNTransform detoriate the results ?

True, Ultralytics use the letterbox to do this function, and it reply on opencv here, we should refactor this part using something in torch to make it consistently comparing to ultralytics.

And this is the only one difference between ultralytics's and my.

[oke-aditya]

I will try once locally by using torch.hub without opencv dependency and try to produce a training script, which we can use.

There are few problems which I forsee while doing using hub, but I want to verify them once.
Some are these opencv hardbindings and other might be that inference is attached to produce some custom BBoX class which I really don't want in this repo.

[oke-aditya]

Though GeneralizedRCNNTransform worked actually fine while torchvision adopted RetinaNet, there seemed to be no issue that time. I'm not sure how super flexible it is.

[zhiqwang]

I will try once locally by using torch.hub without opencv dependency and try to produce a training script, which we can use.

Hopefully to see your experiment result here.

[oke-aditya]

Sure, I will share a Colab so that we can dig into their implementation.
This will enable us to compare ours as well later !