Ask Your Question

paulheckbert's profile - activity

2020-04-15 10:59:36 -0600 received badge  Notable Question (source)
2015-04-20 12:54:26 -0600 received badge  Popular Question (source)
2013-09-30 04:42:19 -0600 received badge  Nice Question (source)
2013-07-22 13:02:05 -0600 commented answer BRISK feature detector giving poor results

I found what looks like a related bug at http://code.opencv.org/issues/2491 so I added my notes & code there.

2013-07-18 02:00:34 -0600 received badge  Student (source)
2013-07-17 18:06:28 -0600 asked a question BRISK feature detector giving poor results

When I try simple tests with OpenCV's BRISK feature detector, I get poor consistency of feature point location and orientation. If I take an image with clear features, and simply translate its pixels (no resampling), I would expect the feature locations and orientations to be translated, but otherwise unchanged, but that's not what I'm finding. Shift-invariant features is part of what the "R" (robust) in the name "BRISK" is supposed to deliver, right?

Below are pictures and source code for a simple test. I created (with Photoshop, and a 15 point Zapf Dingbat font), some nice white features on a black background, in a 200x200 pixel image (image zapf0.png). The features are far from the edges, to eliminate edge effects. You'd expect high contrast, high frequency image details like this to be about the easiest case for a feature detector that you could imagine. I then translated that picture 23 pixels to the left (simulating a stereo pair - also the simplest stereo pair you could imagine -- no noise, no scaling, no rotation, no occluded features..., zapf1.png). RGB pictures with 8 bits per channel.

Then I wrote a little C++ test program that runs BRISK with the default parameter values and visualizes feature point locations and orientations, linked that with OpenCV 2.4.5, and ran it, like so:

brisk_orient zapf0.png zapf0_orient.png; brisk_orient zapf1.png zapf1_orient.png

This program doesn't compute descriptors or do matching; it just does detection, and then visualizes the results. The two generated image files, zapf0_orient.png and zapf1_orient.png:

The results are disappointingly inconsistent. I'd expect these two images to have nearly identical features, except for translation. But if you look at the two squares and the two triangles, only about 2 out of 8 features match, in terms of position and orientation. I tried other parameter values for threshold and octaves and got similarly bad results.

My question: is this an unavoidable weakness of BRISK, a bug in OpenCV's implementation of BRISK, or a result of not using the right parameter settings and inputs to BRISK?

Have others encountered this weakness of BRISK?

thanks -Paul

the two input images:

the C++ source code, brisk_orient.cpp (also available via pastebin)


// read an RGB picture file, run BRISK feature detector on it
// create a picture of the feature points with their orientations, and write it out

#include <iostream>
#include <stdlib.h>

#include <opencv2/core/core.hpp>              // for cv::Mat
#include <opencv2/features2d/features2d.hpp>  // for cv::BRISK
#include <opencv2/highgui/highgui.hpp>        // for cv::imread

static void draw_dot(cv::Mat &pic, float x, float y, int radius, const cv::Vec3b &color) {
  int x0 = floor(x+.5);
  int y0 = floor(y+.5);
  assert(pic.type()==CV_8UC3);
  for (int y=y0-radius; y<=y0+radius; y++) {
    for (int x=x0-radius; x<=x0+radius; x++) {
      if (x>=0 && y>=0 && x<pic.cols && y<pic.rows)
        pic.at<cv::Vec3b>(y, x) = color;
    }
  }
}

static void draw_line_segment(cv::Mat &pic, float ...
(more)