[Insight-users] fast binary dilate image filter

Thu Sep 15 11:42:15 EDT 2005

The same bug is in dilate version, but the change I have sent in previous  
mail in not enough to solve the problem :-(
I have attached a small program to verify it.
It should be a good idea to add a similar program in tests

Gaetan

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

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bw4.png
Type: image/png
Size: 245 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/insight-users/attachments/20050915/693b7346/bw4.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: myProject.cxx
Type: application/octet-stream
Size: 1820 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/insight-users/attachments/20050915/693b7346/myProject.obj