Re: [libcvd-members] FAST corner detection--- RFC

[Edward Rosten]

On Mon, 11 Jun 2007, twd20 wrote:

> I'm a bit concerned about the non max suppression score.  The max
> threshold proposal makes it very sensitive to the exact value of the
> centre pixel.  For a sharp dark corner on a light background it
> essentially finds the darkest centre pixel within the corner region.

That is true. However the max threshold can be used rethresholding or 
locally adaptive thresholding. So, it's only as sensitive as theFAST 
detector.


> It occurred to me that maybe the score should be the (non-integer)
> length of the arc that is above the threshold - non-integer because of
> bilinear interpolation between adjacent ring scores.  This will tend to
> push the maximal score out into the extrema of the corner - which (I
> hope) will tend to be more repeatable at a high level of accuracy???
>
> But I'm open to evidence that max threshold gives better repeatability.

Unknown. I expect that it will have more effect on localisation so the 
differences will be too small for the repeatability dataset.

For any choice, one can think of bad cases, such as having a long but 
faint contguous arc.

[...]


> It might also be nice to rename the parameter in the non-max suppression
> function to be max_corners not nonmax_corners since that's what you get
> back (!).  This will only have the effect of changing the doxygen
> documentation and shouldn't break anything.

OK.

We could provide the following functions:

fast_corner_detect_X

fast_corner_score_Y

nonmax_suppression
nonmax_suppression_with_scores


That way you can choose the detector, the scoring function (or use your 
own) or use nonmax suppression on what ever you want.

Now just getting a bunch of corners requires more lines of code. So I 
propse also providing a two helper functions:

fast_corner_detect_X_nonmax()
fast_corner_detect_X_nonmax_scores()

I will pretty much always use the first one of those.


> Also agree with Georg that you should be able to find out which version
> of the function you're using.  That way when optimising code that needs
> to be fast, we won't have to spend time checking whether a configuration
> error is preventing SCREAMING LORD SIMD from making an appearance.

Yes. However, the place to check should be in the output of the configure 
script.

Try the brand new configure script. :-)

-Ed