[Insight-developers] level sets: curvature term and time step
Lydia Ng
lng at insightful . com
Thu, 10 Jul 2003 13:14:54 -0700
This is a multi-part message in MIME format.
------_=_NextPart_001_01C3471F.ED21DC92
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi Josh,
I think it is possible (but may not be likely) that all the level set
filters (ie. using itk::LevelSetFunction) are affected not just the
spatially varying curvature ones.=20
We have,
Curvature_term =3D curvature * CurvatureWeight * CurvatureSpeed();
Say for example, there is no advection term then in
ComputeGlobalTimeStep
dt =3D m_DT / vnl_math_abs( m_CurvatureWeight );
By default, CurvatureSpeed() returns 1 - so things might go wrong if
curvature is much larger than 1 / m_DT ( > 4 for 2D ).
But I don't know how likely this scenario is.
________________
The problem Nils ( email attached ) is having is because his
CurvatureSpeed() returns 1000 and he has a CurvatureWeight of 1.
Say if curvature is approx 1 then curvature_term is 1000
But dt =3D m_DT =3D 0.25 (2D) and hence the algorithm takes to big a =
step.
While if he had it the other way around: CurvatureSpeed() =3D 1 and
CurvatureWeight =3D 1000 then dt =3D 0.25/1000 and the algorithm remains
stable.
So I think the time step calculation to be general it needs to take into
account the whole curvature_term rather than just the CurvatureWeight.
- Lydia
> -----Original Message-----
> From: Joshua Cates [mailto:cates at sci . utah . edu]
> Sent: Thursday, July 10, 2003 10:32 AM
> To: Lydia Ng
> Cc: Insight-Developers (E-mail)
> Subject: Re: [Insight-developers] level sets: curvature term and time
step
>=20
> Hi Lydia,
>=20
> Just to clarify: you are talking about the spatially varying curvature
> term, and not the curvature calculation itself? So only filters
> which use this term should be affected, right?
>=20
> Josh.
>=20
> ______________________________
> Josh Cates
> School of Computer Science
> University of Utah
> Email: cates at sci . utah . edu
> Phone: (801) 587-7697
> URL: http://www . sci . utah . edu/~cates
>=20
>=20
> On Thu, 10 Jul 2003, Lydia Ng wrote:
>=20
> >
> > Question for those interested in level sets:
> >
> > Currently the itk::LevelSetFunction class does not take the
curvature
> > term into account when computing the time step to meet the CFL
criterion
> > to ensure numerical stability.
> >
> > This is causing some grief with users playing around with the
scaling
> > parameter in each of the term in particular when they set the
curvature
> > scaling to be high relative to the propagation and advection terms.
> >
> > Can someone point me to a paper/book that talks about have to
compute
> > the CFL time step for the curvature term?
> >
> > Alternatively, (hacking versus mathematically sound) could we just
> > restrict the time step such that the change in level set value due
to
> > the curvature term is no larger that half a pixel? Would this have
the
> > desired affect?
> >
> > The second alternative is for me to change my filters
> > ShapeDetectionLevelSetImageFilter and
> > GeodesicActiveContourLevelSetImageFilter just to use a constant time
> > step - making it the user's problem to ensure they choose the time
step
> > small enough. This is how it was before, when I got complaints from
> > other users about how it was difficult to set this parameter...
> >
> > Cheers,
> > Lydia
> > _______________________________________________
> > Insight-developers mailing list
> > Insight-developers at itk . org
> > http://www . itk . org/mailman/listinfo/insight-developers
> >
------_=_NextPart_001_01C3471F.ED21DC92
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3
Received: from localhost.localdomain ([172.16.1.251]) by se2kexch01.insightful.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Jul 2003 00:17:31 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Received: from public.kitware.com (public.kitware.com [24.97.130.19]) by localhost.localdomain (8.12.8/8.12.5) with ESMTP id h6A6QMpE031748 for <lng at insightful . com>; Wed, 9 Jul 2003 23:26:38 -0700
Received: from public.kitware.com (localhost [127.0.0.1]) by public.kitware.com (Postfix) with ESMTP id 81E9A1AB69; Thu, 10 Jul 2003 03:17:02 -0400 (EDT)
content-class: urn:content-classes:message
Subject: RE: [Insight-users] Crash in ShapeDetectionLevelSetImageFilter
Date: Thu, 10 Jul 2003 00:16:22 -0700
Message-ID: <000301c346b3$2bc24c70$0607010a at ssn4006>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Insight-users] Crash in ShapeDetectionLevelSetImageFilter
Thread-Index: AcNGs1Qr97mgjKDlRIC3LyH/+cxC+w==
List-Help: <mailto:insight-users-request at itk . org?subject=help>
List-Subscribe: <http://www . itk . org/mailman/listinfo/insight-users>,<mailto:insight-users-request at itk . org?subject=subscribe>
List-Unsubscribe: <http://www . itk . org/mailman/listinfo/insight-users>,<mailto:insight-users-request at itk . org?subject=unsubscribe>
From: "Nils Hanssen" <hanssen at caesar . de>
To: "Luis Ibanez" <luis . ibanez at kitware . com>
Cc: <Insight-users at public . kitware . com>
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
------_=_NextPart_001_01C3471F.ED21DC92--