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.
Fixed bindings generation for Charuco boards #28517
Fixes https://github.com/opencv/opencv/issues/28512
### 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
features2d: fix heap buffer overflow in AKAZE generateDescriptorSubsample #29623
Prevent out-of-bounds write in `generateDescriptorSubsample()` during AKAZE MLDB descriptor generation when `nchannels < 3` (e.g. `nchannels = 2`).
Fixes#29613
### Summary of Changes
- **Module:** `features2d` (AKAZE)
- **Problem:** When `generateDescriptorSubsample()` is called with `nchannels < 3`, the code hardcoded 3-channel matrix index offsets (`+ 0`, `+ 1`, `+ 2`). Since `comps` allocates rows based on `nchannels * npicks`, writing to index offset `+ 2` when `nchannels = 2` causes a heap buffer overflow past the last row of `comps`.
- **Fix:** Replaced hardcoded 3-channel matrix index assignments with a dynamic loop that iterates over `0` to `nchannels - 1`.
- **Regression Test:** Added `Features2D_AKAZE.Subsample_Channels_Overflow_Fix` in `modules/features2d/test/test_akaze.cpp`.
-
### Acknowledgments
Thanks to @abhishek-gola for reviewing the test and suggesting the correct approach.
### 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 (`4.x`)
- [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
The four memset overloads in cuda4dnn document their first parameter as
src while it is called dest, and the directions are the wrong way round:
the output buffer is marked [in] and the 8-bit fill value is marked [out].
The prose above two of them already says dest, only the tags disagree.
