reading multiple images

[vomojo]

I'm trying to properly create a VI for going through a set of image files (16 bit 2D arrays) after they're captured and saved in my system. Currently I've built a VI (attached) for automatically navigating through each file in that folder and displaying the intensity graph, but there's not enough interactivity on the front panel.

I'd like to be able to include a control like a set of buttons that allow the users to go forward and backwards through the files in the folder at will, rather than with a time delay. 

[James.M]

Sooooo you just want to turn your program that currently works somewhat in to a better user experience. Simple enough, because usually the hard part is getting your application to work properly first.

I would suggest you look in to the State Machine architecture. 

The Simple State Machine template that ships with LabVIEW is really the best way for new developers to get familiar with LabVIEW while utilizing a semi-scalable architecture.

Here's a broad example of how a state machine works:

• States: Init, Idle, Exit, DoThing1, DoThing2, DoThing3
• Each state contains code that might take some time. Ideally, not too long because that's how long your code could be unresponsive.
• The Idle state contains an event structure for all user interaction.
• The front panel has a button that says "Do Thing 1".

1. Loop Iteration 0: Application begins, first state is Init. The Init state does some initialization stuff and tells the application to go to the Idle state when finished.
2. Loop Iteration 1: Application goes to Idle state. It sits there, waiting at the event structure.
3. Time goes by, then user presses button "Do Thing 1". There is no code, or minimal code, within this event case. The output of this event state tells the application to go to the DoThing1 state.
4. Loop Iteration 3: Application goes to DoThing1 state. There is code here that does some stuff. The output of DoThing1 state tells the application to go back to the Idle state.
5. Loop Iteration 4: Application goes to Idle state where it waits at the event structure again.

• Each of the states can tell the application to go to any state they want. Want to reinitialize? Go to the Init state again. Want to end the program? Go to the Exit state. Want each state to trigger another (like a sequence)? Have DoThing1 output DoThing2, which outputs DoThing3,  which outputs Idle.

In your case, you could make the DoThing cases something like Next_Image or Prev_Image.

[vomojo]

Once the SSM is saved and finished, it'll be a standalone application right? As in I can't plug it into existing VI's?

To clarify, part of my original goal was to plug this VI into an existing VI designed by my camera's developers. Though, seeing as the idea was supposed to be an post-capture process, it's not terribly bad that the image review becomes a secondary program to open. 

This seems like a good route to go, nonetheless. Thanks, James!

[James.M]

The SSM architecture is a standalone code set that doesn't take inputs or outputs after it's been initialized. It can be launched in parallel with other loops if needed, though, and a parallel communication method must be developed to handle that.

If you want this VI as a subVI of your main VI, then you could add inputs like "previous" and "next" to sort through the pictures. You would then need to get rid of the For loop, figure out some sort of memory to know what image you are currently on (FGV or another input/output to your main VI), and add an initialization step somewhere so that you aren't prompting the user for that folder every time you run the subVI.

Some of this is hard to describe, but hopefully I am getting my point across. The way that VIs work together within/parallel/inline is a tricky concept at first, but makes LabVIEW development fast once you get the hang of it.