Fix issues with MultiViewTest.OneLineInitialGuess and MultiViewTest.OneLine #28817
To fix issues caused by https://github.com/opencv/opencv/issues/28789
This probably can be fixed for 4.x, but honestly I don't believe it is worth it to have to deal with users tests failing because it was 0.02% off so we can save them like 2 minutes, so I believe it is best to leave the optimization for 5.x.
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
Fix flatten onnx axis==rank case #28812
fix ONNX Flatten layer incorrect output when axis equals input rank edge case
Resolves : https://github.com/opencv/opencv/pull/28781#discussion_r3060088247
OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1342
### 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 Qwen2.5 tokenizer support for dnn #28781
OpenCV extra: https://github.com/opencv/opencv_extra/pull/1334
Extended the dnn tokenizer support to qwen2.5 tokenization.
- Add QWEN2_5 pre-tokenizer regex pattern to utils.hpp
- Generalised buildTokenizerGPT to buildTokenizerFromJson to handle gpt2/gpt4/ and qwen2.5
- Add qwen2/qwen2.5 model type support with special token handling
- Add Qwen2.5 tests
- Add end-to-end qwen_inference script for Qwen2.5 ONNX model
### 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 fusion for activation functions in new DNN engine #28750
After this fusion, we see following improvements in YOLO models:
| Model | Before (`ENGINE_NEW`) | After (`ENGINE_NEW`) | `ENGINE_ORT` | % Improvement (Before v/s After) |
| :--- | :--- | :--- | :--- | :--- |
| **YOLOv8n** | 18.89 ms| 12.06 ms| 12.15 ms| 36.16% |
| **YOLOv5n** | 17.12 ms| 9.29 ms| 9.23 ms| 45.73% |
| **YOLOX-S** | 38.78 ms| 25.56 ms| 25.16 ms| 34.09% |
Device details:
- Model name: Intel(R) Core(TM) i9-14900KS, x86, 32 Cores, ubuntu 24.04,
### 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
Int8 block layout support #28741
After this patch we got the following speed ups on **resnet50-qdq.onnx** model.
- Inference time now: **_~6.6ms_** (inference time using onnxruntime is ~5.7ms).
- Inference time before: _**~11.5ms**_ [after QDQ PR #28595]
- Speed up: _**~42.6% or 1.74x**_
- Device details:
- Model name: Intel(R) Core(TM) i9-14900KS, x86, 32 Cores, ubuntu 24.04,
### 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 OnnxRuntime GPU wrapper #28588
### 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
GSoC 2025: Add Tokenizer Support to DNN Module #27534
merge with https://github.com/opencv/opencv_extra/pull/1276
### Summary
This pull request introduces initial support for a tokenizer module under `modules/dnn/src/tokenizer` as part of Google Summer of Code 2025 (Project: Tokenization for OpenCV DNN).
### Status
- [x] Project structure in place
- [x] Initial BPE tokenizer loading
- [x] Regex splitting (in progress)
- [x] Encoding logic for GPT-2 tokenizer (in progress)
- [ ] Documentation (to be improved)
### Goals
The goal is to support Hugging Face-compatible tokenization (e.g., GPT-2) natively in C++ to be integrated with DNN inference pipelines.
The core pipeline lives in `dnn/src/tokenizer/core_bpe.hpp` and `dnn/src/tokenizer/encoding.hpp`. For Unicode handling I’m using `dnn/src/tokenizer/unicode.hpp`, which is adapted from llama.cpp.
### Feedback
Please share early feedback on:
- General design structure
- Integration strategy with `dnn`
- Code organization or naming conventions
### Reference
Project: https://summerofcode.withgoogle.com/programs/2025/projects/79SW6eNK
core(opencl): fix inplace transpose race by enforcing LLSS ordering via local barrier #28686
The former inplace transpose implementation allowed a reordering of global-memory operations across work-items. Specifically, the intended LLSS (Load–Load–Store–Store) access pattern could be reordered by the GPU into LSLS (Load–Store–Load–Store), causing partially written tiles to be observed by other work-items and producing incorrect output.
This patch introduces a tiled LDS-based algorithm and adds an explicit:
barrier(CLK_LOCAL_MEM_FENCE);
between the load and store phases.
### 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: fix segfault on 0-channel numpy array input #28747
### Pull Request Readiness Checklist
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
N/A: a Python unit test is added in `modules/python/test/test_mat.py`. No external test data required.
- [x] The feature is well documented and sample code can be built with the project CMake
N/A: this is a bug fix, not a new feature. No documentation update needed.
### Problem
Passing a numpy array with shape `(H, W, 0)` (0 channels) to any OpenCV function that accepts a `Mat` argument (e.g. `cv2.resize`, `cv2.warpAffine`, `cv2.blur`) causes a **segfault**.
**Reproducer:**
```python
import cv2
import numpy as np
arr = np.zeros((100, 100, 0), np.uint8)
cv2.resize(arr, (200, 200)) # segfault
```
### Root Cause
In `modules/python/src2/cv2_convert.cpp`, the numpy→Mat conversion checks channel validity only against `CV_CN_MAX` (upper bound):
```cpp
if (channels > CV_CN_MAX) // channels=0 passes this check
```
With `channels=0`, `CV_MAKETYPE(0, 0)` produces `type=-8`, which corrupts the Mat's internal type field and causes undefined behavior downstream.
### Fix
Extend the check to also reject `channels < 1`:
```cpp
if (channels < 1 || channels > CV_CN_MAX)
```
**After fix:**
```
cv2.error: src unable to wrap channels, invalid count (0, must be in [1, 512])
```
### Notes
- This affects all functions that accept a `Mat` input, not just `cv2.resize`
- The same bug exists in the `5.x` branch
- A 0-channel array has no valid OpenCV Mat representation; rejecting it with a clear error is the correct behavior and poses no backward-compatibility risk (the previous behavior was a crash)
Nms empty detection fix#28749
Requires opencv_extra: https://github.com/opencv/opencv_extra/pull/1330
### 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
videoio(gstreamer): fix timestamp drift and color negotiation on Apple #28535
This commit addresses two issues on macOS with Apple M3 hardware:
1. Replaces floating-point timestamp math with gst_util_uint64_scale_int to ensure nanosecond precision.
2. Explicitly forces I420 format in the encoding profile to prevent hardware encoder negotiation failure.
### 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
core: add NEON implementation for rotate function #28609
- This PR adds a NEON intrinsics-based implementation for the rotate function in matrix_transform.cpp for Windows-ARM64.
- The optimized implementation uses ARM NEON intrinsics to accelerate the internal transpose step used by the rotate function.
- In the x64 architecture, the rotate operation benefits from IPP-based optimized implementations. However, on ARM64, the execution falls back to the scalar implementation, which results in lower performance.
- To achieve performance parity with x64, a NEON-based SIMD implementation has been added for ARM64.
- After introducing these changes, the rotate function showed noticeable performance improvements on ARM64 platforms.
<img width="1009" height="817" alt="image" src="https://github.com/user-attachments/assets/8bec0041-b19c-4fc8-9103-532746224515" />
- [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
dnn: fix missing ONNX dispatch entries and RotaryEmbedding bugs #28714
- Wire RMSNormalization and RotaryEmbedding parsers into the ONNX dispatch map. Both parse functions were declared and implemented but never registered, causing the importer to fall through to the generic path and skip constant-folding of cos/sin caches.
- Fix NonMaxSuppression dispatch key typo ("NonMaxSuprression" -> "NonMaxSuppression") so the ONNX op name matches the registered layer class. Also fix the type string set inside the parser.
- Fix tautological self-comparison in RotaryEmbeddingLayer::getMemoryShapes (cos_cache_shape.dims == cos_cache_shape.dims -> sin_cache_shape.dims).
- Fix typo in RotaryEmbedding error message ("cos_cahe" -> "cos_cache").
### 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
dnn: fix Resize initNgraph for two-input case #28724
## Summary
Fixes the issue #28707
When a Resize/Upsample layer has two inputs, the data tensor and a reference tensor whose **shape** defines the output spatial size, the OpenVINO/NGRAPH backend's `initNgraph()` was ignoring `nodes[1]` entirely and relying solely on the `outHeight`/`outWidth` member variables.
These variables are set by `finalize()` from the pre-computed output blob dimensions. However, when the output shape is determined dynamically at runtime from the second input, `finalize()` sets them from the live tensor, but the OpenVINO backend calls `initNgraph()` to build a static compiled graph. If the member variables are 0 at that point, the compiled `Interpolate` node gets hardcoded with `{0, 0}` output dimensions, causing CV_Assert failure: {N,C,0,0} vs {N,C,H2,W2}
Fixes#28396 : out-of-bounds read in SIMD type conversion #28397Fixes#28396Fixes#27080
The vx_load_expand function in WASM intrinsics was using
wasm_v128_load which always loads a full 128-bit register
(16 bytes), even when the function only needed 8 elements.
For example, when converting uint8 to float32:
- vx_load_expand needs 8 uint8 elements
- But wasm_v128_load reads 16 bytes from memory
- This causes an 8-byte out-of-bounds read
### 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
Samaresh Kumar Singh
Rohan Mistry
Alexander Smorkalov
Vincent Rabaud
Varun Jaiswal
Alexander Smorkalov
Abhishek Gola
Jorge Velez
Lurie97
LHOOL1109
vrooomy
Prasad Ayush Kumar
Ahmad
pratham-mcw
Shiyu Xie
SamareshSingh
Anshu