How do I make 1D array and pointer to place acquired image?

[jjsword]

Thanks for the input.  I will try changing it to a pointer sized integer and see if that works. 

Just to be clear, the array is an array of U16.  The syntax for the dll function lists pData, the buffer data pointer, as unsigned short *.  I believe that is referring to the pointer itself and not what it is pointing to? 

I will be sure to try your suggestion and report the result. 

[BlueCheese]

---

@jjsword wrote:

Thanks for the input.  I will try changing it to a pointer sized integer and see if that works. 

Just to be clear, the array is an array of U16.  The syntax for the dll function lists pData, the buffer data pointer, as unsigned short *.  I believe that is referring to the pointer itself and not what it is pointing to? 

I will be sure to try your suggestion and report the result. 

---

Pointers only point to memory. Any type with them is just for conveniece/safety to help you pass the correct type of data that the function expects. In this case your DLL is expecting to treat the memory as an array of 16-bit data. As long as the address in the pointer is to a block of memory with U16 data then it should be correct.

LabVIEW has no notion of types of pointers on the diagram (unless it is doing the conversion on its own within the Call Library Node, such as from a LabVIEW array). If you retreieve a pointer from one Call Library node it is passed as an integer on the diagram. This size must be at last as large as a pointer (32 or 64-bits) to be valid. The datatype of the pointer in this case has no bearing on the type of data it points to. In this case what controls the type of the data pointed to is the image type.

You could do this in a more "safe" way by converting the image to a 2D array, reshaping the array, then passing it to your Call Library node as an array rather than directly as a pointer. This does involve several copies though so it is not as optimal.

Eric

[jjsword]

I am calling a pointer by reference with the Call Library Node that is created with IMAQ GetPixelPointer, from what I understand.  Unfortunately changing the pointer to a pointer sized integer (signed or unsigned) causes LabView to freeze.  It freezes when I pass a 32 bit integer pointer directly from GetPixelPointer into the Call Library Node and gives me an error 1097 when I pass a 16 bit integer into that node.

[BlueCheese]

---

@jjsword wrote:

I am calling a pointer by reference with the Call Library Node that is created with IMAQ GetPixelPointer, from what I understand.  Unfortunately changing the pointer to a pointer sized integer (signed or unsigned) causes LabView to freeze.  It freezes when I pass a 32 bit integer pointer directly from GetPixelPointer into the Call Library Node and gives me an error 1097 when I pass a 16 bit integer into that node.

---

Can you post the signature of the function you are calling? Can you double check the calling convention? Any of these things not matching can cause it to crash, error, or hang because it can corrupt memory, the stack, or cause access violations.

Eric

[jjsword]

Eric,

    Here is the function syntax: longFunction( unsigned short* pImageData,long allocatedSize,ImageProc pCallBack).  I found out that the pCallBack can be NULL so I just have 0 going into an I32 on that Call Library Function Node.  Based on other posts about entering a NULL pointer, that should be sufficient since I won't be using that part of the function.  The screen capture I did had an error with the zero length string but I have that fixed now.

    Do you see a problem with transferring the 32 bit pixel pointer from the GetPixelPointer VI directly in to pImageData?  I recently came to the realization that the syntax listed above having unsigned short* pImageData refers to what pImageData is pointing to and not what size pImageData actually is.  Thanks.

Jeremy

[jjsword]

I changed the pImageData parameter in the Call Library Function Node to a U32 value (not value pointer) and was able to start acquiring images.  There is still a problem with being able to view the images that I am working on currently, but acquiring without errors is huge progress.

[BlueCheese · Accepted solution]

---

@jjsword wrote:

I changed the pImageData parameter in the Call Library Function Node to a U32 value (not value pointer) and was able to start acquiring images.  There is still a problem with being able to view the images that I am working on currently, but acquiring without errors is huge progress.

---

Yes, it needs to be passed as an integer, not a pointer to one (which would then be a uint16**). You probably still want it to be a "pointer-sized-integer" to ensure your code eventually works in 64-bit LabVIEW. On 32-bit LabVIEW there is absolutely no difference between this and a U32.

Eric

[jjsword]

Any idea how to get the intensity graph to display correctly?  The image array is U16 and it is converted to a 2D U16 array going into the intensty graph.

[BlueCheese]

---

@jjsword wrote:

Any idea how to get the intensity graph to display correctly?  The image array is U16 and it is converted to a 2D U16 array going into the intensty graph.

---

If I had to guess I'd guess that your code is not taking the line padding (stride) into account. Vision images always have each line aligned on a certain boundary. I think it is usually 64-byte aligned on Windows systems. This padding is an output on the Map Image Pixel Pointer VI. You could also modify your image width to match the byte alignment so that there is no need for additional padding.

Eric

[jjsword]

I have a 1388 width by 1040 height image with a 3 pixel boundary and (I assume) 7 pixels per side for alignment.  The total pixel width is 1408 pixels. Do you know if it is possible to adjust for the alignment (32 bit listed in GetImagePixelPtr) in the intensity graph properties?  I tried setting image size to 1408 but then the total pixel width automatically increased to 1440.