[Insight-users] fast binary dilate image filter

Thu Sep 15 08:37:03 EDT 2005

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?

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