[Insight-users] Fast binary morphology dilation

[jerome schmid]

James,

Thanks for your long explanation now it is clear. I hope that streaming will
not remove some efficienty of the filter, because if you have a very huge SE
you will have more process in the "padded band". Nevertheless if the filter
is present in a pipeline fully threaded, a lot of time can be saved.

Well it seems that threading this filter won't be easy....! If you need some
help or precisions, advice.

Regards,

Jerome



-----Message d'origine-----
De : Miller, James V (Research) [mailto:millerjv at crd.ge.com]
Envoyé : mardi 14 septembre 2004 21:30
À : 'jerome schmid'; Miller, James V (Research)
Cc : insight-users at itk.org
Objet : RE: [Insight-users] Fast binary morphology dilation


Jerome,

The complexity of "padding" the input is with respect to supporting
streaming.
Let's say I have an image which 100x100 pixels.  I could process the entire
image at once.  But suppose I only want to operate on the middle 50x50
pixels, so that my output image is only 50x50 pixels.  I want the
"boundary pixels" of this 50x50 region to be correct, in that they are
exactly the same values as I would have gotten if I had filtered the
entire 100x100 pixel image and then cropped out the middle 50x50 piece.

The question is how hard is it to support this in this algorithm.  If I was
doing a convolution with a 5x5 kernel, I would simply "pad" the input
requested region by 2 pixels on each side (+-x, +-y).  Then when I went to
calculate the
output pixels on the boundary of the 50x50 region, I know the input pixels
that are outside the output 50x50 region are valid input pixels (if the
subregion
under consideration was closer to the boundary of the input's
LargestPossibleRegion, I would know the input pixels that are outside the
output 50x50 region either valid input pixels OR are prescribed boundary
condition pixels).

For the sake of Minkowski addition, let's say my structuring element has
radius [0, 5] and has a single "on" pixel at offset [0, 5].  The result of
the dilation should shift my image vertically by 5 pixels.  So to generate
the pixels in the output requested region, I would need to know input pixel
values that are 5 pixels outside the output requested region.  Therefore,
my GenerateInputRequestedRegion() method will need to pad the output
requested region by maximum of the radius of my structuring element and
the radius neighborhood connectivity.

The trick I see for the surface tracking in this context is being able to
distinguish between the border of the image and the border of an object.
You track surfaces off the edge of the image. (I think this can be handled
by checking the "status" of the SetPixel calls in the surface tracking
stage.

Jim

Jim