Inaccurate IoU in some cases about rotated_iou HOT 8 OPEN

hi, thank you for the issue!

Yeah, the CUDA result is incorrect in this case. My code is sometimes unstable when it comes to some corner cases, e.g, when some edges and corners exactly overlap. If one rotates one rectangle a little bit, the result becomes correct. For example, with box1 = [4,5,8,10,0.0001] instead of box1 = [4,5,8,10,0]. It might be a numerical issue with float32, but I'm not sure. The NumPy version is probably more stable because it uses float64 by default.

I'm busy with some deadlines now. I would probably come back and try to fix this issue after a few weeks.

TBH, I don't think it's a big problem when you use this code to train neural networks. Because the possibility, that the prediction and the ground truth have exactly overlapping points and edges, is 0 from a statistical perspective. But anyway, it still deserves a fix : )

from rotated_iou.

Hello, Just to let you know that I made a tensorflow version of your algorithm that does not suffer this issue at https://github.com/atuleu/tf-convex-polygon-iou . For the polygon point inclusion, I use the winding number approach, which is a bit more involved, but generalizes to any polygon shape, not just rotated boxes. The unit test gives a correct answer, even for the case above.

from rotated_iou.

hi guys, sorry for the late response. I have been struggling with my own staff in the last few months.

Anyway, I've created a new debug branch and updated my code there.

I've made a lot of changes:

• The CUDA extension is replaced with a native PyTorch implementation. I think they do the same thing. I was just too naive to realize that the CUDA part was unnecessary.
• We don't have to compile anything now, which would probably reduce a lot of issues in the future :-)
• I realized that most problems occurred when two boxes have overlapped corners. So I added a function to check this situation and provide a workaround.

The code looks good to me now and has passed my tests. But I feel the numerical stuff is pretty tricky. I am not sure if all known issues are fixed or if new bugs are introduced (and that's why I didn't push it to the main branch).

So, feel free to check the update in the debug branch and let me know your results.

from rotated_iou.

And I found that if there are some overlapping points(not completely overlapping), the intersection area is wrong.

from rotated_iou.

Thanks for your quick reply! I will try this loss to train my network. By the way, I implemented a differential IoU loss in python before. Although it is accurate, it is too slow because it is not parallel now. I think we could communicate with each other~

from rotated_iou.

Hello, Just to let you know that I made a tensorflow version of your algorithm that does not suffer this issue at https://github.com/atuleu/tf-convex-polygon-iou . For the polygon point inclusion, I use the winding number approach, which is a bit more involved, but generalizes to any polygon shape, not just rotated boxes. The unit test gives a correct answer, even for the case above.

Well done! And thank you for the information! I would try the winding number approach and hope it could solve the issue here.

from rotated_iou.

兄弟，改好了代码上传啊，等了3个多月了，代码还没有更新，这个iou有的地方不对

from rotated_iou.

The enclosing area in this repo is not convex hull area, therefore the results are different from standard package such as Shapely. I think you could use https://github.com/JarvisUSTC/Differential-Rotated-IoU-Loss for calculating more accurate iou.

from rotated_iou.