Jump to content

Grab images from buffer


Recommended Posts

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.

Link to comment
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 by Rolf Kalbermatter
  • Thanks 1
Link to comment
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?

Link to comment
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 by Rolf Kalbermatter
Link to comment
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,

  • Like 1
Link to comment

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 by thenoob94
Link to comment
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 by Rolf Kalbermatter
  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.