Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork56.4k
Fixing how stdDev in calibration is calculated#22992
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation
asmorkalov commentedDec 20, 2022
Why not 3.4 or 4.x? |
savuor commentedDec 20, 2022
@asmorkalov backport to 4.x:#22996 |
lamm45 commentedDec 20, 2022
Thank you for the invitation! I still think that the existing formula is correct. The proposed formula for sigma2 is only asymptotically correct (that is, when the number of points is huge). As a "proof", the existing formula seems to be equivalent to the equation (1) of this paper:https://arxiv.org/abs/2107.13484 The issue isn't really specific to camera calibration. Here is a general explanation of why the number of parameters needs to be included in the denominator:https://stats.stackexchange.com/a/64495 I find the Cramer-Rao lower bound a bit confusing and unrelated to this discussion. |
savuor commentedDec 21, 2022 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
@lamm45 Thanks for your contribution! Not sure if I've really got that explanation on StackExchange (while I've found another reference to it in the Multiple View Geometry in Computer Vision book, see section 5.1.3 at page 134). Anyway, if we believe in it, then the best solution would be to forbid the calibration when (Maybe this condition is incorrect since each point gives at least 2 equations - one per coordinate - and the prohibition bound should be twice bigger here) And to leave stddevs empty when What do you think? |
vpisarev commentedDec 21, 2022
my memories about this part of statistics are very fuzzy, but if I recall correctly the formula you propose is sort of biased estimate of the standard deviation. I would keep the original formula and, as you suggest, avoided cases when total is less than nparams_nz. |
lamm45 commentedDec 22, 2022
I think you are right, the error estimator should use |
savuor commentedDec 22, 2022 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
I've finally understood that denominator correction. While it's more related to ordinary least squares estimation variance, I also found a more general explanation of it in MVG book (see the reference in the PR description). |
lamm45 commentedDec 22, 2022
I should have been more precise, but when I said error estimator or computation, I meant the estimator or computation for thestandard error. In this context, standard error is essentially the same as stddev, but I prefer the former. |
savuor commentedDec 23, 2022
@asmorkalov Backport to 3.4:#23025 |
alalek left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Need align 3.4 / 4.x and this 5.x PRs to minimize conflicts.
Backport of#22992 to 3.4### Pull Request Readiness ChecklistSee details athttps://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request- [x] I agree to contribute to the project under Apache 2 License.- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV- [x] The PR is proposed to the proper branch- [x] There is a reference to the original bug report and related work- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable Patch to opencv_extra has the same branch name.- [x] The feature is well documented and sample code can be built with the project CMake
savuor commentedJan 24, 2023
savuor commentedJan 30, 2023
Merged through#23189 |
Backport ofopencv#22992 to 3.4### Pull Request Readiness ChecklistSee details athttps://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request- [x] I agree to contribute to the project under Apache 2 License.- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV- [x] The PR is proposed to the proper branch- [x] There is a reference to the original bug report and related work- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable Patch to opencv_extra has the same branch name.- [x] The feature is well documented and sample code can be built with the project CMake
Uh oh!
There was an error while loading.Please reload this page.
Fixes#19803
This PR should fix the standard deviation calculation for calibration procedure.
TODOs:
totalshould contain 2x the number of object points (one per each coordinate)EDIT: the previous stddev calculation motivation is considered to be wrong, we need that denominator correction to make our estimates unbiased. An explanation of it can be found in [MVG].
Also, Cramer-Rao bound has nothing to do with it.
Previous incorrect explanation
The stddevs estimation is based onCramer-Rao bound. While it's not said about the variance of samples, the original code (Camera Calibration Toolbox by Jean-Yves Bouguet) and other available implementations calculate sigma2 based on all object points regardless how many are of them or how many parameters are to optimize.
I invite anyone to discuss that and verify that, especially those who've participated in the original issue discussion:
@Seneral@sanketc001@lamm45@alalek
I also invite@vpisarev and@ivashmak because of their experience in calibration.
Pull Request Readiness Checklist
See details athttps://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
Patch to opencv_extra has the same branch name.