Slice timing correction: clarification sought

Greetings AFNI gurus,

I’ve recently been wading into the murky waters of slice timing correction, and I’m trying to establish a robust procedure to ensure that I always get the correct -tpattern string for 3dTshift, regardless of scanner manufacturer or image orientation (sadly I cannot rely on relevant slice timing tags being ported during the NIfTI conversion process).

From reading this forum post -,160244,160244#msg-160244 - I think I’ve gotten the hang of it, but I would greatly appreciate some feedback as to whether I’m on the right track or not. The procedure I have in mind is:

1, From the scanner printout, ascertain slice acquisition pattern (interleaved, sequential, sequential starting from slice 1…)

  1. Also from the printout, establish the location of DICOM slice zero (top or bottom of the subject’s head).

  2. Work out in which order the slices are stored on disk in NIfTI format (3dinfo -orient).

  3. If there’s a disparity between how the slices were acquired from the scanner and how they are stored in NIfTI, apply a flip to the tpattern accordingly (e.g., if the scanner printout shows that the slices were acquired sequentially from foot to head, but 3dinfo shows that the NIfTI orientation for the z-plane is Superior to Inferior, -tpattern would need to be changed from seq+z to seq-z).

Does that sound about right? Am I missing anything? Any clarification would be greatly appreciated!



P.s., I am assuming that all volumes were acquired axially

Just to add to this, I’ve stumbled across another forum post on the topic of AFNI slice timing correction (, which I THINK validates the series of steps I’ve highlighted above, with the added caveat that slice timing correction should really be done before applying any other modifications to the functional volume - on the off chance that other changes the functional volume could introduce an undesirable discrepancy between the output of 3dinfo and the increasing indices along the k data axis of the data block.

Does this all sound about right?



Hi Rich,

This seems reasonable, but there will always be some additional aspect that you could think about. I have not seen that it is even possible to know what the slice timing is, depending on the scanner. So step 1 seems questionable. What sort of printout are you picturing?

Note that some timing patterns cannot be stored in NIFTI. It can handle a fixed list of patterns, but any deviation cannot be directly stored. For example, a multi-band sequence will not match any known pattern in the NIFTI standard, and therefore such information would need to be separate. It could possibly be left in a NIFTI extension, but software would not know to read that.

  • rick

Hi rick,

Since you mentioned multi-band scanning, I assume you refer to the MGH Simultaneous Multi-Slice sequence. In our case, each volume has 69 slices, with a SMS factor of 3 (e.g., 3 bands). TR=1500ms. I use Dicominfo in Matlab to read the slice timing information (see below) from the DICOM file, and assign such timing information to slices using to3d with a customized txt file given to tpattern option. And then do slice timing correction later using 3dTshift. Does this sound a reasonable way for multi-band scanning? Thanks!


timing information:
0 782.5 65 847.5 130 912.5 195 977.5 260 1042.5 325 1107.5 390 1172.5 455 1237.5 520 1302.5 585 1367.5 650 1432.5 717.5 0 782.5 65 847.5 130 912.5 195 977.5 260 1042.5 325 1107.5 390 1172.5 455 1237.5 520 1302.5 585 1367.5 650 1432.5 717.5 0 782.5 65 847.5 130 912.5 195 977.5 260 1042.5 325 1107.5 390 1172.5 455 1237.5 520 1302.5 585 1367.5 650 1432.5 717.5

Hi Qiuhai,

Sure, that sounds good, though the timing might be stored differently for other scanner types.

  • rick