Synchronous image display on external display

[solarsd]

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

😎 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

[A_Person]

You said your sequence works at a loop rate of 5 s but what are you decreasing the loop rate to when you notice the problem?  Also, can you provide more detail on what you are doing to enforce the loop rate? 

To try and answer your specific questions:

1. There is not a way to determine through the WindDraw VI whether it was displayed to the monitor.

2. Don't know of one but question 3 may be on to another possibility.

3. You should be able to access these funcitons through ActiveX calls but I'm not sure if this would be faster as it would add in overhead.

4. Not really sure what you had in mind for this.

It's been a couple days since you originally posted the question so let us know if you have any updates or further information you can provide.

[solarsd]

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.

[A_Person]

Glad to hear you got things working with your application but sorry LabVIEW is not working with those ActiveX calls.  Thanks for posting details on the solution you came up with.  Hopefully someone will find some use for it at some point.

Did you have any further questions that you were looking for feedback on?

[Sababa]

Hi,

I had very similar problem. I found out that it is connected to the Windows OS: if you will set the LCoS as the main screen it may solve the problem.

I solved the issue using the graphic card feature called "Surraund". Mid level NVidia graphic cards has this feature.

If you will turn this feature on, windows will see both screens as single screen with double resolution, and it will be updated synchronously.

Good luck