## page was renamed from SliceTiming
= Slice timing questions =
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