[Insight-developers] points in regions

[Miller, James V (CRD)]

I am not sure I understand your diagram.  With the zero flux boundary
conditition, the indices "outside" your image are computed from 
values "inside" the image.  So when you position your neighborhood
at the first pixel in the image, index 0, 1, 3, and 4 would all
return the value associated with index 4.

Where are you getting the "position" values in your diagram

This diagram is taken from the header file for the zero flux....

 * For example, invoking this function object on a 7x5 iterator that masks
 * a region at an image corner (iterator is centered on the 2):
 *
 *               * * * * * * * 
 *               * * * * * * *
 *               * * 1 2 3 4 5  (where * denotes pixels that lie 
 *               * * 3 3 5 5 6          outside of the image boundary)
 *               * * 4 4 6 7 8
 *
 * returns the following neighborhood of values:
 *
 *               1 1 1 2 3 4 5
 *               1 1 1 2 3 4 5
 *               1 1 1 2 3 4 5
 *               3 3 3 3 5 5 6   (note the corner values)
 *               4 4 4 4 6 7 8
 *

-----Original Message-----
From: Brian B Avants [mailto:avants@grasp.cis.upenn.edu]
Sent: Thursday, April 04, 2002 1:51 PM
To: Miller, James V (CRD)
Cc: Joshua Cates; Insight-Developers
Subject: RE: [Insight-developers] points in regions


just the default "zero neumann" -- here's the output
of neighborhood index vs position:

index      position image sz [256, 124]
 i 0 position 0 0
 i 1 position 0 0
 i 2 position 1 0
 i 3 position 0 0
 i 4 position 0 0
 i 5 position 1 0
 i 6 position 0 1
 i 7 position 0 1
 i 8 position 1 1

so certain points are visited multiple times.

thanks

Brian



On Thu, 4 Apr 2002, Miller, James V (CRD) wrote:

> I thought the center pixel was always index 4 in a 3x3 neighborhood.
>
> What boundary condition are you using for you smart neighborhood iterator?
>
> -----Original Message-----
> From: Brian B Avants [mailto:avants@grasp.cis.upenn.edu]
> Sent: Thursday, April 04, 2002 12:43 PM
> To: Joshua Cates
> Cc: Insight-Developers
> Subject: RE: [Insight-developers] points in regions
>
>
>
> Josh,
>
> Currently, I use the neighborhood in the following way:
>
>  NeighborhoodIteratorType GHood(m_Radius,m_Graph,m_Graph->GetRequestedRegion());
>  GraphNeighborhoodIndexType	GNI;
>
>   for (i=0; i < GraphDimension; i++)
>   {
> 	GNI[i]=m_CurrentNode->GetLocation()[i];
>   }
>
>   GHood.SetLocation(GNI);
>   for (i = 0; i < m_EdgeTemplate.size(); i++)
>   {
>     m_NeighborNode=GHood.GetPixel(m_EdgeTemplate[i]);
> // then do things to that node
>   }
>
> The EdgeTemplate contains the indices to the points in the neighborhood
> that i'd like to use.
>
> The only issues i've noticed is that on the borders, using a smart
> neighborhood, the indices are not consistent.  That is, the center does
> not necessarily remain at index 4 in a 3x3 hood.  If it's at a lower left
> corner, it's index 0.  This makes sense in some applications, but for
> mine, to have a consistent search neighborhood, it forces me to define a
> buffer region.  That's fine, cause normal neighborhoods are faster, but
> maybe this should be handled in a consistent way or commented upon.
>
>
> Brian
>
> On Wed, 3 Apr 2002, Joshua Cates wrote:
>
> > Brian,
> >
> > Right now the neighborhood iterators are inefficient when only some of the
> > indicies are used because all of index pointers are updated (i.e.
> > incremented or decremented).  I plan to rewrite the iterators so that a
> > user can optionally specify which indicies to update and which to ignore.
> > This would better support the use of arbitrarily shaped neighborhoods and
> > make iteration more efficient in those cases.
> >
> > I don't have any big plans for changes to the API.  My current thinking is
> > that the neighborhoods could be accessed in three ways, the first being
> > the current mode of access, where a user would just be expected to know
> > which indicies are valid (which is reasonable, as presumably they are the
> > one who has constructed the object).  Secondly, I could add a list-based
> > access, where each valid index could be accessed sequentially, without
> > knowledge of its spatial position in the neighborhood.  This involves a
> > second dereference, so its use would come with a penalty.  A third mode of
> > access could be a simple dereference with validity checking.  This would
> > be similar to the first mode, but return a valid/invalid value.
> >
> > Any other ideas?
> >
> > Josh.
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>