Preprocessing for atlas based connectivity matrices

21

Sorry I meant aCompCor00. The number of components seems reasonable.

1 Like
22

I could not used the suggestion you gave as

raised the error:

ERROR: no registration file specified

However, what about replacing the two commands you mentioned with the command below? It seems to work in the single case I tested:

mri_convert -rl /preproc/freesurfer/sub-<subject_label>/mri/rawavg.mgz -rt nearest /preproc/freesurfer/sub-<subject_label>/mri/aparc+aseg.mgz aparc+aseg.nii.gz

This command is discussed here for example.

23

Sorry, I forgot the --regheader flag. Iā€™ve updated the command in my original reply.

The command you gave may work just as well. Good find!

24

Thanks @effigies. Actually my command creates issues as for some reason the headers of the atlas and T1 volumes are not exactly the same (sform and qform are different around the 10^-6 digits), so yours works better. I still got the same error though, and had to add --reg dummy.dat for your command to work, was that the right thing to do?

An important question: I thought fmriprep/sub-<subject_label>/func/sub-<subject_label>_task-rest_bold_space-T1w_preproc.nii.gz was in the same space as the T1, but they have different voxel size (~ 3mm isotropic for the first, and ~ 1mm for the latter). Then:

  • Does the fmriprep pipeline align the bold data with the T1 data (...T1w_preproc.nii.gz being the result) but without resampling to T1 space?
  • To compute the connectivity matrices, I would need the bold data exactly in the same space as the aparc+aseg in native T1 space (that includes same voxel size). Would you have any suggestion on how to do that? (Having aparc+aseg with the same low resolution as the bold data would be fine and maybe preferable to avoid further processing of the time series)
25

I think you actually need to add --regheader to mri_vol2vol as well. Sorry for not catching that, earlier. If that works, let me know, and Iā€™ll update the command above.

When we say the BOLD and T1w images are in the same space, what we mean is that they have been coregistered such that the same RAS coordinates in either get you the same brain structure. It is very rare that someone would want to upsample their BOLD data into T1w resolution, I think.

Exactly.

Ah, yes. Youā€™ll still need to down-sample. You can probably do this directly by switching from using T1w_preproc.nii.gz to one of your BOLD outputs, in both the tkregister2 and mri_vol2vol commands, but you should really verify thisā€¦

26

Thanks for all the answers @effigies. In the case of the atlas I am using I prefer indeed to use native BOLD resolution, and I resampled the atlas to that resolution.

I got the same error in the first command (tkregister2) even when using --regheader. I could get rid of the error by adding --reg dummy.dat to save the transform (i.e. adding --regheader --reg dummy.dat to the original command ). No change was needed to mri_vol2vol (I did not need to add --regheader).

27

Hello @oesteban and @ChrisGorgolewski , I was not sure where else to ask about this, but do you have any updates on the possiblity of using despiking with fmriprep? I read the linked github post, and the Power (2017) paper, and from what I understand, the main concern is ā€œmaskingā€ underlying motion artifacts with lower motion values. However its not clear whether this applies to both of the approaches 3dDespike uses (residual SD attenuation, and a pre and post timepoint average interpolation), or whether using a lower FD threshold would largely overcome the problem.

Also, I have come across at least three papers here, and in this recent review which suggest carrying out (presumably attenuation-based) despiking first, showing improvements (not necessarily related to order). So my question was, have your views changed at all on using 3dDespike BEFORE running fmriprep (since running at the end may be problematic in relation to high pass filters)? I have run a sample dataset with and without despiking, and as expected, FD values and DIVARS are attenuated, with fewer motion censoring resgressors. However, Iā€™m still unsure whether we will use those due to concerns about reducing the experimental space/unbalanced conditions, so Iā€™m trying to weigh pros and cons of this approach.

Also, since we used the despike option in MRIQC, it seems to make sense to use the same thresholds and values in fmriprep. Any updated thoughts on this would be greatly appreciated!!

28

Short answer is fMRIPrep will not produce ā€œdespikedā€ outputs, as it is a destructive operation of the original data.

That doesnā€™t mean we cannot integrate 3dDespike in the following ways:

  • Generate a new confound timeseries indicating whether 3dDespike identified a frame as outlier. I would need to learn more about 3dDespike, but this new regressor could be more sophisticated than just a flag -e.g., if 3dDespike only overwrites outlying voxels, provide the rate of outlying voxels w.r.t. the brain mask or similar- (@jdkent, any insights?).
  • Execute head-motion estimation with 3dDespiked signals, which in principle should lead to lower head-motion estimates?

As we promote in our paper (https://doi.org/10.1038/s41596-020-0327-3), MRIQC and fMRIPrep are (and should be kept) different tools for different purposes. So, although it seems logical to use same thresholds and values, this is not a best practice. For example, MRIQC wants to evidence quality problems - so the design decisions will typically try to exacerbate such problems so they become as obvious as possible to the researcherā€™s eyes. Conversely, fMRIPrep wants to minimally massage data so that they can statistically analyzed. As objectives are different, implementations are different.