This is a useful email from RikHenson on the SPM mailing list
See SliceTiming for our main page on slice timing issues.
Subject:Re: slice timing questions
From:Rik Henson (rhenson@fil.ion.ucl.ac.uk)
Date:27 Apr 2000 - 22:03 BST
Barry
> I have a couple of questions regarding the slice timing function in SPM99. The
> first is a matter of usage, the second is a more general theoretical question
> that has been discussed to some extent already.
>
> 1) I collect 24 slices collected from superior to inferior, ordered 1 3 5 7
> 9...24. Thus, I enter a user specified order of 1 3 5 7 9...and a reference
> slice of 24 (since my images are in ANALYZE format and I collected from S-I). Is
> this correct or should I also be ordering my slices in terms of space (i.e.,
> slice order of 24 22 20...)? And does this depend on whether I reorient first
> (which leads into #2)?
You should enter a vector:
- s1 s2 s3 s4.... sN
where the variables s1..sN refer to the slice number, and the left to right order of elements in this vector represent the temporal order of slice acquisition.
The slice number refers to the position within the image file at which that slice is stored - ie depends on the order of slices within the image file (1=first, N=last, in file). You can determine the slice position within the file by switching to "voxel space" when displaying that image in SPM. The bottom slice in the Display windows is the first slice in the image file.
If the slice timing interpolation were perfect, the reference slice wouldn't matter. Since it is not perfect (worse for longer TRs; see below), we usually enter the middle slice in time as the reference slice (ie s(N/2)), on the basis that interpolated error (aliasing) is maximal for shifts of TR/2, and because we use a sequential acquisition sequence (see below), in which the middle slice in time is also the middle slice in space, the maximal interpolation errors will be psuhed to the top and bottom slices, which usually contain the least tissue of interest.
It's not clear what your numbers refer to or what sequence you used, but if odd then even slices from top to bottom, I suspect your order should have been:
- 24 22 20.. 23 21 19...
but I may have misunderstood you.
> 2) I know that the standard recommendation is to do slice-timing before realign
> (and reorienting). However, the issue still seems unresolved (e.g.,
> http://www.mailbase.ac.uk/lists/spm/1999-05/0168.html
> http://www.mailbase.ac.uk/lists/spm/1999-06/0002.html). For example, what type
> of errors are introduced if one reorients before correcting for slice timing?
Imagine two voxels in adjacent slices, and a sudden movement that occurred for one scan only, in which the head translated by one slice.
1. If you slice-time corrected first, the temporal signal for each voxel would be correct, but for one scan the signal would come from a different brain region.
2. If you realigned first (perfectly), the signal would come from the same brain region, but would be incorrect (in timing) for one scan.
Both are potential problems.
In our scanner, we normally use sequential (descending) acquisition of transverse slices. Though movement is often in the z-direction, it is normally small, so the timing error in approach 2 is minimal.
If we used approach 1 on the other hand, voxels on the edge of the brain might show large signal discontinuities (e.g., being sampled from the skull for one scan).
Thus we prefer approach 2. However, for acquisition sequences with large interleaving, approach 2 might lead to considerable temporal errors, and you might prefer approach 1 instead.
> realignment assumes that the head motion is between TRs (i.e., because it
> compares on a volume by volume basis) and slice timing works on a slice by slice
> basis within each volume, why should it matter?
It does matter; see above.
> Finally, correcting for slice
> timing seems like it is more important to do for longer TRs (e.g., 3s or more)
> than for shorter TRs;
True, but ironically, the correction (interpolation) is also worse at long TRs (more aliasing). See helplist for more discussion of this. For designs where timing is important (eg event-related) it is generally best to keep the TR as short as possible.
Rik