integral problem

integral problem

Good morning dear all,

I'm currently using ippiSqrIntegral_8u32f64f_C1R to compute integral and square integral of an image. The square integral double array resulted seem to be right but it's not the case for the float integral array. So i decided to experiment the function in a simple 512x512 image entirely filled with 255 value. With this case, I expect that every value of integral array is gonna finish with "5" or "0" as it is a sum of 255 values... but i  notice that some values can finish with "4" or "7", etc... errors occur between (126,508) and (513,508)  .Here is my problem, because even if i'm wrong with the function paramters, it cannot gives float finishing with value other than "0" or "5". Thanks for any help

Here is my code :

#include <vector>

int main(){

std::vector<unsigned char> white(512*512,255);

Ipp8u* src = &white[0];

int step = 0;

Ipp32f* integral = ippiMalloc_32f_C1(512+1,521+1,&step);
Ipp64f* integral2 = (double*)malloc((512+1)*(512+1)*sizeof(double));

IppiSize roi = {w+2*R,h+2*R};
st = ippiSqrIntegral_8u32f64f_C1R(src,512*sizeof(Ipp8u),integral,(512+1)*sizeof(Ipp32f),integral2,(512+1)*sizeof(double),roi,0,0);

if(st!=ippStsNoErr)
{
std::cout << ippGetStatusString(st) << std::endl;
return 1;
}

for(int i=0 ; i<512+1 ; i++)

for(int j=0 ; j<512+1 ; j++)

{

if(*(integral + i*(512+1) + j)%5 != 0)

{

std::cout << i << "," << j << std::endl;

system("PAUSE");

}

}

return 0;

}

12 posts / 0 new
For more complete information about compiler optimizations, see our Optimization Notice.

Sorry it is :

IppiSize roi = {512,512};

What version ( update ) of IPP are you using?

>>...some values can finish with "4" or "7", etc... errors occur between (126,508) and (513,508)...

Please attach a txt-file with a complete output of the test application. Thanks.

I run w_ipp_7.1.1.119.exe to install ipp.

Here attached, you'll find the .cpp and corresponding command window output in output.txt. I notice that the problem appears for square matrices bigger than 256x256.

thankls

thanks

Attachments:

AttachmentSize
865 bytes
35.15 KB

Thanks for the output.txt file. However, I can not see your problem:

>>...some values can finish with "4" or "7", etc... errors occur between (126,508) and (513,508)...

and there are no any substrings 126,508 or 513,508 in the file.

I just copy-pasted the ouput of command window but the buffer of this window is not big enough to contain all value (it begins only from i=493,j=310). So, i now write directly values in .txt. Please find attached the corresponding output.txt and the .cpp file (where you can change the size of matrix and regenerate output.txt). I don't know why but now , first wrong value occurs at i=129,j=511 (not 126,508) and last one occurs at i=512,j=321 (not 513,508).

Thanks for you help.

Attachments:

AttachmentSize
915 bytes
805.99 KB

Hi Sergey, any news about integral function... thanks a lot for your help

Hi Youcef,

Due to limited width of Ipp32f fraction we cannot expect, that adding 255 to Ipp32f value we'll be getting multiple of 5 indefinitely. Look at the code:

```    Ipp32f sum = 0.;
int i;
for(i = 0; i < 512*512; i++) {
sum += (Ipp32f) 255;
if((sum/5 - (int)(sum/5)) != 0) {
printf("i=%d, sum=%fn", i, sum);
break;
}
}
```

We'll get:
i=65794, sum=16777724.000000
65794/512  = 128.5. I.e. that starting on 129 row you will be not getting 5 or 0 at the end of integral value. That's limitation. If you initialize your src with 5 (instead of 255), you'll get more or less good result.

Regards,
Sergey

Thanks Sergey, it sounds clear for me now.

>>...Due to limited width of Ipp32f fraction we cannot expect, that adding 255 to Ipp32f value we'll be getting
>>multiple of 5 indefinitely...

I did a quick test and I changed 'float a' to 'double a' in a test case 'integral-ipp-test.cpp'. Take a look at results if interested and use Windiff to compare output files as follows:

Windiff.exe

Attachments:

AttachmentSize
507.26 KB

This is again truncation issue. The expression "a/5.0 - (int)(a/5.0)" is performed with different precision for 'float' and 'double' variables. So, the differences can take place.

Regards,
Sergey

>>...This is again truncation issue...

Sergey, This is Not a truncation issue and this is a precision issue ( 24-bit precision for 'float' vs. 53-bit precision for 'double' ). I simply wanted to stress on the right usage of that term and I understand that there are limitations with accuracy of floating-point calculations. Thanks.