Fix distransform to work with large images #22798
This attempts to fix the following bug which was caused by storing squares of large integers into 32-bit floating point variables:
https://github.com/opencv/opencv/issues/22732
### 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
Keep inliers for linear remap with BORDER_TRANSPARENT #23754
Address https://github.com/opencv/opencv/issues/23562
### Pull Request Readiness Checklist
resolves https://github.com/opencv/opencv/issues/23562
I do think that this is a bug because with `INTER_CUBIC + BORDER_TRANSPARENT` the last column and row are preserved. So same should be done for `INTER_LINEAR`
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
imgproc: add contour values check to IntelligentScissorsMB tests
Preparation for the #21959 changes as per @asmorkalov's https://github.com/opencv/opencv/pull/21959#issuecomment-1560511500 suggestion.
### 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
better accuracy for _rotatedRectangleIntersection() (proposal for #23546) #23690
_rotatedRectangleIntersection() can be (statically) customized to use double instead of float for better accuracy
this is a proposal for experimentation around #23546
for better accuracy, _rotatedRectangleIntersection() could use double. It will still return cv::Point2f list for backward compatibility, but the inner computations are controlled by a typedef
- [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 even input dimensions for INTER_NEAREST_EXACT #23634
### Pull Request Readiness Checklist
resolves https://github.com/opencv/opencv/issues/22204
related: https://github.com/opencv/opencv/issues/9096#issuecomment-1551306017
/cc @Yosshi999
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
Usage of imread(): magic number 0, unchecked result
* docs: rewrite 0/1 to IMREAD_GRAYSCALE/IMREAD_COLOR in imread()
* samples, apps: rewrite 0/1 to IMREAD_GRAYSCALE/IMREAD_COLOR in imread()
* tests: rewrite 0/1 to IMREAD_GRAYSCALE/IMREAD_COLOR in imread()
* doc/py_tutorials: check imread() result
In some situations the last value was missing from the discrete theta
values. Now, the last value is chosen such that it is close to the
user-provided maximum theta, while the distance to pi remains always
at least theta_step/2. This should avoid duplicate detections.
A better way would probably be to use max_theta as is and adjust the
resolution (theta_step) instead, such that the discretization would
always be uniform (in a circular sense) when full angle range is used.
Replaced sprintf with safer snprintf
* Straightforward replacement of sprintf with safer snprintf
* Trickier replacement of sprintf with safer snprintf
Some functions were changed to take another parameter: the size of the buffer, so that they can pass that size on to snprintf.
Fixed out-of-bounds read in parallel version of ippGaussianBlur()
* Fixed out-of-memory read in parallel version of ippGaussianBlur()
* Fixed check
* Revert changes in CMakeLists.txt
* better accuracy of _rotatedRectangleIntersection
instead of just migrating to double-precision (which would work), some computations are scaled by a factor that depends on the length of the smallest vectors.
There is a better accuracy even with floats, so this is certainly better for very sensitive cases
* Update intersection.cpp
use L2SQR norm to tune the numeric scale
* Update intersection.cpp
adapt samePointEps with L2 norm
* Update intersection.cpp
move comment
* Update intersection.cpp
fix wrong numericalScalingFactor usage
* added tests
* fixed warnings returned by buildbot
* modifications suggested by reviewer
renaming numericalScaleFctor to normalizationScale
refactor some computations
more "const"
* modifications as suggested by reviewer
Fixed threshold(THRESH_TOZERO) at imgproc(IPP)
* Fixed#16085: imgproc(IPP): wrong result from threshold(THRESH_TOZERO)
* 1. Added test cases with float where all bits of mantissa equal 1, min and max float as inputs
2. Used nextafterf instead of cast to hex
* Used float value in test instead of hex and casts
* Changed input value in test
* Fix integer overflow in cv::Luv2RGBinteger::process.
For LL=49, uu=205, vv=23, we end up with x=7373056 and y=458
which overflows y*x.
* imgproc(test): adjust test parameters to cover SIMD code
different paddings in cvtColorTwoPlane() for biplane YUV420
* Different paddings support in cvtColorTwoPlane() for biplane YUV420
* Build fix for dispatch case.
* Resoted old behaviour for y.step==uv.step to exclude perf regressions.
Co-authored-by: amir.tulegenov <amir.tulegenov@xperience.ai>
Co-authored-by: Alexander Smorkalov <alexander.smorkalov@xperience.ai>
Update rotatedRectangleIntersection function to calculate near to origin
* Change type used in points function from RotatedRect
In the function that sets the points of a RotatedRect, the types
should be double in order to keep the precision when dealing with
RotatedRects that are defined far from the origin.
This commit solves the problem in some assertions from
rotatedRectangleIntersection when dealing with rectangles far from
origin.
* added proper type casts
* Update rotatedRectangleIntersection function to calculate near to origin
This commit changes the rotatedRectangleIntersection function in order
to calculate the intersection of two rectangles considering that they
are shifted near the coordinates origin (0, 0).
This commit solves the problem in some assertions from
rotatedRectangleIntersection when dealing with rectangles far from
origin.
* Revert type changes in types.cpp and adequate code to c++98
* Revert unnecessary casts on types.cpp
Co-authored-by: Vadim Pisarevsky <vadim.pisarevsky@gmail.com>
Also bring perf_imgproc CornerMinEigenVal accuracy requirements in line with
the test_imgproc accuracy requirements on that test and fix indentation on
the latter.
Partially addresses issue #9821
The MinEigenVal path through the corner.cl kernel makes use of native_sqrt,
a math builtin function which has implementation defined accuracy.
Partially addresses issue #9821
* goodFeaturesToTrack returns also corner value
(cherry picked from commit 4a8f06755c)
* Added response to GFTT Detector keypoints
(cherry picked from commit b88fb40c6e)
* Moved corner values to another optional variable to preserve backward compatibility
(cherry picked from commit 6137383d32)
* Removed corners valus from perf tests and better unit tests for corners values
(cherry picked from commit f3d0ef21a7)
* Fixed detector gftt call
(cherry picked from commit be2975553b)
* Restored test_cornerEigenValsVecs
(cherry picked from commit ea3e11811f)
* scaling fixed;
mineigen calculation rolled back;
gftt function overload added (with quality parameter);
perf tests were added for the new api function;
external bindings were added for the function (with different alias);
fixed issues with composition of the output array of the new function (e.g. as requested in comments) ;
added sanity checks in the perf tests;
removed C API changes.
* minor change to GFTTDetector::detect
* substitute ts->printf with EXPECT_LE
* avoid re-allocations
Co-authored-by: Anas <anas.el.amraoui@live.com>
Co-authored-by: amir.tulegenov <amir.tulegenov@xperience.ai>
