In support of Optional Known Foreground Mask for Background Subtractors #4017
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.
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
x 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
Is in support to a pull request regarding, issue https://github.com/opencv/opencv/issues/26476.
Core paired pull request: https://github.com/opencv/opencv/pull/27810
This adds function templates inline with the pure virtual overloaded apply function present for background subtraction. Supporting the build of the pull request:
ximgproc: optimize Adaptive Manifold function for ARM64 #3980
### 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
- This PR introduces an ARM64-specific performance optimization in AdaptiveManifoldFilter::h_filter by applying loop unrolling.
- The optimization is guarded with #if defined(_M_ARM64) to ensure it only affects ARM64 builds.
- The optimization does not affect accuracy and maintains the same numerical behavior as the original scalar implementation.
Performance Improvements :
- The optimization significantly improves the performance of adaptive Manifold function on Windows ARM64 targets.
- The table below shows timing comparisons before and after the optimization:
<img width="1098" height="219" alt="image" src="https://github.com/user-attachments/assets/6cab9147-8ba0-4582-bdc6-e1f57989da86" />
Add missing cudaFree #3999
I found missing memory cudaFree in cv::cuda::FAST_Impl::detectAsync()
I created an issue, but did not receive a response.
https://github.com/opencv/opencv_contrib/issues/3994
### 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
- [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
- Add basic functionality test for HoughPoint2Line in XimgprocTest.java
- Add gen_dict.json to expose RO_STRICT and RO_IGNORE_BORDERS constants in Java wrapper
- Implement minimal test to verify method call and output validity
Add assert to ensure using non-overlapping memory regions #3983
This pr addresses this issue: https://github.com/opencv/opencv/issues/27429
where the user did not realize that the warpaffine function requires non-overlapping src and dst memory regions.
The code now compares the input memory regions and asserts that they do not overlap. There is also a test for this functionality.
### 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.
- [ ] The feature is well documented and sample code can be built with the project CMake
Added fastcv color conversions #3967
This pull request introduces FastCV-based color conversions:
```
COLOR_YUV2YUV444sp_NV12 //!< FastCV: YCbCr420PseudoPlanar to YCbCr444PseudoPlanar
COLOR_YUV2YUV422sp_NV12 //!< FastCV: YCbCr420PseudoPlanar to YCbCr422PseudoPlanar
COLOR_YUV422sp2YUV444sp //!< FastCV: YCbCr422PseudoPlanar to YCbCr444PseudoPlanar
COLOR_YUV422sp2YUV_NV12 //!< FastCV: YCbCr422PseudoPlanar to YCbCr420PseudoPlanar
COLOR_YUV444sp2YUV422sp //!< FastCV: YCbCr444PseudoPlanar to YCbCr422PseudoPlanar
COLOR_YUV444sp2YUV_NV12 //!< FastCV: YCbCr444PseudoPlanar to YCbCr420PseudoPlanar
COLOR_YUV2RGB565_NV12 //!< FastCV: YCbCr420PseudoPlanar to RGB565
COLOR_YUV422sp2RGB565 //!< FastCV: YCbCr422PseudoPlanar to RGB565
COLOR_YUV422sp2RGB //!< FastCV: YCbCr422PseudoPlanar to RGB888
COLOR_YUV422sp2RGBA //!< FastCV: YCbCr422PseudoPlanar to RGBA8888
COLOR_YUV444sp2RGB565 //!< FastCV: YCbCr444PseudoPlanar to RGB565
COLOR_YUV444sp2RGB //!< FastCV: YCbCr444PseudoPlanar to RGB888
COLOR_YUV444sp2RGBA //!< FastCV: YCbCr444PseudoPlanar to RGBA8888
COLOR_RGB2YUV_NV12 //!< FastCV: RGB888 to YCbCr420PseudoPlanar
COLOR_RGB5652YUV444sp //!< FastCV: RGB565 to YCbCr444PseudoPlanar
COLOR_RGB5652YUV422sp //!< FastCV: RGB565 to YCbCr422PseudoPlanar
COLOR_RGB5652YUV_NV12 //!< FastCV: RGB565 to YCbCr420PseudoPlanar
COLOR_RGB2YUV444sp //!< FastCV: RGB888 to YCbCr444PseudoPlanar
COLOR_RGB2YUV422sp //!< FastCV: RGB888 to YCbCr422PseudoPlanar
```
### 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
Fix race condition in Otsu's method #3970
I found that in some cases, Otsu's method can have two or more equal thresholds. In case of the CUDA implementation, this would create a race-condition where the last thread to write the output gets to choose which Otsu threshold to use. The resulting image from cv::cuda::threshold would be the same, but the returned threshold would vary for each run.
I solve this by first doing a poll to check if there are multiple matches with `__syncthreads_count`. If not, we can return the threshold as before. If there are more than one, the kernel does a minimum reduction to find the lowest threshold that matches the otsu score. It doesn't matter which threshold you choose as long as it is consistent, so I choose the smallest one.
I'm unsure when `__syncthreads_count` as introduced, but it is compatible with CC≥2.0. CUDA Toolkit's archive only goes back to version 8.0, but it was documented back then (https://docs.nvidia.com/cuda/archive)
### 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
Add Otsu's method to cv::cuda::threshold #3943
I implemented Otsu's method in CUDA for a separate project and want to add it to cv::cuda::threshold
I have made an effort to use existing OpenCV functions in my code, but I had some trouble with `ThresholdTypes` and `cv::cuda::calcHist`. I couldn't figure out how to include `precomp.hpp` to get the definition of `ThresholdTypes`. For `cv::cuda::calcHist` I tried adding `opencv_cudaimgproc`, but it creates a circular dependency on `cudaarithm`. I have include a simple implementation of `calcHist` so the code runs, but I would like input on how to use `cv::cuda::calcHist` instead.
### 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
Add warpAffine and resizeDown APIs in FastCV Extension #3936
- Added warpAffine function to apply affine transformations.
2x3 affine transformations for both CV_8UC1 and CV_8UC3 input
2x2 matrix-based patch extraction for grayscale images, with ROI.
- Deprecated resizeDownBy2 and resizeDownBy4 functions.
- Introduced resizeDown function to down-scale images using specified scaling factors or dimensions, supporting both single-channel (CV_8UC1) and two-channel (CV_8UC2) images.
### 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
