1
0
mirror of https://github.com/opencv/opencv.git synced 2026-07-25 13:23:02 +04:00
Files
opencv/modules/objdetect/misc/java
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  
![before_fix_multilocus](https://github.com/user-attachments/assets/cc812956-c081-4f00-a7e2-78b7427b1235)
![before_fix_zoomed_small](https://github.com/user-attachments/assets/7e6887cb-b09d-47dc-9fcd-03a27b17f310)

- **After fix:** mean error ≈ −0.001 px
![after_fix_multilocus](https://github.com/user-attachments/assets/1c4f8dfa-d0ae-417c-881e-e2a9cbc4b9f1)
![after_fix_zoomed_small](https://github.com/user-attachments/assets/9c325995-fe0b-42f3-bdbb-6754f985e936)

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
..