Failure to load DICOM Data

Support
1

Operating system: Windows10 Enterprise 1803
Slicer version: 4.10.2
Expected behavior: load DICOM Data
Actual behavior: Error message: Could not load: 1: Unnamed series as a scalar volume

´The DICOM data were produced by a micro-CT and consist of 1080 Slices with 1214x1443 pixel, 16 bit greyscale, little endian.
The first attempt seen in the log file was made using the data as supplied by the owner of the µCT, the second attempt after using the repair command of the DICOM import module. The error message is the same.
The folder on Dropbox provides:
the logfile
Screenshots of the error messages
Screenshot of the folders created by the repair command
Three sample slices
The complete data in a ZIP file

2

You can import this with the dcm2niix extension:

  1. View->Extnesion Manager, search and install “SlicerDcm2nii” extension
  2. Show “All Modules” and choose Dcm2niixGUI, select the “Input Directory” and select “Apply”
3

Thanks for sharing the data.

I suspect the problem is in the pathname to the data files. Probably a non-ascii character in the directory path? Maybe rename the folder and try again.

TypeError: SetArchetype argument 1: (unicode conversion error)

The sample data loads fine for me using the regular dicom module.

image
image1473×511 154 KB

4

@Norbert the unique identifiers (UIDs) in your images end with the space character. This is not allowed;

A character string containing a UID that is used to uniquely identify a wide variety of items. The UID is a series of numeric components separated by the period “.” character. If a Value Field containing one or more UIDs is an odd number of bytes in length, the Value Field shall be padded with a single trailing NULL (00H) character to ensure that the Value Field is an even number of bytes in length.

Therefore, strictly speaking these are not valid images and likely to cause issues with a wide range of tools. The absence of Date [DA] and Time [TM] values may also cause issues with some systems (though removing these is often done for anonymization). The DICOM header is so minimal, I assume this was created locally rather than derived from an image generated by a major vendor. If the latter is the case, I would check the providence of these images and see if you can get a copy prior to the corruption of the UIDs.

Dicom-File-Format

(0002,0000) UL 188 # 4, 1 FileMetaInformationGroupLength
(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
(0002,0002) UI =CTImageStorage # 26, 1 MediaStorageSOPClassUID
(0002,0003) UI [2.25.283649587552159738113732996351763764310] # 44, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianExplicit # 20, 1 TransferSyntaxUID
(0002,0012) UI [1.2.276.0.7230010.3.0.3.6.1] # 28, 1 ImplementationClassUID
(0002,0013) SH [OFFIS_DCMTK_361] # 16, 1 ImplementationVersionName
(0008,0016) UI =CTImageStorage # 26, 1 SOPClassUID
(0008,0018) UI [2.25.331769806794449124647336358989518081197] # 44, 1 SOPInstanceUID
(0008,0020) DA (no value available) # 0, 0 StudyDate
(0008,0023) DA (no value available) # 0, 0 ContentDate
(0008,0030) TM (no value available) # 0, 0 StudyTime
(0008,0033) TM (no value available) # 0, 0 ContentTime
(0008,0050) SH (no value available) # 0, 0 AccessionNumber
(0008,0090) PN (no value available) # 0, 0 ReferringPhysicianName
(0010,0010) PN [Unspecified Patient] # 20, 1 PatientName
(0010,0020) LO [2.25.243620553260306785155209470923857464493] # 44, 1 PatientID
(0010,0030) DA (no value available) # 0, 0 PatientBirthDate
(0010,0040) CS (no value available) # 0, 0 PatientSex
(0020,000d) UI [2.25.243620553339534947668832889995431251117] # 44, 1 StudyInstanceUID
(0020,000e) UI [2.25.243620553418763110181073985456379006125] # 44, 1 SeriesInstanceUID
(0020,0010) SH (no value available) # 0, 0 StudyID
(0020,0011) IS [1] # 2, 1 SeriesNumber
(0020,0012) IS [1] # 2, 1 AcquisitionNumber
(0020,0032) DS [0.500000\0.500000\15.123078] # 28, 3 ImagePositionPatient
(0020,0037) DS [1.000000\0.000000\0.000000\0.000000\1.000000\0.000000] # 54, 6 ImageOrientationPatient
(0028,0002) US 1 # 2, 1 SamplesPerPixel
(0028,0004) CS [MONOCHROME2] # 12, 1 PhotometricInterpretation
(0028,0010) US 1443 # 2, 1 Rows
(0028,0011) US 1214 # 2, 1 Columns
(0028,0030) DS [0.027055\0.027055] # 18, 2 PixelSpacing
(0028,0100) US 16 # 2, 1 BitsAllocated
(0028,0101) US 16 # 2, 1 BitsStored
(0028,0102) US 15 # 2, 1 HighBit
(0028,0103) US 0 # 2, 1 PixelRepresentation
(0028,1052) DS [0.000000] # 8, 1 RescaleIntercept
(0028,1053) DS [1.000000] # 8, 1 RescaleSlope
(7fe0,0010) OW 128a\1188\1162\12a4\1396\13c6\13cf\1487\13fb\1221\10b7\11fe\132e… # 3503604, 1 PixelData

1 Like
5

@Chris_Rorden Thanks for the analysis, your help in investigating DICOM issues is greatly appreciated.

@Norbert If you have control over the DICOM creation process then I would suggest to follow recommendations of @Chris_Rorden. For a quick fix, you may be able to add all missing required fields by using DICOM Patcher module.

1 Like
6

Dear all,

thank you very much for your advice. As a matter of fact, copying the data to a new folder getting rid of non-ASCII characters
in the directory names solved the problem.

With kind regards

Norbert

1 Like