Rvv core norm #29057Fixesopencv/opencv#29052
### Problem
`Core_Norm/ElemWiseTest.accuracy/0` failed on RISC-V with RVV enabled when computing norm for `CV_16S` data.
The reported failing case was:
```text
src[0] ~ 16sC4 3-dim (1 x 116 x 40)
```
The expected norm result was a large positive `double`, but the RVV path returned an incorrect value:
```text
expected: 3370900308417
actual: -173296
```
This indicates that the problem was not in the public `cv::norm()` API, but in the RVV HAL implementation used for the `CV_16S` L2/L2SQR accumulation path.
### Root Cause
The RVV HAL has a specialized implementation for `CV_16S` L2 norm:
```cpp
NormL2_RVV<short, double>
```
The implementation widens `int16` values, squares them, converts the widened products to `float64`, accumulates them in an `f64m8` vector, and finally reduces the vector to a scalar `double`:
```cpp
auto s = __riscv_vfmv_v_f_f64m8(0, vlmax);
...
auto v_mul = __riscv_vwmul(v, v, vl);
s = __riscv_vfadd_tu(s, s, __riscv_vfwcvt_f(v_mul, vl), vl);
...
return __riscv_vfmv_f(__riscv_vfredosum(...));
```
The bug was in the scalar initializer passed to `__riscv_vfredosum`.
Before this patch, the code created an `f64m1` scalar vector but used the maximum vector length for `e32m1`:
```cpp
__riscv_vfmv_s_f_f64m1(0, __riscv_vsetvlmax_e32m1())
```
This is inconsistent: the vector type is `f64m1`, so the VL used to initialize it must correspond to `e64m1`, not `e32m1`.
objdetect(aruco): fix maxCorrectionBits in predefined dictionaries #29034
This PR fixes the bugs in the creation of some dictionaries and standarizes its construction.
## Bugs
1. **DICT_ARUCO_MIP_36h12_DATA** was incorrectly assigned `maxCorrectionBits=12`, which is the intermarker distance. This was causing a high rate of false positives during detection, which is a significant problem.
2. **APRILTAG** dictionaries were incorrectly created with `maxCorrectionBits=0`, making it impossible to do error correction.
## Solution
Given a intermarker distance X, the correct `maxCorrectionBits = X/2 - 1`. Thus, standardize the construction of Dictionaries as such.
libpng upgrade to 1.6.57 #29051
### 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
Python: add context manager compatibility for VideoCapture and VideoWriter #28967
### Description
This PR implements the context manager protocol (`with` statement support) for `cv2.VideoCapture` and `cv2.VideoWriter` objects in Python.
### Problem
Currently, these classes do not support the context manager protocol, leading to a `TypeError: ... object does not support the context manager protocol` when used with a `with` block. As reported in issue #28956, if an exception occurs before an explicit `.release()` call, the video resource or file remains locked in the system[cite: 298, 309].
### Identification & Motivation
By analyzing the issue and the Python binding structure of OpenCV, I identified that while the core logic resides in C++, the Pythonic behavior can be enhanced by injecting `__enter__` and `__exit__` methods during the module initialization. This ensures that resources are automatically and safely released even if the program execution is interrupted by an error[cite: 298, 325].
### Solution
I have modified `modules/python/package/cv2/__init__.py` to dynamically inject the necessary methods:
1. Defined `_video_enter` to return the object itself (standard context manager behavior).
2. Defined `_video_exit` to trigger the `.release()` method automatically.
3. Injected these methods into `VideoCapture` and `VideoWriter` classes immediately after the `bootstrap()` function to ensure the native C++ classes are correctly loaded into the global namespace.
Fixes#28956
## Summary
Replace the existing RVV HAL FAST-16 implementation (`hal/riscv-rvv/src/features2d/fast.cpp`) with a score-first approach, achieving **2-4x speedup** over the previous HAL implementation on RISC-V hardware.
## Approach
The previous HAL implementation used a count-based approach (XOR trick + per-pixel bitmask scanning + separate cornerScore computation). This PR replaces it with a **score-first** approach that processes multiple horizontal pixels in parallel using RVV vectors.
Key optimizations:
1. **Score-first approach**: Directly compute corner scores via min/max reduction over all 9-arc windows, then threshold on score. This eliminates the arc-counting pass and the separate `cornerScore` function.
2. **u8 to i16 zero-extension**: Zero-extend pixel values to int16 for natural signed comparison, eliminating the XOR-delta trick and preventing score overflow.
3. **vcompress batch output**: Extract all corner indices in one vector operation instead of per-lane bitmask scanning.
4. **vlen-adaptive**: Uses `vsetvl_e16m1` for dynamic vector length — works on any RVV 1.0 implementation regardless of VLEN (128, 256, 512, etc.) without code changes.
## Performance
Benchmarked by maintainer on **Muse Pi v3.0** (GCC, SpacemiT toolchain v1.0.4):
| Test | Previous HAL (ms) | This PR (ms) | Speedup |
|------|-------------------|--------------|---------|
| FAST-20 NMS=true | 23.06 | 7.99 | **2.89x** |
| FAST-20 NMS=true (orig) | 7.31 | 1.80 | **4.06x** |
| FAST-30 NMS=false | 20.10 | 7.75 | **2.59x** |
| FAST_DEFAULT s2.jpg | 76.94 | 19.06 | **4.04x** |
| ORB_DEFAULT chess9 | 64.46 | 25.43 | **2.53x** |
Both NMS=true and NMS=false cases are supported.
## Files Changed
- **`hal/riscv-rvv/src/features2d/fast.cpp`**: Replaced count-based implementation with score-first approach
- No changes to `modules/features2d/src/fast.cpp` or any other files
## Test Plan
- [x] Built with RISC-V cross-compilation toolchain (GCC 14.2, RVV 1.0)
- [x] Tested on QEMU (rv64, v=true, vlen=256) — correct results for both NMS modes
- [x] Maintainer tested on Muse Pi v3.0 hardware — 2-4x speedup confirmed
- [ ] CI passes on all platforms
Fix CMake crash when CUDA arch autodetection comes up empty #28954
With CUDA 13 and a system gcc that the toolkit does not support, every NVCC probe inside ocv_filter_available_architecture fails and the result list ends up empty. The next line then calls list(GET ... -1) on that empty list, so CMake dies with the unhelpful message about list GET given empty list and the user has no obvious next step. This change replaces that path with a fatal error that points at the three real fixes, namely setting CUDA_ARCH_BIN, setting CUDA_HOST_COMPILER, or enabling OPENCV_CMAKE_CUDA_DEBUG to see what NVCC actually printed. It also forwards CMAKE_CUDA_HOST_COMPILER into CUDA_HOST_COMPILER since the issue reporter passed the standard CMake variable and it was being silently ignored.
Fixes#28952
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
Use Xcode DocC tool for buiding Apple platform docs + add quick-start tutorial #28704
### 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
This PR resolves https://github.com/opencv/opencv/issues/28702 and https://github.com/opencv/opencv/issues/28703
Additionally it resolves build issues on Apple platforms by making build scripts run with Python 3
Add ARMPL support for DFT Function #28664
- This PR introduces hal/armpl/ with implementation of 1D, 2D DFT and DCT routines using ARM Performance Libraries as a custom HAL replacement for OpenCV's DFT & DCT Function.
- ArmPL MSI package is automatically downloaded and extracted via CMake when building on Windows ARM64, with a WITH_ARMPL option that defaults to ON for that platform.
- Forward and inverse real DFT calls in dxt.cpp are routed through ArmPL when available, with scaling applied only when needed.
- Test error thresholds in test_dxt.cpp are relaxed (from 1e-5 to 2e-4 for float ) to account for numerical differences between ArmPL and OpenCV's reference DFT results.
**Performance Benchmarks :**
<img width="993" height="835" alt="image" src="https://github.com/user-attachments/assets/76def647-6d20-4bce-8bc9-7363e723669f" />
- [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
- Implement inrange_simd() covering uchar/ushort/short, chan=1/2/3/4
- Replace legacy CV_SIMD128 run_inrange3 with modern CV_SIMD API
- Extend perf tests to cover all added type/channel combinations
- Resolves TODO introduced in #12608 (2018)
fix: Guard ndsrvp filter center copy when source span is empty #28915
## Summary
This adds a defensive guard around the centre-region `memcpy` in the ndsrvp HAL filter padding path.
**Description**: Multiple memcpy calls in the ndsrvp HAL filter, bilateral filter, and median blur routines use computed sizes (e.g., cnes * (rborder - j), cn * (rborder - j), src_step * height) without validating that the computed byte count fits within the destination buffer. An attacker supplying a crafted image with manipulated dimensions, channel counts, or border parameters can cause the computed copy size to exceed the allocated destination buffer, resulting in a heap buffer overflow that corrupts adjacent memory.
## Changes
- `hal/ndsrvp/src/filter.cpp`
## Verification
- [x] Build passes
- [x] Scanner re-scan confirms fix
- [x] LLM code review passed
---
*Automated security fix by [OrbisAI Security](https://orbisappsec.com)*
cmake: fix PNG status display when BUILD_PNG=ON #28995
### Description
Fixes#28657.
On macOS (and other Apple platforms), `BUILD_PNG=ON` is the default. The build system correctly clears `PNG_FOUND` in `OpenCVFindLibsGrfmt.cmake` and builds libpng from the bundled source. However, during the subsequent module processing phase, a downstream `find_package(PNG)` call — triggered transitively via `include()` in the **same scope** — overwrites not only `PNG_FOUND`, but also `PNG_INCLUDE_DIR`, `PNG_LIBRARIES`, and `PNG_VERSION_STRING`.
#### Root Cause: FindPNG.cmake Has Asymmetric Guards
Reading CMake 4.3's `FindPNG.cmake` (`/opt/homebrew/share/cmake/Modules/FindPNG.cmake`) reveals:
| Variable | Guard? | Fate |
|---|---|---|
| `PNG_LIBRARY` | `if(NOT PNG_LIBRARY)` at line 138 — **guarded** | Preserved |
| `PNG_PNG_INCLUDE_DIR` | `find_path(...)` at line 115 — **no guard** | **Overwritten** |
| `PNG_INCLUDE_DIR` | Derived from `PNG_PNG_INCLUDE_DIR` | **Chain-overwritten** |
| `PNG_LIBRARIES` | Derived from `PNG_LIBRARY` + `ZLIB_LIBRARY` | **Partly overwritten** |
| `PNG_VERSION_STRING` | Parsed from `PNG_PNG_INCLUDE_DIR/png.h` | **Overwritten** |
`PNG_LIBRARY` survives because FindPNG itself checks `if(NOT PNG_LIBRARY)`. But `find_path(PNG_PNG_INCLUDE_DIR)` runs unconditionally — re-searching and overwriting the bundled path with the system one.
#### Fix: Three Coordinated Changes
**Part A — Status guard** (`CMakeLists.txt`): When `BUILD_PNG=ON`, pass `FALSE` as the condition to always show `"build"` regardless of `PNG_FOUND`.
**Part B — Variable lock** (`cmake/OpenCVFindLibsGrfmt.cmake`): After building from bundled source, lock `PNG_PNG_INCLUDE_DIR` as `CACHE INTERNAL`. CMake's `find_path()` checks the cache first — if the variable exists with a valid path, it skips re-searching. The system path is never found.
**Part C — Cache cleanup** (`cmake/OpenCVFindLibsGrfmt.cmake`): Add `PNG_PNG_INCLUDE_DIR` to the `ocv_clear_internal_cache_vars()` call in the `else` branch. When a user switches `BUILD_PNG=OFF`, the cached variable is cleared, allowing `find_path` to search for the system libpng normally. Prevents stale cache leakage across configuration changes.
#### Verification (macOS 26, CMake 4.3, Homebrew libpng 1.6.58)
```
BEFORE downstream find_package(PNG):
PNG_LIBRARY = libpng
PNG_INCLUDE_DIR = .../3rdparty/libpng
PNG_VERSION_STRING = 1.6.37
AFTER downstream find_package(PNG) [with fix]:
PNG_LIBRARY = libpng ← preserved (FindPNG guard)
PNG_INCLUDE_DIR starts with .../3rdparty/libpng ← locked (Part B)
PNG_VERSION_STRING = 1.6.53 ← from bundled png.h
Status display: build (ver 1.6.53) ← correct (Part A)
```
The full reproduction and analysis are in the attached `bugReview/` directory.
### Checklist
- [x] There is a reference to the original bug report and related work
- [x] The test case is in `bugReview/` directory
- [x] Tested on macOS 26 (arm64) with CMake 4.3 + Homebrew libpng 1.6.58
- [x] Cache hygiene verified for BUILD_PNG ON→OFF→ON transitions
flann: fix Index::radiusSearch output size mismatch #28990
## Problem
`Index::radiusSearch` returns `nn` — the number of neighbors found within the radius — but the output arrays `_indices` and `_dists` are always allocated with `maxResults` columns regardless of how many neighbors were actually found. This creates two inconsistencies:
1. When `nn < maxResults`, the output arrays contain stale entries beyond position `nn`, so `nn != indices.cols` and callers cannot rely on the output size to know how many results are valid.
2. When `nn > maxResults`, the return value exceeds the capacity of the output arrays, which have only `maxResults` columns. The extra neighbors were never stored, so the return value is misleading.
The following snippet reproduces both cases:
```cpp
int testFLANN(){
std::vector<cv::Point2f> corners={{3679.83,1857.22},{3324.43,1850.67},{3278.83,1502.32},{3621.32,1508.69},{3662.26,1837.97},{3336.06,1839.28},{3291.74,1516.03},{3608.94,1518.72},{2980.66,1843.22},{2628.11,1837.14},{2607.73,1491.57},{2948.22,1496.76},{2289.31,1830.19},{1943.99,1824.17},{1945.51,1482.34},{2280.68,1487.39},{1607.47,1819.11},{1260.04,1813.26},{1283.94,1470.34},{1620.03,1475.85},{923.063,1808.08},{576.193,1802.4},{624.713,1459.78},{959.715,1464.93},{3270.25,1494.98},{2952.95,1492.19},{2922.75,1190.02},{3231.05,1194.81},{3284.82,1507.62},{2942.74,1502.59},{2912.32,1178.33},{3242.98,1183.19},{2612.82,1496.37},{2276.44,1491.63},{2267.61,1170.13},{2593.64,1174.43},{1949.73,1486.61},{1614.92,1480.64},{1626.77,1160.34},{1952,1165.51},{1289.38,1476.21},{953.709,1470.21},{986.779,1148.92},{1311.98,1154.89},{3567.28,1195.1},{3237.51,1189.03},{3197.63,884.15},{3518.61,888.76},{2918.31,1183.62},{2588.69,1179.37},{2570.64,875.672},{2889.87,878.902},{2271.97,1174.25},{1947.62,1169.61},{1948.56,868.197},{2263.8,872.533},{1630.99,1164.6},{1306.74,1159.52},{1327.81,858.358},{1642.69,862.765},{992.896,1155.52},{666.107,1149.96},{705.246,845.776},{1023.25,851.582},{3204.48,889.981},{2883.49,885.252},{2859.31,593.752},{3175.43,594.736},{2575.86,880.331},{2259.44,876.647},{2252.33,589.235},{2560.47,592.332},{1954.36,873.708},{1636.7,868.068},{1646.93,580.76},{1956.14,584.797},{1332.02,862.624},{1017.11,856.71},{1045.32,572.178},{1350.95,577.635},{3481.36,605.324},{3169.05,601.083},{3138.84,324.116},{3446.12,325.545},{2866.14,599.61},{2555.38,597.142},{2541.51,320.931},{2845.5,322.419},{2256.79,593.253},{1950.17,590.12},{1951.8,317.445},{2250.88,319.418},{1654.16,587.663},{1344.83,582.787},{1362.8,309.253},{1663.89,313.056},{1050.94,577.867},{741.476,571.648},{776.433,300.444},{1076.97,304.56},{3327.05,1847.65},{2977.74,1840.48},{2945.48,1499.68},{3281.82,1504.97},{2630.85,1834.22},{2287.2,1828.06},{2278.56,1489.51},{2610.64,1494.31},{1946.11,1822.05},{1604.75,1816.18},{1617.11,1478.59},{1947.62,1484.48},{1262.96,1810.53},{920.46,1805.05},{956.712,1467.57},{1286.66,1473.27},{3618.7,1511.71},{3281.82,1504.97},{3240.24,1186.11},{3564.22,1192.53},{2945.48,1499.68},{2610.64,1494.31},{2591.52,1176.55},{2915.32,1180.97},{2278.56,1489.51},{1947.62,1484.48},{1949.81,1167.56},{2269.79,1172.18},{1617.11,1478.59},{1286.66,1473.27},{1308.98,1157.53},{1628.88,1162.47},{956.712,1467.57},{627.315,1462.81},{669.943,1146.75},{989.494,1151.86},{3240.25,1186.11},{2915.32,1180.98},{2887.03,881.727},{3200.69,886.725},{2591.52,1176.55},{2269.79,1172.19},{2261.62,874.587},{2573.63,878.324},{1949.81,1167.55},{1628.88,1162.47},{1640.44,864.751},{1950.74,870.259},{1308.98,1157.53},{989.494,1151.86},{1019.41,854.787},{1329.92,860.49},{3515.88,891.68},{3200.69,886.725},{3171.89,598.263},{3478.26,602.785},{2887.04,881.725},{2573.63,878.324},{2558.28,594.392},{2863.1,597.005},{2261.62,874.587},{1950.74,870.259},{1952.4,588.114},{2254.56,591.241},{1640.44,864.751},{1329.92,860.49},{1348.65,579.559},{1650.55,584.209},{1019.41,854.787},{708.649,849.44},{745.388,568.534},{1047.42,574.313},{3171.89,598.263},{2863.1,597.005},{2842.6,325.169},{3141.93,326.654},{2558.28,594.392},{2254.56,591.241},{2248.65,321.425},{2544.55,323.537},{1952.4,588.113},{1650.55,584.209},{1660.07,316.284},{1954.02,319.457},{1348.65,579.559},{1047.43,574.312},{1073.06,307.674},{1366.42,312.707}};
cv::flann::KDTreeIndexParams indexParams(1);
cv::Mat data = cv::Mat(corners).reshape(1, static_cast<int>(corners.size()));
auto index = std::make_shared<cv::flann::Index>(data, indexParams);
int maxResults = 4;
int nTimesError1 = 0; // nn != indices.size()
int nTimesError2 = 0; // nn > maxResults
for (size_t i = 0; i < corners.size(); i++) {
std::vector<int> indices(4);
std::vector<float> dists(4);
int nn = index->radiusSearch(data.row(static_cast<int>(i)), indices, dists, 100, maxResults);
if (nn != (int)indices.size()) { nTimesError1++; }
if (nn > maxResults) { nTimesError2++; }
}
std::cout << "nTimesError1: " << nTimesError1 << std::endl; // > 0 before fix
std::cout << "nTimesError2: " << nTimesError2 << std::endl; // > 0 before fix
return 1;
}
```
## Fix
- Capture the search result in `rsearch_ret` instead of returning early from each `switch` case (this also required adding the missing `break` statements that would otherwise have caused fall-through between type-incompatible distance specialisations).
- Cap `rsearch_ret` at `maxResults` so the return value never exceeds the capacity of the output arrays.
- When `rsearch_ret < maxResults`, trim `_indices` and `_dists` to `query.rows × rsearch_ret` via `colRange(0, rsearch_ret).copyTo(...)` so the output dimensions always match the returned count.
core : add NEON intrinsics support for norm_mask function #28610
- This PR adds NEON intrinsics-based implementations for masked norm operations in norm.simd.hpp for ARM64 architecture.
- The optimized implementation uses ARM NEON intrinsics to accelerate masked norm computations (Infinity norm, L1 norm, and L2 norm) used by the norm function when a mask is provided.
- In the x64 architecture, masked norm operations benefit from IPP-based optimized implementations. However, on ARM64, the execution falls back to scalar implementations, which results in lower performance.
- To achieve performance parity with x64, NEON-based SIMD implementations have been added for ARM64.
- Additionally, scalar loop unrolling optimizations have been added for non-masked norm operations.
- After introducing these changes, masked norm operations showed significant performance improvements on ARM64 platforms, particularly for single-channel (cn=1) operations where NEON intrinsics provide the greatest benefit.
<img width="952" height="822" alt="image" src="https://github.com/user-attachments/assets/12d35f93-a316-4520-9d9c-12ce6b371ddb" />
- [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
The previous OpenCL implementation of UMat::diag() relied on a sequence of
operations involving buffer initialization followed by copy/transpose on
an aliased diag() view. Although these operations were enqueued on an
in-order command queue, this implicitly assumed memory visibility between
kernels operating on aliased regions of the same buffer.
According to the OpenCL specification, in-order command queues only guarantee
command scheduling order, while memory visibility between commands is only
established through explicit command-level synchronization points (e.g.
events, barriers, or clFinish).Under OpenCL’s relaxed memory model, such
assumptions are not guaranteed without an explicit command-level synchronization
point, and can lead to data races and incorrect results, especially for very
small matrices (e.g. 1x1). The issue is more likely to be exposed on Mesa-based drivers
when the GPU is running at lower frequencies (e.g. 500 MHz).
This change introduces a dedicated OpenCL kernel to construct the diagonal
matrix in a single kernel invocation, avoiding intermediate aliasing and
eliminating the need for implicit ordering assumptions. If the OpenCL path
is unavailable or unsupported, the implementation transparently falls back
to the CPU path.
Signed-off-by: jiajia Qian <jiajia.qian@nxp.com>
hal/riscv-rvv: implement laplacian #28887
OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1353
An implementation of laplacian for riscv-rvv hal
Added benchmark in perf_laplacian.cpp
The performance is evaluated on K1 by running
./opencv_perf_imgproc --gtest_filter="Perf_Laplacian*"
Results are attached in the figure below.
CV_8U fast path supports ksize=3 with BORDER_CONSTANT/BORDER_REPLICATE; unsupported combinations fall back to default implementation. See performance results bellow.
### 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
Feat: Add OpenCL support for AKAZE features #28879
Implement OpenCL-accelerated AKAZE feature
detection and descriptor extraction
Benchmarked on RTX 5060 Ti: 1.2x to 3.31x faster
for image sizes from 640x480 to 3840x2160
- Added 8 OpenCL kernels for feature detection and descriptor extraction
- Refactored compute_kcontrast to use OpenCV magnitude() for consistency
- Added comprehensive tests with >95% accuracy vs CPU baseline
### 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
- [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
The minMaxIdx dispatch table in modules/core/src/minmax.cpp stored
seven differently typed functions through C-style casts to a single
MinMaxIdxFunc pointer type, which is undefined behaviour and trips
UBSan's -fsanitize=function for any CV_32F or CV_64F input. This
change switches the typedef and every depth-specific helper to take
void pointers for src, minval and maxval, with the original typed
pointer recovered at function entry. The dispatch table no longer
needs C-style casts and the int pointer punning at the call site
goes away. Fixes#28928.
Better AutoBuffer API #28909
Mimic std::vector<> to help replacing std::vector<T> by cv::AutoBuffer<T> when possible
### 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
videoio(dshow): fix crash in videoInput::start() when pVih is NULL #28914
### Summary
This PR fixes a critical application crash in the DirectShow backend when encountering certain legacy or virtual cameras (e.g., Microsoft's DirectShow "Ball" Sample).
### The Problem
In `modules/videoio/src/cap_dshow.cpp`, the function `videoInput::start()` calls `pConfig->GetConnectedMediaType(&mt)`.
- In some edge cases, this call returns `S_OK`, indicating success.
- However, the associated format block `mt.pbFormat` (which `pVih` points to) can still be `NULL`.
- The current implementation uses `CV_Assert(pVih)`, which triggers a hard crash of the entire application when this occurs.
### The Fix
I have replaced the `CV_Assert(pVih)` with a null-pointer check. If `pVih` is `NULL`, the function now returns `false`. This allows the high-level `cv::VideoCapture` to handle the failure (e.g., by returning `false` from `.open()`) instead of crashing the process.
### Engineering Rationale
- Execution Path Consistency: For devices providing valid format headers, `pVih` remains non-NULL. In these cases, the conditional check is skipped, and the execution path is identical to the original implementation.
- Process Stability: Replacing `CV_Assert` prevents immediate process termination (SIGABRT) when a DirectShow filter provides an invalid or empty format block.
- Error Propagation: Returning `false` in `videoInput::start()` allows the initialization failure to propagate through the call stack. This ensures that `cv::VideoCapture::open()` returns `false`, enabling the caller to detect the issue via the standard API (e.g., `isOpened()`) instead of the process being terminated.
### Evidence
I have manually reproduced this crash using the Microsoft DirectShow Ball Sample filter on Windows. As shown in the attached debugger screenshot:
- `deviceID` is 2 (the virtual camera).
- `hr` is `S_OK`.
- `pVih` is `NULL`.
<img width="773" height="1413" alt="dshow_null_pvih_debug_evidence" src="https://github.com/user-attachments/assets/5bc454b4-4a0b-4703-825d-0d5fd23cba28" />
Fixes#28904
### 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
- Replace unsafe pointer arithmetic and direct buffer modification with std::string methods.
- Update documentation to clarify that the last digit is used as compression level and truncated from the actual filename.
- Add test cases for .gz and .gz0-9
Teddy-Yangjiale
Alexander Smorkalov
Rafael Muñoz Salinas
Maksim Shabunin
Tiansuanyu
Michael Klatis
Ebrahim Namdari
Shengyu-Wu
SamareshSingh
Alexander Smorkalov
Giles Payne
Pratham Kumar
manfred
orbisai0security
donotsleepy
Dmitry Kurtaev
Kumataro
jiajia Qian
Vincent Rabaud
Alex Wu
Anand Mahesh
Samaresh Kumar Singh
Pierre Chatelier
ekharkov