calibrate.py silent fail?

henry0987

I am attempting to verify whether I can trust the results of calibrate.py on my OAK-D PRO W PoE 97

When I run the calibrate.py with the correct --squareSizeCm parameter, I'm able to get a "successful" calibration result that is flashed onto my camera. This is good.

However, for testing purposes, I purposely gave an incorrect --squareSizeCm parameter (around 3x the correct size). To my surprise, calibrate.py still indicated a low enough reprojection and epipolar error value, and the intrinsic calibration results were flashed onto the camera. How is this possible? Shouldn't the (very) erroneous initial parameter value completely throw off the results? Can I trust that calibrate.py is able to give me a truthful "success" result?

Is calibrate.py somehow able to self-correct the squareSizeCm value? Does anyone know why this might be happening?

Thank you.

henry0987

Follow up. The intrinsics are still able to generate successfully because they are relative measurements and based on pixels (i.e. scale invarient). What does fail is the depth measurement because it is based on the baseline value which is in turn based on the Translation vector. That vector is scaled by the size of the Charuco markers.

Wondering if there is a way to catch this other than putting a simple threshold check in calibration_utils (i.e. if Translation vector is off by X m, reject it)? @jakaskerl

jakaskerl

henry0987 Follow up. The intrinsics are still able to generate successfully because they are relative measurements and based on pixels (i.e. scale invarient). What does fail is the depth measurement because it is based on the baseline value which is in turn based on the Translation vector. That vector is scaled by the size of the Charuco markers.

👍️

henry0987 Wondering if there is a way to catch this other than putting a simple threshold check in calibration_utils (i.e. if Translation vector is off by X m, reject it)?

Good idea, will do.

Thanks
Jaka

henry0987

jakaskerl

Just so I can quickly implement this tolerance threshold myself, do you have an idea of the range of Translation vector values that could reasonably occur?

For example, should I expect "x" translation values for cameraType 0 toCameraSocket 0 to be +- 0.05 around 3.75 cm? And then, I'd reject values if they're outside that range?

Thank you.

jakaskerl

henry0987
I'd give some more wiggle room. Generally, that is fine, but if you were to incorrectly measure the square size, you would not be off by 1% but more like 10%.

Thanks,
Jaka

henry0987

jakaskerl

Fair enough, but a 1% error in square size measurement would result in a 1% error in baseline distance. Measurements are only so precise, and therefore I understand that some error is inevitable.

Is there a specific percentage you think might be reasonable to give as a threshold? 10% seems large, as that corresponds to depth measurements that are 10% off.

jakaskerl

henry0987
I'm saying that we set the threshold to a point where it is clear there has been a user error. Eg. if user specifies the marker size to be 10% off the real size, then extrinsics will differ from the specified x-axis shift (baseline) by quite a lot. It makes it more error prone. Same goes the other way around, if user incorrectly specifies the baseline due to a mistake in measuring, the program should catch that.

Thanks,
Jaka