[Insight-developers] ConstShapedNeighborhoodIterator inheritance

Miller, James V (Research) millerjv at crd.ge.com
Tue Oct 11 09:14:01 EDT 2005


Gaetan, Josh

Looking at ConstShapedNeighborhoodIterator::operator++, it looks to me that
the ShapedNeighborhoodIterators have a linked list to manage which indices
are active in the iterator but that the actual pointers to pixels are 
maintained (incremented, etc.) in the underlying Neighborhood structure
(Neighborhood of pointers). operator++ updates the pointers in the neighborhood
corresponding to the active set AND updates the center pixel pointer (needed
for the base operation of the NeighborhoodIterator).

Given the lack of a GoToBegin(), GoToEnd() in the ShapedNeighborhoodIterators, 
it looks like all the pointers in the Neighborhood are setup to map all 
the elements of the underlying neighborhood via the superclass. When operator++
is called, only the pointers for the active set are updated (and the center pixel).
Same argument holds for SetLocation().

So given this cursory look at the code, I think exposing GetCenterPointer(), 
GetCenterPixel(), SetCenterPixel(), in ConstShapedNeighborhoodIterator and 
ShapedNeighborhoodIterator would be okay.

Jim




-----Original Message-----
From: insight-developers-bounces+millerjv=crd.ge.com at itk.org
[mailto:insight-developers-bounces+millerjv=crd.ge.com at itk.org]On Behalf
Of Gaetan Lehmann
Sent: Monday, October 10, 2005 1:39 PM
To: Joshua Cates
Cc: insight-developers at itk.org
Subject: Re: [Insight-developers] ConstShapedNeighborhoodIterator
inheritance



Hi Joshua,

On Monday 10 October 2005 18:24, Joshua Cates wrote:
> Hi,
>
> The problem is that the ShapedNeighborhoodIterator does not maintain a
> pointer to a center pixel, so in the general case it is dangerous to
> expose this method. 

After a quick look at the code, I don't understand why you say that. 
ConstShapedNeighborhoodIterator is build on top of NeighborhoodIterator and 
call the methods of his ancestor to return the value. The difference is that 
there is a additional layer to handle the neighbors location.
The center pixel seems to be cached as well. Can you point me to the code 
which change the stored data ?

> If you need to access the center pixel, you can 
> include it in the neighborhood mask when you construct the iterator.  Of
> course, that requires that your application know which of the locations
> in the neighborhood is the center pixel.

This is a quite dirty solution: I don't need to have the center pixel in the 
neighborhood, so I will have to make a test to avoid compute it...

Isn't there a better (and easy) way to get the center pixel value ?

>
> Josh.
>
> Gaetan Lehmann wrote:
> > On Mon, 10 Oct 2005 00:39:37 +0200, Joshua Cates <cates at sci.utah.edu>
> >
> > wrote:
> >> Hi Gaetan,
> >>
> >> Superclass members are private where they don't make sense in the
> >> context of a neighborhood of arbitrary shape.  There is no guarantee,
> >> for example, that a ShapedNeighborhood has a center pixel.
> >
> > Are you sure it don't make sense to access the value of the center
> > pixel,  even if it is not in the neighborhood ?
> > There is lots of case where it make sense: Every time you need to look
> > at  the neighbors values to set the center pixel value, or everytime you
> > need  to compare the center pixel value and the neighbor value to set
> > the values  of the neighbors.
> > I have already used 5 iterators (!) only for the flooding part of a
> > morphological watershed, if the Set/GetCenterPixel() methods are not
> > available, I'll have to use 2 more iterators...
> >
> > Gaetan
> >
> >> Josh.
> >>
> >> On Oct 9, 2005, at 2:10 PM, Gaetan Lehmann wrote:
> >>> Hi,
> >>>
> >>> ConstShapedNeighborhoodIterator is a subclass of
> >>> NeighborhoodIterator.  Sadely,
> >>> all members of the superclass are private:
> >>>
> >>> class ITK_EXPORT ConstShapedNeighborhoodIterator
> >>>
> >>>   :  private NeighborhoodIterator<TImage, TBoundaryCondition>
> >>>
> >>> It prevent usage of Set/GetCenterPixel() methods, which  is really
> >>> annoying.
> >>> Is there a good reason to do that ?
> >>> Is it possible to switch to a public inheritance ?
> >>>
> >>> class ITK_EXPORT ConstShapedNeighborhoodIterator
> >>>
> >>>   :  public NeighborhoodIterator<TImage, TBoundaryCondition>
> >>>
> >>> Thanks,
> >>>
> >>> Gaetan
> >>> _______________________________________________
> >>> Insight-developers mailing list
> >>> Insight-developers at itk.org
> >>> http://www.itk.org/mailman/listinfo/insight-developers


More information about the Insight-developers mailing list