1 | initial version |
The question is not new, but it seems that others have the same issue.
Have a look at the detected chessboards in both images with drawChessboardCorners. In some cases the order of the chessboard corners is determined differently in the stereo images (in one case starting from right side and in the other from left side). If that is the case, the reprojection error of stereoCalibrate
is quite high (I had 15, but also much larger values are possible depending on the number of images with wrongly detected chessboard corner pairs). The reason for it is, that the points do not correspond to each other in both images anymore. However, the calibration for a single camera is not affected by that, so the reprojection error of calibrateCamera
can be low at the same time.
By rejecting these wrongly detected chessboard pairs from calibration, I reduced the average reprojection error of stereoCalibrate
to a value of less than 1 (0.7 so far).
Another solution could be the usage of ArUco or ChArUco patterns which should be unambigous in terms of orientation, but I haven't tested that myself.
2 | No.2 Revision |
The question is not new, but it seems that others have the same issue.
Have a look at the detected chessboards in both images with drawChessboardCorners. drawChessboardCorners
. In some cases the order of the chessboard corners is determined differently in the stereo images (in one case starting from right side and in the other from left side). If that is the case, the reprojection error of stereoCalibrate
is quite high (I had 15, but also much larger values are possible depending on the number of images with wrongly detected chessboard corner pairs). The reason for it is, that the points do not correspond to each other in both images anymore. However, the calibration for a single camera is not affected by that, so the reprojection error of calibrateCamera
can be low at the same time.
By rejecting these wrongly detected chessboard pairs from calibration, I reduced the average reprojection error of stereoCalibrate
to a value of less than 1 (0.7 so far).
Another solution could be the usage of ArUco or ChArUco patterns which should be unambigous in terms of orientation, but I haven't tested that myself.
3 | No.3 Revision |
The question is not new, but it seems that others have the same issue.
Have a look at the detected chessboards in both images with drawChessboardCorners
. In some cases the order of the chessboard corners is determined differently in the stereo images (in one case starting from the right side and in the other from the left side). If that is the case, the reprojection error of stereoCalibrate
is quite high (I had 15, but also much larger values are possible depending on the number of images with wrongly detected chessboard corner pairs). The reason for it is, that the points do not correspond to each other in both images anymore. However, the calibration for a single camera is not affected by that, so the reprojection error of calibrateCamera
can be low at the same time.
By rejecting these wrongly detected chessboard pairs from calibration, I reduced the average reprojection error of stereoCalibrate
to a value of less than 1 (0.7 so far).
Another solution could be the usage of ArUco or ChArUco patterns which should be unambigous in terms of orientation, but I haven't tested that myself.
4 | No.4 Revision |
The question is not new, but it seems that others have the same issue.
Have a look at the detected chessboards in both images with drawChessboardCorners
. In some cases the order of the chessboard corners is determined differently in the stereo images (in one case starting from the right side and in the other from the left side). If that is the case, the reprojection error of stereoCalibrate
is quite high (I had 15, but also much larger values are possible depending on the number of images with wrongly detected chessboard corner pairs). The reason for it is, that the points do not correspond to each other in both images anymore. However, the calibration for a single camera is not affected by that, so the reprojection error of calibrateCamera
can be low at the same time.
By rejecting these wrongly detected chessboard pairs from calibration, I reduced the average reprojection error of stereoCalibrate
to a value of less than 1 (0.7 so far).1.
Another solution could be the usage of ArUco or ChArUco patterns which should be unambigous in terms of orientation, but I haven't tested that myself.