<?xml version="1.0" encoding="utf-8"?><!DOCTYPE article  PUBLIC '-//OASIS//DTD DocBook XML V4.4//EN'  'http://www.docbook.org/xml/4.4/docbookx.dtd'><article><articleinfo><title>ProcessingSliceTiming</title><revhistory><revision><revnumber>3</revnumber><date>2013-03-07 21:24:03</date><authorinitials>localhost</authorinitials><revremark>converted to 1.6 markup</revremark></revision><revision><revnumber>2</revnumber><date>2007-06-29 12:40:08</date><authorinitials>RikHenson</authorinitials></revision><revision><revnumber>1</revnumber><date>2007-06-29 12:36:31</date><authorinitials>RikHenson</authorinitials></revision></revhistory></articleinfo><section><title>For slice-time correction of data acquired on our Trio using standard sequences...</title><para>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). </para><para>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). </para><para>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 &quot;microtime onset&quot; when you use the GUI, which should be equated to the &quot;microtime resolution&quot; (which is 16 by default). Or if you use batch scripts, you need to set: </para><screen><![CDATA[SPM.xBF.T0 = SPM.xBF.T ]]></screen><para>(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 &quot;top&quot; slice, ie N here), either via the GUI when you run slice-timing, or if you use AA, by eg: </para><screen><![CDATA[aap.spmanalysis.sliceorder = [32:-1:1]; aap.spmanalysis.refslice = 32; ]]></screen><para>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 <ulink url="https://lsr-wiki-01.mrc-cbu.cam.ac.uk/imaging/ProcessingSliceTiming/imaging/SliceTiming#">SliceTiming</ulink>), 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). </para></section></article>