[Insight-developers] points in regions

[Brian B Avants]

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
> >
>
>