Fix ipp_GaussianBlur will not be called with IPP enabled flag(ENABLE_… by bwang30 · Pull Request #22073 · opencv/opencv

bwang30 · 2022-06-06T03:21:49Z

Fix the issue:
Enabled ENABLE_IPP_GAUSSIAN_BLUR and flag "NE"(result no equal), OpenCV still can't step into use IPP for smoothing acceleration.

It is necessary to provide faster smooth processing with Intel IPP. In the testing on my computer(ICE lake), IPP is faster:

…IPP_GAUSSIAN_BLUR and 'NE')

alalek · 2022-06-06T14:55:14Z

@bwang30 Thank you for contribution!

Could you provide small code snippet in PR's description which is used for evaluation? (which describes used src size, src/dst data type, ROI, GaussianBlur parameters, IPP NE flag setting)

bwang30 · 2022-06-06T15:43:22Z

@alalek Thanks for the review. According to my debug, no matter what I set of ipp flag, OpenCV goes into this condition and return:

opencv/modules/imgproc/src/smooth.dispatch.cpp

Line 654 in 14754de

if(sdepth == CV_8U && ((borderType & BORDER_ISOLATED) || !_src.isSubmatrix()))

because ipp_GaussianBlur is behind of this part of code, but logically we should try to step into Intel IPP code first if we chose enabling IPP and setting ipp NE flag on for those special platforms have better performance with Intel IPP

I compiled opencv with flag WITH_IPP=ON and enabled ENABLE_IPP_GAUSSIAN_BLUR， set IPP NE flag in the envoroment varaiables. I tested more than 100 images, resized all of them to 1920x1080, src/dst data type is CV_8UC3, ROI is the whole image, and parameters are set as the code snippet:

vector<cv::Mat> srcData;
for (auto imgpath : sInputFiles)
{
    Mat img = cv::imread(imgpath, cv::IMREAD_COLOR);
    cv::Size dsize(1920, 1080);
    cv::Mat img_resized;
    cv::resize(img, img_resized, dsize, 0, 0, cv::INTER_CUBIC);
    srcData.push_back(img);
}
vector<cv::Mat> dstData(srcData.size());

cv::Size kernelsize(7, 7);
double SigmaX = 1;
double SigmaY = 1;

for (int i = 0; i < srcData.size(); i++)
{
      cv::GaussianBlur(srcData[i], dstData[i], kernelsize, SigmaX, SigmaY, bordertype);
}

alalek · 2022-06-08T13:00:43Z

sdepth == CV_8U

OpenCV for some functions (list is growing) provides guarantee of "bit-exact" result for 8U (or other integer data type) input (between platforms or used optimizations). There is no floating point computations internally, "softfloat" is used instead. This is enabled by default.

There is no IPP processing with the same result, so IPP code path is not used here.

setUseIPP_NotExact() call is related to IPP behavior, so this hint can't bypass "bit-exact" OpenCV requirement.
At first we need some OpenCV-specific hint to allow bypassing of "bit-exact" requirement in favor of speed. This need to be discussed with OpenCV dev team.

bwang30 · 2022-06-09T02:48:08Z

@alalek Thanks for your clarification. But I still have a question here:
To my understanding, you said 8U smoothing is one of "bit-exact" result functions in your list which uses "softfloat" for float calculation. So I suppose regarding of 8U smooth, OpenCV should not step into the ipp_GaussianBlur function. But as the code shows:

opencv/modules/imgproc/src/smooth.dispatch.cpp

Line 654 in 14754de

if(sdepth == CV_8U && ((borderType & BORDER_ISOLATED) || !_src.isSubmatrix()))

We just need to make _src as a submatrix and enable flag ENABLE_IPP_GAUSSIAN_BLUR, then opencv will step into ipp_GaussianBlur and get NotExact result. Is that the correct behavior?

BTW, IPP provides much better performance, I hope OpenCV can enable this feature for those functions IPP supports even the result is not bit-exact matching.

asmorkalov · 2023-04-11T10:18:34Z

@eplankin Are there any changes related to Gaussian Blur in the last IPP update? Does it pass OpenCV tests now?

eplankin · 2023-04-14T10:11:45Z

