Add 3dDespike step

[chrisgorgo]

https://afni.nimh.nih.gov/pub/dist/doc/program_help/3dDespike.html

• motion estimation should be done on data that was not despiked
• use the -NEW method
• try to use multiple threads
• pass in the ignore option from non-steady state detector

[oesteban]

Interesting and related resources are this blog post that Chris shared some days ago, and J. Power's recent paper: http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0182939

[jdkent]

piggybacking off @oesteban's resources, if you haven't already seen it, the Satterthwaite group released a paper in July about bench-marking different confound combinations for functional connectivity analyses, including despiking and censoring: http://www.sciencedirect.com/science/article/pii/S1053811917302288?via%3Dihub

[oesteban]

Interesting! I'll have a look!

…

On Sep 19, 2017 22:44, "James Kent" ***@***.***> wrote: piggybacking off @oesteban <https://github.com/oesteban> resources, if you haven't already seen it, the Satterthwaite group released a paper in July about bench-marking different confound combinations for functional connectivity analyses, including despiking and censoring: http://www.sciencedirect.com/science/article/pii/ S1053811917302288?via%3Dihub — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#699 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAkhxo7azzzNk3TLXBO99ebgg6Sk-kU2ks5skKYggaJpZM4PVL1P> .

[oesteban]

After discussion in our latest IT meeting it seems that the only feasible change for fMRIPrep is to consider whether despiking helps or not with head-motion realignment.

We discussed that on one hand, you would generally prefer overestimated FD values rather than underestimated if, after all, these spikes happen mostly because of motion. On the other hand, it seems that despiking might help in realigment of timepoints severely affected by spikes (and typically motion).

A solution could be estimating the head motion parameters that are reported in the confounds file without despiking but calculating the affine matrices that will be used in realignment after despiking.

One way or another, this seemed to have very low priority at the moment. I'm changing the impact to low, as we don't see a clear need for this particular feature.