I am encountering an issue when importing DICOM files. I am working with ITK Python library version 5.4.0 and SimpleITK 2.4.0. I have previously asked this same question in 3DSlicer forum, because we are working with Slicer and Python to script our algos. The same behavior is obtained with all these tools.
The details are as follows:
I have around 300 MRI studies, each including series for examining the patient’s thigh. These series consist of a locator scan, performed in the coronal plane, and an axial series for quantifying the mid-thigh region. The same acquisition protocol was essentially used for all these studies.
After reading the DICOM files with SimpleITK/ITK, and saving with a different format (in order to visualize them), I noticed that some studies have the quantification series displayed in an inverted orientation (upside down) and with incorrect voxel spacing (default value of 1 mm). The locator scan is always correctly oriented and has the correct voxel size.
We tested the DICOM files with other viewers (Weasis, Radiant, Syngo), and all of them correctly read all the series.
If the “Interoperability” option is enabled when exporting studies from the MRI workstation, ITK correctly imports the DICOM data. When this option is enabled, each slice is saved in a separate individual DICOM file, whereas initially, there is one DICOM file per entire series.
I am unable to determine which parameter in the DICOM header causes ITK to interpret some studies correctly and others incorrectly. I can share two studies of each type to help debug the import process.
@mathieu.malaterre Thanks a lot for your indications. I have just downloaded from your GitHub the windows version of the GDCM and I get this outputs:
For T_521_2:
PS C:\Program Files\GDCM 3.0\bin> ./gdcminfo.exe -i T_521_2.dcm
MediaStorage is 1.2.840.10008.5.1.4.1.1.4.1 [Enhanced MR Image Storage]
TransferSyntax is 1.2.840.10008.1.2.1 [Explicit VR Little Endian]
NumberOfDimensions: 3
Dimensions: (320,280,88)
SamplesPerPixel :1
BitsAllocated :16
BitsStored :12
HighBit :11
PixelRepresentation:0
ScalarType found :UINT16
PhotometricInterpretation: MONOCHROME2
PlanarConfiguration: 0
TransferSyntax: 1.2.840.10008.1.2.1
Origin: (-219.899,-177.378,-747.605)
Spacing: (1,1,1)
DirectionCosines: (1,-4.63573e-010,1.31627e-008,-4.63574e-010,0.997522,0.07035)
Rescale Intercept/Slope: (0,1)
Orientation Label: AXIAL
The correct dimension should be: 320, 280, 88 and spacing: 1.4125, 1.4125, 3
PS C:\Program Files\GDCM 3.0\bin> ./gdcminfo.exe -i T_521_2.dcm
…
Spacing: (1,1,1)
…
The correct dimension should be: 320, 280, 88 and spacing: 1.4125, 1.4125, 3
Yes, the problem is with e.g. this file: T_521_2.MR.INVESTIGACION_T.71.1.2024.01.20.11.20.47.274.37506607.dcm, it has not only incorrect spacing, but even worse – it is flipped in Slicer.
AFAIK, the ITK’s GDCMIO doesn’t have any special code for “enhanced” IODs and relies on GDCM, isn’t it? Support for “enhanced” IODs is unfortunately very basic, I think this has been known for years, there is the related warning in Slicer.
@mihail.isakov … might be interested in looking into this.
Thank you, in my app the image is OK (s. screenshots 2, 3). Maybe I shall look closer at the GDCMIO a little later.
Thank you very much for your response, Mihail.
Yes, both with SimpleITK and in Slicer, cases 521 and 523 appear flipped.
However, they are correctly oriented in other viewers.
The question is: what DICOM header parameters cause this inconsistent behavior? I do not have sufficient knowledge of the DICOM format to resolve this issue. I have spent quite a few hours trying to debug this inconsistency, but I have not been able to pinpoint the exact source of the problem.
My short-term goal is to adjust the acquisition process on the MRI machine to generate DICOM files that do not appear flipped. This seems achievable since cases 700 and 657 (also shared) are correctly oriented.
Trivial test with the T_521_2.MR.INVESTIGACION_T.71.1.2024.01.20.11.20.47.274.37506607.dcm (in Debug mode):
r@deb2:~/tmp/test022/build$ ./test
Error: In /home/r/itk54/ITK-5.4.0/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmImageHelper.cxx, line 281, function bool gdcm::ComputeZSpacingFromIPP(const DataSet&, double&)
This Enhanced Multiframe is not supported for now. Sorry
Warning: In /home/r/itk54/ITK-5.4.0/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmImageHelper.cxx, line 1458, function static std::vector<double> gdcm::ImageHelper::GetSpacingValue(const gdcm::File&)
Could not find Spacing
Error: In /home/r/itk54/ITK-5.4.0/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmImageHelper.cxx, line 281, function bool gdcm::ComputeZSpacingFromIPP(const DataSet&, double&)
This Enhanced Multiframe is not supported for now. Sorry
Warning: In /home/r/itk54/ITK-5.4.0/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmImageHelper.cxx, line 1458, function static std::vector<double> gdcm::ImageHelper::GetSpacingValue(const gdcm::File&)
Could not find Spacing
Error: In /home/r/itk54/ITK-5.4.0/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmImageHelper.cxx, line 281, function bool gdcm::ComputeZSpacingFromIPP(const DataSet&, double&)
This Enhanced Multiframe is not supported for now. Sorry
Warning: In /home/r/itk54/ITK-5.4.0/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmImageHelper.cxx, line 1458, function static std::vector<double> gdcm::ImageHelper::GetSpacingValue(const gdcm::File&)
Could not find Spacing
