Thank you for this thorough analysis.
The fact that the volumes are flipped head-first vs. feet-first is indeed unfortunate, but I would have thought that this is taken care of by the rigid (bulk) transformation.
A colleague performs the registration in MIM and I double checked with her that she first created the rigid transform to roughly align the two volumes and ran the deformable registration on the aligned volumes.
So does this mean that these components, which we thought to be covered by the rigid transform, are somehow duplicated in the deformation? That would be unexpected, but if that’s the case, we would have to dig into it in MIM.
Thank you for the hint. I struggled with PlastiMatch a while ago, but have not tried Elastix. The thing is that my colleague performs these registrations anyway (in MIM), so for consistency as well as to save some work, it would be really good if we could get the MIM → Slicer workflow running for this project. For other projects, however, I will definitely have a closer look at Elastix. The results in your images look great.
So, to conclude, would you say that the whole issue is because the deformable (grid) transform as exported by MIM is not sufficiently well-defined?
Or is this just an extreme case within the limits of the DICOM standard which is not yet handled correctly by SlicerRT?
I ask because there is a real chance that we can’t do much about how MIM exports these registrations, and so I wonder if we should then just wait and hope for the SlicerRT update or if I would have to start re-doing everything in Elastix.
Thank you very much
Stephan