How can i load DIB data to ippi

[trlinux]

Hi there,

I'm getting DIB data from grabber, is there any function to load that data to Ipp struct, i'mean Ipp8u* like something .. Thanks ...

[Vladimir_Dudnik]

Hello,

one of the benefit of IPP (among others) is structureless design. The IPP functions have low level interface and easy to integrate into your application data representation.

Once your grabber provide you a memory buffer with image data and parameters of image, like width, height number of channel and bit depth you can apply IPP function to this buffer.

For example, ippiMirror_8u_C3IRtakes pointer to source image data, image step (aka pitch), number of bytes in image row, IppiSize structure which combines width and height parameters) and IppiAxis flip parameter which specify how would you like to mirror your image. There are in-place and not in place variants of function. The in-place variant will do operation on your source buffer and will put result here as well (destroying original source data). The not-in-place function wll require you to allocate memory for destintation buffer and will put result into this buffer, not destroying your source data.

I would recommend you to look on IPP documentation and samples for more details.

Regards,
Vladimir

[levicki]

DIB data from capture device usually includes short header with image information such as width, height, color depth, etc. More about DIB header format you can find here.

To be able to process data with IPP, you need to transfer it into memory allocated with ippiMalloc(). To allocate memory for picture buffer you need to find width, height, and color depth (you should be able to find those in the DIB header).

Now comes the complicated part -- most capture devices are providing image data in 16-bit color depth. That can be in any of (standard bitmap) RGB444, RGB555, RGB565, or even (planar, non-RGB) YV12 or NV12 formats.

For some of those data formats you will find proper conversion functions in IPP, but for some of them you will not, because implementing them is not considered a priority for IPP team.

So, to conclude -- after you find out in which format the data you receive from a capture device is, you will be able to convert it to one of the formats IPP functions for image processing can work on.

[Vladimir_Dudnik]

Thanks Igor for providing more details on that. Although I have some correction: it is not mandatory to transfer data into memory allocated with IPP malloc functions to be able to process these data with IPP functions. It is recommended for performance critical pieces of applicationto put datain aligned memory buffers because most of modern processors can access data on aligned boudaries more effiently. But IPP functions will process data with any alignment and performance penalty will not be too big.

We also have data format conversion routines for most of popular formats. The exception are rarely used formats (which you can easely implemet in C)

Vladimir

[levicki]

Vladimir,

Thanks for the correction. What I had in mind when I suggested to allocate with ippiMalloc() was the following:

1. There is no conversion function for RGB555 format.

2. YV12 format is planar. Chrominance channels are stored after the luminance channel with a resolution of [width/2, height/2]. Perhaps there is a conversion function but I am not sure which one.

3. NV12 format is a mix of planar and interleaved. Chrominance channels with a resolution of [width/2, height/2] are interleaved (Cb in LSB, Cr in MSB of a 16-bit word), and stored after the luminance (Y) channel which has even number of lines and perhaps even scanline alignment. NV12 is since recently supported in video coding functions, but I am not aware of any conversion functions that support it.

Since the original poster asked about Ipp8u I presumed that they are interested in getting input data into 8u_C1 or 8u_C3 format for further processing.

The only way to do it (that I am aware of) for the above-mentioned formats would be to write a conversion function which would have to allocate a destination buffer anyway. Since that buffer would be an input for further processing with ippi...() functions, it would be best if the allocation is done with ippiMalloc().

[Vladimir_Dudnik]

Igor,

That's right, we do not provide functionto convert to/fromRGB555 format. There was not much requests on this format.

For the rest I see no better way then refer to documentation,wherewe provide special topic in IPP reference manual, which called Image Color Conversion.It should contain description of all image format conversion functions we offer.

I think functions YUV420ToRGB and RGBToYUV420 provides conversion from YV12 format to both planar and pixel-interleaved RGB formats (BGR variants are also available) and YCbCr420 function converts between YV12 and NV12 formats. Some other variants available too.

Since the original poster asked about DIB,my assumption was he get just not subsamples BGR data.

Regards,
Vladimir

[levicki]

Vladimir,

Thanks for pointing both the original poster and me to those functions -- I may find them usefull as well in the future.

May I suggest that the documentation on YCbCr420 should mention NV12 and YV12 so that people can find it more easily using the Search function?

Regarding DIB data format, maybe I am wrong but I was under impression that format you receive can depend on the capture device driver.

[Vladimir_Dudnik]

Thanks, documentation should be improved, I'll pass your suggestion to appropriate engineers.
And yes, format can depend on capture driver, so theretically it can be either BGR or one of YUV formats.