MPRAGE and T1 in fmriprep

I have a question about fmriprep T1 and bold preprocessing workflows. What if anat folder in BIDS consists of T1w and mprage_T1. Which of two fmriprep takes for work? And if I have 3 bold files in BIDS, how much preprocessed bold files will I have?

I just started playing around with running fmriprep on some test subjects yesterday so hopefully someone with more experience can confirm/correct my response, but this is my understanding:

I think fmriprep will take the T1 file that is named according to the BIDS specification (e.g., “sub-101_ses-txA_T1w.nii”). So I’m guessing that’s your T1w file?

Do you have multiple BOLD files from multiple task runs or sessions (visits)? If you mean you have three BOLD files as a result of multiple runs of the same task, not sure about that. I don’t know the BIDS specification for multiple runs.

If sessions, then assuming your raw data is organized by session, you will end up with preprocessed BOLD files for each session, as shown in the example below.

e.g., I have 2 sessions labeled according to whether they got treatment A vs. B, so fmriprep makes subdirectories for “ses-txA” and “ses-txB” in addition to the “anat” folder (containing derivatives of their T1 averaged from the 2 sessions) within the subject’s folder in /derivatives/fmriprep. You do not have to create these folders (at least based on my experience with fmriprep-docker) you just specify /derivatives as your output directory.

data/
└─ sub-101
       └── ses-txA
                 └── anat
                 └── func
       └── ses-txB
                 └── anat
                 └── func
       └── derivatives
                 └── fmriprep
                            └─ sub-101
                                   └── anat
                                   └── figures
                                   └── ses-txA
                                             └── anat
                                             └── func
                                   └── ses-txB
                                             └── anat
                                             └── func
└─ sourcedata
README
dataset_description.json
participants.tsv

Could you show a tree listing of a subject? That would make it easier to predict.

But, as a rule, T1w images will be merged to form a single template. And for each BOLD series, there will be a corrected BOLD series with a corresponding name (and additional tags indicating preprocessing has been done. and what space it’s in).

@effigies @01010011 Thanks for your reply. As an input BIDS:

BIDS
   └── anat
           └── sub-P001_3d-mprage_T1w.json
           └── sub-P001_3d-mprage_T1w.nii.gz
           └── sub-P001_T1w.json
           └── sub-P001_T1w.nii.gz
   └── func
           └── sub001_task-ser133-volumes_bold.json
           └── sub001_task-ser133-volumes_bold.nii.gz
           └── sub001_task-ser133-volumes_events.tsv
   sub-P001_scans.tsv

structure of DICOM:

DICOM
   └── P001
          └── 200001000
                   └── ser004_MR-cor_3D_T1_MPR
                   └── ser005_MR-133_VOLUMES
                   └── ser006_MR-3D_MP_RAGE

series 005 - its BOLD series. From my sight conversion works well. Maybe you see something wrong.

This does not appear to be a valid BIDS dataset. I’d recommend starting by running the BIDS validator.

Once you do have a valid BIDS dataset, fMRIPrep will most likely combine your MPRAGE and non-MPRAGE T1w volumes (aligning and taking the mean value at each voxel), unless one is substantially higher resolution than the other, in which case the higher resolution image will be preferred.

As you only have one BOLD series, I would expect one preprocessed BOLD series.

1 Like

@effigies orry, for mistake: here is BIDS validated
BIDS_geht_mprage/
├── CHANGES
├── dataset_description.json
├── participants.tsv
├── README
├── sub-P001
│ ├── anat
│ │ ├── sub-P001_3d-mp-rage_T1w.json
│ │ ├── sub-P001_3d-mp-rage_T1w.nii.gz
│ │ ├── sub-P001_T1w.json
│ │ └── sub-P001_T1w.nii.gz
│ ├── func
│ │ ├── sub-P001_task-ser133-volumes_bold.json
│ │ ├── sub-P001_task-ser133-volumes_bold.nii.gz
│ │ └── sub-P001_task-ser133-volumes_events.tsv
│ └── sub-P001_scans.tsv
└── task-ser133-volumes_bold.json
Suppose we have several BOLD series, which BOLD and T1 tookes in EPI to T1 registration node?

3d-mp-rage and task-ser133-volumes should raise issues on the validator. 3d is not a known key, and ser133-volumes is not a valid task label (dashes and underscores are separators).

At present, all T1w images of sufficient resolution are merged into a single template. There is discussion over whether this is the best strategy for multi-session datasets, but at least for now it’s how it is.

If you have several BOLD series, each is independently aligned to the common T1w template.

1 Like

@Relyativist which version of the validator did you use?

I used bids/validator:latest docker image. Thanks @effigies @ChrisGorgolewski, you were right. it raised an issues:

1: Files with such naming scheme are not part of BIDS specification. 
2: Empty cell in TSV file detected: The proper way of labeling missing values is "n/a".
3: Task Name contain an Illegal Character hyphen or underscore.

But could yu please help me to resolve the mprage modality how it should be implemented in heuristic.py:

if (sl == 176) and (nt == 1) and ('MPRAGE' in h.sequence_name):
        t1 = create_key('anatomy/T1_mprage'?

Have you had a look at the extension BEP1 for BIDS ? It is not canon yet but it might help you organize your data already.

8.10.4 Example 2: MP2RAGE

7t_trt/
sub-01/
ses-1/
anat/
sub-01_T1map.nii.gz
sub-01_T1map.json
sub-01_T1w.nii.gz
sub-01_T1w.json
sub-01_MPRAGE.json
sub-01_inv-1_part-mag_MPRAGE.nii.gz
sub-01_inv-1_part-phase_MPRAGE.nii.gz
sub-01_inv-1_MPRAGE.json
sub-01_inv-2_part-mag_MPRAGE.nii.gz
sub-01_inv-2_part-phase_MPRAGE.nii.gz
sub-01_inv-2_MPRAGE.json

I have started using it and it allows me to have a T1w that is compliant with the default BIDS. All the extrafiles will still make the validator complain but you can add those files to a .bidsignore (e.g with a in it _MPRAGE. ) to keep it quiet until a format for MPRAGE in BIDS is made final.

I think this does not apply. @Relyativist is using MPRAGE not MP2RAGE and should use _T1w suffixes.

1 Like