[Insight-developers] Mattes mutual information metric additions

[Jim Miller]

Lydia,

I'll have to take a look at the Mattes code when I get back in the office.
But I was under the impression
that the bspline kernels were used to "populate" the histogram.  So instead
of a sample making a
contribution of 1 to a single bin, a sample would make a weighted
contribution to a number of bins.
I thought this and the fixing the sample set was the major differences in
the MI implementations.

But given this impression, it is not immediately obvious to me how the
analytical derivative is being
calculated.  But I'm sure it will become clear when I look at the code
tomorrow.  As you said,
maintaining the analytical derivative should be a priority.

Jim



On 5/31/06, Lydia Ng <lydiang at gmail.com> wrote:
>
> Here my 2 cents worth:
>
> One of the pro/benefit of the Mattes approach as stated in the paper was
> that
> an *analytical* derivative of the metric can be computed. The original
> paper used a BSpline interpolator and BSpline transform. We generalized the
> approach by allowing different interpolators and transforms.
>
> It is my understanding the histogram based version of the mutual
> information metric does not have this property and relies on the derivative
> to be estimated or require the use of an optimizer that does not require the
> derivative.
>
> While I am sure there is much debate about which approach is
> better/efficient/accurate, I think as a toolkit there should be room for
> both.
>
> I hope that any direct change to the Mattes class would keep the
> "analytical derivative" property intact. Otherwise, I think the modification
> should rightly belong in a subclass.
>
>
> - Lydia
>
>
> On 5/31/06, Miller, James V (GE, Research) <millerjv at crd.ge.com> wrote:
> >
> > Karthik,
> >
> > I just glanced at the Mattes code.  It looks like it is using
> > a uniform bin size.  It is also not using the Histogram class from
> > the Statistics package.  I believe the Histogram class from the
> > Statistics package allows for non-uniform bin sizes. So one option
> > is to convert this code (or develop a subclass that uses) non-uniform
> > bin sizes.  There are probably a number of heuristics from the
> > histogram literature for assessing whether your bins are too large.
> >
> > Jim
> >
> >
> >
> >
> > -----Original Message-----
> > From: Karthik Krishnan [mailto:Karthik.Krishnan at kitware.com ]
> > Sent: Wednesday, May 31, 2006 12:30 AM
> > To: Miller, James V (GE, Research)
> > Cc: Lydia Ng; Insight-developers (E-mail)
> > Subject: RE: [Insight-developers] Mattes mutual information metric
> > additions
> >
> >
> > Hi Jim,
> >
> > Thanks very much for the detailed answer.
> >
> > > What could be having an affect is how the pdfs are constructed. When
> > > you have a few pixels of high intensity, the sampling of the pdf (bin
> > widths)
> > > gets out of whack and you loose resolution in the pdf for the features
> > > (intensities) you are really interested in.
> >
> > Yes. Exactly what was happening. The histogram of the PET image had the
> > bulk of its intensities in the range 0-2 and hardly any from 2-8.
> >
> > > Since the pdf representation becomes
> > > inaccurate, I could see the registration failing if this happens.
> > >
> > > This is classic problem in kernel density estimation.  There are
> > several
> > > strategies to address it: non-uniform bins, hierarchical pdfs,
> > band-width
> > > selection techniques, etc.  Perhaps one of these solutions should be
> > > investigated.
> > >
> > > The approach that you are proposing essentially censors the data.  I
> > am not
> > > sure that I am in favor of this at the Mattes metric layer.  Perhaps
> > > data censorship could be handled at a higher level whereby all image
> > > metrics could benefit.  Data censorship usually leads to a set a
> > > robust statistical techniques (M-estimators to replace least squares,
> > etc.).
> > > These would have general applicability and solve a number of problems
> > > in image registration (registering data pre- and post-implant, etc.).
> > >
> >
> > I agree. Its a lot of work though :)
> >
> > > Alternatively, you could transform the PET data to SUV (standard
> > uptake value)
> > > instead of using the raw counts.  This would bring the dynamic range
> > > of the data down to [0, 6] or so.
> >
> > Yes. It was SUV data.
> >
> > > There are many formulas for calculating
> > > SUV based on data in the DICOM header.
> > >
> > > Jim
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: insight-developers-bounces+millerjv=crd.ge.com at itk.org
> > > [mailto: insight-developers-bounces+millerjv=crd.ge.com at itk.org]On
> > Behalf
> > > Of Karthik Krishnan
> > > Sent: Tuesday, May 30, 2006 2:04 PM
> > > To: Lydia Ng
> > > Cc: Insight-developers (E-mail)
> > > Subject: [Insight-developers] Mattes mutual information metric
> > additions
> > >
> > >
> > > Hi,
> > >
> > > We've had PET-CT datasets, (the PET ones in particular) with intensity
> >
> > > distributions where certain regions have very high pixel intensities
> > > that tend to throw the registration off course. I added some code to
> > the
> > > mattes that optionally allows the joint PDF computation of the metric
> > to
> > > be restricted to a fixed range of intensities and it seems to work
> > well.
> > >
> > > The API is simple. There are 4 optional methods :
> > > SetFixedImageLowerBound( ), SetMovingImageLowerBound( ),
> > > SetFixedImageUpperBound( ), SetMovingImageUpperBound( ).
> > >
> > > I've attached the patch and I would like to commit it, but I want to
> > > confirm with the author or others in case you think its just code
> > > clutter and I should tailor a derived class for my needs.
> > >
> > > Thanks
> > > -karthik
> > >
> > > PS: Just to clarify, setting the bounds is different from using a
> > > rescale intensity
> > > filter on the fixed and moving images prior to computing the metric.
> > > Rescale intensity filters clamp the intensities at the bounds.
> > Therefore,
> > > you will have an intensity peak at the bounds that also contributes to
> > > estimation of the joint intensity PDF's and distorts the histogram.
> > >
> > >
> > _______________________________________________
> > Insight-developers mailing list
> > Insight-developers at itk.org
> > http://www.itk.org/mailman/listinfo/insight-developers
> >
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.itk.org/mailman/private/insight-developers/attachments/20060531/c4c7bb15/attachment.html