[Insight-users] fast binary dilate image filter

Thu Sep 15 10:11:33 EDT 2005

On Thu, 15 Sep 2005 14:37:03 +0200, Miller, James V (Research)  
<millerjv at crd.ge.com> wrote:

> Gaetan,
>
> I saw the two implementations had different GenerateInputRequestedRegion
> methods when I was reconciling them.  However, I do not see why they need
> different versions.
>
> What the current code does is pad by the larger of the m_Radius (1  
> pixel) and
> the size of the kernel.  The m_Radius pad is needed for the determining  
> the object
> boundary points and the kernel pad is needed for the actual  
> dilation/erosion. I
> think this should be the appropriate pad for both dilation/erosion.  Do  
> you
> think otherwise?

Hum...
I missed that the Dilate version also pad by the kernel radius, and your  
right, the input resquested region must be increase for the dilate version  
too. The problem should be somewhere else. Also, it's strange because I  
already have that problem when modifying dilate version to build erode  
version and solve it by rewriting the GenerateInputRequestedRegion()  
method.

>
> So I think the problem is somewherelse.  None of our current tests  
> picked up this
> issue.  Can you send me the image that you are performing the binary  
> closing on?
> I can then put in a regression test using your "right.png" as the  
> baseline.  This will
> help me track down the problem.

It's the test of the BinaryMorphologicalClosingImageFilter
You can get it from

http://voxel.jouy.inra.fr/darcs/itk-mima2/Insight/Testing/Code/BasicFilters/itkBinaryMorphologicalClosingImageFilterTest.cxx
http://voxel.jouy.inra.fr/darcs/itk-mima2/Insight/Testing/Data/Baseline/BasicFilters/BinaryMorphologicalClosingImageFilterTest.png

and the filter is available from

http://voxel.jouy.inra.fr/darcs/itk-mima2/Insight/Code/BasicFilters/itkBinaryMorphologicalClosingImageFilter.h
http://voxel.jouy.inra.fr/darcs/itk-mima2/Insight/Code/BasicFilters/itkBinaryMorphologicalClosingImageFilter.txx

>
> It could be a boundary condition problem, where the wrong boundary value  
> is used for
> the erosion.
>
> Jim
>
>
> -----Original Message-----
> From: Gaetan Lehmann [mailto:gaetan.lehmann at jouy.inra.fr]
> Sent: Thursday, September 15, 2005 7:50 AM
> To: Miller, James V (Research)
> Cc: insight-users at itk.org
> Subject: Re: [Insight-users] fast binary dilate image filter
>
>
>
> Hi Jim,
>
> I see you have replaced binary dilate/erode filters with the fast
> incremental version. Great !
> However, the replacement of my classes by yours break my test. It seems
> that the border problems are back.
> I think it's because the GenerateInputRequestedRegion method should not  
> be
> shared between the 2 classes (erode filter need the output region padded
> by the kernel radius), but I haven't investigated it more.
> I attach the right and the wrong result of a binary closing, just to show
> what I call border problems. We shouldn't see the deformations on the
> bottom and on the right.
> To avoid border problems during the closing, I add a border to the image
> with a ConstantPadImageFilter, do the closing, and remove the border with
> a CropImageFilter. CropImageFilter requires a smaller input image than  
> the
> output image from the BinaryErodeImageFilter , which make the border
> problems appear where they shouldn't.
>
> Regards,
>
> Gaetan
>
>
> On Tue, 06 Sep 2005 16:32:07 +0200, Miller, James V (Research)
> <millerjv at crd.ge.com> wrote:
>
>> Ahh, this sounds like my bad.  I thought I had put in the most recent
>> version of the
>> filter.  I guess I missed the threaded version.
>>
>> I'll try to take a look at the threaded portions.  The merge will be a
>> bit tricky since we made
>> changes to support cross platform builds (mostly the use of typename).
>> But at first glance,
>> it looks as though the section of the algorithm to prepare the output
>> has been moved into
>> the BeforeThreadedGenerate method.  In your message from last September
>> you mentioned something
>> about the multithreaded version may run a bit slower than the previous
>> version when on a single
>> processor machine.  Something about some code redundancy.  Can you point
>> to me that section
>> of the code?
>>
>> As Gaetan noted, he submitted an erosion version of the algorithm.  I am
>> poised to add that
>> filter to ITK as well.  My current thinking is to have
>> FastIncrementBinaryDilate/Erode
>> become BinaryDilate/Erode and make the current
>> FastIncrementalBinaryDilate an empty subclass
>> of BinaryDilate to maintain backward compatibility.
>>
>> I did not look to see how much of the code could be shared between the
>> FastIncrementalDilate and
>> FastIncrementalErode.  I suspected a good bit of the code could be
>> shared but I haven't the time
>> to investigate.
>>
>> I may do the following (no timeline on when):
>>
>> 1. Supplant the current BinaryDilate/Erode with the Incremental  
>> versions.
>> 2. Add the threading changes to the dilate code.
>> 3. Propagate the threading changes to the erode code.
>> 4. Refactor to take shared code from the dilate/erode to some  
>> superclass.
>>
>> Thanks.
>> Jim
>>
>>
>> -----Original Message-----
>> From: insight-users-bounces+millerjv=crd.ge.com at itk.org
>> [mailto:insight-users-bounces+millerjv=crd.ge.com at itk.org]On Behalf Of
>> SCHMID, Jerome
>> Sent: Friday, September 02, 2005 12:28 AM
>> To: insight-users at itk.org
>> Subject: [Insight-users] fast binary dilate image filter
>>
>>
>> Hi,
>>
>> After a long time I am back to the itk list as I find a job elsewhere.
>> Anyway this is not the topic of the mail...
>>
>> It concerns a filter I wrote on fast binary dilation for itk. At that
>> time ( about 1 year ago... ) I was speaking with James Miller about
>> this. Before I quit my previous job the filter hadn't been fully
>> reviewed or validated, I thought that it was lost :-)
>>
>> Anyway I found a thread about this filter in last April (yeah sorry to
>> talk about old things),
>>
>> http://public.kitware.com/pipermail/insight-users/2005-April/012583.html
>>
>> and I discover with pleasure that the filter has been integrated by
>> James. However James wonder if I made some modifications to it since.
>> The answer is no as I haven't access now to my previous work.
>>
>> However I wonder if James tried to test the threadable aspect of the
>> filter that I implemented at that time. The last version of the filter I
>> submited should be in the old following thread:
>>
>> http://public.kitware.com/pipermail/insight-users/2004-September/010538.html
>>
>> Our concern was the safety of some operations. At that time I tested it
>> and it seemed to work. The current implementation
>> itk::FastIncrementalBinaryDilateImageFilter hasn't the threadable aspect
>> available.
>>
>> I hope I can find the time one day to have a deeper look on it.
>>
>> Best Regards,
>>
>> Jerome Schmid
>>
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>
>
>

-- 
Gaetan Lehmann <gaetan.lehmann at jouy.inra.fr>
Tel: +33 1 34 65 29 66
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
Web: http://voxel.jouy.inra.fr