[Insight-users] fast binary dilate image filter
Gaetan Lehmann
gaetan.lehmann at jouy.inra.fr
Mon Sep 19 10:49:40 EDT 2005
Hi,
I have modified binary erode and dilate filter to use the Jerome's
threaded version and include the code below. All test pass now.
I have also used "static_cast<typename NumericTraits<InputPixelType>" to
display background and foreground values.
Jim, can you include the attached files in CVS ?
Thanks,
Gaetan
On Fri, 16 Sep 2005 05:22:49 +0200, SCHMID, Jerome
<jeromeschmid at surgery.cuhk.edu.hk> wrote:
> Hi Gaetan,
>
> Pleased also to see that James found the time to implement both versions
> and add it to the CVS!
>
> Concerning the padding you are right by saying that there might be a pb
> with the border pixels. I think that the region of the
> tmpRequestedRegion must be padded by the maximum of (The size of the
> structuring element, The size of the connectivity element (typically
> one) ):
>
>
> m_PadBy = m_Radius;
> for (unsigned int i=0; i < KernelDimension; ++i)
> {
> m_PadBy[i] =
> (m_PadBy[i]>m_Kernel.GetRadius(i) ? m_PadBy[i] :
> m_Kernel.GetRadius(i));
> }
>
> tmpRequestedRegion.PadByRadius( m_PadBy );
>
> (this snippet is from my old filter)
>
> I tested you prgm with my old filter of september 2004 and crop.png is
> the same as crop2.png. I have investigated in details the filter of Jim
> and cannot say if the pb is exactly there or not. I don't know either if
> the pb comes from the "fusion" of both implementations that introduce
> some errors.
>
> Best Regards,
>
> Jerome Schmid
>
> -----------------------------------
> Jerome SCHMID
> Project Manager/ Engineer
> Augmented and Virtual Reality
> MIS Centre
> Prince of Wales Hospital
> Chinese University Of Hong-Kong
> -----------------------------------
>
>
>
> -----Original Message-----
> From: insight-users-bounces+jeromeschmid=surgery.cuhk.edu.hk at itk.org on
> behalf of Gaetan Lehmann
> Sent: Thu 9/15/2005 11:42 PM
> To: Gaetan Lehmann; Miller, James V (Research)
> Cc: insight-users at itk.org
> Subject: Re: [Insight-users] fast binary dilate image filter
>
> 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: files.tgz
Type: application/x-gzip
Size: 11113 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/insight-users/attachments/20050919/1289d68c/files.bin
More information about the Insight-users
mailing list