video: fix DISOpticalFlow heap-buffer-overflow with patch_size > border_size - #29853Fixes#20185. 4.x companion to #29715.
@asmorkalov asked to retarget #29715 to 4.x since the issue reproduces there too, but that PR's branch descends from 5.x, so literally changing its base produces an unreviewable ~2M-line diff (the two branches have diverged far beyond this module). Opening a separate PR instead: same two commits, cherry-picked cleanly onto 4.x's current tip with zero conflicts (`modules/video/src/dis_flow.cpp` is byte-for-byte identical between the branches apart from this fix).
### What / why
See #29715 for the full writeup. Summary: `DISOpticalFlowImpl` pads `I1` with a fixed 16px border, while `PatchInverseSearch`'s search-position clamp lets a patch be placed up to `patch_size - 1` px outside the image -- safe only while `patch_size <= border_size`. Since `patch_size` is user-settable with no upper bound relative to the hardcoded border, `setPatchSize()` past 16 (or a large-enough temporal-candidate flow) reads past the end of the padded buffer (confirmed via AddressSanitizer).
Fix (per review on #29715): rather than growing the persistent `border_size` object field to match `patch_size` (which a reviewer correctly flagged as the wrong place for a per-call derived quantity), the search clamp itself (`i/j_lower_limit`, `i/j_upper_limit` in `PatchInverseSearch_ParBody`) now accounts for the read window needing to stay inside the *existing* padded buffer. For `patch_size <= border_size` (every built-in preset) the bounds are algebraically identical to the originals -- `border_size` itself is untouched.
### Testing
Verified this reproduces identically on 4.x: built an ASan-instrumented Debug configuration (`core+imgproc+imgcodecs+features2d+flann+video+ts`), confirmed the crash reproduces on pristine 4.x (same crash site as the original report), confirmed it's gone with this fix, and ran the new `regression_20185_patch_larger_than_border` / `regression_20185_stress` tests (5 repeated runs) plus the full `opencv_test_video` suite -- no failures attributable to this change (everything else failing needs `opencv_extra` test data not configured in this scoped build).
### PR 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 code under GPL or another incompatible license.
- [x] The PR is proposed to the proper branch (4.x, per maintainer request on #29715).
- [x] Accuracy tests included (see above).
- [x] No public API/behavior change, so no documentation or sample updates needed.
imgproc: Optimized Moments & perf test added - #29393
- Added dispatch for moments (CV_8U, CV_16U, CV_32F and CV_64F)
- CV_16S is kept in scalar due to regresssions observed.
- Perf test added for meanShift, CamShift and matchShapes.
- Extend Moments1 perf coverage to CV_8U alongside 16/32/64-bit depths.
### 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
dnn: fix eltwise layer memory traversal pattern causing Windows-ARM64 slowdown - #29831
## Problem
- `EltwiseInvoker::operator()` (backs the `Eltwise` layer's SUM/PROD/DIV ops) ran slower on Windows-ARM64 than x64.
## Root cause
- The loop tiled the output into fixed-size blocks and looped over the **channel axis inside each block**.
- In NCHW layout, consecutive channels of the same sample sit far apart in memory (`planeSize * 4` bytes apart).
- So each block jumped between ~256 memory locations per tensor — roughly **768 concurrent strided streams** across the three tensors involved.
- Hardware prefetchers can only track a small, fixed number of streams and Windows-ARM64's prefetcher falls over on this pattern.
## Fix
- Walk the output buffer contiguously and track the current (sample, channel) plane from the offset and clamp each block so it never crosses into the next channel.
- This removes the inner channel loop entirely: one channel finishes before the next starts, so every tensor is read/written sequentially instead of jumping around.
- No behavior change, only the traversal order is different.
## Performance Benchmarks:
<img width="1479" height="208" alt="image" src="https://github.com/user-attachments/assets/0f878757-d988-4564-b166-96d80834c77e" />
core: vectorize masked norm/normDiff for remaining depths - #29815
### Summary
- The masked `cv::norm()` / `cv::norm(a, b)` kernels in `norm.simd.hpp` had SIMD specializations only for `uchar`, `ushort` and `float`.
- `schar`, `short`, `int`, `double` and `uchar` L2 paths uses the scalar implementation.
### Changes
- Added new vectorized implementations of MaskedNorm{Inf,L1,L2}_SIMD for schar, short, int, and double.
- Added new vectorized implementation of MaskedNormL2_SIMD<uchar, int>.
- Added new MaskedNormDiff{Inf,L1,L2}_SIMD implementations for double.
- Added cn == 4 v_load_deinterleave paths to the uchar L1/L2 kernels.
- Replaced the single f64 accumulator in MaskedNormL1_SIMD<float,double> with four independent ones, so the widening adds can overlap instead of each waiting on the previous.
### Performance Benchmarks
<img width="715" height="709" alt="image" src="https://github.com/user-attachments/assets/46afea06-df98-4dd4-a346-dc8cd4a065c9" />
imgproc: optimize PyrDownVecH<uchar,int,3> using v_load_deinterleave - #29811
**Summary:**
- buildPyramid on Windows-ARM64 (1920×1080, 8UC3) was ~7× slower than x64.
- Root cause: PyrDownVecH<uchar,int,3> used vx_lut_quads to gather pixels, which on NEON compiles to 80 scalar byte reads per SIMD iteration filling a stack buffer one byte at a time before loading it as a vector. The SIMD unit was effectively idle.
**Root Cause:**
- The 3-channel horizontal pass needs 5 non-contiguous source pixels per output pixel. The existing code precomputes byte-offset index arrays and calls vx_lut_quads(src, idx) five times per loop body. On NEON, vx_lut_quads is implemented as 16 individual scalar reads → vld1q_s8, so 5 calls = 80 scalar loads producing only 12 int32 outputs.
**Fix:**
- Replace the gather loop with v_load_deinterleave, which maps to vld3q_u8 on AArch64 — single instruction, loads 48 bytes and hardware-deinterleaves R/G/B in one shot
**Performance Benchmarks:**
<img width="1021" height="536" alt="image" src="https://github.com/user-attachments/assets/6c4b5d71-d096-4dfd-9bc4-4315d4e679af" />
open() used to accept only Mono8/Mono12/Mono16/BayerGR8 and silently forced
the camera to Mono8 for everything else, so color cameras were degraded to
grayscale. retrieveFrame() passed the payload through as is, leaving the
demosaicing and the bit depth of the result to the caller.
open() now enumerates the pixel formats the camera offers and picks the best
one it can decode, in this order:
1. true color - BGR8/RGB8, BGRa8/RGBa8, BGR10/12, RGB10/12,
2. Bayer CFA - BayerRG/BG/GR/GB, 8, 10, 12 and 16 bit,
3. grayscale - Mono8, Mono10, Mono12, Mono14, Mono16.
The least deep format is preferred within a group, as the result is 8 bit
anyway. Bit packed formats are not selected, their payload cannot be mapped
to a Mat without unpacking it first.
retrieveFrame() converts whatever arrives to BGR CV_8UC3: Bayer data is
demosaiced, RGB is swapped to BGR, grayscale is replicated to three
channels and deeper formats are scaled down from their significant bits.
The pixel format description is kept in a single table, which also drives
CAP_PROP_FOURCC. Both directions of the property now cover all the formats
above instead of just four, setProperty() reports failure for a fourcc the
camera cannot provide and refreshes the cached format description, which
the old code did not do.
Note that Aravis names a Bayer pattern after its top left 2x2 tile, while
OpenCV names it after the second row, so the codes are related by an
R <-> B swap: BayerRG8 is demosaiced with COLOR_BayerBG2BGR.
An explicit payload size check is added to retrieveFrame(), the frame is no
longer wrapped in a Mat without knowing the buffer is large enough.
core: fix unsigned Rect intersection for disjoint rectangles (#11988) - #29069Fixes#11988
## Problem
`Rect_<_Tp>::operator&` / `operator&=` returned a non-empty rectangle when two **unsigned** rectangles do not overlap.
### Example:
```cpp
cv::Rect_<unsigned> r1(0, 0, 1, 1);
cv::Rect_<unsigned> r2(2, 2, 1, 1);
auto inter = r1 & r2; // was [1 x 1 from (2, 2)], expected empty
```
Root cause: the previous implementation subtracted edge coordinates before checking overlap. For `unsigned _Tp`, expressions like `width - (x_max - x_min)` can underflow when rectangles are disjoint.
### Solution
Add a check for underflow
### Tests
Added regression test `Core_Rect.test_unsigned_overflow in modules/core/test/test_misc.cpp`.
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
SunRasterDecoder::readData() only called CvtPaletteToGray() when the
file contained a color palette (m_maptype == RMT_EQUAL_RGB). But
SunRasterEncoder always writes RMT_NONE (no palette), so gray_palette[]
stayed zero-initialized and FillGrayRow8() mapped every pixel to 0.
Fix: call CvtPaletteToGray() whenever reading as grayscale, regardless
of palette type. readHeader() already fills m_palette correctly via
FillGrayPalette() for the RMT_NONE case.
Add regression test Imgcodecs_SunRaster.imread_grayscale_roundtrip
that writes a full 0-255 ramp, reads it back with IMREAD_GRAYSCALE,
and checks NORM_INF == 0. Without the fix, NORM_INF == 255 (all black).
Remove the "broken (black result)" skip for ras in read_write_GRAYSCALE.
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
