Distorted & malaligned volumes after loading DICOM sets

Support
,
1

Hello

I’ve got multiple DICOM datasets that are not properly loaded by Slicer.

The volumes are distorted and are incorrectly aligned to each other.
The distortion is caused by an incorrect scaling along the superoinferior axis.

As comparison the same datasets were loaded using Mimics:
Incorrect length of the bones in Slicer:
025_Slicer_Femur_Length
Same dataset in Mimics:
025_Mimics_Femur_Length
Incorrect relative position of volumes in Slicer:
025_Slicer_Alignement
Same dataset in Mimics:

025_Mimics_Alignement
025_Mimics_Alignement260×768 42.5 KB

The anonymized DICOM Images can be downloaded here:
https://bit.ly/3TalCrU

Best regards

2

How did you load the images, with which Slicer version? Did you get any warning during loading?

You need to use the DICOM module to load DICOM images. If the image has variable spacing between slices then make sure acquisition geometry regularization is enabled (it is enabled by default in recent Slicer versions).

3

Hi lassoan

I tried both the latest stable (5.0.3) and preview (5.1.0) release.

I did not get any warning in Slicer neither by pressing “Examine” nor “Load” in the DICOM module.
(In Mimics there is a warning in the Log: “Warning: The files are not possible to import in strict mode”)

The acquisition geometry regularization in Slicer was not enabled in 5.1.0.
I have switched it on now.

It seems to fix the distortion issue.
However, the incorrect relative position of the volumes remains (foot and knee at the same position in the picture) and it also seems to introduce other problems:

  1. Offset between the volume and the volume rendering (see distance measurement in the picture).
  2. Segmentation of the cortical bone is not possible anymore (see threshold range in the picture).

Segmentation_and_Offset_Issues
Segmentation_and_Offset_Issues1921×1016 168 KB

Best regards

4

Thanks for sharing the anonymized data. Try hardening the acquisition transform (switch to Transform hierarchy in the Data module and right click on the volume). This will resample the volume to uniform slice spacing. It seems to fix both your issues in my tests.

We don’t apply hardening automatically in case people want to control the resampling resolution but I’m thinking we should do more to alert people that some things won’t work when a transform is applied.

image
image417×1046 80.5 KB

5

Hi pieper

Great. That worked and solved the issues.

I now recognized that there actually is an warning in the Python console when loading the volumes:
^ Irregular volume geometry detected (maximum error of 459.5 mm is above tolerance threshold of 0.001 mm). Adding acquisition transform to regularize geometry.
^ Irregular volume geometry detected (maximum error of 453.662 mm is above tolerance threshold of 0.001 mm). Adding acquisition transform to regularize geometry.

I think this warning and maybe additional information should be presented to the user.

Thanks for your help
Harden AGR

6

Yes, I agree.

Maybe we should put up a dialog any log messages were posted during loading. An option could be to watch signals from the error model during the load process with this signal or similar.

slicer.app.errorLogModel().connect("entryAdded(ctkErrorLogLevel::LogLevel", self.trackError)

7

I had a look at the images. They were loaded incorrectly because they had incorrect SOP Class UID (1.2.840.10008.5.1.4.1.1.7) = Secondary Capture Image Storage. Secondary capture essentially means screenshot, and they are generally not meant to be reconstructed into 3D volumes.

We try to make Slicer behave sensibly for corrupted input data, but DICOM images are so complex that it is impossible to prepare for all the possible ways how they can be messed up.

The limitation of volume rendering not taking into account warping transforms is documented, but it is not realistic to expect users to read the documentation. I’ve submitted an issue to make sure we address this:

We will also review our current choice of using a complex combination of ITK and Slicer for reading DICOM images. Probably we should implement volume rendering construction logic in a Python package. It could be a standalone package that could be used without Slicer, too (just relying on VTK and maybe ITK). @pieper what do you think? Is there any promising Python package that does something similar that we could improve to fulfill all our needs?

8

I had a look at the images. They were loaded incorrectly because they had incorrect SOP Class UID (1.2.840.10008.5.1.4.1.1.7) = Secondary Capture Image Storage. Secondary capture essentially means screenshot, and they are generally not meant to be reconstructed into 3D volumes.

Yes, this is often difficult. In fact Secondary Capture Image Storage doesn’t contain Image Position Patient, Image Orientation Patient attributes. But such images are not seldom, i have seen also similar Osirix exports. Many programs don’t read these attributes from SC files.

Here is also another problem
MediaStorageSOPClassUID (0x0002, 0x0002 in image header) is different from SOPClassUID (0x0008, 0x0016).
MediaStorageSOPClassUID is “DCMTK unknown”
SOPClassUID is “Secondary Capture Image”
It is clearly wrong.

