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
imgcodecs: Fix IMWRITE_AVIF_DEPTH typo and update AVIF details on imwrite() #28063
Close https://github.com/opencv/opencv/issues/28062
- Corrected the documentation for `IMWRITE_AVIF_DEPTH`.
- Added descriptions for the new AVIF encoder parameters in `imwrite()` documentation.
### 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
Fixes issue with libavif >= 1.3.0 where subsampling with identity matrix
coefficients is invalid. Aligns OpenCV AVIF writer with updated libavif
conformance rules.
Add optional template mask for findTransformECC #27952
Supersedes #22997
**Summary**
Add optional template mask support to findTransformECC so that only pixels valid in both the template and the image are used in ECC. Backward compatibility is preserved (existing signatures unchanged; one new overload adds templateMask).
**Motivation**
- Real-world frames often contain moving foreground artifacts (e.g., a football over a static field). Masking the object in one frame only is insufficient because its position changes independently of the background. Since we don’t know the warp a priori, we can’t back-project a single mask across frames. The correct approach is to supply both masks and take their intersection.
- Templates may include uninformative/low-texture or noisy regions, or partial overlaps with other objects. Excluding such regions from the alignment improves robustness and convergence.
This PR completes and replaces https://github.com/opencv/opencv/pull/22997
### 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
Handle near-zero convexity in convexHull #28043
### Pull Request Readiness Checklist
resolves https://github.com/opencv/opencv/issues/21482
closes https://github.com/opencv/opencv/issues/14401
Also skip a code that determines orientation inside rotatingCalipers and rely on the order after convexHull
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
Undistort points convergence #27993
I have looked into the `undistortPoints()` problem of issue #27916 and have found a solution. The problem is, as @Linhuihang has correctly pointed out, that the fixed-point iterations do not converge. Here are the functions which are optimized for the undistortion problem:
$$
\begin{aligned}
r^2 &= x'^2 + y'^2 \\
f_1(x') &= \frac{1 + k_4 r^2 + k_5 r^4 + k_6 r^6}{1 + k_1 r^2 + k_2 r^4 + k_3 r^6} (x'' - 2p_1 x' y' - p_2(r^2 + 2 x'^2) - s_1 r^2 + s_2 r^4) = x' \\
f_2(y') &= \frac{1 + k_4 r^2 + k_5 r^4 + k_6 r^6}{1 + k_1 r^2 + k_2 r^4 + k_3 r^6} (y'' - p_1 (r^2 + 2 y'^2) - 2 p_2 x' y' - s_3 r^2 - s_4 r^4) = y'
\end{aligned}
$$
where $x', y'$ are the undistorted points we want to compute and and $x'', y''$ are the given distorted points. This problem is solved using fixed-point iterations like
$$
x'_{k+1} = f_1(x'_k),\quad
y'_{k+1} = f_2(y'_k)
$$
I guess the issue here is that the distortion function does not necessarily satisfy the [Banach fixed-point theorem](https://en.wikipedia.org/wiki/Banach_fixed-point_theorem), i.e. the slope of the function can be too large. This can be seen in @Linhuihang's comment https://github.com/opencv/opencv/issues/27916#issuecomment-3417883642 - the point series jumps around and doesn't converge.
A common solution is to instead do damped fixed-point iterations, so that the updates are "more smooth".
$$
x'_{k+1} = (1 - \alpha) x'_k + \alpha f_1(x'_k),\quad
y'_{k+1} = (1 - \alpha) y'_k + \alpha f_2(y'_k)
$$
I have implemented a simple logic which starts with $\alpha = 1$ (so just like it is now) and reduces $\alpha$ whenever the optimization error would increase. This seems reasonable to me: the initial logic is to do normal fixed-point iterations and to gradually become "more damped" when we notice that we don't converge. Perhaps there is a better way to ensure convergence, but this is the most straightforward modification to the current code that I have found.
This problem is not due to the $\tau_x, \tau_y$ parameters; it also occurs when they are zero. In fact, the fixed-point iterations are done when the tilt correction of $\tau_x, \tau_y$ has already been applied. I have added a test to reproduce the problem. This PR fixes#27916.
### 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
make cuda::GpuMatND compatible with InputArray/OutputArray #23913
continuation of [PR#19259](https://github.com/opencv/opencv/pull/19259)
Make cuda::GpuMatND wrappable in InputArray/OutputArray
The goal for now is just wrapping, some functions are not supported (InputArray::size(), InputArray::convertTo(), InputArray::assign()...)
No new feature for cuda::GpuMatND
- [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
core: add copyAt() for ROI operation #27318
Close https://github.com/opencv/opencv/issues/27320
Close https://github.com/opencv/opencv/issues/27298
### 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
