Proposals:Slice contiguous images: Difference between revisions
(→Impact) |
No edit summary |
||
| Line 1: | Line 1: | ||
ITK uses a contiguous image memory model. All the pixels in an image/volume are in a single contiguous memory block. Many existing medical image analysis systems use a slice contiguous memory model. Here, all the pixels in a slice are in a contiguous memory block but the slices may not be contiguous in memory. A slice contiguous memory model has benefits over a volume contiguous memory model in memory management and cache coherency. | ITK uses a contiguous image memory model. All the pixels in an image/volume are in a single contiguous memory block. Many existing medical image analysis systems use a slice contiguous memory model. Here, all the pixels in a slice are in a contiguous memory block but the slices may not be contiguous in memory. A slice contiguous memory model has benefits over a volume contiguous memory model in memory management and cache coherency. | ||
| Line 36: | Line 35: | ||
For completness, this support will make more sense if it is accompanied of modifications in the Readers and Writers that will facilitate to bring isolated slices from images into memory and that will allow to write slice-by-slice into output files. | For completness, this support will make more sense if it is accompanied of modifications in the Readers and Writers that will facilitate to bring isolated slices from images into memory and that will allow to write slice-by-slice into output files. | ||
{{ITK/Template/Footer}} | |||
Revision as of 20:40, 20 December 2005
ITK uses a contiguous image memory model. All the pixels in an image/volume are in a single contiguous memory block. Many existing medical image analysis systems use a slice contiguous memory model. Here, all the pixels in a slice are in a contiguous memory block but the slices may not be contiguous in memory. A slice contiguous memory model has benefits over a volume contiguous memory model in memory management and cache coherency.
Design
Image virtual address space manged by the PixelContainer
The implementation could be done at the PixelContainer level. You can think of the PixelContainer as providing a 1D contiguous address space for an ND image. The pixel container could then manage the indexing into real memory.
Which dimensions of an image should be contiguous?
For ND images, we'll need to decide which dimensions are contiguous:
- (N-1)D are contiguous, last dimension sparse across the memory space
- 2D slices are contiguous, (N-2)D dimension sparse across the memory space
Specifying the PixelContainer
At one point in ITK's history, Images were templated over the type of PixelContainer. We could revert back to that design to allow other PixelContainers to be used. Alternatively, we could use inheritance/virtual functions, allowing the existing image to operate on a variety of PixelContainer classes.
Option: Let Iteratior be aware of the internal Image Organization
This option will provide a better shot for supporting high computation times. In this option, the iterators will be aware of the internal slice-by-slice memory organization of the image and will manage the final access to the pixel data in memory.
- WithIndex iterators should be easy to adapt to this framework and not API changes.
- PixelWise (not WithIndex) should also require minor modifications and not API changes.
- Neighborhod iterators will be the more challenging ones, but doesn't seem to bea technical reason why they couldn't be converted.
Impact
- Supporting slice contiguous images will require modification to the image iterators and anywhere Image::GetBufferPointer() is called.
- A simplistic implementation may result in a double derefernce of data which could impact performance.
- Using inheritance in the PixelContainer class will most likely result in a virtual function call to dereference a pixel which could impact performance.
Readers and Writers
For completness, this support will make more sense if it is accompanied of modifications in the Readers and Writers that will facilitate to bring isolated slices from images into memory and that will allow to write slice-by-slice into output files.
