[Insight-users] Submission: FullyConnectedImageFilter to comp lement ConnectedComponentImageFilter

Miller, James V (Research) millerjv at crd.ge.com
Mon, 16 Feb 2004 17:02:53 -0500


The iterator that is used in the algorithm should walk
across the columns, then down the rows, then between the slices.

Since the algorithm picks its iterator, we shouldn't have a problem with its
path.

I think in ND which just have to set up the shape iterator so that the upper
left (front)
triangle is filled.  Admittedly, it is trickier than the face connected one.
But if I think 
about for a while, I'm sure something will strike me as a generic algorithm
for filling
in the shape interator.

Jim

-----Original Message-----
From: Zachary Pincus [mailto:zpincus at stanford.edu]
Sent: Monday, February 16, 2004 2:13 PM
To: Miller, James V (Research)
Cc: insight-users at itk.org
Subject: Re: [Insight-users] Submission: FullyConnectedImageFilter to
comp lement ConnectedComponentImageFilter


James,

I do believe that you are correct regarding the shaped neighborhoods.
(I had initially tried the first pattern you suggested and, as you 
noted,
it did not work, which led me to my eventual solution. I did not think 
of the
second pattern you suggested, however.) Thanks for the input!

I have a couple further questions about this, however:
(1) I can't think of a simple algorithm off the top of my head that 
will fill out this second activation pattern in an 
arbitrary-dimensional hypercube.

(2) Whether the neighborhood should look like this:
     x  x  x
     x  x  .
     .  .  .
or this:
     x  x  .
     x  x  .
     x  .  .
(and so on in higher dimensions)
depends on the direction the iterator moves in, which depends on how 
the image is laid out in memory. Is the iterator always guaranteed to 
traverse an image row-wise with respect to the neighborhood? What is 
the order of traversal for an N-d image? without this sort of 
knowledge, one can't guarantee that the shaped neighborhood is correct.

Any thoughts?

Zach Pincus

Department of Biochemistry and Program in Biomedical Informatics
Stanford University School of Medicine

On Feb 16, 2004, at 5:53 AM, Miller, James V (Research) wrote:

> For vertex+face connected, we may need to add another pixel to the 
> shape
> neighborhood, to be
>
>     x  x  x
>     x  x  .
>     .  .  .
>
> as opposed to the one I just posted
>
>     x  x  .
>     x  x  .
>     .  .  .
>
> -----Original Message-----
> From: Miller, James V (Research) [mailto:millerjv at crd.ge.com]
> Sent: Monday, February 16, 2004 8:48 AM
> To: 'Zachary Pincus'; insight-users at itk.org
> Subject: RE: [Insight-users] Submission: FullyConnectedImageFilter to
> comp lement ConnectedComponentImageFilter
>
>
> Zach,
>
> If the only real difference is checking vertex connected neighbors as 
> well
> as face connected neighbors, couldn't the same code as
> ConnectedComponentImageFilter
> be used by "activating" a few more neighbors in the iterator?
>
> In 2D, the ConnectedComponentImageFilter uses a neighborhood structure 
> like
>
>     .  x  .
>     x  x  .
>     .  .  .
>
> with only the elements marked with "x" being activated.  If we put a 
> mode
> into the
> ConnectedConfidenceImageFilter to switch between face and face+vertex
> connected
> neighbors, then we would toggle between an interator set up like above 
> and
> one
> like
>
>     x  x  .
>     x  x  .
>     .  .  .
>
> Then the same algorithm code can be used, and the mode would just 
> change the
> setup code.
>
> It looks like your version of the code actually checks the neighborhood
>
>     x  x  x
>     x  x  x
>     x  x  x
>
> which checks pixels in front of and behind the current pixel.  Isn't 
> this
> doing more work
> than necessary?
>
> Jim
>
>
>
> -----Original Message-----
> From: Zachary Pincus [mailto:zpincus at stanford.edu]
> Sent: Sunday, February 15, 2004 11:10 PM
> To: insight-users at itk.org
> Subject: [Insight-users] Submission: FullyConnectedImageFilter to
> complement ConnectedComponentImageFilter
>
>
> Hello,
>
> Here is an image filter that labels thin contours in binary images.
>
> While ITK includes a ConnectedComponentImageFilter, this filter only
> works for face-connected objects (in 2-d, that's 4-connected), such as
> blobs. For single-pixel-thick contours, one needs to trace all the
> diagonal connections too (in 2-d, that's 8-connected), so this filter
> is not sufficient.
>
> I have modified itkConnectedComponentImageFilter to trace contours
> across diagonals and faces in n dimensions. (It was a simple, but not
> totally trivial modification.) Here is my code, in case anyone needs
> it, or the ITK maintainers feel that it would be worth including in the
> repository.
>
> (Note that I tried to integrate this into the original
> itkConnectedComponentImageFilter code to avoid excess code duplication,
> but that became really kludgy and unworkable due to the interface
> differences between ShapedNeighborhoodIterator::Iterator and
> Neighborhood::Iterator -- this is a bit of a pain, really.)
>
> Also, in the future, what is the preferred method of code submission?
>
> Zach Pincus
>
> Department of Biochemistry and Program in Biomedical Informatics
> Stanford University School of Medicine
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>