Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.

Bug in ippiGrayErodeBorder

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

which version of ipp are you talking about?

0 Kudos
Adriaan_van_Os
New Contributor I
835 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

 

0 Kudos
Adriaan_van_Os
New Contributor I
835 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

 

0 Kudos
Igor_A_Intel
Employee
835 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

0 Kudos
Adriaan_van_Os
New Contributor I
835 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

0 Kudos
Adriaan_van_Os
New Contributor I
835 Views

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

Regards,

Adriaan van Os

 

0 Kudos
Adriaan_van_Os
New Contributor I
835 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

 

0 Kudos
Igor_A_Intel
Employee
835 Views

Hi Adriaan van Os,

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

regards, Igor 

0 Kudos
Adriaan_van_Os
New Contributor I
835 Views

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

Regards,

Adriaan van Os

 

0 Kudos
Reply