Machine Vision vi alternatives to the Intensity Graph?

[cochenob]

I am developing LV tools to process and display data from a laser scanning system.  Data comes into LV as a serial stream of SGLs, and there's some LV code to organize that serial stream into image lines, and then display it on the front panel.

There are two modes of operation...one in which an entire frame is decoded and displayed, and another that operates in a manner similar to a waterfall or cascade plot, where each new line (or groups of lines) is added to one end of the image, while old lines are popped off the other end.

The sample (pixel) rate, the scanner (line) rate, and the number of lines I wish to display determines the size of the 2D array I feed to the Intensity Graph front panel object.  These front panel objects seem to have a non-trivial overhead associated with them...essentially limiting the frame display rate, or line display rate (depending on the mode of operation).

It seems that there's probably a more efficient way to display my image to a front panel that circumvents the Intensity Graph object, but I don't know what it is...which leads me to this section of the forum.

Are there LV Machine Vision vi's that might be better 'tuned' for writing intensity images to the front panel?

Is there LV hardware where I could just write data to a hardware buffer directly and have the output display on a separate monitor...free of Front Panel overhead?

[TheEngineeringBear]

Actually found this harder to find than I expected, and honestly it's going to probably just take some trial and error on your end to see what you like, but THIS and THAT are the closest documents that mention what's available. 

As for the "free of a Front Panel" question, you likely would have to save images in LabVIEW and then write use a third party program to accomplish that.  NI Hardware is meant to work with LabVIEW, but maybe you could clarify a bit more about what functionality you are looking for as I'm not quite sure what the hardware would hook up to since there would need to be some processing to view the image.

-Bear

[cochenob]

Thanks!

Regarding the "free of Front Panel" operation...I guess what I'd ultimately be looking for is something that operates the same way the OS works with my PC graphics care.  Something where I could just write data to a permanent hardware buffer/register as I decoded new lines, and the hardware would then just be displaying whatever information it saw there at that time.  There wouldn't be any need for LabView (or the operating system) to be in the way with overhead and extra allocations and array computations.  As far as I can tell, I can't do that kind of low/level communication to my PC video card from LabView...but maybe there's some kind of NI hardware that would operate similar to what my PC video card is doing? Sort of like a frame grabber only in reverse...I want to provide the data, not capture it.

I've tried to develop my application using a similar model.  All lines (or frames) are stored as preallocated DVRs, which get worked on/accessed in an In Place structure, thus eliminating unnecessary array allocations as I "prepare" new lines or frames. This helps in moving the data around and doing processing, but in order to get the intensity stored in those References to physically display on the front panel, I can't seem to find any way around the inherent inefficiencies/overhead of the front panel Intensity Graph object. 

From reading the above links (and elsewhere), it looks like the IMAQ data type is similar...the thing that gets passed around are references, not the data itself.  That's good!  However, it's not clear if displaying will have the same kind of overhead as the 2D Intensity Graph.

As an aside....it looks like I can use the IMAQ tools without actually having IMAQ hardware.  Yes?  Like...I can take my own 2D data and convert it to the "IMAQ data type"?

---

Brandon

[TheEngineeringBear]

Ya, I realize now I didn't exactly hit the core of your issue.  I don't think you even need Vision indicators as it's more of a performance issue.  I would try creating a secondary loop to handle the UI that you can pass data to in order to handle the update of the graph. 

I would benchmark sections of your code and figure out what is taking up the most processing.  Ideally you can some kind of data producing loop and then a UI handling loop that is updating a display.  Maybe some pictures of your code may help so we can give advice on how to improve performance!

For your question though, yes!  You can use IMAQ software without hardware.  

-Bear

[cochenob]

Thanks for the discussion.

I've implemented both serialized (aquire data...do some stuff....display an image...repeat) and parallelized (Producer/Consumer loops) implementations of the code.  The performance is a little different in each case, but ultimately  you run into a buffer overflow somehwere since the physical display part can take a long time and can be memory intensive depending on the size of the image.  Serial or parallel operation doesn't seem to fix that fact.  

I have previously benchmarked stuff using the Performance and Memory tool...and the "Display" vi is definitely where all the action (or inaction) happens.

Attached is a picture of the VI block diagram. I have two images...a magnitude and phase.  References to the front panel Intensity Graph objects for each are the bottom pair of references.  The top pair of references are arrays of DVRs...where each DVR is a reference to a 1D array representing a line in the image. These were prepared/written in other places of the code previously. The loop basically indexes each DVR (line), and rewrites it into the corresponding Front Panel array.

I guess ideally I'd want to treat the data in my Front Panel Intensity Graph as a set of references that I would update to point to new lines rather than a 2D array that I have to write...but, I can't quite see how to do that.