SAMRI
SAMRI copied to clipboard
IBT-FMI
Slice Timing for `SAMRI diagnose`
Our diagnosis tool for stimulus evoked activity and measurement quality/stability uses FSL's melodic. Though the MELODIC guide recommends the input be preprocessed the pipeline still fails as soon as the most basic preprocessing step (spatiotemporal realignment) is NOT skipped.
We should:
- Find out what exactly causes the failing behavior (it may be melodic-unrelated - e.g. the spatiotemporal realignment tool may be awry, or the nipype logic may be messy - but I kind-of remember having determined that it is melodic-related).
- Fix it - if it is melodic-related we should contact FSL.
addressed this issue on neurostars:
https://neurostars.org/t/nipy-spacetimerealigner-problem/337/8
@damaggu FSL has a slice timing correction function, which has a nipype interface already. Maybe it's worth a try, though I still believe the best solution is to sort the SpaceTimeRealigner out with Alexis Roche.
so here are the results so far
timecourse of IC 9 without anything
5.64 % of explained variance; 0.73 % of total variance
timecourse of IC 9 with nipy spacetimerealigner
timecourse of IC 9 with just fsl. SliceTimer
5.56 % of explained variance; 0.80 % of total variance
Since the % of explained variance for the IC increases after SliceTimer, I would suggest for now to take that as the default, since I also contacted Alexis Roche and he wasn't sure about the origin of this. Should I change to just SliceTimer as default in preprocessing as well as diagnose?
Sounds like a plan! I'd say we leave the bug open until we find a viable non-SPM solution to both spatial and temporal alignment.
@damaggu I might have figured out what's up. How can the slice timing correction be performed without passing the times of the slices to the function (we currently don't extract those from the ParaVision metadata)?
It can't. The algorithm is forced to assume that the slices are spaced evenly covering the entire TR, which in some scans may not be the case (and may be argued to be suboptimal). I'll have to find out whether this is the case in these scans of mine.