[Insight-users] Speed of Mutual Information calculation

[m.weigert at fz-juelich.de]

Hi Karthik,

my impression is, that Mattes is faster than the viola - wells
implementation, but I wouldn't rely on it.

But another question:
What is the difference between an image to image metric and a histogram image to image metric, and why is there a NormalizedMutualInformationHistogramImageToImageMetric but
not a NormalizedMutualInformationImageToImageMetric in ITK?
I suppose, the histogram image to image metric compares the histograms in
a certain way to evaluate the similarity between to images.
So what are the special circumstances or problems when you prefer to use a
HistogramImageToImageMetric instead of a common imageToImageMetric?


Regards,
Markus




----- Original Message -----
From: Karthik Krishnan <Karthik.Krishnan at kitware.com>
Date: Tuesday, May 16, 2006 5:18 pm
Subject: Re: [Insight-users] Speed of Mutual Information calculation

> Markus Weigert wrote:
> 
> > Hi Luis,
> >
> > thanks for your response.
> > I use the Viola - Wells implementation.
> > Strangely, the Mattes implementation is much faster.
> 
> That is strange. Is this for the same number of spatial samples in 
> both 
> Viola-Wells and Mattes and for the same number of iterations in 
> both 
> cases. I would think *one iteration* of Mattes should be slower 
> than 
> *one iteration* of Viola-wells cause of the BSpline based parzen 
> windowing.
> > I compiled for release with dbg. information on VC6
> > and used GradientDescentOptimizer, not 
> > RegularStepGradientDescentOptimizer.
> > I plot the progress from a Command Observer and currently don't 
> use 
> > multiresolution
> > (only on the original resolution).
> >
> > Cheers,
> > Markus
> >
> >
> > ----- Original Message ----- From: "Luis Ibanez" 
> > <luis.ibanez at kitware.com>
> > To: "Markus Weigert" <m.weigert at fz-juelich.de>
> > Cc: <insight-users at itk.org>
> > Sent: Monday, May 15, 2006 4:40 PM
> > Subject: Re: [Insight-users] Speed of Mutual Information calculation
> >
> >
> >>
> >> Hi Markus,
> >>
> >> Nope, this is not the common time for this size of images.
> >>
> >> This type of registration should take about 2 minutes in
> >> a modern standard computer.
> >>
> >>
> >> Some questions:
> >>
> >>
> >> 1) Are you compiling your application for "Release" ?
> >>
> >> 2) Are you using multi-resolution ?
> >>
> >> 3) Are you using the GradientDescent or
> >>    the RegularGradientDescent optimizer ?
> >>
> >> 4) Are you plotting the progress of the optimizer ?
> >>    from a connected Command Observer ?
> >>
> >> 5) Which one of the 5 ITK implementations of
> >>    Mutual Information Metric  are you using  ?
> >>
> >>
> >>
> >> It is very likely that you are letting the optimizer run
> >> for a lot of uncessary iterations.
> >>
> >> Have you measure the time needed for performing One iteration ?
> >> This will indicate if the problem is to have too many iterations,
> >> or to have metric evaluations that are too slow.
> >>
> >>
> >>
> >> The best way to figure out the problem is to analyze the
> >> trace provided by the Command Observer.
> >>
> >> Given that you are testing with a 3D translation transform,
> >> you are in the lucky situation were you can actually plot
> >> the path of the optimizer in the parametric space.
> >>
> >> You could use a tool such as GNUplot, in order to see this
> >> path in 3D.  Other easy options are a VTK script, or saving
> >> the trace in a .vtk file and loading it into ParaView.
> >>
> >> Whi
> >>
> >>
> >>
> >>
> >> =====================
> >> Markus Weigert wrote:
> >>
> >>> Dear insight users,
> >>>  I currently try to register two 3D images (CT and MR)
> >>> by using mutual information as metric.
> >>> The images have a size of approx. 255 * 290 * 75 slices each 
> (MR 
> >>> perhaps even more).
> >>> Although I use a very simple transformation (translation) and 
> a 
> >>> graddescent
> >>> optimizer, one iteration of the optimizer takes more than 1.5h.
> >>>  Is this a common time for images of this size???
> >>> The metric uses 60000 spatial samples.
> >>> I thougt about using BSpline transform in the next step of the 
> >>> registration
> >>> with MI metric too, but I think I can forget to do this, if I 
> have 
> >>> to deal with 3000 Parameters
> >>> to be optimized!
> >>>  Regards,
> >>> Markus
> >>>  --------------------------------------------------------------
> ---------- 
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
>