I tried to send this message this morning, but I didn't see a copy
appear on the helpline, so I suspect that it didn't go properly
(although everything looked OK from my end). So I thought I would
try again...
Dear Paul,
Thanks for checking with Rik on the other thing.
>My question here really is whether, although the slice timing works best at
>lower TRs, there is some length of TR below which there is no practical
>benefit of using it. In analysing some previous event-related data, I was
>struck by how a relatively sizeable error (about a second) in specifying
>when events occured, there seemed sufficient flexibility in the model to
>cope with the timing problems. That is, when I accidentally modelled all
>events as occuring (approximately) a second later than they actually did,
>the resulting activations (modeled solely with canonical HRF wave) differed
>little from the correctly modelled data. I assumed that this was a result
>of a very blurred temporal reposnse and some degree of flexibility in the
>way that SPM models the responses. This would suggest that the slice timing
>correction, though working best at low TRs, has its least practical value
>at these TRs. Does anyone out there have a feel for whether there is any
>lower limit below which correction for slice timing has lost its value?
In the only event-related study that I have done (the
saccades/attention study in the current issue of Brain) I was pretty
much forced to use the canonical HRF alone to model my events (there
were other events nearby which were not independently ordered). In
that case, the data was analyzed with SPM96, and my TR was about
4.1sec as I remember, with the top slice acquired first in the
functional scans (and no interleaving). These days I wouldn't have
used such a long TR, but that wasn't as clear at the time that those
experiments were done.
I used an early version of slice_timing, and compared this analysis
with two other analyses run without slice_timing, one with the
timings of the events correctly specified for the top slice, and one
with the events correctly specified for a slice at about the level of
the calcarine sulcus. Basically when clusters near the top of the
brain were examined, the non-slice-timed 'top slice' analysis gave
the highest statistical significance, but the slice-timing analysis
(with the top slice as the 'reference slice') did pretty well, with
only a slight depression of t values. The 'middle-slice' analysis
did very badly, and clusters near the top of the brain pretty much
disappeared.
When clusters near the calcarine sulcus were examined, they were
highly significant in all three analyses. Not surprisingly the
non-slice-timed 'middle slice' analysis did the best, then came the
slice-timed analysis, but the t values in the 'top-slice' analysis
were not very much worse. I ended up showing SPMs for the whole
brain from the slice-timed analysis, but referring to the 'top-slice'
analysis in the text of the paper for one particularly crucial
question relating to voxels near the top of the brain.
So, if you were forced to do analysis without 'slice-timing', this
would suggest that it is best to specify events correctly for a slice
near the top. I.e. a positive error and a negative error in
specifying event timings, each of the same amplitude (say 2 sec),
seem to have quite different results. I assume that the reason for
this is that the onset and the offset of the hrf are not the same,
but this may be completely incorrect, and of course the effect may be
specific to the particular areas I was looking at.
So my limited experience is that with a TR of 4.2, slice_timing does
have a significant benefit if you want to show spms of the whole
brain, but for individual slices the statistics are slightly better
if the timings are simply specified correctly for that slice.
Best wishes,
Richard.
--
from: Dr Richard Perry,
Clinical Lecturer, Wellcome Department of Cognitive Neurology,
Institute of Neurology, Darwin Building, University College London,
Gower Street, London WC1E 6BT.
Tel: 0207 679 2187; e mail: [log in to unmask]
|