# Cranial and caudal directions are opposite when loading sequence of DICOM images

**URL:** <https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428>\
**Category:** Support\
**Tags:** dicom\
**Created:** [May 4, 2021, 1:43am UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428 "2021-05-04T01:43:23Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![xackey](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/xackey/32/10860_2.png) [@xackey](https://discourse.slicer.org/u/xackey)\
**Post date:** [May 4, 2021, 1:43am UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/1 "2021-05-04T01:43:23Z")

</div>

Hi.  
When loading sequence of DICOM images (“Load Data”\<\<Chose File(s) to Add"), loading order of files is different between version 4.10.2 and nightly version (4.13.0). I think version 4.10.2 is correct, but caudal and cranial directions are opposite in nightly version.

Can you solve this problem?

 ![fig1](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/6/b/6b9e602080c8cb3f1f384988246ab116dfee6b4d.jpeg)  
 ![fig2](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/7/b/7b3cb88bb76051a29a7d179c6f2fb3df289d9409.jpeg)

---

<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:** [May 4, 2021, 1:06pm UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/2 "2021-05-04T13:06:48Z")

</div>

What kind of scanner are these from? Did you load with the DICOM module or the load data dialog?

Is there any chance you can share data that reproduces this issue?

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [May 4, 2021, 4:27pm UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/3 "2021-05-04T16:27:27Z")

</div>

Probably the same (it is about how to sort slices if IPP/IOP is not available)

> <https://github.com/InsightSoftwareConsortium/ITK/issues/1587>
>
> \### Description
> 
> Some volumes are flipped along their Z axis (ordering of slic…es is inverted). Other axes are not inverted, so it is not a rotation but a mirroring along one axis. It worked well in the previous ITK 5 release.
> 
> !\[image\](https://user-images.githubusercontent.com/307929/73612832-5d9e1c80-45bd-11ea-9fcf-996f745d2c9e.png)
> 
> \### Steps to Reproduce
> 
> Load the DICOM volume using ITK-5.0 and ITK-5.1rc01 and compare them in a sagittal view.
> 
> \### Expected behavior
> 
> They should look the same.
> 
> \### Actual behavior
> 
> There is a flip along the IS axis.
> 
> \### Reproducibility
> 
> I can provide an anonymized data set on request but it is not for public sharing.
> 
> \### Versions
> 
> ITK-v5.1rc01
> 
> \### Environment
> 
> Windows, Visual Studio 2015

---

<div class="post-metadata">

**Author:** ![xackey](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/xackey/32/10860_2.png) [@xackey](https://discourse.slicer.org/u/xackey)\
**Post date:** [May 4, 2021, 9:15pm UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/4 "2021-05-04T21:15:46Z")

</div>

@issakomi  
Yes! This is the same problem.

---

<div class="post-metadata">

**Author:** ![xackey](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/xackey/32/10860_2.png) [@xackey](https://discourse.slicer.org/u/xackey)\
**Post date:** [May 5, 2021, 12:36am UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/5 "2021-05-05T00:36:04Z")

</div>

@pieper

1. The CT scanner is from Siemens, but the same problem happened on Toshiba CT. So, this problem is not related to the kind of CT scanner.
2. I used “Load Data” (not “Load DICOM Data”). But when I loaded images using “Load DICOM Data”, image orientation (z direction) became correct.
3. When I renamed the DICOM files in reverse order (i.e., change from 1, 2, 3, 4 to 4, 3, 2, 1), ordering of slices was inverted (changed from inverted view to correct view). So, maybe this problem is related to loading order of image files.

---

<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:** [May 5, 2021, 10:28pm UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/6 "2021-05-05T22:28:28Z")

</div>

@xackey, does the Slicer DICOM module warn you about geometry issues with this data?

If it’s really the case that ITK is using the file name rather than the Image Position Patient tags in the dicom header to sort the images this is a terrible regression. I haven’t really thought about it since the discussion on the ITK issue tracker last summer, but I’m really surprised this hasn’t been fixed. @lassoan what do you think?

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [May 6, 2021, 12:01am UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/7 "2021-05-06T00:01:44Z")

</div>

> [@pieper](#):
>
> If it’s really the case that ITK is using the file name rather than the Image Position Patient tags in the dicom header to sort the images this is a terrible regression.

In GDCM _IPP/IOP_ ordering is the first choice (there is also an option for user-derined ordering, but is unused), if it fails then _Image Number_ tag is used, if it fails too then file names. The change was to use _Image Number_. There is a link to GDCM commit in ITK issue discussion above.

S. [gdcmSerieHelper.cxx](https://github.com/InsightSoftwareConsortium/ITK/blob/0de9cfe31d42b4a5640e2baae494e99eccdcf347/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmSerieHelper.cxx#L430)

---

<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:** [May 6, 2021, 1:38am UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/8 "2021-05-06T01:38:36Z")

</div>

I could not reproduce the flipping issue by specifying a single DICOM file for ITK. Slicer’s frame sorter works well, too. The problem only occurs when somebody uses the “Add data” dialog in Slicer to load DICOM data - it somehow uses the ITK DICOM reader in an incorrect way.

I’ve never really understood how DICOM loading via “Add data” dialog is supposed to work and why it is so complex. I think the best would be to remove this loading method, as it has many other limitations anyway.

---

<div class="post-metadata">

**Author:** ![xackey](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/xackey/32/10860_2.png) [@xackey](https://discourse.slicer.org/u/xackey)\
**Post date:** [May 6, 2021, 2:39am UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/9 "2021-05-06T02:39:23Z")

</div>

@pieper

> > does the Slicer DICOM module warn you about geometry issues with this data?  
> > →Do you mean viewing a “Error log”? I show a log after loading the DICOM files.
> > 
> > ![log](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/0/c/0c51c7dccddec8eeee5b00d1b9aa3f2d84c0e94d.jpeg)

If this problem can be resolved by changing application settings of 3D Slicer, could you tell me how to do it.  
Thank you!

---

<div class="post-metadata">

**Author:** ![xackey](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/xackey/32/10860_2.png) [@xackey](https://discourse.slicer.org/u/xackey)\
**Post date:** [May 6, 2021, 9:57am UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/10 "2021-05-06T09:57:06Z")

</div>

I tried public DICOM images, but I have the same result; version 4.10.2 is correct view, but 4.13.0 is flipped.

 ![Fig3](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/c/8/c8e689afd78be1d6ad2494794c5d5f2c6be6e54b.jpeg)

I attached the link of the DICOM images below. Could you check whether the issue will be reproduced?

[https://drive.google.com/drive/folders/14s0U2WJyVQ0u-Ni5U8ulet0Yy0fAccZc?usp=sharing](https://drive.google.com/drive/folders/14s0U2WJyVQ0u-Ni5U8ulet0Yy0fAccZc?usp=sharing)

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [May 6, 2021, 6:11pm UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/11 "2021-05-06T18:11:32Z")

</div>

I could not reproduce the problem in Slicer (and in my app too).

 ![Screenshot at 2021-05-06 20-04-56](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/5/c/5c5d427e407568378dd5ec20245ce59268a46fce.jpeg)

Edit:

@xackey

Oops, i have reproduced, in fact, with “Load Data” dialog (select a folder)

 ![Screenshot at 2021-05-06 20-30-20](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/d/e/de632dca7193bbc3f42876053664e2a1716dee2d.png)

---

<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:** [May 6, 2021, 7:18pm UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/12 "2021-05-06T19:18:54Z")

</div>

> [@lassoan](#):
>
> I think the best would be to remove this loading method, as it has many other limitations anyway.

Yes, I think now (as part of slicer5) we stop letting people load dicom via that legacy Add Data code. For now I would at least way we should consider it ill-advised.

I’d still argue this must be a regression in ITK because the dataset that reproduces the issue _does_ have valid ImagePostiionPatient values that Slicer is able to parse, but for some reason the newer ITK ignores in favor of using the filenames. Very odd.

---

<div class="post-metadata">

**Author:** ![xackey](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/xackey/32/10860_2.png) [@xackey](https://discourse.slicer.org/u/xackey)\
**Post date:** [May 6, 2021, 10:51pm UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/13 "2021-05-06T22:51:43Z")

</div>

@issakomi  
Thank you for trying.  
Version 4.10.2 has no such issue even when choosing “Load Data” dialog.  
I think there is something difference in data loading systems between version 4.10.2 and 4.13.0.

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [May 7, 2021, 8:18am UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/14 "2021-05-07T08:18:03Z")

</div>

> [@pieper](#):
>
> I’d still argue this must be a regression in ITK

This ITK example - [ReadDICOMSeriesAndWrite3DImage](https://itk.org/ITKExamples/src/IO/GDCM/ReadDICOMSeriesAndWrite3DImage/Documentation.html) works fine, sorted by IPP as expected. I have tried C++ version with ITK master and above data set, result - _nrrd_ file - is correct. [Here](https://drive.google.com/file/d/1aWd_liUnb6ladsU8afm12ZrNxqUPlz7G/view?usp=sharing) is this example with cmake and data set shared above.

I have also compared _vtkITKArchetypeImageSeriesReader.cxx_ from [4.10.2](https://drive.google.com/file/d/1sWyKERmISARtTdFIQ-VTuKzq_dLOfT80/view?usp=sharing) and from [master](https://drive.google.com/file/d/1yxWxpm_UrloCnYuHGnL8EiHpqM3skfGD/view?usp=sharing), they are very different. 100+ lines were changed, specially parts related to DICOM were updated.

I am still not sure what the problem is. I am building Slicer, may be i shall find the source of the problem and report.

---

<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:** [May 7, 2021, 12:13pm UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/15 "2021-05-07T12:13:06Z")

</div>

Thanks very much for your help with this @issakomi 🙏

---

<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:** [May 7, 2021, 1:51pm UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/16 "2021-05-07T13:51:27Z")

</div>

I can confirm that ITK examples work well, that’s why I did not ask ITK developers to investigate this change in behavior. There is something special about how Slicer uses ITK’s DICOM reader, and considering how complex that code part is, it is quite possible that Slicer does not use the API correctly.

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [May 7, 2021, 1:52pm UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/17 "2021-05-07T13:52:16Z")

</div>

@pieper You’re welcome.

Highly likely the problem is in _vtkITKArchetypeImageSeriesReader.cxx_, i have built Slicer _master_ and have done very quick and dirty port of that file (and .h file) from 4.10.2 (only added things related to new _VoxelVectorType_). And there is no flip. I shall try to find out what exactly is the issue, but it can take several days, and confirm if it will work.  
Here is tiny (20 s) video:

[![](https://img.youtube.com/vi/f0uDJ4CUhDo/maxresdefault.jpg "Test") ](https://www.youtube.com/watch?v=f0uDJ4CUhDo)

---

<div class="post-metadata">

**Author:** ![issakomi](https://avatars.discourse-cdn.com/v4/letter/i/b9e5f3/32.png) [@issakomi](https://discourse.slicer.org/u/issakomi)\
**Post date:** [May 8, 2021, 8:36pm UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/18 "2021-05-08T20:36:59Z")

</div>

This bug is in Slicer since [commit](https://github.com/Slicer/Slicer/commit/cbaaa0182974352736b0567cc0eeaff49813d578) 12 Jan 2020. New function [itk::ImageIOBase::Pointer vtkITKArchetypeImageSeriesReader::GetImageIO](https://github.com/Slicer/Slicer/blob/6a9cb52eb1a93b031c7388ee5688a28a709fa7b4/Libs/vtkITK/vtkITKArchetypeImageSeriesReader.cxx#L206) was added. In the function a list of files is [assembled](https://github.com/Slicer/Slicer/blob/6a9cb52eb1a93b031c7388ee5688a28a709fa7b4/Libs/vtkITK/vtkITKArchetypeImageSeriesReader.cxx#L230) before check for DICOM IO. And [later](https://github.com/Slicer/Slicer/blob/6a9cb52eb1a93b031c7388ee5688a28a709fa7b4/Libs/vtkITK/vtkITKArchetypeImageSeriesReader.cxx#L384), in _vtkITKArchetypeImageSeriesReader::RequestInformation_, the [point](https://github.com/Slicer/Slicer/blob/6a9cb52eb1a93b031c7388ee5688a28a709fa7b4/Libs/vtkITK/vtkITKArchetypeImageSeriesReader.cxx#L412), where itk::GDCMSeriesFileNames is called, is not reached.  
`// if user already set up FileNames, we do not try to find candidate files if ( this->GetNumberOfFileNames() > 0 )`

---

<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:** [May 8, 2021, 8:53pm UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/19 "2021-05-08T20:53:15Z")

</div>

Nice detective work!

This sounds fixable, but we should still consider removing the option to load dicom via that class. That archetype series code is so hard to maintain and it surely needs a redesign after so many years of patching.

---

<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:** [May 10, 2021, 1:03am UTC](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428/21 "2021-05-10T01:03:50Z")

</div>

@issakomi, thanks a lot for this investigation!

It seems that we have 3 slice sorting implementations:

- GDCM: probably robust but most likely it only supports simple cases (e.g., cannot handle 4D volumes with variable spacing)
- vtkITKArchetypeImageSeriesReader: very basic implementation, not robust and currently broken. It can be fixed with [these changes](https://github.com/Slicer/Slicer/commit/3c92804fa88ca19a6867d518181aef51b31d330d), but it would require much more work.
- DICOMScalarVolumePlugin (and other plugins for 2D+t, 3D+t, etc.): can handle very complex cases. It uses vtkITKArchetypeImageSeriesReader to load a file list.

Potential next steps:

- We should remove the sorter in vtkITKArchetypeImageSeriesReader to reduce redundancy and maintenance workload.
- We should also simplify and fix vtkITKArchetypeImageSeriesReader and all subclasses to make errors such as this one easier to avoid in the future. Probably merge all subclasses (vtkITKArchetypeDiffusionTensorImageReaderFile, vtkITKArchetypeImageSeriesReader, vtkITKArchetypeImageSeriesScalarReader, vtkITKArchetypeImageSeriesVectorReaderFile, vtkITKArchetypeImageSeriesVectorReaderSeries) in a single class replace macros by templated functions, etc.
- To reduce chance of use errors, we should probably redirect users to the DICOM module for loading DICOM data. Maybe the image reader plugin could detect DICOM data sets and import them to the DICOM database.

@pieper @jcfr @cpinter @fedorov What do you think?

[Next page](https://discourse.slicer.org/t/cranial-and-caudal-directions-are-opposite-when-loading-sequence-of-dicom-images/17428.md?page=2)