[Insight-users] Speedimage for FastMarchingImageFilter

[Nils Hanssen]

Hi Lydia, Björn,

thanks very much for your help, the only problem was that my speed function
was inverted (high gradient -> high speed and vice versa...). Know, its
working fine.

Thanks again!

Regards,
Nils.

> Hi Nils and Bjorn,
>
> > > In which correlation are the value in the speed image and
> > the step the
> > > evolving front is going outwards within one timestep?
> >
> > 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
> 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
> 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:
> >
> > <URL:http://www.itk.org/Doxygen/html/classitk_1_1EdgePotential
> > ImageFilter.html>
> >
> > 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.
> If you have time could you detail the problems you are having
> and we'll look into it.
>
> Cheers,
> Lydia
>
> > -----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
> >
> >
> > 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
> > GradientRecursiveGaussianImageFilter is
> > > used in conjunction with some exponential damping.
> >
> > 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:
> >
> >   g(I) = 1 / (1 + |(nabla * G)(I)|)
> >
> > or
> >
> >   g(I) = exp(-|(nabla * G)(I)|)
> >
> > where G is a Gaussian and I is the input image.
> >
> > 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.
> >
> > The EdgePotentialImageFilter is supposed to do the former for you:
> >
> > <URL:http://www.itk.org/Doxygen/html/classitk_1_1EdgePotential
> > ImageFilter.html>
> >
> > 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?)
> >
> > Another way to do it is to use the following filters in the
> order they
> > are listed:
> >
> > DiscreteGaussianImageFilter (smooth)
> > GradientMagnitudeImageFilter (compute gradient values)
> > multiplying the result with -1 (for exmaple by using image
> iterators)
> > ExpImageFilter (computes the exp(), obviously)
> >
> > > In which correlation are the value in the speed image and
> > the step the
> > > evolving front is going outwards within one timestep?
> >
> > 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?
> >
> > -Bjorn
> > --
> > The History of the Universe
> > Chapter 1: Bang!  Chapter 2: Sss...  Chapter 3: Crunch!
> > The End
> >
> > _______________________________________________
> > Insight-users mailing list
> > Insight-users@public.kitware.com
> > http://public.kitware.com/mailman/listinfo/insight-users
> >
> >
> _______________________________________________
> Insight-users mailing list
> Insight-users@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-users
>