docs(imgproc): clarify cv::moments behavior for degenerate contours #28227
relates to https://github.com/opencv/opencv/issues/28222
Clarifies that for degenerate contours (single point or collinear points),
cv::moments() returns m00 == 0 and centroid is undefined.
Documents common workarounds such as boundingRect center or point averaging.
docs(features2d): document getBlobContours and collectContours in SimpleBlobDetector #28275
Description: This PR adds missing Doxygen documentation for the getBlobContours() method and the collectContours parameter in SimpleBlobDetector. These features were previously undocumented, making the contour collection functionality difficult for users to discover and use correctly.
Changes:
Added a @brief and detailed note for SimpleBlobDetector::Params::collectContours.
Added documentation for SimpleBlobDetector::getBlobContours(), including a @note regarding the required parameter setup.
Testing:
Verified the documentation build locally on macOS using ninja opencv_docs.
Confirmed the generated HTML displays the descriptions and cross-references accurately.
Partially fixes: #25904
Related PR that adds method: https://github.com/opencv/opencv/pull/21942
### 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.
- [x] The feature is well documented and sample code can be built with the project CMake
modified Input/OutputArray methods to handle 'std::vector<T>' or 'std::vector<std::vector<T>>' properly #28242
This is port of #26408 with some further improvements (all switch-by-vector-type statements are consolidated in a single macro)
### 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
G-API: Add support to set workload type dynamically in both OpenVINO and ONNX OVEP #27460
### 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
Include pixel-based confidence in ArUco marker detection #23190
The aim of this pull request is to compute a **pixel-based confidence** of the marker detection. The confidence [0;1] is defined as the percentage of correctly detected pixels, with 1 describing a pixel perfect detection. Currently it is possible to get the normalized Hamming distance between the detected marker and the dictionary ground truth [Dictionary::getDistanceToId()](https://github.com/opencv/opencv/blob/4.x/modules/objdetect/src/aruco/aruco_dictionary.cpp#L114) However, this distance is based on the extracted bits and we lose information in the [majority count step](https://github.com/opencv/opencv/blob/4.x/modules/objdetect/src/aruco/aruco_detector.cpp#L487). For example, even if each cell has 49% incorrect pixels, we still obtain a perfect Hamming distance.
**Implementation tests**: Generate 36 synthetic images containing 4 markers each (with different ids) so a total of 144 markers. Invert a given percentage of pixels in each cell of the marker to simulate uncertain detection. Assuming a perfect detection, define the ground truth uncertainty as the percentage of inverted pixels. The test is passed if `abs(computedConfidece - groundTruthConfidence) < 0.05` where `0.05` accounts for minor detection inaccuracies.
- Performed for both regular and inverted markers
- Included perspective-distorted markers
- Markers in all 4 possible rotations [0, 90, 180, 270]
- Different set of detection params:
- `perspectiveRemovePixelPerCell`
- `perspectiveRemoveIgnoredMarginPerCell`
- `markerBorderBits`
The code properly builds locally and `opencv_test_objdetect` and `opencv_test_core` passed. Please let me know if there are any further modifications needed.
Thanks!
I've also pushed minor unrelated improvement (let me know if you want a separate PR) in the [bit extraction method](https://github.com/opencv/opencv/blob/4.x/modules/objdetect/src/aruco/aruco_detector.cpp#L435). `CV_Assert(perspectiveRemoveIgnoredMarginPerCell <=1)` should be `< 0.5`. Since there are margins on both sides of the cell, the margins must be smaller than half of the cell. When setting `perspectiveRemoveIgnoredMarginPerCell >= 0.5`, `opencv_test_objdetect` fails. Note: 0.499 is ok because `int()` will floor the result, thus `cellMarginPixels = int(cellMarginRate * cellSize)` will be smaller than `cellSize / 2`
### 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
- [ ] 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 PR is proposed to the proper branch
- [x] The feature is well documented and sample code can be built with the project CMake
Fix the out-of-bounds read in cv::bilateralFilter for 32f images #28259
### Root Cause Analysis
The issue was caused by a discrepancy between the image range used to allocate the color weight look-up table (LUT) and the actual range of pixel values encountered during filtering, especially near the image borders.
- Range Computation: `cv::bilateralFilter` computes the min/max values of the source image and allocates a `LUT (expLUT)` of size `kExpNumBins + 2` based on this range.
- Border Padding: If `cv::BORDER_CONSTANT` is used (defaulting to 0), and 0 is outside the image's original range (e.g., an image with values between 100 and 200), the padded image will contain values (0) that create differences larger than those accounted for in the `LUT`.
- Out-of-Bounds Access: When calculating the color weight, the code computes an index `idx` from the absolute difference. If this difference exceeds the expected range, `idx` can reach or exceed `kExpNumBins + 1`. Since the code performs linear interpolation using `expLUT[idx]` and `expLUT[idx + 1]`, an `idx` of `kExpNumBins + 1` causes an access to `expLUT[kExpNumBins + 2]`, which is out of bounds.
### Fix
I implemented a robust clamping mechanism in both the SIMD (AVX/SSE) and scalar paths of the bilateral filter invoker:
- Signature Update: Updated `bilateralFilterInvoker_32f` to accept `kExpNumBins` (the maximum valid `LUT` index).
- Clamping: Clamped the computed color difference (alpha) to `kExpNumBins` before calculating the `LUT` index. This ensures that any difference exceeding the planned range is safely treated as the maximum difference in the `LUT` (which usually corresponds to a weight of 0), avoiding any out-of-bounds memory access.
### Modified Files
Modified Files:
`modules/imgproc/src/bilateral_filter.simd.hpp`: Updated the invoker class and SIMD/scalar loops to clamp the LUT index.
`modules/imgproc/src/bilateral_filter.dispatch.cpp`: Updated the dispatch call site to pass the correct LUT size.
Closes#28254
### 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
js: restore deep copy behavior for Mat.clone() #28216
### Problem
In OpenCV.js, `cv.Mat.clone()` may resolve to Embind `ClassHandle.clone()` (handle/shallow clone) instead of OpenCV deep copy.
### Changes
- modules/js/src/helpers.js: override `cv.Mat.prototype.clone` -> `mat_clone` after runtime init
- modules/js/test/test_mat.js: update/extend tests to validate deep copy semantics of `clone()`
Fixes #27572
Related: PR #26643 (js_clone_fix), PR #27985 (documentation update)
### Verification
- Built OpenCV.js with Emscripten 2.0.10
- QUnit: bin/tests.html
- CoreMat: test_mat_creation (0 failures)
<img width="745" height="362" alt="clone_fix" src="https://github.com/user-attachments/assets/16399abf-b94c-4591-b4aa-6e0fbd6cf23b" />
### 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
imgproc: fix heap-buffer-overflow in stackBlur #28233#28250
### Summary
Fixes a heap-buffer-overflow in `cv::stackBlur` when the kernel size is larger than the image dimensions
### Changes
* Added input validation to clamp the kernel size to the image dimensions.
* Added a regression test (`regression_28233`) covering 1x1 and small image cases.
Fixes#28233
core: fix solveCubic numerical instability via coefficient normalization (fixes#27748) #28117
Summary
This PR fixes numerical instability in `cv::solveCubic` when the leading coefficient `a` is non-zero but extremely small relative to other coefficients (Issue #27748).
It introduces a **normalization step** that scales all coefficients by their maximum magnitude before solving. This ensures robust detection of when the equation should degenerate to a quadratic solver, without breaking valid cubic equations that happen to have small coefficients (e.g., scaled by 1e-9).
The Problem (Issue #27748)
The previous implementation checked `if (a == 0)` to decide whether to use the cubic or quadratic formula.
- When `a` is extremely small (e.g., 1e-17) but not exactly zero, and other coefficients are normal (e.g., 5.0), the standard cubic formula suffers from catastrophic cancellation and overflow, producing incorrect roots (e.g., 1e14).
The Fix
1. Normalization: The solver now finds `max_coeff = max(|a|, |b|, |c|, |d|)` and scales all coefficients by `1.0 / max_coeff`.
2. Relative Threshold: It then checks `if (abs(a) < epsilon)` on the *normalized* coefficients.
Why this is better than previous attempts
In a previous attempt (PR #28057), a simple absolute check `abs(a) < epsilon` was proposed. That approach was rejected because it failed for scaled equations.
Fixes#27748
Added randomNormalLike layer to 4.x branch #28164
OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1297
Backport of https://github.com/opencv/opencv/pull/28110 to 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
- [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
Stateless HAL for filters and morphology. #28208
### 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
[video] Add setCoarsestScale to DISOpticalFlow (Fixes#25068) #28217
### Description
This PR addresses issue #25068 regarding the number of scales in `DISOpticalFlow`.
Currently, `DISOpticalFlow` automatically computes the `coarsest_scale` based on the image size. While generally effective, this behavior can cause errors in specific use cases (e.g., mechanics/speckle pattern analysis) where high pyramid levels degrade quality.
This change introduces a manual override:
- Added `setCoarsestScale(int val)` and `getCoarsestScale()` to the public API.
- Updated `DISOpticalFlowImpl::calc` and `ocl_calc` to use the user-defined scale if set.
- Preserved the existing "automatic" behavior as the default (when set to -1).
### Changes
- **`modules/video/include/opencv2/video/tracking.hpp`**: Added virtual method declarations.
- **`modules/video/src/dis_flow.cpp`**: Implemented `set/getCoarsestScale` in `DISOpticalFlowImpl` and updated calculation logic.
- **`modules/video/test/test_OF_accuracy.cpp`**: Added `DenseOpticalFlow_DIS.ManualCoarsestScale` regression test.
Fixes#25068
Keep convexHull output indices monotone if possible #28163
### Pull Request Readiness Checklist
resolves https://github.com/opencv/opencv/issues/24907 ?
resolves https://github.com/opencv/opencv/issues/4954
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
Replaces wasteful temporary object construction with in-place construction using emplace_back. Covers hot paths in objdetect, imgproc, and stitching modules.
dnn(tflite): add support for MAXIMUM layer #28171Fixes#26433
This PR adds support for the `MAXIMUM` layer in the TFLite importer.
It maps the TFLite `MAXIMUM` opcode to the existing OpenCV Element-wise `Max` operation.
### 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
Fix regex escape warning in _coverage.py by using raw string #2819
while i am running '_coverage.py' I noticed there is a syntax warning:"\." It is an invalid escape sequence
The regex was written as a normal string with '\.' which is not valid escape in string literals and give problems and error in a new python versions.
To fix this switch to raw string(r'cv2?\.\w+') which can passes the backslashes directly to the regex engine. This removes the warning and keeps the code and pattern working properly.
This is a small fix but important for future compatibilities.
