I made a mistake in my previous pull request. For the function stereoRectify(), R and T are transforms from the first camera to the second, rather than the other way around. To ensure that there is no mistake, I propose developers do a simple check using the stereo_match included executable. It goes as follows:

• Create a left image and a right image, say 100 x 100 pixels each, with the right image shifted 10 pixels to the right.
• Create an intrinsics file, say with intrinsics matrix 80 0 50; 0 80 50; 0 0 1 and zero distortion (f=80, cx = cy = 50)
• Create an extrinsics file, which is the transform from first to second camera, with identity rotation, translation of -10 0 0,
• Invoke the shipped stereo_match executable. This will call the stereoRectify() function whose documentation we want to test.

This will result in a correct disparity of 10 pixels.

This is also consistent with the documentation of stereoCalibrate() in the same file, which creates such an R and T. It has the formula:

\f[R_2=RR_1\f]
\f[T_2=RT_1 + T,\f]

This only makes sense if (R1, T1) go from the world to camera1, (R, T) goes from camera 1 to camera 2, and their composition goes from world to camera 2:

[R | T] *[ R1 | T1] = [R2 | T2]

which can be expanded to
R*( R1x + T1 ) + T = R2x + T2

which yields as above: RR1 = R2, RT1 + T = T2

This pullrequest changes