<div>Luis,</div>
<div>&nbsp;</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>&nbsp;</div>
<div>We&#39;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&#39;ll leave it out of the Borland build until I can track down the problem.
</div>
<div>&nbsp;</div>
<div>Bill<br><br></div>
<div class="gmail_quote">On Nov 9, 2007 11:58 AM, Luis Ibanez &lt;<a href="mailto:luis.ibanez@kitware.com">luis.ibanez@kitware.com</a>&gt; 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. &nbsp; :-/<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 &quot;AllocateElements(size)&quot; in the itkImportImageContainer,<br>which is where the memory allocation is ultimately done.<br>(Note that even the itkVectorImage delegates memory allocation<br>&nbsp;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. &nbsp;These strategies are managed by<br>the RegionSplitter classes. &nbsp;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>&nbsp; &nbsp;Regards,<br><br><br>&nbsp; &nbsp; &nbsp; &nbsp;Luis
<br><br><br><br>-------------------------<br>
<div>
<div></div>
<div class="Wj3C7c">Julien Michel wrote:<br>&gt; Karthik Krishnan a écrit :<br>&gt;<br>&gt;&gt; Julien:<br>&gt;&gt;<br>&gt;&gt; I can understand your issue with being bogged down by memory. However,<br>&gt;&gt; I don&#39;t completely agree with your proposed solution. Here are my
<br>&gt;&gt; disagreements.<br>&gt;<br>&gt;<br>&gt; Karthik,<br>&gt;<br>&gt; Thanks a lot for your response. I agree with you on the fact that the<br>&gt; GetMemoryPrint() method will not apply to all DataObjects. Regarding the
<br>&gt; &nbsp;step where to call the GetPipelineMemoryPrint() method, I was indeed<br>&gt; planning to do this after a<br>&gt; itk::ProcessObject::GenerateOutputInformation() and a<br>&gt; GenerateInputRequestedRegion() (otherwise it as no meaning at all).
<br>&gt; I was hoping that minipipeline would be processed seamlessly by the<br>&gt; recursive call, but maybe I get it wrong.<br>&gt;<br>&gt; &nbsp;&gt; In that case, we do not know about the run-time pixel sizes as<br>&gt; &nbsp;&gt; illustrated in point 1. It would work for for images where the
<br>&gt; &nbsp;&gt; pixel-size information is known at build time.<br>&gt;<br>&gt; Well in our toolkit we recommend the use of VectorImage, from which we<br>&gt; can retrieve the pixel number of components afther an<br>&gt; UpdateOutputInformation(), at run time (but before the
<br>&gt; UpdateOutputData()). This is not a problem for us because we always have<br>&gt; the same number of components for all pixels (our images beeing acquired<br>&gt; by remote sensors). Anyway I agree that this does not fit the generic case.
<br>&gt;<br>&gt; We need to adress this memory problem. The best would be to know the<br>&gt; peak memory usage, but I think we could do well with the overall<br>&gt; pipeline memory usage, even if it is only an estimate that takes into
<br>&gt; account only those DataObjects for which we can compute the memory<br>&gt; print. But put this way it sounds more like a workaround and I<br>&gt; understand that ITK would not like to have a workaround stuck into its
<br>&gt; very base classes. We would welcome any other suggestion on idea to<br>&gt; solve this problem :o)<br>&gt;<br>&gt; Thanks a lot for your reply, and for ITK itself,<br>&gt;<br>&gt; Best regards,<br>&gt;<br>&gt; Julien MICHEL
<br>&gt; _______________________________________________<br>&gt; Insight-users mailing list<br>&gt; <a href="mailto:Insight-users@itk.org">Insight-users@itk.org</a><br>&gt; <a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">
http://www.itk.org/mailman/listinfo/insight-users</a><br>&gt;<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>