Better Durand-Kerner Initialization #29109
While investigating issue #23644, I have found [this paper](https://link.springer.com/article/10.1007/BF01935059) which presents a good initialization for the Durand-Kerner algorithm. Basically the idea is to put the initial points equidistantly on a circle on the complex plane. The radius of the circle is computed as
<img width="607" height="178" alt="image" src="https://github.com/user-attachments/assets/ea31b002-c924-4b93-9334-3e59597c896b" />
Note that the $a_i$ coefficients in that paper are reversed compared to OpenCV. That's where the `(n - i)` in the code comes from.
I have implemented just the mean of the $u_i$'s for the sake of simplicity. That's already enough to make the algorithm converge in all cases I have tested. I have used this to test for convergence for many polynomials of order 2 and 4 and coefficients of different magnitudes:
```cpp
TEST(Core_SolvePoly, large_test)
{
cv::Mat_<float> coefs3(1,3);
cv::Mat_<float> coefs5(1,5);
cv::Mat r;
double prec;
for (int c0 = -20; c0 <= 20; c0++)
{
coefs3.at<float>(0) = c0;
for (int c1 = -20; c1 <= 20; c1++)
{
coefs3.at<float>(1) = c1;
for (int c2 = -20; c2 <= 20; c2++)
{
coefs3.at<float>(2) = c2;
prec = cv::solvePoly(coefs3, r);
EXPECT_LE(prec, 1e-6);
}
}
}
for (int c0 = -10; c0 <= 10; c0++)
{
coefs5.at<float>(0) = c0;
for (int c1 = -10; c1 <= 10; c1++)
{
coefs5.at<float>(1) = c1;
for (int c2 = -10; c2 <= 10; c2++)
{
coefs5.at<float>(2) = c2;
for (int c3 = -10; c3 <= 10; c3++)
{
coefs5.at<float>(3) = c3;
for (int c4 = -10; c4 <= 10; c4++)
{
coefs5.at<float>(4) = c4;
prec = cv::solvePoly(coefs5, r);
EXPECT_LE(prec, 1e-2);
}
}
}
}
}
for (int i = -10; i < 10; i++)
{
coefs3.at<float>(0) = pow(2, i);
for (int j = -10; j < 10; j++)
{
coefs3.at<float>(1) = pow(2, j);
for (int k = -10; k < 10; k++)
{
coefs3.at<float>(2) = pow(2, k);
prec = cv::solvePoly(coefs3, r);
EXPECT_LE(prec, 1e-6);
}
}
}
}
```
This test passes, but I have not committed it because it runs for a couple of seconds.
This fixes#23644 and replaces #29055. I have checked #29055 and it does not pass the test above. It seems to be optimized to the precise polynomial of #23644.
### 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(mjpeg): fix heap-buffer-overflow in put_bits off-by-one resize guard #29113
### Summary
Fix a heap-buffer-overflow (WRITE of size 4) in the built-in MJPEG encoder detected by AddressSanitizer during fuzzing.
Fixes#29112
### Root Cause
`mjpeg_buffer::put_bits` in `modules/videoio/src/cap_mjpeg_encoder.cpp` guards buffer resize with:
```cpp
if ((m_pos == (data.size() - 1) && len > bits_free) || m_pos == data.size())
resize(int(2 * data.size()));
```
When `len == bits_free` the guard is **false** (strict `>`), so no resize happens. The subsequent code then:
1. Subtracts `len` from `bits_free`, making it exactly 0.
2. Enters the `bits_free <= 0` branch and executes `++m_pos`.
3. Writes `data[m_pos]` — now equal to `data[data.size()]` — **out of bounds**.
### Fix
Change `len > bits_free` to `len >= bits_free` so the buffer is grown whenever the current slot will be exactly or more than consumed.
```diff
-if ((m_pos == (data.size() - 1) && len > bits_free) || m_pos == data.size())
+if ((m_pos == (data.size() - 1) && len >= bits_free) || m_pos == data.size())
```
### Verification
Reproducer (1×1 grayscale frame, `CAP_OPENCV_MJPEG`):
```cpp
uint8_t pixel = 0xff;
cv::Mat frame(1, 1, CV_8UC1, &pixel);
int fourcc = cv::VideoWriter::fourcc('M', 'J', 'P', 'G');
cv::VideoWriter writer;
writer.open("/tmp/poc.avi", cv::CAP_OPENCV_MJPEG, fourcc, 25.0, cv::Size(1,1), false);
writer.write(frame);
```
Ran under `-fsanitize=address,undefined`; exits cleanly with no error after this fix.
### Regression Test
`TEST(Videoio_MJPEG, put_bits_no_heap_overflow)` added to `modules/videoio/test/test_video_io.cpp` — opens a `CAP_OPENCV_MJPEG` VideoWriter for a 1×1 grayscale file and writes one frame; asserts `EXPECT_NO_THROW`.
Added MLAS third party module and integrated into GeMM path #28934
### 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 int32 overflow in shape_utils::total() for large tensors #29093
Fixes https://github.com/opencv/opencv/issues/24914
### Problem
When running inference with a ConvTranspose (deconvolution) layer on large inputs
(e.g. 4864×4864 with 30 channels), the DNN module crashes with:
OpenCV net_impl.cpp: error:
(expected: 'total(ints[i]) > 0'), where
'total(ints[i])' is -1455947776
must be greater than
'0' is 0
The root cause is `shape_utils::total()` which returns `int` (32-bit signed).
`ENGINE_CLASSIC` catches this via `CV_CheckGT` and throws.
`ENGINE_NEW` was silently bypassing the check — the overflow in `total()` itself
was never addressed.
### Changes
**`modules/dnn/include/opencv2/dnn/shape_utils.hpp`** — root fix
- Changed return type of both `total()` overloads from `int` to `size_t`
- Changed accumulator from `int elems = 1` to `size_t elems = 1`
**`modules/dnn/src/net_impl.cpp`**
- Updated `CV_CheckGT(total(...), 0)` to `CV_CheckGT(total(...), (size_t)0)`
to match the new return type
**`modules/dnn/src/net_impl2.cpp`**
- Added the same `CV_CheckGT` shape validation that `ENGINE_CLASSIC` has in
`net_impl.cpp:1333-1337` — `ENGINE_NEW` was missing this check entirely
**`modules/dnn/src/legacy_backend.hpp`**
- Removed the now-incorrect `(int)` cast in `CV_CheckEQ` — both sides are
now `size_t`
### Test
Added `Net.ShapeUtils_total_no_int32_overflow` in `modules/dnn/test/test_misc.cpp`:
- The shape [1920 × 1,478,656] is the exact im2col buffer from the bug report.
EXPECT_EQ verifies total() returns the correct size_t value 2,839,019,520.
EXPECT_LT documents that casting it to int wraps to -1,455,947,776 — the
value that caused the original crash.
### 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. -->
requires (YOLO26n , RetinaFace model download) : https://github.com/opencv/opencv_extra/pull/1357
added performance tests for 14 modern deep learning models to `modules/dnn/perf/perf_net.cpp.`
**Tests added**
- RT_DETR_L
- RF_DETR
- Grounding_DINO
- BlazeFace
- RetinaFace
- YOLO26n
- YOLO26m_Seg
- SegFormer_B2_Clothes
- Depth_Anything_V2
- SigLIP
- OWLv2
- RAFT
- SAM2_Encoder
- SAM2_Decoder
Models are available at: https://drive.google.com/drive/folders/1lpYAWSLMtxcmfDtYjiw0qwzZX0bCH-i4
### 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 missing DataLayout constants in generated bindings for 5.x #29074
- Added DATA_LAYOUT_* constants to missing_consts so they
are manually injected into Core.java (same approach used for CV_8U, FILLED etc.)
- Added DataLayout entry to type_dict so the generator correctly maps
DataLayout
### Tests
modules/dnn/misc/java/test/DnnBlobFromImageWithParamsTest.java:
New test added:
- testDataLayoutConstants: verifies all DATA_LAYOUT_* constants are accessible from Core
Pre-existing tests enabled (were commented out earlier):
- testBlobFromImageWithParamsNHWCScalarScale: verifies blobFromImageWithParams
produces correct output with DATA_LAYOUT_NHWC and per-channel scalar scaling
- testBlobFromImageWithParams4chMultiImage: verifies blobFromImagesWithParams
correctly handles a batch of images with DATA_LAYOUT_NHWC layout
Closes : #27264
### 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
[Bug Fix] Slice2 empty-range crash in new DNN engine#29029
Closes: https://github.com/opencv/opencv/issues/29023
Merge with: https://github.com/opencv/opencv_extra/pull/1363
## Summary
ENGINE_NEW asserted `CV_Assert(outsz >= 0)` in `slice2_layer.cpp` when an ONNX Slice op had `start > end` with positive step. Per ONNX spec, such slices are valid and
produce an empty-range output (size 0). The hard assertion crashed SwinIR inference on ENGINE_NEW.
## Fix
- Replaced the fatal assertion with a graceful clamp: when `outsz < 0`, set `outsz = 0` and `end = start`.
- Moved `allEnds[axis] = end` to after the clamp so downstream shape inference receives a consistent value (the previous order propagated un-clamped garbage end values
into `normalize_axis()`, causing SIGSEGV).
## Test
Adds `Reproducibility_SwinIR_ONNX` accuracy test in `test_model.cpp`. Test data registered in opencv_extra PR with matching branch name `fix/dnn-slice2-empty-range`.
- Without fix: 3/3 FAIL with `slice2_layer.cpp:124: (-215:Assertion failed) outsz >= 0`
- With fix: 3/3 PASS (CPU, OCL, OCL_FP16)
### 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
SIMD Kernel speedup for DNN layers #28889
This PR add following speedups for Grounding Dino tiny model.
For Device: Intel(R) Core(TM) i9-14900KS, x86, 32 Cores, ubuntu 24.04,
| Model | `ENGINE_NEW (Before)` | `ENGINE_NEW (After)` | `ENGINE_ORT` |
| :--- | :--- | :--- | :--- |
| **Grounding Dino Tiny** | 3130 ms | 1872.06 ms| 1800.18 ms|
### 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
core(rvv): fix v_matmul/v_matmuladd scalable semantics and expand lane-group test coverage #29080
### 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. -->
## Platform
SpacemiT X60 (K1), 8-core RISC-V RVV 1.0, VLEN=256, 16GB RAM, OS: Bianbu Linux (kernel 6.6.63), GCC 13.2.0, Build: OpenCV 4.14.0-pre, Release, HAL: YES (RVV HAL 0.0.1)
## Motivation
OpenCV's Universal Intrinsics `v_matmul` and `v_matmuladd` have a semantic bug in the RVV scalable backend (`modules/core/include/opencv2/core/hal/intrin_rvv_scalable.hpp`).
The current implementation uses `v_extract_n(v, 0/1/2/3)` with hardcoded indices, assuming the vector holds exactly 4 float lanes (128-bit fixed). On hardware with VLEN=256 (e.g. SpacemiT K1 / BPI-F3), `v_float32` with LMUL=2 holds 16 lanes. As a result, lanes 4–15 silently reuse the inputs from lanes 0–3, producing wrong results.
OpenCV itself acknowledges this in `modules/core/src/matmul.simd.hpp`:
// v_matmuladd for RVV is 128-bit only but not scalable,
// this will fail the test Core_Transform.accuracy
The RVV scalable `transform_32f` path has been disabled because of this bug. However, the existing `TheTest<R>::test_matmul()` only checked the first 4-lane group (the outer loop was effectively hardcoded to `int i = 0`), so the bug was never caught by CI even on wide-vector backends.
## Modification
**Test fix** (`modules/core/test/test_intrin_utils.hpp`): Expanded `test_matmul()` to iterate over all 4-lane groups:
// Before (only checked lane group i=0)
int i = 0;
for (int j = i; j < i + 4; ++j) { ... }
// After (checks all lane groups)
for (int i = 0; i < VTraits<R>::vlanes(); i += 4)
{
for (int j = i; j < i + 4; ++j) { ... }
}
**Kernel fix** (`modules/core/include/opencv2/core/hal/intrin_rvv_scalable.hpp`): Rewrote `v_matmul` and `v_matmuladd` to process all 4-lane groups correctly. Each group of 4 lanes now independently computes the full matrix multiply using its own `v[i], v[i+1], v[i+2], v[i+3]` inputs. The `transform_32f` RVV path in `matmul.simd.hpp` remains disabled as the autovectorized path shows better performance on current hardware.
## Experiment 1: Bug reproduced on SpacemiT K1 (VLEN=256)
./opencv_test_core --gtest_filter="*intrin*"
Result: `hal_intrin128.float32x4_BASELINE` FAILED with 24 failures, all from lane groups i=4, i=8, i=12 (lanes 4–15).
Representative failures from `v_matmul` (line 1526):
i=4 j=4: actual=158 expected=56
i=4 j=5: actual=166.39999 expected=59.200001
i=8 j=8: actual=314.39999 expected=68.800003
i=12 j=12: actual=512.40002 expected=81.599998
Representative failures from `v_matmuladd` (line 1540):
i=4 j=4: actual=147.5 expected=51.5
i=8 j=8: actual=284.70001 expected=60.700001
i=12 j=12: actual=453.89999 expected=69.900002
Lane group i=0 (j=0..3) passed correctly — confirming the bug only affects lanes beyond the first 4, exactly as expected from the hardcoded `v_extract_n(v, 0/1/2/3)` implementation.
## Experiment 2: Both tests pass after fixing the kernel
./opencv_test_core --gtest_filter='hal_intrin128.float32x4_BASELINE'
[ OK ] hal_intrin128.float32x4_BASELINE (1859 ms)
[ PASSED ] 1 test.
./opencv_test_core --gtest_filter='Core_Transform.accuracy'
[ OK ] Core_Transform.accuracy (819 ms)
[ PASSED ] 1 test.
## Experiment 3: RVV transform path remains disabled (performance regression)
After re-enabling the RVV scalable `transform_32f` path experimentally, benchmarks showed a significant regression vs the compiler-autovectorized scalar path (CV_32FC3):
Size RVV path Scalar path Ratio
640x480 7.83 ms 1.48 ms 5.3x slower
1280x720 23.96 ms 5.17 ms 4.6x slower
1920x1080 53.76 ms 10.12 ms 5.3x slower
The compiler-autovectorized path outperforms the hand-written RVV kernel for this workload, consistent with the original comment in `matmul.simd.hpp`. The `transform_32f` RVV path is therefore kept disabled in this PR. The kernel fix to `v_matmul`/`v_matmuladd` remains necessary for correctness on wide-vector hardware, and the expanded test ensures the bug cannot regress silently in future.
Fixed gatherND offset calculation #29084
Bug fix: fixed segmentation fault when running ALIKED onnx model with ENGINE_NEW.
### Description
issue: when running ALIKED onnx model with ENGINE_NEW, segmentation fault happens during the inference.
fix: fixed the offset calculation in gatherND.cpp, so gather does not access out-of-bound memory.
### 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
KleidiCV update to verison 26.03 #28744
KleidiCV release: https://gitlab.arm.com/kleidi/kleidicv/-/releases/26.03
Tuned DNN test threshold as resize linear produces slightly different result with the new KleidiCV version.
### 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
randomnormallike_layer.cpp registered itself via CV_DNN_REGISTER_LAYER_CLASS_STATIC at file scope. Nothing else in the translation unit was referenced from elsewhere, so when OpenCV is built statically (BUILD_SHARED_LIBS=OFF, as in the reporter's MSVC build) the linker drops the object file and the static-init registration never runs. The ONNX importer then sets layerParams.type = "RandomNormalLike" but getLayerInstance has no factory for that type, and parsing fails with "Can't create layer of type RandomNormalLike".
Switch to the standard pattern used by every other layer in the module: declare RandomNormalLikeLayer in all_layers.hpp, expose a static create() factory from the .cpp, and register it explicitly from initializeLayerFactory in init.cpp. Because init.cpp is referenced by the DNN module init path, this pulls in the layer .cpp regardless of build mode and the registration always runs.
The failure was incorrectly attributed to MSVC in the bug report. The bug is build-mode sensitive (static vs shared), not platform sensitive.
Verified locally on linux/gcc-13 by building modules/dnn and
opencv_test_dnn against the patched tree, then running opencv_test_dnn --gtest_filter='Test_ONNX_layers.RandomNormalLike_basic/0:Test_ONNX_layers.RandomNormalLike_complex/0'
Both tests pass; without the patch the same binary reproduces the
"Can't create layer of type RandomNormalLike" error from the report.
Port of the 4.x patch to 5.x. Registers a new
ConsecutiveTransposePairsSubgraph in onnx_graph_simplifier.cpp's
simplifySubgraphs() so that consecutive Transpose nodes whose composed
permutation is identity are eliminated at the ONNX proto level. This
runs before either engine takes over, so both ENGINE_CLASSIC and
ENGINE_NEW benefit.
Equivalent optimizations exist in tf2onnx (TransposeOptimizer._transpose_handler)
and ONNX Runtime (HandleTransposeImpl, 'Permutations cancel' branch).
Update ArUco doc #28824
See https://github.com/opencv/opencv/pull/28823
Update of the ArUco doc but targeted for OpenCV 4.
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
core: add YAML 1.2 support for FileStorage #28482Fixes: #26363
CI Update: https://github.com/opencv/ci-gha-workflow/pull/306
Summary:
- Bool true/false literals support
- Header-less YAMLs support for Python YAML module compatibility. Header-less files are parsed as YAMLs by default
- Added FORMAT_YAML_1_0 flag to FileStorage for fallback.
- New YAML1.2 header
Testing:
- Added Core_InputOutput.YAML_1_2_Compatibility test case in test_io.cpp.
- Added YAML interop test in Python
imgproc: add kernel size validation in boxFilter #29040
Check that ksize dimensions are strictly positive in boxFilter(), returning StsBadSize error instead of producing undefined behavior.
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
Fixed subgraph name scoping in new DNN engine #28971
closes: https://github.com/opencv/opencv/issues/23663, https://github.com/opencv/opencv/issues/19977
OpenCV extra: https://github.com/opencv/opencv_extra/pull/1362
### 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
Rvv core norm #29057Fixesopencv/opencv#29052
### Problem
`Core_Norm/ElemWiseTest.accuracy/0` failed on RISC-V with RVV enabled when computing norm for `CV_16S` data.
The reported failing case was:
```text
src[0] ~ 16sC4 3-dim (1 x 116 x 40)
```
The expected norm result was a large positive `double`, but the RVV path returned an incorrect value:
```text
expected: 3370900308417
actual: -173296
```
This indicates that the problem was not in the public `cv::norm()` API, but in the RVV HAL implementation used for the `CV_16S` L2/L2SQR accumulation path.
### Root Cause
The RVV HAL has a specialized implementation for `CV_16S` L2 norm:
```cpp
NormL2_RVV<short, double>
```
The implementation widens `int16` values, squares them, converts the widened products to `float64`, accumulates them in an `f64m8` vector, and finally reduces the vector to a scalar `double`:
```cpp
auto s = __riscv_vfmv_v_f_f64m8(0, vlmax);
...
auto v_mul = __riscv_vwmul(v, v, vl);
s = __riscv_vfadd_tu(s, s, __riscv_vfwcvt_f(v_mul, vl), vl);
...
return __riscv_vfmv_f(__riscv_vfredosum(...));
```
The bug was in the scalar initializer passed to `__riscv_vfredosum`.
Before this patch, the code created an `f64m1` scalar vector but used the maximum vector length for `e32m1`:
```cpp
__riscv_vfmv_s_f_f64m1(0, __riscv_vsetvlmax_e32m1())
```
This is inconsistent: the vector type is `f64m1`, so the VL used to initialize it must correspond to `e64m1`, not `e32m1`.
objdetect(aruco): fix maxCorrectionBits in predefined dictionaries #29034
This PR fixes the bugs in the creation of some dictionaries and standarizes its construction.
## Bugs
1. **DICT_ARUCO_MIP_36h12_DATA** was incorrectly assigned `maxCorrectionBits=12`, which is the intermarker distance. This was causing a high rate of false positives during detection, which is a significant problem.
2. **APRILTAG** dictionaries were incorrectly created with `maxCorrectionBits=0`, making it impossible to do error correction.
## Solution
Given a intermarker distance X, the correct `maxCorrectionBits = X/2 - 1`. Thus, standardize the construction of Dictionaries as such.
Python: add context manager compatibility for VideoCapture and VideoWriter #28967
### Description
This PR implements the context manager protocol (`with` statement support) for `cv2.VideoCapture` and `cv2.VideoWriter` objects in Python.
### Problem
Currently, these classes do not support the context manager protocol, leading to a `TypeError: ... object does not support the context manager protocol` when used with a `with` block. As reported in issue #28956, if an exception occurs before an explicit `.release()` call, the video resource or file remains locked in the system[cite: 298, 309].
### Identification & Motivation
By analyzing the issue and the Python binding structure of OpenCV, I identified that while the core logic resides in C++, the Pythonic behavior can be enhanced by injecting `__enter__` and `__exit__` methods during the module initialization. This ensures that resources are automatically and safely released even if the program execution is interrupted by an error[cite: 298, 325].
### Solution
I have modified `modules/python/package/cv2/__init__.py` to dynamically inject the necessary methods:
1. Defined `_video_enter` to return the object itself (standard context manager behavior).
2. Defined `_video_exit` to trigger the `.release()` method automatically.
3. Injected these methods into `VideoCapture` and `VideoWriter` classes immediately after the `bootstrap()` function to ensure the native C++ classes are correctly loaded into the global namespace.
Fixes#28956
Added net profiling support #28752
### 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
Adrian Kretz
Yixuan Tang
Alexander Smorkalov
Abhishek Gola
Varun Jaiswal
Naresh
kevinylin88
Shelia J.
Alexander Smorkalov
Vincent Rabaud
Vadim Pisarevsky
Samaresh Kumar Singh
s-trinh
Om Navin Rope
satyam yadav
熊阔豪
Teddy-Yangjiale
Rafael Muñoz Salinas
Maksim Shabunin
Tiansuanyu
Ebrahim Namdari