Dear sir/Madam,

I am using dcm2niix to convert CT scans to NIFTI. Some of the CT scans have different slice thickness. After dcm2niix, it gives a re-sliced NIFTI files with "_Eq" in the file name. However, this NIFTI file has slice thickness as 0 which is really strange. When I view this NIFTI file on Mango, it basically just one slice, and I cannot view any other slice except the first slice. However, the image information gives me the slice number is 42, but slice thickness is 0.

May I ask why? Did I do anything wrong with this tool?

Many thanks,
Wenwen

I suspect this is an issue with your DICOM images. I suspect the Type 1 (Required) tags Patient Position 0020,0032 is missing or corrupted (see http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.2.html for details). 

You can see this by running dcm2niix in verbose mode ("-v 1") and looking at the slice positions reported, e.g.

dcm2niix -v 1 ~/DICOM
Chris Rorden's dcm2niiX version v1.0.20200331 (JP2:OpenJPEG) (JP-LS:CharLS) Clang11.0.0 (64-bit MacOS)
Found 2 DICOM file(s)
Patient Position 0020,0032 (#,@,X,Y,Z) 1 2398 -63 -660.32 598.576
DICOM file: /DICOM/MR.1.3.12.2.1107.5.2.32.35131.2014031012593442716690029
patient position (0020,0032) -63 -660.32 598.576
orient (0020,0037) 0 1 0 0 0 -1
acq 1 img 1 ser 21 dim 384x384x1x1 mm 3.25x3.25x3.6 offset 88840 loc 0 valid 1 ph 0 mag 1 nDTI 0 3d 0 bits 16 littleEndian 1 echo 1 coilCRC 798937909 TE 30 TR 3000
Patient Position 0020,0032 (#,@,X,Y,Z) 1 2396 -63 -660.32 598.576
DICOM file: /DICOM/MR.1.3.12.2.1107.5.2.32.35131.2014031012593723427590139
patient position (0020,0032) -63 -660.32 598.576
orient (0020,0037) 0 1 0 0 0 -1
acq 2 img 2 ser 21 dim 384x384x1x1 mm 3.25x3.25x3.6 offset 88838 loc 0 valid 1 ph 0 mag 1 nDTI 0 3d 0 bits 16 littleEndian 1 echo 1 coilCRC 798937909 TE 30 TR 3000
Slices stacked despite varying acquisition numbers (if this is not desired recompile with 'mySegmentByAcq')
Converting /DICOM/MR.1.3.12.2.1107.5.2.32.35131.2014031012593442716690029
Slice timing range appears reasonable (range 0..2440, TR=3000 ms)
Convert 2 DICOM as /Users/chris/Neuro/issue400/issue400_sag_int_36sl_20140310133834_21 (64x64x36x2)
Conversion required 0.023337 seconds (0.015922 for core code).

Alternatively, you could view the full DICOM header using a tool like dcmdump (e.g. "dcmdump /DICOM/0001.dcm") and inspect these tags. I think you want to look at how your images were created and modified. In particular, some crude tools for DICOM anonymization remove these crucial details. If you can source a copy before these tags were corrupted/removed you should not have a problem converting the images.

Hi Chris,

Thanks for the reply.

I have checked both of my CT files and re-run the command lines you suggested. The image does have the patient position (0020, 0032) information which is -93.3 -130.853 149.594 in it.

But the odd thing is that when I re-run dcm2niix, I don't have the converted NIFTI file with "_Eq" in the file name any more. So now I only have one converted NIFTI file without "_Eq" in the file name, but previous I have two converted NIFTI files: one with "_Eq" and one without "_Eq" in the file name. May I ask why? Previously, the one with "_Eq_" in the file name has slice thickness is 0, the one without "_Eq_" in has re-sliced thickness which is as expected. I run the same data on the same machine use the same command line. 


In another CT file folder, I re-run the my same command line again, dcm2niix -o NIFTIfolder -f %i_%t_%s -z y DICOMfolder, the converted NIFTI with "Eq" does give resliced image. But previously, on the same machine, I got this file with slice thickness 0. 

May I ask why it could happen like this -- run the same command line on the same data but different time can give different results? Many thanks in advance

Originally posted by Chris Rorden:

If image patient position (0020, 0032) is "-93.3 -130.853 149.594" for all slices, it suggests all slices were located in the same position of space, e.g. there is 0mm between the slices. Either this is an error in your DICOMs or this is a time series, where the same slice is sampled at different points in time. dcm2niix assumes that the DICOM images are accurate, it has no other source of information.

Hi Chris,

Thank you for the prompt reply.

The patient position (0020, 0032) is different for each slice. What is the most strange thing is that I get two different results after running dcm2niix with and without -v 1.

If I run this command line "dcm2niix -v 1 -o output_folder -f %i_%t_%s -z y dcm_folder", it gives me proper re-sliced image properly with "_Eq" in the file name. However, if I take "-v 1" off, it will not be able to give me re-sliced image but a warning message "Unable to equalize slice distances: slice order not consistently ascending. Recompiling with '-DmyInstanceNumberOrderIsNotSpatial' might help."

May I ask why? I thought -v 1 only gives more detailed message of the converting process rather than changing my converting results...

Originally posted by Chris Rorden: