Bug in ippiErodeBorder_1u_C1R, ippiDilateBorder_1u_C1R

[Michal_K_1]

Hi,

I think I found a bug in ippiErodeBorder_1u_C1R and ippiDilateBorder_1u_C1R. 8u versions work fine. I have IPP 2017 update 3. Code:

#include <iostream>
#include "ipp.h"

int main()
{
   IppiSize roiSize = { 3, 1 };
   IppiSize maskSize = { 3, 1 };
   int iSpecSize, iBufferSize;
   IppStatus sts;

   sts = ippiMorphologyBorderGetSize_1u_C1R(roiSize, maskSize, &iSpecSize, &iBufferSize);

   IppiMorphState *pSpec = (IppiMorphState*)ippsMalloc_8u(iSpecSize);
   Ipp8u *pBuffer = ippsMalloc_8u(iBufferSize);

   Ipp8u pMask[3] = { 1, 1, 1 };

   sts = ippiMorphologyBorderInit_1u_C1R(roiSize, pMask, maskSize, pSpec, pBuffer);

   Ipp8u pSrc[1] = { 224 };
   Ipp8u pDst[1];

   sts = ippiErodeBorder_1u_C1R(pSrc, 1, 0, pDst, 1, 0, roiSize, ippBorderRepl, 0, pSpec, pBuffer);
   //sts = ippiDilateBorder_1u_C1R(pSrc, 1, 0, pDst, 1, 0, roiSize, ippBorderRepl, 0, pSpec, pBuffer);

   std::cout << (int)pDst[0] << std::endl;
   std::cin.get();

   return 0;
}

Input is 224 which is 1110 0000. Roi size is 3x1 and mask size is 3x1 with {1, 1, 1}, so the resulting first three bits with ippBorderRepl should be 111 for both erode and dilate. Instead, I get 200, which is 1100 1000.

Thanks,

Michal

[Zhen_Z_Intel]

Hi Michal,

The correct answer probably should be 0 for both erosion & dilation.

I am afraid you misunderstand the meaning for binary morphological operation. According to your code, ROI size is 3, that means only three bits will be calculated, others would be ignored. And 1u function actually process from lowest bit to higher bit that means from right to left. Thus, the lowest 3 bits will be calculated.

I checked with Windows IPP2017u3, there's indeed remains problem. The problem should be resolved in IPP2018. And there's no problem for linux IPP2017u3 version.

Best regards,
Fiona

[Michal_K_1]

Hi Fiona,

thank you for your answer and for clarifying that the bits are processed from right to left. I checked the function ippiGrayToBin and the behavior is the same. I didn't realize this and thought they are processed from left to right. In that case I am doing dilation / erosion on right bits 000, so the result should be 000, but not touch other bits - as you write.

If I do another test with 7 (0000 0111) I do get the result of 207 (1100 1111) which is correct in the corresponding bits, but corrupts the other bits. I am on Windows, so thank you for explaining this.

May I ask you what is the reason that Ipp processes bits from right to left? I am asking because the natural ordering of arrays is from left to right, so if I have Ipp8u[5] array and I want to visualize how the bit array looks like I have to reverse each byte. In our application we already use left to right ordering so unfortunately it seems we won't be able to use Ipp functions for our particular task.

In any case thank you for your help.

Best Regards,

Michal

[Zhen_Z_Intel]

Hi Michal,

If you set ROI to 7, the correct answer for binary erosion should be 64. I checked with latest IPP (2018) for Linux & Win*, no problem. Please initialize the value of pDst:

Ipp8u pDst[1]= {0};

Otherwise, in windows env, there might be some problem that those bit do not attend calculation will be set as random value.

[Michal_K_1]

OK, thank you.