Behaviour of copyMakeBorder has changed since rev. 6954 (Bug #1756)

Added by Sergey Popov almost 13 years ago. Updated almost 13 years ago.

Status:Done Start date:2012-04-04
Priority:Normal Due date:
Assignee:Vadim Pisarevsky % Done:

0%
Category:imgproc, video
Target version:2.4.0
Affected version: Operating System:
Difficulty: HW Platform:
Pull request:

Description

The test program linked against rev. 6954 outputs [0, 1] instead of [0, 0] as it was before this revision. Replacing cv::BORDER_REPLICATE by (cv::BORDER_REPLICATE | cv::BORDER_ISOLATED) in the call to copyMakeBorder revert things back.

Is this breaking change or a bug?

test.cpp - test program (340 Bytes) Sergey Popov, 2012-04-04 12:35 pm

Associated revisions

Revision 2fded17f
Added by Vadim Pisarevsky almost 13 years ago

added notice about the changed behavior of copyMakeBorder in the case of ROI (ticket #1756)

Revision 296f76a1
Added by Andrey Pavlenko over 11 years ago

Merge pull request #1756 from alalek:ocl_workaround_memory_leaks_with_subbuffer

History

#1
Updated by Vadim Pisarevsky almost 13 years ago

thanks for the report! this seems to be the breaking change; sorry.

I updated the description of copyMakeBorder in the SVN, r7831

  • Status changed from Open to Done
  • Assignee set to Vadim Pisarevsky

#2
Updated by Sergey Popov almost 13 years ago

I should note that this change also affects on the behaviour of other OpenCV functions. For example, cv::medianBlur and cv::phaseCorrelate now use the pixels outside the ROI that may come from the previous stages of the processing and represent borders relevant for that stages or even be uninitialized.

Also available in: Atom PDF