Emmanuel's profile - activity

Merci Mathieu :-)

Sorry, I'm not sure of my memory here... but as far as I remember, BRISK does not do any cross-ring diferences (unlike FREAK, but FREAK normalizes by the area).

The sigma sets the width of the neighborhood. For such small sizes, integral images are a decent approximation to Gaussian smoothing (and you will learn by experience that many CV research papers implement the same trick and name it Gaussian...). You really should have a look at FREAK's source that is more geared towards what you plan to do.

I'm not sure BRISK is not already doing what you are trying to do.

Here is the algorithmic principle to build a BRISK descriptor:

1. take an image patch (say, 32x32 for example)
2. choose locations inside that patch
3. for each location, compute the sum of the image values (i.e., integrals) in a small neighborhood around it
4. for some pairs of the said locations, compute the difference <integral_1 -="" integral_2=""> and binarize the result by retaining its sign.

This mechanism was first exposed in the BRIEF paper, and I also descrcibe it in a blog post.

Now, the answers to your questions:

1. BRISK performs some smoothing in order to be robust to noise in step 4 above: taking differences of integrals is indeed more robust than differences of pixels.
2. This smoothing is implemented as an integral. Since all neighborhoods have the same size, taking the mean is not required and keeping the integral avoids the need to divide each value.
3. This does naturally explain why a) the smoothed value is higher (no division by the area) and b) integral images are used (= be fast).

If you look at FREAK, you will see an example of a descriptor where the size of the neighborhoods varies and where a normalization by each area is performed.

I'll write the small code and make the PR later this year when I get more time, it does not seem to be urgent yet.

Wow... I don't know for your particular case (sorry). However, the 2.4.3 version may not work with the original FREAK demo from github, because the BruteForceMatcher class is not defined in the same way. So it should be easier for you to try from OpenCV's FREAK version first (both are very close).

Not sure of what's happening in your case because I can't find the documentation for the SiftDescriptorExtractor class. Did you however try with the original SIFT class ? The code to compute the descriptors in your case becomes:

cv::SIFT siftOperator;
cv::Mat descriptorsB;
siftOperator(img1, cv::Mat(), keypointsB, descriptorsB, true);

Isn't the mistake in your atan2 call ? If your vector is PQ, then you should have some Q-P almost everywhere.

Your syntax is incorrect. Since selectPairs() is not a declared as static function, it can only be called by an instance of the class.

So you have write something like this instead:

FREAK myFreak;
myFreak.selectPairs(images, keypoints, 0.7, true);

OK, I figured out myself a small workaround.

According to the code in the cv::PCA, the mean and covariance matrices are public attributes of the class. So I used cv::Mat's ability to read/write to a file, and read/wrote directly to the attributes of my PCA object.

It should do the trick (at least until the attributes get private :-/ ).

Dear all,

I'm trying to save (and subsequently reuse) to a cv::FileStorage a cv::PCAobject after training it.

However, the cv::FileStorageclass does not implement suitable R/W methods for this type, and the cv::PCA class description does provide little insight on how to initialize an object without computing a principal component analysis.

Is what I want to do possible ? And in this case, could someone please point me to the methods that would be useful in my case,?

Thanks in advance.

1. To make sure that you use Qt, you have to pass the option in your cmake call. You can use ccmake to have a visual interface inside your term in rider to check all the settings.

2. These symbols come from the ffmpeg libs. You can install them with e.g. homebrew (among all the methods I have tested to install them it's by far the easiest one). Note however that 2.4.3 introduced a regression for me at this point: highgui is asking at runtime for a specific version of the ffmpeg libs which is not the latest one provided by homebrew.

Hope this helps !

It's actually a little bit more subtle: the pairs used by FREAK were chosen for their matching performance after a scale-sensitive detection of keypoints (the KP detector used is the same as BRISK, i.e. a multi-scale FAST + orientation detection). Hence, FREAK is rotation and scale invariant only up to the sensitivity of this detector and is not per se invariant.