2010 Project Week DICOM supplement 145
Key Investigators
- Mathieu Malaterre: Entrepreneur
- Alex. Gouaillard: A*STAR
- Luis Ibanez: Kitware Inc.
Project
DICOM Supplement 145 provide a way to go over the 32bits limits and allow storing of large images. We propose to implement this specification. In addition, we would implement DICOM specification for JPEG 2000 Part 2 Multi-component Image Compression. This portion of the standard provides higher compression ratio for storing multicomponent images. Finally by implementing DICOM supplement 132, we would provides support for storing of surfaces and 3D volumes, as an addition to the 2D RTSTRUCT.
Standard support for Large multicomponent images in ITK
DICOM currently defines Image IODs by storing the rows and columns as unsigned short integer. This means that an image can only be at most of size 2^16 * 2^16 pixels. This is a limitation for Microscopy Images as , for example, typical Whole Slice Images an be 60,000 * 80,000 pixels. Since images are generally stored with 24-bit color pixels, this means WSI can go up to 15Gb. Confocal Microscopy Images add one additional dimension, and are today already capable of acquiring 24 channels. They are reported to need up to petabytes. For this reason DICOM Supplement 145 defines a way to store images into multiple DICOM files providing a mean to work around this 32bits limitation of DICOM. By implementing this Supplement (which is still in Ballot), we would provide to the ITK community a proof of concept and allow people to start saving larges images using DICOM. This would allow the re-using of technologies and prevent people from re-inventing the wheel and start using a new file format to exchange medical image (second system effect).
Standard support for multicomponent images compression in ITK
Microscopy Images, on top of being larger sometimes by several orders of magnitudes from medical images, are also multi-component. Even though ITK handle multicomponent images per say, by defining the right pixel type, nothing is available today for the storage and compression of images that would have more than 3 channels (RGB). Since 2001, the DICOM standard allows JPEG 2000 compression. GDCM 2.x has supported a portion of the standard by providing an API to allow transfer syntax such as JPEG 2000 Image Compression (1.2.840.10008.1.2.4.90 and 1.2.840.10008.1.2.4.91). However the standard also includes JPEG 2000 Part 2 Multi-component Image Compression (1.2.840.10008.1.2.4.92 and 1.2.840.10008.1.2.4.93). The latter has never made into GDCM / ITK, or any other open source DICOM toolkit, since as quoted from the presentation: “Image Compression Refresher – JPEG 2000 and 3D, David Clunie”: the compression gain was modest (using lossless compression). We see now an opportunity that this compression can make it into GDCM / ITK since microscopy images would perfectly fit into the original design of the compression (ISO/IEC 15444-2:2003 Annex J). This would ease the dissemination of large dataset by reusing standard compression techniques, since this would greatly reduce the size of those file datasets. This will be particularly useful for microscopic images. At the time of writing no other open-source DICOM toolkit offer this compression algorithm.
Standard support for discrete 2 and 3 manifold storage in ITK
From its early design, ITK has always offered some n-dimensional n-manifold (polygonal meshes) support through the itk::Mesh class. However at the time of writing of this proposal, there is still no official way to read or write those meshes from and to a filesystem in ITK. Only an hybrid solution is available in Insight Applications. However it implies a dependency to the entire VTK library which is an overkill most of the time. Thanks to the work on itk::QuadEdgeMesh some progress have been made toward that goal. The Review directory surrently holds a very simple VTK PolyData reader and writer. However, it only supports legacy vtk files using ASCII encoding. For its defense, this implementation was only made for regression testing and illustration of the filters usage. We are proposing here to fill this gap in the ITK toolkit and implement DICOM's Supplement 132, part of the standard since 2008, which would add surfaces and volumes meshes (2 and 3 manifolds) storage capacity to GDCM /ITK. This would add support for surfaces and volume (2 and 3 manifolds in n dimensional space, see supplemental material annex). We suggest 2 different options. The first option would allow for storage of itk::QuadEdgeMesh as a DICOM file. The second options would allow for storage of an itk::Mesh as a DICOM file. Of course reading the corresponding structures from a DICOM file would also be provided. As an illustration, we make a clear distinction in what itk::QuadEdgeMesh handles and what itk::Mesh can handle. Both 2 and 3 manifold objects are handled in the DICOM standard. We do anticipate a large portion of this task to be validation testing. Since there are no other serialization mechanism available in ITK, we will need to setup an hybrid system with VTK to perform validation on the dataset written (a 3D VTK mesh will be used as input for the tests). For this we would be re-using code from InsightApplications/Auxiliary/vtk/vtk2itk.cxx.
Objective
The objectives of the project week is to share with the community and make a list of persons interested and of corresponding efforts before we start implementing. Typically at the end of the week we would like to have identified existing parts, ongoing effort and have a roadmap available possibly with other groups joining in depending on needs, manpower and expertise.
Approach, Plan
1. Item #1: Compare existing technologies: HDF5, DICOM, JPEG2000, TIFF (XMP)
2. Item #2: Identify technologies in ITK: openjpeg v1 which does not support tiles (required for streaming)
3. Item #3: Identify group which would need this technology: maybe CTK ?
Progress
* Worked with Kishore for ITK/JPEG 2000 reader. Code review / Made it compile
* Sync with upstream openjpeg team: there are 400 regression tests now !
* Need to synchronize effort with GDCM 2.x and OpenJPEG v2 update. Prepare patch for GDCM 2.x to use openjpeg v2.
* Worked with GoFigure2 team to identify the need:
- passing algorithm more than passing data.
- image data
- very large image 4D
- mesh based segmentation (2d / 3d mesh)
- annotations (label)
* XMP technogoly is based on XML, which imply ASCII serialization (poor performance, very verbose).
Delivery Mechanism
This work will be delivered to the NA-MIC Kit as a
- ITK Module
- Other: GDCM extension (gdcm is included in ITK)
References
- the official DICOM Standard Proposal here
