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.

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.