Yolov3: build_targets function

[okanlv]

Can you explain why have you used the following constants? I have inspected a few different yolov3 implementation but none had a similar operation.

https://github.com/ultralytics/yolov3/blob/a284fc921db7b87710651238e5e0951c08c59ff1/utils/utils.py#L183

[glenn-jocher]

Ah yes. I did not comment this area sufficiently, I will do a commit to better explain this. This section assigns the closest grid point gi, gj, and anchor a to each target, to ensure that each grid-anchor point is only assigned to one target.

My first technique to do this was to select unique rows from the n x 3 [gi, gj, a] matrix using:

u = torch.cat((gi, gj, a), 0).view(3, -1).numpy()
_, first_unique_slow = np.unique(u[:, iou_order], axis=1, return_index=True)  # first unique indices

but during profiling I found np.unique was slow in selecting unique _rows_, so I merged the 3 columns into a single column by the dot product of a random 1 x 3 vector (the 3 random constants you see here). This produced much faster np.unique results.

u = gi.float() * 0.4361538773074043 + gj.float() * 0.28012496588736746 + a.float() * 0.6627147212460307
_, first_unique = np.unique(u[iou_order], return_index=True)  # first unique indices

I tested the two methods for accuracy using this line, and found differences extremely rare... but wait these are both sorted, and the output used later on is not sorted. Ok I will look into this some more to see the effect of the sorting.

print(((np.sort(first_unique_slow) - np.sort(first_unique)) ** 2).sum())

[glenn-jocher]

Yes I've confirmed there is is a bug here. Thank you very much for spotting this! So numpy returns _sorted_ unique indices by default, whereas I assumed they retained the original order. There exists an open numpy issue on the topic:
https://github.com/numpy/numpy/issues/8621

I've corrected this by reverting to the unique _row_ method (first example above), which does appear to retain the original order. Commit is 6116acb8c20ba523fe54111341032c6aec94ead3.

[okanlv]

Thank you.

[Bilal-Yousaf]

@glenn-jocher Could you please explain how this will affect results because it seems like results will be the same whichever method we use.

[glenn-jocher]

@Bilal-Yousaf Ultralytics has open-sourced YOLOv5 at https://github.com/ultralytics/yolov5, featuring faster, lighter and more accurate object detection. YOLOv5 is recommended for all new projects.

** GPU Speed measures end-to-end time per image averaged over 5000 COCO val2017 images using a V100 GPU with batch size 32, and includes image preprocessing, PyTorch FP16 inference, postprocessing and NMS. EfficientDet data from google/automl at batch size 8.

• August 13, 2020: v3.0 release: nn.Hardswish() activations, data autodownload, native AMP.
• July 23, 2020: v2.0 release: improved model definition, training and mAP.
• June 22, 2020: PANet updates: new heads, reduced parameters, improved speed and mAP 364fcfd.
• June 19, 2020: FP16 as new default for smaller checkpoints and faster inference d4c6674.
• June 9, 2020: CSP updates: improved speed, size, and accuracy (credit to @WongKinYiu for CSP).
• May 27, 2020: Public release. YOLOv5 models are SOTA among all known YOLO implementations.
• April 1, 2020: Start development of future compound-scaled YOLOv3/YOLOv4-based PyTorch models.

Pretrained Checkpoints

| Model | AP^val | AP^test | AP₅₀ | Speed_GPU | FPS_GPU || params | FLOPS |
|---------- |------ |------ |------ | -------- | ------| ------ |------ | :------: |
| YOLOv5s | 37.0 | 37.0 | 56.2 | 2.4ms | 416 || 7.5M | 13.2B
| YOLOv5m | 44.3 | 44.3 | 63.2 | 3.4ms | 294 || 21.8M | 39.4B
| YOLOv5l | 47.7 | 47.7 | 66.5 | 4.4ms | 227 || 47.8M | 88.1B
| YOLOv5x | 49.2 | 49.2 | 67.7 | 6.9ms | 145 || 89.0M | 166.4B
| | | | | | || |
| YOLOv5x + TTA|50.8| 50.8 | 68.9 | 25.5ms | 39 || 89.0M | 354.3B
| | | | | | || |
| YOLOv3-SPP | 45.6 | 45.5 | 65.2 | 4.5ms | 222 || 63.0M | 118.0B

* AP^test denotes COCO test-dev2017 server results, all other AP results in the table denote val2017 accuracy.
* All AP numbers are for single-model single-scale without ensemble or test-time augmentation. Reproduce by python test.py --data coco.yaml --img 640 --conf 0.001
* Speed_GPU measures end-to-end time per image averaged over 5000 COCO val2017 images using a GCP n1-standard-16 instance with one V100 GPU, and includes image preprocessing, PyTorch FP16 image inference at --batch-size 32 --img-size 640, postprocessing and NMS. Average NMS time included in this chart is 1-2ms/img. Reproduce by python test.py --data coco.yaml --img 640 --conf 0.1
* All checkpoints are trained to 300 epochs with default settings and hyperparameters (no autoaugmentation).
** Test Time Augmentation (TTA) runs at 3 image sizes. Reproduce by python test.py --data coco.yaml --img 832 --augment

For more information and to get started with YOLOv5 please visit https://github.com/ultralytics/yolov5. Thank you!

[Bilal-Yousaf]

@glenn-jocher Could you please explain how this will affect results because it seems like results will be the same whichever method we use.
Thank You for sharing YoloV5.
Could you please point out how np.unique returning sorted output will affect results? I think this is handled properly?