Skip to content

Fixed #8149 - Parallel canny on multichannel images#8341

Closed
schwittmann wants to merge 1 commit intoopencv:masterfrom
schwittmann:fix8149
Closed

Fixed #8149 - Parallel canny on multichannel images#8341
schwittmann wants to merge 1 commit intoopencv:masterfrom
schwittmann:fix8149

Conversation

@schwittmann
Copy link
Copy Markdown

resolves #8149

This pullrequest changes

As suggested by @mschoeneck in #8149 moving of _dst.create() fixes the problem - if dst gets updated to the newly created matrix, too. opencv_test_imgproc runs fine.

@alalek
Copy link
Copy Markdown
Member

alalek commented Mar 9, 2017

This patch looks very strange. It doesn't change anything for generic CPU code path, but it probably breaks OpenCL/IPP/OpenVX code paths (because they expect allocated buffers).

@schwittmann
Copy link
Copy Markdown
Author

The change introduced for the generic CPU code is subtle. If Canny is called with the same input and output matrix (Canny(tmp, tmp...)) then _dst.create() will have side effects on _src.

I had a look at the optimized code paths. OpenCL allocates its own buffer and OpenVX is disabled.

You are right about your concerns on IPP, at least I can't find an allocation there. Maybe add an additional _dst.create() here?

@alalek
Copy link
Copy Markdown
Member

alalek commented Mar 9, 2017

_dst.create() will have side effects on _src

This is bad =(
Agree, _dst's InputArray modifies _src underlying storage (cv::Mat), because they are linked to the same storage header.
InputArray invariant is broken here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Race condition in Canny(), opencv 3

2 participants