Set limitation to IPP Bilateral Filter tiles number to avoid too small tiles #27720
### Pull Request Readiness Checklist
This PR fixes the following issue in Bilateral Filter tiling in IPP integration: image ROI can't be closer to the image border than the filter window radius. This issue shows itself during separation of the image to tiles for multithreaded processing. If the tile size small enough, the second tile is closer to the upper image border than the bilateral filter radius, which leads to the incorrect result. To fix this, we need a limitation to the tile size - done in this PR.
_Note: red build status looks like unrelated to the current change_
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
Improve fitEllipseDirect tests #27717
### Pull Request Readiness Checklist
Previous `fit_and_check_ellipse` implementation was very weak - it only checks that points center lies inside ellipse.
Current implementation `fit_and_check_ellipse` checks that points RMS (Root Mean Square) algebraic distance is quite small. It means that on average points are near boundary of ellipse. Because for points on ellipse algebraic distance is equal to `0` and for points that are close to boundary of ellipse is quite small
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
Fix checking that point lies inside ellipse #27704
### Pull Request Readiness Checklist
Previous `check_pt_in_ellipse` implementation was incorrect. For points on ellipse `cv::norm(to_pt)` should be equal to `el_dist`.
I tested current implementation with following Python script:
```
import cv2
import numpy as np
import matplotlib.pyplot as plt
from matplotlib.patches import Ellipse
def check_pt_in_ellipse(pt, el):
center, axes, angle = ellipse
to_pt = pt - center
el_angle = angle * np.pi / 180
to_pt_r_x = to_pt[0] * np.cos(-el_angle) - to_pt[1] * np.sin(-el_angle)
to_pt_r_y = to_pt[0] * np.sin(-el_angle) + to_pt[1] * np.cos(-el_angle)
pt_angle = np.arctan2(to_pt_r_y / axes[1], to_pt_r_x / axes[0])
x_dist = 0.5 * axes[0] * np.cos(pt_angle)
y_dist = 0.5 * axes[1] * np.sin(pt_angle)
el_dist = np.sqrt(x_dist * x_dist + y_dist * y_dist)
assert abs(np.linalg.norm(to_pt) - el_dist) < 1e-10
# TEST(Imgproc_FitEllipse_Issue_4515, accuracy) {
points = np.array([
[327, 317],
[328, 316],
[329, 315],
[330, 314],
[331, 314],
[332, 314],
[333, 315],
[333, 316],
[333, 317],
[333, 318],
[333, 319],
[333, 320],
])
ellipse = cv2.fitEllipseDirect(points)
center, axes, angle = ellipse
angle_rad = np.deg2rad(angle)
points_on_ellipse = []
for point_angle_deg in range(0, 360, 10):
point_angle = np.deg2rad(point_angle_deg)
point = np.array([0., 0.])
point_x = axes[0] * 0.5 * np.cos(point_angle)
point_y = axes[1] * 0.5 * np.sin(point_angle)
point[0] = point_x * np.cos(angle_rad) - point_y * np.sin(angle_rad)
point[1] = point_x * np.sin(angle_rad) + point_y * np.cos(angle_rad)
point[0] += center[0]
point[1] += center[1]
points_on_ellipse.append(point)
points_on_ellipse = np.array(points_on_ellipse)
for point in points_on_ellipse:
check_pt_in_ellipse(point, ellipse)
plt.figure(figsize=(8, 8))
plt.scatter(points[:, 0], points[:, 1], c='red', label='points')
plt.scatter(points_on_ellipse[:, 0], points_on_ellipse[:, 1], c='yellow', label='ellipse')
ellipse = Ellipse(xy=center, width=axes[0], height=axes[1],
angle=angle, facecolor='none', edgecolor='b')
plt.gca().add_patch(ellipse)
plt.gca().set_aspect('equal')
plt.legend()
plt.show()
```
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
Subdiv2d rect2f clean #27641
Closes https://github.com/opencv/opencv/issues/27623
Changes:
- Added Subdiv2D(Rect2f) constructor overload
- Added initDelaunay(Rect2f) method overload
- No changes to the previous implementation to keep it backward compatible
- Added tests for init and testing with edge case of extremely small coordinates
- [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
See original pull request at : https://github.com/opencv/opencv/pull/27631
imgproc: Bilateral filter performance improvement #27433
### 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
optimize some drawing with stack allocation #27599
Some drawings can try a stack allocation instead of a std::vector
### 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
Take into account overflow for connected components #27582
### Pull Request Readiness Checklist
Fix#27568
The problem was caused by a label type overflow (`debug_example.npy` contains `92103` labels, that doesn't fit in the `CV_16U` (`unsigned short`) type). If pass `CV_32S` instead of `CV_16U` as `ltype` - everything will be calculated successfully
Added overflow detection to throw exception with a clear error message instead of strange segfault/assertion error
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
Fixed build issue with some old GCC versions #27569
Fixes build for GCC 4.8.5 at least. Looks like the method default signature differs cross GCC versions or newer version has softer checker.
### 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
Issue 26972: Proper treatment of float values in intersectConvexConvex #26974
As outlined in https://github.com/opencv/opencv/issues/26972 the function `intersectConvexConvex()` may not work as expected in the corner case, where two polygons intersect at a corner. A concrete example is given that I added as unit test. The unit test would fail without the proposed bug fix. I recommend porting the fix to all versions.
Now concerning the fix: When digging into the implementation I found, that when the line intersections are computed, openCV currently does not apply floating point comparison syntax, but pretends that line end points are exact. Instead I replaced the formulation using the eps that is already used in another component of the function in line.277: `epx=1e-5`. IMO that is solid enough, definitely better than assuming an exact floating point comparison is possible.
As a follow up I would suggest to use a scalable eps, s.t. also cases with high floating point numbers would be less error prone. However that would need to be done in all relevant sub steps, not just the line intersection code. So for me outside the scope of this fix.
### 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
imgproc: vectorize cv::createHanningWindow #27368
### 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
Correct IPP distanceTransform results with single thread #27432
### Pull Request Readiness Checklist
resolves#24082
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
Add HoughCirclesWithAccumulator binding #27389
### Pull Request Readiness Checklist
Fix#27377
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#25696: Solved the problem in Subdiv2D, empty delaunay triangulation #27149
Detailed description
Expected behaviour:
Given 4 points, where no three points are collinear, the Delaunay Triangulation Algorithm should return 2 triangles.
Actual:
The algorithm returns zero triangles in this particular case.
Fix:
The radius of the circumcircle tends to infinity when the points are closer to form collinear points, so the problem occurs because the super-triangles are not large enough,
which then results in certain edges are not swapped. The proposed solution just increases the super triangle, duplicating the value of constant for example.
### 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
build: fix more warnings from recent gcc versions after #27337#27343
More fixings after https://github.com/opencv/opencv/pull/27337
### 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
Fix typos #27338
### 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
build: fix warnings from recent gcc versions #27337
This PR addresses the following found warnings:
- [x] -Wmaybe-uninitialized
- [x] -Wunused-variable
- [x] -Wsign-compare
Tested building with GCC 14.2 (RISC-V 64).
### 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
hal/imgproc: add hal for calcHist and implement in hal/riscv-rvv #27332
### 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
imgproc: medianblur: Performance improvement #27299
* Bottleneck in non-vectorized path reduced.
* AVX512 dispatch added for medianblur.
### 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
imgproc: cvtColor: remove to copy edge pixels for COLOR_Bayer*_VNGs. #27226
Close https://github.com/opencv/opencv/issues/27225
Close https://github.com/opencv/opencv/issues/5089
Related https://github.com/opencv/opencv_extra/pull/1249
### 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
Parallel_for in box Filter and support for 32f box filter in Fastcv hal #27182
Added parallel_for in box filter hal and support for 32f box filter
### 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
imgproc: disable SIMD for compareHist(INTERSECT) if f64 is unsupported #27220
Close https://github.com/opencv/opencv/issues/24757
### 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
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
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
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
Nadezhda Mizonova
MaximSmolskiy
Alexander Smorkalov
Aditya Jha
Madan mohan Manokar
Pierre Chatelier
Alexander Smorkalov
ekharkov
eplankin
Martin
Souriya Trinh
Yuantao Feng
Dmitry Kurtaev
Kavyansh Tyagi
Liane Lin
omahs
Abhishek Gola
Kumataro
YooLc
adsha-quic
天音あめ
Gianluca Nordio
Scorpion1234567
JavaTypedScript
Liutong HAN