Hi Arash & Yvonne,
In another discussion, Yvonne wrote:
when we actually run the experiment we will need to be able to average stimuli from the same time point in different trials together in order to employ reverse correlation analysis.
Had I known this when we were deciding how to generate the white noise you need, I would have strongly recommended that you stick to using pre-generated images, rather than generating the noise dynamically inside MWorks.
Here’s the problem: While it’s entirely possible, starting with the seed value and parameters of the stimulus and display, to re-create the entire sequence of noise images outside of MWorks, there are many details that you need to get exactly right. If you mess up the computation at any point, you can end up generating noise that’s entirely different from what was actually displayed during the experiment. If I were doing this experiment myself, and I really cared about the precise pixels that were displayed on screen, I would be very, very uncomfortable with this approach.
On the other hand, while pre-rendered noise images do take time to generate and disk space to store, they also give you an exact, explicit record of what was displayed. Using the MWorks event file, you can easily determine which image was onscreen at any given time, no error-prone computation required.
If you still want to generate the noise images on the fly, I think the best approach would be to use a Python or MATLAB script to generate them between trials, based on parameters defined in the experiment. Each image would have a unique name and would be stored in an archive directory for later use. This is kind of a “best of both worlds” approach, in that
- You get full control over how the noise is generated, but
- You don’t have to pre-generate a fixed number of images before the experiment runs and can instead generate as many as you need at run time.
Of course, I’d be happy to provide you with an example implementation of this idea.
What do you think?
Chris