Generic Image Reader P3 REQ

From IGSTK

Contents 1 Current structure 2 Proposed design 2.1 General guideline 2.2 Use case 2.3 Major issues with generic image reader 2.4 Solution 2.5 Issues open for discussion 2.6 Other issues need to be fixed 3 Implementation 3.1 State Machine Diagram for Reader

Current structure

Proposed design

General guideline

1. Will provide convenient and generic classes while keeping modality specific classes in the library
   • Need to be careful about keeping code in sync

Use case

The use doesn't need to know about the modality, the reader can read any supported modality and format

Major issues with generic image reader

1. Pixel type
   • CT -> signed short
   • MR -> unsigned short
   • US -> unsigned char
2. Dimension
   • CT & MR are mostly 3D
   • US could be 2D, but we can treat it as 3D with the 3rd dimension with only one slice
3. Representation parameters (Window/Level)
   • Different pixel types have different range

Solution

1. Create DICOMGenericImageReader, GenericImageSpatialObject, and GenericImageRepresentation classes
   • DICOMGenericImageReader will instantiate different ITKImage internally according to the DICOM modality tags it encounters
   • Can only read DICOM
2. Wrapper class based on Andinet's insight journal work on "Seamless VTK-ITK pipeline connection for image data handling"
   • Can read all supported format
   • Supported pixel type: ( UNSIGNED_CHAR, CHAR, UNSIGNED_SHORT, SHORT, UNSIGNED_INT, INT, UNSIGNED_LONG, LONG, FLOAT, DOUBLE)
   • Refer to vtkKWImageIO and vtkKWImage classes
3. Base on option 2, but use only one common pixel type

Issues open for discussion

1. Supporting image format other than DICOM?
2. Have some kind of internal data format?
3. Using a common pixel type in IGSTK and handle the conversion internally?
   • What would be the appropriate common pixel type, considering precision and memory trade off, and compatibility to future image data requirements
4. How will reslice representation class be implemented in this regard?
   • The reslicing part itself have nothing to do with modality
   • Might just need to provide a type safe class for each single modality

Other issues need to be fixed

1. USImageObject class should be renamed to USImageSpatialObject to be consistent
2. Current DICOMReader assumes there is only one series in the given directory. When there are multiple series, it will just load the first SeriesUID
   • Should we just send out a notification event but proceed with loading the first series?
   • Should we reject the directory when there are multiple series?
   • Should we provide another class will gather the SeriesUIDs and ask for the user to choose?

Implementation

State Machine Diagram for Reader