Diff for "SliceTimingRikEmail" - MRC CBU Imaging Wiki
location: Diff for "SliceTimingRikEmail"
Differences between revisions 2 and 3
Revision 2 as of 2006-07-25 14:46:47
Size: 6563
Editor: devel03
Comment:
Revision 3 as of 2006-07-25 14:47:52
Size: 4605
Editor: devel03
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Th This is a useful email from RikHenson on the SPM mailing list
Line 6: Line 6:
'''Date:'''27 Apr 2000 - 22:03 BST * '''sorted by:''' [http://www.mrc-cbu.cam.ac.uk/Imaging/Common/welcome.html [ date ]] [http://www.mrc-cbu.cam.ac.uk/Imaging/Common/thread.html [ thread ]] [http://www.mrc-cbu.cam.ac.uk/Imaging/Common/subject.html [ subject ]] [http://www.mrc-cbu.cam.ac.uk/Imaging/Common/author.html [ author ]]
 * '''Next message:''' [http://www.mrc-cbu.cam.ac.uk/Imaging/Common/0189.html Daniel Weissman: "Re: Plotting time course information"]
 * '''Previous message:''' [http://www.mrc-cbu.cam.ac.uk/Imaging/Common/0187.html Karl Friston: "Re: Theoretical questions about t-tests, smoothing and degrees of freedom"]
 * '''In reply to:''' [http://www.mrc-cbu.cam.ac.uk/Imaging/Common/0185.html Barry Giesbrecht: "slice timing questions"]
 * '''Next in thread:''' [http://www.mrc-cbu.cam.ac.uk/Imaging/Common/0195.html Barry Giesbrecht: "RE: slice timing questions"]
'''Date:'''27 Apr 2000 - 22:03 BST
Line 114: Line 111:

---------------------------8-{)}-------------------------

DR R HENSON EMAIL r.henson@fil.ion.ucl.ac.uk
Wellcome Department of
 Cognitive Neurology TEL (work1) +44 (0)20 7833 7483
12 Queen Square TEL (work2) +44 (0)20 7833 7472
London, WC1N 3BG FAX +44 (0)20 7813 1420

 URL: http://www.psychol.ucl.ac.uk/rik.henson/index.shtml

---------------------------------------------------------

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



 * '''Next message:''' [http://www.mrc-cbu.cam.ac.uk/Imaging/Common/0189.html Daniel Weissman: "Re: Plotting time course information"]
 * '''Previous message:''' [http://www.mrc-cbu.cam.ac.uk/Imaging/Common/0187.html Karl Friston: "Re: Theoretical questions about t-tests, smoothing and degrees of freedom"]
 * '''In reply to:''' [http://www.mrc-cbu.cam.ac.uk/Imaging/Common/0185.html Barry Giesbrecht: "slice timing questions"]
 * '''Next in thread:''' [http://www.mrc-cbu.cam.ac.uk/Imaging/Common/0195.html Barry Giesbrecht: "RE: slice timing questions"]
~-''This archive was generated by [http://www.mailbase.ac.uk/docs/hypermail.html hypermail 2b25] :'' 31 Oct 2000 - 10:59 GMT-~

Slice timing questions

This is a useful email from RikHenson on the SPM mailing list 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 are the slice number in Analyze format (1=bottom) and the left to right order of elements in this vector represent the temporal order of slice acquisition.

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.

> and it also seems that it is more important to do slice > timing if the stimulus presentation is synched with data acquisition (i.e., > stimulus presentation is always at the beginning of the TR) compared to when the > stimulus presentation is randomized with respect to data acquisition.

To the extent that synchronising stimuli with respect to scanning may miss higher frequency components, I think you are correct that interpolation is more important in this case.

Rik

CbuImaging: SliceTimingRikEmail (last edited 2013-03-07 21:23:56 by localhost)