BRISK doesn't work properly? (Bug #2491)

Added by Davide Mazzini almost 2 years ago. Updated 12 months ago.

Status:Open Start date:2012-10-30
Priority:Normal Due date:
Assignee:Vadim Pisarevsky % Done:


Target version:-
Affected version:branch '2.4' (2.4-dev) Operating System:Any
Difficulty: HW Platform:Any
Pull request:


Hi, I'm building a matlab application to compare descriptors. I've put in the original version of BRISK from the paper site and the OpenCV version.
It seems that on the same images the original version of BRISK finds lots of keypoints and correctly match them while in the opencv version it fails on every image.
I've run the BRISK code without change anything and the code is the same for all the others descriptors, e.g. SIFT it works.
Could be a bug?

P.S. I've put as an attachment images of matches with original BRISK and with opencv version (with and without RANSAC refinement)

brisk_opencv_no_refinement.png (668.5 kB) Davide Mazzini, 2012-10-30 03:32 pm

brisk_opencv_ransac.png (567 kB) Davide Mazzini, 2012-10-30 03:32 pm

brisk_original.png (408 kB) Davide Mazzini, 2012-10-30 03:32 pm

zapf0.png - left input image (4.1 kB) Paul Heckbert, 2013-07-18 10:00 pm

zapf1.png - right input image (4.1 kB) Paul Heckbert, 2013-07-18 10:00 pm

zapf0_orient.png - left annotated image (3.5 kB) Paul Heckbert, 2013-07-18 10:00 pm

zapf1_orient.png - right annotated image (3.5 kB) Paul Heckbert, 2013-07-18 10:00 pm

brisk_orient.cpp - C++ source (3.1 kB) Paul Heckbert, 2013-07-18 10:00 pm

Related issues (Add)


Updated by Cristian Balint over 1 year ago


Noticed that in your test (except original last BRISK one) your keypoint detector doesn't have any scale or orientation, those selected points are plain points. Can please try again using ORB or FAST point detector ? Keypoints should have orientation and scale at least.

By the way what detector you used in your test ? Can give some details ?

Updated by Paul Heckbert about 1 year ago

I reported a problem with BRISK yesterday in the forum ( and the response I got so far recommended that I file a bug report, since the commenter, SR, found that the original BRISK code did not have this bug, while OpenCV's port of BRISK did. SR wrote "Once again, the OpenCV devs have broken the original code when adding it to OpenCV. sigh". The symptoms sound similar to what Davide Mazzini encountered so my problems and his problems could have a common cause.

I'd summarize Davide's results as "poor matching when using BRISK" and my specific test was narrower in scope, and I'd summarize its results as "poor consistency of keypoint detection - position and orientation are not shift-invariant".

My OS: Mac OS 10.8.4, compiler: g++ version 4.2.1.

Here's what I wrote in the forum, nearly verbatim:

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 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

Updated by Paul Heckbert about 1 year ago

Because it appears that OpenCV's BRISK is broken, I suggest that a clear note to that effect be put into a "known issues" list for BRISK 2.4.5+ at

Updated by Clayton Grassick 12 months ago

I can confirm that BRISK is hopelessly broken in 2.4.6, but only the feature detector, not the extractor. The original BRISK code from the author's website works fine, and is already implemented as a proper OpenCV FeatureDetector. Note that the original code for feature detection does not find oriented features, but relies on the extractor instead.

Can a note be added or can BRISK be removed until someone copies the correct code in? It caused days of head-scratching and frustration.

Updated by Anna Kogan 12 months ago

Hello Davide, Paul, Clayton,

Thank you for reporting the issue. If you could solve the problem on your side and "contribution":How_to_contribute it to the library, it would be highly appreciated!

  • HW Platform set to Any
  • Operating System set to Any
  • Affected version set to branch '2.4' (2.4-dev)

Also available in: Atom PDF