vtk-dicom
0.8.17
|
Reading a directory that contains DICOM files.
DICOM files rarely have descriptive names, so it is usually necessary to identify them by their contents. A typical DICOM folder listing looks something like this:
These files might be 16 slices of a 3D image, or the first three files might be localizer images while the remaining 13 files are slices of a 3D volume. Or they might be something else entirely. So the first thing to do with a batch of DICOM files is to find out how they fit together. There are two classes that can be used for this: the old vtkDICOMFileSorter class, and the newer vtkDICOMDirectory class.
The vtkDICOMDirectory class solves this problem by scanning the directory and reporting information on all of the DICOM files that it finds. In addition, if the directory contains a DICOMDIR file (as is the case for a DICOM CD), then the DICOMDIR file is used as an index. In the simplest case, the directory will contain a single series as in the example below. Since the example is looking for images (and not for other DICOM files such as structured reports), the RequirePixelData flag is set:
Since vtkDICOMDirectory will scan subdirectories recursively, it can be used to catalogue a large collection of DICOM files:
The PatientRecord, StudyRecord, and SeriesRecord in the above example contain attributes for the images that were stored in the DICOMDIR index file. At the bare minimum, these will provide the PatientName, PatientID, StudyDate, StudyTime, StudyInstanceUID, and SeriesInstanceUID. Usually the StudyDescription, SeriesDescription and SeriesNumber are also available. Furthermore, the method GetMetaDataForSeries() returns an amalgamation of the Patient, Study, Series, and Image information as a vtkDICOMMetaData object (though the per-image information is sometimes limited to just the InstanceNumber and the SOPInstanceUID).
The vtkDICOMDirectory class has another trick up its sleeve. It can search for files that have certain attributes, for example it can search a filesystem for all scans of a specific patient. This is similar in purpose to querying a PACS system, except that you are instead providing one or more disk directories where the files might exist. These directories are searched recursively for all files that match the query.
All text attributes except for dates accept the wildcards '*' and '?'. For dates, you can use a hyphen to specify a range of dates. Matching of all text is done by first converting the text to utf-8 for compatibility, and for patient names the matching is case insensitive. The query PRIMARY will match the multi-valued attribute value ORIGINAL\PRIMARY, since only one value has to match.
If the query contains any non-ASCII text, you must set the SpecificCharacterSet attribute to whichever character set your program uses internally. This does not have to be the same as the character set used in the files you are searching for. It is recommended to use utf-8 as the character set for the query, regardless of the character set used in the DICOM files.
The vtkDICOMFileSorter class is obsolete, since its capabilities are eclipsed by the vtkDICOMDirectory class, but its use is documented here for historical reasons. It is also worth stating that the "sorting" provided by this class is, in fact, unnecessary: the vtkDICOMReader itself is capable of sorting its input files into the correct order.
In addition, the sorter can discover which series belong to the same study. That is, it can tell us which series were collected during the same imaging session. One thing the sorter does not do is sort the images in the series according to slice location. It only sorts the images according to the Instance Number embedded in each image, where the Instance Number gives the logical viewing order prescribed by the medical device that generated the images. It is up to the vtkDICOMReader to check the slice positions for the files and sort them by location before generating an image volume or time series.