Slice Timing Processing Pipeline Order Q

[Marco Pipoly]

Hello experts,

I am writing to understand the rationale behind the GenericfMRIVolumeProcessingPipeline.sh LegacyStyleData mode options for slice timing correction. The language states that if "--doslicetime" is set to TRUE, slice timing correction will be performed BEFORE motion correction. 

Do you have recommendations for getting around the forced application of slice timing before motion correction in the pipeline?

Several studies suggest that slice timing should be performed after motion correction, as it can negatively affect motion estimates used later in GLM analyses. 

https://www.frontiersin.org/journals/neuroscience/articles/10.3389/fnins.2019.00821/full 

https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0182939

[Glasser, Matthew]

Ideally one would do some kind of 4D resampling accounting for both slice timing and motion effects in a single step.  I have yet to see an implementation of this that we could easily adopt in the HCP Pipelines.  It is actually not a trivial problem.

If you realign the images, you no longer will be able to interpolate temporally in a naïve fashion, because in the setting of head motion, you will be pulling information from the wrong voxels.

 

Slice timing is not very important for fast TR datasets in any case, so we don’t do it by default.

 

With regard to the second paper, we don’t need that in the HCP Pipelines.  We identify artifacts directly from the data with spatial and temporal ICA and are not dependent on motion measures to do denoising. 

Matt.

--
You received this message because you are subscribed to the Google Groups "HCP-Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hcp-users+...@humanconnectome.org.
To view this discussion visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/c9600ace-04da-4b8b-b9db-32a03b5df3c3n%40humanconnectome.org.

 

---

The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

[Tim Coalson]

We don't recommend using slice timing on HCP-style fast-TR data, that is why slice timing is a legacy-style-data option.  We also don't recommend acquiring fMRI data slow enough that slice timing becomes important.

Motion correction resampling mixes data across different slice timings, and most acquisitions are at least somewhat interleaved, causing slice timings to be substantially different in spatially nearby voxels.  Therefore, within periods of no head movement, it is more theoretically correct for the data to be slice-timing-corrected before the motion resampling damages the slice timing information (even when there is no relative motion between frames, the head position is still usually not the same as the target image or output space, so voxel mixing still happens just by reorienting the data onto a new grid).  Neither method (slice timing first or motion correction first) is theoretically correct for periods containing movement.

The combined 4D resampling problem with slice timing and motion is nonuniformly sampled in all axes, and can contain gaps of unsampled space-time (movement during a single frame can overlap parts of the later slices with the same tissue that was already sampled in earlier slices, therefore completely missing exciting some of the intended tissue in that frame (even before considering the corresponding spin history problems)).  The usual cubic/spline methods aren't appropriate when the data sampling isn't uniform in each axis, which is why the problem is hard.

Estimating motion doesn't technically need to have any type of resampling done on the input, as long as it is aware of slice timing.  It can instead resample from the stationary target image given the current guess of the motion parameters at the slice time of each voxel.  Thus, in theory, the correctness of the motion estimate can be made independent from any choices of how (and if) the motion and slice timing information is applied to the data.  But, since we don't use slice timing correction on the fast-TR data we focus on, this is largely moot for us.

Tim

To view this discussion visit https://groups.google.com/a/humanconnectome.org/d/msgid/hcp-users/832510F6-FED6-4E9B-9B35-94355FF69EBA%40wustl.edu.