[Insight-developers] points in regions

Joshua Cates cates@cs.utah.edu
Thu, 4 Apr 2002 14:19:49 -0700 (MST) 

Hi Brian,

As Jim states, the center should always be at index 4 (in a 3x3),
regardless of where in the image the iterator is positioned.  The smart
iterators are designed to return a value for each index, even if that
index does not correspond to an actual data point. Does this correspond to
what you are seeing? Let me know if you have more questions or have any
suggestions for better documentation.


Josh.

______________________________
 Josh Cates			
 School of Computer Science	
 University of Utah
 Email: cates@cs.utah.edu
 Phone: (801) 587-7697
 URL:   www.cs.utk.edu/~cates


On Thu, 4 Apr 2002, Brian B Avants wrote:

> Jim,
> yes, that's consistent with what my diagram shows, however, i am showing
> coordinates instead of pixel values.  i erroneously expected those
> positions to not be visited at all but understand why it makes sense to do
> what's below.
> thanks for the help,
> Brian
> 
> 
> On Thu, 4 Apr 2002, Miller, James V (CRD) wrote:
> 
> > 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
> > >
> >
> >
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>