* Update polynom_solver.cpp
This pull request is in the response to Issue #19526. I have fixed the problem with the cube root calculation of 2*R. The Issue was in the usage of pow function with negative values of R, but if it is calculated for only positive values of R then changing x0 according to the parity of R, the Issue is resolved. Kindly consider it, Thanks!
* add cv::cubeRoot(double)
Co-authored-by: Alexander Alekhin <alexander.a.alekhin@gmail.com>
Fisheye test has been updated to use new enum cv::fisheye::CALIB_ZERO_DISPARITY and included CV_StaticAssert(...) to ensure cv::CALIB_ZERO_DISPARITY == cv::fisheye::CALIB_ZERO_DISPARITY.
- detect case with infinite loop and raise NoConv exception
- handle such exception
- add support for case with missing `blobDetector` (image contains Point2f array of candidates)
- add regression test
- undone rectification for "failed" detections too
- drop redirectError() usage
Added SQPnP algorithm to SolvePnP
* Added sqpnp
* Fixed test case
* Added fix for duplicate point checking and inverse func reuse
* Changes for 3x speedup
Changed norm method (significant speed increase), changed nearest rotation computation to FOAM
* Added symmetric 3x3 inverse and unrolled loops
* Fixed error with SVD
* Fixed error from with indices
Indices were initialized negative. When nullspace is large, points coplanar, and rotation near 0, indices not changed.
* Fixed indexing in prefilter
* Initialised prefilter
* Initialised prefilter with value initialisation
* Added TC to trigger different Mem Allocs in BufferBM
* Optimize cases with only needed conditions
Lets the user choose the maximum number of iterations the robust
estimator runs for, similary to findHomography. This can significantly
improve performance (at a computational cost).
This is a correction of the previously missleading documentation and a warning related to a common calibration failure described in issue 15992
* corrected incorrect description of failed calibration state.
see issue 15992
* calib3d: apply suggestions from code review by catree
Added type check for solvePnPGeneric | Issue: #16049
* Added type check
* Added checks before type fix
* Tests for 16049
* calib3d: update solvePnP regression check (16049)
Add checks for empty operands in Matrix expressions that don't check properly
* Starting to add checks for empty operands in Matrix expressions that
don't check properly.
* Adding checks and delcarations for checker functions
* Fix signatures and add checks for each class of Matrix Expr operation
* Make it catch the right exception
* Don't expose helper functions to public API
* calib3d: use normalized input in solvePnPGeneric()
* calib3d: java regression test for solvePnPGeneric
* calib3d: python regression test for solvePnPGeneric
(1/4) Revert "Correct image borders and principal point computation in cv::stereoRectify"
This reverts commit 93ff1fb2f2.
(2/4) Revert "fix calib3d changes in 6836 plus some others"
This reverts commit fa42a1cfc2.
(3/4) Revert "fix compiler warning"
This reverts commit b3d55489d3.
(4/4) Revert "add test for 6836"
This reverts commit d06b8c4ea9.
Clarify stereoRectify() doc
The function stereoRectify() takes as input a coordinate transform between two cameras. It is ambiguous how it goes. I clarified that it goes from the second camera to the first.
* Doc bugfix
The documentation page StereoBinaryBM and StereoBinarySGBM says that it returns a disparity that is scaled multiplied by 16. This scaling must be undone before calling reprojectImageTo3D, otherwise the results are wrong. The function reprojectImageTo3D() could do this scaling internally, maybe, but at least the documentation must explain that this has to be done.
* calib3d: update reprojectImageTo3D documentation
* calib3d: add StereoBM/StereoSGBM into notes list