imgproc: fix bit-exact GaussianBlur() / sepFilter2D()#15855
imgproc: fix bit-exact GaussianBlur() / sepFilter2D()#15855alalek merged 3 commits intoopencv:3.4from
Conversation
- avoid kernels with bad approximation - GaussiabBlur - apply error-diffusion approximation for kernel (8-bit fraction)
|
👍 |
| softdouble validation_sum = softdouble::zero(); | ||
| for (size_t i = 0; i < kernel.size(); i++) | ||
| { | ||
| validation_sum += softdouble((double)kernel[i]); |
There was a problem hiding this comment.
error: conversion from ‘__gnu_cxx::__alloc_traits<std::allocator<cv::{anonymous}::ufixedpoint16> >::value_type {aka cv::{anonymous}::ufixedpoint16}’ to ‘double’ is ambiguous
validation_sum += softdouble((double)kernel[i]);
|
Linux x86_64
…On Tue, 17 Dec 2019, 11:25 Maksim Shabunin, ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In modules/imgproc/src/smooth.dispatch.cpp
<#15855 (comment)>:
> @@ -477,6 +584,19 @@ static bool ipp_GaussianBlur(InputArray _src, OutputArray _dst, Size ksize,
}
#endif
+template<typename T>
+static bool validateGaussianBlurKernel(std::vector<T>& kernel)
+{
+ softdouble validation_sum = softdouble::zero();
+ for (size_t i = 0; i < kernel.size(); i++)
+ {
+ validation_sum += softdouble((double)kernel[i]);
@netbrain <https://github.com/netbrain> , what is your platform/compiler?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#15855?email_source=notifications&email_token=AACTNCZQH7SWG5ZRFGBKDD3QZCSIVA5CNFSM4JJUQRDKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCPN4LDQ#discussion_r358710966>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACTNC7DUGCB6WURS2CU4ALQZCSIVANCNFSM4JJUQRDA>
.
|
|
@alalek I do not think you full realize what you did by this fix. Now the speed of GaussianBlur depends on the ability to create a precise filter. That certainly works for small kernels, but not for large ones where the corner coefficients diminish. If the filter cannot be created to be precise, the blur fallbacks to float processing, which results in very high performance hit. For CV_8U images, kernel_size > 10, and reasonable sigma, the createBitExactKernel_32S always returns false. Then fallback to CV_32F computing is processed. But some of us are more interested in performance, not the precision of computation. For example, on embedded devices the slowdown is about 10 fold. Could you add an ignore flag to bitexact computation, such that the user may choose between precision (run CV_32S if possible, fallback to CV_32F) and performance (always run CV_32S version)? Right now we can propably bypass the issue by generating the kernels on our end and filtering directly. But it would be a nice feature to satisfy performance seekers. |
|
@svobora Thanks for the issue report. Could you file bug about the problem as dedicated issue with this description and link to the patch? |
Merge with contrib: opencv/opencv_contrib#2342
Merge with extra: opencv/opencv_extra#685
resolves #9863
TODO: