[Insight-developers] points in regions

[Brian B Avants]

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
>