[Insight-developers] CannySegmentationLevelSetImageFilter

[Miller, James V (Research)]

Hey Josh, 

I think Bill is saying it is not setting a mode since it actually changes
the coefficients.  It is impossible to query the filter and determine
whether someone called ReverseExpansionDirection since the caller would have
to know whether the coefficients were initially positive or negative.

A safer way to do this is to have a ivar that keeps track of whether someone
wants the expansion direction reversed and keep the coefficients the
original values.  Then when the coefficients get used, you multiply by -1 if
neccessary.

Jim

-----Original Message-----
From: Joshua Cates [mailto:cates at sci . utah . edu]
Sent: Friday, November 21, 2003 5:41 PM
To: Bill Lorensen
Cc: Miller, James V (Research); Insight-developers (E-mail)
Subject: Re: [Insight-developers] CannySegmentationLevelSetImageFilter


Yes I agree the best thing is always more documentation.

Note that as implemented in the SegmentationLevelSetImageFilter class, the
ReverseExpansionDirection does in fact set a mode flag.  So you can call
ReverseExp...On to enable and ReverseExp..Off to disable.  It's a
convenience function that flips the signs of the coefficients before
execution (through a call to
SegmentationLevelSetFunction::ReverseExpansionDirection, hence the
confusion).

 Josh.

______________________________
 Josh Cates			
 Scientific Computing and Imaging Institute
 University of Utah
 Email: cates at sci . utah . edu
 Phone: (801) 587-7697
 URL:   http://www . sci . utah . edu/~cates


On Fri, 21 Nov 2003, Bill Lorensen wrote:

> Josh,
> The ReverseExpansionDirection is dangerous since it acts when it is called

> and does not set a mode. If you call it twice, it reverse itself. You can 
> change the behavior by changing the signs of the coefficients. I think the

> best thing is clear documentation.
> 
> Bill
> 
> At 04:22 PM 11/21/2003, Joshua Cates wrote:
> >Hi all,
> >
> >Sorry I missed this discussion on the TCON.  When the level-set section
in
> >the SoftwareGuide was first written there was still some inconsistency
> >among level-set filters, so we left the description of inside/outside to
> >up to documentation in specific classes.  Now everything is standardized
> >and correctly described in the doxygen pages for
> >SegmentationLevelSetImageFilter.
> >
> >Let me see if I understand correctly: The confusion on the initialization
> >is that you expected "inside" to correspond to the intuitive notion of
the
> >region enclosed by the implicit surface, when actually "inside" is
> >determined using values relative (lt) the isosurface you describe in the
> >input?  So using a binary initialization 0, 255 and choosing isosurface
> >value 127, for example, results in negative values external to the region
> >enclosed by the surface.
> >
> >Note that the opposite sign convention (positive-outside) produces your
> >intuitive result from a binary initialization.  A perfectly valid way to
> >work with these filters is to turn on "ReverseExpansionDirection" which
> >effectively reverses the convention during calculations and gives the
> >expansion/contraction of the opposite sign convention.
> >
> >There may also be some use in another method that allows you to flip the
> >sign of the values in your initialization?
> >
> >I'll add some clarifications to the SoftwareGuide on these points.
> >Probably be a week or so before I can get to it.  Let me know if there
are
> >other points that need clarification.
> >
> >Josh.
> >
> >______________________________
> >  Josh Cates
> >  Scientific Computing and Imaging Institute
> >  University of Utah
> >  Email: cates at sci . utah . edu
> >  Phone: (801) 587-7697
> >  URL:   http://www . sci . utah . edu/~cates
> >
> >
> >On Fri, 21 Nov 2003, Miller, James V (Research) wrote:
> >
> > > I mentioned on the tcon this afternoon that we were having some
problems
> > > with the CannySegmentationLevelSetImageFilter.  If we used a positive 
> > weight
> > > for the advection weight, our segmentations would contract whereas if
we
> > > used a negative weight for the advection weight our segmentations
would
> > > expand (like we wanted).
> > >
> > > Lydia mentioned that it may be due to how the seed image is being
used.
> > > Once again, Lydia is right. We were passing in a binary image (the 
> > output of
> > > another segmentation algorithm) as the seed image.  The seed image had
255
> > > for the object and 0 for the background.  The 
> > SparseFieldLevelSetImageFilter
> > > takes this seed image and generates an initial level set by assigning 
> > pixels
> > > above a specified IsoValue as being outside the object and pixels
below a
> > > specified IsoValue as being inside the object.  So while I thought my
> > > segmentation was shrinking, it was actually growing.  It was just that
my
> > > "object" was actually my background.
> > >
> > > So.  Here are my suggestions.  One, we should be very clear that the
inside
> > > of objects have negative level set values and the outside of objects
have
> > > positive level set values.  Two, we should change the documentation
for
> > > *SegmentationLevelSetFilters so that it is clear that the seed image 
> > follows
> > > the same conventions for objectness as the levelsets, i.e. values less
than
> > > the specified IsoValue are interior to the object, values greater than
the
> > > specified IsoValue are exterior to the object.  I am not sure whether
we
> > > want to go so far as to say the seed image is an initial level set
(which
> > > does not really have to be) or whether we can just say that it follows
the
> > > same conventions as level sets.
> > >
> > > Finally, I am not sure when we changed the levelsets to be consistent
with
> > > negative interiors and positive exteriors but I regardless of when it
was
> > > done, it looks like the User Guide is out of date.  We'll need to
propagate
> > > this into the User Guide and perhaps put out a list of "errata" on the
web
> > > site.
> > >
> > > Any comments?
> > >
> > >
> > >
> > > Jim Miller
> > > _____________________________________
> > > Visualization & Computer Vision
> > > GE Research
> > > Bldg. KW, Room C218B
> > > P.O. Box 8, Schenectady NY 12301
> > >
> > > millerjv at research . ge . com <mailto:millerjv at research . ge . com>
> > >
> > > james . miller at research . ge . com
> > > (518) 387-4005, Dial Comm: 8*833-4005,
> > > Cell: (518) 505-7065, Fax: (518) 387-6981
> > >
> > >
> > >
> >
> >_______________________________________________
> >Insight-developers mailing list
> >Insight-developers at itk . org
> >http://www . itk . org/mailman/listinfo/insight-developers
> 
>