I have a bunch of beginner’s questions about what ITK can/cannot do.
We have a bunch of 3-D surface meshes (different faces, each with a bunch of different facial expressions). Different meshes have different number of vertices. We want to register these meshes pairwise. Obviously, this is just a case of non-rigid registration.
So my questions are:
(1) Can ITK do this sort of non-rigid registration (two surface meshes with mutually different number of vertices, i.e., no-corresponding vertices)?
(2) Is ITK the best tool for doing something like this, or should we be looking at something else? (If so, which?)
(3) Is there demo code available for how to do this?
(4) Is there an “ITK for Dummies”, especially something that explains to someone who is a programmer but an ITK outsider as to what ITK can and cannot do.
As far as I know, ICP can only do rigid registration.
You can non-linearly register meshes by converting them to binary masks, computing distance maps from them, and non-linearly register these distance maps (there are ITK functions for all these). However, points will be matched to close surface point and not necessarily provide anatomical match (e.g., a on a mesh of a wide smile, corner of the mouth may be mapped to mesh points on the cheek).
For anatomically correct non-rigid registration, you can identify anatomical landmarks and compute thin-plate-spline transform from these. The transform then provides correspondence for all the mesh points.
This is true in other libraries, but this is not true for ITK. In ITK, any of the many parameterized spatial transformations can be used, including multi-dimensional b-splines and dense displacement fields.
Important: If it is a new algorithm then it must have a new name. Taking the name of an existing well-known algorithm and attaching it to something else would cause a lot of confusion. This topic is just one example of that.
Technically, the library component is called itk::PointSetToPointSetRegistrationMethod. The example is called IterativeClosestPoint, because that is what it boils down to with rigid transform. Also to make it easier to find, as that is a well known name.
Some “historical” perspective: ITK’s implementation is not ICP (Besl, McKay). I remember discussing this with Luis Ibanez more than a decade ago. It is actually closest to the paper by Fitzgibbon.
The naming is indeed unfortunate, but it has been this way almost longer than the age of the average ITK user . So like many things, it’s this way because of historical reasons.
The issue is that if I see “iterative closest point” class name then I (and probably many others) do not even have a closer look at the class because I already know what the class does and how. It essentially makes a good ITK feature invisible.
This can be still fixed. The class could be renamed and the old name could be deprecated now and removed in 5-10 years.
. So like many things, it’s this way because of historical reasons.