jpl's profile - activity

I am asking this question because I had a problem with the function findhomography. I used to work under windows with opencv 2.4.8, and I had absolutely no problem with the infdHomography function, I used it in my programs and it worked well. Then I changed computers and now I'm working on ubuntu 14.04 and opencv 2.4.9 and the function findHomography is not recognized by the compiler. I thought something was wrong with the installation of opencv, so I uninstalled it via make uninstall and installed it again, and I had the same problem. I switched back to windows 7, installed opencv 2.4.9 in ms visual studio 2010, and had no problem with it at all. how can I fix the problem under ubuntu, uninstalling and reinstalling opencv is not a solution.

In the articles of both FREAK and BRISK, they are talking about accelerating the matching process with vectorization. And if you download the FREAK code for example from github, you'll find a trace of that in 2 files : freak_demo.cpp and hammingseg.h. How can I adapt them in order to be able to integrate the code of hammingseg.h with opencv code? Have anyone of you done that?

In the field of computer vision and more specifically in the subject of local features detection and description, most of the times the pre-processing phase involves the construction of the scale-space pyramid, like in SIFT, SURF, FREAK... Does the number of octaves of the pyramid has an influence on the quality and the performance of the descriptor or detector?

Does the opencv code of FAST take into consideration the ID3 algorithm? if no, is there an opencv implementation of ID3?

I've been looking into the FREAK descriptor's code lately. The very first part of its algorithm constructs the sampling pattern that'll be used in choosing the pixels that'll serve to calculate the descriptor of the point of interest.
The sampling pattern is based on concentric circles. The rays of the smallest and the biggest circles were define like so:
const float smallR = 2.0/24.0;
const float bigR = 2.0/3.0;
What is the unit of this measurement, I mean 2.0/3.0 refers to 2 thirds of a pixel, of a centimeter (I know cm is not relevant in this context at all)... If it's 2 thirds of a pixel, how do we measure this in an image?

Why are most articles that deal with comparing feature descriptors use the k-nearest neighbor matcher + RANSAC instead of a brute force matcher, especially that the brute force matcher performs all the possible comparisons, so he gives the best possible result. It's true that by doing so, the brute force matcher takes much more time the k-nearest neighbor matcher + RANSAC, but are there any other advantages to using the knn+RANSAC ?

What is the best matcher to use in general? I am not taking into account how much time they both take, I'm just considering the results they give.

Thanks StevenPuttermans for your answer. Speaking of ground truth set, I found this term all lot in articles, what does it mean exactly?

Results of the evaluation of feature detectors depend on the values we give to their parameters, like the threshold , the number of octaves... How can I know which values are best? Some articles say that they use the values that the detectors' authors have used to evaluate them, but what are these values for the FAST, SURF and BRISK?

why is the majority of articles which compare feature descriptors choose to use as a matching strategy K nearest neighbor+ransac instead of bruteforcematcher+a threshold? Are there adavantages of using the first method over the second?

In the documentation there's this signature of the FAST detector : void FASTX(InputArray image, vector<keypoint>& keypoints, int threshold, bool nonmaxSuppression, int type).
type – one of the three neighborhoods as defined in the paper: FastFeatureDetector::TYPE_9_16, FastFeatureDetector::TYPE_7_12, FastFeatureDetector::TYPE_5_8.
but how can you use it?
I mean, all I can do is this:
FastFeatureDetector detector(100,true); for example.
How can I choose the type TYPE_5_8 for example?
writing FastFeatureDetector detector(100,true, TYPE_5_8); doesn't work.
writing detector.detect(imgA,keypointsA,50,true,TYPE_5_8); doesn't work either.