Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Hi,

ORB is a binary descriptor and for the matching step you could use:

  • FLANN + LSH index, for e.g.: cv::Ptr<cv::DescriptorMatcher> matcher = cv::makePtr<cv::FlannBasedMatcher>(cv::makePtr<cv::flann::LshIndexParams>(12, 20, 2));
  • Brute Force + Hamming distance, for e.g.: cv::Ptr<DescriptorMatcher> matcher = cv::DescriptorMatcher::create("BruteForce-Hamming");

Also, for small database size, the difference in processing time between a brute force approach and the FLANN library is very small (LSH matching very slow), and keep in mind that FLANN means Fast Library for Approximate Nearest Neighbors.

Hi,

ORB is a binary descriptor and for the matching step you could use:

  • FLANN + LSH index, for e.g.: cv::Ptr<cv::DescriptorMatcher> matcher = cv::makePtr<cv::FlannBasedMatcher>(cv::makePtr<cv::flann::LshIndexParams>(12, 20, 2));
  • Brute Force + Hamming distance, for e.g.: cv::Ptr<DescriptorMatcher> matcher = cv::DescriptorMatcher::create("BruteForce-Hamming");

Also, for small database size, the difference in processing time between a brute force approach and the FLANN library is very small (LSH matching very slow), and keep in mind that FLANN means Fast Library for Approximate Nearest Neighbors.

For floating point descriptors (SIFT or SURF for example), the distance between two descriptors is computed using the Euclidean distance:

Euclidean distance

For binary descriptors, the Euclidean distance can be "simplified" with the Hamming distance:

Hamming distance.

On modern CPU architecture, the two operations involved, xor and bits count is normally implemented in such a way that these operations are cheap in term of CPU time.

Hi,

ORB is a binary descriptor and for the matching step you could use:

  • FLANN + LSH index, for e.g.: cv::Ptr<cv::DescriptorMatcher> matcher = cv::makePtr<cv::FlannBasedMatcher>(cv::makePtr<cv::flann::LshIndexParams>(12, 20, 2));
  • Brute Force + Hamming distance, for e.g.: cv::Ptr<DescriptorMatcher> matcher = cv::DescriptorMatcher::create("BruteForce-Hamming");

Also, for small database size, the difference in processing time between a brute force approach and the FLANN library is very small (LSH matching very slow), and keep in mind that FLANN means Fast Library for Approximate Nearest Neighbors.

For floating point descriptors (SIFT or SURF for example), the distance between two descriptors is computed using the Euclidean distance:

Euclidean distance

For binary descriptors, the Euclidean distance can be "simplified" with the Hamming distance:

Hamming distance.

On modern CPU architecture, the two operations involved, xor and bits count is normally implemented in such a way that these operations are cheap in term of CPU time.

This seems to be the way that normHamming is implemented currently in OpenCV 3.0.

Hi,

ORB is a binary descriptor and for the matching step you could use:

  • FLANN + LSH index, index (doc-2.4.11, doc-3.0), for e.g.: cv::Ptr<cv::DescriptorMatcher> matcher = cv::makePtr<cv::FlannBasedMatcher>(cv::makePtr<cv::flann::LshIndexParams>(12, 20, 2));
  • Brute Force + Hamming distance, for e.g.: cv::Ptr<DescriptorMatcher> matcher = cv::DescriptorMatcher::create("BruteForce-Hamming");

Also, for small database size, the difference in processing time between a brute force approach and the FLANN library is very small (LSH matching very slow), and keep in mind that FLANN means Fast Library for Approximate Nearest Neighbors.

For floating point descriptors (SIFT or SURF for example), the distance between two descriptors is computed using the Euclidean distance:

Euclidean distanceEuclidean distance

For binary descriptors, the Euclidean distance can be "simplified" with the Hamming distance:

Hamming distance.Hamming distance

On modern CPU architecture, the two operations involved, xor and bits count is normally implemented in such a way that these operations are cheap in term of CPU time.

This seems to be the way that normHamming is implemented currently in OpenCV 3.0.