Grab images from buffer

[thenoob94]

I'm using Debian.

I'm using a c program to aquire images from a gige camera. This is the code: https://github.com/AravisProject/aravis/blob/main/tests/arvexample.c

What would be the best way to bring the aquired images into labview?

I don't want to call the function every time I want to grab a new image frame because I think this will slow things down since the function first has to connect to the camera.

[Rolf Kalbermatter]

11 minutes ago, thenoob94 said:

I'm using Debian.

I'm using a c program to aquire images from a gige camera. This is the code: https://github.com/AravisProject/aravis/blob/main/tests/arvexample.c

What would be the best way to bring the aquired images into labview?

I don't want to call the function every time I want to grab a new image frame because I think this will slow things down since the function first has to connect to the camera.

The best approach would be to take that code and make your own shared library from it. Export functions to Open the device, Grab Images and Close the device. Basically you do not want an executable with a main function but instead you want a shared library that seperates those indvidual functions out.

Why not call the underlying library directly through the Call Library Node you may ask. Because you have a callback function in there! It may be possible otherwise but that callback really is a no go for direct LabVIEW interfacing.

Edited March 20, 2023 by Rolf Kalbermatter

[thenoob94]

39 minutes ago, Rolf Kalbermatter said:

The best approach would be to take that code and make your own shared library from it. Export functions to Open the device, Grab Images and Close the device. Basically you do not want an executable with a main function but instead you want a shared library that seperates those indvidual functions out.

Why not call the underlying library directly through the Call Library Node you may ask. Because you have a callback function in there! It may be possible otherwise but that callback really is a no go for direct LabVIEW interfacing.

I have compiled my code to an .so file and I'm trying to call it as a shared library. Since the data aquisition is running constantly the function never returns. So my vi freezes. Is it possible to have a function run continuously in Labview? Otherwise the function for the image aquisition has to be resarted each time I want to grab a frame. How would you implement opening the device and accessing the buffer?

[Rolf Kalbermatter]

7 minutes ago, thenoob94 said:

I have compiled my code to an .so file and I'm trying to call it as a shared library. Since the data aquisition is running constantly the function never returns. So my vi freezes. Is it possible to have a function run continuously in Labview? Otherwise the function for the image aquisition has to be resarted each time I want to grab a frame. How would you implement opening the device and accessing the buffer?

Show your code! It's not the meaning that you simply export that main function and call it! you need to take it apart and export separate functions for at least Open, Grab and Close.

Edited March 20, 2023 by Rolf Kalbermatter

[infinitenothing]

I found a related thread that might be helpful

It would be nice to be able to do more with the call library node without having to wrapper everything. If anyone wants to post something on the idea exchange forums, I'd likely give it a vote

Edited March 20, 2023 by infinitenothing

[Rolf Kalbermatter]

1 minute ago, infinitenothing said:

I found a related thread that might be helpful

 

I'm not sure you did a service here. Trying to do callback functions through Windows messages is both not straight forward and in fact the master class of interfacing to a shared library. Considering that his shared libraries are .so files, he also obviously is not on Windows but Linux,

[thenoob94]

CMakeLists.txtThis is what I'm working with at the moment. The image aquisition works out fine. The only issue is that it's not event driven. Instead of only grabbing an image when a new one has been written to shared memory I'm grabbing the image constantly. I know what @Rolf Kalbermatter means by refactoring the code into the functions. The issue is that in order to grab a frame I new to access the camera(aravis "object") which is instanciated in the connection process. I don't see how I could wrap this so I can make use of these functions in Labview.

main.c client.c test.vi

Edited March 21, 2023 by thenoob94

[Rolf Kalbermatter]

40 minutes ago, thenoob94 said:

CMakeLists.txtThis is what I'm working with at the moment. The image aquisition works out fine. The only issue is that it's not event driven. Instead of only grabbing an image when a new one has been written to shared memory I'm grabbing the image constantly. I know what @Rolf Kalbermatter means by refactoring the code into the functions. The issue is that in order to grab a frame I new to access the camera(aravis "object") which is instanciated in the connection process. I don't see how I could wrap this so I can make use of these functions in Labview.

main.c 4.12 kB · 0 downloads client.c 655 B · 0 downloads test.vi 17.76 kB · 0 downloads

Ok, this is not gonna work like this. The sample code you show uses gobjects to start its own loop and do event handling all through it. gobjects is basically a glib task handling system. It's in fact its own execution system and is for instance used as base of gtk and in extension GNOME. But these are build on top of gobjects. LabVIEW has its own execution system and marrying two of them together is a major exercise in coding. In fact it is almost never done since it is so difficult to do right.

You will need to try to find the lower level interface of this aravis library. It will require you to call lots of functions with the arv_ prefix and similar, but you must avoid anything that starts with g_. Basically you would need to start writing something like IMAQdx with many of its functions but instead of calling into IMAQdx you call into the arvis library. It's doable but not for the faint of heart.

Basically trying to interface to image acquisition hardware and libraries is very difficult. Always! And there is a reason these libraries cost money and there are very few freebies here.

The Arvis library itself seems to be free. Its LGPL licensing can be problematic for anyone wanting to use it for a commercial program. And while it states to be LGPL there are actually files in there that state to be GPL. So licensing is not completely clear cut there. Incorporating GPL software in anything other than GPL software is basically impossible.

 

Edited March 21, 2023 by Rolf Kalbermatter