[Insight-users] Curvature in ShapeDetectionLevelSetImageFilter

Lydia Ng lng at insightful . com
Thu, 10 Jul 2003 09:17:16 -0700


Hi Nils and Luis,

There is issue in the current implementation of the level set framework
in that the curvature term is not taken into account when computing the
time step. Ideally, the time step should computed to maintain numerical
stability.

Thus, setting the curvature weight is high relative to the propagation
term will cause problem most likely due to the time step being too
large.

This is a known problem - computing the time step to meet the CFL
criterion is not widely reported in the literature - a few of us is
still trying to figure out what is the mathematically sound thing to do
here.

BTW - I have also fixed the problem of when the propagation weight is
zero - it shouldn't crash now - but you will still get the numerical
instability issue as above.

- Lydia

> -----Original Message-----
> From: Luis Ibanez [mailto:luis . ibanez at kitware . com]
> Sent: Thursday, July 10, 2003 6:58 AM
> To: Nils Hanssen
> Cc: Insight-users at public . kitware . com
> Subject: Re: [Insight-users] Curvature in
> ShapeDetectionLevelSetImageFilter
>=20
>=20
> Hi Nils,
>=20
> I just performed a couple of tests, and the
> ShapeDetectionLSIF is behaving as expected.
> (Note that I did this with the current CVS
>   version, not ITK 1.2).
>=20
> A couple of sample images that help to test
> your case were checked in under:
>=20
>   - Insight/Examples/Data/Circle.png
>   - Insight/Examples/Data/CircleSpikes.png
>=20
> http://www . itk . org/cgi-
> bin/cvsweb.cgi/Insight/Examples/Data/Circle.png?cvsroot=3DInsight
> http://www . itk . org/cgi-
> =
bin/cvsweb.cgi/Insight/Examples/Data/CircleSpikes.png?cvsroot=3DInsight
>=20
> CircleSpikes.png simulates the conditions of your
> tube but in 2D.
>=20
> The example ShapeDetectionLevelSetImageFilter
> was also slightly modified in order to take the
> scaling parameter from the command line arguments.
>=20
> http://www . itk . org/cgi-
>
bin/cvsweb.cgi/Insight/Examples/Segmentation/ShapeDetectionLevelSetFilte
r.
> cxx?cvsroot=3DInsight&sortby=3Ddate
>=20
> Running this example with the parameters below
> succeded to segment the internal circle without
> taking the spikes (bridges).  Note that although
> the segmentation doesn't goes into the spikes, they
> excert some influence on the shape of the final
> contour.
>=20
> Here are the parameters:
>=20
> ShapeDetectionLevelSetFilter
>=20
>    input image:        CirclesSpikes.png
>    output image:       SegmentedCircle.png
>    seed point:         50 50
>    distance:           20
>    sigma:              1.0
>    sigmoid alpha:      -40
>    sigmoid beta:       128
>    curvatureScaling:   3.1
>    propagationScaling: 0.97
>=20
> The overlay of the segmented circle, on top
> of the CircleSpikes.png image is shown in
> the attachement.
>=20
> ---
>=20
> The balance between the curvatureScaling and the
> propagationScaling parameters is quite delicate.
>=20
> For example:
>=20
> keeping curvature scaling =3D 3.1
> propagation scaling =3D 0.98  will overflow the whole image
> while prop. scaling =3D 0.96  will grow just to half the circle
>=20
> OR
>=20
> keeping propagation scaling =3D 0.97
> curvature scaling =3D 3.0 will overflow the image
> curvature scaling =3D 3.2 will fall short on reaching the edges
>=20
>=20
>=20
> My guess is that it may be possible to find a
> continuous function F():
>=20
>     curvatureScaling =3D F( propagationScaling )
>=20
> for which the segmentation grabs on the circle edges,
> but at some threshold of "PropagationScaling" the
> computation will start presenting numerical
> instabilities.
>=20
>=20
>=20
>=20
> Regards,
>=20
>=20
>=20
>     Luis
>=20
>=20
>=20
> ---------------------
> Nils Hanssen wrote:
> > Hi Luis,
> >
> > thank you for the detailed answer.
> >
> >
> > My initial level set conforms to the "negative inside" convention.
> > Now, I am using a curvature weighting of 1000 (just to see what
happens
> in
> > the extreme case) and a propagation weighting of 0.001. When running
the
> > ShapeDetectionLSIF, the contour is not collapsing at all. Maybe
that's
> > because of the feature image that dictates the curvature speed =
(=3D=3D
> > propagation speed in the ShapeDetectionLSIF)?
> >
> > Since the curvature speed in the ShapeDetectionLSF equals the
> propagation
> > speed, I derived my own classes called "TubularLevelSetFunction" and
> > "TubularLevelSetImageFilter". These are basically clones of the
> > ShapeDetection* classes, but with the difference that I set the
> curvature
> > speed to (constant) one in the Level-set function.
> > Now, the contour is collapsing according to the mean curvature but
all
> this
> > happens _very_ slowly (the curvature weighting is 1000!).
> >
> > In itk::LevelSetFunction::ComputeUpdate(...) I see the following:
> > ---
> >   curvature_term =3D curve;
> >   curvature_term *=3D m_CurvatureWeight * this->CurvatureSpeed(it,
> offset);
> > ---
> > so it should make no difference when I set the curvature weight to 1
and
> the
> > curvature speed to (constant) 1000 (and not vice versa), right? But
when
> I
> > do this, I get numerical instabilities during the evolution. What is
> wrong
> > with my assumption?
> >
> > Luis, what was the curvature weighting and curvature speed when you
> tested
> > the collapsing contour with the syntethic sphere image? Was the
> curvature
> > speed constant or dependent on the image?
> >
> > For now, I do all calculations in 2D. Could that be a problem? I
have
> > installed a observer that shows me the progress of the contour after
> each
> > update event.
> >
> >
> > Regards,
> > Nils
> >
> >
> >
> >>-----Original Message-----
> >>From: Luis Ibanez [mailto:luis . ibanez at kitware . com]
> >>Sent: Wednesday, July 09, 2003 6:14 PM
> >>To: Nils Hanssen
> >>Cc: Insight-users at public . kitware . com
> >>Subject: Re: [Insight-users] Crash in
> >>ShapeDetectionLevelSetImageFilter
> >>
> >>
> >>
> >>Hi Nils,
> >>
> >>You are right in your interpretation of the
> >>behavior for the ShapeDetectionLevelSetFilter.
> >>
> >>Increasing the curvature scaling while decreasing
> >>the propagation scaling should make the contour
> >>collapse (contract).
> >>
> >>I just verified this behavior using a syntethic
> >>image of a sphere.
> >>
> >>Note that in version 1.2 this filter is expecting
> >>the input level set to conform to the convention
> >>of "negative inside" which means that the level
> >>set has negative values 'inside' the contour and
> >>positive values outside the contour.
> >>
> >>You may have to push the curvature scaling to
> >>a value higher than 1.0. (e.g. 5.0 or so).
> >>
> >>I would avoid to use 0.0 for the propagation
> >>scaling ( in part just for superstition  against
> >>zeros values as parameters). You may want to
> >>try something like 0.1 for the propagation
> >>scaling.
> >>
> >>Please verify the convention used by your initial
> >>level set. That may be the cause for the contour
> >>not behaving as expected.
> >>
> >>
> >>Regards,
> >>
> >>
> >>    Luis
> >>
> >>
> >>
> >>---------------------
> >>Nils Hanssen wrote:
> >>
> >>>Hi Luis,
> >>>
> >>>I am using the 1.2.0 web release.
> >>>
> >>>Regards,
> >>>Nils
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: insight-users-admin at itk . org
> >>>>[mailto:insight-users-admin at itk . org]On
> >>>>Behalf Of Luis Ibanez
> >>>>Sent: Tuesday, July 08, 2003 3:55 PM
> >>>>To: Nils Hanssen
> >>>>Cc: Insight-users at public . kitware . com
> >>>>Subject: Re: [Insight-users] Crash in
> >>>>ShapeDetectionLevelSetImageFilter
> >>>>
> >>>>
> >>>>
> >>>>Hi Nils,
> >>>>
> >>>>Are you using a very recent checkout of ITK  ?
> >>>>
> >>>>The level set filters have been reworked in
> >>>>recent days, so it will help us to know if you
> >>>>are experiencing this behavior with the current
> >>>>version or with the version as it was two weeks
> >>>>ago (or before that).
> >>>>
> >>>>Please let us know,
> >>>>
> >>>>   Thanks
> >>>>
> >>>>
> >>>>     Luis
> >>>>
> >>>>
> >>>>------------------------
> >>>>Nils Hanssen wrote:
> >>>>
> >>>>
> >>>>>Hi,
> >>>>>
> >>>>>I am trying to understand the behaviour of the
ShapeDetectionLSIF.
> >>>>>Therefore, I set the propagation-weighting to zero. By setting
the
> >>>>>curvature-weighting to a value of one I would expect that
> >>>>
> >>>>the inital
> >>>>
> >>>>
> >>>>>surface is shrinking to a point (I set the MaxRMSError to
> >>>>
> >>>>zero) and the
> >>>>
> >>>>
> >>>>>number of iterations very high.
> >>>>>
> >>>>>The filter is crashing in
> >>>>>SegmentationLevelSetFunction<TImageType, TFeatureImageType>
> >>>>>::PropagationSpeed(const NeighborhoodType &neighborhood, const
> >>>>>FloatOffsetType &offset) const
> >>>>>[...]
> >>>>>-->  else return (
> >>>>
> >>>>static_cast<ScalarValueType>(m_SpeedImage->GetPixel(idx)) );
> >>>>// crashing here
> >>>>
> >>>>
> >>>>>[...]
> >>>>>
> >>>>>When I set the propagation-weighting to - for instance -
> >>>>
> >>0.0001 the
> >>
> >>>>>filter is not crashing, but the contour is not shrinking
> >>>>
> >>>>according to
> >>>>
> >>>>
> >>>>>the mean curvature.
> >>>>>
> >>>>>Is that the correct behaviour of the filter?
> >>>>>
> >>>>>I would appreciate any suggestions. Thanks!
> >>>>>
> >>>>>
> >>>>>Regards,
> >>>>>Nils
> >>>>>
> >>>>>
> >>>>>-------------------------
> >>>>>Nils Hanssen
> >>>>>Surgical Systems Laboratory
> >>>>>research center c ae sa r
> >>>>>Ludwig-Erhard-Allee 2
> >>>>>53175 Bonn
> >>>>>fon: +49-228-9656-197
> >>>>>fax: +49-228-9656-117
> >>>>>___http://www . caesar . de/ssl_
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>_______________________________________________
> >>>>Insight-users mailing list
> >>>>Insight-users at itk . org
> >>>>http://www . itk . org/mailman/listinfo/insight-users
> >>>>
> >>>
> >>>_______________________________________________
> >>>Insight-users mailing list
> >>>Insight-users at itk . org
> >>>http://www . itk . org/mailman/listinfo/insight-users
> >>>
> >>
> >>
> >>
> >>
> >
> > _______________________________________________
> > Insight-users mailing list
> > Insight-users at itk . org
> > http://www . itk . org/mailman/listinfo/insight-users
> >
>=20