I have processed multi-echo resting-state fMRI images (three echoes per scan) using fMRIPrep (V.23.2.0), including the the --dummy-scans flag. I plan to remove the first four volumes from each echo, as these are also flagged as non-steady-state in the fMRIPrep report. This non-steady-state volume removal will be performed before further processing of the images with tedana (V 24.0.1)(former discussion on Neurostars). The processed and combined echo images are aimed to be co-registered to the MNI space and resample it to 2mm isotropic resolution.
To ensure my analysis pipeline is complete and logically structured, I would like to verify the following steps:
Remove the first four volumes from each echo image output by fMRIPrep using fslroi. volume_trim.txt (163 Bytes)
Input the trimmed echo images into tedana for further processing. tedana.txt (3.4 KB)
Apply the transformations provided by fMRIPrep to co-register the images to MNI space (Native → T1 → MNI). The transformations are the ones estimated from the non-trimmed images. registration.txt (1.4 KB)
Resample the image from 3mm to 2mm isotropic. resample.txt (218 Bytes)
Additionally, in my fMRIPrep script, I specified the output spaces as MNI152NLin2009cAsym:res-2 MNI152NLin2009cAsym anat. However, the anat directory in the fMRIPrep output contains only the transformation file: “sub-MTL0002_ses-FU84_acq-MPRAGE_from-T1w_to-MNI152NLin2009cAsym_mode-image_xfm.h5”,
and not a separate transformation for MNI152NLin2009cAsym:res-2.
Is this expected behavior? Does fMRIPrep generate only a single transformation for MNI152NLin2009cAsym, and other resolutions are supposed to be derived from resampling afterwards?
I would greatly appreciate your guidance on whether my approach is valid and appropriate.
I wouldn’t do these two steps. Instead, it is probably better to (1) remove the dummy volumes from the echo-wise files, (2) run tedana on those trimmed files, (3) remove the dummy volumes from the MNI-space optimally combined file from fMRIPrep, and (4) use the tedana ICA components to denoise the trimmed MNI-space file. That way, you don’t have to worry about doing any resampling or warping.
The transform doesn’t specify the resolution. You would apply the transform and use a reference image in the target resolution to get your data in the desired space and resolution.
Many thanks fro your reply, I’m not sure if I completely follow this appraoch would you please elaborate more on that:
The echo-wise images in step 1 are the fMRIPrep output files (sub-MTL0002_ses-FU84_task-rest_run-01_echo-01_desc-preproc_bold.nii.gz)?
In step 3, removing the dummy volumes from the MNI-space optimally combined file from fMRIPrep (sub-MTL0002_ses-FU84_task-rest_run-01_space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz)?
I am unaware of how to apply the step 4 (using tedana components to denosie the trimmed MNI files).
That would be native resolution, so I think you’d probably want sub-MTL0002_ses-FU84_task-rest_run-01_space-MNI152NLin2009cAsym_res-2_desc-preproc_bold.nii.gz instead.
Brilliant approach for skipping the transformations, thank you for suggesting that.
In applying tedana denoising on the MNI-space (2mm) trimmed optially combined fMRIPrep output, I have two quick follow-up questions:
With my understanding from the literature, ME-ICA denosing takes care of the motion related noise and removes that in data.
Accordingly, I am inclined to skip motion regressors and only keep rejected_components as my only confounds input to masker.fit_transform, is it something you would suggest as I noticed motion regressors were included in the sample tedana denoising code?
Within the masker code, there is standardize_confounds=True option, would it still be required if I am only considering the rejected components in masker.fit_transform?
You may find my adapted code to tedana ME-ICA denoising of optimally combined fMRIPrep output here: denoise_tedana.txt (2.5 KB)
Yes, ME-ICA should flag motion-related components as long as they’re not BOLD-based. I’d recommend passing in the motion parameters as external regressors with a decision tree that specifically accounts for them though. There’s more information on that here.
The motion parameters are just in there as an example. It’s not a strong recommendation- it’s just that we want to show how you would use non-ICA confounds in that step.
I’d recommend using that parameter regardless. I think there’s information about it in the Nilearn documentation, but the gist should be that it may help and it will never hurt.