js: add C++17 requirement check for Emscripten 4.0.20+ #28179
Close https://github.com/opencv/opencv/issues/28178
### 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.
- [x] The feature is well documented and sample code can be built with the project CMake
rvv_hal: fix flip inplace #28180
Fixes https://github.com/opencv/opencv/issues/28124
### 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
videoio(ios): fix NSInvalidArgumentException in VideoWriter release #28173
Summary
Fixes a crash on iOS when calling `VideoWriter::release()` in OpenCV 4.12.0.
Issue
Fixes#28165
Detailed Description
This PR resolves a regression where an `NSInvalidArgumentException` was thrown with the message ` -[NSAutoreleasePool retain]: Cannot retain an autorelease pool`.
The crash was caused by the manual usage of `NSAutoreleasePool` in the `~CvVideoWriter_AVFoundation` destructor. The local pool variable was being captured by the completion handler block passed to `[mMovieWriter finishWritingWithCompletionHandler:]`. Since `NSAutoreleasePool` instances cannot be retained, capturing them in a block causes a crash.
Changes:
- Replaced manual `NSAutoreleasePool` allocation and draining with modern `@autoreleasepool` blocks in `CvVideoWriter_AVFoundation`.
- applied this modernization to the Constructor, Destructor, and `write` methods.
- Specifically in the destructor, an inner `@autoreleasepool` is now used inside the completion block, ensuring no pool object needs to be captured from the outer scope.
Iterative Phase Correlation #28146
### 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 KleidiCV on Linux and Mac Mx by default #27640
OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1296
### 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
Update deprecated ov::element::undefined #28127
### Summary
Fixing OpenCV build error below.
Relates to OpenVINO 2026.0 updates on `ov::element::undefined` (https://github.com/openvinotoolkit/openvino/pull/32573) - replaced by `ov::element::dynamic`.
```
/home/jenkins/agent/workspace/openVINO-builder/opencv_source/opencv-opencv-f627368/modules/gapi/src/backends/ov/govbackend.cpp
[2025-12-03T21:25:54.540Z] /home/jenkins/agent/workspace/openVINO-builder/opencv_source/opencv-opencv-f627368/modules/gapi/src/backends/ov/govbackend.cpp: In function ���ov::element::Type toOV(int)���:
[2025-12-03T21:25:54.540Z] /home/jenkins/agent/workspace/openVINO-builder/opencv_source/opencv-opencv-f627368/modules/gapi/src/backends/ov/govbackend.cpp:114:25: error: ���undefined��� is not a member of ���ov::element���
[2025-12-03T21:25:54.540Z] 114 | return ov::element::undefined;
...
/home/jenkins/agent/workspace/openVINO-builder/opencv_source/opencv-opencv-f627368/modules/gapi/test/infer/gapi_infer_ov_tests.cpp
[2025-12-03T21:26:19.642Z] /home/jenkins/agent/workspace/openVINO-builder/opencv_source/opencv-opencv-f627368/modules/gapi/test/infer/gapi_infer_ov_tests.cpp: In function ���ov::element::Type opencv_test::toOV(int)���:
[2025-12-03T21:26:19.642Z] /home/jenkins/agent/workspace/openVINO-builder/opencv_source/opencv-opencv-f627368/modules/gapi/test/infer/gapi_infer_ov_tests.cpp:832:25: error: ���undefined��� is not a member of ���ov::element���
[2025-12-03T21:26:19.642Z] 832 | return ov::element::undefined;
```
### 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
Remove floating point arithmetic from angle computation in QR codes #28157
### Pull Request Readiness Checklist
resolves https://github.com/opencv/opencv/issues/24646
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.
- [x] The feature is well documented and sample code can be built with the project CMake
Test: Add regression test for LINE_4 vs LINE_8 connectivity #28120
Add test to verify correct behavior of LINE_4 (4-connected) and LINE_8 (8-connected) line drawing. This test ensures:
- LINE_4 produces staircase pattern (more pixels) for diagonal lines
- LINE_8 produces diagonal steps (fewer pixels)
- LINE_4 pixels have only horizontal/vertical neighbors (no diagonal-only)
Regression test for issue #26413 where LINE_4 and LINE_8 behaviors were swapped.
Fix ORB inconsistency for masks with values 255 and 1. #26366
### Pull Request Readiness Checklist
The PR fixes : [25974](https://github.com/opencv/opencv/issues/25974)
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
Fix JS bindings for namespaced Ptr factory return types #28143
This PR fixes an issue in the JS bindings generator for factory functions returning cv::Ptr<T> where T belongs to a namespaced class (for example cv::ximgproc::EdgeDrawing).
The generator previously produced unqualified C++ template arguments such as:
.constructor(select_overload<Ptr<EdgeDrawing>()>(&cv::ximgproc::createEdgeDrawing))
This results in invalid C++ because EdgeDrawing is not found in the global namespace.
Fixes https://github.com/opencv/opencv/issues/28130
In modules/js/generator/embindgen.py, inside both:
gen_function_binding_with_wrapper
gen_function_binding
a check is added:
When factory == True,
And the return type begins with Ptr<...>,
And the inner type is missing a namespace (::),
Ptr<T> → Ptr<class_info.cname>
This ensures the fully-qualified class name (e.g. cv::ximgproc::EdgeDrawing) is used in the generated bindings.
.constructor(select_overload<Ptr<cv::ximgproc::EdgeDrawing>()>(&cv::ximgproc::createEdgeDrawing))
Configured OpenCV with:
cmake .. -DBUILD_opencv_js=ON
Ran:
make -j gen_opencv_js_source
JS generator completed successfully without errors.
This change does not modify generated files directly — it modifies the generator logic so the correct namespace is applied automatically.
Dropped OPENCV_FOR_OPENMP_DYNAMIC_DISABLE environment varibale in favor of standard OMP_DYNAMIC #28122
Fixes: https://github.com/opencv/opencv/issues/25717
Replaces: https://github.com/opencv/opencv/pull/28084
### 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
stitching: pass warp params by value to avoid CUDA constant races #28118
### 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 the Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on 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 are accuracy tests, performance tests, and test data in the opencv_extra repository, if applicable.
The patch to opencv_extra uses the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake configuration.
Fixes#26870.
In `modules/stitching/src/cuda/build_warp_maps.cu`, the original implementation copied parameters into global GPU constant symbols:
```cpp
cudaSafeCall(cudaMemcpyToSymbol(build_warp_maps::ck_rinv, k_rinv, 9 * sizeof(float)));
cudaSafeCall(cudaMemcpyToSymbol(build_warp_maps::cr_kinv, r_kinv, 9 * sizeof(float)));
cudaSafeCall(cudaMemcpyToSymbol(build_warp_maps::cscale, &scale, sizeof(float)));
```
As discussed in the issue, this can cause race conditions when multiple warps are built concurrently. This patch removes the use of these global constant symbols and instead passes the required data as kernel parameters (a total of 11 floats encapsulated in `WarpParams`).
One potential concern is increased register pressure due to additional kernel arguments. However, based on experiments using the test case from issue #26870, there is no significant performance regression; in fact, a small speed‑up was observed.
Testing was performed on an NVIDIA GeForce RTX 4090 (single GPU).
Note: ./bin/opencv_perf_stitching did not run successfully on my system even with an unmodified git checkout, so performance was evaluated using the test case from issue #26870 instead.
catch _com_error exceptions to suppress debugger flooding #28073Resolves: #27643
This PR fixes an issue where the Microsoft Media Foundation (MSMF) backend triggers repeated C++ exceptions (_com_error) during video capture. While these exceptions are often non-fatal "first-chance" exceptions, they cause the Visual Studio debugger to break execution repeatedly, making debugging difficulty and flooding the output window.
Changes
cap_msmf.cpp: Added try-catch blocks around critical COM interaction paths.
Updated SourceReaderCB::OnReadSample (Async callback) to catch _com_error.
Updated CvCapture_MSMF::grabFrame (Synchronous grab) to catch _com_error.
Added CV_LOG_WARNING to log the error message from the caught exception, ensuring that actual errors are still visible in the logs without crashing the application or halting the debugger.
Impact
Users debugging OpenCV applications on Windows with Visual Studio will no longer be interrupted by internal MSMF exceptions when using the default backend.
The application flow remains uninterrupted even if MSMF encounters transient internal errors.
fix: set default pixel format for Aravis cameras when unsupported format #28086Fixes#26523
This PR fixes an issue where Aravis VideoCapture returns empty frames when the camera's pixel format is not explicitly set via CAP_PROP_FOURCC.
Problem:
The Aravis backend's retrieveFrame() function only processes four specific pixel formats:
- ARV_PIXEL_FORMAT_MONO_8
- ARV_PIXEL_FORMAT_BAYER_GR_8
- ARV_PIXEL_FORMAT_MONO_12
- ARV_PIXEL_FORMAT_MONO_16
If the camera has a different pixel format configured (or the camera's default format is unsupported), retrieveFrame() returns false on line 333 and all frames appear empty. This happens even though:
- The camera opens successfully (isOpened() returns true)
- The camera is capturing data
- The user has set up autotrigger and auto-exposure correctly
Root Cause:
In open() at line 271, the code retrieves the camera's current pixel format with arv_camera_get_pixel_format(). But if this format doesn't match one of the four supported formats, there's no fallback, causing all subsequent frames to fail retrieval.
Solution:
Added a check after retrieving the camera's pixel format. If the format is not one of the four supported formats, the code now:
1. Sets pixelFormat to a sensible default (MONO_8)
2. Applies this format to the camera via arv_camera_set_pixel_format()
This ensures:
- Cameras work out-of-the-box without requiring explicit CAP_PROP_FOURCC setup
- Users can still override the format with CAP_PROP_FOURCC if needed
- Behavior matches user expectations from other camera backends (V4L2, MSMF, etc.)
The default of MONO_8 was chosen because it's the most universally supported format across USB3 Vision and GigE Vision cameras.
Changes:
modules/videoio/src/cap_aravis.cpp: Added pixel format validation and default setting (10 lines)
Testing:
With this fix:
- Cameras with unsupported default formats will automatically switch to MONO_8
- The sample code from the issue works without uncommenting the CAP_PROP_FOURCC line
- Users can still explicitly set their preferred format via CAP_PROP_FOURCC
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 (4.x)
- [x] There is a reference to the original bug report and related work (issue #26523)
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
N/A - This requires specialized USB3 Vision / GigE Vision hardware not available in CI
- [x] The feature is well documented and sample code can be built with the project CMake
The fix maintains existing API behavior and makes the backend work as expected
Fix tempfile race condition on Windows (issue #19648) #28087
Fix tempfile race condition on Windows
Addresses issue #19648
Problem
The cv::tempfile() function on Windows used GetTempFileNameA() followed by an immediate DeleteFileA() call. This created a race condition where multiple OpenCV processes running simultaneously could receive the same temporary filename, leading to name collisions.
Root Cause
The previous implementation:
Called GetTempFileNameA() to generate a temp filename
Immediately deleted the file to free the name
Returned just the filename string
Between steps 2 and 3, another process could call GetTempFileNameA() and receive the same filename, causing a collision.
Solution
Replaced GetTempFileNameA() with GUID-based filename generation using CoCreateGuid(), following the same approach already used in GetTempFileNameWinRT() and Microsoft's recommendations for scenarios requiring many temp files.
Changes
modules/core/src/system.cpp:
Removed GetTempFileNameA() and DeleteFileA() calls
Added CoCreateGuid() to generate unique GUID-based filenames
Format: "ocv{GUID}" where GUID ensures uniqueness across processes
Benefits
Eliminates race condition in multi-process scenarios
No file I/O overhead from creating and deleting placeholder files
Consistent with WinRT implementation approach
Follows Microsoft best practices
Testing
Standard OpenCV test suite. The change only affects Windows temp file naming and maintains the same String return type and usage pattern.
The pointer offset to move from top-right to bottom-right was incorrect. This change corrects the pointer calculation to use the proper row stride, ensuring it lands on the correct pixel.
Fixed multiband blender memory leak 27333 #28085Fixes#27333
This PR fixes a memory leak in MultiBandBlender where memory from pyramid vectors was not being released when prepare() was called multiple times or when the blender object was reused.
Problem:
MultiBandBlender retains hundreds of MB to several GB of memory even after the blender pointer is released. The issue occurs because:
1. The resize() function on std::vector does not release memory when the new size is less than or equal to the current size
2. It only adjusts the size marker while retaining the capacity and existing data
3. When prepare() is called, the pyramid vectors are resized but old data remains allocated
Example from the bug report: Blending 14 images (1920x1080) retained ~200MB after blender.release(). With larger images, several GB could be retained.
Root Cause:
GPU path (lines 254-256): Correctly calls clear() before operations
Non-GPU path (lines 285-298): Missing clear() calls, causing resize() to retain old data
Solution:
Added .clear() calls before .resize() in the non-GPU path to match the GPU path behavior. This ensures:
- Memory from previous blend operations is released in prepare()
- Reusing a blender object doesn't accumulate memory
- Behavior is consistent between GPU and non-GPU code paths
Changes:
modules/stitching/src/blenders.cpp: Added 2 clear() calls (dst_pyr_laplace_.clear() and dst_band_weights_.clear()) before resize() in the non-GPU path
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 (4.x)
- [x] There is a reference to the original bug report and related work (issue #27333)
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
N/A - This is a memory management fix that doesn't affect algorithm behavior. Existing stitching tests verify correctness.
- [x] The feature is well documented and sample code can be built with the project CMake
The fix maintains existing API behavior, no documentation changes needed
Changed condition to correctly route LINE_8 to Line() instead of Line2().
The condition 'line_type == 1 || line_type == 4' was causing LINE_8 (value 8)
to be processed by Line2() which implements 4-connectivity, and LINE_4 (value 4)
to be processed by Line() which was implementing 8-connectivity behavior. This
resulted in swapped line connectivity.
Changed to 'line_type == 1 || line_type == 8' so LINE_8 goes to Line() with
8-connectivity and LINE_4 goes to Line2() with 4-connectivity, matching the
documented behavior where LINE_4 should produce 4-connected lines and LINE_8
should produce 8-connected lines.
Fixes#26413
Fix memory leak in pyopencv_to for path-like objects #28047
This PR fixes a memory leak in pyopencv_to when handling path-like objects (e.g., pathlib.Path).
Problem:
PyOS_FSPath() returns a new strong reference, but the code was not calling Py_XDECREF to decrement it, causing a memory leak on every call with path-like arguments.
Solution:
Store the returned reference from PyOS_FSPath() in a separate variable path_obj
Call Py_XDECREF(path_obj) on all function exit paths (both success and error paths)
This ensures proper reference counting without changing the function's behavior
Testing:
The leak can be reproduced using the steps in issue #28046 with Python built with --with-address-sanitizer. This fix ensures the reference is properly released.
Fixes#28046
Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
✓ I agree to contribute to the project under Apache 2 License.
✓ 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 (4.x)
✓ There is a reference to the original bug report and related work (#28046)
NA 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
Correct minAreaRect angle to be in range [-90, 0) #28051
### Pull Request Readiness Checklist
Box angle range over all imgproc tests is in interval `[-90, -0.0581199]`
resolves https://github.com/opencv/opencv/issues/27667
resolves https://github.com/opencv/opencv/issues/19472
resolves https://github.com/opencv/opencv/issues/24436
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
Kumataro
Alexander Smorkalov
Yuantao Feng
satyam yadav
zdenyhraz
Stefania Hergane
Dmitry Kurtaev
Ghazi-raad
Skreg
Alexander Smorkalov
shubham khatri
Vincent Rabaud
ramukhsuya
Parth Parekh
Kai Pastor
nishith-fujitsu
sinkboy-chen
Galina Bykova
Akash Arunkumar
Haodi Yao
Anshu