Interpretation about slice timing

[younghoo]

Dear expert,

After running dcm2niix, I got the JSON file and found the slice timing vector. I know the numbers means the time when the slices were acquired. My question is how to know which number corresponds to which slice?

I read the STC Page, and it seems that in Siemens the first slice was always acquired from the inferior to the superior (foot to head) if the slice acquisition was along the axial axis. So I may be confident that the first number in the slice timing vector should correspond to the most inferior slice, if the total slices is odd. How about other vendors? How about the coronal slices were acquired?

I hope the question was clearly presented and I thank you for the help.

[neurolabusc]

The SliceTiming field is in BIDS format: The list goes through the slices along the slice axis in the slice encoding dimension. Therefore, the values correspond to the order that the slices are stored to disk, not a spatial dimension. For axial slices the disk order of slices correspond to inferior-superior (or superior-inferior), for sagittal acquisitions slices are left-right (or right-left) and for coronal the slice order corresponds to anterior-posterior (or posterior-anterior). In other words, SliceTiming refers to the index of the slice (k), not a spatial dimension (x, -x, y, -y, z, -z,).

[younghoo]

Thanks for your response. How can I determine whether the first value corresponds to the most inferior or the most superior slice, for instance, for axial slices? In the BIDS format, there is a slice encoding direction field, which, however, was not available in the JSON file created by dcm2niix.

[younghoo]

I would like to add some further notes to give more background about my question. I am going to do slice timing correction for my fMRI data using FSL's slicetimer or AFNI's 3dTshift. I would like to use the slice timing detected by dcm2niix, which seems more accurate than using slice order. The slice timing index corresponds to the order the slices saved into disk. For instance, the first value in the slice timing corresponds the first slice saved but not the first slice acquired. However, using 3dTshift or slicetimer, I need to know the spatial dimension. For instance, 3dTshift assumes the slices were acquired along the Z axis (in NIFTI orientation, Z means axial axis) and slicetimer also uses X/Y/Z to indicate the slice acquisition direction. In these cases, knowing whether the first value in the slice timing corresponds to the most inferior slice is crucial for axial slices. Maybe the X/Y/Z in AFNI/FSL is a misnomer or synonym of i/j/k?

[neurolabusc]

You can use the BIDS RepetitionTime and SliceTiming fields to generate a FSL slicetimer fractional --tcustom file. This will be more accurate than an indexed order in situations where there is a temporal gap between volumes, and is intuitive for situations like multi band (where there are many ties in the rank order).

For AFNI's 3dTshift you can supply the -voxshift fset to provide your fractional time shift (again based on the RepetitionTime and SliceTiming fields). @afni-rickr may provide additional details. AFNI tends to work best with BRIK/HEAD format files (which store slice timing details in the HEADer) rather than NIfTI format, so if you want to use AFNI, you may prefer their bespoke tools for DICOM conversion.

For both FSL and AFNI, the assumption is that the temporal slices are saved to disk as contiguous slices. If I wrote the AFNI documentation I would use the term K rather than Z to refer to the slices, as they refer to disk dimensions (columns, rows, slices = IJK) not spatial dimensions (right, anterior, superior = XYZ).

[younghoo]

Thank you for very detailed reply and now I can safely use the slice timing in the JSON file. For AFNI's 3dTshift, the slice timing could be directly fed into the command with -tpattern @filename option, which saves a little time.

I think the ambiguity/confusion between disk dimensions and spatial dimensions may be widespread, because I have analyzed fMRI data using AFNI/FSL (and other pipeline softwares) for several years (thus not a newcomer) and this is the first time I realized my misconception. Hope these discussions would be helpful for other users.

Again, many thanks for your kind help and great dcm2niix!

[neurolabusc]

Most EPI brain scans are acquired as axial slices, for these IJK corresponds to XYZ. Therefore, the confusion is typically not an issue. Be aware that -tpattern pre-dates multi-band: the NIfTI header does not encode the more complicated slice orders of multi band sequences. I would suggest using -voxshift fset as a robust solution.

While slice timing correction has proven useful (e.g. Sladky et al.; Parker et al.), it should be seen as a kludge. Specifically, for scans with a long RepetitionTime (TR), the slice timing error is large, but the sampling rate is low so the interpolation is inherently inaccurate. On the other hand, for sequences with a short TR, the error is very small so there is little error to correct. Current tools force us to sequentially choose motion correction versus slice time correction, but these two factors interact (we should really model these factors together). One should listen when Steve Smith describes slice timing correction generally being a bad thing. I do think that multi-band is a real game changer, allowing very short TRs: the slice timing error becomes very small. If you are interested in this topic, I would read the work by Parker et al. carefully: they suggest their STC algorithm slightly outperforms FSL/SPM methods (they did not test AFNI, but I think it is very close to SPM) and also argue that it still helps with very short TRs (720ms). I am surprised by this finding, and in my reading of their work they did not include a temporal derivative of the HRF into their statistical model, which I would have thought would accurately model small slice-timing errors.