Vertical synchronization when displaying video

[Root_Canal]

When rapidly displaying images using IMAQ display, image tearing is always present (rendered frame is a fragmented combination of two seperate frames). The synchronous display option does not alleviate the problem. Adding a time delay does not eliminate the problem. How do I force vertical synchronization in Labview?

thanks,

 -root

[Michelle_N]

Root-

Can you give me a little more information about what your code is doing? i.e. Are you doing a continuous grab from your camera in which the image is consistently unsynched? Do you get the whole image in Measurement and Automation Explorer? or is it cut off too? If you do a Snap, is that image cut off?

It would be really helpful if you could post your code/screen shot of your code.

[Root_Canal]

We are displaying individual 8 bit images in rapid succession. Each image is a frame of video that has been processed. I've noticed that on my rig, no matter what flavor of vi I am running, the IMAQ display is never synced up with the computer monitor frame buffer readout. here's a simple VI that should instantly reveal if you have the same problem on your computer. A snap does not produce a torn image, so the problem is that the monitor readout is not syncronized with the labview image buffer write.

Please do not run this vi if you have photosensitive epilepsy.

The vi will rapidly display alternating frames of red and blue. If you have screen tearing, you will see horizontal lines seperating blue and red boundaries. Otherwise, you'll see a uniform field flashing red and blue, or a uniform purple field if your frame rate is high enough.

Adjusting the timing delay does not eliminate the problem, it just reduces the odds that the monitor will grab a frame while labview is writing to the image buffer. even with a large delay, I still see an occasional torn frame.

I'm running windows xp service pack 2 on dual intel xeon 5140 2.33 GHZ CPUs 2.00 GB of RAM, NVIDIA Quadro FX 3450 SDI graphics card. my monitor is set to 60 Hz, reading out over a DVI cable.

Message Edited by Root Canal on 10-16-2008 01:19 PM

Message Edited by Root Canal on 10-16-2008 01:22 PM

[Michelle_N]

root-

I see what you are talking about. This seems to be an issue with how fast we are reading the image buffer and I think this is expected behavior. Although it effects how you see the image updating, it is not a reflection of the image itself. You can increase the delay such that there is enough time to update the display. You'll have to be careful on what else is going on in the while loop as you probably do not want to delay your processing. 

I did try the WindDraw VIs to see if they had any better result, but they also take a little while to update the display.

[Root_Canal]

I find that adding a delay does not remedy the problem, it merely reduces the odds that LabVIEW will be updating the image at the same time it is being read out to the computer monitor. Even with a delay of one second per frame, you can periodically see torn frames.
 

There must be a way to get LabVIEW to syncronize with the display frame rate. All commerical video display software possesses this functionality.
 

I wrote video out of LabVIEW at several different frame rates and I can view the video with windows media player, or even freeware video players without seeing any tearing. But if I "play" the video in LabVIEW, it looks horrible. That can't be expected behavior!?!?

[Michelle_N]

root,

There is a big difference between creating each new image on the fly and updating the display versus reading an AVI file. What you have been doing in LabVIEW is creating a new frame and updating the display when needed. When you said "play" I'm not sure if you are actually reading the AVI file in LabVIEW or simply updating the image display. These two things are NOT the same. If you were to read the AVI file in LabVIEW you should see similar performance to what you see in Windows Media Player, or any other AVI reader.

I've tried this and see a small difference but it is no where as slow to update as when we are writing to the display on the fly. I do notice some jitter. 

Try my AVI file with the Read AVI Exampl VI.

[Root_Canal]

I still see the exact same problem when playing your AVI with Read AVI Example.vi.

My object tracker program that I am unfortunately not at liberty to send you does, in fact, read from an avi and then display the image in the exact same way that Read AVI Example does. Keep in mind that even on a fast computer, reading from an avi takes a long time (typically many milliseconds). On my computer (see specifications earlier in the post) Read AVI Example.vi can't hold a stable 60 Hz even when reading a small format avi such as the one you sent. When I time it, the max it can sustain is about 30 Hz, peaking at around 49 or so.

Nevertheless, even with 2 display monitor frame times in which to sneak in the display write, every now and then (a few times a second) I, also see the "jitter" that you see, which is image tearing. The problem is quite definitely that Labview is not performing vsync properly. This might be a problem with the national instruments driver.

I've noticed a post from another person trying to figure out if he can read the vsync flag off of his graphics card because, just like you and I, he sees that nasty horizontal line tear in his display when quickly cycling through a series of images, whether they be read from an AVI file, created mathematically, or spirited into memory through some other divinely sanctified means.

I suppose the question then becomes: Does the labview display driver support vsync (vertical synchronization) or not?

thanks,

-root

Message Edited by Root Canal on 10-21-2008 11:35 AM

[Andrey_Dmitriev · Accepted solution]

Hi, root,

Just short explanation: LabVIEW itself (more exactly - IMAQ Vision) doesn't have support for vsync for Image Display (I mean the control placed on the front panel). But IMAQ Vision supported vsync in IMAQ Draw (where you can enable this with IMAQ NonTearing Window).

What you can do is following: Use IMAQ Draw instead of Image Display. Image will be displayed in separate window, but you can embed IMAQ Window int Front Panel as child window.

Another method - use DirectDraw for getting vertical blanc from graphic card. This method may work for moderated sizes of the image. If you will try to visualize pretty large image, then it will be not work, because time for redraw will be bigger than time between blanks.

Anyway, example in attachment.

Andrey.

[Root_Canal]

neat! thanks!

[BruceMoyer]

This would be a nice feature to have.  Any plans for it in future versions?  I'm experiencing this tearing effect too with the IMAQ Display control and it would be nice to be able to use this control without image tearing/flickering.

Bruce