tobj bug

[Gaondong]

Objectness

Hi:
IN this repo, An anchor is probably matched to not just one Groundtruth in crowd scence, so the [b, a, gj, gi] could repeat and repeat assign in tobj because do not remove the repeat [b, a, gj, gi] in build target.
tobj[b, a, gj, gi] = (1.0 - model.gr) + model.gr * iou.detach().clamp(0).type(tobj.dtype) # iou ratio

[glenn-jocher]

@Gaondong yes that is correct. Duplicate of https://docs.ultralytics.com/yolov5/tutorials/pytorch_hub_model_loading05

[Gaondong]

@Gaondong yes that is correct. Duplicate of ultralytics/yolov5#3605

OK, but I have a question, should we either remove the repeat indices in build_targets or add the repeat indices loss in objectness loss to calculate all matched targets ?

Thanks!

[glenn-jocher]

@Gaondong it's an open question really.

The current implementation is obviously working well, the real question is if there is an alternative implementation that might work better.

cls and box loss apply losses for all anchor-target matches, whereas obj loss operates differently, it currently only applies a single loss if multiple matches are made.

We could write code to treat obj similarly to cls and box, though I don't know what effect that might have (i.e. could lead to higher rate of FPs without lowering the obj hyperparameter gain down), as typically one target will have a high multiplicity (especially in YOLOv5) with perhaps 3-6 anchors matching it.

[glenn-jocher]

@Gaondong but to be clear, the multiple indices are no harm, they are simply assigning multiple positives to the same location, i.e. it's the same as if I write:

i = [0, 0, 0]
x[i] = [1.0, 1.0, 1.0]

the result will just be that x[0] = 1.0

[glenn-jocher]

@XHBrain see above comments also regarding objectness. Alternative idea would be to apply all losses the same way cls and box are treated.

[Gaondong]

@Gaondong but to be clear, the multiple indices are no harm, they are simply assigning multiple positives to the same location, i.e. it's the same as if I write:

i = [0, 0, 0]
x[i] = [1.0, 1.0, 1.0]

the result will just be that x[0] = 1.0

Yes! This repo performance is very impressive.
I know that the iou value assigned to tobj is increasing along with the training process, so it could be a value closed to 1.0, so it could not make effects.
By the way, Is the map@0.5 calculated by test.py in training process equal to the map@0.5 calculated by pycocotools in the same thres and test_image_size ?

Thanks for your reply.

[github-actions]

👋 Hello, this issue has been automatically marked as stale because it has not had recent activity. Please note it will be closed if no further activity occurs.

Access additional YOLOv3 🚀 resources:

• Wiki – https://github.com/ultralytics/yolov3/wiki
• Tutorials – https://github.com/ultralytics/yolov3#tutorials
• Docs – https://docs.ultralytics.com

Access additional Ultralytics ⚡ resources:

• Ultralytics HUB – https://ultralytics.com/pricing
• Vision API – https://ultralytics.com/yolov5
• About Us – https://ultralytics.com/about
• Join Our Team – https://ultralytics.com/work
• Contact Us – https://ultralytics.com/contact

Feel free to inform us of any other issues you discover or feature requests that come to mind in the future. Pull Requests (PRs) are also always welcomed!

Thank you for your contributions to YOLOv3 🚀 and Vision AI ⭐!

[glenn-jocher]

@Gaondong Thank you for the kind words! Regarding your question, the mAP@0.5 calculated by test.py should be very close to the mAP@0.5 calculated by pycocotools given the same IoU threshold and test image size. However, slight differences may occur due to implementation details. It's always a good idea to cross-validate if exact precision is required for your application. Keep up the great work! 🚀