Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

slice timing advice incorrect in outputs.rst #2978

Closed
thoernst opened this issue Mar 31, 2023 · 1 comment · Fixed by #3148
Closed

slice timing advice incorrect in outputs.rst #2978

thoernst opened this issue Mar 31, 2023 · 1 comment · Fixed by #3148
Milestone

Comments

@thoernst
Copy link

Hi guys,

in the output.rst advice is given on the correct interpretation of the slice timing. However, the advised correction is exactly the wrong way round. This was already pointed out by a comment of the linked reference at the end, and later corrected in the article.

If the reference time for a slice does increase, the respective onset should decrease by the same amount to keep temporal spacing the same.

Suggestion: use 2,4,6 as example onsets instead of 0,2,4

Also: The referenced article points out that this is not an issue for SPM and FSL use. I suggest that should be included.

Section would then read:

!danger!

Slice timing correction in fMRIPrep is referenced to the middle slice by default, which leads to a time shift in the volume onsets by 0.5 TR (repetition time). That is the correct way for processing with SPM and FSL, but not AFNI or nilearn. For example, assuming a TR of 2s, original onsets of 2, 4, and 6s would be shifted to 1, 3, and 5s, respectively. In case you did execute slice timing correction, you must check that subsequent analyses (e.g., general linear modeling) consider the right onset shifts. For example, when specifying a first-level model, you should set parameters in your software package or first-level model function accordingly (e.g., select the middle slice as reference). Alternatively, you could manually adjust the volume onsets (e.g. as mentioned in the example above from [2, 4, 6] to [1, 3, 5]) or the event onsets accordingly.

Further information on this issue is found at this blog post (with thanks to Russell Poldrack and Jeanette Mumford).

@effigies effigies added this to the 23.2.0 milestone Aug 24, 2023
@effigies
Copy link
Member

I believe the current text is correct. The event onsets need to be shifted back, or the volume onsets forward.

What about the following change:

--- a/docs/outputs.rst
+++ b/docs/outputs.rst
@@ -375,6 +375,8 @@ to perform more advanced denoising or alternative combination strategies.
    slice as reference).
    Alternatively, you could manually adjust the volume onsets (e.g. as mentioned in
    the example above from [0, 2, 4] to [1, 3, 5]) or the event onsets accordingly.
+   In contrast to volume onsets, event onsets need to be shifted *backward* by half a TR,
+   for example, from [5, 10, 15] to [4, 9, 14].
 
    Further information on this issue is found at
    `this blog post (with thanks to Russell Poldrack and Jeanette Mumford)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants