# Emmanuel's profile - activity

 2019-02-19 12:45:34 -0500 received badge ● Notable Question (source) 2016-12-29 02:04:20 -0500 received badge ● Popular Question (source) 2016-02-20 17:16:15 -0500 received badge ● Student (source) 2013-08-26 01:37:36 -0500 commented answer How to read/write a PCA object from/to a cv::FileStorage ? Merci Mathieu :-) 2013-08-23 09:17:19 -0500 commented answer Why do the values returned from Brisk's smoothedIntensity it are very large, much larger than intensity values? 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). 2013-08-23 06:45:22 -0500 commented answer Why do the values returned from Brisk's smoothedIntensity it are very large, much larger than intensity values? 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. 2013-08-23 04:10:54 -0500 answered a question Why do the values returned from Brisk's smoothedIntensity it are very large, much larger than intensity values? 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: take an image patch (say, 32x32 for example) choose locations inside that patch for each location, compute the sum of the image values (i.e., integrals) in a small neighborhood around it for some pairs of the said locations, compute the difference 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: 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. 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. 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. 2013-08-23 03:58:48 -0500 commented answer How to read/write a PCA object from/to a cv::FileStorage ? 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. 2013-05-17 03:59:12 -0500 received badge ● Self-Learner (source) 2013-01-07 14:07:32 -0500 commented question error while compiling FREAK demo 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). 2012-12-30 14:16:31 -0500 answered a question SIFT Feature Descriptor Doesn't Work With ORB Keypoinys 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);  2012-12-28 14:47:44 -0500 commented question Optical Flow Arrow Tips Pointing the Wrong Way Isn't the mistake in your atan2 call ? If your vector is PQ, then you should have some Q-P almost everywhere. 2012-12-27 06:01:47 -0500 received badge ● Editor (source) 2012-12-27 06:01:04 -0500 answered a question FREAK selectPairs Error 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);  2012-12-26 03:51:47 -0500 answered a question How to read/write a PCA object from/to a cv::FileStorage ? 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 :-/ ). 2012-12-04 15:50:43 -0500 asked a question How to read/write a PCA object from/to a cv::FileStorage ? 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. 2012-11-29 05:40:40 -0500 received badge ● Supporter (source) 2012-11-06 04:01:03 -0500 received badge ● Teacher (source) 2012-11-06 02:25:16 -0500 answered a question OpenCV 2.4.3 build on MacOS 10.6.8 fails 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. 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 ! 2012-11-05 12:10:40 -0500 received badge ● Necromancer (source) 2012-11-05 11:26:09 -0500 answered a question Is FREAK scale and rotation invariant? 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.