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

Bradley Lowekamp blowekamp at mail.nih.gov
Fri Jun 29 09:50:09 EDT 2012


Hello Jakob,

I'd like to hear more about the problem you are experiencing which leads you go believe that continuously allocating 100MB-1000MB of memory is problematic?

I don't believe the itk::SliceContiguousImage was part of the recent ITKv3 releases:
http://www.itk.org/Doxygen320/html/classes.html

I have never tried to use this Image class, but knowing how many of the iterators and filters work, it would be rather difficult to know which filters and algorithms worked with this type of memory layout. So I am going to assume that due to compatibility reasons this Image class may never have been incorporated into ITK proper.

Brad


On Jun 29, 2012, at 8:42 AM, Jakob Schluttig wrote:

> Hi,
> 
> sorry for bothering again, but it seems that itk::SliceContiguousImage
> - which would have been what I was looking for - is not part of ITK
> 4.2 anymore.
> 
> Do you (or does anyone) know why?
> 
> Bests,
> Jakob
> 
> 
> 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.
>> 
>>> 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
>> 
>> John
> _____________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.php
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users

========================================================
Bradley Lowekamp  
Medical Science and Computing for
Office of High Performance Computing and Communications
National Library of Medicine 
blowekamp at mail.nih.gov



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20120629/c58e2c24/attachment.htm>


More information about the Insight-users mailing list