Intel® Integrated Performance Primitives
Community support and discussions relating to developing high-performance vision, signal, security, and storage applications.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

Bug in ippiGrayErodeBorder

Adriaan_van_Os
New Contributor I
314 Views

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

0 Kudos
9 Replies
Gennady_F_Intel
Moderator
314 Views

which version of ipp are you talking about?

Adriaan_van_Os
New Contributor I
314 Views

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
New Contributor I
314 Views

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
Employee
314 Views

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
New Contributor I
314 Views

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
New Contributor I
314 Views

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

Regards,

Adriaan van Os

 

Adriaan_van_Os
New Contributor I
314 Views

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
Employee
314 Views

Hi Adriaan van Os,

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

regards, Igor 

Adriaan_van_Os
New Contributor I
314 Views

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

Regards,

Adriaan van Os

 

Reply