# Failure to load DICOM Data

**URL:** <https://discourse.slicer.org/t/failure-to-load-dicom-data/8534>\
**Category:** Support\
**Created:** [September 23, 2019, 11:39am UTC](https://discourse.slicer.org/t/failure-to-load-dicom-data/8534 "2019-09-23T11:39:10Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Norbert](https://avatars.discourse-cdn.com/v4/letter/n/f6c823/32.png) [@Norbert](https://discourse.slicer.org/u/Norbert)\
**Post date:** [September 23, 2019, 11:39am UTC](https://discourse.slicer.org/t/failure-to-load-dicom-data/8534/1 "2019-09-23T11:39:11Z")

</div>

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

> **[Slicer](https://www.dropbox.com/sh/w2650ns9hs22tq1/AAC57MN3sm7bVyFPmPgfzA34a?dl=0)**
>
> Shared with Dropbox

---

<div class="post-metadata">

**Author:** ![Chris\_Rorden](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/chris_rorden/32/4073_2.png) [@Chris\_Rorden](https://discourse.slicer.org/u/Chris_Rorden)\
**Post date:** [September 23, 2019, 2:13pm UTC](https://discourse.slicer.org/t/failure-to-load-dicom-data/8534/2 "2019-09-23T14:13:03Z")

</div>

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”

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [September 23, 2019, 2:24pm UTC](https://discourse.slicer.org/t/failure-to-load-dicom-data/8534/3 "2019-09-23T14:24:12Z")

</div>

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](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/a/5/a5ca0e0251d3bd2eae0647419f9e7ac682e99ace.png)

---

<div class="post-metadata">

**Author:** ![Chris\_Rorden](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/chris_rorden/32/4073_2.png) [@Chris\_Rorden](https://discourse.slicer.org/u/Chris_Rorden)\
**Post date:** [September 23, 2019, 2:43pm UTC](https://discourse.slicer.org/t/failure-to-load-dicom-data/8534/4 "2019-09-23T14:43:57Z")

</div>

@Norbert the unique identifiers (UIDs) in your images end with the space character. This is not [allowed](http://dicom.nema.org/dicom/2013/output/chtml/part05/sect_6.2.html);

> 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

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [September 23, 2019, 2:49pm UTC](https://discourse.slicer.org/t/failure-to-load-dicom-data/8534/5 "2019-09-23T14:49:30Z")

</div>

@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](https://slicer.readthedocs.io/en/latest/user_guide/module_dicompatcher.html) module.

---

<div class="post-metadata">

**Author:** ![Norbert](https://avatars.discourse-cdn.com/v4/letter/n/f6c823/32.png) [@Norbert](https://discourse.slicer.org/u/Norbert)\
**Post date:** [September 24, 2019, 3:29pm UTC](https://discourse.slicer.org/t/failure-to-load-dicom-data/8534/6 "2019-09-24T15:29:45Z")

</div>

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