Distance varies and the output file has different value.

[GYDDHPY]

Describe the bug

The DICOM file has different image value from output nii file.
I'm not sure this is a design of dcm2niix or I used it in a wrong way.
Does dcm2niix change image values during the transfer procedure?

To reproduce

Run the command 'dcm2niix '

Expected behavior

The tranfered nii file has same image value as DICOM file.

Output log

Found 108 DICOM file(s)
Unsupported overlay origin 0/0
Unsupported overlay origin 0/0
Unsupported overlay origin 0/0
Unsupported overlay origin 0/0
...
Unsupported overlay origin 0/0
Unsupported overlay origin 0/0
Warning: Assuming icon SQ 07a3,10ce.
Unsupported overlay origin 0/0
Unsupported overlay origin 0/0
...
Unsupported overlay origin 0/0
Unsupported overlay origin 0/0
Warning: Interslice distance varies in this volume (incompatible with NIfTI format).
Convert 108 DICOM as 4HGQE0GS/4HGQE0GS_RoutineSeq_20210621081535_2 (512x512x108x1)

Version

Chris Rorden's dcm2niiX version v1.0.20211006 GCC9.4.0 x86-64 (64-bit Linux)

[neurolabusc]

@GYDDHPY I see you closed this issue. Can you describe the solution? Be aware that the simple NIfTI format requires a constant distance between slices. This is almost always the case with MR data, but not necessarily the case for CT data (where head scans often have many close slices near the brain stem and much wider spacing between superior slices). If you can share examples with my institutional email I can provide more feedback.

[GYDDHPY]

@GYDDHPY I see you closed this issue. Can you describe the solution? Be aware that the simple NIfTI format requires a constant distance between slices. This is almost always the case with MR data, but not necessarily the case for CT data (where head scans often have many close slices near the brain stem and much wider spacing between superior slices). If you can share examples with my institutional email I can provide more feedback.

Sorry for opening the issue as the difference observed indeed is just some error with my ITK-SNAP software.

The software, dcm2niix, produced two NIfTI files because of the varient distance of my CT slices. I have checked the image array of the raw slices NIfTI file. It's same as the raw DICOM file except the orientation changed.

The Eq file is the corrected file. I found that the number of slices increased a lot. I have read your tutorial but it's still difficult for me to decide which file to use in futher research, the corrected Eq file or raw file. Could you please give me some suggestions?

[neurolabusc]

The NIfTI format requires that all slices in a volume or equidistant. Some DICOM CT scans acquire slices close together in the brain stem and distantly spaced for more superior slices. If slices are not equidistant, dcm2niix will attempt to interpolate evenly spaced slices, with the resulting file having the _eq extension. Interpolation is often problematic, so whether this is acceptable depends on your application. If you have any control over the acquisition, it may be worth exploring acquiring your DICOMs with regular inter-slice distances.

[fedorov]

the simple NIfTI format requires a constant distance between slices

@neurolabusc what is the tolerance value you are using to decide whether distances between slices are consistent?

[neurolabusc]

0.2mm

[vkt1414]

@neurolabusc Hi Dr. Chris, I am from Dr. Fedorov's lab as well. I noticed that two series with slice interval differences of <0.2mm (0.025 and 0.04) had two volumes created by dcm2niix with _eq suffix, which made me think it could be due to inconsistent slice intervals.
Here are some screenshots and a public gdrive link to DICOM files. Whenever possible, could you take a look, Thank you very much.

Dicom files: https://drive.google.com/file/d/1ia8X2tBDS3u7lN7oN9ZzebKYTuW_yc2B/view?usp=sharing

[neurolabusc]

@vkt1414 the latest commit to the development branch should auto-detect that your instance numbers are jumbled. Previously, you would have to compile with -DmyInstanceNumberOrderIsNotSpatial to handle these files. Auto-detecting this rare edge case will incur a small performance penalty for all conversions. We also want to make sure there are no unintended consequences.

I am a huge fan of data re-use. However, CT technology has improved a lot in the last 24 years. Given that these scans are standard or care, I wonder if the National Cancer Institute should consider a modern refresh of these datasets. For machine learning, better quality data would help, and one would think that training on old data may provide a poor fit for modern images. I also note these images have been touched by dcm4che. While I did not see any obfuscation, you should be vigilant.

[fedorov]

@neurolabusc thank you for looking into this!

your instance numbers are jumbled

I think it is important to note that InstanceNumber is a Type 3 attribute. Not only that, but the standard does not appear to place any constraints or expectations about the value of that optional attribute.

I actually didn't realize you are using that attribute for reconstruction. At least for series that correspond to a single volume acquisition, I would never even look at that attribute - InstanceOrientation/Position are sufficient and are Type 1.

Given that these scans are standard or care, I wonder if the National Cancer Institute should consider a modern refresh of these datasets.

I do not know what you mean by a "modern refresh of those datasets".

For machine learning, better quality data would help, and one would think that training on old data may provide a poor fit for modern images.

I agree that in principle it would be nice to replicate an arbitrary clinical trial, or research study in general, with an alternative equipment. In practice, that is unfortunately not practical.

I also note these images have been touched by dcm4che. While I did not see any obfuscation, you should be vigilant.

Again, in practice, one often does not have a choice, and may not be able to fully trace the provenance record and transformations of a given DICOM file. In this case, we are working with the data that originated from the NLST clinical trial, and was graciously shared into public domain. Collecting a comparable dataset is not an option for us, and is not of interest for us.