[Insight-users] Fast binary morphology dilation

[jerome schmid]

James,

Thanks for the interest for the filter proposed together we should improve
it.

First of all you are right for the GenerateInputRequestedRegion() function,
we must pad the input requested region. My first version did it but I cannot
remember why I remove this function...There is also a test which must be
done, for instance in this same function:

		// Test dimensions of input, output images and structuring elements
		if( !(	TInputImage::ImageDimension == TOutputImage::ImageDimension && \
				TKernel::NeighborhoodDimension == TInputImage::ImageDimension ) )
		{
			// build an exception
			DataObjectError e(__FILE__, __LINE__);

			OStringStream msg;
			msg << static_cast<const char *>(this->GetNameOfClass())
				<< "::GenerateInputRequestedRegion()";
			e.SetLocation(msg.str().c_str());
			e.SetDescription("The dimensions of input, output and structuring element
must be the same.");
			throw e;
		}

This test is necessary if user plays to give a SE in 2D whereas the input
image are in 3D , etc...In fact as we manage
index internally it can be dangerous. Honestly I do not think users use an
input image in 3D with a output in 2D with a SE in 1D for instance!

I add your version with the modification attached to this mail.( I hadn't
attach the .h, the modifications are of course in the
generateInputRequestedRegion and in the GenerateData one at the beginnning
when we define the tmpRequestedRegion ). It is zipped because my previous
mail was refused, > 40 kb...

Secondly, if you want to manage your objects stuff ( some objects labeled
with #i ) I think the final loop you put is ok. I understand better your
"most appropriate background value" now however you are agree with me that
when center pixel was not on, some problems appeared previously.

Last point it is true that threading this filter can be difficult, that is
why I started with the normal version...

Regards,

Jerome

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


Jerome,

I have a few other questions on this new filter.

I am a bit confused by the "second stage" code.  I think this filter needs
a GenerateInputRequestedRegion().  The superclass' version will only request
an input requested region that matches the output requested region.  At a
minimum, the input requested region would need to be padded by one.  And I
think
it should really be padded by the m_Kernel.GetRadius().

That being said, I do not see how a pixel that "on" and on the border of the

image (defined by the LargestPossibleRegion) will ever be marked as a border
pixel.  Since the boundary condition for the oNeighIt is the background tag,

any neighboring pixel that is outside the border of the image will return
the background tag.   So the code

      // Test current pixel: it is a border pixel or an inner pixel?
      bool bIsOnContour = false;

      for (i = 0; i < neighborhoodSize; ++i)
        {
        // If at least one neighbour pixel is off the center pixel
        // belongs to contour
        if( oNeighbIt.GetPixel(i) == backgroundTag )
          {
          bIsOnContour = true;
          break;
          }
        }

will say bIsOnContour is true for a pixel that is on and one of its
neighbors is
off AND bIsOnContour is true for a pixel that is on and on the boundary of
the
image (wrt LargestPossibleRegion).

(On a side note, it is not going to be trivial to thread this filter.  The
"third stage" code is not thread safe. Multiple threads could try to write
to
the same pixel at the same time. For instance, pixels near the boundary
between
threads.)

I've attached my modified versions of your filter.

Jim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itkFastIncrementalBinaryDilateImageFilter2.zip
Type: application/octet-stream
Size: 8213 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/insight-users/attachments/20040914/1879a80a/itkFastIncrementalBinaryDilateImageFilter2.obj