Slice Timing Correction
Ruben Sanchez
Glasser, Matthew
We don’t recommend slice timing correction because it isn’t really needed with fast TR data and it interacts with motion correction. If you are wanting to use a 4D resampling tool, that would be an interesting improvement to the HCP Pipelines.
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/ea0e3b1c-da8a-4d9c-910a-7f9e6bfcfc31n%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.
Ruben Sanchez
Glasser, Matthew
Hi Ruben,
My suggestion would be to just write a module for it and plug it into the HCP Pipelines. We would be happy to work with you on this, as we were also interested to try that approach, but haven’t had a chance.
Ruben Sanchez
Glasser, Matthew
Thinking about this a bit more your original idea of running the 4D processing first before the HCP Pipelines might be a better one for testing (and just write a dummy method for motion correction that outputs identity matrices to avoid any additional motion correction). You won’t be able to do one-step resampling, but the python code below would need to be modified in any case to take distortion correction warpfields, fMRI to T1w affine, and MNI warpfields to do something like that. To make a dummy motion correction method you would just implement another method case in the case statement of this file: https://github.com/Washington-University/HCPpipelines/blob/master/fMRIVolume/scripts/MotionCorrection.sh lines 99-114 that produces the same types of outputs as the existing methods there (could be a simple as copying the input name to the output name and naming a bunch of 4x4 identity matrices appropriately, which you could determine by running another of the existing methods to figure out how to name things).
If we wanted to implement this in the HCP Pipelines, it might make more sense for us to just do it as a part of the one-step resampling Connectome Workbench command (wb_command -volume-resample or a new command). Tim could comment on if he thinks that would be hard to implement appropriate temporal interpolation in there. It looks like the temporal interpolation in the python code is also splines, so these would be 4D splines instead of 3D splines. Also, I haven’t read the paper or code in detail, but it isn’t immediately clear to me that motion correction estimation necessarily need be tied to 4D resampling (such that one could continue to use our existing motion correction algorithms to compute the realignment matrices and then also incorporate slice information to do a 4D resampling in the one-step resampling). Also including Jure given that you are an existing QuNex user.
Overall, I think enabling 4D resampling would be an enhancement to the HCP pipelines (that would have a bigger impact on legacy data than HCP-Style data) and if the task is not huge, would be worth doing. At least it would allow us to provide a form of slice timing correction to users who care about it that we could actually recommend. In general, we are always open to methodological suggestions that improve upon what the HCP Pipelines already do.