|
Dear Darren and others,
thanks for your prompt responding. Yes - the slice timing continues to
give me a headache, too. Please, let me elaborate a bit more:
I have implemented your extension of the spm_slice_timing.m-code. (My
mailing program truncated some of your line editing but I got it to work
nicely. Thanks.)
First, I have come used to rescue to the user specified acquisition
type. As you, Rik and others (including myself) have previously pointed
out, "interleaved" differs between scanning implementations.
However, having chosen "user specified" I now [i.e. using your
spm_slice_timing.m] get 3 different slice orders being requested for the
SPM input: "order of slices", then "anatomical order of slices" and
finally "time order of slices". Do you get the same? Basically, I donīt
know what to make of the first. I guess it is somehow redundant and must
be the identical to either "anatomical order of slices" or "time order
of slices". My hunch is the latter.
Lets stick to your original example (mail sent 26th of June): 8 slices
acquired the following way-
actual anatomical position - top to bottom
acquired slice order = 1 5 2 6 3 7 4 8.
SPM slice number = 8 7 6 5 4 3 2 1 [in the .img-volume]
Here, I would enter 8 7 6 5 4 3 2 1 into "anatomical order of slices"
and 8 4 7 3 6 2 5 1 into "time order of slices", right?!? But before
getting these prompts, I first have to specify the old "order of
slices", even using your code. What do I have to enter there, 8 7 6 5 4
3 2 1 or 8 4 7 3 6 2 5 1???? My notion would be 8 4 7 3 6 2 5 1. In
summary for the above example, I would enter:
"order of slices" - 8 4 7 3 6 2 5 1
"anatomical order of slices" 8 7 6 5 4 3 2 1
"time order of slices" 8 4 7 3 6 2 5 1
Is that ok? And how can I check the output of the slice timing
procedure, i.e. the delay ascribed to an individual slice? You have
reported on your checking the delays and I wonder how to do it.
These are my main questions. But I find the issue TR/RT vs. TA problem
important, too. Michael has provided some solution, and now SPM assumes
that "timing(2) = time between last slices and next" in terms of the
beginning of the last slice of the [n]th volume and the beginning of the
first slice of the [n+1]th volume. (An alternative would be the end of
the last slice of the previous volume in the time series.)
Supposing that the acquisition of a slice itself does not take a
significant amount of time, the time points of slice acquisitions are
seperated by equal temporal spacings of RT divided by the number of
slices. Since RT should be the time between the beginning of the first
slice of the [n]th volume and the beginning of the first slice of the
[n+1]th volume, TA equals RT - timing(2) = RT - RT/nslices. Right? SPM
suggests that for the input. However, particularily in case of external
triggering some additional delay (TD*) may set in. (In fact, our vision
scanner needs it to overcome some refractory period for accepting the
next trigger reliably.) Therefore, TA = RT - TD* - TR/nsclices. (cave:
Michael speeks about TD = TR/nslices if I got him right and therefore I
am talking about TD*). If TA ought to specify the time between the
beginning of the first and last slice of a volume, then RT shall be the
time between the beginning of the first slices of two consequtive
volumes, TR the "physical" time minimally required from the start of the
first slice acqusition between two consecutive volumes and TD* the delay
RT - TR. Lets say, I am getting 8 slices in 1 second but have to wait
another 0.2 seconds to provide the next trigger. The interscan intervall
I specify first in slice timing is 1.200 s, and SPM will suggest 1.050 s
for TA. However,that is obviously not the case and instead I would have
to specify 0.875 s for TA. I can do so (i.e. SPM accepts the input) that
but as you noted I am not sure the calculation will be accurate. Will it
be ok in the example? And if the slice timing would be correct that way,
how about the statistics? The design matrix assumes the "time binning"
according to RT/nslices and isnīt that violated by the introduction of
an TD*?
To sum it up, I feel that slice timing needs to account for the fact
that the time between slices within a volume does not necessarily equal
the time between the final slice of a volume and the first slice of the
consecutive volume.
Additionally, I am not sure if there is not some extra time in the
beginning, i.e. a slight delay to the acqusition of the first slice
which adds into RT AND TR. If have tried to ask for that but did not get
feedback so far. Anyhow, that might be rather picky and irrelevant for
the stats and should not be as important as the delay introduced by the
above mentioned TD* which I would consider quite important. BTW, TD* is
of course not only crucial in external tiggering but you can also decide
on TD* by extending your RT over TR for whatever other reason. I know
that some people decided to use the scanner to drive the paradigm and
that others simply monitor the running of the scanner and the paradigm
to be sure about the timing. But we decided for external triggering to
have the paradigm drive the scanner and I still like it best.
I humbly submit the mail to you and the other SPM & Matlab experts. I
hope it makes some sense and I am looking forward to any clarification.
TIA-
andreas
PS: Dear Darren - the time bin selection to align to remains confusing
to me:
> For example if you get 8 slices, descending,
> and want to align the slices to the first acquired selecting 1 is the
> correct choice. To align to middle slice 4 is correct.
8 slices, SPM descending: top->bottom (= Vision ascending)
anatomical order - 8 7 6 5 4 3 2 1
time order (= order of slices? see above) - 1 2 3 4 5 6 7 8
The is no "middle slice, is there? But there is a slice in the middle of
the time bins which would be the 5th slice acquired and therefore 4th
SPM slice, right?
Have a good night...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
