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.
The 16-bit icvCvt_* helpers in utils.cpp move the row pointer with
step/sizeof(x[0]) - size.width*N. sizeof is unsigned, so this is done in
unsigned math. When the caller passes step == 0, it underflows to a huge
value and the pointer goes out of range, which is undefined behavior.
The TIFF decoder hits this: it walks rows itself and calls these helpers
with step = 0, so reading a 16-bit 4-channel TIFF triggers the bug.
Cast sizeof(...) to int so the math is signed. Same result for normal
calls, no overflow when the step is 0.
Added Imgcodecs_Tiff.regression_29615_16UC4 which round-trips a CV_16UC4
TIFF in memory.
This is the 4.x version of the fix, requested in
https://github.com/opencv/opencv/pull/29620 (issue #29615).
Truncation toward zero produces incorrect interpolation indices for
negative border coordinates. Use nearest-even rounding so OpenCL remap
matches the CPU behavior.
Implemented a check to enable instrumentation for IPP HAL #29542
To enable instrumentation for IPP HAL correctly it needed to generalize a part of `private.hpp` and put it to the separate file that can be included in `private.hpp` and `ipp_utils.hpp` both to avoid duplication.
Built with `-DENABLE_INSTRUMENTATION=ON` and ran `opencv_perf_imgproc --perf_instrument=1`:
| Test | IPP weight before | IPP weight after |
|---|---|---|
| `distanceTransform` (8U->32F) | 0.0% | ~76% |
| `ippSobel` | 0.0% | ~98% |
| `scharrViaSobelFilter` | 0.0% | ~90% |
### 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
In HOGCache::init the block gaussian weights are computed into two buffers:
AutoBuffer<float> di(blockSize.height), dj(blockSize.width);
The vectorized (CV_SIMD128) loop that fills dj was bounded by
`blockSize.height` instead of `blockSize.width`. When the block is taller than
it is wide, `v_store(_dj + j, ...)` writes past the end of the width-sized dj
buffer, causing a heap buffer overflow / access violation (e.g. HOGDescriptor
with a 198x281 window, or the 2399x2400 case from the report).
Bound the dj loop by `blockSize.width` to match the buffer size and the scalar
tail loop. This keeps the SIMD path (unlike the workaround in the report, which
disabled it).
Added a regression test that computes a HOGDescriptor with a tall block; without
the fix it triggers a heap-buffer-overflow (confirmed with AddressSanitizer at
hog.cpp:731 inside HOGCache::init).
Fixes#23580
hal_rvv core: Cover more data types for split with native RVV intrinsics #29557
Covering 16-bit, 32-bit and 64-bit split.
### 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
SourceReaderCB owns an Event created for asynchronous frame delivery,
but its destructor did not close the handle. Close it when the callback
is destroyed to prevent one Event handle from leaking across repeated
MSMF capture lifecycles.
Fixes#29562
The IPP HAL (hal/ipp/src/warp_ipp.cpp) routed cv::warpAffine with
INTER_NEAREST to iwiWarpAffine for CV_16S{C1,C3,C4}, CV_64F{C1,C3,C4}
and CV_16UC4 via the non-enforced (default) impl[] dispatch table,
whose comment promises results "strictly aligned to OpenCV
implementation". That contract was broken: IPP rounds source
coordinates at the half-pixel boundary differently from the native
fixed-point kernel (warpAffineBlocklineNN, 10-bit AB_BITS), so under
rotation or fractional translation about 0.05-0.07% of destination
pixels resolve to a different source pixel. Because INTER_NEAREST does
no blending, those pixels take entirely different values, so warping
identical data as e.g. CV_16S (IPP path) versus CV_16U (native path)
produced non-identical output, and x86_64 (IPP) silently diverged from
ARM (no IPP). This is the same "Different results" behavior for which
IPP warpAffine was disabled from ~2017 through 4.11.
Zero the INTER_NEAREST column of the non-enforced dispatch table for
the affected types so the dispatch guard falls back to the native
kernel, restoring the "strictly aligned" contract. The LINEAR and
CUBIC columns for these rows were already 0, so IPP was only ever used
for NEAREST here. The IPP_CALLS_ENFORCED table is left untouched so the
opt-in performance-benchmarking build still exercises IPP.
Adds a regression test (Imgproc_Warp.regression_29279) that warps a
gradient image with INTER_NEAREST as each affected type and asserts
bit-exact equality with a native (CV_32F) reference across several
rotation angles and a fractional translation.
Fixes#29279
When a user disables a bundled image-codec dependency (e.g.
BUILD_ZLIB=OFF) to supply an external build but find_package()
cannot locate it, OpenCVFindLibsGrfmt.cmake silently falls back to
compiling the bundled 3rdparty version. As reported in the issue,
this is misleading: the editable ZLIB_LIBRARY_DEBUG/RELEASE cache
entries have no effect after the fallback and nothing points the
user at the real knob (ZLIB_ROOT / ZLIB_DIR).
Emit a message(WARNING) in each fallback branch, guarded by
NOT BUILD_<lib>, so the built-in fallback is no longer silent when
the user explicitly opted out of the bundled build. The warning
names the correct search variables for that library and points to
the CMake find_package / Find<lib> documentation. Applied
consistently to the zlib, libjpeg, libtiff, libpng and libwebp
fallback branches.
The existing fallback behavior is intentionally left unchanged, so
configurations that rely on the built-in fallback continue to build.
Fixes#26746
