jav_rock's profile - activity

And could also be that every time I call freak-> compute(image, keyp, desc); internally buildpattern() is called? Is it possible to use the same pattern always if the image size doesn't varies, I guess. Maybe by modifying that...

Nice!, thanks, many good ideas, lets see what can I do.

Is it possible to reduce FREAK extraction time below 70ms?

I am using FAST in pyramids for detection and it takes 1ms to detect. FREAK extraction never takes less than 70 ms. I tried to reduce points passed to the algorithm but never gets below that time, so it is not point-dependent. I am just doing one

extractor = new FREAK();

and then call the method, so it is not a constructor problem I guess. Maybe is something that FREAK does always when you call compute and it is slowing down all the process.

Is there any way of calling the extractor in a static way, like with FAST?

In my application The times are more or less like this in the PC:

detection 1ms
extractor with FREAK 80ms
matching 20ms

FREAK is still slower than I expected even if I only create the object once. It doesn't change that much for android as I use native JNI libraries.

I think if you are getting times of 6 seconds for detection you may have a LOT of things wrong. Check all memory leaks, size of of frames you are processing, check that you create objects once (detector, extractor, matcher). Put timers just for the process of freak extraction to see the real time.

For rotated and scale dimages I just achieve good matching results using FREAK when adjusting the patternScale parameter and downsampled the traingin image like this:

pyrDown(training, training);

FREAK extractor(true, true, 40, 4);

extractor.compute( training, keypointsA, descriptorsA );
extractor.compute( img, keypointsB, descriptorsB );

Which is the relation of the patternScale parameter and the size of the training image? Is there a way to tune it for all cases of rotations and scalings?

I have the same problem as you and I am ging to mail the author of the codes to see if I can learn more. I have been playing with different scales of the training image (with cv::pyrDown(source, dest)) and the scaleNormalized parameter. I think it is very sensitive and dependent on the training image, its size and the number of keypoints.

BFMatcher is also the matcher to use with new FREAK descriptor, using NORM_HAMMING as type because it is a binary descriptor.

I came across with this comment in the compute code:

/*
 * Compute the descriptors for a set of keypoints in an image.
 * image        The image.
 * keypoints    The input keypoints. 
 *              Keypoints for which a descriptor cannot be computed are removed.
 * descriptors  Copmputed descriptors. Row i is the descriptor for keypoint i.
 */
CV_WRAP void compute( const Mat& image, CV_OUT CV_IN_OUT vector<KeyPoint>& keypoints, 
                   CV_OUT Mat& descriptors ) const;

Pay attention to the line after keypoints. It says keypoints are removed if no descriptor is found. I think this answer the question of why they are zeroed.

I think that "flagging as duplicate/low quality" is needed as an extra to "flag offensive" in order to call moderators attention. Maybe it is not necessary to copy all the tools from SO as this site is still small, but I am missing this tool right now.

The flag duplicate will make possible to remove questions on the same topic and make it easier the search for users.

As a coment, IMHO, I think that it wouldn't be a good idea to copy the policy of SO regarding theoretical questions or tutorial-like questions with no codes (where they usually close them), as this OpenCV sometimes requires kind of tutorials or suggestions/discussions. OpenCV is not only programing related, is also researching, thats why I think discussions/suggestions should be admited (following the Q&A format, always argumented).

I have been reading information about FREAK descriptor and I understand it is a binary descriptor that claims to be more robust than previous descriptors.

Reading the publication I noticed that they use a scale-space FAST (that works in pyramids with the image scale) detector for evaluation of FREAK. That means that they detect keypoints with FAST and then compute descriptors with FREAK.

QUESTION

I don't understand then which is the aim of the OpenCV function

FREAK::selectPairs(images, keypoint, corrTresh, verbose);

Is this supossed to be a kind of detector for FREAK? Which are the input/output parameters of the function?

SURF is a detector like FAST. FREAK is a descriptor extractor. It has more sense to compare it with SIFT.

Actually, in the paper they say they use FREAK descriptors together with a pyramidal FAST detector that is called AGAST.

So answering your question:

• It is rotation and scale invariant.

• It is supposed to be a more robust descriptor than SIFT. I am going to test it but still don't have results.

There is a cool video that if you pay attention to every step there is no chance to get lost.

The key is to download the TBB package to a folder (in the video is called "dep"), and when you click configure in CMake the route will be NOT FOUND, so you have to set it manually and click configure again. The same for IPP.

I think this video tutorial is what you need, there is no chance to fail.

I have an application using FAST detector and SIFT descriptors. I want to try the new FREAK descriptor.

• Is it enough by replacing SIFT functions by FREAK and keep using FAST detector or do I need to apply major changes?