Imaging and analyzing image without saving to hard disk in LabVIEW

[CatDoe]

I am new to image processing in LabVIEW and am creating a distributable application which will be run 2000 times a day. The distributable application window will be opened once, left open, and a button press will trigger a single run. In each run, I need to take 6-9 individual pictures, stitch them together to create one large image, analyze the stitched image via NI Vision Assistant using an array of pixel values. Due to the large number of images (minimum 12,000/day, 84,000/week) I would like to avoid storing the images on the hard disk. The images are only for analysis and are not important to save.

The goal is to both be as fast as possible and prevent memory issues. Is there a way to quickly image, analyze without involving the hard disk to avoid memory issues? I can temporarily save and overwrite images on the hard disk, but this may lead to data corruption long term.

Secondary question, what would be the best method to create a distributable with a set order of operations based on user interaction with buttons to trigger a predefined order of operations? Previous distributable applications have used queued message handlers. These applications were written pre-2017 -- I am unsure if this is still the best method.

LabVIEW 2021

Edited to add:

- GigE compatible camera

- potential need for distortion etc... correction

- Images taken at various points during a raster scan (1 image per pause in XY table raster scan)

[Gregory · Accepted solution]

It sounds like you're using the LabVIEW Vision Acquisition Software or Vision Development Module. These use the IMAQdx drivers, which use image buffers. The buffers are constantly being overwritten when you grab images from the camera. In your case, if you need 9 buffers you can create them using the IMAQ create function. Alternatively, you could convert the image data into an array, then you will have a numerical representation of the image.

As for the architecture of your program, the main requirement I see so far is that it has to respond to button presses, so using an event structure is a good start. Sometimes this is called an "event driven message handler". The JKI state machine is a pretty easy to use queued message handler.