Error in transormation using FindHomography

I have two images (img_1 and img_2) of a plane "A" acquired by the same camera in two consecutive times. Between these two instants the camera performs a little rotation around one of the two axes x, y (considering that the z one points to the plane "A" ...so the transformation between the images is perspective.

My goal is to find a point (previously detected in img_1) in img_2. So i use FindHomography function and than i multiply the coordinates of such a point (setting z=1, normalized as suggested here: findhomography) with the matrix obtained.

The problem i that the new point in img_2 is always shifted a bit in one direction with respect where it should be....

what am i doing wrong? could be something about the scale factor? (take into account that the transformation matrix for translational movement of the camera is computed properly).

My code is the same of this example obviously my code stops at:

             Mat H = findHomography( obj, scene, CV_RANSAC );


..than, in the main function, i simply do:

dstMat = H*srcMat;


where scrMat is the point in img_1 (setting z=1) and dstMat is the point in img_2

edit retag close merge delete

Which method do you use for the homography? Do you make sure that you only use inliers(in case its ransac) when transforming the coordinates?

Maybe post a small snippet of the important code

( 2013-08-16 09:26:13 -0500 )edit

i've just updated the question... it's a systematic error...it doesn't depend on the presence of outliers i suppose

( 2013-08-16 09:55:11 -0500 )edit

How much is it it actually shifted and this is true for all Points?

( 2013-08-16 10:50:59 -0500 )edit

yes, for all the points and the shift is about 10/20 pixel.. if i repeat the operation lot of times the result is the same as if the z coordinate of these point was different from the plane "A"'s one and so the perspective transformation is wrong. might be?

( 2013-08-16 10:57:00 -0500 )edit

The important thing is that your points are coplanar, so that findHomography works correctly, but I guess this is given, since you are talking about a simple plane.

What kind of detector/descriptor and matching do you use?

( 2013-08-16 11:19:15 -0500 )edit

yes, confirm that are absolutely coplanar. I'm using Sift..actually works very well in my case because the plane represents the aerial image of a city (full of corners)

( 2013-08-16 11:26:17 -0500 )edit

correction...actually i remove the part from --Quick calculation of max and min distance between keypoints....that because my problem is a 3d problem..and so that type of selection doesn't work..in fact i have a lot of wrong matchings but i think that the RANSAC method does its work... did i do right?

( 2013-08-16 13:15:42 -0500 )edit

Actually, you should already preeliminate lots of outliers. Ransac is good to a certain extent. Since you are using SIFT, I can recommend to try a ratio check for the matches. This is also what Lowe proposed in his papers about SIFT. Here are some examples including the ratiocheck: http://itlab-computer-vision.googlecode.com/svn-history/r62/trunk/Belousov/filter.h

This could improve your result. Btw, your problem is still in 2D, not 3D :P

( 2013-08-16 13:22:21 -0500 )edit

thanks..i'm gonna try.. 2 doubts: 1_the ratio check function takes a vector<vector<DMatch> > , i have a vector<DMatch > instead...?? 2_if the problem was about outliers i should have the same issue for the translational part as well...shouldn't I?

( 2013-08-18 07:41:25 -0500 )edit
1. You need to use knnmatch for the ratio check, so you will need a vector<vector<DMatch>>, since every entry will have 2 matches. 2. Dont know exactly. Maybe its just not noticable.
( 2013-08-18 14:20:31 -0500 )edit

I tried hard..i'm not an expert in programming stuff: may I have a clue about the usage of such a "ratio check function" within the OpenCV's example? ..I really don't know how to acquire a vector <vector <DMatch> > ...thanks

( 2013-08-20 12:58:13 -0500 )edit

ok..i tried it out: this function removes about 50 wrong matchings over about 280.. by the way the result doesn't change..the shifts are still present....:(

( 2013-08-21 04:14:12 -0500 )edit