# Interpreting point-to-point distance output

I am testing the fixed Model to Model distance extension. It can now calculate the point-to-point correspondence on windows. But I am having a hard time making sense of the resultant heatmap. As a reminder this is the same 3D model that a geometric transformation applied, resulting in a slightly different shape. This is the output I get.

Lets focus on the incisors as it displays the problem clearly. How can the front of the incisor is colored about -1.5mm, while the back of it is +1.5mm. The scalar plotted is the signed point to point distance.

If you measure approximately the corresponding distances on the source and target models, the magnitude of the difference at both front and back is right, but I don’t understand the sign difference in the model 2 model output.

any input on this?
@jcfr @pieper @lassoan

Did you put the data someplace where people can easily replicate the issue?

You can try with any of these
https://app.box.com/s/plth0mmkovmqrvizoa9j5t3y9dibx0j6

I usually set the mean as target and pc1 as source.

When you get the signed distance it is as defined here and that probably works well for simple shapes but not so well for these complex surfaces. The `x-p` vectors for the front and back of the tooth would be similar length and the same size, but the surface normals are opposite, so that would be why the sign shifts. The AbsolutePointToPointDistance (first image below) makes sense to me but the signed distance (second image) doesn’t have much meaning for this data.

Not quite sure why the surface normal would matter for a point to point distance calculation. For every vertex on source model, there is corresponding vertex on the target. It should simply calculate the distance between these vertices (in a paired sense), and the sign of the distance should come from this calculation (positive for distance larger in the target, and negative for the opposite).

Whatever the justification might be for it, it doesn’t make much sense to me.

I think the current behavior does make sense and the root of the issues is the lack of a consistent interpretation for “sign” in general for a surface like this one. You are correct that the point-to-point distance is very clear, and that is a positive number, the square root of the sum of the squares, defined only by the two points involved. But the “sign” would need to be with respect to some outside reference. In a simple case, say scaling a sphere about the center, the signed distance as calculated by the filter makes sense, because the surface normal of the sphere is a good approximation of the overall shape so that when the scale makes the sphere smaller the sign is negative and when you scale it larger the sign is positive. When the surface normals are not representative of the overall shape you get situations like the back of the tooth.

Perhaps what you really want is to calculate the principle moments or axes of the object and then get the dot product of the distance vector with those vectors to define the sign of the distance (effectively like approximating the object with an ellipsoid). I don’t see that the ModelToModel module implements this. It would be pretty simple to script up in python in Slicer using the SegmentStatistics module and some numpy manipulations.

In general defining the sign is going to be application-dependent, so picking the reference for the sign should be a part of the analysis design. For example I can imagine two skulls like yours where everything would be the same but the teeth would be larger in one than the other. In that case you’d want to define the sign of the distance in terms of the local axes of the tooth, not the full model of the head. Again I think the building blocks are all there in Slicer and just some code is needed.

It may also help if you remove the bulk linear transformation component and only visualize the remaining local deformation component.