[Insight-users] Evolution : overall pipeline memory print

[Karthik Krishnan]

Julien:

I can understand your issue with being bogged down by memory. However, I
don't completely agree with your proposed solution. Here are my
disagreements.

On 11/8/07, Julien Michel <julien.michel at c-s.cnes.fr> wrote:
>
> For instance, in itk::Image, the GetMemoryPrint() implementation would be:


1. Its hard to do this for all dataobjects. They will require information
available only at run-time.
Consider itk::Image< itk::VariableLengthVector< double > >. This will in
reality require you to traverse each pixel and find out its size.
You will notice that there are several dataobjects that fit this
description.

- in itk::ProcessObject
>         size+=this->GetOutput(idx)->GetMemoryPrint();
>         size+=
>         this->GetInput(idx)->GetSource()->GetPipelineMemoryPrint();
>         }


2. This is based on the assumption that the outputs have already been
generated. That would defeat your purpose, since your intention is to use
this as a query prior to updating.
Let's assume that we are smarter and stick this somewhere during the
pipeline information update stage (which occurs before the data-update
stage), sometime after itk::ProcessObject::GenerateOutputInformation() /
GenerateInputRequestedRegion().

In that case, we do not know about the run-time pixel sizes as illustrated
in point 1. It would work for for images where the pixel-size information is
known at build time.

3. All this is considering is memory related to filter inputs and outputs.
Let's take filters that have mini-pipelines etc. The
HessianRecursiveGaussian is one such beast that uses a series of filters
inside, as many as the image dimension.

4. Then there is the argument. Are we talking about the peak memory usage or
the memory of the pipeline itself.

I think is a fairly tricky problem to address.

Regards
-- 
Karthik Krishnan
R&D Engineer,
Kitware Inc.
Ph: 518 371 3971 x119
Fax: 518 371 3971
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20071108/00405a6d/attachment.html