[Insight-users] Speedimage for FastMarchingImageFilter
Lydia Ng
lng@insightful.com
Thu, 23 May 2002 09:40:05 -0700
Hi Nils and Bjorn,
> > In which correlation are the value in the speed image and=20
> the step the
> > evolving front is going outwards within one timestep?
>=20
> I'm not too familiar with the internals of the fast marching filter.
> Perhaps someone else on this list would care to answer this question?
The fast marching filter produces an image which the corresponds to the=20
time of arrival of the front at each pixel. So if you want to know
where the front is at time T, you will need to threshold the output at =
T.
The boundary between values less than T and values greater than T is=20
the position of the front at time T.
So if the speed image is an image of ones the output should be =
concenteric circles
(or a cone if you view the value as elevation). That is, the front =
(which starts
as one point) is marching out uniformly from the seed point.
As Bjorn described, if you used a speed image that is close to one in
homogenous areas and close to zero near edges that the front will get
"stuck" at the edges - thereby delineating the boundaries.
Of course, the quality of the delineation depends on how sharp the
edges are. If the edges are fuzzy, then the gradient might be small
the fast marching algorithm will eventually walk pass it.
BTW: James Sethian has great website explaining fastmarching
and level sets:
http://math.berkeley.edu/~sethian/Explanations/interface_explain.html
Hope this helps.
> The EdgePotentialImageFilter is supposed to do the former for you:
>=20
> <URL:http://www.itk.org/Doxygen/html/classitk_1_1EdgePotential
> ImageFilter.html>
>=20
> This filter didn't work too well the last time I tried it, but maybe
> it has been fixed by now. (Is that to be considered a bug report?)
Bjorn:
Thanks for your feedback.=20
If you have time could you detail the problems you are having=20
and we'll look into it.
Cheers,
Lydia=20
> -----Original Message-----
> From: Bjorn Hanch Sollie [mailto:bhs@pvv.org]
> Sent: Thursday, May 23, 2002 4:29 AM
> To: Nils Hanssen
> Cc: insight-users@public.kitware.com
> Subject: Re: [Insight-users] Speedimage for FastMarchingImageFilter
>=20
>=20
> On Thu, 23 May 2002, Nils Hanssen wrote:
> > I am wondering myself what is the appropriate speed image for the
> > fast-marching image filter.
> > In the "ShapeDetection" example, a=20
> GradientRecursiveGaussianImageFilter is
> > used in conjunction with some exponential damping.
>=20
> The speed image is the gradient magnitude image (edge image of your
> input image) scaled to values between 0 and 1. The formula for
> converting an edge image into a speed image to be used with the fast
> marching filter is typically something like this:
>=20
> g(I) =3D 1 / (1 + |(nabla * G)(I)|)
>=20
> or
>=20
> g(I) =3D exp(-|(nabla * G)(I)|)
>=20
> where G is a Gaussian and I is the input image.
>=20
> The input image is typically smoothed using a Gaussian, then the
> derivative magnitude is computed, and the result is then scaled to
> intensity values between 0 and 1. The resulting image should contain
> values close to 0 in regions with small variations in intensity and
> values close to 1 in regions with rapid intensity changes.
>=20
> The EdgePotentialImageFilter is supposed to do the former for you:
>=20
> <URL:http://www.itk.org/Doxygen/html/classitk_1_1EdgePotential
> ImageFilter.html>
>=20
> This filter didn't work too well the last time I tried it, but maybe
> it has been fixed by now. (Is that to be considered a bug report?)
>=20
> Another way to do it is to use the following filters in the order they
> are listed:
>=20
> DiscreteGaussianImageFilter (smooth)
> GradientMagnitudeImageFilter (compute gradient values)
> multiplying the result with -1 (for exmaple by using image iterators)
> ExpImageFilter (computes the exp(), obviously)
>=20
> > In which correlation are the value in the speed image and=20
> the step the
> > evolving front is going outwards within one timestep?
>=20
> I'm not too familiar with the internals of the fast marching filter.
> Perhaps someone else on this list would care to answer this question?
>=20
> -Bjorn
> --=20
> The History of the Universe
> Chapter 1: Bang! Chapter 2: Sss... Chapter 3: Crunch!
> The End
>=20
> _______________________________________________
> Insight-users mailing list
> Insight-users@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-users
>=20
>=20