[Insight-users] Issue with BinaryErodeImageFilter

[Dan Mueller]

Hi Robert,

I had a look at your data, it seems to be highly anisotropic (the
out-of-plane resolution is much bigger than the in-plane resolution,
Spacing=[1.87500, 1.87500, 7.00000]). In this case perhaps 3-D erosion
is not really suitable. To perform erosion in a slice-by-slice manner,
you simply set one of the sizes in your structuring element to zero,
eg. Size=[1,1,0]. Alternatively, if eventually you want to apply other
filters on a slice-by-slice basis, you could employ the
SliceBySliceImageFilter which Gaetan submitted to the Insight Journal:
   http://insight-journal.org/dspace/handle/1926/368

In terms of boundary conditions, the BinaryErodeImageFilter uses a
ConstantBoundaryCondition with pixels outside set to zero:
   see Code/BasicFilters/itkBinaryMorphologyImageFilter.txx, line 201-204

Welcome to the world of open-source, where you can peer directly into
the guts of the code to see how the algorithm is implemented!

HTH

Cheers, Dan

On 13/09/2007, Robert Tamburo <robert.tamburo at gmail.com> wrote:
> Hi Gaëtan and Dan,
>
> Thanks for the replies.  I've uploaded the code and data to http://
> www.tamburo.us/temp/erosion_files/erosion.zip
>
> Dan, that does make some sense. I forgot that the structure element
> was a sphere and not a disc. I suppose that I was expecting a slice
> by slice erosion in the volume. Is there currently a way to do this?
> I tried using a 2D structure element, but received an awful error.
>
> How are boundary conditions handled? In the case that I removed the
> blank slices, what is being used as the "previous slice"? What
> accounts for the seemingly repeated first slice in the output image?
>
> Thanks again,
> Robert
>
>
> On Sep 11, 2007, at 6:29 PM, Dan Mueller wrote:
>
> > Hi Robert,
> >
> > From your description, it appears the erode filter is working
> > correctly. If slice 0 and 18 are blank in your input image, after
> > eroding with a structuring element [1,1,1] I would expect slice 1 and
> > 17 to also be blank in the output. Remember, the erode filter takes
> > the minimum value of all those under the element; for slices 1 and 17
> > the element will include pixels from slice 0 (and 2) and slice 18 (and
> > 16), which are blank (ie. the minimum). I don't think the
> > corresponding slice index is being moved, but simply the erosion has
> > been applied changing the shape for all given slices.
> >
> > As Gaetan said, providing the source code would be very helpful. Also,
> > perhaps you could upload your original 3-D dataset to the URL so we
> > can confirm nothing funny is happening.
> >
> > Anyway, hope this helps.
> >
> > Cheers, Dan
> >
> > On 12/09/2007, Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr> wrote:
> >>
> >> Hi Robert,
> >>
> >> Le 11 sept. 07 à 23:48, Robert Tamburo a écrit :
> >>
> >>> Hi all,
> >>>
> >>> I'm trying to use the erosion filter on a 3D binary image. I'm
> >>> using the itkBinaryErodeImageFilter with an
> >>> itkBinaryBallStructuringElement in the same way that is
> >>> demonstrated in the SoftwareGuide. The input image has a total of
> >>> 19 slices with the first and last slices being blank (black,
> >>> background). In the output image the first 2 and last 2 slices end
> >>> up being blank... two slices of data are missing.  Moreover, an
> >>> obviously corresponding slice no longer has the same index.
> >>>
> >>> I tried a couple of things to try and understand what was
> >>> happening. First, I tried padding the image with additional blank
> >>> slices. I added 1, 2, and 3 additional slices and got the same
> >>> results.  Then I tried removing the blank slices. No blank slices
> >>> were introduced. However, the index problem is still an issue.
> >>> I've created a temp web page with some screen captures to better
> >>> illustrate the problem. The URL is: http://www.tamburo.us/temp/
> >>> erosion.htm
> >>>
> >>> The results are confusing to me and not what I expected. Any
> >>> clarification on these issues would be greatly appreciated. Source
> >>> code and images can be made available if needed.
> >>
> >> The source code would be really useful. If you can send it, I'll look
> >> at that problem tomorrow.
> >> In the mean time, here are some possible cause of the problem:
> >>   - be sure to call the CreateStructuringElement() method on the
> >> BinaryBallStructuringElement
> >>   - try with ITK cvs - it include a fix for a bug in ITK 3.2 which
> >> highly slow down the filter. The speed may not the only effect of
> >> that bug...
> >>
> >>>
> >>> Regards,
> >>> Robert
> >>>
> >>> P. S. I'm using a MacBook Pro with ITK version 3.2.0 and gcc 4.0.1.
> >>
> >> I'm doing the same - works great for me :-)
> >>
> >>> P. P. S. The documentation in the header for the erosion filter is
> >>> incorrect in that it describes dilation.
> >>
> >> I'll fix that (I must be the one who made that mistake). Thanks for
> >> the report!
> >>
> >> Regards,
> >>
> >> Gaëtan