I’ve been using itk::ImageSeriesReader to read various DICOM studies, and code similar to that described in the “Process a 2D Slice of a 3D Image” example to extract any of the slices in a series. My code works for all CT and MRI series I’ve thrown at it, with one exception. When I try to extract any images from a multiplanar scout from an MRI examination, itk::ExtractImageFilter throws an exception:
ITK ERROR: ExtractImageFilter(00000186D95E84E0): Invalid submatrix extracted for collapsed direction.
This makes sense, in that the scout series has 19 mixed multiplanar (axial/sagittal/coronal) images, rather than a volume of axial (or coronal or sagittal) images.
Is there a way to tell from the DICOM header, or preferably from the itk::Image<> object, that this is a multiplanar scout? Or is there some other way I should be extracting the images in a series, besides assuming they’re from a 3D volume?
Unfortunately, the DICOM standard does not provide a solution for this. Probably the best thing you can do is to implement heuristics that try different interpretations of an image series and then load the data set using the most likely one.
In 3D Slicer, we have implemented a number of DICOM plugins, each containing intricate logic that try to make sense of the frames in the image series. For example, you can have a look at the logic of the basic 3D scalar volume plugin here. It deals with scout scans that contain frames in different orientations by splitting the volume into sub-series by image orientation and offer each as a separate loadable. The frames are also processed by a volume sequence plugin, which checks if the series can be interpreted as a 4D volume (based on additional grouping fields), and may offer a single loadable with a higher confidence value. These two plugins together can loading correctly simple rectilinear 3D volumes, scout images with multiple orientations, and 4D volumes. There are about a dozen more plugins, they all get a chance to interpret the series and offer different interpretations and corresponding confidence values. In the end the loadable(s) with highest confidence are offered for loading by default.