Problem with treatment of Pointers

[Pablo_Novadep]

Hello everyone!!

I have a problem with the treatment of Pointers.

Actually i work with a IMAQ images, but i need to do a special vision treatment to these images. My client who is the one who works the artificial vision part, has given me a function made in C, that converts the frames, that I generate in my program in a single image, already treated.

To generate the pointers of my images, i use the function IMAQ GetImagePixelPtr (I think this is correct)

The function of my provider has this structrure:

extern "C" __declspec(dllexport) long int CalculateWeight(long int);

Where:

The inpunt is each of the frame pointers and the ouput is a pointer to the final image.

My problem is how to convert that pointer to an image of LABVIEW. I have read that this should be done with the functions of LabVIEW: DSNewPtr, MoveBlock and DSDisposePtr.

I think I have not defined these functions well, because i recived a wrong image.

can you help me with this? Thanks in advance!

[wiebe@CARYA]

If the external software uses the pointer to modify the image, the image should be modified. You should be able to simply use the IMAQ data like any other IMAQ data. There would be no need to copy the IMAQ data to LabVIEW using the pointer, because the pointer points to the IMAQ data to begin with?

If the external software creates new data (e.g. allocates memory, you'll get into lots of trouble. (Who's going to deallocate the memory and how?).

MoveBlock takes two pointers. There's no need to use DSNewPtr:

The last parameter is the size, not a pointer.

[rolfk]

Lots of memory management questions!

First, your provider should define the function prototype as follows:

extern "C" __declspec(dllexport) intptr_t CalculateWeight(intptr_t);

long int is a particularly bad choice for a pointer sized variable.  On Linux it is a 32-bit or 64-bit integer depending on the bitness for which it is compiled, on Windows long is ALWAYS 32-bit. So if that code ever needs to be compiled for 64-bit on Windows all will be wrong!

Second: Is the pointer returned a newly allocated memory buffer that the function returns? If it is just the passed in pointer you have a potential problem as you have already unmapped the IMAQ image pointer and that pointer may be invalid at that point. If it is a newly allocated buffer, who is gonna free it and how? You currently pass that pointer to DSDisposePtr(). This is almost certainly wrong. DSDisposePtr() can ONLY be used for pointers explicitly allocated with a call to DSNewPtr[Clr](). If the returned pointer is just a copy of the passed in pointer, things go awry because that mapped pointer is not directly a pointer allocated by the LabVIEW memory manager but really some pointer with an offset into an allocated buffer. If it was allocated in your providers DLL, it is almost 100% sure that he did NOT use the LabVIEW memory manager function DSNewPtr() for that. In both cases the DSDisposePtr() receives a pointer that was never allocated by its sibling function and if it doesn't crash right away it has at least the potential to corrupt some memory if you do that.

The DLL developer needs to document with what function that pointer was allocated and if he used malloc() for that he also needs to explicitly export an additional function that calls internally free() for such a pointer and you will need to call that function to avoid creating a huge memory leak.

Last but not least, passing an IMAQ pointer to a C function without extra information as to the width, height, pixel format and padded width that includes the IMAQ border of by default 3 pixels and any additional row padding is simply nonsense. The pointer points at the data portion of the IMAQ image, which is simply a linear buffer of memory. This buffer contains "height" lines of pixels of length "padded width" bytes. The pixels use a number of bytes depending on the pixel format. There can be and will be extra memory between each line depending on the border size for the IMAQ image. The Map Pixel Pointer.vi returns these values for a reason along with the pointer itself!

C programming is hard because you need to do proper memory management, and calling DLL functions is C programming no matter what.