[Insight-users] ITK memory usage

[Luis Ibanez]

Hi Tom,

Thanks for your detailed description.

The example that you are using, computes Multi-Resolutions images
by using "float" as pixel type.

See lines 487-488

>   typedef   float     InternalPixelType;
>   typedef itk::Image< InternalPixelType, Dimension > InternalImageType;

So your image of 155 Mb is converted in to 300Mb in the first
pyramid level, and 38Mb in the second level. The reader still
holds the original image at 155Mb.

I assume that on the 2D image you are loading a Fluoroscopy image
that is usually in the order of 1024x1024 pixels at 2 bytes / pixel,
which is about 2 Mb. Is that right.

Once you feed the high resolution image into the registration
method, the Metric is going to compute the gradient of the image.
This is done in order to accelerate the computation of the Metric
derivatives. That gradient image will have 3 components per pixel
and may presumably be of type float. That will take 900Mb.

By putting all these pieces together it is plausible to get to the
2Gb limit for one process.

You may want to start by adding the ReleaseDataFlag to the readers
or actually destroying the readers once you have computed the
Multi-Resolution pyramids. Note that the example is using pyramid
both for the 2D and the 3D image.


One easy way to track the memory consumption is to insert a number
of printouts on the images, something like:


std::cout<< image->GetBufferedRegion().GetNumberOfPixels() <<std::endl;
image->Print( std::cout );

This will allow you to track the places where memory is being taken.


A pragmatic approach to work with multi-resolution is to avoid
the Pyramids and manually do the sub sampling. Solve one resolution
level and then move to the next.


Please let us know what you find.


    Thanks



       Luis


-----------------------
Tom Radcliffe wrote:
> I'm playing around with 2D/3D registration using the example code:
> IntensityBased2D3DRegistration.cxx (tweaked slightly to read a DICOM
> image series rather than a single volume file) and it runs out of memory
> on a volume of 512X512X296.  This is on Windows running a few other apps
> at the same time, but the reported message is "failure to allocate
> memory" at the image input stage.  The volume data are shorts, so it's
> only 155 MB, and on Windows the per-process memory limit is 2GB.  So I'm
> surprised that memory is being exhausted.  I can read the volume in for
> other purposes (DRR generation, for example) with no difficulty.
> 
> The memory exhaustion seems to be taking place in the update call to the
> moving image pyramid, and I haven't tracked it down to a lower level
> than that yet.  Has anyone hit up against this kind of thing?  Any
> pointers before I plunge into the lower levels of the code would be
> appreciated.
> 
> The complete debug output of the run is:
> 
> 0 0 236 2
> 0 1 236 2
> 0 2 1 1
> 1 0 473 1
> 1 1 473 1
> 1 2 1 1
> MultiResolutionPyramidImageFilter (00D56F80)
>   RTTI typeinfo:   class itk::MultiResolutionPyramidImageFilter<class
> itk::Image
> <float,3>,class itk::Image<float,3> >
>   Reference Count: 2
>   Modified Time: 36
>   Debug: Off
>   Observers:
>     none
>   Number Of Required Inputs: 1
>   Number Of Required Outputs: 2
>   Number Of Threads: 1
>   ReleaseDataFlag: Off
>   ReleaseDataBeforeUpdateFlag: Off
>   No Inputs
>   Output 0: (00D58EB0)
>   Output 1: (00D590C8)
>   AbortGenerateData: Off
>   Progress: 0
>   Multithreader:
>     RTTI typeinfo:   class itk::MultiThreader
>     Reference Count: 1
>     Modified Time: 20
>     Debug: Off
>     Observers:
>       none
>     Thread Count: 1
>     Global Maximum Number Of Threads: 0
>   No. levels: 2
>   Schedule:
> [2, 2, 2]
> [1, 1, 1]
> 
> MultiResolutionPyramidImageFilter (00D54AC8)
>   RTTI typeinfo:   class itk::MultiResolutionPyramidImageFilter<class
> itk::Image
> <float,3>,class itk::Image<float,3> >
>   Reference Count: 2
>   Modified Time: 9161
>   Debug: Off
>   Observers:
>     none
>   Number Of Required Inputs: 1
>   Number Of Required Outputs: 2
>   Number Of Threads: 1
>   ReleaseDataFlag: Off
>   ReleaseDataBeforeUpdateFlag: Off
>   No Inputs
>   Output 0: (00D56A88)
>   Output 1: (00D56DB8)
>   AbortGenerateData: Off
>   Progress: 0
>   Multithreader:
>     RTTI typeinfo:   class itk::MultiThreader
>     Reference Count: 1
>     Modified Time: 2
>     Debug: Off
>     Observers:
>       none
>     Thread Count: 1
>     Global Maximum Number Of Threads: 0
>   No. levels: 2
>   Schedule:
> [2, 2, 1]
> [1, 1, 1]
> 
> ExceptionObject caught !
> 
> itk::ExceptionObject (0012EE88)
> Location: "ImportImageContainer::AllocateElements"
> File:
> c:\software\3rd_party\insighttoolkit-1.8.1\code\common\itkimportimagecon
> tainer.txx
> Line: 186
> Description: Failed to allocate memory for image.
> 
> And the process dies with a signal 127.
> 
> I'm wondering if fiddling with the ReleaseData flags might help, but the
> failure is happening so early that it doesn't seem a likely fix.  As I
> said, any pointers appreciated.  The only change I've made in the
> example code is to read a DICOM series rather than a single volume file.
> 
> Thanks,
> Tom
> 
> Tom Radcliffe, Ph.D., P.Eng.
> Chief Scientific Officer
> Improved Outcomes Software Inc.
> 613-549-6666 x4224
> 
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 2005-01-06
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
> 
>