# Loading DICOM files

**URL:** <https://discourse.slicer.org/t/loading-dicom-files/11995>\
**Category:** Development\
**Created:** [June 11, 2020, 9:37pm UTC](https://discourse.slicer.org/t/loading-dicom-files/11995 "2020-06-11T21:37:20Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![nsbosse](https://avatars.discourse-cdn.com/v4/letter/n/a183cd/32.png) [@nsbosse](https://discourse.slicer.org/u/nsbosse)\
**Post date:** [June 11, 2020, 9:37pm UTC](https://discourse.slicer.org/t/loading-dicom-files/11995/1 "2020-06-11T21:37:21Z")

</div>

Hi there, I have a few questions regarding the process for loading DICOM files.

Does Slicer’s DICOM reader apply the rescale slope/intercept prior to loading the intensity values into memory? What is the fallback strategy in the case when the DICOM header does not contain or has illegal rescale slope/intercept values?

Also, which class/method is responsible for loading DICOM images from disk? So far, I believe I’ve followed the code correctly from the AddArchetypeScalarVolume method in the vtkSlicerVolumesLogic.cxx file through to the ReadDataInternal method in the vtkMRMLVolumeArchetypeStorageNode class. It looks like there’s a vtkITKArchetypeImageSeriesReader that may load the data. Am I on the right track?

Thanks

---

<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:** [June 11, 2020, 11:50pm UTC](https://discourse.slicer.org/t/loading-dicom-files/11995/2 "2020-06-11T23:50:06Z")

</div>

Hi -

Yes, you are on exactly the right track for scalar volumes. Slicer uses ITK to do the read, and if if there is rescale info in the header it is used. If not I guess the values go straight through unchanged (you could check), but it’s a required tag so technically behavior is undefined.

Note that slicer lets you pick the GDCM or DCMTK implementations of ITK dicom, so the behavior might be slightly different (or rather, it is sometimes different in that they handle some border cases differently and that’s why we give you the option).

Note also that DICOMPlugin classes may interpret certain dicom instances differently, e.g. diffusion scans or segmentations, but the DICOMScalarVolume plugin uses the code you cited.

---

<div class="post-metadata">

**Author:** ![nsbosse](https://avatars.discourse-cdn.com/v4/letter/n/a183cd/32.png) [@nsbosse](https://discourse.slicer.org/u/nsbosse)\
**Post date:** [June 12, 2020, 2:23am UTC](https://discourse.slicer.org/t/loading-dicom-files/11995/3 "2020-06-12T02:23:53Z")

</div>

That’s helpful. Thanks a lot!  
Do you happen to know, would it be the DCMTKImageIO and GDCMImageIO classes that are responsible for doing the read from disk at the lowest level? I do see a read method in both classes, but I’m yet sure where they would be called from, so not positive yet.

---

<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:** [June 12, 2020, 12:10pm UTC](https://discourse.slicer.org/t/loading-dicom-files/11995/4 "2020-06-12T12:10:53Z")

</div>

Yes, those are the classes that are used in the end. I agree the many layers can be quite hard to follow and reason about. I suggest putting some breakpoints in those read methods and tracing through a bit to see what’s going on.

Do you have a particular issue you are investigating, or just learning?

---

<div class="post-metadata">

**Author:** ![nsbosse](https://avatars.discourse-cdn.com/v4/letter/n/a183cd/32.png) [@nsbosse](https://discourse.slicer.org/u/nsbosse)\
**Post date:** [June 12, 2020, 3:11pm UTC](https://discourse.slicer.org/t/loading-dicom-files/11995/5 "2020-06-12T15:11:09Z")

</div>

Perfect. Thanks again. Personally, I’m learning. I’m a computer science co-op student. I’ve been trying to help my teammates verify some specifics about how DICOM files are loaded by studying the code from the point where it enters the C++ realm.