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

[Dan Mueller]

Hi Jakob,

"Alternative Memory Models for ITK Images" is an Insight Journal
article, with full source code, which can be found here:
    http://www.insight-journal.org/browse/publication/646

It was written for ITK 3.x, so may need some work to port it to ITK
4.0. This contribution is not part of ITK proper. You need to download
the source code with the article.

The alternate memory layouts (slice contiguous, sparse, single-bit)
work with _any_ filter which accesses pixels using iterators only.
They do not work for filters which bypass this layer of abstraction
and directly access the pixel buffer via GetBufferPointer (e.g. image
IO, export to VTK, optimized registration framework).

The biggest drawback of these classes is that they do not (currently)
work with image IO. This means that if you read an image from disk
using the standard ITK image IO, it will have the standard contiguous
memory layout. The only way to use the slice contiguous memory model
for example is if you read each slice separately and manually create
your own 3d image from each slice. However, once you have done this,
filter pipelines will work as expected. I wrote these classes
(especially slice contiguous memory model) so that I could integrate
ITK with an in-house application which read a DICOM image as slice
contiguous memory blocks.

HTH

Cheers, Dan Mueller

On 29 June 2012 23:20, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> 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
>
>
>
>
>
> _____________________________________
> 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
>