DICOM multiframe support

Development
1

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

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.

2

Would it be a complete heresy to bundle 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).

1 Like
3

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 is compatible.

As an aside, I also like the look of the MIRcroGL renderer - could make an interesting extension tool.

4

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.

5

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, looks like the “home” for ITK DICOM development is GitHub - KitwareMedical/ITKDICOM: Better support for DICOM in ITK., 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! :smiley:

6

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.

8

@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.

1 Like
9

ITK’s Jira Issue Tracker is dead. Long live ITK’s GitHub Issue Tracker! :crown:

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 is still available – if there is a relevant issue that you find important, please migrate them to the GitHub issue tracker.

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!

2 Likes
11

@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.

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), I get the error below:

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, it is clearly a valid DICOM file (and it comes from David Clunie).

$ 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 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?

12

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

14

@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.

1 Like
16

Thank you @fedorov !

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

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

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

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.

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

1 Like
17

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?

19

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

20

@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:

 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

21

@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?

24

This post on the ITK issue tracker contends that the multiframe file is left/right flipped - is that true?

26

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

27

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

28

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?