Diff for "SliceTimingRikEmail" - MRC CBU Imaging Wiki
location: Diff for "SliceTimingRikEmail"
Differences between revisions 7 and 8
Revision 7 as of 2006-10-01 13:36:13
Size: 4871
Comment: Putting in line breaks in quoted email sections
Revision 8 as of 2011-02-09 09:55:47
Size: 4699
Editor: RikHenson
Comment:
Deletions are marked like this. Additions are marked like this.
Line 40: Line 40:
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
where the variables s1..sN refer to the slice number, and the left to right order of elements in this vector represent the
Line 45: Line 43:

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 order within the file by switching to
"voxel space" when displaying that image. The bottom slice in
the Display windows is the first slice in the image file.
Line 124: Line 130:
''> and it also seems that it is more important to do slice''
[[BR]]
''> timing if the stimulus presentation is synched with data acquisition (i.e.,''
[[BR]]
''> stimulus presentation is always at the beginning of the TR) compared to when the''
[[BR]]
''> 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.

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 BR > first is a matter of usage, the second is a more general theoretical question BR > that has been discussed to some extent already. BR > BR > 1) I collect 24 slices collected from superior to inferior, ordered 1 3 5 7 BR > 9...24. Thus, I enter a user specified order of 1 3 5 7 9...and a reference BR > slice of 24 (since my images are in ANALYZE format and I collected from S-I). Is BR > this correct or should I also be ordering my slices in terms of space (i.e., BR > slice order of 24 22 20...)? And does this depend on whether I reorient first BR > (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 order within the file by switching to "voxel space" when displaying that image. 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 BR > (and reorienting). However, the issue still seems unresolved (e.g., BR > http://www.mailbase.ac.uk/lists/spm/1999-05/0168.html BR > http://www.mailbase.ac.uk/lists/spm/1999-06/0002.html). For example, what type BR > 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 BR > compares on a volume by volume basis) and slice timing works on a slice by slice BR > basis within each volume, why should it matter?

It does matter; see above.

> Finally, correcting for slice BR > timing seems like it is more important to do for longer TRs (e.g., 3s or more) BR > 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

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