In the past, I have created labels for each type of scan within a study (so that I could script), but not specifically BIDS labels. As I move our procedure to BIDS, I am realizing that I’m not sure how to label each scan file we have. In “non-BIDS” structure, we labeled the high resolution structural “3d” and then after running BET in FSL would add a file of “3d_brain.” As I look at BIDS, this would now be T1w (with all the other BIDS pieces), but what about the BET output?
Similar to above, when we get the functional scans from the scanner, they need to be reoriented for registration purposes. So in the past, we have created a label for the original nifti file related to the functional task (i.e., “rest”) and then once it is reoriented, that gets a new name (i.e., “flip_rest”). For BIDS format, would the final file that is labeled be that final reoriented version? So we could have an intermediate file from the scanner called something (“original_rest” or something) and then once it is is reoriented to standard, then it gets called the final task-based name in the BIDS structure?
Finally - I think I know the answer to this, but just to double check - BIDS doesn’t care if there are extra files, just as long as the required files are present - so if we had those original versions that were not oriented to standard, it won’t screw up the BIDS structure.
A BIDS dataset should generally have the absolute minimum of preprocessing done, so much of what you’re discussing here would fall into the category of “derivatives”, which are addressed section 3.4 of the BIDS standard and in greater detail in BIDS Extension Proposal 003. Derivatives generally have a parallel structure to the primary data set, and begin with most (if not all) of the name of the file from which they’re derived.
- BET skull-stripped files could be stored in
<bids-root>/ derivatives/ BET/ sub-<participant_label>/ anat/ sub-<participant_label>_T1w_brainmask.nii.gz
- This one’s a little ambiguous, since you could either consider the “rest” file to be “source data”, and “flip_rest” one the BIDS-official copy, or you could consider the “rest” to be the original and “flip_rest” a derivative. If it’s just header changes (e.g. adjusting the affine to turn an LPI image to RAS), I think you could go either way (as long as you make sure metadata like phase-encoding direction and slice axis remain correct), but if you’re resampling at all (e.g. de-obliquing), I would consider it a derivative. So there are two options:
<bids-root>/ sourcedata/ sub-<participant_label>/ func/ # Original sub-<participant_label>_task-rest_bold.nii.gz sub-<participant_label>/ func/ # Reoriented sub-<participant_label>_task-rest_bold.nii.gz
<bids-root>/ derivatives/ reorient/ sub-<participant_label>/ func/ # Reoriented sub-<participant_label>_task-rest_bold_space-<space>_preproc.nii.gz sub-<participant_label>/ func/ # Original sub-<participant_label>_task-rest_bold.nii.gz
- I believe the BIDS validator now considers unexpected files an error, as the alternative was that misnamed files were being silently ignored, You can add a
.bidsignorefile with patterns of files that shouldn’t be checked.
In BIDS raw data is separated from any data derivatives. A single dataset can lead to many different derivatives (skullstripping can be done in multiple ways and it’s only one data transformation) so its beneficial to have just the raw data in one place.
Currently BIDS prescribes storing derivatives in the
/derivatives/ folder (where
/ refers to the root of the dataset so the level where
sub-xx folders are). As for how data should be organized inside that folder - we are currently working on naming conventions for derivatives, but those are not yet finalized. If you would like to adopt them anyway please have a look at https://docs.google.com/document/d/1Wwc4A6Mow4ZPPszDIWfCUCRNstn7d_zzaWPcfcHmgI4/edit
You should store the raw data (with its original “native” orientation) under
/sub-xx/func/sub-xx_task-rest_bold.nii.gz. Reoriented or normalized volumes are considered derivatives (unless the original orientation is incorrect - for example due to a know left/right flip produced by a faulty multiband reconstruction procedure) and you should store them in
That is correct, however the bids-validator (which I strongly recommend you to use) will raise an error for “unknown” files (unless they are stored in the
/derivatives folder which the validator ignores). This measure was put in place to highlight mistakes that are merely typos in filenames intended to be valid BIDS names. To make the validator happy with non-standard extra files you will need to provide a
/.bidsignore file with patterns matching extra files. See https://github.com/INCF/bids-validator#bidsignore for details.
I hope this helps!