-
Notifications
You must be signed in to change notification settings - Fork 4
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
ADD overview.md #28
ADD overview.md #28
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
The RepoStim project provides a data solution for archiving and cataloging stimulus presentation records for fMRI experiments. | ||
A “record” in this context refers to a digital media file that contains the audio and visual stimulation presented to a subject while undergoing fMRI scanning for a particular session. | ||
The goal is to provide one record for every acquisition collected at an fMRI research center where audio/visual stimulation was presented. | ||
The merits of collecting such records, if not obvious, are numerous and will be considered in a separate section. | ||
While the scope of the project is limited to the special circumstances of collecting data at an fMRI research center, we anticipate that future modifications driven by interest and necessity may expand the set of use-cases to include other behavioral and neuroimaging paradigms. | ||
andycon marked this conversation as resolved.
Show resolved
Hide resolved
|
||
Within its current scope, ReproStim is meant to serve as a center-wide resource for a brain imaging center. | ||
Thus, the setup and maintenance of ReproStim is expected to fall under the purview of an authorized IT specialist charged with center operations and data archiving. | ||
andycon marked this conversation as resolved.
Show resolved
Hide resolved
|
||
End users, including researchers who collect and analyze data at the center, ideally need not interact with ReproStim in any way except to benefit from having access to stimulus records associated with their fMRI data as procured by the center. | ||
Given this general overview of the scope and purpose of the ReproStim project, there are four major components to the project that must be considered. | ||
These include hardware requirements and setup, server software configuration, tools for record procurement, and documentation. | ||
|
||
Setting up ReproStim requires an initial investment in hardware, including a video capture device, a computer that runs the ReproStim capture server software, | ||
a USB “sniffer” device to capture scanner trigger pulses for use by the capture service, | ||
and necessary cables and connectors including audio and video splitter cables. | ||
[These details will be filled in later, and there is a reasonable sketch of the hardware set up already in the README.md file.] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok for now, But as we build up this doc, most of the information would be moved from README.md into the docs, and README just to point to them. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK. So all details about st-up, configuration, etc. will be removed from the overview. Makes sense. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. will it be done in this PR or you would like to do that in a separate follow up PR? |
||
|
||
The server software runs continuously on a dedicated computer that is connected to audio/video capturing device interjected between the stimulus presentation system (SPS) at the fMRI scanner suite. | ||
The software monitors the audio and video streams that are sent over the SPS so that whenever there is a video feed to the projector in the scanner, | ||
all content is recorded and time-stamped. | ||
andycon marked this conversation as resolved.
Show resolved
Hide resolved
|
||
Any change in the parameter of captured video (connect/disconnect, change of resolution) triggers creation of a new captured content file. | ||
These recordings are not yet considered “records” in that they are not matched to specific fMRI scans. | ||
The server simply monitors the SPS for content and records everything. | ||
These raw recordings will often contain long periods of screen capture that show the content of the display on experimenter’s stimulus presentation computer (often a lab laptop). | ||
andycon marked this conversation as resolved.
Show resolved
Hide resolved
|
||
**Warning: as a result, captured video could contain sensitive data if it was displayed.** | ||
Therefore, it is necessary to take some precautions to store these files securely to protect experimenters information and privacy in case some personal information is exposed, such as an email inbox. | ||
Consideration should be taken as to how long these raw recordings are kept, when they should be deleted, and where they will be stored. | ||
For example, operators will need to provide sufficient hard drive space for this data and implement some policies about how long to keep the original raw data, after “records” parsed and procured to the fMRI archive. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with the above note, I think not even worth mentioning this here, and just say that every neuroimaging file (be it fmri, anat, dwi, etc) would have a corresponding stimulus file.
Also -- ultimate goal is to incorporate ReproStim within ReproIn/heudiconv data conversion, so to have all these files placed into BIDS dataset. Worth adding a reference to bids-standard/bids-specification#751 as WiP to possibly enhance BIDS to support per-neuroimaging file stimuli.
And also, such system could also be employed for purely behavioral experiments, and those are supported by BIDS as well.