RGB U32 = RGBA ?

[Bublina]

Hello,

I am developing my own .h264 encoder using Intel Media SDK, since I can only feed the API encoding function with LabVIEW unsupported formats ( YUY2, YV12, NV12 ) I must use an SDK implemented preprocessing function that can convert RGBA (in the API docu it is referenced as RGB4) into NV12.

So, is the RGB U32 LabVIEW fromat an RGB24 + the alpha byte, so RGB U32 = RGBA ?

Another question is: Is there any way (except programming everything on my own), how to implement the NV12 format into labview and modifying the "Imaqdx Get Image" function so I will not need to decode and code same format and save CPU time ? Somthing like IMAQdx Get Image Data, that would return the memory pointer.

[okubik]

Hello,

try to browse  NI Vision Concepts Help for detailed information about Vision images formats. You can also find here NI Vision supported Image Types.

Can you get any diferent image data format from your data acquisition device? Such as Array of U8/U32? There are functions like ArrayToImage on "pixel manipulation" palette or ArrayToColorImage on "Color Utilities" palette which are really fast. Did you try ExtractColorPlanes func?

(You can also contact directly Czech support via techsupport@ni.com)

[Bublina]

Thank you for answer,

I do not want to convert my image data into LabVIEW array type. I do not want to convert the image data to any supported image format in LabVIEW, I want to feed my frame encoding dll functions with the same data, that are acquired from camera, without the need of making my own camera driver and with the comfort of using LabVIEW as top level language.

[okubik]

Hi,

I am not sure that putting LabVIEW as an interface between IMAQ driver and Intel API is good idea. Based on my experiences with LV (I am 99,9% sure), there is no easy way how to implement transparent API based on LV code that pass pointer to received data to some API. Because if some unhandled error conditions occur, it can  cause to race conditions or memory violation.

In your case it should be better to call directly IMAQ driver functions from Intel API. See NI-IMAQ Function Reference manual.

I think you can call me on Czech Tech Support line (800 142 669) and we can discuss it.

Ondřej

[Bublina]

Thanks for the answer.

I am about to use memcpy, so the only operation that affects LabVIEW is reading some of it´s memory. This is used often. I am aware of possible lost functionality with different Vision runtimes installed.

The image I provided was supposed to clarify what I was asking about, the wire between blocks does not represent same memory pointer.

I cannot use IMAQ, the camera is ethernet bus type.

---

@okubik wrote:

Hi,

Based on my experiences with LV (I am 99,9% sure), there is no easy way how to implement transparent API based on LV code that pass pointer to received data to some API. Because if some unhandled error conditions occur, it can  cause to race conditions or memory violation.

---

I do not want to implement any API based on LV code. I am implementing Intel API  using DLL function calls in LabVIEW. I believe, that once I read the memory, all race conditions and memory violations upon newly allocated memory are caused by my own code.

As for using Imaqdx functions in other IDE like Microsoft Visual, thanks for suggestion. I thought the functions are the same, so that the IMAQdxGetImage returns Image *, etc. but I took a look at IMAQdxGetImageData and it returns

void* buffer,

uInt32 bufferSize

so I guess I can connect this output directly to the Intel API functions.

[BlueCheese]

If you are using a GigE Vision camera that can return images in a YUV pixel format, then using IMAQdxGetImageData will give you an array of data directly in YUV format (identical to what the camera sends) that you could possibly pass directly to some other code expecting that type of data. The 2D array can be passed to a Call Library node as a standard C pointer.

Eric

[vekkuli]

While reading through similar topics I noticed this old thread and decided to share my own findings. I use a lot of external code in LabVIEW applications so these sort of issues come up often. Inspecting the memory it clearly looks to me that for an RGB (U32) type image the component order for each pixel in memory is actually BGRA. I haven't been able to find any unambiguous description of this, which I find a little frustrating. Closest thing I've seen is this Image Types help that suggests the format would be ARGB, which at first seems just plain wrong but could be twisted into the apparent BGRA by assuming the 32-bit integer and little endian byte order.

[Bublina]

It will be BGRA on desktop computers. Had Tue same issue. Also beware of image line padding and where the IMG ptr starts.