ippA0C4

[Adriaan_van_Os]

The IPP headers define ppA0C4, but I didn't see any actual calls for the format. The documentation says: If an alpha (opacity) channel is present in image data, the image must have four channels, with alpha channel being the last or the first one. This data type is indicated by the AC4 or A0C4 descriptors respectively. So, for example, ARGB (or uRGB where u stands for unused) is A0C4 whereas RGBA (or RGBu) is AC4. But 8-bit ARGB and uRGB are quite common formats, so what to do with them ? One trick is to call ippiSwapChannels, but that costs extra processing time, as one may have to call it three times (on the source and then after filtering on the target and source to get back to ARGB or uRGB). Another trick is to offset the data pointers by one channel. But does that process one extra pixel-channel at the end ? The documentation is rather vague about AC4. It says The presence of the alpha channel can modify the function's behavior. For such functions, Intel IPP provides versions with and without alpha. If an alpha channel is specified, the operation usually is not performed on that channel. So, it would be good if AC4 would really mean "A channel not processed" to imply "A channel memory location not touched". Another question is if the one-channel offset ruins performance by disalignment ? By the way, I am confused by AC4 being implemented or not. For example, ippiFilterBorder has C4 but no AC4 variants. Do we really want convolution on the alpha channel ? And what is the purpose of convolution (etcetera) on a channel that has (in most cases) all zeros or all ones (255 or 65535 or 1.0) ?

[Igor_A_Intel]

Hi Adriaan van Os,

several A0C4R were available in IPP in the pre-deprecation era - before IPP 9.0, then they were deprecated and removed as there were no any customers' feedbacks/requests for such functionality. You are the first (for the last 10-15 years). Shift on 1 channel will lead to perf drop because of unaligned access to all pixels, but I guess that it's less expensive than perform additional allocation and format conversion. Also there is one more way - use ippiCopy_xx_C4C1R to store A channel and C1C4R - to restore.

Regarding words "the operation usually is not performed on that channel" - this means that A channel stays the same after function call as it was before with several exceptions that mentioned in the documentation - for example AlphaComposition functions use and can change A-channel. I can't say that for all other cases A-channel is not touched - it's touched (for better performance) but remains unchanged (for example AddC to AC4 image can add {r,g,b,0} - A-channel is touched, but not changed.)

Regarding the last one - we have customers for C4R - this pixel format is supported in the library according to customers' requests. If you need AC4R support for ippiFilterBorder - please submit official request through Intel Premier support - it will be considered.

regards, Igor

[Adriaan_van_Os]

I see, thanks for the reply. Still, for the record, you may find it interesting to see what pixel formats are supported by Mac OS X and iOS. The table is listed here <>. Regards, Adriaan van Os

[Adriaan_van_Os]

The link to the supported pixel formats was removed from previous post. I will try again (sorry for the noise) <>