[Insight-users] Fast binary morphology dilation

[jerome schmid]

Hi james,

Good news. Apparently some few things on neighborhooditerators were the
tricky part of the code...! Well I think I have understood the main issues
you encountered and I will have a look the day you submit a version.

Of course you should better test it and test it before supplant the current
filters. Concerning the erosion I am sure you can have some common parts. A
simple and first idea would be to create the tmp image as the inverse of
original one, then have the common part which performs dilation and then,
when writting to output, inverse again. Of course you should manage
carefully you stuff of multiple objects #1, #2 ...

Well, it will be a pleasure to see the great changes you've done.

Regards,

Jerome

-----Message d'origine-----
De : Miller, James V (Research) [mailto:millerjv at crd.ge.com]
Envoyé : mercredi 15 septembre 2004 22:52
À : 'jerome schmid'
Objet : RE: [Insight-users] Fast binary morphology dilation


Hey Jerome,

I think I have your dilation filter working properly in a streaming context.
I had to fix one bug in the NeighborhoodIterators.  I also had to change
the regions that were specified to the neighborhood iterators whose use
was via SetLocation().  The latter was pretty tricky.  The
NeighborhoodIterators
rely on the user not trying to position the iterator at a position outside
the specified region.  In essence, when you tell a NeighborhoodIterator
the region is will traverse, you are promising the NeighborhoodIterator that
the "center" of the locator will never be outside that region.  The
NeighborhoodIterator caches some information about whether boundary
conditions
will ever be needed.

You can query values outside the specified region using the GetPixel(i)
method but you cannot reposition the iterator using SetLocation() to a
location
outside the specified region.

You had a couple of NeighborhoodIterators that we set to use the
outputRequestedRegion and then the iterator was repositioned to a neighbor
of a position in outpuRequestedRegion. This location may not be in the
outputRequestedRegion.  I changed these to the tmpRequestedRegion and
everything worked (and the invalid pointer read/write errors I was getting
disappeared).

I think I have a little clean up/testing to do and then I will check it into
ITK.  I haven't quite decided whether to supplant the current filters or
not.

I also want to think about how to best support erosion.  I'd like to have a
separate filter.  So I might push some of the code you gave me into a
superclass that the two subclasses can share.  The AnalyzeKernel() method
would be one that could be shared.  Not sure how much of GenerateData can
be shared.


Jim


-----Original Message-----
From: jerome schmid [mailto:jerome.schmid at ircad.u-strasbg.fr]
Sent: Wednesday, September 15, 2004 3:36 AM
To: Miller, James V (Research)
Cc: insight-users at itk.org
Subject: RE: [Insight-users] Fast binary morphology dilation


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]
Envoye : mardi 14 septembre 2004 21:30
A : '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