[Insight-users] fast binary dilate image filter
Gaetan Lehmann
gaetan.lehmann at jouy.inra.fr
Mon Oct 10 03:45:22 EDT 2005
Hi Jim,
Can you have a look at the files attached in the previous mail and include
it in the CVS ?
I think it's better to include those changes quickely so it can be heavily
tested before the next release :-)
Thanks,
Gaetan
On Mon, 19 Sep 2005 16:49:40 +0200, Gaetan Lehmann
<gaetan.lehmann at jouy.inra.fr> wrote:
>
> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
--
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
http://voxel.jouy.inra.fr
More information about the Insight-users
mailing list