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

[twd20]

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.

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.

ie for all corners that are known to match between two views we should
choose the non-max function so as to minimise the sum squared image
error in placement.  I don't really care which pixel is chosen so long
as it is likely to be the same one.

Georg's technique of testing against *all* corners - not just maximal
corners might make this unnecessary but it's still not a reason to have
an arbitrary choice.

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.

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.

Cheers

Tom


On Mon, 2007-06-11 at 13:55 +0100, Georg Klein wrote:
> On Fri, 8 Jun 2007, Edward Rosten wrote:
> 
> >
> > After a comment from Georg a while back, I now believe that the "max 
> > threshold for which point is still a corner" is a better way of doing the 
> > corner score.
> >
> > Does anyone ever use FAST corners without nonmax? I think that nonmax 
> > suppression should be the default operation. Is there a good reason to 
> > provide non nonmax functions?
> 
> Yes, I do. I initialise my features on max locations, then run detection 
> on all cornery regions.
> 
> >
> > We have about 1e6 FAST detector functions. Ethan has contributed faster_* 
> > which are the fastest versions and are exact. I now have non SSE versions 
> > which are also exact (not yet in CVS). I'm planning on merging these in to:
> >
> > fast_corner_detect_?
> 
> Sounds cool. In my experience the SSE detection has occasionally been a 
> bit haphazard in the configure script - it'd be nice to have a way of 
> knowing that you are in fact getting the SCREAMING SIMD version if you 
> want it. Currently, the compile brekage if you don't accomplishes that.
> 
> 
> 
> _______________________________________________
> libcvd-members mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/libcvd-members