[Insight-users] fast binary dilate image filter
SCHMID, Jerome
jeromeschmid at surgery.cuhk.edu.hk
Thu Sep 15 23:22:49 EDT 2005
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
More information about the Insight-users
mailing list