Edge cases of DICOMOrient

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?

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:

1 Like

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!

2 Likes