[Insight-developers] Flood iterator ++ method

[Miller, James V (CRD)]

Damion,

The confusion is that the stack is not keeping track of "where you have been" (the stack is not an
exhaustive representation of where you have been, your tempImage is really keeping track of that).
Your stack is really keeping track of "where you need to go next" (places that you have identified as
potentially inside the function, but have yet to be checked).

Your tempImage is the mask that I was referring to.

(I don't think state #3 is really needed.)

Jim



-----Original Message-----
From: Damion Shelton [mailto:dmsst59+@pitt.edu]
Sent: Wednesday, June 06, 2001 2:44 PM
To: Miller, James V (CRD); 'insight-Developers'
Subject: Re: [Insight-developers] Flood iterator ++ method


Jim:

Could you elaborate a little on your suggestion? The current implementation,
in a nutshell, is:

-----------------
Create tempImage as an n-dimensional image of unsigned chars the same size
as source image.
Pixel values in tempImage are:

0=unchecked
1=checked, not in function
2=checked, in function, neighbor check incomplete
3=checked, in function, neighbor check complete

Push the seed index onto the stack.

Do{
Examine the pixel at the index on top of the stack
If the pixel has not been checked (i.e. tempImage[index] = 0)
    If this pixel is inside the function
         tempImage[index] = 2
    Else (it's not inside the function)
        tempImage[index] = 1
        Pop top index off the stack
        Continue (next iteration of do loop)
    Now check all neighbors
        If there's a neighbor that's hasn't been checked
(i.e.tempImage[neighborindex] = 0)
            Push neighbor's index onto stack
        Else
            tempImage[index] = 3
            Pop top index off stack (we've checked all the neighbors)
}While there are no indices on the stack
-----------------

The stack keeps track of where I've been, and the temp image store info
about the state of all of the pixels in the original image
(in/out/checked/unchecked). The stack seems neccessary since it allows me to
reverse my forward progress and ensure that all neighbors are eventually
checked. But, if you have a way around this that would be great.

I'm also not sure how RLE would help - recomputing a RLE compressed temp
image at every iterator step would be an expensive operation, but I'm
probably misunderstanding what you mean.

-Damion-

----- Original Message -----
From: "Miller, James V (CRD)" <millerjv@crd.ge.com>
To: "'Damion Shelton'" <dmsst59@pitt.edu>; "'insight-Developers'"
<insight-developers@public.kitware.com>
Sent: Wednesday, June 06, 2001 7:29 AM
Subject: RE: [Insight-developers] Flood iterator ++ method


> Damion,
>
> Instead of a stack of indices indicating where you have been, you could
keep a mask (image). This
> could be an image of a low bit count or a run length encoded image. You
really only need one bit per
> pixel to indicate that you have visited that pixel.
>
> While this is analogous to your stack storage, it would require less
memory.
>
> Jim