Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inaccurate IoU in some cases #39

Open
JarvisUSTC opened this issue Mar 2, 2022 · 8 comments
Open

Inaccurate IoU in some cases #39

JarvisUSTC opened this issue Mar 2, 2022 · 8 comments

Comments

@JarvisUSTC
Copy link

Hi, this repo is very useful for me! But when I test for the accuracy, I find in one case the result of oriented_box_intersection_2d is wrong.

box1 = [4,5,8,10,0]
box2 = [3,4,6,8,0]

The test results in test_box_intersection_2d.py:
CUDA:
[[56. 80.]
[56. 80.]]
[[ 6. 8.]
[ 0. 8.]
[ 0. 0.]
[ 6. 0.]
[ 8. 10.]
[ 6. 8.]
[ 0. 0.]
[ 0. 0.]
[ 0. 0.]]

Numpy:
48.0
[[ 3.6 4.8]
[-2.4 4.8]
[-2.4 -3.2]
[-2.4 -3.2]
[ 3.6 -3.2]]

obviously, the correct result is 48.0

@JarvisUSTC
Copy link
Author

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

@lilanxiao
Copy link
Owner

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 : )

@JarvisUSTC
Copy link
Author

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~

@atuleu
Copy link

atuleu commented Mar 30, 2022

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.

@lilanxiao
Copy link
Owner

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.

@rubbish001
Copy link

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

@JarvisUSTC
Copy link
Author

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.

@lilanxiao
Copy link
Owner

lilanxiao commented Jun 3, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants