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>
Maksim Shabunin
Alexander Alekhin
Christoph Rackwitz
inayd
Alexander Smorkalov
Zihao Mu
lamm45
Berke
@lizhiyu3
heavyrain-lzy
Sean McBride
Kumataro
Yulv-git
eplankin
Pierre Chatelier
Artem Saratovtsev
Suleyman TURKMEN
Stefano Allegretti
Vincent Rabaud
Alexander Alekhin
Vincent Rabaud
yuki takehara
tv3141
AleksandrPanov
Tomoaki Teshima
Amir Tulegenov
Tiago De Gaspari
Xinguang Bian
thezane
danielenricocahall
Quella Zhang (Beyondsoft Corporation)
Aaron Greig
Federico Bolelli