User-defined logger callback, C-style. #27154
This is a competing PR, an alternative to #27140
Both functions accept C-style pointer to static functions. Both functions allow restoring the OpenCV built-in implementation by passing in a nullptr.
- replaceWriteLogMessage
- replaceWriteLogMessageEx
This implementation is not compatible with C++ log handler objects.
This implementation has minimal thread safety, in the sense that the function pointer are stored and read atomically. But otherwise, the user-defined static functions must accept calls at all times, even after having been deregistered, because some log calls may have started before deregistering.
### 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
Notify the main GUI thread upon receiving a close event instead of when
the windows is destroyed. Additionally there was a logic error in in
GuiReceiver::isLastWindow() that is corrected.
Fixes#6479 and #20822
Fix heap buffer overflow and use after free in imgcodecs #27138
This fixes:
- https://g-issues.oss-fuzz.com/issues/405243132
- https://g-issues.oss-fuzz.com/issues/405456349
### 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.
- [ ] The feature is well documented and sample code can be built with the project CMake
Add RISC-V HAL implementation for cv::warp series #27119
This patch implements `cv_hal_remap`, `cv_hal_warpAffine` and `cv_hal_warpPerspective` using native intrinsics, optimizing the performance of `cv::remap/cv::warpAffine/cv::warpPerspective` for `CV_HAL_INTER_NEAREST/CV_HAL_INTER_LINEAR/CV_HAL_INTER_CUBIC/CV_HAL_INTER_LANCZOS4` modes.
Tested on MUSE-PI (Spacemit X60) for both gcc 14.2 and clang 20.0.
```
$ ./opencv_test_imgproc --gtest_filter="*Remap*:*Warp*"
$ ./opencv_perf_imgproc --gtest_filter="*Remap*:*remap*:*Warp*" --perf_min_samples=200 --perf_force_samples=200
```
View the full perf table here: [hal_rvv_warp.pdf](https://github.com/user-attachments/files/19403718/hal_rvv_warp.pdf)
### 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 minAreaRect and boxPoints docs (#26799) #27139
As requested from issue #26799 the docs regarding minAreaRect and boxPoints are extended specifying the order of the corners for boxPoints and the way the angle is computed for the rotated rect returned by minAreaRect
core: refactored normDiff in hal_rvv and extended with support of more data types #27115
Merge wtih https://github.com/opencv/opencv_extra/pull/1246.
### 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
Move IPP norm and normDiff to HAL #27128
Continues https://github.com/opencv/opencv/pull/26880
### 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
Initial version of IPP-based HAL for x86 and x86_64 platforms #26880
### 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
When WARP_INVERSE_MAP is used, accelerate the calculation with multi-threading #27108
### 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
GIF: Make sure to resize lzwExtraTable before each block #27081
This fixes https://g-issues.oss-fuzz.com/issues/403364362
### 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.
- [ ] The feature is well documented and sample code can be built with the project CMake
imgcodecs: gif: support animated gif without loop #26971Close#26970
### 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
core: improve norm of hal rvv #26991
Merge with https://github.com/opencv/opencv_extra/pull/1241
### 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
- [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
displayOverlay doesn't disappear after timeout #27082Fixes#26555
### Expected Behaviour
An overlay should be displayed atop an image and then disappear after `delayms` has timed out, but it doesn't. Also, `displayStatusBar` doesn't appear to set any text on the window.
### Actual Behaviour
The overlay appears but doesn't disappear unless a mouse move event happens on the image.
### Changes
- Fixed the issue with `displayOverlay` not disappearing after the timeout.
### 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.
- [ ] There is accuracy test, performance test, and test data in the opencv_extra repository, if applicable.
- [ ] The feature is well documented, and sample code can be built with the project CMake.
[HAL RVV] unify and impl polar_to_cart | add perf test #26999
### Summary
1. Implement through the existing `cv_hal_polarToCart32f` and `cv_hal_polarToCart64f` interfaces.
2. Add `polarToCart` performance tests
3. Make `cv::polarToCart` use CALL_HAL in the same way as `cv::cartToPolar`
4. To achieve the 3rd point, the original implementation was moved, and some modifications were made.
Tested through:
```sh
opencv_test_core --gtest_filter="*PolarToCart*:*Core_CartPolar_reverse*"
opencv_perf_core --gtest_filter="*PolarToCart*" --perf_min_samples=300 --perf_force_samples=300
```
### HAL performance test
***UPDATE***: Current implementation is no more depending on vlen.
**NOTE**: Due to the 4th point in the summary above, the `scalar` and `ui` test is based on the modified code of this PR. The impact of this patch on `scalar` and `ui` is evaluated in the next section, `Effect of Point 4`.
Vlen 256 (Muse Pi):
```
Name of Test scalar ui rvv ui rvv
vs vs
scalar scalar
(x-factor) (x-factor)
PolarToCart::PolarToCartFixture::(127x61, 32FC1) 0.315 0.110 0.034 2.85 9.34
PolarToCart::PolarToCartFixture::(127x61, 64FC1) 0.423 0.163 0.045 2.59 9.34
PolarToCart::PolarToCartFixture::(640x480, 32FC1) 13.695 4.325 1.278 3.17 10.71
PolarToCart::PolarToCartFixture::(640x480, 64FC1) 17.719 7.118 2.105 2.49 8.42
PolarToCart::PolarToCartFixture::(1280x720, 32FC1) 40.678 13.114 3.977 3.10 10.23
PolarToCart::PolarToCartFixture::(1280x720, 64FC1) 53.124 21.298 6.519 2.49 8.15
PolarToCart::PolarToCartFixture::(1920x1080, 32FC1) 95.158 29.465 8.894 3.23 10.70
PolarToCart::PolarToCartFixture::(1920x1080, 64FC1) 119.262 47.743 14.129 2.50 8.44
```
### Effect of Point 4
To make `cv::polarToCart` behave the same as `cv::cartToPolar`, the implementation detail of the former has been moved to the latter's location (from `mathfuncs.cpp` to `mathfuncs_core.simd.hpp`).
#### Reason for Changes:
This function works as follows:
$y = \text{mag} \times \sin(\text{angle})$ and $x = \text{mag} \times \cos(\text{angle})$. The original implementation first calculates the values of $\sin$ and $\cos$, storing the results in the output buffers $x$ and $y$, and then multiplies the result by $\text{mag}$.
However, when the function is used as an in-place operation (one of the output buffers is also an input buffer), the original implementation allocates an extra buffer to store the $\sin$ and $\cos$ values in case the $\text{mag}$ value gets overwritten. This extra buffer allocation prevents `cv::polarToCart` from functioning in the same way as `cv::cartToPolar`.
Therefore, the multiplication is now performed immediately without storing intermediate values. Since the original implementation also had AVX2 optimizations, I have applied the same optimizations to the AVX2 version of this implementation.
***UPDATE***: UI use v_sincos from #25892 now. The original implementation has AVX2 optimizations but is slower much than current UI so it's removed, and AVX2 perf test is below. Scalar implementation isn't changed because it's faster than using UI's method.
#### Test Result
`scalar` and `ui` test is done on Muse PI, and AVX2 test is done on Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz.
`scalar` test:
```
Name of Test orig pr pr
vs
orig
(x-factor)
PolarToCart::PolarToCartFixture::(127x61, 32FC1) 0.333 0.294 1.13
PolarToCart::PolarToCartFixture::(127x61, 64FC1) 0.385 0.403 0.96
PolarToCart::PolarToCartFixture::(640x480, 32FC1) 14.749 12.343 1.19
PolarToCart::PolarToCartFixture::(640x480, 64FC1) 19.419 16.743 1.16
PolarToCart::PolarToCartFixture::(1280x720, 32FC1) 44.155 37.822 1.17
PolarToCart::PolarToCartFixture::(1280x720, 64FC1) 62.108 50.358 1.23
PolarToCart::PolarToCartFixture::(1920x1080, 32FC1) 99.011 85.769 1.15
PolarToCart::PolarToCartFixture::(1920x1080, 64FC1) 127.740 112.874 1.13
```
`ui` test:
```
Name of Test orig pr pr
vs
orig
(x-factor)
PolarToCart::PolarToCartFixture::(127x61, 32FC1) 0.306 0.110 2.77
PolarToCart::PolarToCartFixture::(127x61, 64FC1) 0.455 0.163 2.79
PolarToCart::PolarToCartFixture::(640x480, 32FC1) 13.381 4.325 3.09
PolarToCart::PolarToCartFixture::(640x480, 64FC1) 21.851 7.118 3.07
PolarToCart::PolarToCartFixture::(1280x720, 32FC1) 39.975 13.114 3.05
PolarToCart::PolarToCartFixture::(1280x720, 64FC1) 67.006 21.298 3.15
PolarToCart::PolarToCartFixture::(1920x1080, 32FC1) 90.362 29.465 3.07
PolarToCart::PolarToCartFixture::(1920x1080, 64FC1) 129.637 47.743 2.72
```
AVX2 test:
```
Name of Test orig pr pr
vs
orig
(x-factor)
PolarToCart::PolarToCartFixture::(127x61, 32FC1) 0.019 0.009 2.11
PolarToCart::PolarToCartFixture::(127x61, 64FC1) 0.022 0.013 1.74
PolarToCart::PolarToCartFixture::(640x480, 32FC1) 0.788 0.355 2.22
PolarToCart::PolarToCartFixture::(640x480, 64FC1) 1.102 0.618 1.78
PolarToCart::PolarToCartFixture::(1280x720, 32FC1) 2.383 1.042 2.29
PolarToCart::PolarToCartFixture::(1280x720, 64FC1) 3.758 2.316 1.62
PolarToCart::PolarToCartFixture::(1920x1080, 32FC1) 5.577 2.559 2.18
PolarToCart::PolarToCartFixture::(1920x1080, 64FC1) 9.710 6.424 1.51
```
A slight performance loss occurs because the check for whether $mag$ is nullptr is performed with every calculation, instead of being done once per batch. This is to reuse current `SinCos_32f` function.
### 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 test for ArucoDetector::detectMarkers #27079
### Pull Request Readiness Checklist
Related to #26968 and #26922
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
[HAL RVV] reuse atan | impl cart_to_polar | add perf test #27000
Implement through the existing `cv_hal_cartToPolar32f` and `cv_hal_cartToPolar64f` interfaces.
Add `cartToPolar` performance tests.
cv_hal_rvv::fast_atan is modified to make it more reusable because it's needed in cartToPolar.
**UPDATE**: UI enabled. Since the vec type of RVV can't be stored in struct. UI implementation of `v_atan_f32` is modified. Both `fastAtan` and `cartToPolar` are affected so the test result for `atan` is also appended. I have tested the modified UI on RVV and AVX2 and no regressions appears.
Perf test done on MUSE-PI. AVX2 test done on Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz.
```sh
$ opencv_test_core --gtest_filter="*CartToPolar*:*Core_CartPolar_reverse*:*Phase*"
$ opencv_perf_core --gtest_filter="*CartToPolar*:*phase*" --perf_min_samples=300 --perf_force_samples=300
```
Test result between enabled UI and HAL:
```
Name of Test ui rvv rvv
vs
ui
(x-factor)
CartToPolar::CartToPolarFixture::(127x61, 32FC1) 0.106 0.059 1.80
CartToPolar::CartToPolarFixture::(127x61, 64FC1) 0.155 0.070 2.20
CartToPolar::CartToPolarFixture::(640x480, 32FC1) 4.188 2.317 1.81
CartToPolar::CartToPolarFixture::(640x480, 64FC1) 6.593 2.889 2.28
CartToPolar::CartToPolarFixture::(1280x720, 32FC1) 12.600 7.057 1.79
CartToPolar::CartToPolarFixture::(1280x720, 64FC1) 19.860 8.797 2.26
CartToPolar::CartToPolarFixture::(1920x1080, 32FC1) 28.295 15.809 1.79
CartToPolar::CartToPolarFixture::(1920x1080, 64FC1) 44.573 19.398 2.30
phase32f::VectorLength::128 0.002 0.002 1.20
phase32f::VectorLength::1000 0.008 0.006 1.32
phase32f::VectorLength::131072 1.061 0.731 1.45
phase32f::VectorLength::524288 3.997 2.976 1.34
phase32f::VectorLength::1048576 8.001 5.959 1.34
phase64f::VectorLength::128 0.002 0.002 1.33
phase64f::VectorLength::1000 0.012 0.008 1.58
phase64f::VectorLength::131072 1.648 0.931 1.77
phase64f::VectorLength::524288 6.836 3.837 1.78
phase64f::VectorLength::1048576 14.060 7.540 1.86
```
Test result before and after enabling UI on RVV:
```
Name of Test perf perf perf
ui ui ui
orig pr pr
vs
perf
ui
orig
(x-factor)
CartToPolar::CartToPolarFixture::(127x61, 32FC1) 0.141 0.106 1.33
CartToPolar::CartToPolarFixture::(127x61, 64FC1) 0.187 0.155 1.20
CartToPolar::CartToPolarFixture::(640x480, 32FC1) 5.990 4.188 1.43
CartToPolar::CartToPolarFixture::(640x480, 64FC1) 8.370 6.593 1.27
CartToPolar::CartToPolarFixture::(1280x720, 32FC1) 18.214 12.600 1.45
CartToPolar::CartToPolarFixture::(1280x720, 64FC1) 25.365 19.860 1.28
CartToPolar::CartToPolarFixture::(1920x1080, 32FC1) 40.437 28.295 1.43
CartToPolar::CartToPolarFixture::(1920x1080, 64FC1) 56.699 44.573 1.27
phase32f::VectorLength::128 0.003 0.002 1.54
phase32f::VectorLength::1000 0.016 0.008 1.90
phase32f::VectorLength::131072 2.048 1.061 1.93
phase32f::VectorLength::524288 8.219 3.997 2.06
phase32f::VectorLength::1048576 16.426 8.001 2.05
phase64f::VectorLength::128 0.003 0.002 1.44
phase64f::VectorLength::1000 0.020 0.012 1.60
phase64f::VectorLength::131072 2.621 1.648 1.59
phase64f::VectorLength::524288 10.780 6.836 1.58
phase64f::VectorLength::1048576 22.723 14.060 1.62
```
Test result before and after modifying UI on AVX2:
```
Name of Test perf perf perf
avx2 avx2 avx2
orig pr pr
vs
perf
avx2
orig
(x-factor)
CartToPolar::CartToPolarFixture::(127x61, 32FC1) 0.006 0.005 1.14
CartToPolar::CartToPolarFixture::(127x61, 64FC1) 0.010 0.009 1.08
CartToPolar::CartToPolarFixture::(640x480, 32FC1) 0.273 0.264 1.03
CartToPolar::CartToPolarFixture::(640x480, 64FC1) 0.511 0.487 1.05
CartToPolar::CartToPolarFixture::(1280x720, 32FC1) 0.760 0.723 1.05
CartToPolar::CartToPolarFixture::(1280x720, 64FC1) 2.009 1.937 1.04
CartToPolar::CartToPolarFixture::(1920x1080, 32FC1) 1.996 1.923 1.04
CartToPolar::CartToPolarFixture::(1920x1080, 64FC1) 5.721 5.509 1.04
phase32f::VectorLength::128 0.000 0.000 0.98
phase32f::VectorLength::1000 0.001 0.001 0.97
phase32f::VectorLength::131072 0.105 0.111 0.95
phase32f::VectorLength::524288 0.402 0.402 1.00
phase32f::VectorLength::1048576 0.775 0.767 1.01
phase64f::VectorLength::128 0.000 0.000 1.00
phase64f::VectorLength::1000 0.001 0.001 1.01
phase64f::VectorLength::131072 0.163 0.162 1.01
phase64f::VectorLength::524288 0.669 0.653 1.02
phase64f::VectorLength::1048576 1.660 1.634 1.02
```
### 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
[HAL RVV] impl magnitude | add perf test #27002
Implement through the existing `cv_hal_magnitude32f` and `cv_hal_magnitude64f` interfaces.
**UPDATE**: UI is enabled. The only difference between UI and HAL now is HAL use a approximate `sqrt`.
Perf test done on MUSE-PI.
```sh
$ opencv_test_core --gtest_filter="*Magnitude*"
$ opencv_perf_core --gtest_filter="*Magnitude*" --perf_min_samples=300 --perf_force_samples=300
```
Test result between enabled UI and HAL:
```
Name of Test ui rvv rvv
vs
ui
(x-factor)
Magnitude::MagnitudeFixture::(127x61, 32FC1) 0.029 0.016 1.75
Magnitude::MagnitudeFixture::(127x61, 64FC1) 0.057 0.036 1.57
Magnitude::MagnitudeFixture::(640x480, 32FC1) 1.063 0.648 1.64
Magnitude::MagnitudeFixture::(640x480, 64FC1) 2.261 1.530 1.48
Magnitude::MagnitudeFixture::(1280x720, 32FC1) 3.261 2.118 1.54
Magnitude::MagnitudeFixture::(1280x720, 64FC1) 6.802 4.682 1.45
Magnitude::MagnitudeFixture::(1920x1080, 32FC1) 7.287 4.738 1.54
Magnitude::MagnitudeFixture::(1920x1080, 64FC1) 15.226 10.334 1.47
```
Test result before and after enabling UI:
```
Name of Test orig pr pr
vs
orig
(x-factor)
Magnitude::MagnitudeFixture::(127x61, 32FC1) 0.032 0.029 1.11
Magnitude::MagnitudeFixture::(127x61, 64FC1) 0.067 0.057 1.17
Magnitude::MagnitudeFixture::(640x480, 32FC1) 1.228 1.063 1.16
Magnitude::MagnitudeFixture::(640x480, 64FC1) 2.786 2.261 1.23
Magnitude::MagnitudeFixture::(1280x720, 32FC1) 3.762 3.261 1.15
Magnitude::MagnitudeFixture::(1280x720, 64FC1) 8.549 6.802 1.26
Magnitude::MagnitudeFixture::(1920x1080, 32FC1) 8.408 7.287 1.15
Magnitude::MagnitudeFixture::(1920x1080, 64FC1) 18.884 15.226 1.24
```
### 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
Make sure there are enough channels to check for opacity #27040
### 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
Test for in-memory animation encoding and decoding #27013
Tests for https://github.com/opencv/opencv/pull/26964
### 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
Find contours speedup #26834
It is an attempt, as suggested by #26775, to restore lost speed when migrating `findContours()` implementation from C to C++
The patch adds an "Arena" (a pool) of pre-allocated memory so that contours points (and TreeNodes) can be picked from the Arena.
The code of `findContours()` is mostly unchanged, the arena usage being implicit through a utility class Arena::Item that provides C++ overloaded operators and construct/destruct logic.
As mentioned in #26775, the contour points are allocated and released in order, and can be represented by ranges of indices in their arena. No range subset will be released and drill a hole, that's why the internal representation as a range of indices makes sense.
The TreeNodes use another Arena class that does not comply to that range logic.
Currently, there is a significant improvement of the run-time on the test mentioned in #26775, but it is still far from the `findContours_legacy()` performance.
- [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
Added optional mask to cv::threshold #26842
Proposal for #26777
To avoid code duplication, and keep performance when no mask is used, inner implementation always propagate the const cv::Mat& mask, but they use a template<bool useMask> parameter that let the compiler optimize out unnecessary tests when the mask is not to be used.
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
core: vectorize normDiff with universal intrinsics #27042
Merge with https://github.com/opencv/opencv_extra/pull/1242.
Performance results on Desktop Intel i7-12700K, Apple M2, Jetson Orin and SpaceMIT K1:
[perf-normDiff.zip](https://github.com/user-attachments/files/19178689/perf-normDiff.zip)
### 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
- [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
Fix Aruco marker incorrect detection near image edge #26968
### Pull Request Readiness Checklist
Fix#26922
As I understood the algorithm, at the first stage we search for the contours of the marker several times (adaptive threshold with different windows sizes). Therefore, for the same marker, we get several contours (inner and outer with different sizes due to the different windows sizes). In the second stage, we group the contours for the same marker into one group, from which we take the largest contour as the best candidate (which should best match the border of the marker).
The problem is that using the `minDistanceToBorder` parameter, we discard contours at the first stage. Thus, we discard the best candidates most appropriate to the marker border, and inner contours may remain, representing a significantly smaller marker border (which we observe in the issue).
But if we use the `minDistanceToBorder` parameter to discard the best candidate of the group at the second stage, then there will be no such problems and we will completely discard markers located too close to the border of the image.
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
Update tutorials #26441
### 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.
- [ ] The feature is well documented and sample code can be built with the project CMake
