Progress Report

December 20th, 2005

Work Agreed Upon

Work Agreed Upon - Ctd.

Paper Draft: Text and Graphics

Paper Draft - Ctd.

Break-down of Evaluation (Assessment) Approaches

Data Annotation and MIAS-Grid

Notes below are somewhat of an utter dross.

These have been added nonetheless to encourage a discussion.

There is an annotation associated with brain images. Point files: stored in a format which is not overly complex. It is built for easy parsing by the corresponding C/C++ code. Example is in the next slide.

Data Annotation and MIAS-Grid

version: 1
n_points: 163
{
118.833 102.5
117.492 100.992
116.333 98.977

[omitted]

104.363 29.637
116.742 26.258
}

Data Annotation and MIAS-Grid - Ctd.

'Version' is there just in case the format gets extended. The number of point is the number of 2-D points contained within the file. You then have pairs of numbers (in this case 163 of them) , which are pixel positions (X,Y) in the corresponding brain images. For each brain, there is one points file. The order of the numbers matters. It defines the correspondence. For example, the 10th point in one file corresponds to the 10th point in another. There can be hundreds of such files, which should typically go under a filename with the extension .pts

Data Annotation and MIAS-Grid - Ctd.

What determines the number of points in the files is a statement in line 2 of each file, e.g.: n_points: 163.

This number indicates exactly how many points are listed inside the subsequent brackets.

Points in the file often correspond to/are embedded in sharp edges and corners, e.g. points around the skull.

A registration algorithm is intended to give an annotation file that is 'correct'. Different registration algorithm could, in some sense, produce different annotation files.

Data Annotation and MIAS-Grid - Ctd.

Whether the point list an orderless list is an interesting question. In practice, the order matters. The points are numbered in such a way so that they can be connected without intersecting one another. There is also the triangulation to take account of. If one thinks of the skull, as an observer move from point 1 to 2, t 3 and so forth, the observer is probably just 'travelling' around the exterior of the head.

Data Annotation and MIAS-Grid - Ctd.

Misunderstanding related to the interpretation of the term "annotation".

Alan needed the label images.

The corresponding control points are indeed another kind of annotation.

One needs the topology of the triangulation to interpret point files in the same manner.

Data Annotation and MIAS-Grid - Ctd.

There is also another obvious issue: both types of annotation are special cases of a generic class. Different representations of the same thing are possible.

The annotations are binary images which represent the existence or inexistence of an anatomical structure, namely left/right ventricle, white matter, grey matter, and the caudate nucleus.

We have 37 such images.

Data Annotation and MIAS-Grid - Ctd.

The numbers in directory names are arbitrary and they simply stand for something that people at MGH used as ID's. There is no notion of control points. Each image in the directory /caudate_right, for example, shows the right caudate nucleus in white. Black color in the image is anything that is not the right caudate nucleus.

In the binary images you can see somewhat of a contour of the label. Think of such anatomical label as if it is represented by just the 'line' which surrounds it. The line, in turn can be sampled using a set of points. That is what the points are. They are usually a description of a label boundary.

Data Annotation and MIAS-Grid - Ctd.

In our case, we always deal with these anatomical structures.

In our experiments, the list which includes 8 structures is the full one.

There is only one point list; each corresponds to an original brain image.

Annotation can come in one of two forms: label images or a point list. Point lists can be ignored altogether.

Data Annotation and MIAS-Grid - Ctd.

The points represent locations in the image which are meaningful and distinguishable.

One can think of them as a poorer method of annotating images.

Labels are much more effective, but are more difficult to obtain.

Unrelated note: all VXL code was resent to Katy for re-compilation

kNN in Calculation of Model Indices

kNN in Model Evaluation

kNN in model evaluation
kNN-based Generalisation ability of degrading registration

Image Distances: A Greedy Approach

I was following the general approach that was named IMage Euclidean Distance (IMED). I relied on a gross implementation though. It took into account angles and locations of pixels to infer image distances. Instead of assuming a hyperspace with orthogonal axes, where each axis corresponds to one image position (x,y), we took into consideration their spatial relationships. Think of Euclidean distance in the image (between pixels) rather than the space images get embedded in.

