Hierarchical approach to 3d registration (Regression hunting)

[jcfr]

Caution

This pull request was created to provide a reference to a prior version (before rebase and final integration) to tentatively identify a working version and help identify where the registration was "broken".

It should NOT be integrated.

Related pull requests & issues:

• ENH: Hierarchical approach to 3d registration #99

[sbelsk]

Testing each of the commits going back from 4c5b380 to 512452e (inclusive) using the data and steps outlined in #119, I'm getting the same bad results as I do on my installed version of Slicer 5.6.2 and AutoscoperM version 7d1de4d (2024-09-11), which look like this:

Notice the radius and the trapezium are not registered correctly. I had the mc1 and tpm bones nested at the same level, both under the rad, and attempted tracking with the rad as the root node.

When I tried to test 77e189c and 77254f3, I had issues with the Tracking3D module trying to execute import Elastix in line 3 of Tracking3D.py because the module couldn't be found.

I can't seem to search and install new extensions in my Slicer exe that I built from source, and it doesn't seem to know about the extensions I have installed using my installed version of Slicer. I tried clicking the "Install from file..." button in the extensions manager and install this zip, but got the error:

No extension description found in archive '<path to zip>'

So I also tried copying the installed files of the SlicerElastix extension from where my installed version of Slicer stores them, and I put them into my SlicerAutoscoperM build tree next to Tracking3D.py.
That seemed to work around the import error, but soon after clicking the "Apply" button to run the registration on either 77e189c or 77254f3 I got the error:

and the details say:

Traceback (most recent call last):
  File "C:\D\SD\Slicer-build\bin\Python\slicer\util.py", line 3295, in tryWithErrorDisplay
    yield
  File "<...SAM_build>/inner-build/lib/Slicer-5.7/qt-scripted-modules/Tracking3D.py", line 246, in onApplyButton
    self.logic.registerSequence(CT, rootID, startFrame, endFrame, initialGuess)
  File "<...SAM_build>/inner-build/lib/Slicer-5.7/qt-scripted-modules/Tracking3D.py", line 398, in registerSequence
    self.registerRigidBody(
  File "<...SAM_build>/inner-build/lib/Slicer-5.7/qt-scripted-modules/Tracking3D.py", line 352, in registerRigidBody
    self.elastixLogic.registerVolumes(
  File "<...SAM_build>/inner-build/lib/Slicer-5.7/qt-scripted-modules/Elastix.py", line 637, in registerVolumes
    self.logProcessOutput(elastixProcess)
  File "<...SAM_build>/inner-build/lib/Slicer-5.7/qt-scripted-modules/Elastix.py", line 572, in logProcessOutput
    raise subprocess.CalledProcessError(return_code, "elastix")
subprocess.CalledProcessError: Command 'elastix' returned non-zero exit status 3221225781.

So that didn't really work, I still need a way to install SlicerElastix properly. @jcfr Any suggestions?

[sbelsk]

With @jcfr's help, I got SlicerElastix building from source to work with the testing of 77e189c. I must be misusing the feature or providing some unexpected data, because on this commit, I'm getting results that look like:

As in the released version and in the other commits I tested, the radius doesn't seem to be tracked despite being the root node of the selected hierarchy.

[jcfr]

Closing, this is superseded by the following:

• BUG: Fix off-by-one bug in end frame for 3D registration #127
• BUG: Fix wrong transformation layers applied to generated PVs #128

For context, this pull request was originally created to provide a reference to prior version (before rebase and final integration) to tentatively identify a working version and help identify where the registration was "broken".