topic Igor, in Intel® Integrated Performance Primitives

Bug in ippiGrayErodeBorder

Adriaan_van_Os — Sun, 01 Mar 2020 18:01:24 GMT

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

which version of ipp are you

Gennady_F_Intel — Mon, 02 Mar 2020 02:02:01 GMT

which version of ipp are you talking about?

I checked version IPP 9.0,

Adriaan_van_Os — Mon, 02 Mar 2020 07:55:13 GMT

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

Same problem with

Adriaan_van_Os — Mon, 02 Mar 2020 15:35:05 GMT

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

Hi Adriaan van Os,

Igor_A_Intel — Mon, 02 Mar 2020 15:46:55 GMT

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

Igor,

Adriaan_van_Os — Mon, 02 Mar 2020 16:26:30 GMT

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

Sorry, you are right, I

Adriaan_van_Os — Mon, 02 Mar 2020 16:29:15 GMT

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

Regards,

Adriaan van Os

Igor,

Adriaan_van_Os — Tue, 03 Mar 2020 15:25:20 GMT

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

Hi Adriaan van Os,

Igor_A_Intel — Tue, 03 Mar 2020 18:14:55 GMT

Hi Adriaan van Os,

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

regards, Igor

I will reimplement the

Adriaan_van_Os — Wed, 04 Mar 2020 03:12:28 GMT

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

Regards,

Adriaan van Os