Proposals:Slice contiguous images
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.
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.
