[Insight-developers] level sets: curvature term and time step
Tolga Tasdizen
tolga at sci . utah . edu
Fri, 18 Jul 2003 16:16:02 -0600
--------------030408000509070208030400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
I am going to change the level set time computation for the case when
curvature weight is zero. Currently it is
dt = m_WaveDT / d->m_MaxAdvectionChange
which is unstable (will not converge). I will change it to
dt = vnl_math_min(( m_WaveDT / d->m_MaxAdvectionChange ),
( m_WaveDT / vnl_math_abs(m_PropagationWeight) ));
This change also compatible with the time step computation when
curvature weight is not zero.
I am not sure if anyone else uses the level set function without
curvature flow, but I thought I'd check to see if anybody has objections.
Tolga
Lydia Ng wrote:
>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.
>
>We have,
>Curvature_term = curvature * CurvatureWeight * CurvatureSpeed();
>
>
>Say for example, there is no advection term then in
>ComputeGlobalTimeStep
>
>dt = 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 = m_DT = 0.25 (2D) and hence the algorithm takes to big a step.
>
>While if he had it the other way around: CurvatureSpeed() = 1 and
>CurvatureWeight = 1000 then dt = 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
>
>
>>Hi Lydia,
>>
>>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?
>>
>>Josh.
>>
>>______________________________
>> 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
>>
>>
>>On Thu, 10 Jul 2003, Lydia Ng wrote:
>>
>>
>>
>>>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
>>>
>>>
>>>
>>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> Subject:
> RE: [Insight-users] Crash in ShapeDetectionLevelSetImageFilter
> From:
> "Nils Hanssen" <hanssen at caesar . de>
> Date:
> Thu, 10 Jul 2003 00:16:22 -0700
> To:
> "Luis Ibanez" <luis . ibanez at 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 (==
>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 = curve;
> curvature_term *= 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
>
>
>
>
--------------030408000509070208030400
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Hi,<br>
<br>
I am going to change the level set time computation for the case when curvature
weight is zero. Currently it is<br>
<br>
dt = m_WaveDT / d->m_MaxAdvectionChange <br>
<br>
which is unstable (will not converge). I will change it to<br>
<br>
dt = vnl_math_min(( m_WaveDT / d->m_MaxAdvectionChange ),<br>
( m_WaveDT / vnl_math_abs(m_PropagationWeight) ));<br>
<br>
This change also compatible with the time step computation when curvature
weight is not zero.<br>
I am not sure if anyone else uses the level set function without curvature
flow, but I thought I'd check to see if anybody has objections.<br>
<br>
Tolga<br>
<br>
<br>
Lydia Ng wrote:<br>
<blockquote type="cite"
cite="midEEF8736EDA4962479208961401D6A02C4B8DD6 at se2kexch01 . insightful . com">
<pre wrap="">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.
We have,
Curvature_term = curvature * CurvatureWeight * CurvatureSpeed();
Say for example, there is no advection term then in
ComputeGlobalTimeStep
dt = 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 = m_DT = 0.25 (2D) and hence the algorithm takes to big a step.
While if he had it the other way around: CurvatureSpeed() = 1 and
CurvatureWeight = 1000 then dt = 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
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: Joshua Cates [<a class="moz-txt-link-freetext" href="mailto:cates at sci . utah . edu">mailto:cates at sci . utah . edu</a>]
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
</pre>
</blockquote>
<pre wrap=""><!---->step
</pre>
<blockquote type="cite">
<pre wrap="">Hi Lydia,
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?
Josh.
______________________________
Josh Cates
School of Computer Science
University of Utah
Email: <a class="moz-txt-link-abbreviated" href="mailto:cates at sci . utah . edu">cates at sci . utah . edu</a>
Phone: (801) 587-7697
URL: <a class="moz-txt-link-freetext" href="http://www . sci . utah . edu/~cates">http://www . sci . utah . edu/~cates</a>
On Thu, 10 Jul 2003, Lydia Ng wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Question for those interested in level sets:
Currently the itk::LevelSetFunction class does not take the
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->curvature
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">term into account when computing the time step to meet the CFL
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->criterion
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">to ensure numerical stability.
This is causing some grief with users playing around with the
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->scaling
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">parameter in each of the term in particular when they set the
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->curvature
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">scaling to be high relative to the propagation and advection terms.
Can someone point me to a paper/book that talks about have to
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->compute
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->to
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">the curvature term is no larger that half a pixel? Would this have
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->the
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->step
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:Insight-developers at itk . org">Insight-developers at itk . org</a>
<a class="moz-txt-link-freetext" href="http://www . itk . org/mailman/listinfo/insight-developers">http://www . itk . org/mailman/listinfo/insight-developers</a>
</pre>
</blockquote>
<pre wrap="">></pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<br>
<hr width="90%" size="4"><br>
<table border="0" cellspacing="0" cellpadding="0" width="100%"
class="header-part1">
<tbody>
<tr>
<td>
<div class="headerdisplayname" style="display: inline;">Subject:
</div>
RE: [Insight-users] Crash in ShapeDetectionLevelSetImageFilter</td>
</tr>
<tr>
<td>
<div class="headerdisplayname" style="display: inline;">From: </div>
"Nils Hanssen" <a class="moz-txt-link-rfc2396E" href="mailto:hanssen at caesar . de"><hanssen at caesar . de></a></td>
</tr>
<tr>
<td>
<div class="headerdisplayname" style="display: inline;">Date: </div>
Thu, 10 Jul 2003 00:16:22 -0700</td>
</tr>
<tr>
<td>
<div class="headerdisplayname" style="display: inline;">To: </div>
"Luis Ibanez" <a class="moz-txt-link-rfc2396E" href="mailto:luis . ibanez at kitware . com"><luis . ibanez at kitware . com></a></td>
</tr>
</tbody>
</table>
<br>
<pre wrap="">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 (==
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 = curve;
curvature_term *= 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
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: Luis Ibanez [<a class="moz-txt-link-freetext" href="mailto:luis . ibanez at kitware . com">mailto:luis . ibanez at kitware . com</a>]
Sent: Wednesday, July 09, 2003 6:14 PM
To: Nils Hanssen
Cc: <a class="moz-txt-link-abbreviated" href="mailto:Insight-users at public . kitware . com">Insight-users at public . kitware . com</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Luis,
I am using the 1.2.0 web release.
Regards,
Nils
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:insight-users-admin at itk . org">insight-users-admin at itk . org</a>
[<a class="moz-txt-link-freetext" href="mailto:insight-users-admin at itk . org">mailto:insight-users-admin at itk . org</a>]On
Behalf Of Luis Ibanez
Sent: Tuesday, July 08, 2003 3:55 PM
To: Nils Hanssen
Cc: <a class="moz-txt-link-abbreviated" href="mailto:Insight-users at public . kitware . com">Insight-users at public . kitware . com</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">the inital
</pre>
<blockquote type="cite">
<pre wrap="">surface is shrinking to a point (I set the MaxRMSError to
</pre>
</blockquote>
<pre wrap="">zero) and the
</pre>
<blockquote type="cite">
<pre wrap="">number of iterations very high.
The filter is crashing in
SegmentationLevelSetFunction<TImageType, TFeatureImageType>
::PropagationSpeed(const NeighborhoodType &neighborhood, const
FloatOffsetType &offset) const
[...]
--> else return (
</pre>
</blockquote>
<pre wrap="">static_cast<ScalarValueType>(m_SpeedImage->GetPixel(idx)) );
// crashing here
</pre>
<blockquote type="cite">
<pre wrap="">[...]
When I set the propagation-weighting to - for instance -
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">0.0001 the
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">filter is not crashing, but the contour is not shrinking
</pre>
</blockquote>
<pre wrap="">according to
</pre>
<blockquote type="cite">
<pre wrap="">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
___<a class="moz-txt-link-freetext" href="http://www . caesar . de/ssl_">http://www . caesar . de/ssl_</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Insight-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Insight-users at itk . org">Insight-users at itk . org</a>
<a class="moz-txt-link-freetext" href="http://www . itk . org/mailman/listinfo/insight-users">http://www . itk . org/mailman/listinfo/insight-users</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Insight-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Insight-users at itk . org">Insight-users at itk . org</a>
<a class="moz-txt-link-freetext" href="http://www . itk . org/mailman/listinfo/insight-users">http://www . itk . org/mailman/listinfo/insight-users</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
Insight-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Insight-users at itk . org">Insight-users at itk . org</a>
<a class="moz-txt-link-freetext" href="http://www . itk . org/mailman/listinfo/insight-users">http://www . itk . org/mailman/listinfo/insight-users</a>
</pre>
</blockquote>
</body>
</html>
--------------030408000509070208030400--