# DICOM multiframe support

**URL:** <https://discourse.slicer.org/t/dicom-multiframe-support/4806>\
**Category:** Development\
**Tags:** dicom\
**Created:** [November 19, 2018, 3:58pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806 "2018-11-19T15:58:30Z")\
**Posts on this page:** 20\
**Page:** 1

<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:** [November 19, 2018, 3:58pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/1 "2018-11-19T15:58:31Z")

</div>

This thread contains a link to a dicom multiframe object David Clunie created. @fedorov reports that it doesn’t load correctly in Slicer.

[https://groups.google.com/forum/?utm\_medium=email&utm\_source=footer#!msg/dicom4qi/BD9i2lUklvU/TN\_gRgSFBgAJ](https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/dicom4qi/BD9i2lUklvU/TN_gRgSFBgAJ)

My thinking is that we should write a DICOMMultframePlugin that detects the multiframe SOPClassUIDs and loads them directly, probably using pydicom and custom logic that detects volume geometry (or MultiVolume / Sequence geometry). Ideally the core logic of this sorting should be independent of Slicer it can be re-used in other pydicom applications. The Plugin would be a thin wrapper on this logic.

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [November 19, 2018, 4:08pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/2 "2018-11-19T16:08:21Z")

</div>

Would it be a complete heresy to bundle [dcm2niix](https://github.com/rordenlab/dcm2niix) and use that for conversion?

Alternatively, we should look if we can perhaps reuse plastimatch, already bundled in SlicerRT, at least as an alternative parsing strategy. I did try it for this specific multiframe dataset, and I could not figure out quickly how to make it work, but maybe we should just check with @gcsharp.

I am just not convinced it is a good investment of effort to reimplement this functionality (and to assemble a good test dataset).

---

<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:** [November 19, 2018, 4:31pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/3 "2018-11-19T16:31:21Z")

</div>

> [@fedorov](#):
>
> Would it be a complete heresy to bundle [dcm2niix](https://github.com/rordenlab/dcm2niix) and use that for conversion?

That would be great actually - it looks like the license if compatible. We could start by adding this as an extension and then if it works well make it part of the Slicer distribution. From what I can tell the [dcm2niix license](https://github.com/rordenlab/dcm2niix/blob/master/license.txt) is compatible.

As an aside, I also like the look of the [MIRcroGL renderer](https://www.mccauslandcenter.sc.edu/mricrogl/) - could make an interesting extension tool.

---

<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:** [November 19, 2018, 5:00pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/4 "2018-11-19T17:00:45Z")

</div>

Is it a simple 3D volume? Shouldn’t we report the error to ITK developers and ask them to fix multiframe support? It should not be difficult.

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [November 19, 2018, 6:20pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/5 "2018-11-19T18:20:06Z")

</div>

> [@lassoan](#):
>
> Shouldn’t we report the error to ITK developers and ask them to fix multiframe support? It should not be difficult.

I think I already reported some of those on Jira, this issue came up before, but now that ITK Jira is gone, no way to confirm…

Based on a discussion here: [Slicer DICOM Scalar volume plugin relies on (old) GDCM: why do we not use DCMTK? - #24 by pieper](https://discourse.slicer.org/t/slicer-dicom-scalar-volume-plugin-relies-on-old-gdcm-why-do-we-not-use-dcmtk/354/24), looks like the “home” for ITK DICOM development is [GitHub - KitwareMedical/ITKDICOM: Better support for DICOM in ITK.](https://github.com/KitwareMedical/ITKDICOM), but I do not see a lot of activity there, and there are issues open since 2017. Not clear if ITK community prioritized DICOM support over many competing interests. I am sure something like “deep learning in ITK” would be much higher on the list! 😃

---

<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:** [November 19, 2018, 6:55pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/6 "2018-11-19T18:55:03Z")

</div>

I would be happy with any of these solutions (pydicom, dcm2niix, ITK or others) - whatever works well and is maintained and has a compatible license.

Ideally the DICOMPlugin layer of Slicer shouldn’t contain any of the actual logic, just adaptors to turn a well defined set of DICOM data into the corresponding Slicer (MRML) objects.

---

<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:** [November 19, 2018, 7:37pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/8 "2018-11-19T19:37:30Z")

</div>

@Mihail_Isakov - agreed, it’s a messy business! In Slicer we allow multiple plugins to evaluate the data and offer different reader options for the user to select from (each with a “confidence” so the user can just choose the highest confidence by default). But it’s an imperfect mapping so we are always looking for ways to improve things.

---

<div class="post-metadata">

**Author:** ![thewtex](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/thewtex/32/32_2.png) [@thewtex](https://discourse.slicer.org/u/thewtex)\
**Post date:** [November 19, 2018, 8:32pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/9 "2018-11-19T20:32:24Z")

</div>

> [@fedorov](#):
>
> > Shouldn’t we report the error to ITK developers and ask them to fix multiframe support? It should not be difficult.
> 
> I think I already reported some of those on Jira, this issue came up before, but now that ITK Jira is gone, no way to confirm…

ITK’s Jira Issue Tracker is dead. Long live [ITK’s GitHub Issue Tracker](https://github.com/InsightSoftwareConsortium/ITK/issues)! 👑

If there are issues with ITK’s reading of multi-frame DICOM files, please report it there. To the best of my knowledge, reading multi-frame DICOM volumes works well.

The old [Jira issue tracker](https://insightsoftwareconsortium.atlassian.net/projects/ITK/issues/ITK-3546?filter=allopenissues) is still available – if there is a relevant issue that you find important, please migrate them to the GitHub issue tracker.

> [@fedorov](#):
>
> Not clear if ITK community prioritized DICOM support over many competing interests. I am sure something like “deep learning in ITK” would be much higher on the list! 😃

Deep learning is wonderful, and ITK helps apply deep learning methods to medical imaging data. To perform deep learning on medical imaging data, we definitely need good DICOM support!

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [November 19, 2018, 10:47pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/11 "2018-11-19T22:47:54Z")

</div>

@thewtex thanks for the response!

I thought it is probably not very helpful if I submit an issue demonstrating the problem in Slicer, since there are potentially other sources of error, so I wanted to reproduce the problem with ITK.

I googled for “itk read dicom series”, and came across the python example here: [https://itk.org/ITKExamples/src/IO/GDCM/ReadDICOMSeriesAndWrite3DImage/Documentation.html](https://itk.org/ITKExamples/src/IO/GDCM/ReadDICOMSeriesAndWrite3DImage/Documentation.html).

However, when I run this example (after adding `import sys`) on the dataset referenced from the thread mentioned in the initial post (the dataset itself is available here: [https://www.dropbox.com/s/re37n46wvktez5c/mf.dcm.bz2](https://www.dropbox.com/s/re37n46wvktez5c/mf.dcm.bz2)), I get the error below:

```nohighlight
WARNING: In /Users/kitware/Dashboards/ITK/ITKPythonPackage/standalone-build/ITK-source/Modules/IO/GDCM/src/itkGDCMSeriesFileNames.cxx, line 109
GDCMSeriesFileNames (0x7fe8869d7bb0): No Series were found

No DICOMs in: .

```

Looks like this DICOM file is not even recognized as DICOM by ITK `GDCMSeriesFileNames`.

Checking it with [`dcmdump`](https://support.dcmtk.org/docs/dcmdump.html), it is clearly a valid DICOM file (and it comes from David Clunie).

```nohighlight
$ dcmdump mf.dcm|more 2.3.6

# Dicom-File-Format

# Dicom-Meta-Information-Header
# Used TransferSyntax: Little Endian Explicit
(0002,0000) UL 214 # 4, 1 FileMetaInformationGroupLength
(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
(0002,0002) UI =LegacyConvertedEnhancedMRImageStorage # 28, 1 MediaStorageSOPClassUID
(0002,0003) UI [1.3.6.1.4.1.5962.99.1.7321.1421.1542625430036.1.1.1.2.1] # 56, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianExplicit # 20, 1 TransferSyntaxUID
(0002,0012) UI [1.3.6.1.4.1.5962.99.2] # 22, 1 ImplementationClassUID
(0002,0013) SH [PIXELMEDJAVA001] # 16, 1 ImplementationVersionName
(0002,0016) AE [OURAETITLE] # 10, 1 SourceApplicationEntityTitle

# Dicom-Data-Set
# Used TransferSyntax: Little Endian Explicit
(0008,0008) CS [ORIGINAL\PRIMARY\M\NONE] # 24, 4 ImageType
(0008,0012) DA [20181119] # 8, 1 InstanceCreationDate
(0008,0013) TM [060350.036] # 10, 1 InstanceCreationTime
(0008,0016) UI =LegacyConvertedEnhancedMRImageStorage # 28, 1 SOPClassUID
(0008,0018) UI [1.3.6.1.4.1.5962.99.1.7321.1421.1542625430036.1.1.1.2.1] # 56, 1 SOPInstanceUID
(0008,0020) DA [19991231] # 8, 1 StudyDate
(0008,0021) DA [19991231] # 8, 1 SeriesDate
(0008,0023) DA [19991231] # 8, 1 ContentDate

```

Is [LegacyConvertedEnhancedMRImageStorage](http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.71.html) IOD expected to be supported by ITK?

Is there another example you can point me to that is recommended that I can use to reproduce the problem and report the issue?

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [November 19, 2018, 10:50pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/12 "2018-11-19T22:50:32Z")

</div>

Forgot to mention, I have itk-4.13.1.post1 installed with pip on mac 10.14.1.

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [November 19, 2018, 11:08pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/14 "2018-11-19T23:08:01Z")

</div>

@Mihail_Isakov sounds good, thanks. But to me this means that _de facto_ reading multiframe DICOM, at least of this specific type, is not supported in ITK as of today. @thewtex please let me know if I am missing something, or if I should try something different.

cc: @dzenanz - I see you authored the python sample code that I’ve been using for testing.

---

<div class="post-metadata">

**Author:** ![thewtex](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/thewtex/32/32_2.png) [@thewtex](https://discourse.slicer.org/u/thewtex)\
**Post date:** [November 20, 2018, 2:02am UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/16 "2018-11-20T02:02:59Z")

</div>

> [@fedorov](#):
>
> I thought it is probably not very helpful if I submit an issue demonstrating the problem in Slicer, since there are potentially other sources of error, so I wanted to reproduce the problem with ITK.

Thank you @fedorov !

> [@fedorov](#):
>
> I googled for “itk read dicom series”, and came across the python example here: [Read DICOM Series and Write 3D Image — v5.4.0](https://itk.org/ITKExamples/src/IO/GDCM/ReadDICOMSeriesAndWrite3DImage/Documentation.html).

This is for reading the more cumbersome series distributed over multiple files.

For a multi-frame DICOM, we can just use:

```auto
import itk
image = itk.imread('mf.dcm')

```

> [@fedorov](#):
>
> However, when I run this example (after adding `import sys` ) on the dataset referenced from the thread mentioned in the initial post (the dataset itself is available here: [https://www.dropbox.com/s/re37n46wvktez5c/mf.dcm.bz2](https://www.dropbox.com/s/re37n46wvktez5c/mf.dcm.bz2)),

I tried the above with the given image, and it reads in a head volume content fine. However, the origin and spacing are not populated.

> [@Mihail\_Isakov](#):
>
> Legacy Converted Enhanced was partially supported, this commit added more support (spacing, origin, etc.), probably not yet in ITK.
> 
> [github.com/malaterre/GDCM](https://github.com/malaterre/GDCM/commit/38fff78cbe6f2065e22dfea32b406e016665c5f5)
> 
> [![malaterre](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/2X/e/ed41d5165e8a83a031690a53f6db16b8cdf57e4b.png) ](https://github.com/malaterre)
> 
> #### [Merge pull request #55 from issakomi/legacy\_enh2](https://github.com/malaterre/GDCM/commit/38fff78cbe6f2065e22dfea32b406e016665c5f5)
> 
> Spacing and other. attr. for Legacy, Breast Tomo
> 
> by [malaterre](https://github.com/malaterre) on [06:50AM - 20 Aug 18 UTC](https://github.com/malaterre/GDCM/commit/38fff78cbe6f2065e22dfea32b406e016665c5f5)
> 
> changed **3 files** with **70 additions** and **14 deletions**.

Very nice @Mihail_Isakov ! I will try updating ITK’s GDCM, and I will report back on the resulting origin / spacing…

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [November 20, 2018, 2:16am UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/17 "2018-11-20T02:16:08Z")

</div>

> [@thewtex](#):
>
> > I tried the above with the given image, and it reads in a head volume content fine. However, the origin and spacing are not populated.

Thanks – this is consistent with what we observe in Slicer, so the problem is reproduced. Should I create an issue so we could follow on the updates?

---

<div class="post-metadata">

**Author:** ![thewtex](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/thewtex/32/32_2.png) [@thewtex](https://discourse.slicer.org/u/thewtex)\
**Post date:** [November 20, 2018, 2:36am UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/19 "2018-11-20T02:36:50Z")

</div>

> [@fedorov](#):
>
> Thanks – this is consistent with what we observe in Slicer, so the problem is reproduced. Should I create an issue so we could follow on the updates?

Good – yes, an issue would be helpful to collect information and track progress.

---

<div class="post-metadata">

**Author:** ![thewtex](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/thewtex/32/32_2.png) [@thewtex](https://discourse.slicer.org/u/thewtex)\
**Post date:** [November 20, 2018, 3:28am UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/20 "2018-11-20T03:28:25Z")

</div>

> [@Mihail\_Isakov](#):
>
> There are more issues, but enough written today 🙂 Sorry for many posts.

@Mihail_Isakov thanks for your contributions. These variations can be challenging, but working together on them collectively disarms the challenge.

Your fix in GDCM indeed fixed the issue with the provided dataset:

```auto
 RequestedRegion:
   Dimension: 3
   Index: [0, 0, 0]
   Size: [256, 256, 128]
 Spacing: [1, 1, 1.33]
 Origin: [-83.2177, -123.869, 159.934]
 Direction:
4.37571e-31 -1e-16 1
0.976296 -0.21644 -2.1644e-17
-0.21644 -0.976296 -9.76296e-17

```

Pull request is here: [Update GDCM to 2018-11-05 release branch by thewtex · Pull Request #208 · InsightSoftwareConsortium/ITK · GitHub](https://github.com/InsightSoftwareConsortium/ITK/pull/208)

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [November 20, 2018, 3:56pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/21 "2018-11-20T15:56:20Z")

</div>

> [@Mihail\_Isakov](#):
>
> they _always_ have In-Stack Position Number in reversed order, e.g.  
> Stack ID / In-Stack Position Number  
> 1 / 121  
> 1 / 120  
> 1 / 119  
> 1 / 118  
> etc.  
> Not sure it is a bug, sometimes it is correct, sometimes definitely not. Where take the origin? 1st frame, last frame? GDCM takes always first. Per standard in Legacy Converted dimension organisation is optional, so if there is no dimension organisation - i ignore In-Stack Position Number, load frames one by one (as GDCM returns) and do own validation. If it fails, mark image as non-uniform and disable orientation letters.

@Mihail_Isakov what makes you believe you can rely on in-stack position number for volumetric reconstruction of the geometry? I think those positions can only be useful for visualizing the frames to the user, and one should always sort individual frames geometrically to reconstruct the volume and calculate the origin.

@thewtex @malaterre does ITK/GDCM sort frames of enhanced objects using shared/per frame geometry information as part of volume reconstruction?

---

<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:** [November 21, 2018, 1:47pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/24 "2018-11-21T13:47:28Z")

</div>

[This post on the ITK issue tracker](https://github.com/InsightSoftwareConsortium/ITK/pull/208#issuecomment-440659486) contends that the multiframe file is left/right flipped - is that true?

---

<div class="post-metadata">

**Author:** ![Mihail\_Isakov](https://avatars.discourse-cdn.com/v4/letter/m/a9adbd/32.png) [@Mihail\_Isakov](https://discourse.slicer.org/u/Mihail_Isakov)\
**Post date:** [November 21, 2018, 2:29pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/26 "2018-11-21T14:29:56Z")

</div>

Here is same image exported as classic series, no problem, if individual slices sorted by IPP/IOP. It is then ASL (in ITK terminology)

[Classic series](https://drive.google.com/file/d/1mGZYywLseaipcG-SnJJOjll32xxR7T2Q/view?usp=sharing)

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [November 21, 2018, 2:53pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/27 "2018-11-21T14:53:29Z")

</div>

For the sake of completeness, here’s the link to the original MR series that David Clunie converted into the multiframe instance referenced in the original post: [https://www.dropbox.com/s/8m7ugu4cmw83fvd/dicoms-anon.zip?dl=0](https://www.dropbox.com/s/8m7ugu4cmw83fvd/dicoms-anon.zip?dl=0)

---

<div class="post-metadata">

**Author:** ![Mihail\_Isakov](https://avatars.discourse-cdn.com/v4/letter/m/a9adbd/32.png) [@Mihail\_Isakov](https://discourse.slicer.org/u/Mihail_Isakov)\
**Post date:** [November 21, 2018, 3:03pm UTC](https://discourse.slicer.org/t/dicom-multiframe-support/4806/28 "2018-11-21T15:03:13Z")

</div>

Yes, it confirms. Try to open multi-frame and classic series in volume rendering or compare Z-directions thru calculations. Flipped. Didn’t you say frames should be sorted?

[Next page](https://discourse.slicer.org/t/dicom-multiframe-support/4806.md?page=2)