@asmorkalov AFAIK issues with bit-exactness haven't been fixed yet.
Are there any special test cases for IPP that should pass? Or running the whole GaussianBlur_Bitexact test suite with enabled ENABLE_IPP_GAUSSIAN_BLUR is enough to check whether there are still problems with bit-exactness in IPP or not?

Added flag to GaussianBlur for faster but not bit-exact implementation #25792 Rationale: Current implementation of GaussianBlur is almost always bit-exact. It helps to get predictable results according platforms, but prohibits most of approximations and optimization tricks. The patch converts `borderType` parameter to more generic `flags` and introduces `GAUSS_ALLOW_APPROXIMATIONS` flag to allow not bit-exact implementation. With the flag IPP and generic HAL implementation are called first. The flag naming and location is a subject for discussion. Replaces #22073 Possibly related issue: #24135 ### 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

asmorkalov · 2024-07-18T09:19:54Z

Replaced by #25792

Added flag to GaussianBlur for faster but not bit-exact implementation opencv#25792 Rationale: Current implementation of GaussianBlur is almost always bit-exact. It helps to get predictable results according platforms, but prohibits most of approximations and optimization tricks. The patch converts `borderType` parameter to more generic `flags` and introduces `GAUSS_ALLOW_APPROXIMATIONS` flag to allow not bit-exact implementation. With the flag IPP and generic HAL implementation are called first. The flag naming and location is a subject for discussion. Replaces opencv#22073 Possibly related issue: opencv#24135 ### 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

Added flag to GaussianBlur for faster but not bit-exact implementation opencv#25792 Rationale: Current implementation of GaussianBlur is almost always bit-exact. It helps to get predictable results according platforms, but prohibits most of approximations and optimization tricks. The patch converts `borderType` parameter to more generic `flags` and introduces `GAUSS_ALLOW_APPROXIMATIONS` flag to allow not bit-exact implementation. With the flag IPP and generic HAL implementation are called first. The flag naming and location is a subject for discussion. Replaces opencv#22073 Possibly related issue: opencv#24135 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

Added flag to GaussianBlur for faster but not bit-exact implementation opencv#25792 Rationale: Current implementation of GaussianBlur is almost always bit-exact. It helps to get predictable results according platforms, but prohibits most of approximations and optimization tricks. The patch converts `borderType` parameter to more generic `flags` and introduces `GAUSS_ALLOW_APPROXIMATIONS` flag to allow not bit-exact implementation. With the flag IPP and generic HAL implementation are called first. The flag naming and location is a subject for discussion. Replaces opencv#22073 Possibly related issue: opencv#24135 ### 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 ipp_GaussianBlur will not be called with IPP enabled flag(ENABLE_…

83f75ef

…IPP_GAUSSIAN_BLUR and 'NE')

asmorkalov added optimization category: imgproc labels Jun 6, 2022

asmorkalov mentioned this pull request Jun 20, 2024

Added flag to GaussianBlur for faster but not bit-exact implementation #25792

Merged

6 tasks

asmorkalov closed this Jul 18, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix ipp_GaussianBlur will not be called with IPP enabled flag(ENABLE_…#22073

Fix ipp_GaussianBlur will not be called with IPP enabled flag(ENABLE_…#22073
bwang30 wants to merge 1 commit intoopencv:4.xfrom
bwang30:opencv-smooth-ippfix

bwang30 commented Jun 6, 2022

Uh oh!

alalek commented Jun 6, 2022

Uh oh!

bwang30 commented Jun 6, 2022

Uh oh!

alalek commented Jun 8, 2022

Uh oh!

bwang30 commented Jun 9, 2022

Uh oh!

asmorkalov commented Apr 11, 2023

Uh oh!

eplankin commented Apr 14, 2023 •

edited

Loading

Uh oh!

asmorkalov commented Jul 18, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

bwang30 commented Jun 6, 2022

Uh oh!

alalek commented Jun 6, 2022

Uh oh!

bwang30 commented Jun 6, 2022

Uh oh!

alalek commented Jun 8, 2022

Uh oh!

bwang30 commented Jun 9, 2022

Uh oh!

asmorkalov commented Apr 11, 2023

Uh oh!

eplankin commented Apr 14, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

asmorkalov commented Jul 18, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

eplankin commented Apr 14, 2023 •

edited

Loading