Fix calibration tutorial docs, decomposeProjectionMatrix, and convertMaps performance claims #29487Fixes#25655, #26791, #27277.
Three doc fixes:
1. Calibration tutorial: rows/cols swapped, fixed np.mgrid consistency
2. decomposeProjectionMatrix: clarified transVect is camera center in homogeneous coordinates
3. convertMaps: replaced overstated 2x speed claim
### Pull Request Readiness Checklist
- [x] I agree to contribute under Apache 2 License
- [x] Not based on GPL/incompatible license
- [x] PR proposed to proper branch (4.x)
- [x] Reference to original bug report and related work
- [ ] Accuracy test, performance test, test data: N/A (doc-only)
- [x] Feature well documented and sample code buildable
doc: modernize Doxygen comments to support for v1.15.0 #28903
This PR addresses several documentation build failures encountered with modern Doxygen versions, particularly v1.15.0 (shipped with Ubuntu 26.04).
- flann module: Updated license headers from /**** to /*M****. This prevents Doxygen from misinterpreting the license text (specifically the unclosed backticks in ``AS IS'') as documentation blocks, which previously caused "Reached end of file" errors.
- core module: Fixed a typo in operations.hpp where a doubled backtick (``) caused parsing to fail.
- tutorials: Fixed a missing backtick in real_time_pose.markdown (around line 108) and corrected typos in the RobustMatcher class name.
- Links: Resolved explicit link request failures in calib3d.hpp by ensuring proper namespace resolution.
These fixes ensure that the documentation can be generated without errors on the latest toolchains.
### 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
- [ ] There is a reference to the original bug report and related work
- [ ] 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
Optimize calibrateCamera with Schur‑complement LM and parallel Jacobian accumulation #28461
## Summary
- Optimized `calibrateCamera` for faster runtime without changing outputs using Schur‑complement LM, Parallel Jacobian accumulation, alongside other optimizations.
- Reduced time complexity from O(n^3) to O(n)
- Add a perf test that uses a 500-image chessboard dataset for performance testing.
## Performance
<img width="1200" height="800" alt="base_vs_fast_results" src="https://github.com/user-attachments/assets/6dafa19f-f9cb-4f7f-ba40-0940373712e8" />
<img width="1200" height="800" alt="fast_vs_ceres_results" src="https://github.com/user-attachments/assets/7157af27-8a2b-4810-8b53-3cc9972a8493" />
<img width="1200" height="800" alt="base_vs_fast_param_deviation" src="https://github.com/user-attachments/assets/fe4f954c-34f9-4b9a-b1b2-46e4c76ce08c" />
[Testing repo
](https://github.com/Ron12777/OpenCV-benchmarking)
## Testing
- All local tests pass
## Related
- [opencv_extra PR with test images](https://github.com/opencv/opencv_extra/pull/1312)
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
- [ ] 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
docs(calib3d): clarify coordinate systems in projectPoints, undistort Points, and fisheye::undistortPoints #28333
This PR improves documentation clarity by explicitly describing:
- Input/output coordinate systems (pixel vs normalized coordinates)
- When to use normalized vs pixel coordinates in undistortPoints output
- Differences between fisheye and standard pinhole camera models
- Coordinate system transformations for better understanding
Changes:
- projectPoints: Added explicit note about input (world coords) and output (pixel coords)
- undistortPoints: Clarified that input is pixel coordinates, and output depends on parameter P (normalized vs pixel)
- fisheye::undistortPoints: Added comprehensive documentation including coordinate systems, when to use fisheye vs standard model, and distortion coefficient differences
These improvements help users avoid ambiguity when using these functions for camera calibration and 3D vision pipelines.
docs: fix spelling errors in documentation and code #28301
- [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
- [ ] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
- [ ] The feature is well documented and sample code can be built with the project CMake
### Description
Fixed multiple spelling errors across documentation, comments, and code:
- 'colummn' → 'column' (cublas.hpp, 3 occurrences)
- 'points_per_colum' → 'points_per_column' (calib3d.hpp, 3 occurrences)
- 'Asignee' → 'Assignee' (sift files, 2 occurrences)
- 'compability' → 'compatibility' (face.hpp, 2 occurrences)
- 'orignal' → 'original' (aruco_detector.cpp)
- 'refrence' → 'reference' (chessboard.cpp)
- 'indeces' → 'indices' (stitching.hpp)
- 'OutputPrecison' → 'OutputPrecision' (test)
- 'tranform' → 'transform' (slice_layer.cpp, 3 occurrences)
Total: 24 fixes across 14 files. Documentation and comment changes only, no functional impact.
[calib3d] Add estimateTranslation2D() #27950
Merge with opencv_extra PR: opencv/opencv_extra#1286
### **Description**
This PR adds a new API, `cv::estimateTranslation2D()`, to the **calib3d** module.
It computes a **pure 2D translation** between two sets of corresponding points using robust methods (`RANSAC` and `LMedS`).
The function mirrors the interface and behavior of `estimateAffine2D()` and `estimateAffinePartial2D()`, but constrains the transformation to translation only.
This model is particularly useful for cases where the motion between images is purely translational, such as:
- Aerial stitching and planar mosaics.
- Image alignment in fixed-camera systems.
- Lightweight pipelines where affine or homography models are unnecessarily complex.
The implementation introduces a new internal class `Translation2DEstimatorCallback` and integrates seamlessly into OpenCV’s existing robust estimation framework (`PointSetRegistrator`).
---
### **Key Features**
- Implements `cv::estimateTranslation2D()` in the `calib3d` module.
- Supports robust methods **RANSAC** and **LMedS**.
- Adds accuracy and performance tests.
- Provides full **C++ and Python bindings**.
- Includes **Doxygen documentation** consistent with OpenCV’s standards.
- Verified correctness across noise, outlier, and datatype variations.
---
### **Testing & Verification**
**Unit Tests** (`modules/calib3d/`)
- **Minimal sample:**
`test1Point` validates that a single correspondence recovers the correct translation under both **RANSAC** and **LMedS** across 500 randomized trials.
- **Robustness to noise and outliers:**
`testNPoints` generates 100 correspondences, injects noise and outliers (≤40% for RANSAC, ≤50% for LMedS), and verifies that:
- Estimated **T** closely matches ground truth (`cvtest::norm(..., NORM_L2)`).
- Inlier mask consistency and correctness are maintained.
- **Datatype conversion:**
`testConversion` checks mixed input datatypes (integer → float) to ensure correct conversion and consistent results.
- **Input immutability:**
`dont_change_inputs` confirms that input arrays remain unchanged after function execution, mirroring affine behavior.
**Performance Tests** (`modules/calib3d/`)
- `EstimateTranslation2DPerf` benchmarks **RANSAC** and **LMedS** using:
- Point counts: 1000
- Confidence levels: 0.95
- Refinement iterations: 10, 0
These tests confirm **numerical stability**, **performance scaling**, and **consistency** across datatypes and noise levels.
---
### 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 (`4.x`)
- [x] There is a clear description, motivation, and validation summary in this PR
- [x] There are accuracy and performance tests in the calib3d module
- [x] The feature is well documented and sample code can be built with CMake
- [x] The feature has Python bindings and verified documentation output
- [x] There is test data or sample code in the opencv_extra repository (if applicable)
- [ ] There is a reference to the original bug report or related issue (if applicable)
In `fisheye::initUndistortRectifyMap` states, that the function 'compensate radial and tangential lens distortion'. But in fact, fisheye camera model in OpenCV does not uses tangential distortion. It uses only radial distortions, with 4 distortion k_1, k_2, k_3, k_4, which all are radial. In the code of the function all of those koeficients indeed are used as radial lens distortion coefficients. Possible reason of that issue is similar documentation of pinhole camera, that as first four coefficients uses 2 radial and 2 tangential lens distortion coefficients - k_1, k_2, p_1, p_2.
Moved pattern generator to apps and rewrote tutorial #27833
### 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
- [ ] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [ ] 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
solvePnPRansac implementation for Fisheye camera model #26669
Related: https://github.com/opencv/opencv/pull/25028
### 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
- [ ] There is a reference to the original bug report and related work
- [ ] 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
Fix handeye #24897
Fixes to the hand-eye calibration methods, from #24871.
The Tsai method is sensitive to poses separated by small rotations, so I filter those out.
The Horaud and Daniilidis methods use quaternions (and dual quaternions), where $q$ and $-q$ represent the same transform.
However, these methods depend on the gripper motion and camera motion having the same sign for the real part.
The fix was simply to multiply the (dual) quaternions by -1 if their real part is negative.
### 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~~ N/A
Fix documentation for findEssentialMat to reflect how it actually works. #25488
Documentation for findEssentialMat() incorrectly states that the method uses the same cameraMatrix for both lists of points even though there are two cameraMatrix and distCoeffs.
Checked the code and it does the right thing i.e. uses cameraMatrix1, distCoeffs1 for points1 and cameraMatrix2, distCoeffs2 for points2.
Updated the documentation for the method to clarify what it does. The code itself is not changed.
calib3d: doc: remove C API link (For 4.x) #25141
Related to #25140 (for 4.x)
### 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
- [ ] 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
solvePnP implementation for Fisheye camera model #25028
Credits to Linfei Pan
Extracted from https://github.com/opencv/opencv/pull/24052
**Warning:** The patch changes Obj-C generator behaviour and adds "fisheye_" prefix for all ObjC functions from namespace.
### 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
- [ ] 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
Co-authored-by: lpanaf <linpan@student.ethz.ch>
Co-authored-by: Vadim Levin <vadim.levin@xperience.ai>
Check Checkerboard Corners #24546
What I did was get you to pull out of findChessboardCorners cornres the whole part that "checks" and sorts the corners of the checkerboard if present.
The main reason for this is that findChessboardCorners is often very slow to find the corners and this depends in that the size the contrast etc of the checkerboards can be very different from each other and writing a function that works on all kinds of images is complicated.
So I find it very useful to have the ability to write your own code to process the image and then have a function that controls or orders the corners.
### 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
- [ ] There is a reference to the original bug report and related work
- [ ] 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
Update USAC #23078
### Pull Request Readiness Checklist
- [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
FAN YUCHEN
Alexander Smorkalov
Kumataro
Vincent Rabaud
Rohan Mistry
Souriya Trinh
Murat Raimbekov
hyndhavamahesh345
HAILOM ASEGEDE
Alexander Smorkalov
Ismail Abou Zeid
Vladyslav Humennyy
Aditya Jha
Gou Minghao
Ola Olsson
catree
Alexander Smorkalov
John Stechschulte
Dmitry Kurtaev
inkredibl
Markus Murschitz
thewoz
Tomoaki Teshima
Maksym Ivashechkin
Alexander Alekhin
Rostislav Vasilikhin
Stefan Spiss
Ed J