Angle stop at -pi

[cgyx008]

Hi, Thanks for your great work!

I have 2 questions.

1. line 240-242 in rapid.py:

   # calculate iou between truth and reference anchors
   anchor_ious = iou_mask(gt_boxes, norm_anch_00wha, xywha=True,
                      mask_size=64, is_degree=True)

   Can I use regular method instead of mask to calculate iou for training speed? regular method like:

   anchor_ious = torchvision.ops.box_iou(gt_boxes[:, :4], norm_anch_00wha[:, :4])

2. I replaced the dark53 with yolov5-s and encountered a situation where the predicted angle stop at -pi, as shown below. This happens only on little objects, and I think it might be relate to that the bbox of little objects are close to square. Have you ever encountered this situation? What do you suggest I do? Thanks.

[duanzhiihao]

Hi, thank you for your attention.

Can I use regular method instead of mask to calculate iou for training speed? regular method like torchvision.ops.box_iou

I believe using regular IoU will decrease the model accuracy since regular IoU != rotation-aware IoU, which will negatively affect the anchor bbox assignment.

... the bbox of little objects are close to square ...

That's a good point. It may be that the mask resolution in iou_mask is not good enough to represent those tiny objects. I would suggest you try to increase the mask resolution mask_size and see if it helps. https://github.com/duanzhiihao/RAPiD/blob/bc0f2f049ac376536d8de8bf11af12973ccd18e4/models/rapid.py#L242

Have you ever encountered this situation?

Tiny objects are also problematic when we were working on the paper. Not exactly the same as your case, but we found that training on tiny objects make the model tend to predict many false positives (because tiny objects are usually just black dots, so the model learns to detect any black dot as a person). We work around this by simply setting a threshold and removing all objects smaller than the threshold in the training set.

[cgyx008]

Hi, thanks for your reply. But I still have some confusion.

... since regular IoU != rotation-aware IoU, which will negatively affect the anchor bbox assignment.

I found when assigning anchor bbox, the angle of gt boxes and anchor boxes are both 0, so I think here regular IoU == rotation-aware IoU. Am I misunderstanding?

... increase the mask resolution mask_size...

OK! I missed this parameter before and I will try.

For the question of the predicted angle border, you extend the angle range to avoid the predicted angle stopping at pi/2, but after extending range, the predicted angle will stop at -pi (see figure above, the red arrow pointing down will stop at -pi) in theory, right?

[duanzhiihao]

when assigning anchor bbox, the angle of gt boxes and anchor boxes are both 0, so I think here regular IoU == rotation-aware IoU.

Oh yes you are right. I forgot there are two locations where I compute IoU. For the IoU you mentioned (linked below), I believe we can use torchvision.ops.box_iou equivalently, since angles are all zeros anyway. I used iou_mask in the code just because historically we experimented using anchors with angle, but that didn't help, so we reverted back to anchors without angles. https://github.com/duanzhiihao/RAPiD/blob/bc0f2f049ac376536d8de8bf11af12973ccd18e4/models/rapid.py#L241 Anyway, now I agree with you. Sorry for the confusion.

the predicted angle will stop at -pi (see figure above, the red arrow pointing down will stop at -pi) in theory, right?

Yes. I believe this problem exists for any bounded prediction interval. I don't know if it makes sense to unboundedly predict the angle. Maybe the model will learn to predict very large angles? I didn't try it and I'm not sure. All I know is that (-pi, pi) is better than (-pi/2, pi/2) as we showed in the paper.

[cgyx008]

OK! Thank you!