Diff for "ProcessingSliceTiming" - MRC CBU Imaging Wiki
location: Diff for "ProcessingSliceTiming"
Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2007-06-29 12:36:31
Size: 2222
Editor: RikHenson
Comment:
Revision 3 as of 2013-03-07 21:24:03
Size: 2333
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
Our standard sequences acquire the slices from top to bottom (ie > descending). Thus the correct slice order for slice-timing correction is [N:-1:1], where N is your number of slices (eg 32) and the slice number refers to the position of the slice within the image file and in our case 1=last slice acquired (eg bottom slice). Our standard sequences acquire transverse(ish) slices from top to bottom (ie, descending). Thus the correct slice order for slice-timing correction is [N:-1:1], where N is your number of slices (eg 32) and the slice number refers to the position of the slice within the image file, where in our case 1=last slice acquired (eg, bottom slice for transverse). (To check this, display the image in voxelspace, after which slice 1 is z=0).
Line 10: Line 10:
(assuming SPM.xBF.T already set to, eg, 16). Alternatively, you can change the reference slice during slice-time correction to the first slice acquired (eg "top" slice, ie N here), either via the GUI when you run slice-timing, or if you use AA, by: (assuming SPM.xBF.T already set to, eg, 16). Alternatively, you can change the reference slice during slice-time correction to the first slice acquired (eg "top" slice, ie N here), either via the GUI when you run slice-timing, or if you use AA, by eg:

For slice-time correction of data acquired on our Trio using standard sequences...

Our standard sequences acquire transverse(ish) slices from top to bottom (ie, descending). Thus the correct slice order for slice-timing correction is [N:-1:1], where N is your number of slices (eg 32) and the slice number refers to the position of the slice within the image file, where in our case 1=last slice acquired (eg, bottom slice for transverse). (To check this, display the image in voxelspace, after which slice 1 is z=0).

However, if you have specified the reference slice to be slice 1 (as currently default in AA, for example), you WILL need to change the default reference timebin used in your subsequent 1st-level statistical analysis (to be the last timebin, eg 16, to match the fact that the data are synchronised to the last slice acquired). Otherwise your model will be 1 TR shifted with respect to your data, which can cause problems for event-related designs, particularly for long TRs and the short SOAs (generally speaking).

In other words, if you slice-time correct using a descending slice order but do not explicitly change the reference slice, you will need to change the reference timebin for your stats. This is called the "microtime onset" when you use the GUI, which should be equated to the "microtime resolution" (which is 16 by default). Or if you use batch scripts, you need to set:

SPM.xBF.T0 = SPM.xBF.T 

(assuming SPM.xBF.T already set to, eg, 16). Alternatively, you can change the reference slice during slice-time correction to the first slice acquired (eg "top" slice, ie N here), either via the GUI when you run slice-timing, or if you use AA, by eg:

aap.spmanalysis.sliceorder = [32:-1:1]; aap.spmanalysis.refslice = 32; 

For the very pedantic, yet another option is to change BOTH the reference slice to the mid-slice-acquired and the reference timebin to the mid-timebin. The reasoning here is that any temporal interpolation error during slice-timing correction is pushed towards the top and bottom slices (see SliceTiming), which tend to include regions of least interest (though not necessarily - if you are only interested in one ROI (in z-direction), then you can even choose the reference slice and reference timebin to match the slice containing that ROI).

CbuImaging: ProcessingSliceTiming (last edited 2013-03-07 21:24:03 by localhost)