Getting the votes from the Hough transform

[yakir12]

In the Hough transform, the votes give a good indication of how likely a certain pair of r and θ represent a line. But depending on the thickness and straightness of the lines in the image, the Hough transform can return multiple pairs of r and θ that represent lines that are very similar to each (i.e. colinear lines). We can then cluster the r and θ pairs into groups (especially useful when we know how many lines there are in the image), and use the centers of each group to get a mean line. But it would be even better to have the votes per pair of r and θ so that we can weigh the r and θ estimates accordingly when calculating the mean per group (and/or even before, during the clustering).

[timholy]

The Hough transform doesn't require that a line be continuous; take a few pixels out of the middle, and you get almost exactly the same transform. That's actually part of its point, it can identify lines in noisy images. So what does "per line" actually mean?

[yakir12]

I mixed the terminologies, where "lines" should have been "pairs of r and θ". I've now edited my post, and hope it's clearer. My main point was that having access to the votes helps analyzing which pairs of r and θ belong to which line in the image and what their contribution to that line is. This knowledge can help improve the line estimates.

[timholy]

Maybe more generally, I think the current implementation mixes two things: I think there's a strong case to be made that accumulator_matrix is the Hough transform, and that what's currently being returned is the result of some analysis of the transform. Want to take a crack at a better API? Breaking changes are totally fine, we'll just bump the minor version number.

[yakir12]

I totally agree.
I'll give it a shot ASAP.

[yakir12]

So I took a look, and while it should be straight forward to separate between generating the accumulator_matrix and the specific method of detecting line-candidates, I can't find a ρ range. There is a range for the angles, but not for the distances. Is this an implementation detail, and it's simply range(0, step = stepsize, length = numrho + 2), or is it because the distances are different per angle?

It's worth mentioning that the current implementation is pretty smart about avoiding saving a large matrix of useless r and θ pairs. So in that respect it seems like a shame to move away from that efficiency... With that in mind, maybe it would be good to simply add the vote value to each rθ pair, opening up the possibility to the kind of post-analysis I mentioned above. I'll give that a look.