questions > dcm2niix, slice timing and slice order
Showing 1-4 of 4 posts
Jun 18, 2019 10: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: https://www.mccauslandcenter.sc.edu/crnl...
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": [
0,
0.1375,
0.2775,
0.4175,
0.5575,
0.6975,
0.835,
0.975,
1.115,
1.255,
.....
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...
Best,
Rich
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: https://www.mccauslandcenter.sc.edu/crnl...
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": [
0,
0.1375,
0.2775,
0.4175,
0.5575,
0.6975,
0.835,
0.975,
1.115,
1.255,
.....
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...
Best,
Rich
Jun 18, 2019 01:06 PM | 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 05:07 PM | 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,
Rich
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,
Rich
Jul 4, 2019 10: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.
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.