Sub-optimal results by overlap resolver

[thorstenwagner]

@hinerm

I've played around with some other image data and found some strange results. The original image is:
http://fiji.sc/_images/f/f5/CNT_Ridge_Detection_Original.png

I've used the following settings...
Sigma = 1.5, Lower Threshold = 1.3, Higher Threshold = 7
... and get some 'strange' results:

[hinerm]

thanks for playing with this @thorstenwagner!

So, for the bottom image (lines 133, 132) I think it is fairly arbitrary - from a slope/straightness perspective - which "top" end to pair with that "bottom" end pointing to the left.

My current implementation does a greedy search for maximizing straightness. We could improve the results by trying to find a globally optimal configuration for all pairings about an overlap point, which would improve the algorithm in some cases.

However, the primary assumption of a slope/straightness heuristic (that intersection is more likely than overlapping, simultaneous curves) falls apart the larger the length of overlap - especially when the length of overlap is large relative to the overall line length.

So I would say the 132, 133 line set is not an ideal candidate for the slope heuristic and would be better served by SVM, manual inspection, etc..

(and I will try to make this clear in my wiki contribution)

[hinerm]

Same explanation for the above two images. The initial segmentation is a poor starting point for a slope/straightness-based heuristic.

I played with the parameters a bit:

which looks opposite of what you might expect at first, but I think it's working exact as advertised. The algorithm likely paired the top two sections together because they were processed first (greedy) and they best preserve overall straightness. Then the bottom two sections are simply left over and paired together.

My goal for the wiki is to contrast these examples with images like this one:

to show when slope overlap detection is, and is not, useful.

[hinerm]

There are, of course, probably still bugs! So let me know if you find more odd behavior 😄

Thanks again!

[hinerm]

Here is something that should never happen. The wrong ends were merged together.

[thorstenwagner]

@hinerm Yes, but it seems only happen sometimes... If check / uncheck preview multiple times it only occurs sometimes...

[hinerm]

I will investigate!

[hinerm]

So the problem is - unsurprisingly - that I took some short cuts in simplifying the assumptions I was making about intersection structure.

I started a branch to work on making the search more robust - by considering all combinations of "enclosed" segments as possible pairings, which then will necessitate global error minimization as well - but I don't really have the time to finish it right now.

It's fun to work on so I hope to get back to it eventually. Anyone else is welcome to continue its refinement as well. And @thorstenwagner if there's anything you consider a showstopper bug I will try to fix it.