2 Commits

Author	SHA1	Message	Date
Siddharth Panditrao	0c613de006	Merge pull request #28380 from WalkingDevFlag:fix/charuco-detector-offset-25539 ... Fix ~0.5px systematic offset in CharucoDetector subpixel refinement #28380 Resolves #25539 ### Problem `CharucoDetector::detectBoard` produces Charuco corner coordinates that are consistently offset by approximately **+0.5 pixels** compared to `findChessboardCorners + cornerSubPix`. This offset is systematic (mean ≈ −0.5 px when comparing legacy − Charuco) and reproducible across images. Visual inspection also shows that the legacy chessboard detector aligns better with the actual corner locations. ### Root cause In `charuco_detector.cpp`, the points passed to `cornerSubPix` are manually shifted by `-Point2f(0.5f, 0.5f)` before refinement and then shifted back by `+Point2f(0.5f, 0.5f)` after refinement. However, `cornerSubPix` refines corners in **absolute image coordinates** and converges to the true saddle point based on image gradients. Shifting the initial guess does not affect the converged result as long as the true corner lies within the refinement window. The additional `+0.5` shift applied after refinement therefore introduces a constant bias, resulting in: ``` P_out = P_true + 0.5 ``` ### Solution Remove the manual `±0.5` coordinate shifts around the `cornerSubPix` call and let the refined result be returned directly. ### Test updates Updated expected corner values in the following tests: - `testBoardSubpixelCoords` - `testSeveralBoardsWithCustomIds` The previous expected values (e.g. `200`, `250`, `300`) were only correct due to the +0.5px bias introduced by the bug. `generateImage` creates checkerboard squares of exactly **50 pixels**, which places true corner locations on **pixel boundaries** rather than pixel centers. As a result, the correct subpixel coordinates are: ``` 199.5, 249.5, 299.5 ``` instead of the previously expected integer values. After updating the expected values, all **30 Charuco-related tests pass** with the fix applied. ### Verification I verified the fix using a Python reproducer that compares `CharucoDetector` output against `findChessboardCorners + cornerSubPix`: - **Before fix:** mean error ≈ −0.501 px   - **After fix:** mean error ≈ −0.001 px   After the change, the Charuco detector output aligns with the legacy chessboard detector both numerically and visually. ### Notes This change only affects the post-refinement coordinate handling and does not alter detection logic, refinement parameters, or performance. See details at https://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	2026-01-28 14:31:54 +03:00
Alexander Panov	e2621f128e	Merge pull request #25378 from AleksandrPanov:move_charuco_tutorial ... Move Charuco/Calib tutorials and samples to main repo #25378 Merge with https://github.com/opencv/opencv_contrib/pull/3708 Move Charuco/Calib tutorials and samples to main repo: - [x] update/fix charuco_detection.markdown and samples - [x] update/fix charuco_diamond_detection.markdown and samples - [x] update/fix aruco_calibration.markdown and samples - [x] update/fix aruco_faq.markdown - [x] move tutorials, samples and tests to main repo - [x] remove old tutorials, samples and tests from contrib ### Pull Request Readiness Checklist See details at https://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. - [ ] The feature is well documented and sample code can be built with the project CMake	2024-04-16 12:14:33 +03:00