Bug?: Different results depending on image orientation

[rostrost]

I noticed that the algorithm produces different results on the same image when rotated by 90° or 180°.

Reproducing steps:

• Take an image, e.g. 35.jpg from the examples, execute the algorithm and look at lsimg (ellipseDetectionByArcSupportLSs.m, uncomment line 28).

• Take the same image rotated by 180° (or 90° or -90°), execute the algorithm and look at lsimg.

Expected result: Both lsimg should look the same.

Actual result: the lsimg's differ.

In some of my images, it differs so much that in some orientation, an ellipse is detected, in another orientation not.

See the attached lsimgs for 35.jpg

and here a superposition of the two:

A workaround is to let the algorithm work on the same image in 4 orientations and take the result with maximum number of detected ellipses.

But is there maybe an error somewhere? Shouldn't the algorithm be independent of the orientation of the image?

[shatalinra]

The algorithm is definetely not invariant to rotating (even by 90 degrees) or flipping due to implemented line segment detection algorithm. Look at region_grow function, it explicitly favors adding left top neigbours pixels to a segment. There is also issue with numerical stability of LSD due to repeating summation of cos and sin values. I made my own private implementation of LSD in order to deal with this problems but there are still somewhat different segments under different orientations. And this indeed leads to different results on higher levels. P.S. I do not plan to make my implementation publicly available in any near future but I can share some experience and hints about LSD.

[huntkao]

hi shatalinra,

Great. Could you share the experience you have on this issue? thanks.

[shatalinra]

@huntkao three years have passed and now OpenCV have LSD implementation after solving some license issues (https://github.com/opencv/opencv/blob/4790a3732e725b102f6c27858e7b43d78aee2c3e/modules/imgproc/src/lsd.cpp#L167). I strongly suggest looking at their code as reference since it is much more clean than my old implementation, lol. My ideas for making LSD more independent of image orientation were:

1. Prioritize region growing based on gradient magnitude. This way there is no explicit preference for top left corner. This will have profound effect on results since stronger edges are followed first. But this was fine for my particular application.
2. Cos and sin sum stability could be improved if you notice that we are doing atan2 in one place and then cos and sin on the result later. So, instead you can directly do sums with normalized gradient components to remove additional numerical error. But then there is yet another possibility: don't even normalize gradient at all and sum components as integers. This again biases results towards stronger edges but then you avoid numerical stability issue completely without any performance hit. I think this was pretty much it since ellipse detection level don't care about orientation much.

[huntkao]

So much thanks for quick and nice share.I will try it. Thank you.Best regards,Huntshatalinra @.***> 於 2023年9月14日 下午4:15 寫道： @huntkao three years have passed and now OpenCV have LSD implementation after solving some license issues (https://github.com/opencv/opencv/blob/4790a3732e725b102f6c27858e7b43d78aee2c3e/modules/imgproc/src/lsd.cpp#L167). I strongly suggest looking at their code as reference since it is much more clean than my old implementation, lol. My ideas for making LSD more independent of image orientation were:

Prioritize region growing based on gradient magnitude. This way there is no explicit preference for top left corner. This will have profound effect on results since stronger edges are followed first. But this was fine for my particular application. Cos and sin sum stability could be improved if you notice that we are doing atan2 in one place and then cos and sin on the result later. So, instead you can directly do sums with normalized gradient components to remove additional numerical error. But then there is yet another possibility: don't even normalize gradient at all and sum components as integers. This again biases results towards stronger edges but then you avoid numerical stability issue completely without any performance hit. I think this was pretty much it since ellipse detection level don't care about orientation much.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>