Input data priority list

[tsalo]

There are a few different situations that we probably want to support:

1. Raw BIDS dataset + full fMRIPrep derivatives
   • At minimum, we'll have access to the transforms necessary to warp the data to boldref space, anatomical space, or MNI152NLin6Asym space.
   • We may also have BOLD data in a variety of output spaces and resolutions, depending on how users ran fMRIPrep.
2. Raw BIDS dataset + minimal fMRIPrep derivatives.
   • At minimum, we'll have access to the transforms necessary to warp the data to boldref space, anatomical space, or MNI152NLin6Asym space.
3. Full fMRIPrep derivatives only
   • We'll have BOLD data in at least one output space, but that will be limited based on how users ran fMRIPrep.
   • We can require specific output spaces and resolutions if necessary. In fMRIPost-AROMA we require MNI152NLin6Asym-space outputs in this scenario.

@bbfrederick are there specific spaces that work best with rapidtide? With scenarios 1 and 2, we can work with both native-space BOLD data and MNI152NLin6Asym data (and possibly others), as necessary, so if working with multiple spaces is useful then that's fine. With scenario 3, though, we're limited to specific spaces.

[bbfrederick]

I'm pretty sure things will work fine in all three of those cases.

rapidtide works best on preprocessed data, so there is no need for the Raw BIDS data.

rapidtide does not have a preferred coordinate system to work in; it's generally fastest in native BOLD space, since there are fewer voxels to process, but you can run it in any derived space. I generally do it in MNI152NLin6Asym, because then all my derived maps in all subjects are aligned, and that's the coordinate system I tend to work in, but you could also run in native space and transform the outputs.

Regressor finding and extraction works best in volumetric space, so if you're outputting data in any of the surface formats, you will want to run rapidtide on the volumetric data first, and then either transform your denoised data or run rapidtide on the surface data, skipping the regressor finding and starting from a regressor you extracted from the volumetric data.

As I mentioned in the other post, while a gray matter mask is not required, if you are interested in more than simply denoising, it does tend to make it somewhat easier to consider the various maps from different subjects together (a lot of my preferences for options come from trying to optimize delay maps to talk about hemodynamics, but for denoising prior to further analyses, which is, I assume, will be the primary use case for fmripost-rapidtide, it's not as crucial). Rapidtide can use either an _dseg.nii.gz file or a full aparc+aseg file to get the gray matter mask, although fmriprep generally does not produce the latter in MNI152NLin6Asym space, so you'd have to do the transform yourself. I think even with minimal fmriprep derivatives you get the _dseg.nii.gz file though, right?

There are some newer capabilities I'm looking at adding (arterial territory fingerprinting for one) that are currently only possible if you have data in MNI152NLin6Asym space, but for the first pass, that's probably not the top priority.

[tsalo]

I think even with minimal fmriprep derivatives you get the _dseg.nii.gz file though, right?

It looks like you do get the dseg.nii.gz with resampling mode (not sure about minimal mode), though it's in native T1w space and will need to be warped to MNI152NLin6Asym.

If working in MNI152NLin6Asym is easiest, can fMRIPost-rapidtide calculate the moving regressor from MNI152NLin6Asym-space data and then determine the lags independently for each output space (e.g., CIFTIs in fsLR)?

[bbfrederick]

If working in MNI152NLin6Asym is easiest, can fMRIPost-rapidtide calculate the moving regressor from MNI152NLin6Asym-space data and then determine the lags independently for each output space (e.g., CIFTIs in fsLR)?

Yes, that's probably the best approach, and rapidtide is already set up to do that pretty easily.

[bbfrederick]

So as I see it now, one straightforward way to do this is to require that one of the output spaces for the fmriprep run be MNI152NLin6Asym_res-2 (this was the case when AROMA was part of fmriprep - I don't know how this is handled for fmripost-AROMA, but we should probably do the same thing here).

So the steps are:

1. Collect (or construct as necessary) the files needed to run rapidtide in MNI152NLin6Asym space.
2. Run a full rapidtide analysis (iterative regressor and voxelwise delay fitting, followed by noise removal).
3. Extract the final sLFO regressor from the output files of step 2.
4. For every other target space that has fMRI data, run a single step non iterative rapidtide denoising step (given the target regressor, calculate voxelwise delay, and regress the delayed regressor out of each voxel of each dataset. Rapidtide can perform this on any 4D NIFTI or CIFTI dtseries file natively.

For step 1, for each subject we'd need:

From derivatives/fmriprep/sub-XXX/anat:
sub-XXX_space-MNI152NLin6Asym_res-2_label-GM_probseg.nii.gz (this seems to be present in any case, in which case we don't have to transform the dseg file.)

And from each derivatives/fmriprep/sub-XXX/ses-YYY/func directory:

sub-XXX_ses-YYY_task-rest_run-ZZZ_space-MNI152NLin6Asym_res-2_desc-brain_mask.nii.gz
sub-XXX_ses-YYY_task-rest_run-ZZZ_space-MNI152NLin6Asym_res-2_desc-preproc_bold.nii.gz
sub-XXX_ses-YYY_task-rest_run-ZZZ_desc-confounds_timeseries.tsv
sub-XXX_ses-YYY_task-rest_run-ZZZ_desc-confounds_timeseries.json

For step 4, we'd need the regressor file from step 3, plus whatever functional file in whatever output space we wanted, e.g.:

sub-XXX_ses-YYY_task-rest_run-ZZZ_desc-preproc_bold.nii.gz
sub-XXX_ses-YYY_task-rest_run-ZZZ_space-T1w_desc-preproc_bold.nii.gz

I've never looked into reading or writing .gii files, and I'm not sure exactly how they are created. I'm open to adding the capability to rapidtide if nibabel supports them and its not too hard. Should we denoise them directly, or should we construct denoised files out denoised volumetric files? The second might be theoretically better, since you wouldn't be trying to remove noise from a spatial location constructed out of multiple underlying voxels potentially with different delays, but I'm guessing the constituent voxels are so close together it probably doesn't matter.

[tsalo]

So as I see it now, one straightforward way to do this is to require that one of the output spaces for the fmriprep run be MNI152NLin6Asym_res-2 (this was the case when AROMA was part of fmriprep - I don't know how this is handled for fmripost-AROMA, but we should probably do the same thing here).

In the long run, fMRIPost workflows should be able to take in native-space BOLD data and apply the transforms from fMRIPrep to get them into whatever space users want (or the fMRIPost workflows require), but for right now I agree that requiring data in a specific space+resolution is a solid strategy.

I've never looked into reading or writing .gii files, and I'm not sure exactly how they are created. I'm open to adding the capability to rapidtide if nibabel supports them and its not too hard. Should we denoise them directly, or should we construct denoised files out denoised volumetric files?

I think denoising them directly makes the most sense for now. They're definitely easy to load into an array and write back out.