On 06/19/2017 09:44 AM, 天马行空 wrote:
at the moment you should ask such questions on the PTB forum, not my
e-mail, unless you have a support contract with me. Forwarding the
conversation to the forum, please respond there if you have further
questions.
OS+graphics driver, if the driver supports that. Otherwise it falls back
to our own stereomode 11 implementation.
In true stereomode 1, we have no way to detect when stimuli update on
the screen under MS-Windows, and if returned Flip timestamps correspond
to the left eye or right eye hitting the screen, or if this is variable,
e.g., sometimes left eye, sometimes right eye. All you get is some hints
by how the system behaves. If PTB reports a
Screen('GetFlipInterval',...) of 2 refresh durations then that would be
a hint that each flip only happens after both imags of a stereo pair
have been presented for at least one refresh cycle.
always presenting each image of a stereo pair at least once, as long as
it flickers between mostly yellow and black, as the code inserts a black
stereo-pair every 2nd flip. I don't know how strong the flicker would be
at 120 Hz, but it is strong at 60 Hz.
If timestamps correspond to the left eye or right eye can't be detected
by that test on Windows though.
If you want reliable timestamps and stimulus onset timing, you'd need to
switch to Linux and see if your NVision 3D goggles work in stereomode 1
or 11 ("help NVision3D" for setup for stereomode 11). At least in
stereomode 11, with PTB's own implementation, you can control which eye
should Screen('Flip') first, by selecting it during a
'SelectStereoDrawBuffer' call:
Screen('SelectStereoDrawBuffer', w, 0, x);
With x = 0 --> Flip, so that Flip updates to a new stereo-pair with the
left-eye stimulus first, and the returned timestamp correspond to
left-eye stimulus onset.
x =1 --> Flip, so that Flip updates to a new stereo-pair with the
right-eye stimulus first, and the returned timestamp correspond to
right-eye stimulus onset.
For those settings, it would be guaranteed that each stereo-pair is
presented fully for at least one refresh cycle per eye. The default
setting for x, if you never specify it, is x = -1 == "Don't care".
In stereomode 1 on Linux, when using a proprietary graphics driver for a
NVidia or AMD Pro-Series card, PTB would still try to make stimulus
onset and timestamping consistent on a specific eye for a x = 0 or x = 1
setting if the graphics driver allows that, but you'd need to use the
FrameSequentialStereoTest to find out, what setting of x to use for
onset on which eye, as this might be driver specific, or even
incorporate the probe logic from FrameSequentialStereoTest to adapt your
script to potential changes for each session, as it is up to the
proprietary drivers on how they implement this. It's just that your
chances for consistent behavior in stereomode 1 are much better on Linux
than on Windows.
-mario
> Dear Mario Kleiner,Hi,
at the moment you should ask such questions on the PTB forum, not my
e-mail, unless you have a support contract with me. Forwarding the
conversation to the forum, please respond there if you have further
questions.
> Recently, I'm trying to write stereo stimuli with PTB3 and NVidiaStereomode 1 uses the native OpenGL quad-buffered stereo support of your
> 3D vision. I wanted to present stereogram with fixed duration. So I want
> to know the exact timing for every flip at stereo mode 1 (temporally
> interleaved, display running at 120 Hz). I thought that each flip would
> flip left and right buffers and take 2 inter-frame intervals (2/120Hz).
> However, it seemed not the case. Would you please clarify how flip works
> at stereomode 1 for me?
OS+graphics driver, if the driver supports that. Otherwise it falls back
to our own stereomode 11 implementation.
In true stereomode 1, we have no way to detect when stimuli update on
the screen under MS-Windows, and if returned Flip timestamps correspond
to the left eye or right eye hitting the screen, or if this is variable,
e.g., sometimes left eye, sometimes right eye. All you get is some hints
by how the system behaves. If PTB reports a
Screen('GetFlipInterval',...) of 2 refresh durations then that would be
a hint that each flip only happens after both imags of a stereo pair
have been presented for at least one refresh cycle.
> We tried FrameSequentialStereoTest(). Without shutter glasses, theMostly yellow is good, also hinting at one flip every 2 video refreshes,
> display showed mostly yellow but had serious flickering. Here is our set
> up: asus pg278qr +win10 64bit + nvidia gtx1080+3D vision 2. Does it mean
> our system has a very noisy timing?
always presenting each image of a stereo pair at least once, as long as
it flickers between mostly yellow and black, as the code inserts a black
stereo-pair every 2nd flip. I don't know how strong the flicker would be
at 120 Hz, but it is strong at 60 Hz.
If timestamps correspond to the left eye or right eye can't be detected
by that test on Windows though.
If you want reliable timestamps and stimulus onset timing, you'd need to
switch to Linux and see if your NVision 3D goggles work in stereomode 1
or 11 ("help NVision3D" for setup for stereomode 11). At least in
stereomode 11, with PTB's own implementation, you can control which eye
should Screen('Flip') first, by selecting it during a
'SelectStereoDrawBuffer' call:
Screen('SelectStereoDrawBuffer', w, 0, x);
With x = 0 --> Flip, so that Flip updates to a new stereo-pair with the
left-eye stimulus first, and the returned timestamp correspond to
left-eye stimulus onset.
x =1 --> Flip, so that Flip updates to a new stereo-pair with the
right-eye stimulus first, and the returned timestamp correspond to
right-eye stimulus onset.
For those settings, it would be guaranteed that each stereo-pair is
presented fully for at least one refresh cycle per eye. The default
setting for x, if you never specify it, is x = -1 == "Don't care".
In stereomode 1 on Linux, when using a proprietary graphics driver for a
NVidia or AMD Pro-Series card, PTB would still try to make stimulus
onset and timestamping consistent on a specific eye for a x = 0 or x = 1
setting if the graphics driver allows that, but you'd need to use the
FrameSequentialStereoTest to find out, what setting of x to use for
onset on which eye, as this might be driver specific, or even
incorporate the probe logic from FrameSequentialStereoTest to adapt your
script to potential changes for each session, as it is up to the
proprietary drivers on how they implement this. It's just that your
chances for consistent behavior in stereomode 1 are much better on Linux
than on Windows.
-mario
> Thank you.
>
>
>
>
>
> Part of my code is listed as following:
> %%%%%%%%%%%%%%%%
> for i_frame = 1:nframes_animation
> Screen('SelectStereoDrawBuffer', w, 0);
> Screen('DrawTexture',w,
> Wbg_L,[],CenterRectOnPointd(frameRect,center_left(1),center_left(2)));
> Screen('SelectStereoDrawBuffer', w, 1);
> Screen('DrawTexture',w,
> Wbg_R,[],CenterRectOnPointd(frameRect,center_right(1),center_right(2)));
> Screen('SelectStereoDrawBuffer', w, 0);
> Screen('DrawTextures', w, gabortex, [], dstRects_l(:,:,i_frame),
> rotAngles, [], [], [], [], kPsychDontDoRotation, mypars_l);
> % Screen('DrawTexture',w, Wbg_L);
> % Screen('DrawingFinished',w);
> Screen('SelectStereoDrawBuffer', w, 1);
> Screen('DrawTextures', w, gabortex, [], dstRects_r(:,:,i_frame),
> rotAngles, [], [], [], [], kPsychDontDoRotation , mypars_r);
> % Screen('DrawTexture',w, Wbg_R);
> Screen('DrawingFinished',w);
> vbl=Screen('Flip', w);
> end
> %%%%%%%%%%%
>
> ------------------
> Zhimo Yao Ph.D
> School of Ophthalmology & Optometry and Eye Hospital
> Wenzhou Medical University,
> Wenzhou, Zhejiang 325027, China
>