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
Disable test test that sporadically fails with OpenVINO on CI #29531
### 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
core: vectorize cv::reduce #27510
- [ ] ~reduceR_~ Dropped due to performance
- [x] reduceC_
### 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
imgproc: Optimized OpticalFlowPyrLK (PyrDownH) #28650
- Optimized Uchar PyrDown Horizontal processing intermediate storage.
- Improved horizontal processing with AVX512 vbmi ISA.
- Todo: further refinement for other archs.
### 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: Optimized remap interpolation #29507
- Add a SIMD dispatch file for remap and vectorize the single-channel (C1) in-bounds paths of bilinear, bicubic and lanczos4 interpolation (32F / 16U / 16S) using width-agnostic gather
- Dispatch the bilinear C1 path and drop the per-pixel weight-table gathers
- Widen the fixed-point coordinate map conversion
- 32F lanczos4 is kept on the scalar path: its vectorized 64-tap accumulation deviates beyond the set float accuracy tolerance
- Vectorize the bilinear inlier/outlier run detection so any-channel linear remap skips constant-status runs with SIMD instead of a per-pixel bounds test
### 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
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
Fix calibration tutorial docs, decomposeProjectionMatrix, and convertMaps performance claims #29487Fixes#25655, #26791, #27277.
Three doc fixes:
1. Calibration tutorial: rows/cols swapped, fixed np.mgrid consistency
2. decomposeProjectionMatrix: clarified transVect is camera center in homogeneous coordinates
3. convertMaps: replaced overstated 2x speed claim
### Pull Request Readiness Checklist
- [x] I agree to contribute under Apache 2 License
- [x] Not based on GPL/incompatible license
- [x] PR proposed to proper branch (4.x)
- [x] Reference to original bug report and related work
- [ ] Accuracy test, performance test, test data: N/A (doc-only)
- [x] Feature well documented and sample code buildable
Gapi doc update #29149
This PR improves G-API documentation by clarifying the introduction and kernel API pages
- fixing some spelling errors
- operator|() can now link to the overloaded version that is actually called.
- supplemented and revised the doc based on the author's annotations.
The change is documentation-only and does not affect runtime behavior. I tested the doc reconstruction of this module.
### 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
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
Enable ipp calls for sort, sortIdx#29477
Follow up on https://github.com/opencv/opencv/pull/29184
Also introduced parallelization to sort similar to #29192
Performance is up to ~17x faster per our measurements
+ ~127KB to binary size.
### 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 DynamicQuantizeLinear ONNX layer support #29018
### 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
- [x] There is a reference to the original bug report and target platform(s)
- [x] There is an accuracy test
- [ ] There is a performance test
### Description
Implements the ONNX `DynamicQuantizeLinear` operator (opset 11) for the OpenCV DNN module.
**What it does:**
- Adds `QuantizeDynamicLayer` and `DequantizeDynamicLayer` layer classes
- Registers layers and adds ONNX importer dispatch for `DynamicQuantizeLinear`
- Computes scale and zero-point at runtime from activation min/max
- Quantizes FP32 input to int8 (stored as uint8 - 128, matching OpenCV convention)
**Framework limitation & workaround:**
Due to the single-dtype-per-layer constraint in `LayerData::dtype` (see #29017), the float32 scale output cannot be passed through the CV_8S blob pipeline directly. As a workaround, the scale is encoded as 4 raw bytes in a CV_8S `{1,4}` blob using `memcpy`, and decoded by the downstream `DequantizeDynamic` layer.
**Testing:**
- Custom accuracy tests reproduce all 3 ONNX conformance test cases: `test_dynamicquantizelinear`, `test_dynamicquantizelinear_max_adjusted`, `test_dynamicquantizelinear_min_adjusted`
- Each test verifies: quantized values, scale, zero point, and round-trip dequantize accuracy
- All existing quantization regression tests pass (42/42)
**Conformance tests:**
The 6 conformance tests for `DynamicQuantizeLinear` remain in the parser denylist (they were already denylisted before this PR) because the framework cannot produce mixed-type outputs. The custom tests provide equivalent coverage.
### Files changed
- `modules/dnn/include/opencv2/dnn/all_layers.hpp` — layer class declarations
- `modules/dnn/src/init.cpp` — layer registration
- `modules/dnn/src/onnx/onnx_importer.cpp` — ONNX import dispatch
- `modules/dnn/src/int8layers/quantization_utils.cpp` — layer implementations
- `modules/dnn/test/test_onnx_importer.cpp` — custom accuracy tests
Fix#29452: Remove <complex.h> to prevent _Complex macro conflicts #29455
### 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
---
**Description:**
Resolves https://github.com/opencv/opencv/issues/29452
**Reason for the issue:**
The C99 `<complex.h>` header defines the macro `complex` on some platforms (like NetBSD with GCC 14). Because it was included before C++ `<complex>`, this caused conflicts where `std::complex<T>` was being expanded into `std::_Complex<T>`, resulting in the reported syntax errors.
**Changes made:**
- Removed the unnecessary C-style `#include <complex.h>`.
- Added a safety guard to `#undef complex` in case any transitive lapack headers attempt to define it, ensuring `std::complex` works cleanly without C-preprocessor interference.
