IMAQimage references

[Neil Pate]

I have used Vision on and off for several years and never really grokked the subtleties of IMAQimage references and what they actually represent. Now using strings instead this all just clicks into place for me.

[Jordan Kuehn]

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.

[Rolf Kalbermatter]

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). 

[Jordan Kuehn]

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. 

[Rolf Kalbermatter]

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 October 4, 2019 by Rolf Kalbermatter

[Jordan Kuehn]

Agreed wholeheartedly. 

[Neil Pate]

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. 

[drjdpowell]

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.

[Neil Pate]

Wow that sounds pretty rubbish! I have never really gotten to the point where I have said yup I totally understand this API. 

[smithd]

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

[Neil Pate]

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. 

[Antoine Chalons]

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 October 7, 2019 by Antoine Chalons

[Rolf Kalbermatter]

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.

[Antoine Chalons]

53 minutes ago, Rolf Kalbermatter said:

which they acquired from Graftec I believe

Graftek Imaging the website does give a few words about the history : https://graftek.biz/aboutus