Jump to content

IMAQimage references


Recommended Posts

A good way to illustrate what the IMAQimage reference is. I really wish they had a better way to differentiate this on the wire. I've had to explain countless times that the wire is a reference not a value, but it just feels like it should be by value unlike other things that use reference wires.

Link to comment
21 hours ago, Jordan Kuehn said:

A good way to illustrate what the IMAQimage reference is. I really wish they had a better way to differentiate this on the wire. I've had to explain countless times that the wire is a reference not a value, but it just feels like it should be by value unlike other things that use reference wires.

It's a named reference. You could think of it as a name and a pointer. There is an inherent mapping in it similar to other named references like VISA or DAQmx refnums. If you pass in a string, LabVIEW converts it automatically to a refnum by looking up the name in its internal registry for that refnum class. If you pass in a refnum whose internal "pointer" is a valid reference it will directly use that reference instead and save the intrinsic lookup in the refnum registry for the according class. (Class being here a refnum class not a LabVIEW class). 

Link to comment
2 hours ago, Rolf Kalbermatter said:

It's a named reference. You could think of it as a name and a pointer. There is an inherent mapping in it similar to other named references like VISA or DAQmx refnums. If you pass in a string, LabVIEW converts it automatically to a refnum by looking up the name in its internal registry for that refnum class. If you pass in a refnum whose internal "pointer" is a valid reference it will directly use that reference instead and save the intrinsic lookup in the refnum registry for the according class. (Class being here a refnum class not a LabVIEW class). 

Right. My point is that it is not intuitive to someone who is starting to work with NI Vision. Perhaps that has changed in recent years? I have seen so many people get confused why they branch the wire and perform image manipulation operations on it and wonder why the behavior is erratic for example. 

Link to comment
6 hours ago, Jordan Kuehn said:

Right. My point is that it is not intuitive to someone who is starting to work with NI Vision. Perhaps that has changed in recent years? I have seen so many people get confused why they branch the wire and perform image manipulation operations on it and wonder why the behavior is erratic for example. 

The difficulty is that it goes beyond the by value dataflow principle in LabVIEW. And there is no easy way to fix that. The reference nature for images is neccessary as otherwise you run out of memory very quickly when trying to process huge images. But it remains a strange duck in LabVIEW land and even I have sometimes to remind myself that IMAQ images work differently than standard LabVIEW data. You would think that the DVR might change that a little as it is in fact a similar concept but there you need a special node to access the internal data and that protects from most possible race conditions that might otherwise be not obvious. Not so for IMAQ images references.

Edited by Rolf Kalbermatter
Link to comment

The one thing that always confused me was writing the actual image to the terminal. If it was purely reference based there would be no need to sequence it as I have done it in my demo. The indicator gets updated when the same actual data value hits it, which is a bit unreference like (maybe...). As Rolf says, a strange duck. 

This does help me know what happens if for example I broadcast an Image reference on a user event. No data copy of the whole image occurs, and if I do stuff to ref coming out the receiving event it might effect my original image, it is not a copy. 

Link to comment
21 minutes ago, Neil Pate said:

The one thing that always confused me was writing the actual image to the terminal. If it was purely reference based there would be no need to sequence it as I have done it in my demo.

Worse, writing the image ref only triggers the need for a refresh of the control; the actual read of the data is asynchronous (like all LabVIEW indicators) and happens a short while later, possibly after the image has been changed.

Link to comment
17 hours ago, drjdpowell said:

Worse, writing the image ref only triggers the need for a refresh of the control; the actual read of the data is asynchronous (like all LabVIEW indicators) and happens a short while later, possibly after the image has been changed.

i think if you put the img display in snapshot mode its synchronous?

On 10/4/2019 at 4:22 PM, Rolf Kalbermatter said:

The reference nature for images is neccessary as otherwise you run out of memory very quickly when trying to process huge images.

I agree that imaq needs refs, but why does it need named refs? Thats the part thats horrifying

Link to comment

So out of curiosity, how does everyone else handle their name generation? Multiple cameras with multiple image processing steps each needing temporary storage. I usually try and programitically generate the name but now that I think about this thread there must be a better way that I don't know about. 

Link to comment
26 minutes ago, Neil Pate said:

So out of curiosity, how does everyone else handle their name generation? Multiple cameras with multiple image processing steps each needing temporary storage. I usually try and programitically generate the name but now that I think about this thread there must be a better way that I don't know about. 

I have a "rule" something quite basic like "VisionSystemRef_CameraName_BufferType_Index"

For the buffer type I have a typedef with a few options :

- "Acq" for acquisition only buffer, I never do any processing on these, they are used only to store an image that has just been acquired from a camera

- "Save" buffers reserved to store images that will be saved to disk

- "Proc" for processing

- "Disp" buffers reserved for images to be displayed on the UI

So I use the "image copy" VI a lot do to transfer image data from a buffer to another

Edited by Antoine Chalons
  • Like 1
Link to comment
On 10/7/2019 at 4:25 AM, smithd said:

I agree that imaq needs refs, but why does it need named refs? Thats the part thats horrifying

That's most likely heavily influenced by the fact that the original Concept VI image analysis library, which they acquired from Graftec I believe, had to create some sort of handle like object without the ability to hack into LabVIEW itself. Their solution was to create a cluster with an image name string and some extra attributes including the actual pointer. They made the cluster such that only the string was visible. To a casual user it looked like it was just the name of the image but internally it consisted of a lot more. The name was used to register each handle in an internal list and each image could also be retrieved with the name only from this list when the handle had been getting invalid somehow.

In hindsight it was not the ideal choice but back then (early 1990ies) LabVIEW programming was also not quite at the standard level of today. Error Clusters were not yet used throughout everything and most functions including that image library only returned an integer that could indicate an error code. External code programming in LabVIEW was entirely CIN based and refnums like they exist now in abundance only existed for file IO, and network.

  • Thanks 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.