Saccade-like trials in mworks

[ggaziv]

Hi Chris,

We’re considering running a modified version of our RSVP experiment, where each trial simulates a saccade-like scan of a “big” image.
Each trial will consist of a sequence of crops (K = 6-8) from an image, presented without masks within a trial (200ms “on” per image, ~2-5sec per trial).
The idea is that the user just hands over these N crops as the RSVP stimuli: 1…N where N = K * n, n being the total number of “big” images, and every subset of images, [1 + (j - 1) * K, 1 + j * K]; j=1…n, defines a valid trial/sequence.

A) How should we revise our standard RSVP .mwel file to implement this experiment? (our current .mwel is attached)
B) There is also another version of the above experiment, where the “saccades” appear in different orders. Specifically, we would allow for pemurations within a defined sequence across repeated presentations (but sequences should not mix).

Lastly, for this experiment, an entire trial should be invalidated if not fully completed (even if a part of the trial was successfully fixated on).

Many thanks in advance!
Guy

(attachments)

d1_v80.mwel (25 KB)

[cstawarz]

Hi Guy & Ani,

If I understood correctly,

1. each set of crops of a particular image constitutes a trial,
2. the order of the crops within a trial should be variable, and
3. the trial is a failure if the monkey breaks fixation at any time.

Is that right? If so, then I have a few questions/comments:

• How will the order of the crops in a trial be determined? Is it random, or will you draw from a set of predetermined sequences?

• Rather than creating separate image files for each crop, you could use just the “big” image and “crop” at runtime using masks (or even just four rectangles). That would give you the option of varying the content of each crop, if you wanted. Just something to consider.

Thanks,
Chris

[ggaziv]

Yes!

• We would ideally like to have both configurations available: Random order and fixed (predetermined). But definitely the more important one is the predetermined sequence.
• Interesting option but we would ideally have the crops controlled and determined on the user’s end.

[cstawarz]

Ok, thanks. I will put together an example of how this could work and send it to you.

Chris

[cstawarz]

Hi Guy & Ani,

I’ve attached an example that demonstrates a possible way to implement this experiment. Here are the key points:

• Each image file is named with two indices (e.g. img_3_5.png). The first index identifies the “big” image, and the second index gives the crop number. (An alternate approach would be to have a separate directory for each “big” image.)

• The selection variable (image_selection) selects a “big” image.

• The set of crops for each “big” image is loaded at the beginning of the trial and unloaded at the end.

• If fixation is broken at any point during the trial, the whole “big” image is rejected and will be selected again in a later trial.

• At present, the crop order is sequential. If you wanted to switch to random order, you could add another selection variable (e.g. crop_selection) to determine the crop order.

If you have any questions, please let me know.

Cheers,
Chris
simulated_saccade.zip (94.0 KB)

[ggaziv]

Perfect! Thank you so much, Chris.
To clarify, is this tested and ready to go as is as a substitute for the RSVP example previously sent (up to hyperparameters ofc)? What about stimulus_presented and those other guys relied on during preprocessing?
We are going to be tight in monkey time for this experiment so just trying to minimize the room for errors in execution.

Thanks again.
Guy

[cstawarz]

To clarify, is this tested and ready to go as is as a substitute for the RSVP example previously sent (up to hyperparameters ofc)?

No, it’s just a demonstration of how things might work. You will need to adapt the methods it uses to your actual experiment.

Writing full-fledged experiment code is not a service I provide (either for the DiCarlo Lab or anyone else).

Cheers,
Chris

[ggaziv]

Got it, thanks!
Will be in touch if running into difficulty.

[ggaziv]

If I were to unroll my image crops to a single index 1…n, would the following modification do the trick?

stimulus_group crops {
    range_replicator (
        variable = rr_index
        from = 1
        to = crops_per_image
        step = 1
        ) {
        image_file im_${rr_index} (
            // path = 'images/img_${current_image}/crop_${rr_index}.PNG'
            path = 'images/img$((current_image * crops_per_image + rr_index)).PNG'
            x_size = stimulus_size
            x_position = stimulus_pos_x
            y_position = stimulus_pos_y
            deferred = explicit
            announce_load = false
            )
    }
}

selection image_selection (
    // values = 1 : image_set_size
    values = 0 : image_set_size - 1
    selection = random_without_replacement
    advance_on_accept = true
    )

[cstawarz]

Almost. You need to put a $ in front of rr_index (one of the quirks of replicators):

path = 'images/img$(current_image * crops_per_image + $rr_index).PNG'

And you need to change crops_per_image from a macro to a variable:

var crops_per_image = 6

Then it should work.

Chris

[ggaziv]

Thanks! Hmmm do we understand this error then?

[cstawarz]

You need to declare the “images” directory as a resource, like my example does. You’ll need to do the same for the sounds directory (and any other resource files that your experiment needs).

Somewhere in your MWEL file, add the following lines:

resource ('images')
resource ('/Library/Application Support/MWorks/Examples/RSVPDemo/sounds')

Chris

[cstawarz]

Regarding the “There are no more items left to draw” error:

My example set the selection variable’s advance_on_accept parameter to true, so that it didn’t have to invoke next_selection. Since your experiment already uses next_selection, just remove that parameter from the definition of image_selection:

selection image_selection (
    values = 0 : image_set_size - 1
    selection = random_without_replacement
    )

That should fix the problem.

Chris