|
Hi Richard, Christian,
my take is that for a block-design, most people do not do a slice timing
correction. Even for event-related designs, some people don't as there
is another interpolation step of questionable value (and results vary
desisively depending on your chosen settings). I do know that some
software packages (BAMM, specifically) instead allow to shift your
design matrix depending on the order of the slice acquisition wich I
personally find rather elegant :)
Best,
Marko
Mohr, Christian wrote:
> Hello Richard!
> I do not know a reference including a discussion about yes or no for
> using slice-timing in block designs. I tried to find the same answer
> some weeks ago you are looking for now. All I could find and appaised as
> useful information were the general explanations of the slice-timing
> procedure from R. Henson postet in the SPM-archives.
> I appended the posting further down.
> For more infos, search the list!
> Hope this helps and if somebody tells you the reference, I would be very
> happy about receiving a copy of this email....
>
> Best,
> Chris
>
> Richard Smith schrieb:
> > Hi all,
> >
> > In our lab, we do fMRI analaysis using SPM and our design is a Block
> Design During the preprocessing stage, do I need to include the Slice
> Timing? Is there any benefit/ harm if I include Slice Timing for a Block
> Design?
> >
> > If possible, can someone give me the reference?
> >
> > Thank you. Appreciate your help.
> > Richard.
> >
> > Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and
> 30+ countries) for 2¢/min or less.
>
>
> Christian Mohr
> Klinik für Neurologie
>
> Universitätsklinikum Schleswig-Holstein
> Campus Lübeck
> Ratzeburger Allee 160
> 23538 Lübeck
>
> Telefon: +49 451-500-3709
> FAX: + 49 451-500-2489
> email1: [log in to unmask]
> email2: [log in to unmask]
>
> ----------------------------------------------------------------------------------------------------------
>
> SPM SLICE-TIMING: THE FINAL WORD?
>
> The concept behind slice order specification is actually very simple,
> but there appears to be much room for confusion.
>
> Let me try to summarize the development of spm_slice_timing...
>
>
> When Christian and I wrote the front-end for the slice-timing
> code you provided (adapted from Geoff and Eric's code), we made
> the following simple assumptions:
>
> 1. The temporal order of slices would be coded by the
> left-to-right order of slices in a vector
>
> 2. The slices would be referenced by the Analyze convention,
> where 1=bottom slice.
>
> If you follow these rules when entering the slice order (as user-
> specified), there is no problem. Thus a six-slice descending sequence
> in space (top slice acquired first) would be coded as:
>
> 6 5 4 3 2 1
>
> I repeat: no errors will have been made if you followed these rules,
> regardless what sequence you use.
>
>
> The potential for confusion perhaps arose when we introduced two
> further
> options. The first was the the addition of various default menu options
>
> (descending, ascending, interleaved) that avoided the need for the user
>
> to type in slice order by hand (for the most common sequences). The
> second was the default choice of a reference slice (particularly in
> relation
> to interleaved sequences)....
>
>
> 1. Default options: Interleaving
> ================================
>
> The ascending/descending options refer to acquisition order in space,
> and are equivalent to typing 1:N or N:-1:1 respectively as user-
> specified (where N=number of slices).
>
> However, there are many possible interleaved sequences one can use:
> Odd-even slices, top-to-middle, bottom-to-middle. Rather than trying to
>
> offer all these, we chose one particular interleaving: top-to-middle.
> For a six-slice sequence, this would give:
>
> 6 3 5 2 4 1
>
> Note for an odd-number of slices, the "odd" slice is placed first
> (ie for a five-slice sequence: 3 5 2 4 1, rather than the alternative:
> 5 3 4 2 1).
>
> Your scanner may however use a different sequence. In this case, you
> should type the sliceorder by hand in the user-specified option.
> Thus it is possible that you might have pressed interleaved thinking
> it was appropriate for the particular interleaving used on your scanner
>
> when it was not. Our apologies for not making this clearer in the
> menu options.
>
>
> 2. Default reference slice
> ==========================
>
> As detailed in many previous emails to this list, the default reference
>
> slice (to which all other slices are "synchronised") offered by SPM is
> the middle slice in space (in Analyze format).
>
> Remember: if the temporal interpolation were perfect, the choice of
> reference slice would not matter. However, the interpolation will alias
>
> frequencies above the Nyquist limit, which may introduce appreciable
> noise if your TR is long (eg ~>2s).
>
> The amount of noise introduced will tend to increase the more the
> timeseries is shifted (ie the futher away, in time, a slice is from
> the reference slice), up to TR/2.
>
> Because we use sequential acquisition (ascending/descending) here, our
> rationale for offering the middle slice in space was that, because
> the middle slice in space happens to coincide with the middle slice
> in time for sequential acquistions, the maximum interpolation error
> would then be "pushed" to the top and bottom slices, which are usually
> at the extremes of the field-of-view and of least interest (eg the top
> and bottom of the brain, which usually have the least grey-matter
> voxels).
>
> If however you are interested in a particular region within your
> field-of-view (other than the middle), you might want to change
> the reference slice to coincide with that region.
>
> With interleaved sequences however, the choice of reference slice
> is far from clear (on the above rationale). For example, with a
> top-to-middle sequence, eg:
>
> 10 5 9 4 8 3 7 2 6 1
>
> The middle slice(s) in space (5/6) are not the middle in time (8/3).
> This is also true for odd-even sequences, eg:
>
> 10 8 6 4 2 9 7 5 3 1
>
> Without an a priori "slice-of-interest", there seems no principled
> reason for choosing the reference slice with interleaved sequences.
> In this case, one might as well chose the first slice in time (10
> in the above examples), to avoid the need to change the default
> fMRI_T0 in the SPM stats stage (see point 3 below). Thus you must
> think before accepting the default reference slice (which was
> chosen for sequential acquisitions) when using interleaved
> acquisitions.
>
>
> Other points to note:
>
> 3. Reference slice and reference time-bin
> =========================================
>
> As discussed in many previous emails, the value of fMRI_T0 in the
> Defaults-Statistics-fMRI menu should correspond to your choice of
> reference slice. fMRI_T0 tells SPM which of the fMRI_T time-bins
> (per TR) should be used as the value of the covariate for that scan.
>
> Namely, if you have interpolated to slice r of N (where r now refers
> to time, not Analyse format), then:
>
> fMRI_T0 = round ( fMRI_T * (r/N) )
>
> Note that the default value is 1 (ie first slice acquired). This makes
> sense for epoch designs (eg boxcars), where slice-timing is less of a
> problem.
>
> We thought about automatically changing the value of the global
> variable
> fMRI_T0 on the basis of the user's choice of reference slice during a
> previous slice-timing correction stage. However, since this change
> would
> only apply if the same matlab session were in operation, we have
> decided
> not change the defaults. Thus it is up to the user to remember to
> change
> the value of fMRI_T0 (if necessary) to match the reference slice (if
> slice-timing correction has been used) before creating a design matrix.
>
>
>
> 4. TA and TR
> ============
>
> We originally imagined near-continuous scanning, where the TR (time
> between first slice of one scan and first slice of the next) was very
> close to
> the TA (time between the first and last slice of one scan). With N
> slices,
> the time-per-slice (which the interpolation obviously needs to know) is
>
> simply:
>
> TR/N
>
> To accommodate significant gaps between scans, Michael Erb allowed the
> user to enter a TA smaller than the TR. Matthew Brett then pointed out
> a
> small error in the calculation of time-per-slice, which should be (and
> is now):
>
> TA/(N-1)
>
> Note that if your TA is a lot less than your TR, you might also want to
>
> adjust the value of fMRI_T0 appropriately, because fMRI_T (and fMRI_T0)
> refer
> to the number of time-bins per TR (not per TA). Thus, if you had TA=3s
> and
> TR=4s, and wanted to reference to the middle slice in time, you would
> chose:
>
> fMRI_T0 = fMRI_T * 3/4 * 1/2
>
> Eg for the default fMRI_T=16, fMRI_T0 would be 6 (not 8).
>
> Several people have pointed out that you could change the value of
> fMRI_T to match the number of slices, N. Then the reference time-bin
> could match the reference slice (in time) exactly. This is perfectly
> acceptable;
> the only reason we chose an fMRI_T value of 16 was that it seemed a
> reasonable degree of temporal resolution with typical TRs of 3-4s:
> increasing
> fMRI_T above this will not gain any real sensitivity (with typical TRs,
> given
> the time constants of the HRF and temporal smoothing), but may slow
> down
> computation.
>
>
>
> --
> ---------------------------8-{)}-------------------------
>
> DR R HENSON
> Institute of Cognitive Neuroscience &
> Wellcome Department of Cognitive Neurology
> 17 Queen Square
> London, WC1N 3AR
> England
>
> EMAIL: [log in to unmask]
> URL: http://www.fil.ion.ucl.ac.uk/~rhenson
> TEL1 +44 (0)20 7679 1131
> TEL2 +44 (0)20 7833 7472
> FAX +44 (0)20 7813 1420
--
=====================================================================
Marko Wilke (Dr.med./M.D.)
[log in to unmask]
Universitäts-Kinderklinik University Children's Hospital
Abt. III (Neuropädiatrie) Dept. III (Pediatric neurology)
Hoppe-Seyler-Str. 1, D - 72076 Tübingen
Tel.: (+49) 07071 29-83416 Fax: (+49) 07071 29-5473
=====================================================================
|
