core: SIMD optimizations for norm, distance and Hamming APIs. (Improves ORB & BRISK) #29335
Generic universal-intrinsic kernels (benefit all SIMD backends: NEON, AVX2, AVX-512, etc.), plus enabling wider dispatch for the norm module.
- hal::normHamming: cached-pointer dispatch (resolve once, no per-call dispatch chain or trace region) + vector popcount path. cv::norm(NORM_HAMMING) and binary-descriptor matching (BFMatcher ORB/BRISK/FREAK via cv::batchDistance).
- hal::normL2Sqr_ / normL1_: direct inlinable kernels with single-vector tail (cv::batchDistance / BFMatcher float L2/L1, cv::kmeans).
- cv::norm masked NORM_INF: deinterleave SIMD for multichannel + back-step tail.
- cv::norm(src1, src2, type, mask): SIMD masked norm-diff; INF is one templated kernel for all element types, plus uchar L1/L2 and int L1 kernels.
- Enable AVX512_SKX/AVX512_ICL dispatch for the norm module.
- features2d: add BFMatcher knnMatch perf tests (float L2/L1, binary Hamming).
- ORB and BRISK performance improved
### 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
Extended Attention layer support #29333
Implemented present/past KV support.
Merge with: https://github.com/opencv/opencv_extra/pull/1381
Co-authored by: @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
- [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
dnn: add Winograd F(6,3) RVV implementation for RISC-V (VLEN≥256) #29411
### Summary
Adds a RISC-V Vector (RVV) backend for the Winograd F(6,3) convolution path
in the DNN module, targeting VLEN≥256 processors (tested on SpacemiT K1,
rv64gcv).
### Background
The Winograd F(6,3) path was already gated on `useSIMD128 || useAVX ||
useAVX2 || useNEON` at runtime, and protected by the same set of compile-time
macros. RVV was simply missing from both guards, so it always fell through to
generic convolution even when the hardware supports it.
A second issue: `conv_winograd_f63` was registered with
`ocv_add_dispatched_file`, which skips ISA variants not present in the host
toolchain during cross-compilation. Changing to `ocv_add_dispatched_file_force_all`
forces the `.rvv.cpp` translation unit to be generated unconditionally, matching
how every other RVV-enabled kernel in the DNN module is registered.
### Implementation notes
**Atom width.** `vsetvlmax_e32m1()` returns 8 on VLEN=256, so `winoAtomF32=8`
is chosen, matching the AVX2 atom width. The `impl_accum_F32` and transform
functions are structured identically to the AVX2 path (4 output channels ×
6 input tiles per atom).
**Input/output transform.** AVX2 uses `_mm256_unpacklo/hi_ps` + `permute2f128`
for an in-register 8×8 transpose. RVV has no equivalent cross-lane shuffle at
this width without `vrgather`, which adds index-vector overhead for a
non-bottleneck step. Instead the 8×8 intermediate matrix is transposed
scalar-in-memory between the two `wino_bt8x8_rvv` / `wino_at8x6_rvv` passes.
This keeps the transform code simple and correct; the GEMM in `impl_accum_F32`
dominates runtime.
**VLEN guard.** `getWinofunc_F32` checks `vsetvlmax_e32m1() >= 8` at runtime
and returns an empty functor on narrower implementations, so the code is safe
on VLEN=128 targets without a separate code path.
### Testing
**Correctness:** `ConvolutionWinograd.Accuracy` passes on the K1 board (9 ms).
**Performance:** `opencv_perf_dnn`, SpacemiT K1 (rv64gcv, VLEN=256),
GCC 13, `-O2 -march=rv64gcv`. Reported times are per-iteration medians from
`[ PERFSTAT ]` output (`--perf_min_samples=5`). "Generic" is the same build
with Winograd disabled via `OPENCV_DNN_DISABLE_WINOGRAD=1`.
| Input → Output C | Winograd (ms) | Generic (ms) | Speedup |
|--------------------------|--------------|-------------|---------|
| {1,128,52,52} → 256 | 35.97 | 62.86 | 1.75× |
| {1,512,13,13} → 1024 | 65.18 | 112.50 | 1.73× |
| {1,256,75,75} → 256 | 159.75 | 271.65 | 1.70× |
| {1,64,300,300} → 64 | 174.21 | 295.32 | 1.69× |
| {1,1152,16,16} → 1152 | 176.12 | 245.33 | 1.39× |
### 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.
- [ ] The feature is well documented and sample code can be built with the project CMake
Optimized gemm implementation with Universal SIMD #29242
- vectorized GEMMSingleMul and GEMMBlockMul
### 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
dnn: implement LpPool ONNX operator #29217
## Summary
Implements the `LpPool` ONNX operator (opset 1–18), which was previously unregistered and caused a parse failure. `LpPool` computes the Lp-norm pooling: `(sum(|x|^p))^(1/p)` over a sliding window.
## Changes
- New `LpPoolLayer` in `modules/dnn/src/layers/lppool_layer.cpp`
- Supports `kernel_shape`, `strides`, `dilations`, `pads`, `auto_pad` (NOTSET/SAME_UPPER), `ceil_mode`, and `p` (default 2)
- SIMD fast paths for p=1 (abs + accumulate) and p=2 (square + accumulate + sqrt); scalar fallback for other values of p
- Registered `LpPool` dispatch entry in both `onnx_importer.cpp` (classic engine) and `onnx_importer2.cpp` (new graph engine)
- Added `LpPoolLayer` declaration to `modules/dnn/include/opencv2/dnn/all_layers.hpp`
- Registered layer class in `modules/dnn/src/init.cpp`
- Re-enabled 8 lppool conformance tests in `test_onnx_conformance.cpp` (previously in parser denylist)
- `test_lppool_2d_same_lower` added to the global conformance denylist — same known SAME_LOWER padding bug that affects `averagepool` and `maxpool`
## Testing
All applicable ONNX conformance tests pass:
| Test | Result |
|------|--------|
| test_lppool_1d_default | PASSED |
| test_lppool_2d_default | PASSED |
| test_lppool_2d_dilations | PASSED |
| test_lppool_2d_pads | PASSED |
| test_lppool_2d_same_lower | SKIPPED (known SAME_LOWER padding bug, consistent with avgpool/maxpool) |
| test_lppool_2d_same_upper | PASSED |
| test_lppool_2d_strides | PASSED |
| test_lppool_3d_default | PASSED |
Tested on: macOS (x86_64/SSE4, Rosetta 2) and Linux x86_64 (AVX2/AVX-512, GCC 13.3.0), Release build
OpenCV version: 5.0.0-pre
## Related Issues
None
---
### 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.
- [ ] The feature is well documented and sample code can be built with the project CMake
videoio(avfoundation): fix SIGSEGV crash when releasing VideoWriter on iOS #29359
Replace deprecated synchronous finishWriting with
finishWritingWithCompletionHandler + dispatch_semaphore
to properly wait for the async completion handler.
The synchronous finishWriting method is deprecated since iOS 6
and, despite blocking until writing status completes, does NOT
wait for internal NSOperation KVO observer blocks that are
dispatched asynchronously to GCD worker threads. When the
destructor returns and drains the autorelease pool, these
blocks may access already-released objects, causing SIGSEGV.
This fix uses a semaphore to block until the
finishWritingWithCompletionHandler callback has fully completed,
eliminating the race condition between the async block and
autorelease pool drain.
Fixes#28165
cmake: fix#29028 macOS dynamic framework RPATH for relocatable install #29396
### Problem
When building OpenCV as a dynamic framework on macOS (`-DAPPLE_FRAMEWORK=ON -DBUILD_SHARED_LIBS=ON`), installed binaries contain an absolute `LC_RPATH` pointing to the build tree, making the install non-relocatable. Moving the install directory or deploying to another Mac causes binaries to crash on launch.
### Root cause
`cmake/OpenCVInstallLayout.cmake` unconditionally sets `CMAKE_INSTALL_RPATH` to `${CMAKE_INSTALL_PREFIX}/${OPENCV_LIB_INSTALL_PATH}` for all platforms. Additionally, `cmake/platforms/OpenCV-Darwin.cmake` was empty and missing the `@executable_path`/`@loader_path` linker flags that the iOS toolchain already sets for the same `APPLE_FRAMEWORK AND BUILD_SHARED_LIBS` case.
### Fix
- Guard `CMAKE_INSTALL_RPATH` in `OpenCVInstallLayout.cmake` to use relocatable `@executable_path` tokens for Apple framework builds
- Add equivalent linker flags to `OpenCV-Darwin.cmake`, mirroring `platforms/ios/cmake/Modules/Platform/iOS.cmake`
Fixes#29028
### 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
Use validBitIdThreshold for Aruco refineDetectedMarkers #29252
The goal of this PR is to solve the issue raised by @vrabaud in https://github.com/opencv/opencv/pull/28289 (comment: https://github.com/opencv/opencv/pull/28289#discussion_r3355812646).
**Issue:**
`refineDetectedMarkers()` converted the extracted cell ratios with `convertTo(CV_8UC1)` (an implicit 0.5 threshold) before computing the code distance, ignoring `detectorParams.validBitIdThreshold`.
**Solution:**
Make the refine path consistent with the main detection path `Dictionary::identify`.
**Changes:**
- Add a `Dictionary::getDistanceToId()` overload that takes the float cell pixel ratio matrix and `validBitIdThreshold` (similar to how it's done for the `identify()` overload.
- Move the per cell distance computation into a private `getDistanceToIdImpl` helper used by both `identify()` and the new overload of `getDistanceToId()` to avoid repetitions.
- `refineDetectedMarkers()` now calls the new overload.
**Tests:**
- `CV_ArucoRefine.validBitIdThreshold`: a marker with one degraded cell is recovered at threshold 0.7 but not at 0.49.
- `CV_ArucoDictionary.getDistanceToIdCellPixelRatio`: unit-tests both `getDistanceToId` overloads.
All passed
SVM::predict is dominated by the per-feature kernel reduction over the
support vectors. Vectorize the four reduction kernels in svm.cpp with
universal intrinsics (two independent accumulators + scalar tail):
calc_non_rbf_base (dot product), calc_rbf (squared distance),
calc_intersec (min-sum) and calc_chi2. Same approach as the KNN
findNearest reduction in #29380. Adds modules/ml/perf/perf_svm.cpp
covering the RBF/POLY/INTER/CHI2 kernels.
core: fix Unicode temp path handling on Windows (fix#21960) #28935
## Summary
Fixes getCacheDirectoryForDownloads and related temp file functions failing when the user home directory contains Unicode characters like C:\\Users\\テスト\\AppData\\Local\\Temp.
## Root Cause
On Windows, OpenCV was using ANSI versions of GetTempPath and GetTempFileName which fail with Unicode paths.
## Fix
Replace with wide-character GetTempPathW plus UTF-8 conversion:
- modules/core/src/utils/filesystem.cpp - getCacheDirectory for cache paths
- modules/core/src/system.cpp - temporary file creation
- modules/ts/src/ts_gtest.cpp - test stream capture
## Testing
The fix has been verified compiles. Manual testing on Windows with Unicode username required.
## Risk
Low: Uses same output format, just different encoding path. Existing ASCII functionality preserved.
---
Fixesopencv/opencv#21960
bound alphanumeric values in qr decodeAlpha before map lookup #29378
decodeAlpha in the no-quirc QR backend reads alphanumeric symbols from the post-ECC bitstream and indexes a fixed 45-entry map[] with the raw values. The 11-bit pair from next(11) goes up to 2047, so tuple/45 lands on 45 once the pair passes 2024, and the 6-bit trailing char from next(6) goes up to 63, so map[value] runs out to map[63]. A QR whose data codewords carry an alphanumeric segment with one of those out-of-range values reads past the static array, and the stray byte lands in the string returned by detectAndDecode. WITH_QUIRC defaults off, so this is the decoder a stock build runs.
Before, the only guard was on the encode side, which never emits those values, so the decoder trusted the stream and indexed map[] directly. New version checks value range and return empty string for malformed qr codes.
### 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
- [ ] 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
- [ ] The feature is well documented and sample code can be built with the project CMake
Port of #29377 to 5.x. Wires Log, Erf, Exp, Sin, Cos, Sinh, Cosh, Tan,
Softplus, BNLL, Asinh, Acosh, Atanh into the dispatched activation_kernels
registry, plus a Layer_Activation perf test. 1.4-12.3x across
M4/A76/Threadripper/Xeon, correct to <=5e-7 vs scalar.
bound tile axis and repeats length in onnx parseTile #29345
OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1385
parseTile sizes repeats_vec from the input-0 rank, then fills it from fields of the model that are never checked against that size. In the tile-1 path the axis taken from the third input indexes repeats_vec directly, and in the tile>1 path the loop writes one entry per element of the repeats tensor. A crafted ONNX with an out-of-range axis, or a repeats tensor longer than the input rank, writes past repeats_vec while loading the model through readNetFromONNX.
The fix runs axis through normalize_axis, the same helper the squeeze and concat paths in this file already use, so a negative or oversized axis is rejected before the write, and it checks the repeats length equals the input rank before the loop. Keeping both bounds in the parser puts the check next to the write instead of trusting the model to be well formed. Before, a repeats tensor shorter than the rank was silently accepted; after, it is rejected, which matches the ONNX rule that repeats carries one entry per input dimension.
- [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
- [ ] The feature is well documented and sample code can be built with the project CMake
dnn: SIMD for transcendental activation layers (15 functors) 🧑💻🤖#2937
# dnn: SIMD for transcendental activation layers (15 functors) 🧑💻🤖
### Summary
Many `BaseDefaultFunctor`-based activation functors fall back to the scalar `BaseDefaultFunctor::apply`
— one `libm` call per element. This PR adds vectorized `apply()` overrides (universal intrinsics,
matching the existing `MishFunctor`/`GeluFunctor`/`SigmoidFunctor` pattern, each with a scalar tail) to
the **15 transcendental activations** that have a clean SIMD path:
| functor | uses | | functor | uses |
|---|---|---|---|---|
| TanH | `v_exp` (1−2/(e²ˣ+1)) | | Asinh | `v_log`,`v_sqrt` (sign·log(\|x\|+√(x²+1))) |
| Log | `v_log` | | Acosh | `v_log`,`v_sqrt` |
| Erf | `v_erf` | | Atanh | `v_log` |
| Exp | `v_exp` | | Softplus | `v_exp`,`v_log` |
| Sin | `v_sin` | | BNLL | `v_exp`,`v_log` (max(x,0)+log1p(e^−\|x\|)) |
| Cos | `v_cos` | | GeluApproximation | `v_exp` (tanh) |
| Tan | `v_sin`/`v_cos` | | Sinh / Cosh | `v_exp` |
Functors compile at the baseline SIMD width (SSE on x86, NEON on ARM — same as the existing SIMD
functors). `Sqrt`/`Floor`/`Ceil`/`Round`/`Abs`/etc. are intentionally **not** included — those are
single cheap ops the compiler already auto-vectorizes (measured `Sqrt` at 0.95×). `Asin`/`Acos`/`Atan`
are omitted (no `v_atan`/`v_asin`/`v_acos` intrinsic).
### Performance
Real `opencv_perf_dnn` `Layer_Activation` (added here), 8×256×128×100 = 26.2 M-elem CV_32F blob, A/B
vs the scalar fallback, median speedup:
| functor | M4 clang/NEON | A76 gcc/NEON | Threadripper gcc | Xeon W-2235 gcc | functor | M4 | A76 | TR | Xeon |
|---|---|---|---|---|---|---|---|---|---|
| TanH | 9.1× | 2.3× | 7.3× | 7.3× | Sinh | 3.3× | 3.2× | 5.2× | 5.0× |
| Cos | 8.8× | 3.0× | 3.3× | 3.0× | Acosh | 3.2× | 2.9× | 2.7× | 2.6× |
| Log | 7.8× | 3.0× | 2.5× | 2.4× | Cosh | 2.8× | 3.2× | 2.6× | 2.5× |
| Sin | 7.8× | 3.0× | 3.4× | 2.9× | Exp | 2.4× | 2.5× | 1.4× | 1.5× |
| GeluApprox | 7.6× | 2.4× | 6.6× | 5.8× | BNLL | 4.2× | 2.0× | 1.6× | 1.4× |
| Atanh | 7.0× | 3.6× | 6.0× | 5.2× | Softplus | 2.0× | 2.0× | 3.3× | 2.7× |
| Tan | 6.8× | 3.6× | 6.6× | 6.0× | Erf | 4.2× | 2.4× | 3.9× | 3.5× |
| Asinh | 3.9× | 2.4× | 5.8× | 5.7× | | | | | |
Every functor is a win on every tested out-of-order core (worst case 1.4×). On the **in-order
Cortex-A55** (a55-tuned build) all 15 measure 0.985–0.99× — neutral, within noise: the SIMD
polynomials are dependency-chain-bound, which an in-order pipeline can neither accelerate nor (here)
slow down. So: meaningful wins on out-of-order ARM + x86, no regression on in-order ARM.
### Accuracy
Uses the `v_exp`/`v_log`/`v_erf`/`v_sin`/`v_cos` polynomials OpenCV already ships and relies on (Gelu
via `v_erf`, Mish/Sigmoid via `v_exp`). Verified vs scalar `libm` on 320 K random elements per functor
with domain-correct inputs (Acosh x≥1, Atanh |x|<1, …): **max abs error ≤ 3e-5** (most ≤ 2e-6), zero
elements exceeding rel>1e-3 & abs>1e-4. ONNX conformance and the layer accuracy tests exercise these ops.
### 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 (4.x)
- [ ] There is a reference to the original bug report and related work — N/A (perf improvement)
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable — perf test added (`Layer_Activation`, `SANITY_CHECK_NOTHING`); accuracy covered by existing ONNX conformance/layer tests
- [ ] The feature is well documented and sample code can be built with the project CMake — N/A (internal optimization, no new API)
Fix js ximgproc edge drawing #29387
## Summary
This PR fixes OpenCV.js binding generation for factory functions that return `cv::Ptr<T>` where `T` is a namespaced class exported with a module-prefixed JavaScript binding name.
The failure is reproduced with OpenCV.js plus `opencv_contrib/modules/ximgproc`. The generated binding for `cv::ximgproc::EdgeDrawing` currently contains:
```cpp
.constructor(select_overload<Ptr<EdgeDrawing>()>(&cv::ximgproc::createEdgeDrawing))
```
but `EdgeDrawing` is not available in the generated C++ scope as an unqualified type. The generated constructor should use:
```cpp
.constructor(select_overload<Ptr<cv::ximgproc::EdgeDrawing>()>(&cv::ximgproc::createEdgeDrawing))
```
## Related issues
Fixesopencv/opencv_contrib#4161.
Related to #27963, #28130, and #28143.
#28143 added namespace qualification for factory `Ptr<...>` return types when the inner `Ptr` type matches the generator class key. The remaining `ximgproc::EdgeDrawing` case is different:
```text
inner Ptr type: EdgeDrawing
generator class key: ximgproc_EdgeDrawing
C++ class name: cv::ximgproc::EdgeDrawing
```
Because `EdgeDrawing` does not match `ximgproc_EdgeDrawing`, the previous condition does not handle this case.
## Fix approach
The JS generator now centralizes factory `Ptr<...>` return-type qualification in a helper used by both generator paths:
* `gen_function_binding_with_wrapper`
* `gen_function_binding`
The helper keeps the existing behavior for already qualified types and for the existing class-key match. It additionally handles the case where the inner `Ptr` type matches the basename of the C++ class name:
```text
cv::ximgproc::EdgeDrawing -> EdgeDrawing
```
This allows the generator to emit `Ptr<cv::ximgproc::EdgeDrawing>` for `createEdgeDrawing()` without changing generated files directly.
## Necessity as an opencv code change
The failing API is exposed by `opencv_contrib/modules/ximgproc`, but the invalid C++ line is emitted by OpenCV core's JavaScript binding generator in `modules/js/generator/embindgen.py`.
A contrib-only workaround would have to change the `ximgproc` public declaration or special-case the JS export list for `createEdgeDrawing`. That would only work around one symbol and would not fix the generator's handling of namespaced factory `Ptr` return types. The generator already has the class metadata needed to produce the correct fully qualified C++ type, so the fix belongs in OpenCV core.
## Verification
Tested with:
* OpenCV core `4.x`
* opencv_contrib `4.x`
* Emscripten `6.0.1`
* CMake generator: Ninja
* Build list: `core,imgproc,imgcodecs,video,calib3d,ximgproc,js`
Generator target:
```bash
emcmake cmake \
-S /path/to/opencv \
-B /path/to/build \
-G Ninja \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_CXX_STANDARD=17 \
-DOPENCV_EXTRA_MODULES_PATH=/path/to/opencv_contrib/modules \
-DBUILD_LIST=core,imgproc,imgcodecs,video,calib3d,ximgproc,js \
-DBUILD_SHARED_LIBS=OFF \
-DBUILD_opencv_js=ON \
-DBUILD_TESTS=OFF \
-DBUILD_PERF_TESTS=OFF \
-DBUILD_EXAMPLES=OFF \
-DBUILD_DOCS=OFF
ninja -C /path/to/build gen_opencv_js_source
```
This generated the expected binding:
```cpp
.constructor(select_overload<Ptr<cv::ximgproc::EdgeDrawing>()>(&cv::ximgproc::createEdgeDrawing))
.smart_ptr<Ptr<cv::ximgproc::EdgeDrawing>>("Ptr<ximgproc_EdgeDrawing>")
```
The same patch was also verified with the full OpenCV.js target:
```bash
ninja -C /path/to/build opencv.js
```
Validate onnx tensor payload size in getMatFromTensor (5.x) #29370
5.x port of #29314. The DNN ONNX importer diverged here, so the change is ported manually.
`getMatFromTensor()` sizes the output blob from `TensorProto.dims` and then reads that many elements out of the tensor payload, but the payload is sized independently in the model and never checked against the shape. In 5.x the payload reaches the read through three sources: a typed `*_data` field, `raw_data`, or external-file data routed through `getTensorRAWData()`. An initializer whose dims claim more elements than the payload holds makes the `Mat` copy/convert read past the buffer.
### Before
A FLOAT tensor declaring `[1000000]` backed by a 4-byte `raw_data` reads about 4 MB out of bounds (ASan flags a heap over-read in `cv::Mat::copyTo`). The same mismatch is present in every datatype branch and for both the typed-field and `rawdata` sources, reachable from `readNetFromONNX`/`readNetFromONNXBuffer` for every initializer.
### After
Compute the element count the shape implies once, then check each payload source holds at least that many elements before the read. `getTensorRAWData()` now reports the byte count it returns (covering both `raw_data` and external-file data), and `getMatFromTensor()` validates the typed fields and the raw byte count per datatype. A short payload throws a clear `cv::Exception` instead of over-reading.
### Tradeoffs
The check lives in `getMatFromTensor` because that is the one place the shape and the payload meet, so every initializer and attribute tensor is covered without each caller repeating it. The added cost is one multiply-accumulate over the dims plus a comparison per tensor at load time; well-formed models, where the payload already matches the shape, are unaffected. The element-count accumulation saturates on overflow so an oversized shape can't wrap to a small total and slip past the check.
### 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
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
- [ ] The feature is well documented and sample code can be built with the project CMake
fix MSVC warning for minMaxIdx_simd #29379
### 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
fixed Dynamic quantized linear layer error #29386
### 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 signmask+popcount only in AVX-512 dispatch units; keep the legacy
batched SIMD kernels for AVX2, NEON, and LASX to avoid regressions on
narrow SIMD widths.
Perf test for gemm #28706
OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1336
- Added perf test to verify gemm performance.
- small sizes, square & rectangular matrix shapes are added.
- special case of n=1 and m=1 are added.
### 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
The first-class-language OpenCV CMake config (OpenCVConfig-CUDALanguage.cmake.in)
pinned the consumer's CUDA Toolkit to the exact patch version OpenCV was built
with (e.g. 12.3.107), via find_package(CUDAToolkit ... EXACT) and a full
VERSION_EQUAL check. Patch versions change frequently while the CUDA runtime API
is stable within a minor release, so this forced needless rebuilds and could
FATAL_ERROR even for a matching toolkit.
Per the core team's direction on #26966, the change lives in the installed
config template rather than the build scripts, and is controlled by a
consumer-set variable:
- Default: match major.minor only (fixes the reported patch-pinning bug).
- OPENCV_STRONG_CUDA_VERSION_CHECK: restore the exact full-version match.
The build-time detection (OpenCVDetectCUDALanguage.cmake) is left untouched, so
OpenCV_CUDA_VERSION still records the full version for diagnostics.
Fixes#26965
Vectorize the per-sample squared-Euclidean distance in
BruteForceImpl::findNearestCore with universal intrinsics (two
independent v_fma accumulators + scalar tail). The scalar reduction
accumulates in float in strict order, which the compiler cannot
auto-vectorize without -ffast-math; independent SIMD accumulators
break that serial-accumulation dependency.
Accumulates in float exactly as before (only summation order changes,
~1e-7, below stored float precision); selected neighbors and distances
matched scalar on all test data, ML_KNearest tests pass. Real
findNearest A/B: 3.76x M4, 3.47x Threadripper, 3.73x Xeon, 4.10x A76,
2.82x A55 (in-order).
Adds modules/ml/perf with a findNearest perf test.
Migrate the ushort specialization from CV_SIMD128 to (CV_SIMD ||
CV_SIMD_SCALABLE), enabling AVX2/AVX512/RVV widths instead of 128-bit only.
uchar specialization left at CV_SIMD128 — initial migration regressed on
RVV (Muse Pi v3.0, 0.77~0.85x) when vlanes16 == TILE_SIZE collapses the
SIMD loop to one iteration and per-tile setup overhead dominates.
- replace v_int32x4/v_uint32x4/v_uint64x2 with scalable v_int32/v_uint32/v_uint64
- iota vector in static const sized by VTraits::max_nlanes (initialized once at program load)
- drop buf64; use v_reduce_sum(v_uint64) directly (defined on all backends)
- vx_cleanup() at operator() tail for RVV vsetvl hygiene
Teddy-Yangjiale
Uwez Khan
Madan mohan Manokar
Abhishek Gola
Alexander Smorkalov
Saravana Balaji Mohan Balaji
Fedorov, Andrey
Vincent Rabaud
ZC
Anshu
Jonas Perolini
Tonu Samuel
Mulham Fetna
uwezkhan
Tõnu Samuel
정상원
Alexander Smorkalov
Prasadayus
Ijtihed Kilani
Savya Sanchi Sharma
WalkingDevFlag
kjg0724