Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

yarikoptic
Copy link
Collaborator

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)
  • 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?

…nc data

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)
- 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).

TODOs
- [ ] do formalize the content of .json sidecar file
@yarikoptic yarikoptic mentioned this pull request Mar 9, 2021
@sappelhoff
Copy link
Member

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 sappelhoff added the discussion ongoing discussion label Mar 30, 2021
@yarikoptic
Copy link
Collaborator Author

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion ongoing discussion stimuli
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants