# DICOM images out of order

**URL:** <https://discourse.slicer.org/t/dicom-images-out-of-order/22247>\
**Category:** Support\
**Tags:** dicom\
**Created:** [March 1, 2022, 7:26pm UTC](https://discourse.slicer.org/t/dicom-images-out-of-order/22247 "2022-03-01T19:26:21Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![carlosar](https://avatars.discourse-cdn.com/v4/letter/c/49beb7/32.png) [@carlosar](https://discourse.slicer.org/u/carlosar)\
**Post date:** [March 1, 2022, 7:26pm UTC](https://discourse.slicer.org/t/dicom-images-out-of-order/22247/1 "2022-03-01T19:26:21Z")

</div>

Operating system: Linux, Ubuntu 20.04  
Slicer version: 4.11.20210226  
Expected behavior:  
When loading a DICOM database from the root folder, the order of the images is not inferred from `(0020, 0013) Instance Number` tag, however, when loading the first image in the series via the drag and drop functionality, the order is preserved.

Actual behavior: Not sure if this is expected behavior, since the discussion on ordering below indicates that the sorted images depend on having some geometry tags.

I do get the warning about this from this function:

> <https://github.com/Slicer/Slicer/blob/3de75b9c4c6f3ee9a1e5da17059b9f11517e16ab/Modules/Scripted/DICOMLib/DICOMUtils.py#L567>

Similar discussions:

> [@Slice order in dicom loader](https://discourse.slicer.org/t/slice-order-in-dicom-loader/15129):
>
> Hi, I wanted to confirm the mechanism with which Slicer orders dicom slices. I need the slice order (basically z-coordinate value) with filenames to write to csv for my application use and I found that the examineFiles function in DICOMScalarVolumePlugin.py uses getSortedImageFiles function DICOMUtils.py to order them. I wanted to know whether is this the Slicer’s backend for showing ordered slices in Slicer viewer so I can call this examineFiles function to get array of sorted files and inde…

> [@What determines DICOM import "Image Type" ordering?](https://discourse.slicer.org/t/what-determines-dicom-import-image-type-ordering/11508):
>
> Hello, I am importing DICOM Dixon images and am getting inconsistent ordering of the image types. Slicer correctly identifies that there are 4 image types, but does not order them in a consistent way. Other software (e.g. Horos) consistently orders them. [Dixon images](https://radiopaedia.org/articles/dixon-method?lang=us) involve 4 series, a water image (W), a fat image (F), and two raw images from which the water and fat images are derived, one referred to as the in-phase (IP) and the other referred to as the opposite-phase (OP). Horos consist…

Is this expected behavior?

---

<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:** [March 1, 2022, 7:31pm UTC](https://discourse.slicer.org/t/dicom-images-out-of-order/22247/2 "2022-03-01T19:31:31Z")

</div>

Make sure you use the DICOM module to [load DICOM images](https://slicer.readthedocs.io/en/latest/user_guide/modules/dicom.html#read-dicom-files-into-the-scene). That module uses the correct DICOM tags (image position patient, image orientation patient) to reconstruct the 3D volume. `Instance number` must not be taken into account when reconstructing a 3D volume from slices.

We have not disabled ITK’s limited DICOM image reader that can be accessed via the “Add data” dialog (or drag-and-dropping the first file to the application window), but that reader should not be used.

---

<div class="post-metadata">

**Author:** ![carlosar](https://avatars.discourse-cdn.com/v4/letter/c/49beb7/32.png) [@carlosar](https://discourse.slicer.org/u/carlosar)\
**Post date:** [March 1, 2022, 8:43pm UTC](https://discourse.slicer.org/t/dicom-images-out-of-order/22247/3 "2022-03-01T20:43:15Z")

</div>

Thanks for the prompt response! I have been using the DICOM Module to load the image, but its possible the data I am using does not have the appropriate tags for orientation or pixel sizing.

When using the drag and drop, does this mean it is using ITK’s DICOM reader instead?

If so, then I guess ITK’s reader either uses the file name and/or `Instance Number` tag. Is this not recommended?

Since the order of the slices from the patient data I am using is missing the ones used by the DICOM module, would you suggest preprocessing to add the correct metadata to incorporate the correct tags? I am new to DICOM data, any advice would be appreciated!

---

<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:** [March 1, 2022, 9:05pm UTC](https://discourse.slicer.org/t/dicom-images-out-of-order/22247/4 "2022-03-01T21:05:13Z")

</div>

> [@carlosar](#):
>
> If so, then I guess ITK’s reader either uses the file name and/or `Instance Number` tag. Is this not recommended?

ITK reader used to sort the files by default but then a few years ago the behavior changed, and I think you now always need to sort the files before passing it to the reader (ITK provides helper methods for that). In Slicer, we have not invested time into fixing up DICOM loading via the “Add data” dialog, so I think now this methods loads the files unsorted (uses whatever order the files are found on the file system).

Our plan is to intercept DICOM file loading in “Add data” and redirect that to the DICOM module, but this has not been implemented yet:

> <https://github.com/Slicer/Slicer/issues/5726>
>
> DICOM import via "Add data" dialog has many limitations, such as cannot deal wit…h varying slice spacing, 4D volumes, cannot import any other objects than images, etc. and has issues, such as potentially loading the image in incorrectly slice order.
> 
> DICOM loading this way should be disabled and preferable replaced by importing via the DICOM module. To match the previous functionality more closely, the import should be done via a temporary DICOM database and should be fast (at least time to first image should be quick and simple).
> 
> \## Environment
> \- Slicer version: Slicer-4.11 and later
> \- Operating system: all

---

<div class="post-metadata">

**Author:** ![carlosar](https://avatars.discourse-cdn.com/v4/letter/c/49beb7/32.png) [@carlosar](https://discourse.slicer.org/u/carlosar)\
**Post date:** [March 1, 2022, 9:30pm UTC](https://discourse.slicer.org/t/dicom-images-out-of-order/22247/5 "2022-03-01T21:30:22Z")

</div>

Great thanks for the update.

I’ve played around more with loading the data using the DICOM module, and the order is now preserved, when selecting the root folder with all patient/study/series data, but when loading one series individually, the order is not preserved:

`./root/DICOM/PAT_0000/STD_0000/SER_00XY/OBJ_0001/`  
versus loading at the root

`./root`

in either case, the tag `Pixel Spacing` is not read properly.

Any thoughts on how to debug this? I assume its connected to the warning:

`No geometry information available for DICOM data, skipping corner calculations`

---

<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:** [March 1, 2022, 10:50pm UTC](https://discourse.slicer.org/t/dicom-images-out-of-order/22247/6 "2022-03-01T22:50:48Z")

</div>

You can enable `Detailed logging` in Application settings → DICOM to get some more information, but I’m not sure if you get more details if basic geometry fields are invalid/missing.

`Pixel Spacing` is stored as a decimal string. If it is ignored then it is typically because the string is invalid (e.g., you write leading or trailing spaces, incorrect decimal separator, etc.).

DICOM standard is complex and it is hard to create valid images. One way to address this is to have a look at a valid DICOM image that is similar to what you want to create to see what fields are usually set. Then read description of each field in the DICOM standard to see how you should set them for your images.