Sorry for the late answer, I wa= s not quite able to reach a descent connexion during my trip.

From w= hat I remember and what I just checked quickly:

The "itkIma= geToTubeRigidRegistration" is the re-factored and cleaned version = of the initial one given the exact same results while the "itkImage= ToTubeRigidRegistration2" is a modified version of this previous c= lass.
This last one is supposed to be better as described here: (https://docs.google.com/open?id=3D1psAY1= BKx2pEfVPDF4S-xwHOuSP4Mrp7AxQXErgmmQvHthA-LvFauCEdfpQQs).
It is the one I would like to be the right one (I may have to go through an= other clean step however), nevertheless I was waiting for some feedbacks f= irst and as you are saying:

Comparing the output of the tests, the registered tube resampled onto
an image, the "2" result does not resemble the input image (as fa= r as
I can tell).

--> See Image enclosed.

I just have some trouble to explain this as the performance measureme= nt on the second metric seems to be more accurate and following a "mor= e" coherent curve and equations compared to the initial one (c.f. prev= ious link && enclosed convergence curves). I was thinking about fir= st making the read of the ".tre" file to be able to make some vis= ual comparisons; I am really open to any explanations/ideas about why the r= esults are that "bad" given the new metric.

Then, concerning the ability to read a ".tre" file into a vie= wer, It is exactly what I am currently working on. I will create a specific= module to get the reading and representation done as well as the integrati= on with a MRML scene.
Thank you to let me know if the plan suits you and do not hesitate for any = comments/suggestions.

Regards,
Michael J-L.

--f46d042ef47949693504c5adcc75--