[Insight-developers] points in regions

[Brian B Avants]

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.