core: add ARMPL HAL backend for cv::invert(DECOMP_LU) - #30080
## Summary
- Follow-up to #[30035](https://github.com/opencv/opencv/pull/30035) to apply the same `cv::invert` optimization to the 5.x branch.
- Adds an ARM Performance Library (ArmPL) HAL backend for cv::invert under DECOMP_LU (cv_hal_LU32f / cv_hal_LU64f), replacing OpenCV's default LU decomposition path with ArmPL's LAPACKE_sgesv / LAPACKE_dgesv for float and double matrices on AArch64.
## Changes
**hal/armpl/include/armpl_hal_core.hpp:**
- Declare armpl_hal_LU32f / armpl_hal_LU64f and register them as cv_hal_LU32f / cv_hal_LU64f.
**hal/armpl/src/armpl_hal_core.cpp:**
- Add armpl_lu() function (works for both float and double), that does the LU decomposition of the matrix:
- If a right-hand side b is given, then LAPACKE_sgesv/dgesv is called.
- If no right-hand side is given, it only factorizes the matrix using LAPACKE_sgetrf/dgetrf
- Fall back to OpenCV's default (non-HAL) implementation for small matrices (m < 100).
core: RVV HAL transpose2d for 3-channel element sizes - #30075
### Summary
`cv::transpose` for 3-channel types (`8UC3`/`8SC3`, `16UC3`/`16SC3`/`16FC3`, `32SC3`/`32FC3`) falls back to the scalar core path on RISC-V. The RVV HAL `transpose2d` dispatches on *element size* and only implements `esz ∈ {1, 2, 4, 8}`. This PR adds kernels for
`esz = 3, 6, 12`, and an accuracy test that covers the new paths including non-continuous ROI.
### Root cause
- `hal/riscv-rvv/src/core/transpose.cpp`: the `Transpose2dFunc tab[]` table has entries only at indices 1/2/4/8, so `cv_hal_transpose2d` returns `CV_HAL_ERROR_NOT_IMPLEMENTED` for every 3-channel type and the caller runs the generic path.
- On the scalable RVV backend (`intrin_rvv_scalable.hpp`) `CV_SIMD128` is never defined, so the existing `transpose_8/16/32/48bit_simd` fast paths `modules/core/src/matrix_transform.cpp` are compiled out entirely; what runs is the scalar 4x4 element loop. 8UC3 (the default color type) is the most visible case.
### Implementation
The new kernels deinterleave the three channels of several source rows with `vlseg3e{L}` and emit the transposed rows with strided segment stores (`vssseg{6,8}e{L}`). The number of source rows per block was picked experimentally: 8 rows for 8-bit lanes, 2 rows for 16/32-bit lanes. For 16/32-bit lanes, taller blocks e.g. 8 rows will add register pressure and cause regression. A one-row tail covers the remainder; unaligned 16/32-bit inputs fall back to the generic path.
### Performance
SpacemiT K1 / X60, OpenCV 5.x, `--perf_force_samples=20
--perf_min_samples=20`, `BinaryOpTest.transpose2d`:
| type (esz) | 640x480 | 1280x720 | 1920x1080 |
|---|---:|---:|---:|
| `CV_8UC3` (3) | 2.758 -> 1.648 ms (**1.67x**) | 16.772 -> 10.575 ms (**1.59x**) | 42.901 -> 39.552 ms (1.09x) |
| `CV_16SC3` (6) | 8.384 -> 3.556 ms (**2.36x**) | 31.112 -> 19.450 ms (**1.60x**) | 71.921 -> 62.460 ms (1.15x) |
Untouched element sizes (esz 1/2/4/8, 16 cases at 640x480 + 1280x720): geomean **1.005x**,
range 0.977x ... 1.058x.
### Accuracy
New test `Core_Transpose.C3ElementSizesWithRoi` (`modules/core/test/test_mat.cpp`) sweeps
`CV_8UC3, CV_8UC(6), CV_16SC3, CV_16FC3, CV_8UC(12), CV_32FC3` over sizes `1x1, 2x3, 137x5, 133x4` through non-continuous ROI views, byte-compares every element against the source, and asserts the bytes outside the destination ROI are untouched. On K1:
```
[ PASSED ] 4 tests. # Core_Transpose.C3ElementSizesWithRoi
# Core_Transpose/ElemWiseTest.accuracy/0
# Core_Rotate/ElemWiseTest.accuracy/0
```
`BinaryOpTest.transpose2d` already provides the performance coverage; no `opencv_extra` data is needed.
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
Carotene resize left edge clamp 5x - #30076
### 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
Process masked integer norms chunk by chunk and reuse each loaded mask
and predicate across channels, avoiding repeated mask processing.
Extend norm_mask performance coverage with three-channel 8U, 8S, 16U,
16S, and 32S inputs for INF, L1, and L2 norms.
Co-authored-by: Yang Wang <yangwang@iscas.ac.cn>
Co-authored-by: Yuansheng <yuansheng@isrc.iscas.ac.cn>
Replace separate widening multiplication and FP64 addition with
widening FMA in the unmasked and masked FP32 L2 norm kernels.
Finite FP32 products are exactly representable in FP64, so this
preserves numerical results without changing the accumulation order.
Tail and mask undisturbed policies are retained.
Co-authored-by: Yang Wang <yangwang@iscas.ac.cn>
Co-authored-by: Yuansheng <yuansheng@isrc.iscas.ac.cn>
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)
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>
Extracted IPP to HAL for getRectSubPix function in 5.x - #29514
### 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 moving IPP functions to HAL for bilateral_filter in Imgproc - #29409
**Performance Numbers on Intel(R) Core(TM) i9-11900K:** https://docs.google.com/spreadsheets/d/1hnH2aGmc3D88HGnvM34xczQbRZUgsKsAHorcB-DpLq4/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
Enabled WarpAffine and WarpPerspective for IPP HAL - #29771
PR enables Warp* functions that were switched off before. The thing is that I added clear 1 for places that agrees with OpenCV due to the changes in OpenCV. Also restrict the transparent border since OpenCV and IPP differently process transparent border with a workaround for current ICV package since it fails on Windows as it was mentioned in https://github.com/opencv/opencv/pull/29669#issuecomment-5339331722.
Locally the `Imgproc_WarpPerspective_Test.accuracy` test passed with ICV that is automatically downloaded by CMake.
### 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
dnn: add HAL hook for general convolution and an RVV kernel - #29689
### 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
Adds cv_hal_dnn_conv32f and a RISC-V RVV implementation.
The hook uses the same flat C ABI as the existing DNN hooks and is behaviour-neutral without a backend. The RVV kernel runs e32m2 at vl = K0 = 8 with 10 output positions in flight, and on wide registers packs P = VLMAX/K0 output channel blocks into one vector. It declines to the built-in when an output channel block is only partially filled: K % 8, K/ngroups % 8, or grouped C/ngroups % 8.
### Verification — K3 board, VLEN 256 and 1024, GCC 15.2 + Clang 22
- Standalone harness, 22 configurations (kernel sizes, strides, dilation, asymmetric pads, 1D/2D/3D, groups, residual, all five activations): pass at both VLENs, bit-identical to a scalar reference
- opencv_test_dnn under OPENCV_FORCE_DNN_ENGINE=2: 960 passed / 29 failed, failure set identical with the hook on and off and at both VLENs; the 29 are pre-existing
- Fault injection flips exactly 19 tests, confirming the hook is on the execution path
### Performance – speedup over the built-in
| Network | 8 threads, VLEN 256 | 1 thread, VLEN 256 | 1 thread, VLEN 1024 |
| :--- | :--- | :--- | :--- |
| **SqueezeNet_v1_1** | 2.91× | 7.8× | 19.4× |
| **Inception_v1** | 2.00× | 7.0× | 13.7× |
| **Squeezenet** | 2.17× | 6.9× | 14.5× |
| **TinyYolov2** | 2.14× | 6.8× | 14.2× |
| **ResNet_50** | 2.56× | 5.7× | 9.7× |
| **LResNet100E_IR** | 1.94× | 5.5× | 11.2× |
Enabled WarpAffine and WarpPerspective for IPP HAL - #29669
PR enables Warp* functions that were switched off before. The thing is that I added clear `1` for places that agrees with OpenCV due to the changes in OpenCV. Also restrict the transparent border since OpenCV and IPP differently process transparent border.
### 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
### 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
Pratham Kumar
Ziyuan_Li
Lurie97
Alexander Smorkalov
Abhishek Gola
Prasadayus
Akansha Mallick
Andrei Fedorov
Prasad Ayush Kumar
Sean McBride
velonica0
velonica0
Teddy-Yangjiale
Alexander Smorkalov
orbisai0security