Image Distances Greedy Approach - Ctd.

(*) not fuzzy at the moment, but in principle, this would be easy to extend.

Image Distances Greedy Approach - Ctd.

It will be very intersting to see how this compares with the shuffle distance. There are some free parameters to tweak, such as how to treat infinite distances. I haven't got around to thinking about it yet.

The Nearest Pixel Match Approach

Brain image unwarped
A brain in its original (unwarped) state

Nearest Pixel Map - 20/255

Brain image unwarped Intensity 20 location
Left: arbitrary brain image; Right: predicted location of intensity with value 20

Nearest Pixel Map - 57/255

Brain image unwarped Intensity 57 location
Left: arbitrary brain image; Right: predicted location of intensity with value 57

Nearest Pixel Map - 70/255

Brain image unwarped Intensity 70 location
Left: arbitrary brain image; Right: predicted location of intensity with value 70

Nearest Pixel Map - 100/255

Brain image unwarped Intensity 100 location
Left: arbitrary brain image; Right: predicted location of intensity with value 100

Nearest Pixel Map - 150/255

Brain image unwarped Intensity 150 location
Left: arbitrary brain image; Right: predicted location of intensity with value 150

Distance Map to Nearest Intensity Match - 20/255

Brain image unwarped Intensity 20 map
Left: first brain image from the set; Right: distance for each pixel from a pixel of value 20

Distance Map to Nearest Intensity Match - 60/255

Brain image unwarped Intensity 60 map
Left: first brain image from the set; Right: distance for each pixel from a pixel of value 60

Distance Map to Nearest Intensity Match - 100/255

Brain image unwarped Intensity 100 map
Left: first brain image from the set; Right: distance for each pixel from a pixel of value 100

The Effects of Dimensionality

(Carole) Could we say anything sensible about the way we would expect our measures to vary with the number of generated examples? This proved to be hard, especially due to the high dimensionality.

Entropic Measures - Discussion

Notes by CJT:

Entropic Measures - Discussion - Ctd.

Entropic Measures - Discussion - Ctd.

The best I can do so far is to point out that under the null hypothesis (the two distributions are the same) what we are measuring (in both the specificity and generalisation cases) is a monotonic function of the entropy of the common distribution.

This might lead us to consider a natural measure such as the difference between the entropy estimated from the A->B nearest neighbour (NN) graph (based on the length we currently compute for specificity), and that measured from the A->A NN graph -- where A is the synthetic set, and B the training set.

Entropic Measures - Discussion - Ctd.

Computed the A->A NN graph overnight. The B->B NN graph takes less than an hour to compute, so can ultimately code up the entropic expression and get the figures. This gives us a measure of overlap that is apparently sensitive. As we need to repeat this several times (e.g. 8), it takes a while to find out if it was all worthwhile.

However, we could just sample from the A->A graph. In practice, the first 18 examples were taken, which is not a wise choice (in retrospect)

Entropic Measures - Discussion - Ctd.

We can increase the sample whenever required or when time permits. It is built in a way which allows it to expand and the measures to becomes more accurate, i.e. depend on a greater proportion of the data in its entirety.

Entropy-based Overlap Estimation

Entropy-based Overlap Estimation - Ctd.

>> entropy([randperm(7)])

ans = 2.0691

>> entropy([randperm(7),randperm(7)])

ans = 1.9385

>> entropy([randperm(7),randperm(7),randperm(7)])

ans = 1.8762

>> entropy([randperm(7),randperm(7),randperm(7),randperm(7)])

ans = 1.8735

Entropy-based Overlap Estimation - Ctd.

Progress on Entropic Graphs

Progress on Entropic Graphs - Ctd.

We have an entropic method for estimating graph overlap, thus model and registration quality. To get some graphs, we will need to have run large evaluations overnight because of the matrix sizes and the code which is inefficient and interpreted rather than compiled and run.

Entropic Graphs in NRR/Model Assessment

Entropic Graphs in NRR/Model Assessment - Visual

Entropic graph-based evaluation
Entropic graph-based evaluation and comparion with other measures and intermediate steps

Next Experiment - Alternative Approach

Summary and/or Milstones Ahead