AKAZE descriptors slow

[John B]

I've been running THEIA using SIFT features, but I want to switch to AKAZE to avoid the patent issues with SIFT; however, the feature detection using AKAZE is insanely slow (~15 minutes for one image compared to a matter of seconds with SIFT). Is there any reason you know of that might cause that kind of performance? I've never used AKAZE before, but from what I understand it is supposed to be faster than SIFT.

 I was also curious about trying some other descriptors - possibly some OpenCV implementations. Would it be difficult to integrate OpenCV features with your feature matcher? Or would it be easier to use their matching functions and convert to your match interface?

Also - this is great work - thank you for creating it!

John

[Chris Sweeney]

Hi John,

The AKAZE implementation is my own port of the original AKAZE library to use eigen instead of OpenCV. I've found that OpenCV has very bad and inefficient implementations for many of their algorithms, plus it is a huge library so I avoid using it in Theia for practical purposes. It would not be hard to add OpenCV descriptors -- just extend the KeypointDetector and DescriptorExtractor classes to implement OpenCV keypoints/descriptors of interest.

What size images are you running the detectors on? Are you compiling in release mode?

Chris

--
You received this message because you are subscribed to the Google Groups "Theia Vision Library" group.
To unsubscribe from this group and stop receiving emails from it, send an email to theia-vision-lib...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John B]

I was indeed compiling in debug mode. Switching to release gives the speeds that I would expect. Thanks!

John

To unsubscribe from this group and stop receiving emails from it, send an email to theia-vision-library+unsub...@googlegroups.com.

[John B]

Chris,

It appears that you don't use the KeypointDetector class... or am I missing something?

It looks like you just call on the SIFT and AKAZE libraries inside of the DescriptorExtractor in DetectAndExtractDescriptors to do the detection.

So is it strictly necessary to extend a new KeypointDetector?

Thanks,

John

[Chris Sweeney]

In the those particular cases there is a significant speedup gained when using DetectAndExtractDescriptors because the computation for keypoint detection and descriptor extraction can be shared. In general, though, you could use any keypoint class with any descriptor extractor hence the added generality in the class structure. 

To unsubscribe from this group and stop receiving emails from it, send an email to theia-vision-lib...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Theia Vision Library" group.

To unsubscribe from this group and stop receiving emails from it, send an email to theia-vision-lib...@googlegroups.com.

[John B]

Cool. I think I've got that part figured out. I'm playing around with matching between your libAKAZE descriptors and the openCV descriptors ( which I believe is just the FAST-AKAZE implementation) and noticed a few differences. Hoping you can clarify a few..

First, I noticed you have hardcoded the SURF float descriptor as the descriptor defacto in libAKAZE. Is there a reason you chose that one? Would using the MLDB binary descriptor be much worse for SfM purposes? I think I remember seeing something on this thread about getting rid of the binary descriptors - can't remember if that had to do with the matching.

I imagine there might also be some patent issues that would arise from using SURF in a commercial setting...

But just running a side-by-side comparison of libAKAZE and openCV showed the keypoints pretty dang close. The only discrepancy would be the descriptors, which brings me to the next question...

And you may not be the person to ask for this one, but your binary descriptors are 486 bits, which is what Pablo used in his implementation and paper, so I get that. But the OpenCV impl uses 61 bit descriptors as the largest size. Do you have any idea as to why 61?

I'm delving deeper into the various implementations, so I may come across the answer to that one soon.

Thanks again!

John

On Thursday, June 21, 2018 at 6:19:07 AM UTC-6, Chris Sweeney wrote:

In the those particular cases there is a significant speedup gained when using DetectAndExtractDescriptors because the computation for keypoint detection and descriptor extraction can be shared. In general, though, you could use any keypoint class with any descriptor extractor hence the added generality in the class structure. 

On Tue, Jun 19, 2018 at 6:48 PM John B <jrb...@g.cofc.edu> wrote:

Chris,

It appears that you don't use the KeypointDetector class... or am I missing something?

It looks like you just call on the SIFT and AKAZE libraries inside of the DescriptorExtractor in DetectAndExtractDescriptors to do the detection.

So is it strictly necessary to extend a new KeypointDetector?

Thanks,

John

On Sunday, June 10, 2018 at 11:41:16 AM UTC-6, John B wrote:

I was indeed compiling in debug mode. Switching to release gives the speeds that I would expect. Thanks!

John

On Thursday, May 31, 2018 at 9:46:31 AM UTC-6, Chris Sweeney wrote:

Hi John,

The AKAZE implementation is my own port of the original AKAZE library to use eigen instead of OpenCV. I've found that OpenCV has very bad and inefficient implementations for many of their algorithms, plus it is a huge library so I avoid using it in Theia for practical purposes. It would not be hard to add OpenCV descriptors -- just extend the KeypointDetector and DescriptorExtractor classes to implement OpenCV keypoints/descriptors of interest.

What size images are you running the detectors on? Are you compiling in release mode?

Chris

On Tue, May 29, 2018 at 3:22 PM John B <jrb...@g.cofc.edu> wrote:

I've been running THEIA using SIFT features, but I want to switch to AKAZE to avoid the patent issues with SIFT; however, the feature detection using AKAZE is insanely slow (~15 minutes for one image compared to a matter of seconds with SIFT). Is there any reason you know of that might cause that kind of performance? I've never used AKAZE before, but from what I understand it is supposed to be faster than SIFT.

 I was also curious about trying some other descriptors - possibly some OpenCV implementations. Would it be difficult to integrate OpenCV features with your feature matcher? Or would it be easier to use their matching functions and convert to your match interface?

Also - this is great work - thank you for creating it!

John

--
You received this message because you are subscribed to the Google Groups "Theia Vision Library" group.

To unsubscribe from this group and stop receiving emails from it, send an email to theia-vision-library+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Theia Vision Library" group.

To unsubscribe from this group and stop receiving emails from it, send an email to theia-vision-library+unsub...@googlegroups.com.

[Pierre]

Hi,

I can answer for the 61 size factor -> it is to make the descriptor with a size % 8

If you want to encode the akaze descriptor on a series of uchar you can't -> 486/8 -> 60.78 uchar

If you use 61*8 -> you have 488 bits that fits in 61 uchar.

Regards,

Pierre

[John B]

Ah of course! Thank you Pierre.