3dDespike when using 3dTproject

fmri

#1

Hi all. So I’ve been reading through the following literature:

Chen, Jingyuan E., Hesamoddin Jahanian, and Gary H. Glover. “Nuisance Regression of High-Frequency Functional Magnetic Resonance Imaging Data: Denoising Can Be Noisy.” Brain connectivity 7.1 (2017): 13-24.

Lindquist, M. A., Geuter, S., Wager, T. D., & Caffo, B. S. (2018). Modular preprocessing pipelines can reintroduce artifacts into fMRI data. Human brain mapping .

And of course 3dTproject a-la @BobCox , which is meant to address this very issue.

I’m attempting something similar to Chen et al, but I’m at something of a loss as to how to properly implement this.

I’ve seen previous work despike data (via 3dDespike) prior to running 3dTproject with nuisance regressors, but I can’t help but get the impression that running something like 3dToutcount or 3dTqual and writing it to a file for 3dTproject for simultaneous nuisance regression and/or interpolation via -NTRP is the “more correct” way to “despike” the data.

Anyone have any suggestions or opinions about this particular topic?


#2

3dDespike is a hack, originally designed to deal with a problematic scanner. The principal difference between using 3dDespike and censoring is that censoring is all-or-nothing for a time point, whereas 3dDespike just takes the original (bad) data in one voxel and replaces it with some fiction.

A “proper” way to do deal with voxel-specific spikes (and thus not worth censoring the entire volume away) would be to use a different regression matrix for each voxel - or at least, for each voxel requiring despiking. That way, the bad data in each voxel can be censored/regressed out separately without affecting the (putatively) good data in other voxels at that time point.

This solution has the drawback that it is computationally sluggish, requiring setting up and tearing down a whole raft of matrices for the time series analysis. I have thought of doing it in 3dREMLfit, a la the ‘-dsort’ option - with some code changes necessary for various scenarios. But I’ve not got around to implementing it.

Would doing such separate voxelwise censoring make a significant difference over despiking? I have my doubts, a lot of them, which is why I have not spent the time to implement my sketched-out ideas in the previous paragraph. To do it super-properly, the voxels to be censored out should also not be used in the volume registration, which would also require modifying 3dvolreg to allow such censoring. All of this is possible, but I’m not going to do it for a whirl just to see if it matters in any significant way.

What I’ve written above is implicitly for task FMRI. For resting FMRI, the changes would be similar but “properly” should also include censoring voxelwise when the inter-voxel correlations are computed - that is, if time point 37 is “bad” in voxel A and time point 73 is “bad” in voxel B, then omit both of them when doing the correlation between A and B. For Pearson correlation, that’s easy - set censored voxel time points to 0 in the residuals - which is what is usually done for censored time points now anyhow (just on the “all or nothing” basis). So the “despiking aware” version of 3dTproject would have to do that. Since 3dTproject also allows the ‘-dsort’ option, that could be done now with a little shell programming wizardry. (I think.)