Synchronous image display on external display

Question

Hi,
I'm trying to get structural illumination microscopy using a LCoS spatial
light modulator working. The modulator is controlled using DVI interface, and
having no dedicated DVI capable hardware I'm stuck controlling the modulator
using a dual video output desktop PC. I've developed a VI that executes
following algorithm:
1) Show grid 1 on external display
2) Acquire frame 1
3) Show grid 2
4) Acquire frame 2
5) Show grid 3
6) Acquire frame 3
7) Compute and store image
8) Advance stage and repeat
I'm using the External Display VIs form the Vision menu group to display the
grids, and IMAQdx for the acquisition.
The problem I'm having is that when this looping is slow enough, say 5 s,
everything goes well, but when I optimized it and increased the speed, some of
the acquired frames are wrong. After some tedious debugging I've think the
problem is that shown images are delayed because of all the Windows fuss. There
is no way of synchronizing the displayed image with the acquisition routine -
after the image is "displayed" it's up for windows to actually
display it.
1) Is there a way to know that the image is actually drawn using IMAQ
WindDraw VI ?
2) Is there a better (as in faster, more predictable) way of showing a
bitmap image on an otherwise empty external display?
3) Maybe it is possible to control the external display using some kind of
low level video driver functions (OpenGL, DirectX, the card is NVIDIA, fairly
recent)?
4) Maybe the right way to do it would be to play a looping video? And if so,
how could this synchronizing issue resolved then.
Any kind of input would be appreciated.
lukas

Answer 1

Hi,
And thanks for the input. Yes, in fact we've made some progress, so I'll add some details on this problem. First the answers to A Person's questions:
1) The loop rate when this issue occurs is about 2-5 fps.
2) We are using a simple delay to throttle down the execution. Originally we intended to run this as fast as possible, so there was no need for specific execution speed.
And our progress is as follows:
1) As it appears and was confirmed by NI staff, we were unable to come up with any kind of workaround on the WindDraw method, so we're dropping it.
2) We've developed an simple DLL using VisualBasic to load our three bitmaps into a form window placed on the external display. The shown on one or the other bitmap now happens with a simple call to the DLL to change the visibility of a particular bitmap. It seems to solve our initial problem. Also, if that isn't enough, we're considering an analogous DLL using OpenGL orthographic projection window using three bitmaps and triple buffering. The specific bitmap would be shown then just by offsetting the video memory buffer.
3) The video idea was not that good after all I think. The advantage would still be fast DirectDraw accesses, but 2) method seems more reasonable.
And a little bit off this topic:
4) After solving this problem, we've encountered another. Now the camera acquisition isn't synchronized to the frame clock signal of the SLM. This produces a well known screen flicker seen on the TV when a computer or TV screen is filmed without a sync signal. Our camera, the Kappa DX4 274FW, has an external trigger connection, but the interface connection is a mini centronix. To be honest this is the first time I heard of it and it is next to impossible to get one for a reasonable price. Even if we could, there is no pinout nor the inner workings information concerning the trigger, the official site just states "External trigger". The official support is also ignorant. So that's thumbs down for Kappa. We've switched to Point Gray Chameleon camera, which has proper technical documentation on it's triggering functionality and the again present "we have and you don't, please buy from us" type connector was changed to a proper SMA connector with a bit soldering and drilling. The bad news is that the ActiveX interface used by this camera is using user defined return data types and some of the methods are grayed out when trying to call from LabView. According to
http://digital.ni.com/public.nsf/allkb/27B959B430BA501486256A920071F567
It wont and should not work, so now we're considering moving to VisualBasic completely. Again, it's worth mentioning that the initial problem could be solved using method 2), but this felt kind of connected and this "industrial connector hindering" business got me frustrated. So sorry for the lengthy post.