Fix function pointer signature mismatches - #30040
Contrib PR: https://github.com/opencv/opencv_contrib/pull/4224
Calling a function through a function pointer with a mismatched signature is undefined behavior in C/C++ and causes Clang Control Flow Integrity to trap with `SIGILL` (`ud1`) at indirect call sites.
This is a follow-up on https://github.com/opencv/opencv/pull/28939
### 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
Remove deprecated CommaInitializer API - #29948
This goes hand in hand with https://github.com/opencv/opencv_contrib/pull/4217
### 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
Rework accuracy test for legacy C-API cvApproxPoly and CV_PerimeterTest - #29547
### 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
**Details:**
This PR restores the deleted C-API `cvApproxPoly` tests (part of #24957).
I used `cv::pointPolygonTest` to make sure every original point is within the allowed `epsilon` distance to the final approximated polygon rather than calculate the distance to the corresponding line.
**Update:**
Restored `CV_PerimeterTest` *TEST(Imgproc_ContourPerimeter, accuracy)*.
Created a parameterized test for open/closed curves with int/float type shapes. I also added a simple 10x10 square test.
Geometry:Test cleanup - #29753
**co-authored by: @varun-jaiswal17**
### geometry test cleanup
### Removed (dead or unbuildable)
- `test_modelest.cpp` (231 lines, removed entirely): includes `_modelest.h` and subclasses `CvModelEstimator2`,
both of which are gone from the tree, so it cannot compile.
- `test_cameras.cpp:11-207` (197 lines removed): a `#if 0` block, never compiled, holding an older
`cvtest::ArrayTest`-based `CV_ProjectPointsTest` built on the removed C API (`CvMat`, `cvProjectPoints2`). A
live class of the same name derived from `cvtest::BaseTest` follows it and covers strictly more: `Rodrigues`
plus five jacobians against the dead block's two.
### Given real assertions
- `Calib3d_FindFundamentalMat.correctMatches` (`test_fundam.cpp:410`): reverting the solvePoly fix gives -nan /
1.79e+308 and it still passed.
### 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.
- [x] The feature is well documented and sample code can be built with the project CMake
geometry: fix strict-aliasing UB in convexHull - #29714Fixes#26952.
### What
`convexHull()` allocated a single `AutoBuffer<Point*>` and obtained a `Point2f**` view of the *same storage* via `reinterpret_cast` to share the sort/`Sklansky_` code between the `CV_32S` and `CV_32F` cases, and unconditionally read the input via `points.ptr<Point>()` regardless of the Mat's actual depth. Both are strict-aliasing violations -- the exact mechanism the issue title describes ("bogus C-cast and illegal assumptions of object layout") -- and are undefined behavior independent of `Point` and `Point2f` happening to be the same size.
### Why this approach
Two prior attempts (#26975, #27020, both by @kallaballa, both open for months before stalling) tried to fix this by rewriting input/output handling around `InputArray::copyTo` and `std::vector`. That cascaded into unrelated scope -- undocumented-input-format questions, new overloaded signatures that broke Java bindings, uncertainty about what the "authoritative spec" for accepted inputs even is -- and neither landed. @asmorkalov's own diagnosis in that thread was narrower: *"the same data is casted as `Point*` and `Point2f*` and used as integer or floating point"* -- i.e. the casting itself, not the input/output handling, is the bug.
This PR makes only that minimal change. `convexHull`'s core is now a function template on the point type (`convexHull_<_Tp,_DotTp>`), so `pointer`/`data0` are always genuinely `Point_<_Tp>*`-typed for whichever branch is active -- no cast is ever needed, because the two instantiations never share storage. `Sklansky_` and `CHullCmpPoints` needed no changes at all; they were already correctly templated -- the UB was only in how the non-template `convexHull()` constructed and reinterpreted the buffers it passed to them. The public signature, input parsing, and output writing are otherwise unchanged, and no other function needed touching (`convexityDefects`/`isContourConvex` already dispatch on depth correctly).
### Testing
- All 55 existing tests covering `convexHull`, the self-intersection index-monotonicity fixup (`!returnPoints`), `minAreaRect`, `minEnclosingTriangle`, and `convexityDefects` pass unchanged -- these call `convexHull` internally, which is exactly what broke under the prior attempts' more invasive rewrites.
- **Performance** (the other thing that sank a prior attempt): my first design (switching the internal representation from a pointer array to an int index array) measured a real, consistent ~10-13% slowdown at n=10000/100000 vs pristine 5.x (A/B via `git stash`, 7-trial medians) -- traced to the extra `index * stride` address computation an index array requires on every dereference that a direct pointer dereference doesn't. Redesigned to keep the *pointer*-array representation (just correctly typed per template instantiation instead of cast), which recovered performance matching baseline within trial-to-trial noise at every size tested. Added `modules/geometry/perf/perf_convhull.cpp` as a permanent regression guard (100/1k/10k/100k points, `CV_32S`/`CV_32F`) -- no such perf test existed before, despite this being exactly the kind of change that regressed performance in prior attempts.
- Full `opencv_test_geometry` suite: no failures attributable to this change (the 3 present are pre-existing, needing `opencv_extra` test data not configured in this scoped build).
### PR 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 code under GPL or another incompatible license.
- [x] The PR is proposed to the proper branch (5.x).
- [x] Accuracy and performance tests included/added (see above).
- [x] No public API/behavior change, so no documentation or sample updates needed.
In 5.0 cv::Mat_<bool>::depth() returns CV_Bool instead of CV_8U, so
boundingRect routed boolean masks into pointSetBoundingRect, which expects
a CV_32S/CV_32F point set and threw. CV_Bool is a 1-byte 0/1 mask type, so
handle it like CV_8U/CV_8S via the byte-wise maskBoundingRect path.
Documentation fixes, Added How to use pre-built opencv doc #29288
closes: https://github.com/opencv/opencv/issues/29263
co-authored by: @kirtijindal14 @Akansha-977
### 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
doc: remove duplicated bib #29298
### 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
Inverted imgproc-geometry dependency and moved more functions to geometry #29230
Fixes: https://github.com/opencv/opencv/issues/20267
Continues: https://github.com/opencv/opencv/pull/29175
OpenCV Contrib: https://github.com/opencv/opencv_contrib/pull/4137
OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1377
Summary:
- LSD returned back to imgproc
- drawing functions moved to imgproc
- undistort image and related perf-pixel functions moved to imgproc
- moments moved to geometry
- estimateXXXtransform moved to geometry
After the patch the geometry module depends on code and Flann and may be used everywhere without potential circular dependencies
### 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
Dedicated pointcloud module #29224
OpenCV contrib: https://github.com/opencv/opencv_contrib/pull/4134
### 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
Homogeneize some calib/3d behavior #29077
- use CV_Check to validate input sizes (thus throwing for invalid inputs)
- return bool to validate a function result
This fixes#22746
### 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.
- [x] The feature is well documented and sample code can be built with the project CMake
Vincent Rabaud
ahmadmasood43
Alessio Roberto Antochi
Prasad Ayush Kumar
CodeCraftsman
Abhishek Gola
Teddy-Yangjiale
Varun Jaiswal
Arnesh Banerjee
Alexander Smorkalov
Kumataro
Alexander Smorkalov