Save screen shot efficiently?

[Azazel]

Hello all,

I have a VI that is used for real time imaging and this VI requires to save raw data and screen shots from time to time.  The Vi works fine but when I save data and/or screen shots the frame rate is reduced dramatically.  I have this saving option running inside my main while loop which I think is the problem.  I played around with several while loops to force labview to create more threads but I wasn't succesful.  I couldn't get the save data/screen shot while loop to begin as the program never left the main while loop.  I have attached a vi that highlights parts of my main vi with data generation and graphing and my current method of saving.  Can anyone improve this...I also looked at queue's but got really confused.  Thanks for you help in advance!!!!!!

Thanks,

Azazel

[mfitzsimons]

Azazel,

I am not sure where the issue lies in this program.  From what I read is that the frame rate drops down when you save the front panel image.  Is this correct? 

To create more threads you need to create new, separate, while loops.  Queues are very easy to use.  Use Obtain Queue in both while loops and name them the same.  In one while loop use enqueue elements to add to the queue and use dequeue in the other while loop.  When done use Relese Queue to clean up the queue. 

Does this help?

Matt

Message Edited by mfitzsimons on 11-10-2005 10:34 AM

[DFGray]

I am not sure that you will be able to get around the frame rate drop when you save a screenshot.  This will strongly depend upon how much you are utilizing your computer bandwidth (disk, bus, memory, cpu).  If you are not really utilizing it and just need to break the two processes into two loops, try the method shown in the image I have attached.  Just wrap it around your current code.

The queue is used to signal the bottom loop to execute the screenshot code.  It is overloaded to exit the loop as well.  The bottom loop will wait forever on the queue, so does not take any CPU time until it actually executes.  This allows your acquisition code in the top loop to run full speed at all times.  If you have a hyperthreaded or multi-processor machine, LabVIEW will take advantage of it.

One other thing which may help.  JPG is a poor format for screenshots.  Due to the lossy compression algorithm, it produces halos around all the edges and text.  I would only use it if you absolutely must have the smallest possible file size.  If you need small size, I would recommend GIF or PNG.  If you need speed, use BMP.  The file size will be large due to no compression, but it requires much less CPU time due to no compression, so will probably give you a net increase in speed.  If you need smaller files for storage, you can use another program to convert from BMP to GIF or PNG.  Note that a 256 color PNG or GIF with an optimized palette is usually about the same size as a JPG, with much better quality, for LabVIEW screenshots.  If you don't have a way to convert the images, IrfanView (interactive) or ImageMagick (command line/script) are both free for personal use and work well.

[Philip_Courtois]

Hi Azazel,

I agree with DFGray that it's good to consider different image types for optimized performance.

I also want you to consider using an Event Structure to handle the part of the code that saves the screenshot. That is probably easier than using Queues for this purpose. Here's how you could do it:



I've attached the VI too (download LabVIEW 8.0 from ni.com/downloads).

Have fun!

Message Edited by Philip C. on 11-12-2005 02:54 PM

[Azazel]

Thanks for all of your different suggestions.  The easiest one I have been able to implement is Philip C.'s approach with the event structure.  I do have another question.  With the sample vi you attached it saves a screen shot upon each boolean activation....I require the vi to save continuously until the boolean is de-activated.  Is this possible with the event structure?  So I only want to save images when the boolean is clicked, but the boolean should remain in a high state so the vi saves continously, and then stop saving images when the boolean is clicked to go back to the low state.  Thanks again for all of the great suggestions.

Azazel

Message Edited by Azazel on 11-14-2005 08:36 AM

[Philip_Courtois]

Hi Azazel,

Well in that case you should just use a Case Structure instead of the Event Structure and then connect a boolean control to the case selector. Two things are important: You need to include a delay inside the loop so you don't take a screenshot a million times per second. Use the "Wait Until Next ms Multiple" function or the "Wait (ms)" function. The second thing to remember is to specify the correct mechanical action for the boolean control by right-clicking and selecting "Mechanical Action". For keeping the value repeated in the state the button is in, use one of the "Switch..." modes. The "Latch..." modes will only return the value once and then return the button to it's default state.

Have Fun!