(this might as well fit in the beginner category )
I’m looking at integrating ITK into our libraries, which would mean creating a bridge between itk::Image and our in-house data structure for 3D uniform grid volumes. That seems to be straightforward in case of contiguously allocated memory, but in our case (due to the size of the volumes) we also use block arrays that are non-contiguous in memory.
Is this supported in ITK, or is there only support for contiguously allocated memory?
Going through the software guide and documentation didn’t really make it clear, so any pointers (har har, punny) are appreciated.
Adding support for non-contiguous memory layout was originally envisioned and later discussed, but it was never implemented. Most things don’t assume contiguous layout, but some do. Adding it would be a major effort, with some performance impact too.
Going through the code it seemed at first that using Image::PixelContainer would allow shoehorning something in, but seeing all the references to ImportImageContainer::GetBufferPointer() to access the base pointer has quickly killed any optimism I initially had.
Seems like contiguous memory is the only feasible way. That means marshalling or some major refactoring.
Thanks for the input.
I have been using the SliceContiguousImage contributed in an IJ submission for quite some time. It works well as input type to all filters i have used. I simply avoid using it as an output image type, i. E. I copy the 3d itk::Image back to the application image.
)