FraserT's profile - activity

Look into the function solvePnP which calculates the cameras perspective from given points, so long as you know the model space positions of these points. I assume since they are in the corners of a sheet of paper, you know the real world positions of the triangles?

With 4 points, you could use the P3P flag to solve for 3 points.

The process is very similar to obtaining the camera position relative to an Augmented Reality marker, so looking up tutorials/demo's of that would be a good start.

Thanks for the reply, so if Rt is just a transform from one image to the next, if I wanted to plot the camera's path as above, would it be enough to extract the final column 't' as the new relative position? Or is it in the form, rotate by R, then move along by t?

If so, do I need to extract euler angles from R first?

Sorry for the inundation of questions, I've been stuck on implementing an odometry algorithm for quite a while!

Hi everyone, playing around with how to find the egomotion of a camera, particularly a kinect sensor. One approach I've looked at is the sample packed with opencv, 'rgbdodometry' which sprouts from this paper: https://vision.in.tum.de/_media/spezial/bib/steinbruecker_sturm_cremers_iccv11.pdf I believe.

However, other than that I can find very little documentation on it. It seems to return the projection matrix [R|t] between the camera views?

In an attempt to extract these values I tried:

bool isFound = cv::RGBDOdometry(Rt, oldRt, image0, depthFlt0, mask0, image1, depthFlt1, mask1, cameraMatrix, minDepth, maxDepth, maxDepthDiff, iterCounts, minGradMagnitudes, transformationType );
Mat rot, trans, rX, rY, rZ, rE, K;
Mat P = Rt.rowRange(0,3);
cout << P << endl;
decomposeProjectionMatrix(P, K, rot, trans, rX, rY, rZ, rE);
cout << "Rotated [x,y,z]: " << rE << endl << "Tranformed [x,y,z]: " << trans << endl;

On the hoof that it might work, but I'm pretty sure it doesn't. The camera matrix K that is returned, is nothing like the cameraMatrix I use with the RGBDOdometry function (calibrated before).

I have read the full projection matrix is K[R|t], which would make sense why I am getting an invalid K, if I only had [R|t] to begin with!

Ideally, all I'm looking for now is a rough guess as to how the camera is moving, and I'd probably output that drawing the camera path in a separate window, (ignoring changes in Y).

Is this possible?

I am calculating the fundamental matrix between two successive frames of a kinect, and according to Hartley and Zisserman the matrix should satisfy x'Fx=0.

I wrote up some quick code that I thought might do the job, but it's not working perfectly, which I will detail at the end of this question:

        Mat RansakMask;
        Mat F = findFundamentalMat(good_matches1,good_matches2,8,3.0,0.99,RansakMask);
        cout << "Number of matches: " << RansakMask.size().height << endl;
        int matches[2];
        matches[0]=0;matches[1]=0;
        for (int j = 0; j < (good_matches1.size()); j++)
        {
            if(RansakMask.at<uchar>(j, 0) != 1)continue;
            cv::Mat p1(3,1, CV_64FC1), p2(3,1, CV_64FC1);

            p1.at<double>(0) = good_matches1.at(j).x;
            p1.at<double>(1) = good_matches1.at(j).y;
            p1.at<double>(2) = 1.0;

            p2.at<double>(0) = good_matches2.at(j).x;
            p2.at<double>(1) = good_matches2.at(j).y;
            p2.at<double>(2) = 1.0;

            Mat m = (p1.t()*F*p2);
            int i = (abs(m.at<double>(0))<0.5)?0:1;
            matches[i]++;
        }
        cout << "Number of correct: " << matches[0] << endl << "Number of wrong: " << matches[1] << endl;
        if(matches[1]>matches[0])
        {
            cout << "Fundamental Mat is wrong" << endl;
        }

The basic idea was, out of all the inliers, compute which were accurate (<0.5f), and which weren't. If there are more accurate than wrong, we can proceed assuming F is relatively accurate.

However, when holding the camera still, this seems to work 9 frames out of 10, on the tenth frame usually giving an answer like (2 correct, 198 wrong) whereas every other frame is typically (198 correct, 2 wrong) etc.

When I move the camera, this turns into more of a 50% chance to be wrong. I don't want to have to throw away F every second frame, so I feel I must be missing something with this code.

Any advice would be appreciated. Thanks.