# Edge cases of DICOMOrient

**URL:** https://discourse.itk.org/t/edge-cases-of-dicomorient/7559
**Category:** Algorithms
**Tags:** python, orientation, dicom, simpleitk
**Created:** [June 5, 2025, 7:55am UTC](https://discourse.itk.org/t/edge-cases-of-dicomorient/7559 "2025-06-05T07:55:49Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![ahulist](https://discourse.itk.org/user_avatar/discourse.itk.org/ahulist/32/4509_2.png) [@ahulist](https://discourse.itk.org/u/ahulist)
#### Post date: [June 5, 2025, 7:55am UTC](https://discourse.itk.org/t/edge-cases-of-dicomorient/7559/1 "2025-06-05T07:55:50Z")

</div>

I’m using SimpleITK’s `DICOMOrient` to reorient a stack of DICOM slices. When I read files as a simple list (instead of using `ImageSeriesReader`), SITK only uses the first slice’s Origin/Spacing and infers the rest on the fly. In my case, the series was in LPS– (Z positions ran from –180 to –60), but because the first slice had Z = –60, SITK assumed subsequent slices must increase in Z (LPS+) and reordered them incorrectly. Switching to `ImageSeriesReader.GetGDCMSeriesFileNames(...)` fixes orientation automatically.

Are there other edge cases or pitfalls of `DICOMOrient` on DICOM series that I might be unaware of and should watch out for?

---

<div class="post-metadata">

### Author: ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [June 5, 2025, 12:38pm UTC](https://discourse.itk.org/t/edge-cases-of-dicomorient/7559/2 "2025-06-05T12:38:55Z")

</div>

Hello,

Are you able to share your DICOM series?

There are 3 steps here to look at:

- input list to the ImageSeriesReader
- the meta-data of the read image e.g. Direciton cosine matrix, Origin and Spacing
- the DICOMOrient behavior

I am not sure what you mean by “read files as a simple list”, and how that compares to the list generated by `GetGDCMSeriesFileNames`. The series reader does not reorder the list, is uses what is provided, so the difference between these approaches likely originates here.

The following issue and PR seem related:

> <https://github.com/SimpleITK/SimpleITK/issues/2292>
>
> \*\*Describe the bug\*\*
> 
> I have the a series comprising 413 dicom slices the "Image…PositionPatient" tag for the slices are :
> slice 1 : -216.500 \\ -216.500 \\ 70.000
> slice 2: -216.500 \\ -216.500 \\ 68.750
> .....
> slice 413 : -216.500 \\ -216.500 \\ -445.000
> 
> The "ImageOrientation" is the same for all tags : 
> (0020,0037)	Image Orientation Patient	1.000000\\0.000000\\0.000000\\0.000000\\1.000000\\0.000000
> 
> I read these slices with the Image Series Reader:
> \`\`\`
> reader = sitk.ImageSeriesReader()
> reader.SetFileNames(dcm\_list)
> image = reader.Execute()
> \`\`\`
> 
> Reading the slice from the last to the first (bottom to top), the metadata of the final 3d image is inconsistant with the values of the dicom tags :
> image.GetOrigin() -\> (-216.5, -216.5, -445.0) seems OK
> image.GetDirection() -\> (1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, -1.0) not OK last vector should be 1 instead of -1
> 
> if I put the slices from the first to the last I get correct results :
> image.GetOrigin() -\>(-216.5, -216.5, 70.0) seems OK
> image.GetDirection() -\> (1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, -1.0) now it is OK since we are reading from top to bottom
> 
> so depending on the order of the slice given, one give a coherent result in term of metadata and the other does not. 
> 
> My understanding was that the code computed the 3d direction matrix with both the "image orientation" for the first two axes, and the vector defined by the vector separing the "image position patient" of the two first slice given. In that case it should be 0 / 0 / 1 when reading the image from bottom to top and 0 / 0 / -1 from top to bottom but last vector is always 0 / 0 / -1
> 
> 
> \*\*To Reproduce\*\*
> Hard to reproduce without sharing the dcm files itself, on request it can be done
> 
> Thanks !
> 
> Here are the full information of the final 3d image for reference :
> \`\`\`
> 
> Image (0x40bcd700)
> RTTI typeinfo: itk::Image\<int, 3u\>
> Reference Count: 1
> Modified Time: 16338
> Debug: Off
> Object Name:
> Observers:
> none
> Source: (none)
> Source output name: (none)
> Release Data: Off
> Data Released: False
> Global Release Data: Off
> PipelineMTime: 1807
> UpdateMTime: 16334
> RealTimeStamp: 0 seconds
> LargestPossibleRegion:
> Dimension: 3
> Index: \[0, 0, 0\]
> Size: \[512, 512, 413\]
> BufferedRegion:
> Dimension: 3
> Index: \[0, 0, 0\]
> Size: \[512, 512, 413\]
> RequestedRegion:
> Dimension: 3
> Index: \[0, 0, 0\]
> Size: \[512, 512, 413\]
> Spacing: \[0.845703, 0.845703, 1.25\]
> Origin: \[-216.5, -216.5, -445\]
> Direction:
> 1 0 0
> 0 1 0
> 0 0 -1
> 
> IndexToPointMatrix:
> 0.845703 0 0
> 0 0.845703 0
> 0 0 -1.25
> 
> PointToIndexMatrix:
> 1.18245 0 0
> 0 1.18245 0
> 0 0 -0.8
> 
> Inverse Direction:
> 1 0 0
> 0 1 0
> 0 0 -1
> 
> PixelContainer:
> ImportImageContainer (0x40f65de0)
> RTTI typeinfo: itk::ImportImageContainer\<unsigned long, int\>
> Reference Count: 1
> Modified Time: 1875
> Debug: Off
> Object Name:
> Observers:
> none
> Pointer: 0x7fdb14418010
> Container manages memory: true
> Size: 108265472
> Capacity: 108265472
> \`\`\`

> <https://github.com/InsightSoftwareConsortium/ITK/pull/5357>
>
> If the spacing between slices is negative, then direction cosine matrix was not …correct with reguards to the sign.
> 
> 
> 
> 
> 
> 
> \## PR Checklist
> \- \[\] No \[API changes\](https://github.com/InsightSoftwareConsortium/ITK/blob/master/CONTRIBUTING.md#breaking-changes) were made (or the changes have been approved)
> \- \[\] No \[major design changes\](https://github.com/InsightSoftwareConsortium/ITK/blob/master/CONTRIBUTING.md#design-changes) were made (or the changes have been approved)
> \- \[\] Added test (or behavior not changed)
> \- \[\] Updated API documentation (or API not changed)
> \- \[\] Added \[license\](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Utilities/KWStyle/ITKHeader.h) to new files (if any)
> \- \[\] Added Python wrapping to new files (if any) as described in \[ITK Software Guide\](https://itk.org/ItkSoftwareGuide.pdf) Section 9.5
> \- \[\] Added \[ITK examples\](https://github.com/InsightSoftwareConsortium/ITKSphinxExamples) for all new major features (if any)
> 
> Refer to the \[ITK Software Guide\](https://itk.org/ItkSoftwareGuide.pdf) for
> further development details if necessary.

---

<div class="post-metadata">

### Author: ![ahulist](https://discourse.itk.org/user_avatar/discourse.itk.org/ahulist/32/4509_2.png) [@ahulist](https://discourse.itk.org/u/ahulist)
#### Post date: [June 5, 2025, 11:22pm UTC](https://discourse.itk.org/t/edge-cases-of-dicomorient/7559/3 "2025-06-05T23:22:39Z")

</div>

As it turns out `sorted(glob.glob('*.dcm'))` is definitely not good enough. Switching to `sitk.ImageSeriesReader.GetGDCMSeriesFileNames` as a source for `sitk.ImageSeriesReader().SetFileNames(files_list)` fixed the issue.

Thank you for the assistance!
