a.francesconi's profile - activity

What functions use Intel's IPP when available? The answer to this question says that "There are a limited set of functio

It could be, but what dll? In the same level of "opencv_core330.dll" there are all the others opencv_*.dll. I tried to put there also the dlls from Intel TBB (located in tbb2017_20170604oss\bin\ia32\vc14), but no luck. About the wrong version... is there a "right" one? As I wrote, I used the latest release of Intel TBB... maybe I must use a different version? I don't see any documentation about that.

Hello, I'm following this guide to compile OpenCV 3.3.0 for Windows 32bit.

In particular, I would like to enable Intel's TBB so I followed the last chapter, step-by-step. Here is the steps I did in details:

• I downloaded the latest release of TBB for Windows here: https://github.com/01org/tbb/releases...
• Extracted it in C:\dev\tbb2017_20170604oss_win folder
• In Cmake, after Configure, my variables are:
  • BUILD_TBB = FALSE
  • TBB_ENV_INCLUDE = C:/dev/tbb2017_20170604oss/include
  • TBB_ENV_LIB = C:/dev/tbb2017_20170604oss/lib/ia32/vc14/tbb.lib
  • TBB_ENV_LIB_DEBUG = C:/dev/tbb2017_20170604oss/lib/ia32/vc14/tbb_debug.lib
  • TBB_VER_FILE = C:/dev/tbb2017_20170604oss/include/tbb/tbb_stddef.h
  • WITH_TBB = TRUE

The Visual Studio project is generated and I can compile everything without problems (using BUILD_ALL). After that, I build the INSTALLER sub-project to populate the "installer" folder with all the compiled files.

I link the new OpenCV distribution to my project. It compiles fine too, but when the project start it throws this error:

The procedure entry point ?default_num_threads@task_scheduler_init@tbb@@SAHXZ could not be located in the dynamic link library [...]\opencv_core330.dll

Did I miss something while configuring/compiling OpenCV? Thanks for the help

Say that an image contains several shapes and the HoughCircles finds N circles in it. Is it possible to calculate a "score" for each found circle? I'm asking because sometimes it detects irregualr shapes that are not actually circles, so it's better to filter them.

I'm trying to port a C# code that uses AForge library into C++, using OpenCV.

I've found these lines:

Matrix3x3 u, v;
Vector3 e;
model.SVD( out u, out e, out v );

How can I "translate" this into OpenCV? I can't understand the right bindings between the arguments of AForge's SVD (u, e, v) and OpenCV's SVD (w, u, vt) methods.

For several months I worked with a toolbox that uses BRISK detector + ORB descriptor + BruteForce matcher in order to get matches from a "particular" pair of images. The difference between the traditional usage of such kind of algorithms is that my image pair are very similar between each other. In fact, they differ for a very little horizontal translation (and a little rotation, too). Like this one:

Now, the combination of BRISK+ORB often produces good results, but there are cases in which the computation returns some matches that are affected by a small error, in terms of distance from the real location of the correspondent point in the second image (lets say, for example, 5 pixels).

In some cases this error could be treated as irrelevant, in other cases it produces a very bad input for the subsequent step. I'm wondering if there is a combination of (fast and lightweight) detector, descriptor and matcher that fits better my needs.

A NOTE: originally, I implemented just BRISK detector + descriptor and a BruteForce matcher and results were better. The problem is that BRISK descriptor is a very memory-consuming algorithm, I cannot implement it on devices with low RAM. This is why I switched to ORB.

If I understand you comment, nope, they aren't ambiguous. For a disparity value of "+5", the object is tretated to be on the front, while for a value of "-5" (negative!) it's behind the zero value. The important fact is that now the disparity can be positive but also negative

Thank you for this, I'll try ORB. Anyway, what's a "small" and a "good" vale for a patternScale? Is 50 too low? About the excessive memory problem on BRISK, it's not a bug but it's caused by the allocation of a huge array of pattern points (it reach over 3.000.000 elements each one containing 3 float variables!). I could hack the source code by myself to see if there is a way to avoid this allocation, but right now I have no time ;)

I was into a similar problem (by the way, why is it called "toe-in"?). What I had to do was to get a disparity map from a stereo pair taken with two "potentially" converging cameras. I say "potentially" because the converging factor was variable from pair to pair.

I had to modify my own stereo matching algorithm from a simple "right-to-left" correspondence search to a "right-to-left & left-to-right" method.

In few words, if your method does that:

for disp = 0 to MAX_DISPARITY
     score = correspondence between left(x ; y) and right(x - disp ; y)
     if score is better than the previous
         disparity(x ; y) = disp

you have to modify it this way

for disp = 0 to MAX_DISPARITY
     score1 = correspondence between left(x ; y) and right(x - disp ; y)
     // move also to the right
     score2 = correspondence between left(x ; y) and right(x + disp ; y) 
     score = max(score1, score1)
     if score is better than the previous
         if score1 > score2
              disparity(x ; y) = +disp 
         else 
              disparity(x ; y) = -disp

In this way, you will save a disparity map where values from -MAX to 0 are referring to the object furthest than the converging point, and 0 to MAX referring to the ones closer to the observer.

The problems of this algorithm are basically two:

1. There are more operations to do
2. You need a robust correspondence metric, because it grows the numer of false positives

I'm into a CV project where I need to extract some matched keypoints between two very similar images. Not a lot, "only" 20-30 for my purposes. So far I used the combination of two (three) algorithms:

1) BRISK to detect keypoints in both images

BRISK briskObj = BRISK(50, 0);
briskObj.detect(img1, keyp1);
briskObj.detect(img2, keyp2);

2) BRISK, again, to compute descriptors

briskObj.compute(img1, keyp1, descr1);
briskObj.compute(img2, keyp2, descr2);

3) BruteForceMatcher to match (then I filter by myself using the distance field)

BFMatcher matcher(NORM_HAMMING, true);
matcher.match(descr1, descr2, matches);
// ..... 
if (thisMatch.distance < 40) {
     filtered.push_back(thisMatch);
}

Result are REALLY good. I must quote BRISK as one of the best detector/descriptors because it produces several "perfect" matches. But it has a limit: its descriptor module is too much memory consuming for my needs (I want to port it on a device with not so much RAM).

For this, I decided to change only the second method with another lighter descriptor: FREAK.

FREAK freakObj = FREAK(true, true, 60);
freakObj.compute(img1, keyp1, descr1);
freakObj.compute(img2, keyp2, descr2);

The problem, now, is that none of the matched keypoints is right. Every match is far from the right position by 10-30 pixels (and this is because I've filtered them, otherwise it would be worse). I tried changing its parameters, like testing patternScale from 30 to 80, normalization booleans or my own filtering method. All of my matches are wrong...

So, how can I reach the performances of the BRISK descriptor with FREAK? I really need it because of its lightness

I'm wondering if it's reasonable to align stereo pairs using a single camera, like a webcam or better a cell phone. To do so, I will take two picture of the same scene, but moving the camera "a bit" to the right when taking the second image.

Which set of functions should I use under OpenCV to calibrate my single camera and rectify each pair?

Should I use stereoCalibrate with each pair as input, or it won't work cause I wasn't using an ordinary stereo cam?