Hi Chris,
I’m following up on a previous conversation we had about using large sets of images, specifically with more than 8,000 images. I have a few questions I’d appreciate your help with, and I’m copying Ani, Guy and Jim since we’re verifying our analysis code on Guy’s experiment involving a large image set.
-
Hashing Policy
Could you provide more details about MWorks’ hashing policy for the stimulus set? Does MWorks use pixel-hashing, or does it generate unique hashes from filenames? Given the potential for redundant images, in large stimulus sets, is there something users should be cautious about? -
Accessing MWorks’ Hash Code
I’m developing a neural experiment pipeline and would like to ensure my code handles stimulus metadata accurately. Currently, I log the stimulus ID based on the MWorks experiment code, like the “stimulus_presented” variable in your RSVP example. Is there a way to access the hash table MWorks uses? Would doing so improve the reliability of managing stimulus metadata (compared to relying solely on the stimulus ID variable)? For example, if a user mapped their stimulus ID incorrectly in MWorks, could I still recover the exact filenames associated with the hash codes used in each RSVP trial (fixation)? -
Handling Large Lists of Images
I recall that Chong ran an experiment with a large image set. He chose to “vectorize” all repeated stimuli instead of repeating unique images—presenting 16,000 images once instead of showing 8,000 unique images twice. Is there a difference in maintaining image order between these two approaches? -
Lastly, I recently conducted an experiment involving 8,400 images presented twice. The parsed stimulus events and neural responses appear consistent, but I’d appreciate it if you could take a look at the MWorks code to ensure the code is handling image-ordering properly. Here is the dropbox link (2GB) containing the code and image set.
Thanks again for your time and help!
Yoon