1
0
mirror of https://github.com/opencv/opencv.git synced 2026-07-27 22:33:03 +04:00

5 Commits

Author SHA1 Message Date
Rafael Muñoz Salinas cc1ab3e3ac Merge pull request #28773 from rmsalinas:imgproc_find_truco_contours
imgproc: add findTRUContours - lock-free parallel contour extraction #28773

Integrates the TRUCO algorithm (Threaded Raster Unrestricted Contour Ownership, @cite TRUCO2026) as a transparent fast path inside `cv::findContours`. No API change is required: existing code automatically benefits when `mode=RETR_LIST` and no hierarchy output is requested.

### How it works

When `mode=RETR_LIST` and the caller does not request hierarchy, `findContours` delegates to the TRUCO parallel engine instead of Suzuki-Abe. All ContourApproximationModes are supported; approximation is applied in parallel after extraction. In all other cases the original Suzuki-Abe path is used unchanged.

### Key design ideas
- Row-strip domain decomposition parallelised via `cv::parallel_for_`
- Start-point ownership rule + speculative downward tracing eliminate tile stitching and synchronisation primitives (lock-free)
- 8-bit state space instead of the 32-bit integer labeling required by Suzuki-Abe, giving higher SIMD throughput and lower memory-bandwidth pressure
- Paged contour buffer (`TRUCOPagedContour`) avoids heap reallocation on the hot tracing path
- SIMD-accelerated row scanning via `cv::v_uint8` intrinsics
- Thread count controlled globally via `cv::setNumThreads()`, consistent with OpenCV conventions

### Output correctness

Significant effort has gone into ensuring the output is identical to the original `findContours` in every respect: same contour set, same ordering, and same approximation results for all methods. A dedicated test suite (`test_contours_truco.cpp`) verifies exact match against Suzuki-Abe across all four `ContourApproximationModes` and thread counts from 1 to 39, using noise images, circles, nested rectangles, and mixed scenes.

### Performance vs. Suzuki-Abe (from submitted paper)
- single-thread: ~1.8–1.9× faster (8-bit SIMD advantage)
- 20 threads: ~14–20× faster on i7-13700H (6P+8E, 20T)
- 20 threads: ~10–12× faster on Xeon Silver 4510 (12C/24T)

### 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
2026-05-14 13:55:39 +03:00
Anshu fe160f3eed Merge pull request #28548 from 0AnshuAditya0:fix-minEnclosingCircle-welzl-28546
imgproc: fix minEnclosingCircle O(n^3) worst case by adding Welzl shuffle #28548

Welzl's algorithm requires random permutation of input points to
achieve expected O(n) time. Without shuffling, sorted inputs such
as those produced by findContours() trigger O(n^3) worst case.

Fix: copy input to std::vector<PT> and apply cv::randShuffle()
before processing. Uses OpenCV's RNG so cv::setRNGSeed() ensures
reproducible behavior.

Original benchmark (5088 contour points, Release, AVX2):
findContours output: 3.93 ms → 0.033 ms (119x speedup)
Random points: 0.051 ms → 0.049 ms (no regression)

Perf test results (this PR, Release, AVX2):
| Input | N | Time |
|-------|---|------|
| Sequential circle points | 10000 | 0.03 ms |
| Sequential circle points | 5000 | 0.01 ms |
| Random points (CV_32F) | 100000 | 1.87 ms |
| Random points (CV_32S) | 100000 | 2.81 ms |

Fixes #28546

### 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
2026-03-04 15:16:07 +03:00
Vitaly Tuzov 78f80c35d2 Performance test for bounding rect estimation 2019-01-18 15:50:21 +03:00
Vitaly Tuzov e991e05b9b Added anonymous namespace to perf_contours 2018-11-27 11:35:40 +03:00
Vitaly Tuzov e9e8bf4b81 Added performance tests for findContours 2018-11-21 19:57:02 +03:00