[Insight-developers] Mattes mutual information metric additions

[Miller, James V (GE, Research)]

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.
> 
>