crc_meanHausdorffDist normalization

[CPernet]

Hey Chris,

could you add a normalization factor ? last time i think we agreed on dividing by the total number of voxels from one of the images so that max is 1

cheers

[ChristophePhillips]

Thinking of the issue with large values for the Haussdorff distance, it's not that simple.
My impression is that when a cluster is missing, then you end up with large H-distance. In other words the H-distance only provides useful information (how well do blob contours match) when there is a match between the blobs. We could condition the H-distance to only matching blobs?

Let me come up with a demo case and some tests. :-)

[CPernet]

ok not sure I follow here - what I talking about is that between subjects we have comparable values
so in the loop I add
if normalize
D12 = D12 ./ max(D12);
D21 = D21 ./ max(D21);
end

[ChristophePhillips]

I do not think this is the right way to deal with the very variable H-dist values returned. The distance is expressed in mm, averaged over the contours of the blobs in the pair of images. This thus some "absolute" measure. If it's big, then it means some border was, on average, very far away from a border in the other image. :-(
In fact H-dist is only useful when the blobs in both images are matching, like here. On the other hand if the blobs are not overlapping at all, then H-dist doesn't mean much at all, only how far away (on average) the borders of 2 non-overlapping blobs are located which boils down to about the distance between their centre of gravity. See the test with img3 and img3b in testing_imgOverlap.m. (Available in the branch MPMextendedTPM.)

Possible solution:
Only calculate the H-distance for blobs that are matching across the images. Then the measure would only be interpretable in combination with the cluster TP/FP counts...