My company recently switched to Ipp 9.0 Update 3 (was Ipp 7.1), and I changed our internal libraries to reflect the changes the warping functions.
After getting really strange behavior changes in our high-level code, I tracked the differences to a change in images that we used to warp with ippiWarpPerspectiveQuad_8u_[mod] (Ipp 7.1) but now warp using ippiWarpQuadCubicInit and ippiWarpPerspectiveCubic_8u_[mod] (Ipp 9.0U3):
In a few cases, the left, right, top or bottom borders (or any combination thereof) of the warped images remain completely black. I assume this is connected to the IppiBorderType behavior. Currently, I have it set to ippBorderTransp (which is documented to ignore the border pixels), changing it to ippBorderInMem however randomly(!) produces crashes somewhere in ippiWarpPerspectiveCubic.
Cubic interpolation also changed, changing the interior of the images, but let's ignore that for the moment.
Can someone please tell me the combination of settings I have to use to most closely reproduce the behavior of the deprecated ippiWarpPerspectiveQuad_8u?
Thanks and best regards,
The function ippiWarpPerspectiveCubic_8u_[mod] with the border type ippBorderInMem requires one pixel size border around the processing source image to process edge pixels of this image. That can lead to memory access violation, if there are no additional pixels that are are obtained from the out of the source image origin space.
Could you please provide the parameters of the transformation (rect->quadrangle, image sizes, processed ROI) to reproduce the differences?
Thanks for the quick reply.
Your description matches my problem very closely, and in all likelihood the crashes I experienced with ippBorderInMem were due to quadrangles on or too near the input image border.
My main question, however, is how to best reproduce the behavior of the old (IPP 7) warping functions. One did not have to specify a border type, and the input quadrangles could lie near or on the input image boundary without any problems whatsoever. The interpolation of border pixels was great.
Now, it appears I only have a choice between non-interpolated border pixels with ippBorderTransp, OR I can't warp input quadrangles near or touching the borders.
I'm going ahead right now to implement the obvious switching between the two behaviors, depending on inputQuad position, but there will still be cases where our image recognition software will not be able to reproduce the earlier behavior and performance. And I'm not even talking about less significant changes such as the no longer available non-parametric cubic interpolation, that has turned out to also be disadvantageous for us in about 0.2% of cases (which is a lot, if you aim for performances in the high 90% range).
It assumes that ippiWarpPerspectiveCubic_8u_[mod] with the border type ippBorderTransp has the behavior that is close to ippiWarpPerspectiveQuad_8u_[mod] excepting the interpolation formulas. If a new function has worse performance or incorrectly works with border pixels, it should be investigated. So I need to have the transformation parameters to reproduce the problem.