videoio(gstreamer): fix timestamp drift and color negotiation on Apple #28535
This commit addresses two issues on macOS with Apple M3 hardware:
1. Replaces floating-point timestamp math with gst_util_uint64_scale_int to ensure nanosecond precision.
2. Explicitly forces I420 format in the encoding profile to prevent hardware encoder negotiation failure.
### 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: add NEON implementation for rotate function #28609
- This PR adds a NEON intrinsics-based implementation for the rotate function in matrix_transform.cpp for Windows-ARM64.
- The optimized implementation uses ARM NEON intrinsics to accelerate the internal transpose step used by the rotate function.
- In the x64 architecture, the rotate operation benefits from IPP-based optimized implementations. However, on ARM64, the execution falls back to the scalar implementation, which results in lower performance.
- To achieve performance parity with x64, a NEON-based SIMD implementation has been added for ARM64.
- After introducing these changes, the rotate function showed noticeable performance improvements on ARM64 platforms.
<img width="1009" height="817" alt="image" src="https://github.com/user-attachments/assets/8bec0041-b19c-4fc8-9103-532746224515" />
- [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
dnn: fix Resize initNgraph for two-input case #28724
## Summary
Fixes the issue #28707
When a Resize/Upsample layer has two inputs, the data tensor and a reference tensor whose **shape** defines the output spatial size, the OpenVINO/NGRAPH backend's `initNgraph()` was ignoring `nodes[1]` entirely and relying solely on the `outHeight`/`outWidth` member variables.
These variables are set by `finalize()` from the pre-computed output blob dimensions. However, when the output shape is determined dynamically at runtime from the second input, `finalize()` sets them from the live tensor, but the OpenVINO backend calls `initNgraph()` to build a static compiled graph. If the member variables are 0 at that point, the compiled `Interpolate` node gets hardcoded with `{0, 0}` output dimensions, causing CV_Assert failure: {N,C,0,0} vs {N,C,H2,W2}
Fixes#28396 : out-of-bounds read in SIMD type conversion #28397Fixes#28396Fixes#27080
The vx_load_expand function in WASM intrinsics was using
wasm_v128_load which always loads a full 128-bit register
(16 bytes), even when the function only needed 8 elements.
For example, when converting uint8 to float32:
- vx_load_expand needs 8 uint8 elements
- But wasm_v128_load reads 16 bytes from memory
- This causes an 8-byte out-of-bounds read
### 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
Optimize calibrateCamera with Schur‑complement LM and parallel Jacobian accumulation #28461
## Summary
- Optimized `calibrateCamera` for faster runtime without changing outputs using Schur‑complement LM, Parallel Jacobian accumulation, alongside other optimizations.
- Reduced time complexity from O(n^3) to O(n)
- Add a perf test that uses a 500-image chessboard dataset for performance testing.
## Performance
<img width="1200" height="800" alt="base_vs_fast_results" src="https://github.com/user-attachments/assets/6dafa19f-f9cb-4f7f-ba40-0940373712e8" />
<img width="1200" height="800" alt="fast_vs_ceres_results" src="https://github.com/user-attachments/assets/7157af27-8a2b-4810-8b53-3cc9972a8493" />
<img width="1200" height="800" alt="base_vs_fast_param_deviation" src="https://github.com/user-attachments/assets/fe4f954c-34f9-4b9a-b1b2-46e4c76ce08c" />
[Testing repo
](https://github.com/Ron12777/OpenCV-benchmarking)
## Testing
- All local tests pass
## Related
- [opencv_extra PR with test images](https://github.com/opencv/opencv_extra/pull/1312)
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
Convert exportResource() and loadResource() to use try-with-resources
to ensure InputStream, FileOutputStream, and ByteArrayOutputStream are
properly closed even when exceptions occur.
Also remove printStackTrace() in exportResource(), as the exception is
already rethrown as CvException with the original exception details.
Signed-off-by: ffccites <99155080+PDGGK@users.noreply.github.com>
Replace System.exit(-1) with exceptions in HighGui.java (#28696) #28699
## Summary
Library code should never call System.exit() as it kills the entire JVM. Replaced all 3 instances with appropriate exceptions.
Closes#28696
## Changes
- `imshow()` with empty image: `System.exit(-1)` -> `throw new IllegalArgumentException("Image is empty")`
- `waitKey()` with no windows: `System.exit(-1)` -> `throw new IllegalStateException("No windows created. Call imshow() first")`
- `waitKey()` with null window image: `System.exit(-1)` -> `throw new IllegalStateException("No image set for window: ... Call imshow() first")`
- `InterruptedException` catch: `printStackTrace()` -> `Thread.currentThread().interrupt()`
When a module is disabled in an incremental build (e.g. switching from
-DBUILD_opencv_gapi=ON to OFF), its typing stub directory persists from
the previous build. The stubs generator only creates directories for
enabled modules but never removes old ones, and the copy step merges
rather than replaces, so stale .pyi files propagate to both the loader
directory and the install prefix.
This causes type-checkers (mypy, pyright) to report errors for stubs
that reference symbols from modules that are no longer available.
Fix both propagation paths:
- generation.py: remove all subdirectories under the stubs output root
before regenerating, so only currently enabled module stubs exist in
the build directory. Top-level files (py.typed) are preserved.
- copy_typings_stubs_on_success.py: remove stale .pyi files and
py.typed markers from the loader directory before copying fresh stubs,
so leftover stubs from a previous copy are cleaned up. Runtime .py
files are not affected.
imgproc: add SIMD support for distance transform function #28636
- This PR adds OpenCV SIMD intrinsics-based optimizations to the distance transform functions for improved performance.
- The optimized implementation uses vectorized operations to accelerate the forward and backward passes of distance computation.
- In x64 architecture, distance transform function benefit 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 distance transform functions showed noticeable performance improvements on Windows-ARM64.
<img width="800" height="706" alt="image" src="https://github.com/user-attachments/assets/9786606a-9d92-489d-a5ea-d2e57453ef02" />
- [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
Fix two issues that cause `import cv2` to fail when building with
-DBUILD_opencv_gapi=OFF:
1. In `has_all_required_modules()`, the function parameter `type_node`
was ignored in favor of the enclosing scope's loop variable `node`.
This works by accident when called as `has_all_required_modules(node)`
but is incorrect — the parameter should be used directly.
2. In `__load_extra_py_code_for_module()`, only `ImportError` was
caught. When a stale gapi submodule directory exists from a previous
build, gapi/__init__.py raises `AttributeError` (not `ImportError`)
because it tries to access C++ bindings that don't exist. Now catches
both exception types for defense-in-depth.
Refs: #26098
video: Optimized ScharrDeriv#28632
- Move to CV_SIMD_SCALABLE
- avx2 & avx512 dispatch added for ScharrDeriv
### 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
Optimized flip Horizontal #28614
- Refactor flipHoriz implementation.
- Optimizations for horizontal image flipping added.
### 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
core: fix heap-buffer-overflow in YAML parseKey for empty keys #28620
### 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
### Description
Fixes https://github.com/opencv/opencv/issues/28619
Moves the "empty key" check before the backward do-while scan in `YAMLParser::parseKey()`.
**Problem:** When parsing a YAML mapping with an empty key (e.g. `: 10` at column 0), `endptr == ptr` after the forward scan finds `:`. The do-while loop `do c = *--endptr; while(c == ' ')` always executes at least once, so it decrements `endptr` to `ptr-1` and reads one byte before the heap allocation (ASan: heap-buffer-overflow READ of size 1).
**Fix:** Check `endptr == ptr` before entering the backward loop. If the key is empty, raise `CV_PARSE_ERROR_CPP("An empty key")` immediately without the OOB read.
This contribution was developed with AI assistance (Claude Code).
imgproc: fix HoughCircles Python return type to allow None #28621
### 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
### Description
Fixes https://github.com/opencv/opencv/issues/28528
`HoughCircles` returns `None` when no circles are found, but the auto-generated Python type stub declares the return type as `MatLike` without `None`. This causes type checkers (mypy/pyright) to miss potential `None` dereferences.
**Fix:** Add `HoughCircles` to `NODES_TO_REFINE` in `api_refinement.py` using the existing `make_optional_none_return` helper - the same pattern already used for `imread` and `imdecode`.
This contribution was developed with AI assistance (Claude Code).
imgproc: fix minEnclosingCircle O(n^3) worst case by adding Welzl shuffle #28548
Welzl's algorithm requires random permutation of input points to
achieve expected O(n) time. Without shuffling, sorted inputs such
as those produced by findContours() trigger O(n^3) worst case.
Fix: copy input to std::vector<PT> and apply cv::randShuffle()
before processing. Uses OpenCV's RNG so cv::setRNGSeed() ensures
reproducible behavior.
Original benchmark (5088 contour points, Release, AVX2):
findContours output: 3.93 ms → 0.033 ms (119x speedup)
Random points: 0.051 ms → 0.049 ms (no regression)
Perf test results (this PR, Release, AVX2):
| Input | N | Time |
|-------|---|------|
| Sequential circle points | 10000 | 0.03 ms |
| Sequential circle points | 5000 | 0.01 ms |
| Random points (CV_32F) | 100000 | 1.87 ms |
| Random points (CV_32S) | 100000 | 2.81 ms |
Fixes#28546
### 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
Identify ArUco markers based on threshold to reduce false positives #28289
**Goal:** parametrize the current marker identification process (pixel-based majority count) to reduce the number of false positives while maintaining high recall. Useful in high risk scenarios in which false positives are not acceptable.
**Context:** This PR builds on top of https://github.com/opencv/opencv/pull/23190 in which we've introduced a pixel-based confidence in the marker detection.
**Solution:** Include a new parameter: `validBitIdThreshold` used to identify markers based on the pixel count of each cell. Set the parameter default either to 50% which is equivalent to the current majority count implementation or to 49% which already singnificantly reduces the number of false positives (see details below).
**Test coverage:**
- Unit tests: `CV_ArucoDetectionThreshold`, `CV_InvertedArucoDetectionThreshold`
- The impact of `validBitIdThreshold` on false positives was also tested using the benchmark dataset: `MIRFLICKR-25k` https://www.kaggle.com/datasets/skfrost19/mirflickr25k which contains random images without any markers. Every marker detection is a false positive.
Example of images in the dataset:
**Results:** A threshold of 49% already allows to significantly reduce the number of false positives for the dict `DICT_4X4_1000`:
- `5942` false positives for `validBitIdThreshold = 0.5`
- `629` false positives for `validBitIdThreshold = 0.49` and `0.46`
- number of false positives divided by `9.5` when compared to `validBitIdThreshold = 0.5`
- `139` false positives for `validBitIdThreshold = 0.43` and `0.4`
- number of false positives divided by `42` when compared to `validBitIdThreshold = 0.5`
Dicts with a higher number of cells are not as impacted since it's much harder to obtain false positives. However, the less cells in a marker the further away it can be reliably detected, so the dict `DICT_4X4_1000` is commonly used.
<img width="1280" height="800" alt="false_positive_image_rate" src="https://github.com/user-attachments/assets/1a0ee16a-221d-443e-835b-022ed6dea6b0" />
In the image attached, the values of `validBitIdThreshold` tested are: `0.10f, 0.20f, 0.30f, 0.40f, 0.43f, 0.46f, 0.49f, 0.50f, 0.53f, 0.56f, 0.60f, 0.70f, 0.80f, 0.90f`
Summary of the results: [summary.csv](https://github.com/user-attachments/files/24315662/summary.csv)
Note that we can also analyse the number of false positives per marker `id`. For example, here's the histogram for the dict `DICT_4X4_1000`. (The CSV attached contains all the results)
<img width="1440" height="640" alt="false_positive_ids_DICT_4X4_1000_thr0 50" src="https://github.com/user-attachments/assets/af4f3ff8-9b8f-4682-9d51-a090c2610d8c" />
For example, the marker id 17 is detected 252 times with `validBitIdThreshold = 0.5` and only 34 times with `validBitIdThreshold = 0.49`. Looking at marker 17 (see below), we understand that this simple pattern randomly occurs in images.
<img width="447" height="441" alt="Marker17" src="https://github.com/user-attachments/assets/f5d09227-b39b-4598-94f9-b529f8300703" />
Results for every dict and every `validBitIdThreshold` [per_id.csv](https://github.com/user-attachments/files/24315667/per_id.csv)
**Missing coverage:** there is no labeled dataset with images containing markers to analyse the impact of on the recall (i.e. look at the true positive rate). For my specific use case (drones) any threshold above `0.4` allows to maintain a high recall in all conditions.
### 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
- [ ] 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: Fix OpenVINO 2026 build failure due to ov::Tensor::data() const change #28592
Fixes: https://github.com/opencv/opencv/issues/28586
### 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
### PR Description
OpenVINO 2026 changed ov::Tensor::data() to return `const void*`
instead of `void*`. This causes a build error in
modules/dnn/src/op_inf_engine.cpp when constructing a cv::Mat
wrapper over Tensor memory.
Tensor memory for input/output blobs remains mutable, but the API
now enforces const-correct access. This patch casts away const with
an explicit comment to preserve existing zero-copy semantics and
restore compatibility with OpenVINO 2026.
Preserves existing zero-copy semantics of the OpenVINO backend without altering runtime behavior.
Tested by building OpenCV 4.x against OpenVINO 2026.0.0 on Ubuntu 24.04.
In fitEllipseDirect, `double det = fabs(cv::determinant(M))` applies
fabs() unnecessarily since the next line `if (fabs(det) > 1.0e-10)`
already takes the absolute value. Remove the outer fabs() to avoid
the redundant operation.
Fix inRange type signature to accept Scalar values #28536Fixes#28534
The Python type signature for cv2.inRange was too restrictive, requiring MatLike for lowerb and upperb parameters. However, the C++ implementation accepts InputArray which includes Scalar values (tuples, floats, etc.).
This caused type checkers to incorrectly flag valid code from official tutorials as type errors.
Added make_matlike_or_scalar_arg() refinement function to create union types MatLike | Scalar for affected parameters, matching the C++ InputArray behavior.
### 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
imgcodecs(webp): improve IMWRITE_WEBP_LOSSLESS_MODE to support exact lossless compression #28519Close#28503
Add IMWRITE_WEBP_LOSSLESS_MODE enum to control lossless strategy:
- IMWRITE_WEBP_LOSSLESS_OFF: Lossy compression.
- IMWRITE_WEBP_LOSSLESS_ON: Optimize/drop color in transparent pixels.
- IMWRITE_WEBP_LOSSLESS_PRESERVE_COLOR: Preserve color in transparent pixels.
Note: Currently limited to still images; animated WebP support is deferred per YAGNI.
### 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
Vincent Rabaud
Ahmad
Alexander Smorkalov
pratham-mcw
SamareshSingh
Anshu
Alexander Smorkalov
Rohan Mistry
Adrian Kretz
ffccites
Weixie Cui
Abhishek Gola
Pavel Guzenfeld
Pavel Guzenfeld
usernotfound-101
Madan mohan Manokar
Matt Van Horn
Prasad Ayush Kumar
JoyBoy900908
Souriya Trinh
Jonas Perolini
Murat Raimbekov
ADITYA MISHRA
gideok Kim
ekharkov
Muhammad Awais
Kumataro