fMRIVolume Related Pull Request — Slice timing correction #139
Conversation
sivcek
changed the title
…the filename of the reoriented image to *_orig_reorient.
There was a problem hiding this comment.
Please put a warning when using slice timing correction to this effect (should also appear next to the options in the Batch script):
WARNING: This legacy option of slice timing correction is performed before motion correction (as is typically done in legacy-style brain imaging) and thus assumes that the brain is motionless. Errors in temporal interpolation will occur in the presence of head motion and may also disrupt data quality measures as shown in Power et al 2017 PLOS One "Temporal interpolation alters motion in fMRI
scans: Magnitudes and consequences for artifact detection." Slice timing correction and motion correction would ideally be performed simultaneously; however, this is not currently supported by any major software tool. HCP-Style fast TR fMRI data acquisitions (TR<=1s) avoid the need for slice timing correction, provide major advantages for fMRI denoising, and are recommended.
|
Added the warning. |
| # use FSL's fslreorient2std for reorienting the image to match the approximate orientation of the standard template images MNI152 | ||
| # this makes the single-band processing more robust to registration problems |
There was a problem hiding this comment.
This won't work. You can't reorient the slice acquisition axis without also accounting for that as part of STC. I see that slicetimer has an option (-d, --direction) to set the direction of slice acquisition, but if you want to use that, you will need to add code that ascertains what is the axes of the slice acquisition after fslreorient2std has been applied. (If you have previously processed any non-axially acquired data using this approach, then the STC applied to that data is completely wrong).
There was a problem hiding this comment.
Is it ok if we do reorient after slice timing correction?
There was a problem hiding this comment.
As regards STC itself, yes, but not in the broader context of fMRIVolume overall, where:
- changing the orientation changes the UnwarpDir.
- I'm not immediately sure of the implications on the SEFMs either.
This is a complicated issue if you want the reorientation to be part of the pipeline code itself.
There was a problem hiding this comment.
Hmm. What if we currently limit it to only those data that do not have any DC method available?
There was a problem hiding this comment.
As this is quite common intersection in legacy datasets with SB bolds with no DC, so it would cover most cases where fslreorient might help.
There was a problem hiding this comment.
Chad and Takuya said they hand-reoriented (sometimes needing to relabel the axes) the NHP inputs before using them, so the NHP pipelines never need to deal with non-axial data.
There was a problem hiding this comment.
It is probably okay, though we should think about how this would interact with fieldmap-less distortion correction if it is implemented.
There was a problem hiding this comment.
Can I assume the consensus is we limit it to the data w/o available DC correction method?
There was a problem hiding this comment.
For now, I think it is either that, or you eliminate the fslreorient2std part entirely. Regardless, people need to be aware of the reorienting, so I'd include a prominent comment at that section of the code, and also issue a log_Warn on the issue.
There was a problem hiding this comment.
Did that. @mharms can you please check the note and warning and suggest changes if necessary.
…ilable. Added note and warning.
|
Joined with other fMRIVolume related PRs into PR #156 |
Addition of slice timing correction functionality.