Maximum image size allowed in IPP

Maximum image size allowed in IPP

Dear all,

most of the data structures and functions paramters that refer to the image dimensions are of type int. Usually with a 32 bit int we can represent numbers up to 2147483647. This said, my quuestion is the following.

Can the image processing functions of IPP handle images where the linear index to the raw data is larger than the maximum number representable with an int on a 64 bit platform with sufficient memory? If this is not possible, what is the maximum size allowed for an image to be manipulated using IPP function?

For example, suppose I am dealing with image that is RGBA interleaved, whose dimensions are 50000 x 50000 pixels. Suppose IPP internally needs to access the pixel at position (49000, 49900). Then the offset from the base pointer to the raw data containing the pixel information is:

offset = 49900 * step + 49000 * 4

where, disregarding for the sake of simplicity alignement issues. the step is:

step = 50000 * 4

Thus we obtain:

offset = 9980196000 > 2147483647

which is clearly larger than the maximum number which can be represented using an int. Will IPP functions work?

12 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

Hello,

you are right, current IPP functions can't address data bigger than 2Gb in size (because of signed 32-bit integer limited range).

There are basically two approaches to work with such big data:
1. process huge data arrays by chunks. We do provide IPP tiling image processing sample, you can find it under image-processingimage-tiling folder of IPP sample package
2. provide functions capable to access huge data arrays because of 64-bit parameters. That is what we are considering as one of the possible future features of IPP product and really interested in your feedback on that. How it is important for you? Do you see a value of having a library to work with huge data arrays in-memory? What IPP functionality do you think may benefit most of such feature?

Regards,
Vladimir

Dear Vladimir,

thanks a lot for your prompt answer. Here are some considerations regarding the possibility to process large images.

I have looked into the tile processing business and I personally believe that it adds a huge layer of complexity to treat the data in aseamlessly manner (so that the IPP user actually does not care about the tile layoutin memory but just on slightly higher level operations).

On the other hand if the "linear indexing" of the elements was performed via long integers an approximate calculation shows that on a 64 bit machine we could manage a 32 bit RGBA image composed of more than 2 billion squared pixels (provided we have enough memory). And nowadays it is not rare to see desktops with about 8Gb of RAM (which would fit in memory a32 bit RGBA 46K x 46K pixelsimage).

I work in the field of image processing and more specifically I develop software to create image panoramas. I guarantee you that the image processing community and the scientific community in general have a great interest in creating, processing and visualizing such large images (a 32 bit RGBA image 100K x 100K pixels is definitely something appealing to scientist working in biological, biomedical sciences or astronomy just to cite a few). A simple google search for "large panorama" or similar keywords will prove this.

If I could express a wish, I'd like most of the low level IPP functions (allocation, simple geometric and photometric transforms, filtering, pyramids, ...) capable to go beyond the 2Gb boundary you mentioned. If there is enough interest I may come up with a more accurate list of functions.

In case this (huge) effort is not possible, I would like to have basic image processing functions to allocate, clear and dispose such large arrays and a cropping function that works on such images, so that I can at least pull out the chunk I need, process it within the 2Gb boundary and then place it back in the original image. All this with two simple function like:

ippGetImageChunk_????

ippSetImageChunk_????


Best,
Marco

How about changing IPP functions to take size_t arguments? This will have no effect for 32-bit code but will expend sizes to 64-bit in 64-bit code while maintaining API compatibility.

For a variety of reasons it's not as simple as just letting the compiler handle the job of automatically sizing function parameters. Ultimately, the IPP library primitives are hand tuned to the data size elements being passed, since they use SIMD instructions, which are very size-specific functions. In essence, the IPP functions end up being a mix of C code, assembly code, and compiler intrinsics (which are like a cross between assembly and C, do a search for "intel SIMD intrinsics" to find more information about intrinsics).

Quoting - Paul Fischer (Intel)

For a variety of reasons it's not as simple as just letting the compiler handle the job of automatically sizing function parameters. Ultimately, the IPP library primitives are hand tuned to the data size elements being passed, since they use SIMD instructions, which are very size-specific functions. In essence, the IPP functions end up being a mix of C code, assembly code, and compiler intrinsics (which are like a cross between assembly and C, do a search for "intel SIMD intrinsics" to find more information about intrinsics).

That's true, but the width/height only serve to control the outer loops of the primitives, converting x,y pairs into 128-bit SSE block pointers. All ippi functions take the IppiSize argument by copy (as opposed to by reference or pointer), so it should be trivial to redefine it as :
typedef struct { size_t width; size_t height; } IppiSize;
with primitives replacing 'int' and using something like
for (size_t y = 0; y < roiSize.height; ++y)
for (size_t x = 0; x < roiSize.width; x += sizeof(__m128i))
{
// SSE / assembly
}

Just a note regarding this feature request: after much discussion and debate we have decided that length/width parameter specifications for image processing will be migrating to unsigned 32-bit notation in future versions of the library to allow processing of 4 Gig image dimensions; they will not migrate to 64-bit integers at this time.

Hello Paul, is there an implementation date for this change to unsigned int.
Dirk

Hello Paul, is there an implementation date for this change to unsigned int.
Dirk

Hello Paul, 

is there any update regarding the implementation date for this change to unsigned int.

 

Thanks,

Ronen. 

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.

Best regards,

Yakov
 

Yakov,

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.

Thanks,
Chao

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui