core: fold a*alpha + b*beta + gamma into the fused OP_ADDW kernel - #29953
Part of #29443 — "fuse `a*alpha + b*beta + gamma`, where alpha, beta and gamma are scalars, into
some new `OP_ADDW`". Builds on #29937, which is required for correctness (see below).
### Problem
`OP_ADDW` already computes `a*alpha + b*beta + gamma` as a single kernel over two `v_fma`, and
`emitBinary()` already knows how to emit it — but the string front-end never recognized the
pattern, so `cv::texpr()` always took the written-out path: two multiplies, two adds, three temp
buffers and four passes over the data.
```
{0}*2.0 + {1}*3.0 + 1.0 at CV_32F
insns=4 temps=3 buffers=3 insns=1 temps=0 buffers=0
0: mul(1, 4) -> 5 ==> 0: addWeighted(1, 2) -> 11
1: mul(2, 7) -> 8 params=[2, 3, 1]
2: add(5, 8) -> 9
3: add(9, 11) -> 13
```
### Fix
A peephole in `emitBinary()`: `a*alpha + b*beta` folds into one `OP_ADDW`, and a trailing scalar
folds into that instruction's gamma rather than costing another pass.
`emitBinary()` may wrap a multiply in casts — an integer array times a fractional scalar computes
in the float domain and lands back in the array's own type — so the matcher accepts the optional
widening and narrowing casts around it. That is what makes the common 8-bit blend fuse; without
it `{0}*0.7 + {1}*0.3` at `CV_8U` stays at eight instructions and seven temps.
Shapes that are not an addWeighted keep their own meaning: an `a*b` term has no scalar factor, a
per-channel constant cannot ride the params block, and `CV_Bool` has no `OP_ADDW` form.
**Dependency on #29937.** This retires the instructions it folds, exactly as the
`abs(x - y) -> absdiff` peephole does. Without the `pinned` flag added in #29937 it would
reintroduce that bug for `u = {0}*2.0; v = {1}*3.0; u + v`, where the named terms are still live.
### Semantics on integer types
The fused kernel evaluates at its own work precision, so intermediate results no longer saturate
at each step. On integer inputs the result changes — it now agrees with `cv::addWeighted`, which
is what the expression means. This is the same trade the existing `abs(x - y)` peephole documents
in `emitUnary()`: the saturation artifacts of the literal expansion are never the desired result.
### Performance
1920x1080, best of 5 runs of 50 iterations, same build rebuilt both ways on 03ae9eac50:
| expression | depth | before | after |
| --- | --- | --- | --- |
| `a*0.7 + b*0.3` | 8U | 0.646 ms | 0.159 ms |
| `a*2 + b*3 + 1` | 8U | 0.261 ms | 0.150 ms |
| `a*2.5 + b*-1.5 + 7` | 32F | 0.360 ms | 0.214 ms |
| `a*2 + b*3 + 1` | 32F | 0.213 ms | 0.155 ms |
| `a*b + b*2` (control, not fused) | 32F | 0.393 ms | 0.358 ms |
The control row runs identical code in both builds and still moves by ~9%, so run-to-run noise on
this machine is around 10% — treat the 32F rows as indicative and the 8-bit rows as the real
result. Timings include `cv::texpr()` re-parsing and recompiling the expression on every call, so
the kernel-level gain is larger than the totals suggest.
### Tests
28 parameterised cases — 7 depths crossed with 4 weight sets, including a zero gamma and negative
weights — assert the fused result matches `cv::addWeighted`. Two further tests cover the variants
(no gamma, scalar written first, leading gamma) and the shapes the peephole must decline. 1801
tests in the arithmetic and TExpr suites pass.
Also adds the missing `OP_ADDW` case to `opName()`, which this change makes visible in every dump
of such a program.
### 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
Remove deprecated CommaInitializer API - #29948
This goes hand in hand with https://github.com/opencv/opencv_contrib/pull/4217
### 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
Added Backend Agnostic fusion in DNN - #29656
# What This Adds
A way for any layer, on any backend, to absorb trailing per-element math — with the pass knowing nothing about either layer and holding no list of op types.
- **Description**: `LayerMath` (one layer's math) → `AdjacencyGraph` (hash-consed chain)
- **Contract**: two `bool` virtuals on `Layer`
- **CPU implementations**: three, behind that contract
Pointwise fusion is the first consumer, not the point.
## The Problem
```cpp
ActivationLayer* activ = dynamic_cast<ActivationLayer*>(layer_ptr);
Conv2Layer* conv = getLayer<Conv2Layer>(newprog, conv_layer_idx);
if (conv) conv->fuseActivation(layer);
```
Guest type, host type, method name all hardcoded in the pass. `Clip` never fused (fails the cast), `Gemm` never fused (no virtual), no 2-op chain fused at all, and no backend could fuse anything without a CPU-specific method.
## Results
| Model | 5.x | this PR | speedup |
|-----------------------|----------|----------|---------|
| MPHand | 2.34 ms | 1.03 ms | 2.27 |
| EfficientNet | 9.82 ms | 5.00 ms | 1.96 |
| MPPose | 5.14 ms | 2.81 ms | 1.83 |
| MobileNet_SSD_v1_ONNX | 12.58 ms | 8.38 ms | 1.50 |
| BlazeFace | 0.95 ms | 0.77 ms | 1.23 |
| DenseNet_121 | 20.56 ms | 19.08 ms | 1.08 |
| MobileNetv2_ONNX | 2.07 ms | 1.99 ms | 1.04 |
| MobileViT_XS | 6.33 ms | 6.11 ms | 1.04 |
| YuNet_320 | 1.33 ms | 1.27 ms | 1.04 |
| PPOCRv3 | 43.05 ms | 42.15 ms | 1.02 |
| BERT | 9.78 ms | 9.68 ms | 1.01 |
| BEiT_Base_Patch16_224 | 27.48 ms | 27.08 ms | 1.01 |
| DeiT_Tiny_Patch16_224 | 4.74 ms | 4.72 ms | 1.01 |
| MPPalm | 1.88 ms | 1.85 ms | 1.01 |
| SSD | 50.19 ms | 49.82 ms | 1.01 |
| YOLOv4_tiny | 7.10 ms | 7.03 ms | 1.01 |
### 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
Add a CV_SIMD_SCALABLE path for the DIS patch processing kernels using
universal intrinsics and runtime vector lane counts.
Keep the existing CV_SIMD128 implementation unchanged to avoid affecting
fixed-width SIMD targets. The scalable path vectorizes patch rows with
v_float32 and handles remaining elements with the existing scalar code.
This enables native RVV vectorization for processPatch(),
processPatchMeanNorm(), computeSSD(), and computeSSDMeanNorm().
Co-authored-by: Yang Wang <yangwang@iscas.ac.cn>
Co-authored-by: Yuansheng <yuansheng@isrc.iscas.ac.cn>
core: fix overflow in borderInterpolate BORDER_WRAP path - #29884
### Description
Fixes an integer overflow/underflow bug in `cv::borderInterpolate()` when using `BORDER_WRAP`. For extreme values of `p` (e.g. `INT_MIN` or `INT_MAX`), the previous implementation performed the modulo operation directly on `int`, which can invoke undefined behavior on overflow and produce a result outside the valid `[0, len)` range.
The fix widens the intermediate calculation to `int64_t` before taking the modulo, then adjusts for negative results and narrows back to `int` only once the value is confirmed to be in range.
### Changes
- `modules/core/src/copy.cpp`: use 64-bit intermediate arithmetic in the `BORDER_WRAP` branch of `borderInterpolate()` to avoid overflow.
- `modules/core/test/test_misc.cpp`: add `Core_BorderInterpolate.wrap_no_overflow_29232`, a regression test that exercises `BORDER_WRAP` with `INT_MIN` and `INT_MAX` and asserts the result stays within `[0, len)`.
Fixes#29232
### 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 for the patch (added in test_misc.cpp); no performance test needed as this is a bug fix with negligible performance impact.
- [x] The feature is well documented and sample code can be built with the project CMake
Merge pull request #29931 from abhishek-gola:onnx_conformance_remaining_fixes
fix ONNX auto_pad, PRelu broadcasting and LSTM peepholes - #29931
closes: https://github.com/opencv/opencv/issues/21078
Upated ONNX coverage: 77.8%
### 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: optimize 8U row reduce sum with vwaddu.wv - #29923
### Summary
Optimize the RVV implementation of `reduceRowSum_8u32s` by using the
native widening add instruction `vwaddu.wv`.
The generic scalable-vector path expands each `u8m1` input vector into
two `u16m1` halves and performs two separate load/add/store sequences
for the `u16` accumulation buffer.
On RVV, an `u8m1` vector and an `u16m2` vector have the same number of
elements. This allows the implementation to use an `u16m2` accumulator
directly and combine widening and addition with `vwaddu.wv`:
```text
u16m2 = u16m2 + u8m1
```
This removes the explicit widening and low/high `u16` accumulator split,
reducing the vector operations in the hot accumulation loop.
The existing scalar tail and 256-row `u16`-to-`u32` flush logic remain
unchanged.
The implementation is VLEN-agnostic.
### Functional Testing
The Reduce tests were run with:
```bash
./bin/opencv_test_core \
--gtest_filter='*Reduce*:*reduce*'
```
### Performance Testing
Performance was measured with:
```bash
OPENCV_FOR_THREADS_NUM=1 ./bin/opencv_perf_core \
--gtest_filter='*Reduce*:*reduce*'
```
Test environment:
- SpacemiT K3 / X100
- RVV 1.0
- VLEN = 256
- GCC 14.3.0
- Release build
- Single thread
Results were compared against an unmodified `5.x` baseline.
Median execution time (ms):
| Size / Type | Baseline | RVV `vwaddu.wv` | Speedup |
| --- | ---: | ---: | ---: |
| 640x480 8UC1 | 0.09 | 0.05 | 1.80x |
| 640x480 8UC4 | 0.36 | 0.16 | 2.25x |
| 1280x720 8UC1 | 0.27 | 0.12 | 2.25x |
| 1280x720 8UC4 | 1.08 | 0.56 | 1.93x |
| 1920x1080 8UC1 | 0.62 | 0.29 | 2.14x |
| 1920x1080 8UC4 | 2.43 | 1.11 | 2.19x |
Geometric mean speedup: **~2.09x**.
`REDUCE_MIN`, `REDUCE_MAX`, and `REDUCE_SUM2` performance remains
essentially unchanged, indicating that the speedup is localized to the
optimized 8-bit row SUM path.
### Co-authors
- Yang Wang <yangwang@iscas.ac.cn>
- Yuansheng <yuansheng@isrc.iscas.ac.cn>
### 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
imgproc: fix NaN in phaseCorrelateIterative for float32 input - #29871
### 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
### Summary
`cv::phaseCorrelateIterative` could return the image boundary as the detected shift (e.g. `(-32, -32)` for a 64x64 image) for ordinary float32 input, while the same input in float64 and the non-iterative `cv::phaseCorrelate` both return the correct shift. Reported in #29849 with a reproducer.
### Problem
`calculateCrossPowerSpectrum()` divided by the bin magnitude without a zero check. When a frequency bin of the cross power spectrum has exactly zero magnitude, the division produces NaN (0/0). A single NaN bin is enough: after the inverse DFT the whole correlation landscape becomes NaN, `minMaxLoc` degenerates, the peak lands on the wraparound corner, and the function exits through the out-of-bounds fallback returning `L3peak - L3mid = (-N/2, -M/2)`.
This is reachable with perfectly valid input: for a 64x64 image, bins where either frequency component hits Nyquist produce `dft1[bin] * conj(dft2[bin]) = 0` for Gaussian-like windows (the Hanning-windowed images issue #29849 used), because one of the DFT factors is exactly zero there.
### Solution
Two changes in `calculateCrossPowerSpectrum()`, both matching what the non-iterative implementation already does:
1. Guard the zero-magnitude case: a bin with zero magnitude has undefined phase, so write 0 instead of dividing by zero. `cv::divSpectrums()` handles the same situation by adding an epsilon to the denominator; zeroing the bin is equivalent here and keeps the output strictly on the unit circle.
2. Accumulate in `double` before rounding back to the storage type, as `cv::divSpectrums()` does in its CV_32F branch. This also protects large images, where float32 products of DFT bins can overflow to inf.
### Testing
- Reproduced #29849 with the issue's reproducer ported to C++: float32 returned `(-32, -32)` before the fix, `(-2.96, 1.99)` after (float64 reference: `(-2.94, 1.96)` for the true shift (-3, +2)).
- Added regression test `Imgproc_PhaseCorrelationIterative/64x64_float32_accuracy` covering this case. Verified it fails without the fix (returns `(-32, -32)`) and passes with it.
- `opencv_test_imgproc`: all 1635 tests pass with the fix (opencv_extra testdata, 5.x branch). The pre-existing `float32_overflow` and accuracy tests for the non-iterative path also pass.
Port of #29862 (merged into 4.x) to 5.x.
- Type/stride substitution only; arithmetic and evaluation order unchanged.
- RedBlackSOR: the v_extract<3>(prev, next) previous-lane construction is
replaced by an unaligned vx_load(p_next + j - 1); v_extract<3> is only
previous-lane when vlanes == 4, so this is required for wider lanes.
- HorPass keeps a strict bound, j < len - vlanes, while the other three use
j <= len - vlanes, since the vector body applies UPDATE to every lane and
the rightmost element must not receive UPDATE across the right border.
- No SVE claim: there is no SVE backend in-tree; scalable means RVV today.
video:rvv: optimize PyrLK tracker with RVV - #29947
### Summary
Add an RVV path to `LKTrackerInvoker` for patch interpolation and
covariance matrix accumulation.
### Implementation
Vectorize bilinear interpolation of image pixels and derivatives, and
accumulate A11, A12 and A22 using RVV widening operations. Reuse
temporary vectors and keep the main computation at `e16,m1` and
`e32/f32,m2` to limit vector register pressure.
### Functional Testing
```bash
./bin/opencv_test_video \
--gtest_filter='Video_OpticalFlowPyrLK.accuracy' \
--test_threads=1
./bin/opencv_test_video \
--gtest_filter='Video_OpticalFlowPyrLK.submat' \
--test_threads=1
```
Correctness was verified with:
- `Video_OpticalFlowPyrLK.accuracy`
- `Video_OpticalFlowPyrLK.submat`
### Performance Testing
```bash
OPENCV_FOR_THREADS_NUM=1 \
./bin/opencv_perf_video \
--gtest_filter='*OpticalFlowPyrLK_self*' \
--perf_threads=1
```
Performance was measured with `OpticalFlowPyrLK_self` using a single
thread on an RVV 1.0 system with VLEN=256.
All 96 benchmark cases improved with no regression. The sum of
per-case median execution times decreased from 409.89 ms to 332.33 ms,
a reduction of 18.9%. The best case decreased from 8.41 ms to 5.50 ms,
corresponding to a 34.6% reduction in execution time (1.53x speedup).
Median execution time (ms):
| Metric | Baseline | RVV | Time reduction |
|---|---:|---:|---:|
| Sum of per-case medians across all 96 cases | 409.89 | 332.33 | 18.9% |
| Best case | 8.41 | 5.50 | 34.6% |
### Co-authors
- Yang Wang <yangwang@iscas.ac.cn>
- Yuansheng <yuansheng@iscas.ac.cn>
### 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
- [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 #29862 (merged into 4.x) to 5.x.
- Type/stride substitution only; arithmetic and evaluation order unchanged.
- RedBlackSOR: the v_extract<3>(prev, next) previous-lane construction is
replaced by an unaligned vx_load(p_next + j - 1); v_extract<3> is only
previous-lane when vlanes == 4, so this is required for wider lanes.
- HorPass keeps a strict bound, j < len - vlanes, while the other three use
j <= len - vlanes, since the vector body applies UPDATE to every lane and
the rightmost element must not receive UPDATE across the right border.
- No SVE claim: there is no SVE backend in-tree; scalable means RVV today.
FileStorage's XML/YAML/JSON parsers recurse once per nesting level
with no depth limit, allowing a small crafted file to exhaust the
stack and crash the process with an uncatchable SIGSEGV (CWE-674).
Add a shared CV_PERSISTENCE_MAX_DEPTH constant and thread a depth
counter through parseValue (XML/YAML) and parseSeq/parseMap (JSON),
raising a catchable cv::Exception via CV_PARSE_ERROR_CPP once the
limit is exceeded.
Fixes#29939
TExpr::moveToOutput() and the abs(x - y) -> absdiff(x, y) peephole in
TExpr::emitUnary() retire a value's arg slot (reclassify it to NONE) once
its single consumer has been emitted. That holds for an anonymous
intermediate, but a value the parser bound to a name ("t = ...;") may be
referenced again: the parser's name table still points at the retired slot,
so the later reference resolved to the reserved empty operand and
cv::texpr() silently returned a wrong result - for
t = {0} - {1}; abs(t) + t
t = {0} - {1}; (abs(t), t)
t = {0} + {1}; (t, t)
the reused name yielded input {0} instead of its own value, with no
assertion.
Mark a slot as pinned when the parser binds it to a name and skip both
retire manoeuvres for a pinned slot; each then takes the non-destructive
path it already has - moveToOutput() copies into the output via OP_CAST,
and the abs peephole falls through to the plain absdiff(a, 0) form, keeping
the OP_SUB that the name still needs. Anonymous intermediates are
unaffected, so the zero-temp fast path for single-op programs still fires.
core: fix RVV widening load lane count (#29907) - #29921
# core: fix RVV widening load lane count
Partially fixes#29907.
The RVV `v_load_expand` implementation used the source vector lane count for the widening load. For widening loads, the number of loaded elements must match the destination widened vector lane count instead.
This change:
* uses `VTraits<_Tpwvec>::vlanes()` for the RVV widening load and conversion;
* adds regression coverage for `texpr` `select()` with byte masks across multiple data types, channel counts, mask types, strided matrices, and in-place output.
### Pull Request Readiness Checklist
See details at the OpenCV contribution guidelines.
* [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 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 an accuracy/regression test where applicable.
* [x] The change does not require documentation or sample updates.
core: handle zero-sized broadcast dimensions - #29911
### 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
Port the fix from #29878 to the 5.x branch.
This adds a guard for zero-sized destination matrices in
cv::broadcast() and a regression test covering broadcasting
from {1, 0} to {3, 0}.
The relevant BroadcastTo.* tests pass locally.
Related: #29878
Add an RVV HAL implementation for CV_32F to CV_16S conversion.
The RISC-V convertScale HAL already handles several source/destination
depth combinations, but CV_32F to CV_16S currently returns
CV_HAL_ERROR_NOT_IMPLEMENTED and falls back to the generic core path.
Implement the missing conversion using native RVV intrinsics. The
identity-scale case skips the multiply-add, while scaled conversions
apply alpha and beta before narrowing to signed 16-bit output.
The implementation is VLEN-agnostic and uses vsetvl for tail handling.
Functional test:
```text
./build-rvv/bin/opencv_test_core \
--gtest_filter='*ConvertScale*'
```
Performance was measured with opencv_perf_core on SpacemiT K3
(RVV 1.0, VLEN=256), comparing against an unmodified 5.x baseline.
CV_32F -> CV_16S median time:
```text
1920x1080 C1, alpha=1:
26.16 ms -> 1.46 ms (17.92x)
1920x1080 C1, alpha=1/255:
24.10 ms -> 1.45 ms (16.62x)
1920x1080 C4, alpha=1:
103.76 ms -> 6.06 ms (17.12x)
1920x1080 C4, alpha=1/255:
96.03 ms -> 5.68 ms (16.91x)
```
All four corresponding opencv_perf_core cases pass.
Co-authored-by: Yang Wang [yangwang@iscas.ac.cn](mailto:yangwang@iscas.ac.cn)
Co-authored-by: Yuansheng [yuansheng@iscas.ac.cn](mailto:yuansheng@iscas.ac.cn)
ptcloud , photo test suit cleanup - #29742
## Test suite cleanup
### Given real assertions
- **ptcloud** — `HugeSceneGrowthTest`: zero assertions, including a `// Reset check` comment followed by no check.
- **ptcloud** — `PointCloud.SaveBadExtension`: passed an empty vertex set, so it exited at the empty-input guard and never reached the extension code it is named for.
- **ptcloud** — new `PointCloud.SaveEmptyVertices`: covers the early-return branch the above was hitting by accident.
### Moved
- **photo** — `Photo_Denoising.speed` → `perf/perf_denoising.cpp`: a `getTickCount` + `printf` stopwatch in the accuracy suite, asserting nothing, costing 393 ms per run.
### Library fixes found while doing the above
- **ptcloud** — `findPlanes` now converts 3-channel input instead of reshaping it: `Mat_<Vec4f>::operator=` reshapes when depths match, so a 320×240 `CV_32FC3` input silently became 240×240.
- **ptcloud** — new `RGBD_Plane.regression_3channel_matches_4channel`: nothing covered the documented 3-channel path, since all 40 `RgbdPlaneGenerate` cases feed `CV_32FC4`.
### 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
Joining BINARIES_PATHS with an unconditional trailing separator
creates an empty search-path entry when the variable was unset.
On POSIX that empty entry is CWD (ld.so), so children can load
the wrong libraries. Keep prepending extras, but only insert the
separator when an old value exists. Same join on Windows PATH.
The generic odd-radix DFT path created the index vector with
vsetvlmax_e32mf2() and kept it live across a subsequent setvl() call used
for the current processing chunk.
This code pattern can produce incorrect results with GCC 15.2 using the
default optimized VSETVL strategy. Core_DFT.accuracy and
Core_DCT.accuracy fail with the RVV HAL enabled, while disabling VSETVL
global fusion makes the same tests pass.
Generate the index vector after setting the vector length for each
q-loop chunk instead. Keep all vector operations within the same local
qvl and advance q explicitly by that value.
This preserves the existing odd-radix DFT algorithm while avoiding
vector values that span changes of VL.
Tested on SpaceMIT K3 with GCC 15.2.0, RVV 1.0 and VLEN=256:
RISCV_RVV_SCALABLE=ON
WITH_HAL_RVV=ON
CMAKE_BUILD_TYPE=Release
Core_DFT and Core_DCT accuracy tests pass with GCC's default VSETVL
optimization enabled.
Co-authored-by: Yuansheng <yuansheng@iscas.ac.cn>
Co-authored-by: Yang Wang <yangwang@iscas.ac.cn>
core: fix addWeighted null kernel crash for f64 dtype and bool inputs - #29883Fixes#29880.
`cv::addWeighted` segfaults for `CV_8U`, `CV_8S`, `CV_16U`, `CV_16S`, `CV_16F`, `CV_16BF` and `CV_32F` inputs with `dtype=CV_64F`, and for `CV_Bool` inputs with any dtype. When no direct `T -> rdepth` kernel exists, `TExpr::emitBinary()` picks a wide work type and looks the kernel up again, but for those input types only `T -> T` and `T -> f32` kernels are generated, so the second lookup returns a null function pointer too. The `addInsn()` overload that takes an already resolved kernel stores it without checking, and `runInsn()` then calls through the null pointer.
Cast the operands to the work type when there is no kernel for them either, so the f64 (or f32) kernel runs on widened inputs. That is also what 4.x did, it converted the sources to the working type before computing, so an f64 destination keeps full precision instead of going through an f32 intermediate. Added the `CV_Assert` on the resolved kernel that the other emit paths already carry.
### 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 (`5.x`, the element-wise engine this regressed in does not exist on `4.x`)
- [x] There is a reference to the original bug report and related work (#29880, regressed by #29426)
- [x] There is an accuracy test (`Core_Arithm.addWeighted_dtype_29880`, which segfaults without the fix); not applicable: performance test and opencv_extra test data
- [x] N/A: this is a bug fix, no new public API or documentation needed
Alexander Smorkalov
Alexander Smorkalov
pranayr710
Vincent Rabaud
Savya Sanchi Sharma
Akshar Singhal
Abhishek Gola
Pranshul Soni
Jeongkeun Kim
Rishiii57
MUHAMMAD AHMAD MASOOD
Sridhar
cuishuang
Varun Jaiswal
Dylan Xu
Lazizbek Ergashev
Bhushan Asati