[Insight-users] fast binary dilate image filter

Thu Sep 15 10:37:46 EDT 2005

On Thu, 15 Sep 2005 16:11:33 +0200, Gaetan Lehmann  
<gaetan.lehmann at jouy.inra.fr> wrote:

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

I think I have found the problem:
in itkBinaryErodeImageFilter.txx, line 76,

   tmpRequestedRegion.PadByRadius( radius );

should be;

   tmpRequestedRegion.PadByRadius( this->GetKernel().GetRadius() );

I'm don't know if the region should be only padded by kernel radius, or if  
it should be padded by kernel radius + neighborhood radius.

And dilate version should also need the same change.

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