Added RandomNormalLike layer for fixing ViTs parsing issue #28110
closes: https://github.com/opencv/opencv/issues/27603
### 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
Introduce option to generate Java code with finalize() or Cleaners interface #28159
Closes https://github.com/opencv/opencv/issues/22260
Replaces https://github.com/opencv/opencv/pull/23467
The PR introduce configuration option to generate Java code with Cleaner interface for Java 9+ and old-fashion finalize() method for old Java and Android. Mat class and derivatives are manually written. The PR introduce 2 base classes for it depending on the generator configuration.
Pros:
1. No need to implement complex and error prone cleaner on library side.
2. No new CMake templates, easier to modify code in IDE.
Cons:
1. More generator branches and different code for modern desktop and Android.
TODO:
- [x] Add Java version check to cmake
- [x] Use Cleaners for ANDROID API 33+
### 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
Fix frame seeking with negative DTS values in FFMPEG backend #27878
**Merge with extra**: https://github.com/opencv/opencv_extra/pull/1289
Fixes https://github.com/opencv/opencv/issues/27819
Fixes https://github.com/opencv/opencv/issues/23472
Accompanied by PR on https://github.com/opencv/opencv_extra/pull/1289
The FFmpeg backend fails to correctly seek in H.264 videos that contain negative DTS values in their initial frames. This is a valid encoding practice used by modern video encoders (such as DaVinci Resolve's current export) where B-frame reordering causes the first few frames to have negative DTS values.
When picture_pts is unavailable (AV_NOPTS_VALUE), the code falls back to using pkt_dts:
`picture_pts = packet_raw.pts != AV_NOPTS_VALUE_ ? packet_raw.pts : packet_raw.dts;`
If this DTS value is negative (which is legal per H.264 spec), it propagates through the frame number calculation:
`frame_number = dts_to_frame_number(picture_pts) - first_frame_number;`
This results in negative frame numbers, messing up seeking operations.
Solution implemented in this branch is a timestamp normalization similar to FFmpegs -avoid_negative_ts_make_zero flag:
- Calculate a global offset once on the first decoded frame by getting the minimum timestamp in either:
- Container start_time
- Stream start_time
- First observed timestamp (PTS, then DTS).
- Apply the offset consistently to all timestamps, shifting negative values to begin at 0 while keeping relative timing.
- Simplify timestamp converters to remove `start_time` subtractions since timestamps are pre-normalized.
This also includes a new test `videoio_ffmpeg.seek_with_negative_dts`
This test verifies that seeking behavior performs as expected on a file which has negative DTS values in the first frames.
A PR on opencv_extra accompanies this one with that testing file: https://github.com/opencv/opencv_extra/pull/1279
```
opencv_extra=ffmpeg-videoio-negative-dts-test-data
```
<cut/>
### 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
Added 16U and 32F support in merge functions in photo module #28168
closes: https://github.com/opencv/opencv/issues/27873
### 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
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
RMSNorm: reference cpu impl #28104https://onnx.ai/onnx/operators/onnx__RMSNormalization.html
### 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
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.
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
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.