[Insight-users] Evolution : overall pipeline memory print

[Julien Michel]

Karthik Krishnan a écrit :
> 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.

Karthik,

Thanks a lot for your response. I agree with you on the fact that the
GetMemoryPrint() method will not apply to all DataObjects. Regarding the 
  step where to call the GetPipelineMemoryPrint() method, I was indeed 
planning to do this after a 
itk::ProcessObject::GenerateOutputInformation() and a 
GenerateInputRequestedRegion() (otherwise it as no meaning at all).
I was hoping that minipipeline would be processed seamlessly by the 
recursive call, but maybe I get it wrong.

 > 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.

Well in our toolkit we recommend the use of VectorImage, from which we 
can retrieve the pixel number of components afther an 
UpdateOutputInformation(), at run time (but before the 
UpdateOutputData()). This is not a problem for us because we always have 
the same number of components for all pixels (our images beeing acquired 
by remote sensors). Anyway I agree that this does not fit the generic case.

We need to adress this memory problem. The best would be to know the 
peak memory usage, but I think we could do well with the overall 
pipeline memory usage, even if it is only an estimate that takes into 
account only those DataObjects for which we can compute the memory 
print. But put this way it sounds more like a workaround and I 
understand that ITK would not like to have a workaround stuck into its 
very base classes. We would welcome any other suggestion on idea to 
solve this problem :o)

Thanks a lot for your reply, and for ITK itself,

Best regards,

Julien MICHEL