# Issue with Importing DICOM Files in Slicer
**URL:** https://discourse.itk.org/t/issue-with-importing-dicom-files-in-slicer/7345
**Category:** Algorithms
**Created:** [December 9, 2024, 6:01pm UTC](https://discourse.itk.org/t/issue-with-importing-dicom-files-in-slicer/7345 "2024-12-09T18:01:20Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@rcabeza](https://discourse.itk.org/u/rcabeza)
#### Post date: [December 9, 2024, 6:01pm UTC](https://discourse.itk.org/t/issue-with-importing-dicom-files-in-slicer/7345/1 "2024-12-09T18:01:20Z")
Hello everyone,
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](https://discourse.slicer.org/t/issue-with-importing-dicom-files-in-slicer/40463), 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:
1. 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.
2. 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.
3. We tested the DICOM files with other viewers (Weasis, Radiant, Syngo), and all of them correctly read all the series.
4. 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.
[2share\_dicom\_files](https://unavarra-my.sharepoint.com/:u:/g/personal/rcabeza_unavarra_es/EbQjfHXJ-39MgD0sXIAdSrgBf2OqFM8byT7ZZqa_tsurRw?e=FKbLEJ)
Best regards, and many thanks in advance.
Rafa
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [December 9, 2024, 6:03pm UTC](https://discourse.itk.org/t/issue-with-importing-dicom-files-in-slicer/7345/2 "2024-12-09T18:03:07Z")
@mihail.isakov and/or @mathieu.malaterre might be interested in looking into this.
---
### Author:  [@mathieu.malaterre](https://discourse.itk.org/u/mathieu.malaterre)
#### Post date: [December 12, 2024, 9:28am UTC](https://discourse.itk.org/t/issue-with-importing-dicom-files-in-slicer/7345/3 "2024-12-12T09:28:43Z")
@rcabeza I did download your files. I did check the DICOM file “T\_521\_2.MR.INVESTIGACION\_T.20.1.2024.01.20.11.20.47.274.37506101.dcm”.
Here is what I see on my side:
```auto
> gdcminfo T_521_2.MR.INVESTIGACION_T.20.1.2024.01.20.11.20.47.274.37506101.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: (512,903,8)
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: (-196.677,-21.2027,-540.594)
Spacing: (0.78125,0.78125,9)
DirectionCosines: (1,0,0,0,0.0415523,-0.999136)
Rescale Intercept/Slope: (0,1)
Orientation Label: CORONAL
```
So indeed the Z-spacing should be approx 9mm. I suspect you need to debug inside the itkGDCM code to check why this is getting changed to 1.
cc: @mihail.isakov
---
### Author:  [@rcabeza](https://discourse.itk.org/u/rcabeza)
#### Post date: [December 12, 2024, 11:07am UTC](https://discourse.itk.org/t/issue-with-importing-dicom-files-in-slicer/7345/4 "2024-12-12T11:07:33Z")
@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
Best regards and thank you again
Rafa
---
### Author:  [@mihail.isakov](https://discourse.itk.org/u/mihail.isakov)
#### Post date: [December 13, 2024, 2:57am UTC](https://discourse.itk.org/t/issue-with-importing-dicom-files-in-slicer/7345/5 "2024-12-13T02:57:42Z")
> 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.
---
### Author:  [@rcabeza](https://discourse.itk.org/u/rcabeza)
#### Post date: [December 13, 2024, 10:34am UTC](https://discourse.itk.org/t/issue-with-importing-dicom-files-in-slicer/7345/6 "2024-12-13T10:34:42Z")
**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.
Thank you again for all your help.
---
### Author:  [@mihail.isakov](https://discourse.itk.org/u/mihail.isakov)
#### Post date: [December 13, 2024, 7:22pm UTC](https://discourse.itk.org/t/issue-with-importing-dicom-files-in-slicer/7345/7 "2024-12-13T19:22:30Z")
Trivial [test](https://drive.google.com/file/d/1-FAb5oppS3D2iE0z0w1TVXZKURowAmUj/view?usp=sharing) with the `T_521_2.MR.INVESTIGACION_T.71.1.2024.01.20.11.20.47.274.37506607.dcm` (in Debug mode):
```auto
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 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 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 gdcm::ImageHelper::GetSpacingValue(const gdcm::File&)
Could not find Spacing
```
S. [gdcmImageHelper.cxx](https://github.com/InsightSoftwareConsortium/ITK/blob/80a172e8c241bfd19827232f2cd6e589b0a2dce5/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmImageHelper.cxx#L273-L284):
```auto
const double ZTolerance = 1e-3; // ??? FIXME
prev = distances[0];
for(unsigned int i = 1; i < nitems; ++i)
{
const double current = distances[i] - prev;
if( fabs(current - zspacing) > ZTolerance )
{
// For now simply gives up
gdcmErrorMacro( "This Enhanced Multiframe is not supported for now. Sorry" );
return false;
}
prev = distances[i];
```
**Edit:**
shortened the post because the problem was identified
---
### Author:  [@mihail.isakov](https://discourse.itk.org/u/mihail.isakov)
#### Post date: [December 13, 2024, 8:48pm UTC](https://discourse.itk.org/t/issue-with-importing-dicom-files-in-slicer/7345/8 "2024-12-13T20:48:13Z")
> Or non-uniform image or non-equidistant image.
> ```auto
> const double ZTolerance = 1e-3; // ??? FIXME
>
> ```
Works if _ZTolerance_ is reduced to `1e-2`.
---
### Author:  [@rcabeza](https://discourse.itk.org/u/rcabeza)
#### Post date: [December 20, 2024, 4:25pm UTC](https://discourse.itk.org/t/issue-with-importing-dicom-files-in-slicer/7345/9 "2024-12-20T16:25:16Z")
Thanks a lot Mihail. As final user of SimpleITK, how can I change this tolerance parameter?