Graeme Phillipson, 22nd April 2008
There are two methods of synchronising the display of stereo images in Psychopysics Toolbox. In one method you open one screen across both displays and in the other you open one screen for each window. This is the function used to open a window:-
[windowPtr,rect]=Screen('OpenWindow',windowPtrOrScreenNumber [,color] [,rect][,pixelSize][,numberOfBuffers][,stereomode][,multisample][,imagingmode]);
The parameter windowPtrOrScreenNumber can either be set to 0 which will return one windowPtr which referes to a screen which spans both displays or the function can be called twice with the windowPtrOrScreenNumber set to the ID of each screen to be used and then there will be two windowPtr values each one referring to one screen.
When drawing there will now be two different ways to interchange the front and back buffers depending on how the screen was opened. If one screen was opened across both displays then calling :-
Screen('Flip')
will interchange the front and back buffers on both displays simultaneously. However, if two separate displays have been opened then the multi-flip parameters must be set:-
[VBLTimestamp StimulusOnsetTime FlipTimestamp Missed Beampos] = Screen('Flip', windowPtr [, when] [, dontclear] [, dontsync] [, multiflip]);
A value of greater than zero for multi-flip will cause it to flip all screens which are currently open. This means it only needs to be called once, and it does not matter which screen ID you put into the windowPtrvalue.
In order to test the synchronisation between the screens two photodiodes were connected to an oscilloscope. Each photodiode was placed behind one eye of a pair of polarised glasses, so that it would receive a signal mainly from only one projector. The screen was then programmed to alternate between white and black to produce a square wave signal on each photodiode. To confirm that the signal seen on each photodiode was from one projector, and not from both projectors the flashing screen stimulus was run twice, once on only the left eye projector and once on only the right eye projector. In each case a square wave signal was seen on only one of the photodiodes.
In the case where only one screen was opened across both displays the synchronisation was good (it was not possible to visually identify a difference between the signals on the oscilloscope). However when two screens and multiflip were used then there was a synchronisation difference between the two screens of approximately 2.5ms. This is illustrated in the photograph below.
The difference in timing between the two screens is probably caused by the fact that multiflip works by making the OpenGL flip command on both screens as fast as it can in software, and so is limited by the speed at which system calls can be made. When only one screen is opened, the OpenGL flip command only needs to be called once by Psychophsyics toolbox, and the flipping of both screens is handled by the driver, which means there is much less overhead between the flipping of each buffer.
The problem with using only one screen is that it is not “officially” possible to use separate gamma correction tables for each projector. This means that any difference between each projector and the average of both of them will produce variations in intensity between the two eyes for a given output level. However it is currently possible to to load two different gamma tables with PTB by taking advantage of the undocumented behavior that opening a new window does not reset the gamma table. Therefore it is possible to open two separate windows and load a separate gamma table in each window, then close the windows and open one window that spans both of these. They will be left with separate gamma tables for each window from when they were altered before. See here for more on the gamma correction.
Jenny Read, 3rd December 2009 Today I tested the projectors again. Windows was set up such that each projector/monitor was recognised as a separate display. That is, the We have had some really wacky results today.
1. Windows was set up with the dual-output NVidia graphics card in “dual control” mode such that each projector/monitor was recognised as a separate display. That is, in Psychtoolbox
Screen(‘Screens’) gave [0,1,2,3] where 1 and 3 are the projectors, each 1400×1050 pixels, and 2 is the control monitor, 1280×1024, and 0 is both projectors considered as a single monitor, 2800×1050 pixels, by Psychtoolbox. I opened a single window in Psychtoolbox in stereomode 4 (free fuse, i.e. the two eyes’ input correspond to the left/right halves of monitor)
Screen(‘OpenWindow’,0,[],[],4) I set up a flashing stimulus, 1 frame of white 11 frames of black, and looked at the output with a photodiode. I found that there was a delay of 5ms between the projectors. This was disturbing, because when this was tested in 2008 (above), we found that there was no asynchrony under these circumstances.
2. So I then changed Windows so that the dual-output NVidia graphics card was in “horizontal span” mode, such that Windows saw both projectors together as a single display.
Screen(‘Screens’) [0,1,2] where 1 is a single screen corresponding to both projectors, 2800×1050 pixels, and 2 is the control monitor, 1280×1024. I again opened a single window in Psychtoolbox in stereomode 4, this time on the single projector “screen”
Screen(‘OpenWindow’,1,[],[],4) This reduced the asynchrony to about 2ms
It seemed clear that the problem must be that the graphics card was not updating both projectors simultaneously. To verify this, Ignacio suggested we swap round the projector DVI cables. If the asynchrony was in the computer signal, this would swap over the delay, i.e. the projector which was previously leading would now lag. To our surprise, the delay remained the same – the top projector was still updating first.
So it now seemed as if the problem must lie in the projectors. Even if they receive synchronous inputs, apparently the bottom one takes 2ms longer to display the input than the top one.
We turned the projectors off and unplugged them. Cue some panic when the top projector would not turn on again. It seemed completely dead. But the computer was still displaying the flashing test pattern in Psychtoolbox. When we stopped that running, suddenly the projector started working again! Bizarre. Why would it care what image it was asked to display??
Anyway, so we went back to dual display mode. This time the asynchrony was 7.5ms – half a frame! But once again, it didn’t invert when we swapped the DVI cables to the projectors, suggesting the problem was in the projectors. This could be due to the colourwheel not synching to the refresh rate. My understanding had been that the F2sx projectors do synch to the refresh signal, and my previous testing had indicated this, but it certainly wasn’t looking like it today.
We then changed back into span mode, without turning the projectors off as we did so. This reduced the asynchrony to 2ms or so. As ever, it didn’t invert when we swapped the DVI cables. We were left scratching our heads.
- Each time we test it, the asynchrony on the oscilloscope is completely fixed and regular: it’s not a case of random noise and jitter.
- Even with the asynchrony, the substructure within each frame of white is identical for each projector, which is reassuring as well. [In DLP projectors, a white frame consists of many flashes of light from the mirrors, passed through different filters of the colourwheel, so a single frame on the oscilloscope consists of 8 or so spikes of differing amplitude. The pattern of spikes is identical for both projectors.]
- The problem can’t be just the signal from the computer, otherwise which projector displayed first would depend on which way round we connected the cables.
- The problem can’t just be the projectors (e.g. a lag from vsynch to display update which is constant for each projector but different between them), as otherwise it would not depend on whether Windows was set to use the projectors in span mode or dual display mode.
As far as I can see, we have to postulate some interaction between the computer signal and the projectors. E.g., in span mode, the bottom projector takes 5ms longer to update than the top projector, but in dual-display mode, it takes only 2ms longer. 1413 – span mode; top projector sees a flashing rectangle on left, bottom on right (or viceversa): y1 leads y2 by around 1.8ms 1420 – span mode; now both projectors get identical rectnagles in middle of screen; y1 still leads y2 by around 1.8ms 1430 – dual display mode; now both projectors get identical rectangles in middle of screen; y1 now leads y2 by around 7ms 1432 – dual display mode; swapped oscilloscope inputs around; y2 now leads y1 by around 6ms 1434 – went back to span mode leaving osc inputs in swapped position; y1 now leads y2 by around 2ms, 1.95ms 1434 – swapped osc inputs back ; y2 now leads y1 by around 1.8ms Seems to me this indicates a possible contribution of 0.05ms due to the different cable lengths or due to any timelag between channels 1 and 2 on the ‘scope. So this is not the problem. 1520 – took out RS-232 cables and turned off Virtalis box. y1 still lags y2 by 1.9ms or so. – pic1 1620 – bypassed DVI splitter boxes and connected dual output of graphics card via DVI-VGA converter to VGA input of projectors. Now, the lag was about 1.5ms — and critically, it now swaps sign when we swap over the VGA cables into the projectors! This was in span mode. 1630 – moved to dual-display mode.