Difference between revisions of "Complex Image Set"
(Created page with 'A complex image set cannot be represented by a single grid. Instead it is made up of multiple grids, because it includes things like: # gantry tilt # irregular slice spacing # ...') |
|||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 7: | Line 7: | ||
Proposed data structure shown in pseudocode | Proposed data structure shown in pseudocode | ||
| − | + | // itkImageCollection is a subclass of itkOrientedImage. The image in the base class | |
| − | + | // is a standard itk image with uniform spacing & direction cosines. | |
| − | + | // The memory for the base class image is allocated when the source image group | |
| − | + | // is reformatted into a uniform grid. | |
| − | + | itkImageCollection : itkOrientedImage { | |
| − | + | // The sourceImageGroup is an array of image sections. Each image | |
| − | + | // section corresponds to a group of slices with the same tilt, spacing, etc. | |
| − | + | itkArray<itkOrientedImage> sourceImageGroup; | |
| − | |||
| − | |||
} | } | ||
| − | Normal ITK routines will operate on the reformatted image | + | Normal ITK routines will operate on the reformatted image, using C++ inheritance. But if the user needs the original images or their headers, they are available. |
| + | |||
| + | At image load time, the image should be loaded as an image collection. By default, reformatting will occur automatically using the spacing found in the largest source image. If reformatting is not desired, the programmer must specify no reformatting prior to load. | ||
| + | |||
| + | After reformatting, the images within the source image group may be deallocated to save memory. It should be possible to deallocate the image data only (retaining header information for the image group items), or deallocate the entire image group (leaving only the reformatted image). | ||
| + | |||
| + | By default, the image save will write the reformatted image to disk. When saving as source image format, the reformatted image is first interpolated back to the source image space by the programmer. | ||
| + | |||
| + | == Dicom Images == | ||
| + | |||
| + | One missing issue is that the dicom uid's are important. For example, a DICOM-RT compliant segmentation algorithm needs the UID's for cross-reference. | ||
| + | |||
| + | But ITK images don't know anything about dicom uid. The dicom loader needs to be smart enough not to discard these header information. | ||
| + | |||
| + | Solution TBD. | ||
| + | |||
| + | == See Also == | ||
| + | Note from the ITK community about ITK 4.0 planning: | ||
| + | |||
| + | http://www.itk.org/Wiki/ITK_Release_4.0#Oriented_Images | ||
| + | |||
| + | Slicer bug 595 | ||
| + | |||
| + | http://www.na-mic.org/Bug/view.php?id=595 | ||
Latest revision as of 20:29, 17 July 2009
Home < Complex Image SetA complex image set cannot be represented by a single grid. Instead it is made up of multiple grids, because it includes things like:
- gantry tilt
- irregular slice spacing
- overlapping scans
Proposed data structure shown in pseudocode
// itkImageCollection is a subclass of itkOrientedImage. The image in the base class
// is a standard itk image with uniform spacing & direction cosines.
// The memory for the base class image is allocated when the source image group
// is reformatted into a uniform grid.
itkImageCollection : itkOrientedImage {
// The sourceImageGroup is an array of image sections. Each image
// section corresponds to a group of slices with the same tilt, spacing, etc.
itkArray<itkOrientedImage> sourceImageGroup;
}
Normal ITK routines will operate on the reformatted image, using C++ inheritance. But if the user needs the original images or their headers, they are available.
At image load time, the image should be loaded as an image collection. By default, reformatting will occur automatically using the spacing found in the largest source image. If reformatting is not desired, the programmer must specify no reformatting prior to load.
After reformatting, the images within the source image group may be deallocated to save memory. It should be possible to deallocate the image data only (retaining header information for the image group items), or deallocate the entire image group (leaving only the reformatted image).
By default, the image save will write the reformatted image to disk. When saving as source image format, the reformatted image is first interpolated back to the source image space by the programmer.
Dicom Images
One missing issue is that the dicom uid's are important. For example, a DICOM-RT compliant segmentation algorithm needs the UID's for cross-reference.
But ITK images don't know anything about dicom uid. The dicom loader needs to be smart enough not to discard these header information.
Solution TBD.
See Also
Note from the ITK community about ITK 4.0 planning:
http://www.itk.org/Wiki/ITK_Release_4.0#Oriented_Images
Slicer bug 595
