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?
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.
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).