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.



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).



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


My setup:

Computer: PowerMac 3.2 GHz Quad-core Intel Xeon, running OS 10.6.6 (updated


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:



and the data:






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.