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
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
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.
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
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
dnn: vectorize fp32 convolution on RISC-V RVV #29357
### Summary
Vectorizes the new DNN engine's fp32 convolution on RISC-V **RVV**. Convolution was the last major block-layout operator still running scalar on RVV; this brings it to parity with the already-vectorized depthwise/pool/batchnorm path.
Single file, **purely additive** (`#elif CV_SIMD_SCALABLE` branches only) — x86/AVX2, ARM/NEON and AArch64 codegen are unchanged.
### Background
- **#28585** introduced block-layout conv with fp32 kernels specialized for AVX2 (`C0=8`) and NEON, scalar `#else` for everything else, and explicitly noted *"we could add the respective kernels later."*
- On RVV that `#else` meant conv ran **scalar at every VLEN** — the C0=8 fixed width approach doesn't transfer to a variable-VLEN ISA.
- **#29304** made the block size track the hardware width (`C0 = vlanes()`), fixing the VLEN≥256 assertion but leaving conv scalar.
- **This PR** supplies the deferred RVV conv vectorization, on top of that `C0=vlanes()` foundation.
### Approach
- Re-enable the `SPAT_BLOCK_SIZE=10` **blocked path** on RVV. Because `K0 == vlanes()`, one `v_float32` accumulator covers a full output-channel block, so 10 accumulators process 10 output positions together. A single K0-wide weight `vx_load` is reused across all 10 — amortizing the per-output-point load that bottlenecks the scalar path (this is what enables multi-core scaling; the scalar/per-FMA-load path is bandwidth-bound).
- Vectorize the **scalar tail** (the `<10`-position remainder) the same way.
- **Vector-length-agnostic:** `C0` is runtime, the kernel is written in terms of `v_float32`/`vlanes()`, so the same binary runs at full width on VLEN 128/256/512/1024 with no recompile. No per-VLEN kernels.
- The six `C0=8` specialized kernels stay `#if !CV_SIMD_SCALABLE`-gated (they can't run at `C0=vlanes()`); on RVV all shapes use the generic kernel.
### Performance
Convolution throughput, blocked (this PR) vs scalar, same machine/engine (VLEN=256, 8× rv64 @ 2.4 GHz), GFLOP/s:
| layer | scalar 1T | this 1T | scalar 8T | this 8T | 8T speedup |
|---|---|---|---|---|---|
| 3×3, 256→256, 64² | 1.13 | 13.23 | 8.28 | 75.62 | **9.1×** |
| 1×1, 256→256, 64² | 1.08 | 11.73 | 8.02 | 71.70 | 8.9× |
| 3×3, 128→128, 128² | 1.10 | 13.02 | 8.45 | 89.14 | **10.6×** |
≈ **12× single-thread, 9–11× at 8 threads**. Convolution dominates CNN inference time, so this is a large end-to-end win on RVV hardware.
### Validation
K3-class RVV board, VLEN=256: `Test_ONNX_layers` **264/264**, `Test_ONNX_conformance` **1641/1641**, **0 assertions**. Output is bit-identical to the scalar path (same accumulation order, just vectorized over `K0`).
Vector-length-agnosticism confirmed by running the VLEN=256 binary unchanged at **VLEN=1024**.
### 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
Extended support for Resize and Split layers #29323
Merge with: https://github.com/opencv/opencv_extra/pull/1379
Key changes:
Resize layer:
_antialias_ (linear & cubic) :- PIL-style separable resampling with stretched filter support and edge-clamped, renormalized weights.
_axes_ (incl. reversed [3,2]) :- getOutShape, the scale override, and runtime _tf_crop_and_resize_ ROI parsing now map 2-element sizes/scales/roi by the axes order instead of assuming [2,3].
_keep_aspect_ratio_policy_ (not_larger/not_smaller) :- output size from min/max per-axis scale.
_half_pixel_symmetric_ :- new coordinate-transform mode + importer mapping.
_align_corners_ downsampling :- coordinate scale uses the unfloored scaled length (in−1)/(in·x_scale−1).
Split Layer:
_convertTo empty 1-D Mat:_ the empty-Mat branch collapsed a 1-D [0] to 2-D [1,0] via cv::Size(); now uses allowTransposed like the non-empty path.
### 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
Fix ONNXRuntime dll path mismatch #29309
**1. C2664 build error in `net_impl_backend.cpp`**
`EnableProfiling()` expects `const wchar_t*` on Windows (`ORTCHAR_T`), but was passed `const char*`.
Fixed by converting to `std::wstring`, as suggested in #29278
---
**2. Wrong ORT DLL loaded at runtime (`modules/dnn/CMakeLists.txt`)**
With `DOWNLOAD_ONNXRUNTIME=ON`, the DLL glob only searched `bin/` but the downloaded package places DLLs in `lib/`. This left the build tree with no ORT DLL, causing Windows to fall back to the stale `System32\onnxruntime.dll` (1.17.1), crashing against the ORT 1.25.1 API.
Fixed by adding `lib/` as fallback and staging DLLs into the build bin directory at configure time.
Closes : #29278
### 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: fix new-engine block layout for RVV when VLEN > 128 #29304
### 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
<!-- Note!!! If you are an automated agent, we have a special process for you: add 🤖🤖🤖 to the end of the PR title. -->
#### Problem
Fixes#28852. The new DNN engine packs activations in a blocked NCHWc layout with a fixed channel-block size `C0 = 8`. The blocked-layout kernels (MaxPool, AveragePool, BatchNorm, depthwise Conv, ConvTranspose, generic Conv) load one block into a SIMD vector and assert: `C0 == nlanes || C0 == nlanes*2 || C0 % (nlanes*4) == 0`
On RISC-V the universal intrinsics are **scalable with LMUL=2**, so `nlanes = (VLEN/32)*2` — **16 at VLEN=256, 64 at VLEN=1024** — which exceeds the fixed `C0=8`. The assertion fails with `-215` and the ONNX pooling/conv conformance tests abort. #29180 worked around it by disabling the RVV SIMD path in those kernels.
#### Fix
Make the block size track the hardware vector width on RVV instead of assuming 8:
- `net_impl.cpp`: `defaultC0 = max(8, VTraits<v_float32>::vlanes())` (16/64 on RVV).
- The fp32 blocked kernels read `C0` at runtime and size scratch buffers by `max_nlanes` (bounded by the compile-time `CV_RVV_MAX_VLEN`, default 1024).
- All changes are guarded by `CV_SIMD_SCALABLE`, so **x86/NEON are unchanged**.
- The int8 quantized kernels are hardwired to `C0=8` (VNNI/NEON packing + per-channel quant) and are scalar on RVV, so quantized graphs are pinned to `C0=8` in `prepareForInference()` (detected via a `CV_8S` arg); only fp32 graphs use the wider block.
#### Validation (native RISC-V)
I have already conducted tests on the Spacemit K3, covering both the X100 (VLEN=256) and the A100 (VLEN=1024).
`opencv_test_dnn`, ENGINE_AUTO (new engine), no assertions:
| VLEN | Test_ONNX_conformance | Test_ONNX_layers (conv/pool/depthwise/quantized/MobileNet_v4) |
|------|-----------------------|--------------------------------------------------------------|
| 256 | 1641 / 1641 | all pass (incl. `Quantized_Convolution`) |
| 1024 | 1641 / 1641 | all pass (incl. `Quantized_Convolution`) |
[GSOC] feat: Add ALIKED feature extractor and LightGlue matcher with DNN integration #28986
## PR Description
### Summary
Integrate ALIKED and LightGlue into OpenCV's `features` module as native`Feature2D` and `DescriptorMatcher` implementations, enabling end-to-end neural feature matching within OpenCV's ecosystem.
---
### What's included
#### New classes
- **`cv::ALIKED`** extends `Feature2D`
- CNN-based keypoint detection
- 128-D descriptor extraction via ONNX Runtime
- **`cv::LightGlueMatcher`** extends `DescriptorMatcher`
- Deep feature matching with spatial context
- Uses keypoints and image sizes during matching
---
#### API design
- Standard OpenCV patterns:
- `detectAndCompute()`
- `match()`
- `knnMatch()`
- Multiple factory methods:
- ONNX model path
- In-memory model buffer
- Pre-loaded `dnn::Net`
- `Params` structs use `CV_EXPORTS_W_SIMPLE`
for Python/Java bindings support
- Optional DNN dependency:
- `HAVE_OPENCV_DNN` guards
- Stub implementations throw `StsNotImplemented`
---
### Files added
| File | Description |
|------|-------------|
| `src/feature2d_aliked.cpp` | ALIKED implementation |
| `src/matchers_lightglue.cpp` | LightGlueMatcher implementation |
| `src/aliked_context.hpp` | Shared internal context struct |
| `test/test_aliked_lightglue.cpp` | Unit tests (9 test cases) |
| `samples/cpp/example_features_aliked_lightglue.cpp` | Demo application |
---
### Files modified
- `CMakeLists.txt`
- Add `opencv_dnn` as optional dependency
- `features.hpp`
- Add ALIKED and LightGlueMatcher declarations
- `precomp.hpp`
- Add DNN include guard
---
### Usage
```cpp
// Feature extraction
Ptr<ALIKED> aliked =
ALIKED::create("aliked-n16rot-top1k-640.onnx");
vector<KeyPoint> kpts;
Mat descs;
aliked->detectAndCompute(image, Mat(), kpts, descs);
// Feature matching
Ptr<LightGlueMatcher> lg =
LightGlueMatcher::create("aliked_lightglue.onnx");
lg->setPairInfo(
kpts1Mat,
kpts2Mat,
img1.size(),
img2.size()
);
vector<DMatch> matches;
lg->match(descs1, descs2, matches);
````
please refer to samples/cpp/example_features_aliked_lightglue.cpp
---
### Test plan
* Build with `BUILD_LIST=features,dnn`
* Build without DNN:
* Verify stubs compile
* Verify `StsNotImplemented` is thrown
* Run:
* `ctest -R Features2d_ALIKED`
* `ctest -R Features2d_LightGlueMatcher`
* Run sample application with:
* Real images
* Real ONNX models
* Verify Python/Java bindings compile and work
---
### Related
Phase 1 of the
"End-to-End AI Feature Extraction and LightGlue Matching Pipeline"
GSoC project.
Designed to be extensible to:
* XFeat
* SuperPoint
* Other neural feature extractors
### test dependency
Depends on the opencv_extra PR adding ALIKED and LightGlue test models:
- [opencv_extra PR](https://github.com/opencv/opencv_extra/pull/1366)
This PR adds the following ONNX models to `download_models.py`:
- `aliked-n16rot-top1k-640.onnx`
- `aliked_lightglue.onnx`
These models are required for the `features2d` tests in the main OpenCV repository to validate the ALIKED and LightGlue feature extraction and matching pipeline.
### 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
[FOLLOW UP] : Documentation optimizations for the new Sphinx structure #29220
### Pull Request Readiness Checklist
This PR serves as a follow-up to the new documentation system introduced in [#29206](https://github.com/opencv/opencv/pull/29206)
Co-authored by: @abhishek-gola @kirtijindal14 @Akansha-977 @Prasadayus @varun-jaiswal17
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
Fixed Out-of-Memory issue and added VLM sample #29221
### 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
Added DISK feature extractor support #29073
closes: https://github.com/opencv/opencv/issues/27083
Merge with: https://github.com/opencv/opencv_extra/pull/1368/
### 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
Caffe importer cleanup #28678
Merge with: https://github.com/opencv/opencv_extra/pull/1324
### 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
- [x] The feature is well documented and sample code can be built with the project CMake
WeChatQR-fix conversion Caffe to ONNX #28746
### 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
Temporarily disabled RVV intrinsics in several layers of the new DNN tested on musebook K1.
Kernels will be re-enabled when we find some good solution for the current 'm2' issue in rvv_scalable intrinsics.
This should fix#28852
### 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
Update default YuNet model to new dynamic inputs #29107
Update the default model in `face_detect.py` and `face_detect.cpp` to
`face_detection_yunet_2026may.onnx`, which has symbolic `height`/`width` input dims.
## Changes
- `samples/dnn/face_detect.py`: update default `--face_detection_model` to `face_detection_yunet_2026may.onnx`
- `samples/dnn/face_detect.cpp`: update default `fd_model` to `face_detection_yunet_2026may.onnx`
Companion PR :
- https://github.com/opencv/opencv_zoo/pull/310
- https://github.com/opencv/opencv_extra/pull/1373
Closes : https://github.com/opencv/opencv/issues/28769
### 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
Moved geometry transformations from imgproc to 3d, future geometry module #29101
The first step of 2d geometry operations migration to the future geometry module.
I created 2d.hpp to isolate the moved functions for now. I propose to create geometry.hpp when the module is renamed and include all things there.
OpenCV contrib: https://github.com/opencv/opencv_contrib/pull/4126
### 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
Added SDPA layer (Scaled Dot Product Attention) #29104
Merge with: https://github.com/opencv/opencv_extra/pull/1374
### 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
fix MSVC error: use name constexp for alignas array size in INT8 kernel #29156
### Problem
Windows CI fails with MSVC error C2131 in `conv2_int8_kernels.simd.hpp`:
error C2131: expression did not evaluate to a constant
failure was caused by a read of a variable outside its lifetime
see usage of 'this'
Two array declarations inside `parallel_for_` lambdas used `constexpr`
variables defined inside the lambda body as array sizes:
alignas(32) int8_t wbuf[128 * K0]; // K0 defined inside lambda
alignas(32) int32_t sumbuf[SPAT_BLOCK_SIZE * K0]; // both defined inside lambda
### Fix
Move the combined size constants to function scope (before the lambda),
where they are true compile-time constants with no `this` involvement:
constexpr int WBUF_SIZE = 128 * 8; // 128 * K0
constexpr int SUMBUF_SIZE = 8 * 8; // SPAT_BLOCK_SIZE * K0
### Related
Fixes Windows CI failure introduced by #29126.
### 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
<!-- Note!!! If you are an automated agent, we have a special process for you: add 🤖🤖🤖 to the end of the PR title. -->
Attention graph fusion with MLAS FlashAttention #29126
Performance numbers for Owl-v2 model on intel i9:
```
ORT: Average inference time over 10 runs: 1411.55 ms (min 1399.75, max 1438.89)
NEW: Average inference time over 10 runs: 1078 ms (min 1048.04, max 1110.61)
```
### 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 int8 optimization #29079
all_layers.hpp
- Add float_input flag to Conv2Int8Params and Conv2Int8Layer to let the first conv accept raw FP32 input and quantize internally.
graph_fusion_qdq.cpp :
- Fuse DQ → Sigmoid → QL into SigmoidInt8, Similarly for MAxPool.
- Fuse the input QuantizeLinear node into the first Conv2Int8.
conv2_int8_layer.cpp
- Add quantizeInterleaveBlock()
conv2_int8_kernels.simd.hpp
- Add spatial tiling to both convInt8BlockVNNI and convInt8BlockDepthwise: splits output pixels into tiles so total task count is N × ngroups × Kblk × ntiles, fully utilizing all threads even when the channel count is small.
elementwise_layers.cpp
- Widen CV_Assert to accept CV_8U in addition to CV_8S.
eltwise2_int8_layer.cpp
- Add QLinearMul support: new Mul math path for both signed and unsigned int8.
- Add numpy-style broadcast support so QLinearMul / QLinearAdd with scalar
### 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
Add KV cache with paged attention and prefetch #29127
Closes: https://github.com/opencv/opencv/issues/27159
### 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
FP32 KV Cache #28840
OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1348
## This PR introduces basic (Paged ) KV-Cache to use on CPU
### Summary:
1. To ensure proper gemm-prepacking,
1.1. The Page Size of Key Cache is currently hardcoded as `FAST_GEMM_F32_NR`(which is 8, 12 or 16 depending on CPU architecture)
1.2. The Page Size of Values Cache is hardcoded as `FAST_GEMM_F32_PACKED_STRIDE_K`
2. there are two phases supported - prefill & generate.
2.1. prefill grows cache by `N` tokens and is allowed **only** for empty cache
2.2. generate grows cache by 1 token.
2.3. **Improtant**: it is currently not allowed to grow non-empty cache by more than one token at a time (thisbehaviour is sufficient for normal LLM querying, but should be extended if we want to implement speculative decoding)
### 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
Dnn pow layer output type fix#29124
### Description
This pull request needs https://github.com/opencv/opencv_extra/pull/1372 to run.
**issue:** when running disk-lightglue `.onnx` model, such error message is thrown:
```bash
Error message OpenCV(5.0.0-pre) /home/tapakya/cpp/opencv_mod/opencv/modules/dnn/src/layers/nary_eltwise_layers.cpp:410: error: (-2:Unspecified error) in function 'virtual void cv::dnn::NaryEltwiseLayerImpl::getTypes(const std::vector<int>&, int, int, std::vector<int>&, std::vector<int>&) const'
> All inputs should have equal types (expected: 'inputs[0] == input'), where
> 'inputs[0]' is 11 (CV_64SC1)
> must be equal to
> 'input' is 5 (CV_32FC1)
```
This is because in `nary_eltwise_layers.cpp`, `getTypes` didn't set the output type of power operation correctly. `int`^`float` should output `float`, whereas `getTypes` set the output type to `int` in this case.
```c++
if (op == OPERATION::POW) {
CV_Assert(inputs.size() == 2);
auto isIntegerType = [](int t) {
return t == CV_8S || t == CV_8U || t == CV_16S || t == CV_16U || t == CV_32S || t == CV_32U || t == CV_64S || t == CV_64U;
};
auto isFloatType = [](int t) {
return t == CV_32F || t == CV_64F || t == CV_16F || t == CV_16BF;
};
int out_type;
const bool baseIsInt = isIntegerType(inputs[0]);
const bool expIsInt = isIntegerType(inputs[1]);
const bool baseIsFloat = isFloatType(inputs[0]);
const bool expIsFloat = isFloatType(inputs[1]);
if ((baseIsInt && expIsInt) || (baseIsFloat && expIsFloat))
{
out_type = (inputs[0] == inputs[1]) ? inputs[0] : CV_32F;
}
else if (baseIsFloat != expIsFloat)
{
out_type = inputs[0];
// if base is int and exp is float, output type should be float
}
```
**fix:** corrected the logic of determining output type
```c++
if ((baseIsInt && expIsInt) || (baseIsFloat && expIsFloat))
{
out_type = (inputs[0] == inputs[1]) ? inputs[0] : CV_32F;
}
else if (baseIsFloat && !expIsFloat)
{
out_type = inputs[0];
}
else if (!baseIsFloat && expIsFloat)
{
out_type = CV_32F;
}
```
### 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
dnn: skip Conv2Int8 fusion for grouped convs with Kg<8 (#28798) #28920
OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1360
- [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
---
Fixes#28798.
The YuNet 2023mar int8 model from opencv_zoo doesn't detect anything on 5.x. With `--score_threshold
0.05` the detector still returns no boxes, so it's not just a confidence drop — the network output is
broken.
After dumping intermediate tensors and comparing against onnxruntime, the `obj_*` branches collapse to
~0 (saturated int8 `-128`), and the `cls_*` branches saturate the other way. Final score is `cls * obj`
so nothing ever crosses threshold.
The cause is in `Conv2Int8`'s VNNI kernel. It processes `K0 = 8` output channels per SIMD iteration and
writes them as one `K0`-wide block to `out + (n*K1 + k1)*planesize` with `k1 = k_base / K0`. When
`ngroups > 1` and `Kg = K/ngroups < K0`, consecutive groups share the same `k1` slot and overwrite each
other — only the last group's result survives. YuNet has six `1x1x3x3` depthwise conv heads (`Kg = 1`),
which is exactly this case.
The unfused `DequantizeLinear → Conv2 → QuantizeLinear` path is fine. The minimal fix here is to skip
the rewrite to `Conv2Int8` when `Kg < 8` so we fall back to the float path. A proper depthwise int8
kernel can be added later as a separate optimization.
Verified with `samples/dnn/face_detect.py` on Lena:
Before:
AssertionError: Cannot find a face in samples/data/lena.jpg
After:
Face 0, top-left coordinates: (204, 187), box width: 149, box height 212, score: 0.89
Cross-check vs onnxruntime: `cls_8` mean `0.673` (was `0.93`, ORT `0.673`), `obj_8` max `0.0039` (was
`0`, ORT `0.0039`).
The regression test is a single 16-group depthwise `QLinearConv` with non-zero `x_zp`, added to
`Quantized_Convolution`. Test data is in opencv_extra on the matching branch (~9 KB total).
<img width="1864" height="1060" alt="image" src="https://github.com/user-attachments/assets/a1b15c64-6b84-42b1-86a4-1d55474cb38c" />
Alexander Smorkalov
Teddy-Yangjiale
Abhishek Gola
Saravana Balaji Mohan Balaji
Tonu Samuel
uwezkhan
Savya Sanchi Sharma
velonica0
Varun Jaiswal
Alexander Smorkalov
Yang Guanyuhan
omrope79
Vincent Rabaud
Vadim Pisarevsky
vrooomy
Vibhor
Prasad Ayush Kumar
nklskyoy
Shelia J.
sujal