Fixes#28095
Problem:
- Stateful kernels dereference null state pointer on line 446 in gcpukernel.hpp
- jinboson confirmed state_ptr is null on x86 Ubuntu (7 hours ago)
- Causes crash with std::shared_ptr assertion on LoongArch64 and strict platforms
Solution (addressing Copilot review feedback from PR #28096):
1. Added null pointer check using CV_Error instead of CV_Assert:
- CV_Assert with && 'message' doesn't display the message correctly
- CV_Error properly reports cv::Error::StsNullPtr with clear message
2. Fixed test kernels to properly initialize state using std::make_shared:
- GOCVStInvalidResize: Initialize state in setup()
- GOCVCountStateSetups: Initialize state before incrementing counter
- Used std::make_shared<int>() for modern C++ best practice
Impact:
- Prevents crashes on platforms with strict null pointer checking
- Provides actionable error message for developers
- Fixes StatefulKernel.StateInitOnceInRegularMode and InvalidReallocatingKernel tests
* Updated libpng to v1.6.51 and added RISC-V optimimizations.
* Force 3rdparty build for CI test.
* Added RISC-V RVV diagnostics for PNG.
* RISC-V RVV diagnostic fix.
* Disabled incorrect in-place flip HAL on RISC-V RVV.
* Disabled risc-v rvv of png_read_filter_row_paeth in libpng.
* Set PNG simd configuration defaults accornding to OpenCV settings.
* Update to libpng 1.6.52 with RISC-V RVV fix.
* Build fix for RISC-V RVV.
* Reverted CI changes.
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
Adding github CodeQL #28078
Related pipeline in CI repo: https://github.com/opencv/ci-gha-workflow/pull/280
### 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
Merge pull request #28112 from asmorkalov:as/jpeg_turbo_3.1.2
### Pull Request Readiness Checklist
Previous update: https://github.com/opencv/opencv/pull/27031
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
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
