<div>Luis,</div>
<div> </div>
<div>I just checked in a test, Testing/Code/Common/itkObjectFactoryTest2,cxx that exercises the factory load from a library code in itkObjectFactoryBase.cxx. The test provides a factory-based ImportImageContainer that does some simple memory allocation reporting. It might stimulate some further ideas on how to report memory usage.
</div>
<div> </div>
<div>We'll see if the object loading is portable across ITK systems. I already had to exclude the test from the Borland build because of problems. I'll leave it out of the Borland build until I can track down the problem.
</div>
<div> </div>
<div>Bill<br><br></div>
<div class="gmail_quote">On Nov 9, 2007 11:58 AM, Luis Ibanez <<a href="mailto:luis.ibanez@kitware.com">luis.ibanez@kitware.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>Hi Julien,<br><br><br>We will discuss this topic further today during the ITK tcon.<br><br><br>I agree with Karthik that it is not a trivial problem to solve,
<br>but also agree with you that it is a problem worth looking at.<br><br><br>Images are only going to get bigger...<br>and they will do so a lot faster than computer memory is<br>going to get cheaper. :-/<br><br><br>We have also challenging situations when dealing with microscopy
<br>data from sources such as electron microscopy and confocal<br>microscopy...<br><br><br><br>One way of simulating the memory behavior of the pipeline<br>is to overload/intercept the image method Allocate(), and<br>have it report its memory request to a central log, instead
<br>of actually allocating the memory, then having the pixel<br>container simulate that it actually have allocated the<br>memory and return a constant (or a random) value for every<br>pixel request. It may be done also by intercepting the
<br>method "AllocateElements(size)" in the itkImportImageContainer,<br>which is where the memory allocation is ultimately done.<br>(Note that even the itkVectorImage delegates memory allocation<br> to its internal ImportImageContainer).
<br><br><br><br>By running your pipeline in such mode, it will be possible<br>to collect the *actual* memory allocation requests, instead<br>of the *estimated* ones from every filter, that as Karthik<br>pointed out, will be very hard to do in a reliably way for
<br>the entire toolkit.<br><br><br>In that mode, then you could experiment with different<br>image partition strategies, for example the ones in the<br>StreamingImageFilter. These strategies are managed by<br>the RegionSplitter classes. You could by trial an error
<br>identify what size of image pieces would make possible<br>to run the pipeline in the amount of memory that is<br>actually available in the hardware.<br><br><br>The drawback of this method is that it still will use the
<br>CPU time of actually computing the output of the filters,<br>instead of just making a pass to estimate the memory<br>footprint of the toolkit....<br><br><br>You may have other ideas on how to implement other<br>memory estimation strategies.
<br><br><br><br>We certainly agree that if such functionality is developed<br>it will be much better to add it to ITK than to have it<br>in your local copy of the toolkit.<br><br><br><br> Regards,<br><br><br> Luis
<br><br><br><br>-------------------------<br>
<div>
<div></div>
<div class="Wj3C7c">Julien Michel wrote:<br>> Karthik Krishnan a écrit :<br>><br>>> Julien:<br>>><br>>> I can understand your issue with being bogged down by memory. However,<br>>> I don't completely agree with your proposed solution. Here are my
<br>>> disagreements.<br>><br>><br>> Karthik,<br>><br>> Thanks a lot for your response. I agree with you on the fact that the<br>> GetMemoryPrint() method will not apply to all DataObjects. Regarding the
<br>> step where to call the GetPipelineMemoryPrint() method, I was indeed<br>> planning to do this after a<br>> itk::ProcessObject::GenerateOutputInformation() and a<br>> GenerateInputRequestedRegion() (otherwise it as no meaning at all).
<br>> I was hoping that minipipeline would be processed seamlessly by the<br>> recursive call, but maybe I get it wrong.<br>><br>> > In that case, we do not know about the run-time pixel sizes as<br>> > illustrated in point 1. It would work for for images where the
<br>> > pixel-size information is known at build time.<br>><br>> Well in our toolkit we recommend the use of VectorImage, from which we<br>> can retrieve the pixel number of components afther an<br>> UpdateOutputInformation(), at run time (but before the
<br>> UpdateOutputData()). This is not a problem for us because we always have<br>> the same number of components for all pixels (our images beeing acquired<br>> by remote sensors). Anyway I agree that this does not fit the generic case.
<br>><br>> We need to adress this memory problem. The best would be to know the<br>> peak memory usage, but I think we could do well with the overall<br>> pipeline memory usage, even if it is only an estimate that takes into
<br>> account only those DataObjects for which we can compute the memory<br>> print. But put this way it sounds more like a workaround and I<br>> understand that ITK would not like to have a workaround stuck into its
<br>> very base classes. We would welcome any other suggestion on idea to<br>> solve this problem :o)<br>><br>> Thanks a lot for your reply, and for ITK itself,<br>><br>> Best regards,<br>><br>> Julien MICHEL
<br>> _______________________________________________<br>> Insight-users mailing list<br>> <a href="mailto:Insight-users@itk.org">Insight-users@itk.org</a><br>> <a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">
http://www.itk.org/mailman/listinfo/insight-users</a><br>><br><br>_______________________________________________<br>Insight-users mailing list<br><a href="mailto:Insight-users@itk.org">Insight-users@itk.org</a><br><a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">
http://www.itk.org/mailman/listinfo/insight-users</a><br></div></div></blockquote></div><br>