Display Picture From Video Recording.

[markconigliaro]

Hello everyone, I'm very new to Labview (not too new to programming in general, though), but I'm having a problem.

I was given a program to modify. The program is a constantly running video camera, and you can press a button to take a picture and a different button to start recording video. The program works fine, but my problem is that when taking a picture, the picture saves to the specified folder and that's it. What I need to happen is I press the button, the picture is saved, AND the picture is displayed on the screen so I can mess with it later. I'm using IMAQ Write JPEG File, inputs being the video and the constructed filepath, all inside a case structure for the button. And the problem with that is that there's no output, that's just the end of the code, so I can't grab the filepath from it after it saves (I can easily grab and display a picture given it's filepath). I tried grabbing the path before it went into the IMAQ Write and I got stuck in an infinite while loop. 

My workaround was to find a way to display the last created picture, but that seemed like too much work for something as little as "push button, save and display picture". The computer with labview does not have internet, so if this is unclear, I can take a screenshot and post it tomorrow. Thank you for any suggestions.

[Bob_Schor]

Post your code.  Attach the VI itself, not a picture of (part of) the Block Diagram.  If multiple VIs are involved, compress the folder that contains them and attach the resulting .ZIP file.  We should then be able to make a meaningful (and, I hope, sensible) response.

Bob Schor

[markconigliaro]

Hopefully that's what you need. Thank you.

[Bob_Schor]

The Stacked Sequence structure is, by far, the most horrible-to-decipher structure within LabVIEW (many have advocated for its removal).  The only thing worse than a Stacked Sequence is one where only one member has code!

There is so much missing and "wrong" with this "excerpt" that you chose to show that it is almost pointless to try to correct.  Instead, you should think about redesigning your task "from scratch" according to reasonable design principles, starting with (probably) something like a State Machine, or possibly a Queued Message Handler "acting" (in part) as a State Machine.

Before doing this, try the "Old School Adage" of "Write the Documentation First".  One of the problems is that the Tasks and Goals of this Program are very unclear.  The only thing that is obvious is that Video Images are being acquired from a Camera.  Here are some suggestions about clarifying the Specifications in the Documentation:

• Describe the video acquisition in terms of Frame Rates and Duration.  Does the whole program revolve around a single Recording Session?  Are there multiple Recording Sessions (i.e. do you start and stop the camera more than once)?  Does Recording start when the program starts, and end when it ends?
• Are you saving the video?  If so, describe the file format, including details for creating the file name(s).
• Are you viewing the video?  Every frame?
• Do you need to view isolated frames?  If so, how are they selected?  How are they displayed?  Are they manipulated in any way?  Are they saved separately from the video (assuming that the Video is saved to a file)?  Do you need to save the isolated images (as opposed to saving the frame number of the image from the Video file)?  If so, how are you naming the isolated images, and in what format will the images be saved?

When I've done something like this, I've often used a multi-loop architecture, sometimes based on the Queued Message Handler.  I've had an Event Loop to handle Front Panel interactions (such as "Save This Frame" button pushes).  The Camera was typically in its own Queued State Machine loop, started from the QMH enqueing a "Start Video" state, whereupon the Camera Loop acted as a Producer, enqueing Frames to a Consumer loop that handled saving the Videos and potentially sending individual Frames to another "Process Single Frame" "sub-Consumer" Loop.

Learn to use sub-VIs (each having an Icon that you create) to handle the important-but-distracting-details, such as "Create AVI PathName" or "Create Frame PathName".  You can also encapsulate "Save JPEG" or other "distracting" details.  Ideally, you should be able to look at a single screen image of your top-level VI and understand what the program is supposed to do, with the details of how it does it possibly buried within well-named sub-VIs.

Bob Schor 

[markconigliaro]

Wow, thank you for detailed response. Although being new to labview, I don't understand most of it, but I have plenty of time to learn. But like I said, I was given this program by someone else, so things like the Stacked Sequence may have had a purpose at some point (or involved future plans) that I wouldn't know about. I agree that it's a bit unclear, one of my goals was to clean it up a bit when I knew what I was doing (I'm a bit of a stickler for organization and clenliness), but if it's that bad I'll now consider learning and reworking it to make it more efficient.

[Bob_Schor]

The problem with the Stacked Sequence, besides the fact that there's no good mechanism (like Shift Registers) to transfer data from one "state" to the next, is there is no logic to the various Sequences other than sequential ("Do 0 first, then do 1").  Consider replacing it with a State Machine, a While Loop with a State Selector (typically an Enum whose values "names" the respective States, making the logic more transparent if you use names like "Initialize", "Start", "Acquire", "Process", "End".  You can use Shift Registers on the enclosing While to hold variables that persist (and may change) throughout the loop, making Data Flow much more "obvious".  Indeed, when I first encountered these monstrosities, I immediately replaced the Stacked Sequence with a For Loop surrounding a Case Statement, wiring the Index to the Case Selector (pretty lame, as I had States 0, 1, 2, also not very mnemonic, but at least I gained Shift Registers -- I learned later about State Machines).

Bob Schor