questions > dcm2niix, slice timing and slice order
Showing 1-4 of 4 posts
Results per page:
Jun 18, 2019  03:06 AM | Richard Parker - Institute of Psychiatry, Psychology & Neuroscience, King's College London
dcm2niix, slice timing and slice order
Hi Chris,

I typically use scanner printouts to determine slice ordering/direction for slice timing correction, but currently I'm dealing with some Siemens data with an ambiguous printout ('Image numbering' changed to H>>F), as described on your website:

As you suggest, I will refer to the dcm2niix BIDS file to extract slice timing info for this data. One thing I'd appreciate some extra clarity on is the order of the slice timing values in the BIDS file w.r.t the image volume. For example, for the following output:

"SliceTiming": [

How can we find out which slice the first entry ("0") corresponds to? Is it always a fixed location (e.g., the most inferior slice in the head), or does it vary according to the order that the slices were acquired?

If the latter, is there any easy way to determine the spatial location of the relevant slice from the DICOMs or the NIfTI? I looked into ascertaining spatial locations from DICOM tags not too long ago, and if I remember correctly it's not a straightforward procedure...


Jun 18, 2019  06:06 AM | Chris Rorden
RE: dcm2niix, slice timing and slice order
The slice timing values are with respect to the order that the 2D slices are saved to disk. In you case, the first slice on disk was acquired first, and the next slice as saved to disk was acquired 0.1375 seconds later. This is how tools like FSL's slicetimer and SPM expect the data to be reported. These slice timing tools do not need to know anything regarding world-space (x,y,z dimensions), they only work within image space (i,j,k). So since you mention H>F, it suggests that your data was acquired as axial slices. Therefore, if the first slice on disk is the closest to the feet, with subsequent slices moving superior than your acquisition was ascending in the head to foot direction. On the other hand, if the first slice is the most superior, this is a descending sequence. You can look at the header's QForm or SForm to transform i,j,k (columns, rows, slices) to x,y,z (left-right, posterior-anterior, inferior-superior). Alternatively, open the preferences window in MRIcron and turn of image reorient/rotation and load your data without spatial transforms.
Jul 3, 2019  10:07 AM | Richard Parker - Institute of Psychiatry, Psychology & Neuroscience, King's College London
RE: dcm2niix, slice timing and slice order
Thanks Chris, very informative!

If that's the case, would I be right in thinking that dcm2niix preserves the slice order when converting fMRI volumes from DICOM to NIfTI? (i.e., the first 3 entries in the slice timing part of the .json file correspond to NIfTI slices 1,2 and 3?)

Also, can I ask how exactly you determine the order of the dicom slices? I also have some GE data with a questionable console printout, but luckily these scans happen to have the TriggerTime tag. I would like to use this info to work out the slice acquisition order, but I first need to know how to order all my DICOM files.

Thanks again,

Jul 4, 2019  03:07 AM | Chris Rorden
RE: dcm2niix, slice timing and slice order
The slice times reported in the BIDS json file correspond to the order that dcm2niix stores the slices to disk. This web page describes how dcm2niix infers slice timing and other details from GE files. In general, dcm2niix converts images based on the order or their instance number, and the vendor-specific DICOM tag reveals the acquisition time for that slice. Unfortunately, the DICOM standard does not require that instance number refers to acquisition order (or is even unique). Therefore, if instance number does not correspond with spatial position, dcm2niix orders the slices based on spatial position and again uses the corresponding time tag to infer the slice time of that slice. In brief, NIfTI requires slices are saved in spatially sequential order, so dcm2niix ensures this.

Also, I have heard reports but have not confirmed that some recent GE software releases use the single-band reference times for multi-band acquisition. Be aware that dcm2niix assume that the values in the DICOM header are truthful. This reflects an error in GE's DICOMs, not dcm2niix.