Hello,
I need to know how dcm2niix handles and treats different imaging scan types including BOLD, anatomical, diffusion, localizer, and field map scans. I mainly want to know how dcm2niix handles each type of scan differently. I've been trying look all over Google and Google Scholar.
I’ve gone through the dcm2nii manual, but there are only brief mentions of how slice order recording for BOLD images. NITRC
Your question is underspecified. Different manufacturers use different methods to record slice order in DICOM files. Please check the dcm2niix page devoted to your manufacturer: Siemens, GE, Philips, Canon (ne Toshiba), Mediso, or UIH. Be aware that Philips does not record slice order in the image DICOMs, this is a limitation of Philips DICOMs, not dcm2niix.
but IIRC there was a way to deduce order (but not timing per se) from UIDs if really needed…
Hello,
So, I know that with BOLD scans, dcm2niix converts the dicoms into a 4D nifti image and detects slice order into the nifti header. With anatomical scans, dcm2niix will autocrop T1-weighted images to remove excess air surrounding the individual and parts of the neck below the cerebellum and reorient all images so they are all aligned to the nearest orthogonal direction to canonical space and convert into a 3D Nifti file. Are there any other differences between how dcm2niix handles different imaging types? I’m looking for how dcm2niix handles localizer scans as well.
@yarikoptic I have never heard of that trick, and I do not have access to Philips hardware. Can you provide further details and ideally validation datasets?
@PKornmanNeuroPsych to be clear, by default dcm2niix will losslessly rotate 3D non-EPI acquisitions to roughly match RAS and remove excess neck. This can be disabled with -x n (to not crop the 3D images) and -x i (to neither rotate or crop the data). Note that it is entirely possible to acquire 2D (rather than 3D) anatomical scans.
EPI scans are not rotated. This is because the slice timing routines of SPM, FSL and AFNI assume that the slice direction as saved to disk matches the temporal slice direction.
Be aware that the bvec/bval files that dcm2niix generates are in FSL format, e.g. aligned to the image plane, and with the first component flipped for volumes that have a positive determinant. This is very different from how a Siemens scanner saves b-vectors (with respect to scanner bore).
dcm2niix also attempts to store a lot of sequence information in the BIDS JSON file. See here for details.
As required by the BIDS standard: dcm2niix saves fMRI and DWI scans as 4D files but if there are multiple echoes each echo is stored as a separate file.
Found it – was discussed on nipy-devel@neuroimaging.scipy.org (gone now) in 2014. Found the script, converted to python3 – pushed into a new dumpster zvalysche/philips_order.py at master · yarikoptic/zvalysche · GitHub – seems to work on some sample philips dicom I demoed it in 2014:
$> wget http://www.onerussian.com/tmp/1.3.46.670589.11.17088.5.20.1.1.1464.2014022410164443495.dcm
...
$> python3 philips_order.py 1.3.46.670589.11.17088.5.20.1.1.1464.2014022410164443495.dcm
1.3.46.670589.11.17088.5.20.1.1.1464.2014022410164443495.dcm
Series: fMRI_SSh_3mm_sense2_sl35
Sequence: FEEPI
# slices: 35
order: [ 0 6 12 18 24 30 1 7 13 19 25 31 2 8 14 20 26 32 3 9 15 21 27 33 4 10 16 22 28 34 5 11 17 23 29]
TR (sec): 2.00
timing???: [0. 0.32012 0.60024 0.88036 1.18048 1.4906 0.08002 0.36014 0.65026 0.94038 1.2205 1.52062 0.13004 0.41016 0.69028 0.9904 1.27052 1.57064 0.16006 0.46018 0.7403 1.04042 1.32054 1.61066 0.22008 0.5202 0.79032 1.08044 1.36056 1.66068 0.2701 0.55022 0.83034 1.13046 1.43058]
max(???): 1.66
@yarikoptic that is an unintuitive trick. It would be interesting to know if this is a robust method we could include in dcm2niix. @sandeepganji do you have any thoughts on this?
Thank you so much. Sorry to ask. How are localizer scans handled through dcm2niix? Are they “split” by dimension then compressed into a 3D file?
Unlike DICOM, NIfTI requires that all image slices in a file are coplanar. Therefore, DICOM localizers that store Sagittarius, coronal and axial slices in a single series must be saved as three different NIfTI files. Localizers suffer from artifacts and partial volume effects and are only useful for planning subsequent scans. I always use the dcm2niix option ‘-i y’ to ignore these.
@yarikoptic I did evaluate your trick. It clearly works some of the time, but fails with modern systems and sequences. Specifically, for a 48 slice multi-band x2 (where pairs of spatially distant slices should share the same slice time) on a 3T Philips MR 55.1 5.5.2 the values were
"RepetitionTime": 1.97409,
"MTState": false,
"FlipAngle": 72,
"SliceTiming": [
0.07812,
0.10938,
0.10938,
0.10938,
0.14062,
0.14062,
0.14062,
0.15625,
0.17188,
0.17188,
0.20312,
0.21875,
0,
0,
0,
0.01562,
0.01562,
0.01562,
0.03125,
0.03125,
0.03125,
0.0625,
0.0625,
0.0625,
0.23438,
0.23438,
0.23438,
0.23438,
0.23438,
0.25,
0.25,
0.25,
0.25,
0.25,
0.25,
0.26562,
0.26562,
0.26562,
0.26562,
0.26562,
0.26562,
0.28125,
0.28125,
0.28125,
0.28125,
0.28125,
0.28125,
0.28125 ],
Maybe the report times when images are returned from a reconstruction system that works in parallel rather than sequentially. I do think your script may help some people, but it is not robust enough to include in dcm2niix.
FWIW, I came up with that trick / wrote that script I believe before any sms acquisition was available 
might need tuning or could be applied solely for non multi band.
But the best way would be - contact Phillips and ask WTF that critical metadata isn’t in dicom. Do you have contacts at Phillips? Otherwise I will try to go through Magdeburg radiologist through whom we had zebra artifact fixed (they didn’t want to listen to our whining directly).
MANAGED BY INCF