Bugs
Bug list:
2011-03-22: Timing problem with stimuli that use color table animation
2011-01-01: Gratings in the wrong place (new news 2011-04-16)
2011-03-31: Update in timing problem with stimuli that use color table animation
Hi all -
I have heard back from Mario Kleiner, the head programmer of the Psychophysics Toolbox project. He has said that today's video cards make no guarantees as to the speed of Color Look Up Table installation. So it varies by the card, and apparently our card does not do it in a single frame guaranteed.
The upshot is that a few of our stims will need to be re-coded for optimal performance. A new rotation student on the lab (Bethany!) is beginning to work on this. I expect we will have significant updates in about 6 weeks.
The short version of the implications: gratings will have slight glitches but almost certainly not enough to affect responses (our lab is proceeding). Reverse-correlation-type stims are fine at lower frame rates but the transitions will take 1 video frame longer than you might expect. High speed reverse correlation stims (30Hz and up) will likely be very unreliable.
More in a few weeks.
Best,
Steve
2011-03-22: Timing problem with stimuli that use color table animation
On 2011-03-22 we noticed that there is a problem with NewStim for PsychToolbox 3.0. Stims that rely on Color Table Animation (this is most of the commonly-used stims, periodicstim (gratings), stochasticgridstim (dense noise), others). The time it takes to change the image on the screen can vary up to 1 video frame. This means that at high presentation frame rates the animation cannot be trusted to be accurate on a video frame-by-video frame basis. (For lower presentation frame rates, such as 10Hz in stochasticgridstim, there is usually a 1 video frame delay between onset and presentation, and this can be trusted).
This issue has been raised with the Psychophysics toolbox community (see message below) and I'll report back when I hear news. If no fix is available, we will need to re-code stims to use direct drawing rather than color table animation (will take a week or so).
Best
Steve
My message to the PTB list:
Hi all -
Last summer/fall I converted a lot of old PTB 2 code to PTB 3, but I still used
Color Look Up Table (CLUT) animation to perform some tasks (using
Screen('LoadNormalizedGammaTable')). I didn't keep any notes, but my
recollection is that everything was going fine timing-wise.
In the last week I've done some photodiode tests and it seems that it can take 0
or 1 video frames for an installed CLUT to actually show up on the monitor.
Flip returns normally and doesn't report any timing errors. Needless to say,
this has big implications for precise control of stimuli using CLUT animation.
A search of the archive didn't turn up anything obvious in this regard
(apologies if I've missed something).
I've created a test function called BlackWhiteTest (uploaded to the Yahoo group)
that uses 3 different schemes to alternate the screen between a black value and
white. For this stimulus, it is easy to examine the monitor output using an
oscilloscope and a photodiode to see at a glance if the system is doing the
right thing. When direct drawing is used, the stimulus appears to be right on
every time (perfect alternation between black and white); when either of 2 CLUT
animation schemes are used, the alternation is not performed correctly. (See
data on Yahoo group.)
Does anyone have an opinion as to whether is this a bug with my code, my set up,
Mac OS X, or PTB, or is this just the new normal (and we all need to use direct
drawing)?
My setup:
Computer: PowerMac 3.2 GHz Quad-core Intel Xeon, running OS 10.6.6 (updated
2011-03-21)
Video card: ATI Radeon HD 5870 OpenGL Engine :: 2.1 ATI-1.6.26
Matlab: 2009 32 bit mode
PTB: 3.0.8, revision 1942
Here is the link to the function:
http://f1.grp.yahoofs.com/v1/QI-ITdbEUGxHul-SMO6yFY_vs3mMKGzUMQalpJUAGfurywkYcvB\
9E0d0XYwSwM3Z95gFvERLrhLQfhKA71vrF5PQjzuFfA/BlackWhiteTest/BlackWhiteTest.m
and the data:
http://f1.grp.yahoofs.com/v1/QI-ITdJ4B6NHul-SiOuY0SOcwy4WjWVKHQfhpAFcQdTsbMUplIX\
oGYxrAIa7GbWh5oHywrdtDBslSA67-0W6UpCZpcKdkQ/BlackWhiteTest/BlackWhiteTest_photod\
Thanks
Steve
2011-01-01: Gratings in the wrong place
Gratings don't seem to show up in the right place. Our typical screen resolution is 800x600. If you request a grating to be placed at [0 0 800 600] ([left top bottom right]) it will appear lower on the screen. So far, asking for a rectangle of [0 0 1000 1000] will fill the screen, but this is a bug to be fixed.
This bug is probably in 1 of 2 places: either in the sub function "NewStimMasker.m", or in how the periodicstim/loadstim.m uses the output from this function.