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) (more) |