dciodvfy 025/SMIR.Lower_limb.064Y.F.CT.564/SMIR.Lower_limb.064Y.F.CT.564.0.dcm

Error - MediaStorageSOPClassUID different from SOPClassUID
Warning - Value dubious for this VR - (0x0008,0x0090) PN Referring Physician's Name  PN [1] = <unknown referring physician's name> - Retired Person Name form
SCImage
Error - Missing attribute Type 2C Conditional Element=<Laterality> Module=<GeneralSeries>
Error - Missing attribute Type 2C Conditional Element=<PatientOrientation> Module=<GeneralImage>
Error - Missing attribute Type 1C Conditional Element=<RescaleType> Module=<ModalityLUTMacro>
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x0050) DS Slice Thickness 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x0060) DS KVP 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x0088) DS Spacing Between Slices 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x0090) DS Data Collection Diameter 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x1100) DS Reconstruction Diameter 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x1110) DS Distance Source to Detector 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x1111) DS Distance Source to Patient 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x1120) DS Gantry/Detector Tilt 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x1130) DS Table Height 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x1140) CS Rotation Direction 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x1150) IS Exposure Time 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x1151) IS X-Ray Tube Current 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x1152) IS Exposure 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x1160) SH Filter Type 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x1170) IS Generator Power 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x1190) DS Focal Spot(s) 
Warning - Attribute is not present in standard DICOM IOD - (0x0018,0x1210) SH Convolution Kernel 
Warning - Attribute is not present in standard DICOM IOD - (0x0020,0x0032) DS Image Position (Patient) 
Warning - Attribute is not present in standard DICOM IOD - (0x0020,0x0037) DS Image Orientation (Patient) 
Warning - Attribute is not present in standard DICOM IOD - (0x0020,0x0052) UI Frame of Reference UID 
Warning - Attribute is not present in standard DICOM IOD - (0x0020,0x1041) DS Slice Location 
Warning - Dicom dataset contains attributes not present in standard DICOM IOD - this is a Standard Extended SOP Class

The attributes are from CT Image Storage.

1 Like
9

We do this already, but we only report errors that Slicer finds. ITK reader does not provide any warnings or errors, it just silently fails - reporting (1,1,1) spacing and (0,0,0) origin if it cannot determine the correct value. This is a quite serious limitation of ITK’s DICOM reader. Slicer checks consistency of the image geometry based on Image Position Patient and Image Orientation Patient tags and reports to the user if something seems wrong. However, in this case the values in these fields were correct but the problem was that these were not the fields that were supposed to be used (due to the incorrect SOP class UID). Since ITK does not report any issues and Slicer did not detect any issues, no errors were displayed to the user. When acquisition geometry regularization was enabled then Slicer detected that ITK’s image geometry looks incorrect and it took over, but this is usually not an error case (that’s how things supposed to work), so this is not reported to the user as a problem.

So, it was an unfortunate, unusual way of messing up a DICOM image, that got through our current error detection mechanisms. Enabling acquisition geometry regularization by default would have helped. I thought it is enabled by default in current Slicer version, but apparently not, so I’ve submitted a pull request to change the default - see:

10

With 5.0.3 and my local build the message only comes up in the python console as @MCM-Fischer reported. The message comes via logging.warning from the scalar volume plugin, so it shows up in the console and the error log but there’s no dialog box in this case.

Yes, I started down that path when I added the option to use either gdcm or dcmtk in the reader based on some experience we had with them behaving differently in their ability to handle certain datasets. We could add another path there to a pydicom-based parser. There are some other packages like dicomstack and some extensions that were being worked on in nibabel.

I think yes, we should try to factor out all the Slicer dicom parsing into python packages for general purpose use. Our dicom plugins can then depend on those and can add a layer to create the MRML representations of the parsed objects.

11

Yes, only those errors are displayed in a popup that Slicer detects. Slicer only detects inconsistencies of Image Position Patient and Image Orientation Patient values, and in this case these values were consistent, only the incorrect SOP class UID prevented ITK from using them. Unfortunately, ITK does not provide any warnings or errors.

You are right that probably there is no single toolkit that can handle all types of data sets. There is no single person, or even group, who would be aware of all details, error cases, ways how various device manufacturers messed up their implementations, etc. for all kinds of data sets, ranging from brain diffusion imaging to 4D cardiac ultrasound. Instead, we should choose a few high-quality implementations that cover all use cases.

In addition to DCMTK, GDCM, nibabel, and dcmtk, there is also dcm2niix and vtkDICOM.

12

This behavior is caused by GDCM. GDCM refuses to process Image Position Patient Patient and Image Orientation Patient for Secondary Capture Image Storage.

Also spacing is not taken from 0x0028, 0x0030 for SC, if i remember correctly.

13

SIDE NOTE: Support for regularization transform hardening in DICOM Scalar plugin has been added. See link.