isMaskSupported now returns false when the matcher is
created with crossCheck enabled, because the mask
path is unsupported in that mode. knnMatchImpl also
drops the mask so it cannot reach batchDistance and
trigger its mask.empty() assertion.
https://github.com/opencv/opencv/issues/22093
core: SIMD optimizations for norm, distance and Hamming APIs (5.x) #29479
- Cache normHamming SIMD impl via a function pointer to cut per-call dispatch cost (improves ORB & BRISK)
- Add masked norm and norm-diff SIMD kernels (incl. cn==4 paths) and AVX-512 dispatch for norm/stat
- Add brute-force matcher perf test
- Alternative port of PR #29335 adapted to the 5.x norm.simd.hpp structure
### 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
Replace "static inline" by "inline" in headers #29453
This fixes#29436
I also replaced CV_INLINE which can be removed in a later PR.
I can make a similar PR for 4.x if you want.
### 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
- [ ] 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
Documentation fixes, Added How to use pre-built opencv doc #29288
closes: https://github.com/opencv/opencv/issues/29263
co-authored by: @kirtijindal14 @Akansha-977
### 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.
- [x] The feature is well documented and sample code can be built with the project CMake
- Count zero lanes via v_signmask()+popcount in AVX-512 dispatch units
- Alternative port of PR #29390 adapted to the 5.x macro-based kernels, including a SIMD path for 64F.
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.
Filter2D IPP extraction to HAL for 5.x #29428
### 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
dnn: silence false-positive CPU target warning for New graph engine #29457
### 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 (`5.x`)
* [ ] There is a reference to the original bug report and related work
No existing OpenCV issue or pull request directly covers this warning. This PR is the original report and fix.
* [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Not applicable. This patch changes only diagnostic behavior for an existing CPU no-op path.
* [ ] The feature is well documented and sample code can be built with the project CMake
Not applicable. This patch adds no feature or public API.
## Summary
Suppress a misleading warning emitted when OpenCV 5 New DNN graph engine receives its default CPU target request.
`FaceDetectorYN` and `FaceRecognizerSF` call:
```cpp
net.setPreferableTarget(DNN_TARGET_CPU);
```
after loading their networks.
When New graph engine is active, target switching is not supported. OpenCV therefore currently prints:
```text
Targets are not supported by the new graph engine for now
```
However, New graph engine already executes on CPU. The CPU request does not require a target change, is ignored, and inference continues through New graph engine.
The warning therefore suggests a failed configuration or fallback to Classic DNN even though neither occurs.
## Change
Treat `DNN_TARGET_CPU` as a silent no-op when generic New graph engine is active.
```text
New graph engine + CPU target
→ no target change needed
→ return unchanged
→ no warning
New graph engine + non-CPU target
→ target remains unsupported
→ preserve existing warning
→ return unchanged
```
## Behavior before
```text
New graph engine active
→ caller requests CPU
→ request is ignored
→ warning emitted
→ inference continues on New graph engine
```
## Behavior after
```text
New graph engine active
→ caller requests CPU
→ request is ignored
→ no warning
→ inference continues on New graph engine
```
## Unchanged behavior
* New graph engine selection is unchanged.
* Inference execution is unchanged.
* CPU remains the effective target for generic New graph engine.
* Classic DNN behavior is unchanged.
* ONNX Runtime handling is unchanged.
* Non-CPU targets continue to emit the existing warning.
## Motivation
The current diagnostic is a false positive for the default CPU request. It reports unsupported target selection even though CPU is already the active execution target and inference succeeds through New graph engine.
## Testing
* Built OpenCV locally.
* Ran relevant DNN tests.
* Verified New graph engine still loads and executes affected models.
* Verified CPU target requests no longer emit the misleading warning.
* Verified non-CPU target requests retain the existing unsupported-target warning.
The Caffe importer removal (#28678) left behind the protoc-generated
opencv-caffe.pb.{cc,h} and caffe_io.{cpp,hpp}. The generated files can
only be compiled with an old libprotobuf and can no longer be
regenerated since opencv-caffe.proto was deleted, so any build with
PROTOBUF_UPDATE_FILES=ON or an external protobuf failed (#29291, #29419).
- Move the generic ReadProto* helpers, the only remaining consumers of
caffe_io (used by the TensorFlow importer), to src/protobuf_io.{hpp,cpp};
delete src/caffe and misc/caffe, and move glog_emulator.hpp to src/.
- Guard the protobuf version check so it also works with newer protobuf
where GOOGLE_PROTOBUF_VERSION is not defined.
- Drop the unconditional opencv-onnx.pb.h include from cast2_layer.cpp,
using the spec-fixed ONNX data type values instead, and update stale
readNetFromONNX/readNetFromTensorflow stubs to the current signatures
so WITH_PROTOBUF=OFF builds link again.
core: fix use-after-scope when Mat::mul() is given a scalar #29447
### Summary
`cv::Mat::mul()` called with a scalar returns a `MatExpr` that reads a dead stack slot when it is evaluated. In a normal (non-instrumented) build this produces silently wrong values as soon as the slot is reused:
```cpp
static cv::MatExpr makeExpr(const cv::Mat& m)
{
return m.mul(7); // 7.0 is a temporary double in THIS frame
}
cv::Mat matrix(2, 3, CV_32FC1, cv::Scalar(3.0f));
cv::MatExpr expr = makeExpr(matrix);
// ... any further calls reuse the dead frame ...
cv::Mat result = expr; // observed: all 0, expected: all 21
```
Under AddressSanitizer this is the `stack-use-after-scope` reported in #23577, with the same stack trace (`cvt64s` -> `convertAndUnrollScalar` -> `arithm_op` -> `multiply` -> `MatOp_Bin::assign`).
Storing the expression is the documented lazy-evaluation usage of `MatExpr`; the argument is ordinary supported API usage (`mat.hpp` itself shows `Mat C = A.mul(5/B);`).
### Root cause
A scalar argument binds to `_InputArray(const double& val)`, which records the **address** of the temporary with kind `MATX`:
```cpp
inline _InputArray::_InputArray(const double& val)
{ init(FIXED_TYPE + FIXED_SIZE + MATX + CV_64F + ACCESS_READ, &val, Size(1,1)); }
```
`Mat::mul()` then parks `m.getMat()` inside the returned `MatExpr`. For `MATX` kind, `getMat_()` returns a non-owning, non-refcounted header over that stack memory (`return Mat(sz, flags, obj);`). The temporary dies at the end of the full expression, but the `MatExpr` keeps the header, and `MatOp_Bin::assign()` later feeds it to `cv::multiply()`. `Matx`/`Vec` arguments take the same path.
`Mat::mul()` is the only `MatExpr` factory in `matrix_expressions.cpp` that takes an `InputArray`; every other scalar operand there is stored by value in the `Scalar` member (`e.s`), so no other expression path can capture a stack pointer this way.
### Fix
Snapshot the operand with `clone()` unless it is a `Mat`/`UMat`, which keep the current zero-copy behaviour: their headers are refcounted and already safe to defer. Any other `InputArray` kind (a scalar, `Matx`, `Vec`, `std::vector`, an evaluated expression) is a potentially non-owning view, so it is copied once at expression construction, off any hot path.
### Test
Adds `Core_MatExpr.mul_scalar_use_after_scope_23577` to `modules/core/test/test_operations.cpp`. It builds the expression in a helper frame and overwrites the stack before evaluating; the helpers are called through volatile function pointers so they cannot be inlined, which makes the stale read deterministic. The test fails before the fix (result is all 0 instead of all 21) and passes after. It is self-contained: no opencv_extra data is needed.
Verified locally on macOS/AArch64 (Apple clang 17, Release): full `opencv_test_core` passes, and the AddressSanitizer reproducer from the issue is clean after the fix.
Fixes#23577.
### 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
Self-contained accuracy regression test in `modules/core/test/test_operations.cpp`; no opencv_extra data required. No performance test: no existing perf test covers `Mat::mul` expression construction, and the copy happens once at expression construction, only for non-`Mat`/`UMat` operands.
- [ ] The feature is well documented and sample code can be built with the project CMake
N/A - bug fix, no new API.
Filter2D IPP migration to HAL for 4.x #29427
### 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
Merge pull request #29414 from Prasadayus:box_filter_refactor
Moving IPP functions to HAL for box_filter in Imgproc #29414
**Performance Numbers on Intel(R) Core(TM) i9-11900K:** https://docs.google.com/spreadsheets/d/1puWmOSTtAFwWjPu8J1SpuccPQvxUJU8NlFQs7mAZwL8/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
Refactoring and optimizing cvtcolor in Imgproc #29389
**Key Changes:**
1. Unified three divergent SIMD swap implementations into a single shared `v_swap` helper.
2. Consolidated the repeated `CV_8U/CV_16U/CV_32F` depth-dispatch chains into a single `CvtColorLoopDepth` template.
3. Extracted the duplicated coefficient-selection loops in the YCrCb/YUV constructors into `selectYuvCoeffs`.
4. Collapsed the shared YUV420 store logic duplicated across both decode invokers into `storeYUV420block`.
5. Generalized the inline blue-channel coefficient swaps in `color_lab.cpp` into `swapBlueCoeffsCols`/`swapBlueCoeffsRows`.
6. Added a `v_dotprod`-based SIMD path (`v_RGB2Y`/`v_RGB2UV`) for the previously scalar `RGB8toYUV422Invoker`.
7. Migrated all inline `CV_IPP_CHECK` cvtColor paths out of the dispatch files and into the IPP HAL plugin (`hal/ipp/src/color_ipp.cpp`), replacing each call site with `CALL_HAL`.
**Performance Numbers on Intel(R) Core(TM) i9-11900K**: https://docs.google.com/spreadsheets/d/1pz0aHlTeG4Ao8RT7LipgdNSjhCJz92QfZG3GmNa63hU/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
Extract IPP integration as HAL function for box_filter #29420
Backport of https://github.com/opencv/opencv/pull/29414
**Performance Numbers on Intel(R) Core(TM) i9-11900K:** https://docs.google.com/spreadsheets/d/1kMKiZWh--pH30hqsQo6j1suNw1lfQiKzSankMCMa2FI/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
core: Fix mul32f and addWeighted32f to use native f32 SIMD paths #29413
OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1388
- add 32FC1 coverage to addWeighted benchmark
- avoid intermediate double for f32 variants of scaled multiply and addWeighted.
- Relax AddWeighted 32F test tolerance to match f32 FMA semantics.
### 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
Alexander Smorkalov
Anand Mahesh
Madan mohan Manokar
Varun Jaiswal
Vincent Rabaud
Abhishek Gola
velonica0
Alexander Smorkalov
Anushka
Andrei Fedorov
Akansha-977
Scott
rmsalinas
Kenmar Francisco
MAAZIZ Adel Ayoub
orbisai0security
Prasad Ayush Kumar
Teddy-Yangjiale