[Insight-users] ITK Image Memory Layout (now as text)

[Jakob Schluttig]

Hi John,

many thanks for your quick reply!

2012/6/29 John Drescher <drescherjm at gmail.com>:
>> First I have to apologize my first post this morning which was sent as
>> html by accident :( . Sorry!
>>
>> I am very new to ITK and have a probably very simple question I could
>> not find a clear answer for using google and the standard
>> documentation (I also skipped through the Doxygen documentation, but I
>> was not able to dive into the code as deep as the answer to my
>> question would require :( ).
>>
>> 3D data typically requires large amounts of memory - in the orders of
>> 100MB - 1000MB . It is typically not a good idea to allocate data
>> ranges that large as a single big chunk of memory.
>
> I would think this would be a problem mostly on 32 bit systems or
> compiling for 32 bit on 64 bit systems. If you can go to 64 bit. I
> have moved a few years ago and its much easier not to worry at all
> about running out of contiguous address space.

I do not fully agree that moving to 64bit solves the contiguous memory
problem. Especially in complex mixed managed/unmanaged environments,
memory can still be to subject to defragmentation and other
undesirable effects. We have dealt with such problems a lot in the
past. It is quite simple to construct example code where allocating
large chunks (1GB) of data won't succeed even if there seems to be
enough free memory.

>>So I wonder: If I
>> set up a large 3D image with ITK - is the memory split up internally
>> (like volume slices or whatever)? Or does ITK try to do something like
>> (probably a bit oversimplified, but it should make clear what I mean)
>> :
>>
>> float *p = new p [1024*1024*1024];
>>
> This is the way itk::Image allocates its memory.
>
> http://www.kitware.com/products/html/AlternativeMemoryModelsForITK.html

Yes! This is exactly what I was looking for!

Many thanks again and bests,
Jakob