bids-specification icon indicating copy to clipboard operation
bids-specification copied to clipboard

[ENH] allow for _stim.{mp[34],mkv,avi} to provide stimuli files for func data

Open yarikoptic opened this issue 4 years ago • 2 comments

The intention is to allow for BIDS to have not only "one for all" stimuli/ which is typically used for storing stimuli shared (selectively or overall) across subjects, but also to allow for storing subject/session specific audio-video stimulation. Such stimulation could be

  • pre-"rendered" audio or video clip presented to the subject
  • recording of auditory input from some interactive sessions or hyperscanning (as received from another participant)
  • VR feed presented to the subject
  • or, just simply audio/video recording for EVERY BIDS dataset/acqusition, as we are aiming to achieve with https://github.com/ReproNim/reprostim/ (which was already handy to recover trial order randomization in the event of an overriden protocol file)

Note that we already had _stim.{tsv,json} reserved for similar cases in the scope of https://github.com/bids-standard/bids-specification/blob/HEAD/src/04-modality-specific-files/06-physiological-and-other-continuous-recordings.md

And in this case ideally each .media (.mp3 etc) file SHOULD be accompanied by .json. I do see that aforementioned one making .json a MUST to have one one, but I do not think it is necessary in the case of .media recordings since ideally they should be perfectly aligned (thus StartTime=0), there would be no Columns, and SamplingFrequency might be insufficient since might need to be specified for different stimuli streams (video or audio).

WDYT?

TODOs

  • [ ] do formalize the content of .json sidecar file
  • [ ] add pertinent example(s) in the section for functional data?

yarikoptic avatar Mar 09 '21 19:03 yarikoptic

I think for subject specific stimuli that don't fit into the _stim.[tsv.gz|json] I would organize my /stimuli directory in a suitable way, and use the stim_file column from events.tsv to point to these files.

├── participants.tsv
├── README
├── stimuli
│   ├── sub-01
│   │   └── movie.mp4
│   └── sub-02
│       └── movie.mp4
├── sub-01
│   └── eeg
│       ├── sub-01_task-movie_channels.tsv
│       ├── sub-01_task-movie_eeg.edf
│       └── sub-01_task-movie_events.tsv
├── sub-02
│   └── eeg
│       ├── sub-02_task-movie_channels.tsv
│       ├── sub-02_task-movie_eeg.edf
│       └── sub-02_task-movie_events.tsv
├── task-movie_eeg.json
└── task-movie_events.json

Where then for example sub-01_task-movie_events.tsv would contain the path (relative to /stimuli) to sub-01/movie.mp4

What would speak against such an approach?

sappelhoff avatar Mar 11 '21 09:03 sappelhoff

What would speak against such an approach?

just some quick ideas now that I recalled this PR to exist ;) :

  • choosing one ad-hoc type of stimuli serialization (.tsv.gz) over an original (.avi)
  • replicating full hierarchy of subjects elsewhere
  • stimuli/ layout is not formalized IIRC
  • loosing possibility to validate correctness of those files etc (e.g. validator could ensure that duration of audio/video corresponds to the duration of the functional run if such a file was located nearby)

yarikoptic avatar Jan 09 '22 23:01 yarikoptic