Bug in ippiGrayErodeBorder

[Adriaan_van_Os]

The IPP Developer Reference documents that the border parameter of the functions ippiGrayErodeBorder_8u_C1R and ippiGrayErodeBorder_32f_C1R accepts ippBorderRepl as the only type of border.

However, for application threading (which is what Intel wants us to do, for mysterious reasons) ippBorderRepl must be combined with a mask of ippBorderInMemTop, ippBorderInMemBottom, ippBorderInMemLeft and ippBorderInMemRight, depending on the location of the tile to be processed. But when ippBorderRepl is combined with ippBorderInMemTop, ippBorderInMemBottom, ippBorderInMemLeft or ippBorderInMemRight, ippiGrayErodeBorder_8u_C1R and ippiGrayErodeBorder_32f_C1R return errror ippStsBadArgErr (=-5).

Consequently, ippiGrayErodeBorder can not be application-threaded.

Now that we are at it, I wonder why there is no ippiGrayErodeBorder_16u_C1R variant.

Regards,

Adriaan van Os

[Gennady_F_Intel]

which version of ipp are you talking about?

[Adriaan_van_Os]

I checked version IPP 9.0, 2018-2 and the bug fix notes. There is no mentioning that this would have been fixed since.

Regards,

Adriaan van Os

[Adriaan_van_Os]

Same problem with ippiFilterWiener. This function doesn't even have an IppiBorderType parameter. Consequently, no ippBorderInMem mask can be passed for individual tiles. And therefore ippiFilterWiener can not be application-threaded.

Regards,

Adriaan van Os

[Igor_A_Intel]

Hi Adriaan van Os,

ippiFilterWiener is based on ROI concept and therefore can be easily application-threaded. ROI concept assumes that all required for operation pixels are available in the memory - therefore it is default implementation of the Border In Mem. The staring point of Wiener filtering operation is calculated as 

    strtSrc = (Ipp8u*)pSrc - ( mask.height - anchor.y - 1 ) * srcStep - ( mask.width - anchor.x - 1 );
 for 8u_C1R image/block/chunk/tile.

regards, Igor

[Adriaan_van_Os]

Igor,

With all respect, that doesn't work.

(1) If we set the ROI size to be an exact (un-enlarged) tile of the image, on the seams of the tiles it will be visible that there is no Wiener Filtering at the edges of the tiles;

(2) If we set the ROI size to be enlarged at the in-memory sides of the tiles, we have concurrent access of several threads to the same data; which is a recipe for disaster.

Regards,

Adriaan van Os

[Adriaan_van_Os]

Sorry, you are right, I withdraw my previous comment.

Regards,

Adriaan van Os

[Adriaan_van_Os]

Igor,

OK, tiling for ippiFilterWiener works. Still, for large kernel sizes (say 39), is ippiFilterWiener an approximation or exact ? And how could it be so fast if it is exact ? The ippiFilterWiener function doesn't seem to be completely size-independent in all cases.

Regards,

Adriaan  van Os

[Igor_A_Intel]

Hi Adriaan van Os,

ippiFilterWiner is implemented absolutely in the same way as in Matlab.

regards, Igor 

[Adriaan_van_Os]

I will reimplement the WienerFilter, compare the results and get back.

Regards,

Adriaan van Os