### 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
Extracting IPP to HAL for matchTemplate function in 5.x #29466
### 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
imgproc: extend boxFilter / gaussianBlurBinomial coverage in RISC-V RVV HAL #29440
### Summary
This PR extends RVV HAL coverage of the two most frequently used smoothing filters. Previously, `cv_hal_boxFilter` was only implemented for single-channel types (plus 32FC3) at 3×3/5×5, and `cv_hal_gaussianBlurBinomial` for 8UC1/16UC1/8UC4. The most common cases in practice — interleaved **8UC3** images and **7×7** box kernels — fell back to the core `FilterEngine` path, which runs single-threaded, costing 6–19× on multi-core RISC-V hardware.
New coverage:
- `boxFilter`: **8UC3 / 8UC4** (3×3, 5×5, 7×7); **7×7** for 8UC1, 16SC1, 32FC1, 32FC3 and the 8U→16U variant
- `gaussianBlurBinomial`: **8UC3** (3×3, 5×5)
Combinations already covered upstream keep their existing kernels byte-for-byte; net diff is +274/−162 across two files.
### Implementation
1. **Channel-blind "flat" kernels** (`boxFilterFlat8U<ksize, cn>`, `gaussianBlurFlat8U<ksize, cn>`). An interleaved row is processed as `width*cn` flat u8 elements whose horizontal taps sit at strides of `cn` elements: element *i* sums exactly its own channel's taps at `i, i+cn, …, i+(ksize−1)·cn`. One template therefore serves all channel counts, and:
- the horizontal pass becomes `ksize` independent unaligned `vle8` loads combined with widening adds — no `vlseg`/`vsseg` and no serial `vslide1down` chains, which are microcoded/serialized on current RVV hardware;
- the vertical pass is a single contiguous u16 stream processed at LMUL=8;
- the output is a plain `vse8` after saturating narrowing.
2. **Incremental vertical sliding window** for box with `ksize > 3`: the column-sum ring buffer keeps `ksize+1` rows so the window slides in O(1) per output row (add the entering row, subtract the leaving row) instead of re-summing `ksize` rows. u16 modular arithmetic stays exact because window sums never exceed 49·255 = 12495.
3. **Division-free normalization**: normalized box output uses multiply-high + shift (`m = ceil(2^18 / k²)`, Granlund–Montgomery; exact for divisors 9/25/49 over the full value range, verified per divisor) instead of long-latency vector integer division. Rounding is bit-identical to the previous `(sum + k²/2) / k²`.
4. **Existing kernels are extended, not rewritten**: `boxFilterC1` and the float `boxFilterC3` gain a 7×7 step in their existing unrolled style, so the 3×3/5×5 instantiations compile to the same code as before. The previous per-channel gaussian 8UC4 segment kernel is replaced by the flat kernel at measured parity, which is why the diff removes more gaussian lines than it adds.
5. Constraints respected: no hard-coded VLEN, RVV 1.0 intrinsics only, no scalable vector types in arrays.
### Performance
SpacemiT K1 (X60, rv64gcv, VLEN=256, 8×1.6 GHz), 1280×720, against a clean build of current 5.x HEAD.
**Measurement protocol:** each case is timed for **30 iterations** (after 2 warm-up runs) and the minimum is taken; the whole benchmark is executed in **2 interleaved rounds per library** (baseline/candidate alternated to cancel frequency/thermal drift, measured at up to 2× per run on this board), reporting the per-case minimum across rounds.
| Case | Generic | HAL | Speedup |
|------|--------:|----:|--------:|
| boxFilter 8UC1 7×7 | 6.539 ms | 0.330 ms | 19.8× |
| boxFilter 8UC3 3×3 | 7.325 ms | 0.994 ms | 7.4× |
| boxFilter 8UC3 5×5 | 8.118 ms | 1.142 ms | 7.1× |
| boxFilter 8UC3 7×7 | 15.930 ms | 1.328 ms | 12.0× |
| boxFilter 8UC4 3×3 | 9.552 ms | 1.466 ms | 6.5× |
| boxFilter 8UC4 5×5 | 10.775 ms | 1.841 ms | 5.9× |
| boxFilter 8UC4 7×7 | 14.268 ms | 2.112 ms | 6.8× |
| gaussianBlur 8UC3 3×3 | 2.382 ms | 1.023 ms | 2.3× |
| gaussianBlur 8UC3 5×5 | 2.746 ms | 1.684 ms | 1.6× |
**Geometric mean: ~6.1×** across the newly covered cases. Most of the box gain is the HAL's row-parallel execution (core `FilterEngine` has no internal parallelism) multiplied by the flat-layout kernels; the incremental window gives 7×7 a further ~1.9× over the plain flat version.
Regression check: the full `opencv_perf_imgproc` sweep (5610 timed cases, `--perf_min_samples=10`, one round per library) shows a geomean of 1.015× with no regressions beyond run-to-run noise — every case initially below 0.90× was re-verified with 2×2 interleaved rounds and per-case minima, and none persisted. The blur fixtures independently confirm 4.7–8.6× on 8UC4 across sizes and border types.
### Accuracy
- **Bit-exact against the core fallback**: for every newly covered combination (all 15 type/ksize pairs exercised), the HAL output was checksummed against the generic implementation on identical random inputs — all checksums match exactly. This includes the multiply-high normalization (bit-identical rounding to the previous division) and the incremental vertical window (u16 modular add/subtract cancels exactly).
- **Full accuracy suites**: `opencv_test_imgproc` filter/blur/smooth tests (`*BoxFilter*:*GaussianBlur*:*Blur*:*blur*:*Smooth*:*smooth*`) were run on K1 against a clean upstream HEAD build: **819 tests pass on both libraries, and the failure sets (pre-existing upstream failures, unrelated to this PR) are line-for-line identical**. These suites cover random anchors, all border modes, ROI offsets, and in-place operation.
- Combinations already covered upstream are unchanged by construction (same kernels, same codegen), so their accuracy behavior is inherited.
Note for reviewers: the large baseline gap also reflects that core `FilterEngine` runs single-threaded; that affects all non-HAL targets and may deserve a separate issue.
### 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
Distransform function IPP migration to HAL in 4.x #29463
### 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
Extracting IPP integaration as HAL for Canny #29434
Backport of : https://github.com/opencv/opencv/pull/29433
**Performance Numbers on Intel(R) Core(TM) i9-11900K:** https://docs.google.com/spreadsheets/d/1RMvUZP1tSQtdjuNQY9JasYmlx1L5iN9XWGhXtG5u1uI/edit?usp=sharing
### 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
Extracting IPP to HAL for matchTemplate function in 4.x #29464
### 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
Filter2D IPP extraction to HAL for 5.x #29428
### 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
Filter2D IPP migration to HAL for 4.x #29427
### 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
Merge pull request #29414 from Prasadayus:box_filter_refactor
Moving IPP functions to HAL for box_filter in Imgproc #29414
**Performance Numbers on Intel(R) Core(TM) i9-11900K:** https://docs.google.com/spreadsheets/d/1puWmOSTtAFwWjPu8J1SpuccPQvxUJU8NlFQs7mAZwL8/edit?usp=sharing
### 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
Refactoring and optimizing cvtcolor in Imgproc #29389
**Key Changes:**
1. Unified three divergent SIMD swap implementations into a single shared `v_swap` helper.
2. Consolidated the repeated `CV_8U/CV_16U/CV_32F` depth-dispatch chains into a single `CvtColorLoopDepth` template.
3. Extracted the duplicated coefficient-selection loops in the YCrCb/YUV constructors into `selectYuvCoeffs`.
4. Collapsed the shared YUV420 store logic duplicated across both decode invokers into `storeYUV420block`.
5. Generalized the inline blue-channel coefficient swaps in `color_lab.cpp` into `swapBlueCoeffsCols`/`swapBlueCoeffsRows`.
6. Added a `v_dotprod`-based SIMD path (`v_RGB2Y`/`v_RGB2UV`) for the previously scalar `RGB8toYUV422Invoker`.
7. Migrated all inline `CV_IPP_CHECK` cvtColor paths out of the dispatch files and into the IPP HAL plugin (`hal/ipp/src/color_ipp.cpp`), replacing each call site with `CALL_HAL`.
**Performance Numbers on Intel(R) Core(TM) i9-11900K**: https://docs.google.com/spreadsheets/d/1pz0aHlTeG4Ao8RT7LipgdNSjhCJz92QfZG3GmNa63hU/edit?usp=sharing
### 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
Extract IPP integration as HAL function for box_filter #29420
Backport of https://github.com/opencv/opencv/pull/29414
**Performance Numbers on Intel(R) Core(TM) i9-11900K:** https://docs.google.com/spreadsheets/d/1kMKiZWh--pH30hqsQo6j1suNw1lfQiKzSankMCMa2FI/edit?usp=sharing
### 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
imgproc: fix INTER_NEAREST_EXACT to match Pillow (5.x retarget of #28661) #28873
## Summary
Fixes `INTER_NEAREST_EXACT` producing different results from Pillow for images with dimensions that are multiples of 64 (e.g., 128, 192).
Retargets #28661 to 5.x per core team request.
## Root cause
The old 16-bit fixed-point arithmetic (`ifx`, `ifx0`, `>> 16`) rounds differently from Pillow's pixel-center coordinate mapping. At exact pixel boundaries (e.g., y=7 with 128 to 160: `0.4 + 7*0.8 = 5.999999999999999`), Pillow's truncation drops to 5 while the old opencv formula rounds to 6.
## Changes
- `resize.cpp`: Replace `ifx/ifx0/ify/ify0` 16-bit fixed-point with an int64 arithmetic formula equivalent to `floor((i + 0.5) * src / dst)`, computed as `((int64_t)(i * 2 + 1) * src) / (dst * 2)`. This matches Pillow's pixel-center mapping exactly, is deterministic across platforms, and avoids FP rounding divergence entirely.
- `test_resize_bitexact.cpp`: Add `NearestExact_PillowCompat` covering 4 dimension pairs including the reproducer from #28429.
## Testing
- All 3 `Resize_Bitexact` tests pass (Linear8U, Nearest8U, NearestExact_PillowCompat) on this branch built against 5.x
- Verified bit-exact match to PIL output (Python 3.14, Pillow) on 49 dimension combinations including random pairs
- Built on macOS ARM64 with HAL (carotene/KleidiCV) active
Fixes#28429
Defer the u8→i16 widening (vzext) in the pre-screen phase until after
the quick-reject check passes. This avoids 5 unnecessary widen
operations per pixel-strip when the pre-screen rejects (which happens
~70-80% of the time at the default threshold=20).
The approach uses u8mf2 (same VL as i16m1) for the pre-screen
comparison with vssubu/vsaddu for bounds and vmsgtu for unsigned
comparison. When the pre-screen passes, the already-loaded u8mf2
variables are widened to i16m1 for the score computation, reusing
the same data without redundant memory loads.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Reenable ICV and fix#29166#29183
Fixing https://github.com/opencv/opencv/issues/29166 and return back the 2026.0.0 ICV.
Tests are passed locally on Windows machine. Feel free to check if they are passed in bigger test systems.
### 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
RISC-V: add RVV convertScale paths for selected depth conversions #29058
### Summary
This PR extends the RISC-V RVV HAL `convertScale` implementation with optimized paths for selected `convertTo()` depth conversions:
- `CV_32F -> CV_8U`
- `CV_16U -> CV_32F`
- `CV_16S -> CV_32F`
The change is confined to `hal/riscv-rvv/src/core/convert_scale.cpp`. It does not modify the generic `convertTo()` implementation or affect dispatch for non-RISC-V targets.
### Rationale
`Mat::convertTo()` reaches architecture-specific implementations through the HAL `convertScale` interface. Adding these paths in the RVV HAL keeps the optimization in the existing backend layer and avoids introducing RISC-V-specific branches into common OpenCV code.
The selected conversions were chosen based on measured benefit and practical relevance. `CV_32F -> CV_8U` provides the largest speedup, while `CV_16U -> CV_32F` and `CV_16S -> CV_32F` provide consistent improvements for common image-processing data paths.
### Benchmark
Tested on Banana Pi BPI-F3, an 8-core RISC-V board with RVV 1.0 support.
Build and test configuration:
- OpenCV `4.14.0-pre`
- Release build
- RVV HAL enabled
- Compiler: `riscv64-unknown-linux-gnu-g++ 14.2.1`
- Test binary: `opencv_perf_core`
- Test filter: `*convertTo*`
- Samples: `--perf_force_samples=20 --perf_min_samples=20`
Benchmark command:
```bash
./opencv_perf_core \
--gtest_filter=*convertTo* \
--perf_force_samples=20 \
--perf_min_samples=20
```
Each benchmark case was measured with 20 forced samples. The baseline/after comparison was repeated to check run-to-run stability. The optimized conversion pairs showed consistent improvements.
Second-run comparison for the optimized pairs:
```text
OPTIMIZED_PAIRS: 24 cases, gmean 2.6009x
CV_32F -> CV_8U: 16.0718x
CV_16U -> CV_32F: 1.2334x
CV_16S -> CV_32F: 1.1376x
```
`CV_32F -> CV_8U` showed the largest improvement, with speedups in the `14.5x` to `18.8x` range across the tested image sizes, channel counts, and alpha values.
### Notes on Measurement
The initial benchmark run showed noise in conversion pairs not touched by this PR, likely due to board-level variance such as frequency scaling, thermal state, or background scheduling.
A second run showed untouched pairs close to neutral:
```text
UNTOUCHED_OTHER: gmean 0.9941x
```
The optimized conversion pairs remained consistently faster across both runs, with no observed regression in the added RVV paths.
### 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
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`.
Akansha-977
Teddy-Yangjiale
Alexander Smorkalov
Alexander Smorkalov
Prasad Ayush Kumar
velonica0
Andrei Fedorov
orbisai0security
Prasadayus
Matt Van Horn
ozhanghe
Shengyu Wu
Ziyuan Li
Kevin Lin
Tiansuanyu