Speed up imgproc warpAffine and warpPerspective for BORDER_TRANSPARENT - #29779
### 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.
- [x] The feature is well documented and sample code can be built with the project CMake
## Why
I was using `warpPerspective` to draw several source images on a large destination image in mode `BORDER_TRANSPARENT` and ran into `warpPerspective` being surprisingly slow. Upon reading the code, it turns out that `warpPerspective`, as well as `warpAffine`, iterates over all the destination image's pixels even if the source image gets projected to only a small part of the destination image, resulting in considerable overhead for my use case. I believe other users would also benefit from making this case more efficient.
## Changes
d19c343704 calculates the ROI of the source image in the destination image and then limits the destination image walk to that area. Given that the existing tests didn't cover `BORDER_TRANSPARENT`, I extended that in e451f59cda. Next to that, I added a small performance test dedicated to this use case (c4e271c2dc).
## Performance improvement
The following table show the timing difference before and after, generated using the added perf test (source image projects to 64x64, drawn in a 512x512 destination image):
| function | type | interp | base [ms] | opt [ms] | speedup |
| --- | --- | --- | --- | --- | --- |
| warpAffine | 8UC1 | NEAREST | 0.204 | 0.010 | 19.8× |
| warpAffine | 8UC1 | LINEAR | 0.428 | 0.026 | 16.6× |
| warpAffine | 8UC4 | NEAREST | 0.239 | 0.021 | 11.5× |
| warpAffine | 8UC4 | LINEAR | 0.433 | 0.031 | 14.0× |
| warpPerspective | 8UC1 | NEAREST | 0.759 | 0.033 | 23.2× |
| warpPerspective | 8UC1 | LINEAR | 1.125 | 0.067 | 16.8× |
| warpPerspective | 8UC4 | NEAREST | 0.786 | 0.040 | 19.5× |
| warpPerspective | 8UC4 | LINEAR | 1.110 | 0.101 | 11.0× |
In short, a 10 to 20x speedup.
## Notes
- This is my first PR for the OpenCV project, I'm sorry in case I didn't respect all contribution guidelines.
- If relevant, Clause Opus 4.8 was used for exploring the codebase, some code and style suggestions and review.
objdetect: do not modify the input features in FaceRecognizerSF::match - #29804
`FaceRecognizerSF::match()` normalizes its two `InputArray` features in place, writing
through to the caller's buffers, and returns a wrong score when the two overlap.
### Fix
Normalize both features into their own destinations. This yields bit-exact the same
values as the in-place form, checked across a range of shapes and depths including a
non-continuous ROI, so scores for non-overlapping inputs do not move.
### 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 (no issue reports this; #7298 is the related RFC)
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable (accuracy test added in-repo; it reuses the existing model, so there is no opencv_extra patch)
- [ ] The feature is well documented and sample code can be built with the project CMake (n/a — bug fix, no API, sample or documentation change)
Extract IPP integration as HAL function for bilateral_filter - #29410
Backport of https://github.com/opencv/opencv/pull/29409
**Performance Numbers on Intel(R) Core(TM) i9-11900K:** https://docs.google.com/spreadsheets/d/1rmNB3X_V8rWttUGBqXRs1FmkxeKR0O93x_ez5tVjutY/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
Remove Intel-only gates from dedicated 3x3/5x5 GaussianBlur kernels and
single-pass separable filter paths so AMD and other OpenCL devices can
use the same optimized implementations with existing fallbacks.
imgproc: Extended spatialGradient API and applied to different detector algorithms - #29273
imgproc: Add fused Sobel2D gradient API and use it in different detector algorithms
Add a public Sobel2D API computing dx/dy in a single fused pass with 3x3 and 5x5 kernels (SIMD-dispatched). The float (CV_32F) path folds the output scale and float store into the kernel, avoiding a separate convertTo pass.
- Add runtime SIMD dispatch for the Canny edge path.
- Integrate fused Sobel2D into:
- Canny
- cornerEigenValsVecs (cornerHarris, cornerMinEigenVal, cornerEigenValsAndVecs, goodFeaturesToTrack)
- GeneralizedHough
- IntelligentScissors
- HoughCircles
- Add performance and accuracy tests.
### 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
calib3d: fix division by zero in SGBM 3-way mode when uniquenessRatio is 100 - #29762Fixes#29761.
`SGBM3WayMainLoop` derives its uniqueness threshold in the SIMD path as `(100*min_cost)/(100-uniquenessRatio)`, so a `uniquenessRatio` of 100 divides by zero and the process dies with SIGFPE. The scalar fallback right below it, and the other SGBM modes, express the same test as `cost*(100 - uniquenessRatio) < min_cost*100`, which needs no division and copes with the value fine. `MODE_HH4` goes through `CalcHorizontalSums`, which never divides, so only `MODE_SGBM_3WAY` reproduces.
The SIMD shortcut is now skipped once `uniquenessRatio` reaches 100 and the scalar loop decides on its own, which is exactly what a build without SIMD already does. Ratios below 100 keep the fast path and produce identical output. The diff looks long because the existing block is indented one level, `?w=1` shows the real change.
The second commit fixes the neighbouring case: `thresh` grows to `100*min_cost` as the ratio approaches 100, well past `SHRT_MAX`, and `(short)(thresh+1)` wraps. On the reporter's image pair at ratio 99, 3-way marked 48723 pixels valid while `MODE_SGBM`, `MODE_HH` and `MODE_HH4` all landed near 48370; saturating brings it to 48371.
Verified with opencv_extra test data: `Calib3d_StereoSGBM.regression`, `Calib3d_StereoSGBM.deterministic`, `Calib3d_StereoSGBM_HH4.regression` and `Calib3d_StereoBM.regression` still pass. The new `Calib3d_StereoSGBM.regression_29761` aborts on unpatched 4.x under `-fsanitize=integer-divide-by-zero` and passes with the fix.
The same code sits at `modules/stereo/src/stereosgbm.cpp` on 5.x, which is the path the reporter cited. The module move means the merge will not apply cleanly, so tell me if you would rather have a separate 5.x PR.
### 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.
- [ ] The feature is well documented and sample code can be built with the project CMake
Optimize fastGEMM1T NEON: extend 4-wide to 8-wide outer loop unrolling - #29716
**PR Description:**
- This PR extends the NEON fastGEMM1T optimization by adding an 8-wide outer loop before the existing 4-wide loop. The 8-wide block processes 8 output neurons per iteration instead of 4, reducing the total number of outer loop iterations by half and sharing the vector load cost across 8 output accumulator registers instead of 4.
- On x86, the AVX2 path processes 8 floats per instruction (256-bit registers) and AVX-512 processes 16 floats per instruction (512-bit registers). On ARM, NEON is 128-bit, only 4 floats per instruction. Intel's wider registers naturally cover more outputs per inner step. This patch brings ARM NEON closer to Intel parity through wider outer loop unrolling.
**Performance results:**
<img width="1236" height="478" alt="image" src="https://github.com/user-attachments/assets/c933e64c-2200-450e-9887-3fd0cbdd5b8e" />
Notes:
- The existing 4-wide loop is retained to handle remainders when nvecs is not a multiple of 8
- No existing tests modified
- Follows the same pattern as the existing 4-wide NEON path.
- [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
core: fix JacobiSVD SIMD accumulation to match scalar path - #29727
Replace FMA with mul-add in dotD/givensD to avoid Windows MSVC rounding drift.
- Address the FMA drift introduced in https://github.com/opencv/opencv/pull/29720
### 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
* The condition under which the test `AsyncAPICancelation/cancel/0.basic` doesn't compile using GCC 11 is narrowed down to the only GCC versions which are affected: GCC 11.0 and 11.1. The issue was fixed in GCC 11.2 (verified using 11.2.0, 11.3.0, 11.4.0, 11.5.0, 12.1.0 versions of GCC).
* The corresponding issue: opencv/opencv#19678.
CV_Assert permits rvec/tvec as Size(1,3) or Size(3,1), but the
implementation only handled column vectors:
- LM path read rvec/tvec via .at<double>(i,0), OOB for a row vector.
- LM path's convertTo() write-back reallocated a local Mat alias
instead of writing in place whenever the source/dest shapes
mismatched, silently discarding the refined result for row vectors.
- VVS path's "R1 * tvec" requires a column vector; a row vector threw
a cv::Exception from gemm's shape assertion.
Fixed all three with shape-agnostic .at<double>(i) indexing and
reshape() before convertTo()/matrix arithmetic so orientation always
matches. Added Calib3d_SolvePnP.refine_row_vector covering both
solvePnPRefineLM and solvePnPRefineVVS with both orientations.
Fixes#29747
imgproc: avoid NaN in masked TM_CCOEFF_NORMED for constant templates - #29071
### 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
Fixes#23257.
This patch handles a degenerate masked `TM_CCOEFF_NORMED` case in `matchTemplate()`. When the template is constant over the effective mask area, the template norm can become zero or NaN, which may propagate NaN/Inf values into the result. The masked path now returns all ones for this case, matching the existing behavior of the unmasked `TM_CCOEFF_NORMED` implementation for constant templates.
### Tests
- `cmake --build build_project4 --target opencv_test_imgproc -j4`
- `./build_project4/bin/opencv_test_imgproc '--gtest_filter=Imgproc_MatchTemplateWithMask.regression_23257_constant_template'`
- `./build_project4/bin/opencv_test_imgproc '--gtest_filter=*MatchTemplate*'`
The MatchTemplate-related test filter ran 147 tests successfully.
allow cv::resize to support more than 4 channels in AREA path - #29691
Fixes #29651
### 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
Extracted IPP to HAL for getRectSubPix function in 4.x - #29512
### 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: Optimize AVX-512 path for accumulate - #29718
- Add AVX512_SKX/AVX512_ICL to accum dispatch
- Video_RunningAvg.accuracy failure observed in #29394 has been fixed.
### 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
Add VBLAS::dotD and VBLAS::givensD to vectorize JacobiSVDImpl_'s dot-product,
Givens rotation and norm loops with double-precision accumulation matching the
scalar path.
Dispatch lapack for both AVX512_SKX and AVX512_ICL.
gdal: skip raster band mapped to an out-of-range channel in readData - #29439
Repro: read a 3-band GDT_Byte raster (no palette) whose third band is tagged `GCI_AlphaBand`, via `imread(path, IMREAD_LOAD_GDAL)`. ASan reports a heap-buffer-overflow WRITE of size 1 at `grfmt_gdal.cpp:259`.
Cause: an alpha band makes `readData` pass `color = 3`, but the `gdalChannels == 3 && image.channels() == 3` branch of `write_pixel` indexes `Vec3b[channel]` with no bound, so `channel == 3` stores one element past the 3-lane pixel. On the last pixel that lands past the Mat buffer.
Fix (per review): `readData` checks the mapped color index against `img.channels()` in the band loop, before the pixel iteration. An out-of-range band is skipped as a whole with a `CV_LOG_WARNING` naming the band and range, instead of a silent per-pixel guard. Valid RGB rasters decode identically.
### 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
- [ ] The feature is well documented and sample code can be built with the project CMake
imgproc: add simd support for calchist & calchist1d function - #28728
- This PR adds OpenCV SIMD intrinsics-based optimizations to the Calchist and calcHist1d function for improved performance on Windows-ARM64 platforms.
- The optimized implementation uses vectorized operations to accelerate histogram computation.
- In x64 architecture, `calcHist1d` benefits from IPP-based optimized implementations. However, on ARM64 platforms, the execution falls back to scalar implementation, which results in lower performance.
- After introducing these changes, the calcHist and calchist1d function showed noticeable performance improvements on Windows-ARM64.
**Performance Benchmarks:**
<img width="1247" height="460" alt="image" src="https://github.com/user-attachments/assets/ed740d87-158e-49d4-889e-9c7dda482a63" />
<img width="552" height="210" alt="image" src="https://github.com/user-attachments/assets/76b9e46e-304e-480c-9a57-af0aba6e937a" />
- [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
imgproc: Optimized accumulate with AVX512 dispatch and AVX2 kernels improved #29394
- Add AVX512_SKX/AVX512_ICL to accum dispatch
- Fine tune AVX2 kernels for float, cn = 1 and 3 cases.
### 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
imgproc: support arbitrary channel counts in medianBlur #29638
## Summary
Fixes#29592.
`cv::medianBlur`/`cv2.medianBlur` rejects `CV_8U` images with channel counts other than 1, 3, or 4 whenever the optimized large-kernel path is needed — `ksize >= 7` always, and `ksize == 5` on SIMD-enabled builds (the `ksize == 3`/`ksize == 5`-without-SIMD "sort net" path already handles arbitrary channel counts generically, so this only affects the fast path):
```
src.depth() == CV_8U && (cn == 1 || cn == 3 || cn == 4)
```
Median filtering is channel-independent, so there's no correctness reason for this restriction — it's an implementation detail of the optimized SIMD kernels (which hard-code 1/3/4-channel-interleaved layouts), not a property of the algorithm. Users with 2, 5, 6, 9+ channel images (multispectral, feature maps, stacked masks) currently have to split, filter, and re-concatenate manually outside the library — exactly the workaround already implemented downstream in Albucore, per the issue.
## Fix
In `cv::medianBlur` (`modules/imgproc/src/median_blur.dispatch.cpp`), before dispatching to HAL/OpenCL/the optimized SIMD path: if the channel count isn't 1, 3, or 4, split the image into individual channels, run `medianBlur` on each one independently (a single channel is always supported by every existing path, recursively), and merge the results back together. This touches none of the performance-critical kernels — it's a fallback that only runs for channel counts those kernels don't support, and the existing 1/3/4-channel fast paths are completely unaffected.
## Test plan
- [x] Added `Imgproc_MedianBlur.arbitrary_channel_count_29592` in `modules/imgproc/test/test_filter.cpp`, covering channel counts `{1,2,3,4,5,6,9}` × kernel sizes `{3,5,7,9}`. For each combination it asserts `medianBlur` doesn't throw, preserves size/type, and — critically — produces output bit-identical to filtering each channel independently via `cv::split`/`cv::merge` (the reference/expected behavior).
- [x] Built `opencv_core` + `opencv_imgproc` + `opencv_test_imgproc` locally (MSVC) and ran the new test — passes.
- [x] Ran the full existing `Imgproc_MedianBlur.*`, `Imgproc_Filter2D.*`, `Imgproc_Blur.*`, `Imgproc_GaussianBlur.*` suites — all 14 pass, no regressions.
- Note: `GaussianBlurVsBitexact`, `sepFilter2D_types`, and `StackBlur` tests in the same binary fail/crash in this local environment, but reproduce identically on unmodified `4.x` with no changes at all — confirmed pre-existing and unrelated to this change (not investigated further, out of scope here).
The generated cv_cpu_helper.h sets CV_TRY_<OPT> to 1 both when <OPT> is a
dispatch target and when it is part of the baseline, but an opt_<OPT> namespace
is only emitted for the dispatch case: __ocv_add_dispatched_file() guards it
with CPU_DISPATCH_FINAL, and a baseline optimization is deliberately kept out of
that list. Code that hand-rolls "#if CV_TRY_<OPT> ... opt_<OPT>::fn" therefore
fails to compile as soon as the optimization lands in the baseline, e.g. with
-DCPU_BASELINE=AVX512_ICL or -march=native on an ICL capable CPU:
lut.dispatch.cpp:22:16: error: 'opt_AVX512_ICL' has not been declared
CV_CPU_CALL_<OPT>() already handles the namespace selection for a call. Add the
same thing for code that needs the function pointer instead:
CV_CPU_GET_FN_PTR_<OPT>(fn) per optimization
CV_CPU_GET_FN_PTR_BASELINE(fn) chain terminator
CV_CPU_DISPATCH_FN(fn, modes) full chain, mirrors CV_CPU_DISPATCH()
In the baseline case it resolves to cpu_baseline::fn, which is the <OPT> build
of the kernel, so no implementation is lost and no second copy is emitted. In
the dispatch case it keeps the cv::checkHardwareSupport() test and returns
opt_<OPT>::fn, and it compiles out when the optimization is unavailable.
Use it in the two places that hit this, which also removes the hand-written
preprocessor blocks. Generated code for the dispatch configuration is unchanged
(byte-identical .text with -DCPU_BASELINE=SSE3 -DCPU_DISPATCH=AVX512_ICL).
Fixes#29694
cvtColor's @param src promised 8U, 16U and 32F unconditionally, but the accepted
depths depend on the conversion code: CV_16U is rejected by COLOR_BGR2HSV,
COLOR_BGR2Lab, COLOR_BGR2Luv and the packed 16-bit codes, while COLOR_BGR2GRAY,
COLOR_BGR2XYZ, COLOR_BGR2YUV and RGB<->RGB accept it. That is what #26447
reported.
State it on @param src and point at the [8U]/[16U]/[32F] markers already
documented on ColorConversionCodes. The @note only said the source "must be of
an appropriate type", which is now redundant, so drop it from both functions.
demosaicing has the same problem: the Variable Number of Gradients codes accept
8-bit input only, while the other Bayer codes also accept 16-bit.
Fixes#26447
AVCodec::supported_framerates was deprecated in FFmpeg 7.1 and removed in
FFmpeg 9, so direct field access no longer builds against FFmpeg 9.
Read the supported frame rate list through avcodec_get_supported_config()
when building against libavcodec 61.13.100 or newer. That call returns the
same list plus its entry count, so the loop iterates by count instead of the
old sentinel terminator. Older FFmpeg keeps the previous field access.
