[Insight-users] fast binary dilate image filter

[SCHMID, Jerome]

Miller, James V (Research) 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?
>
Hi James,

Well what I meant about redundancy is that when you use threading the image is tiled into several regions. For a given region you have to enlarge it because you need to know if pixel at the boundary of this region are or not surface pixels. So the redundancy comes when in two adjacent regions you will perform the same process of pixel analysis in order to test whether or not you are dealing with surface pixels. There is not an easy and efficient way to record the property of a pixel as border pixel and to _share_ this info between threads. But of course the idea is that the redundancy can be insignifiant compared with the time saved by  a real parallel processing  (i.e. on several processors, not a threads or process on a same CPU ).

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

Well it seems that the sharing is possible, but like you I haven't investigated it yet. I agree with you that a fast version should be better in the future.

>
>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
>
>
Looks good. When you do it, if you need some help I can try to have a look ( I can try.....! ). BTW thanks for your efforts.

Jerome

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