1 | initial version |
Not quite. First, rotation matrices don't work that way, and second, coordinate systems.
There is more information on rotation matrices HERE, but to start there are three things you need to know.
Bearing number 3 in mind, if you combine the two rotation matrices together directly, you would be transforming from world to camera1, then from world to camera2. This is wrong because after the first, the point isn't a world point any more.
You pick one of the cameras to be the origin (use camera1) and change the rotation and translation of the other to be the camera relative to the world. If you want to really understand what's going on, you should derive this for yourself, but that's always easier if you know what you're going for, so here's code to reverse the rotation and translation vector and get the transformation from camera to world.
Rodrigues(rvec, cameraRotation); //3x1 to 3x3
cameraRotation = cameraRotation.t(); //Invert the rotation matrix
cameraTranslation = (-cameraRotation * tvec); //Appropriately transform the translation vector
So, now you have camera2->world and world->camera1. You combine them by multiplying the rotation matrices (I always forget which order, I think it's rotMat1*rotMat2, but try both to be sure). And combing translation is as easy as transVec1+transVec2.
Now you have an R and T from camera2->camera1, and you have what you need.
Or almost. Where did you get your original rvec and tvecs? If you used camera calibration, did you use a static scene? Was the calibration target in exactly the same physical location for both calculations? Since world points are defined as places on the calibration target, if you moved the target, you moved your world points, and you actually have two, unknown world frames. If necessary, take a new picture of an unmoving scene and use solvePnP to get your rvecs and tvecs.