# itk::Image support for non-contiguous memory?
**URL:** https://discourse.itk.org/t/itk-image-support-for-non-contiguous-memory/2443
**Category:** Engineering
**Created:** [November 26, 2019, 1:34pm UTC](https://discourse.itk.org/t/itk-image-support-for-non-contiguous-memory/2443 "2019-11-26T13:34:09Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Bram](https://discourse.itk.org/u/Bram)
#### Post date: [November 26, 2019, 1:34pm UTC](https://discourse.itk.org/t/itk-image-support-for-non-contiguous-memory/2443/1 "2019-11-26T13:34:09Z")
(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.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [November 26, 2019, 2:10pm UTC](https://discourse.itk.org/t/itk-image-support-for-non-contiguous-memory/2443/2 "2019-11-26T14:10:36Z")
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.
---
### Author:  [@Bram](https://discourse.itk.org/u/Bram)
#### Post date: [November 26, 2019, 2:25pm UTC](https://discourse.itk.org/t/itk-image-support-for-non-contiguous-memory/2443/3 "2019-11-26T14:25:22Z")
Oh well… So far for it being easy 🙃
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.
---
### Author:  [@dyoll](https://discourse.itk.org/u/dyoll)
#### Post date: [December 4, 2019, 5:40pm UTC](https://discourse.itk.org/t/itk-image-support-for-non-contiguous-memory/2443/4 "2019-12-04T17:40:39Z")
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.
See [https://github.com/ITISFoundation/osparc-iseg/blob/master/Thirdparty/IJ/AlternativeMemoryModels/itkSliceContiguousImage.h](https://github.com/ITISFoundation/osparc-iseg/blob/master/Thirdparty/IJ/AlternativeMemoryModels/itkSliceContiguousImage.h)
And [https://github.com/ITISFoundation/osparc-iseg/blob/master/Data/ImageToITK.h](https://github.com/ITISFoundation/osparc-iseg/blob/master/Data/ImageToITK.h), where i shallow copy the data to the SliceContiguousImage
---
### Author:  [@Bram](https://discourse.itk.org/u/Bram)
#### Post date: [December 4, 2019, 6:10pm UTC](https://discourse.itk.org/t/itk-image-support-for-non-contiguous-memory/2443/5 "2019-12-04T18:10:20Z")
Interesting :-). Thanks for the pointer!