Drifting gratings and random dots

hi chris,

mworks is now installed on one of our rigs.
we started playing with the drifting gratings and had a few questions that probably should be documented.

1-How are stimulus parameters specified?Is size in pixels?Is spatial frequency in cycles per image?what about speed, is it speed or is it temporal frequency?While it is possible to figure all of this out, might be good to have it written somewhere.
2-How does one manipulate contrast? Can we do multiple and overlapping gratings?I know the answer is yes in opengl, but has it been implemented in the “grating plugin”.

we tried to look for some sample random dot motion stimuli, but couldn’t find any on the website. Might have been looking for the wrong thing, but is there a chance you can share some with us? do we need to install a plugin to make these stimuli work?

best
najib

Hi Najib,

Regarding the drifting grating stimulus:

Is size in pixels?

No, position and size are in the same units as other standard stimuli: visual angle in degrees of arc, with the conversion to pixels determined by the width, height, and distance values specified in your setup_variables.xml file.

Is spatial frequency in cycles per image?

No, it’s in cycles per degree of visual angle.

what about speed, is it speed or is it temporal frequency?

Speed is in degrees of visual angle per second.

How does one manipulate contrast?

If the background is 50% gray (as it is by default), then the alpha_multiplier parameter determines the contrast. The valid range is 0 to 1.

Can we do multiple and overlapping gratings?

You definitely can do multiple gratings. The drawing code is quite efficient, so performance should be good even with many gratings on screen at once.

You can also overlap gratings, with the (probably significant) caveat that gratings are opaque, so you can’t, say, display a rectangle containing two independent, intermingled gratings. If that’s something you need, then I can update the plugin to do that.

Regarding the random dots stimulus:

we tried to look for some sample random dot motion stimuli, but couldn’t find any on the website. Might have been looking for the wrong thing, but is there a chance you can share some with us?

Sure, you can find several here. Here are the units of the various parameters:

  • field_radius, field_center_x, field_center_y, dot_size: visual angle in degrees
  • dot_density: number of dots per square degree
  • direction: angle in degrees between the velocity vector and the positive x-axis (so 0 is to the right, 90 is straight up, etc.)
  • speed: degrees of visual angle per second
  • coherence: unitless, range is [0,1]
  • lifetime: seconds (the amount of time a given dot is onscreen before being removed and replaced)
  • announce_dots: boolean; if true, the dot positions are included in the stimulus announcements that are recorded to the event file

You’ll be the first person (besides me) to test this stimulus, so I’d appreciate any feedback or suggestions you have.

do we need to install a plugin to make these stimuli work?

No, the plugin is bundled with the MWorks nightly build, so the examples should just work.

If you have other questions, please don’t hesitate to ask.

Cheers,
Chris

Hi Najib,

i am enclosing the original code that Tony Movshon wrote to present random dots to non-human primates. i am not even sure what language it was written, but the main thing to notice is that there is no dot lifetime in his instantiation.

how difficult would it be to replicate this kind of logic in your dots plugin?

After some brief research, my best guess is that the code you sent me is written in MACRO-11, the assembly language for the PDP-11. While it’s kind of fascinating as a historical artifact, it’s not going to be of much help in implementing the MWorks dots plugin.

Regarding dot lifetime: So far, the only people who have been willing to describe a dot-generation algorithm to me are folks who don’t use dot stimuli in their research. I believe it was Jim who said that dot lifetime should be a parameter, so that’s why it’s there.

A while back, Mehrdad (again, someone who does not use dot stimuli) was kind enough to share some details about Expo’s handling of dot fields. In particular, he mentioned the “epoch” parameter and gave me some source code. The documentation included with the source says:

Specify in Epoch the interval (typically a small number of frames) after which an element will be regenerated in a new position. Within each of the N frame ticks in an epoch, Expo normally generates 1/N of the elements specified by Dots/Epoch/Deg2.

If I’m interpreting that correctly, it means that the only difference between Expo’s “epoch” and my “lifetime” is that the former is specified in frames and the latter in seconds. If you want the MWorks plugin to use “epoch” and frames, too, that’s no problem.

Best,
Chris