A less obtrusive and more trivial change might be to add an overloaded constructor to the flood fill iterator that reads :<br><br> Iterator( imagePtr, fnPtr, seedList, exclusionImagePtr)<br>  <br>This constructor would simply look exactly like the other constructor, except that it instead of calling InitializeIteration(), (which creates a new m_TemporaryPtr), it would set m_TemporaryPtr to exclustionImagePtr itself.<br>
<br>What do you think ?<br><br>Thanks<br><br><br><div class="gmail_quote">On Wed, Aug 12, 2009 at 4:48 PM, David Doria <span dir="ltr">&lt;<a href="mailto:daviddoria%2Bitk@gmail.com">daviddoria+itk@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">My goal was to add the functionality of &quot;remembering&quot; which regions have been marked as &quot;filled&quot; so the regions grown after multiple region growing iterations will be mutually exclusive.<br>
<br>Ie. <br>
Set seed1<br>Grow region A<br>Set seed 2<br>Grow region B<br><br>A and B should not contain any of the same pixels.<br><br>I spoke with Luis and he thought I should just be able to modify itkFloodFilledFunctionConditionalConstIterator to prevent it from clearing m_TemporaryPointer. The problem with that was that the region growing filters (I was using itkConnectedThresholdImageFilter as an example) construct a new floodfill iterator <br>

IteratorType it ( outputImage, function, m_SeedList );<br><br>each time GenerateData() is called. Therefore there is no way to keep track of the m_TemporaryPointer in the FF class (i.e. prevent it from being deleted) because a different FF instance is generated each time a region is created.<br>

<br>The way I fixed it is by changing itkConnectedThresholdImageFilter to have a member pointer to a FF iterator<br>IteratorType* floodfill_iterator;<br><br>and an instance counter:<br>unsigned int m_InstanceCounter;<br>
<br>
so that in GenerateData() I could do:<br><br>         if(m_InstanceCounter == 0)<br>         {<br>            //IteratorType it ( outputImage, function, m_SeedList );<br>             floodfill_iterator = new IteratorType( outputImage, function, m_SeedList );<br>

         }<br>         else<br>         {<br>             floodfill_iterator-&gt;FakeConstructor( outputImage, function, m_SeedList );<br>         }<br>         m_InstanceCounter++;<br><br>It is working exactly how I want (see <a href="http://www.rpi.edu/%7Edoriad/ITK_List/itkFloodFilledFunctionConditionalConstIterator2.zip" target="_blank">http://www.rpi.edu/~doriad/ITK_List/itkFloodFilledFunctionConditionalConstIterator2.zip</a>), but I&#39;m concerned that it is not an *elegant* enough solution - as it would require a change in every region growing class. I didn&#39;t want to write up an IJ paper about what I did because maybe someone will say &quot;bah that was silly, just do this...&quot;.<br>

<br>Thoughts?<br><br clear="all">Thanks,<br><font color="#888888"><br>David<br>
</font><br>_____________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the ITK FAQ at: <a href="http://www.itk.org/Wiki/ITK_FAQ" target="_blank">http://www.itk.org/Wiki/ITK_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">http://www.itk.org/mailman/listinfo/insight-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Karthik Krishnan<br>R&amp;D Engineer,<br>Kitware Inc.<br>Ph: 518 881 4919<br>Fax: 518 371 4573<br>