Dear IPP developers,
It has nothing to do with the type used for image dimensions. The images we have get as large as 2GB not because of their individual dimensions being large, but because the stride*height product is large. Yes, somebody may have an image 8 Gpx wide and just 1 px tall, in which case there is no way supporting it without changing the interface, but this is an extremely ridiculous scenario.
The problem most people are likely to face (including the OP and me) can be solved by you fixing the address calculations inside the IPP implementation, without any interface change or breakage. Some functions appear to do the correct 64-bit pointer arithmetic on 64-bit machines, but some, like RGBToGray_8u, appear to count byte offsets from the base pointer in 32-bit registers. As others have noted, Paul Fischer's "IPP uses SIMD" argument is simply not true because the address calculations are done in general-purpose registers.
Please fix this problem, as >4GB machines are even more common nowadays than 5-years before, and the computational tasks we face do use images that take that much memory.
Thanks for the feedback. Do you have some specific functions that we have a further check? As you know IPP includes thousand of the functions, it is not easy to add such feature for these general functions. If you have a few functions, we could have further check if we can optimize on that.