Problem using ippiCrossCorrNormGetBufferSize - negative buffer size! (Ipp 8.1)

[Uta_M_]

Hello,

the buffer size returned by ippiCrossCorrNormGetBufferSize is negative, if the size of the source roi is greater than ~33488896.

Within the following ranges, the buffer size is calculated correctly:

if w <= 511 then h <= 65536

if w <= 1023 then h <= 32768

if w <= 2047 then h <= 16384

if w <= 4095 then h <= 8192

if w <= 8191 then h <= 4096

if w <= 16383 then h <= 2048

Sometimes the function "recovers" and returns positive values again. E. g. if w <= 2047 and h > 32768 it returns positives values again.

Can you confirm this bug (Ipp 8.1)? Will this problem be fixed in the near future? Is there a quick workaround calculating the buffer size?

Best regards,

Uta

[Igor_A_Intel]

Hi Uta,

thank you for reporting this - this is the real bug due to int limitation...The issue has been already fixed - the fixed version will be available in the next IPP release. Anyway the "huge" sizes will not be supported - the GetSize function will track int overflow during the buffer size calculation and return bad status in case of overflow (ippStsExceededSizeErr). This is current IPP API limitation, for rather big sizes please use slices-based approach.

regards, Igor

[Uta_M_]

Hi Igor,

what is the next IPP release? 8.2 update1, 8.3 or 9?

Is there a workaround for this problem?

Best regards

Uta

[Igor_A_Intel]

Hi Uta,

the buffer size calculation for this function is rather complicated and depends on many factors such as source and template size, type of correlation, type of normalization and type of method used - about 200 lines of code. My first intention was to publish here this code - but it is not enough as in this case this code requires several internal IPP headers and structures, and you know - IPP is not open source... As a workaround I can only suggest to check the sign of the buffer size and consider it erroneous if it is < 0... Another workaround is to use temporally "old" deprecated APIs - they will be supported till the same next IPP version where this bug has been already fixed - IPP 9.0 (~H2'15).

regards, Igor