Loading in DICOM series to volume - Best way/most robust way of taking all file DICOM file types.

Support
1

I currently use VTK to read in a dicom series using vtkDICOMImageReader. (->setDirectory name).

It reads the dicoms into a block or volume, of which i then reslice in my desired planes(s).
vtkSmartPointer slice_DICOM = vtkSmartPointer::New();
slice_DICOM->SetInputConnection(DICOM_reader->GetOutputPort());
slice_DICOM->SetSlicePlane(plane);

m_image_slice = vtkSmartPointer<vtkImageSlice>::New();
m_image_slice->SetMapper(slice_DICOM);

This issue with using this is that the series I have needs to be loaded and exported in 3d Slicer, which automatically processes the DICOM files to a usable format, of which i export. It is only then that the vtkDICOMImage works.

For my program to be robust I will need to create a program that can take in all types of DICOM (or at least the vast majority) for it to be usable/reliable, like slicer does.

I am very confused on how to approach this problem, and what direction I should be going in order to achieve this as there appears to be many options:

  • I have read that vtkDICOMImageReader is not a robust reader where i here the gdcm library “vtkGDCMImageReader” is better at doing this.

  • i have also come across many converters that do many compression’s/decompressions ect

  • I have also come accross this volume reader: vtkITKArchetypeImageSeriesScalarReader.

-I have also come accross ITK functions
“itkImage.h”
“itkGDCMImageIO.h”
“itkGDCMSeriesFileNames.h”
“itkImageSeriesReader.h”
“itkImageFileWriter.h”

In summary i’m very lost on what or where i should be choosing.

  • are there any popular methods of achieving this?
  • should i stack all of them in a series of if statements in each failure, to increase the chance of it working?
  • It is worthwhile to use install ITK in this process with GDCM and VTK?
  • Do i need to include converters aswell as these readers?

Many thanks in advance.

Joe

2

If your application has to support only certain kinds of images, generated by a known set of scanners then you can choose a DICOM toolkit that works quite well for those and implement workarounds, pre/post processing for the remaining problematic cases.

Implementing a general DICOM reader that can deal with most image types is extremely difficult. We have been constantly working on improving 3D Slicer’s DICOM importer for more than a decade and we still get reports of various difficulties of loading certain data sets and have to make fixes and improvements accordingly. We use DCMTK, GDCM, pydicom, dcm2niix DICOM toolkits, add many pre/post processing steps to handle special cases, and a DICOM patcher to fix DICOM standard non-compliances.

Overall, if DICOM import is not the main goal of your project but it is just a necessity -so that you use your method on medical images - and you need to support “all” kinds of DICOM data objects, then I would recommend to build on an existing application that can already do this. It minimizes the workload and risk for you - even if you encounter any problematic data set, you can send the data to the application developers, who investigate the problem and improve the importers accordingly.

3D Slicer is an obvious choice, since it is free in every sense (freely available, has free support, can be used even in commercial applications without any restrictions), can be used as a desktop application, as a command-line tool, as a Jupyter kernel, in web browser (via a docker container), customized and extended in Python or C++, runs on Windows, Mac, and Linux. VTK, ITK, and couple of other commonly used medical image computing packages are already bundled and several others can be installed via extensions, and in recent versions you can install and use any Python3 packages directly in your custom modules.

2 Likes
3

Thank you very much for your answer

4

Hi Andras. Is your answer still the same in 2024?

5

Yes, the answer is still valid today.

@pieper and I would like to spin off Slicer’s DICOM reader/writer logic into a standalone Python package to make it easier to read/write a wide range of DICOM data objects to/from VTK/ITK objects (all kind of images, with non-uniform spacing, tilted-gantry acuisition, etc., segmentation, surface segmentation, spatial registration objects, structured reports, RT structure set/dose/plan/image data types etc.) independently from the Slicer application, but we don’t have any funding dedicated to it. So, if you want to import/export a wide range of DICOM data objects then 3D Slicer application is probably still your best bet.