Hi there,
I wonder if there are known issues with loading deformable registration DICOM objects using SlicerRT.
I have 2 CT volumes (“baseline” and “end”) which were registered in an external software suite (MIM 6.8.3) in a two-step process: A manual rigid registration followed by an automated (intensity based) deformable registration. Both registrations were then exported as DICOM objects and loaded into Slicer.
The rigid registration is converted correctly into a LinearTransform.
The deformable registration becomes two transforms: “1: DeformableReg: Intensity-based BL CT to ES CT [1]_DeformableRegistrationGrid” and “1: DeformableReg: Intensity-based BL CT to ES CT [1]_PostDeformationMatrix” (the latter being the identity transformation matrix).
When I apply the rigid registration and the deformable registration to the baseline volume, the result doesn’t even display (it generates some noisy patterns, but nothing like the result in MIM). Furthermore, although the volumes were more or less aligned after the rigid registration, they do not even overlap anymore as soon as the deformable registration is applied.
I might just get things wrong from the start, so I wonder if someone could point me to a tutorial or something (I didn’t find post similar to my issue here on the discourse board). I would also be happy to share screenshots or the original files, if that helps.
@stephan I know that @gcsharp had created some sample datasets, I believe using MIM, but I’m not sure how widely things been tested with various configurations etc. If you have data (no PHI) to share that illustrates any issues I’m sure that would be welcome.
Hi Stephen,
I’m not sure of the current status of DICOM deformable registration objects. I think it is still work in progress. But, maybe you can try dragging the post-deformation matrix onto the deformable grid, and then drag the image onto the post-deformation matrix, until it looks like this:
I will try to share the raw data tomorrow (when I’m back at the lab). Fortunately, PHI is not an issue, as it’s an animal study and the pigs told me they won’t mind.
Greg, I had tried your suggestion before, in both orders (DeformableRegistrationGrid as parent of PostDeformationMatrix and vice versa), with and without the additional rigid transformation.
Interestingly, the PostDeformationMatrix is diag(1,1,1,1), so it simply does not change anything.
Of course it might also be that MIM exports non-standard DICOM SROs. Are you by any chance aware of another free DICOM viewer that understands deformable registrations? I might then just double-check if the files can be read correctly there.
The viewer I use for quickly scrolling through a CT doesn’t do image fusion or anything beyond basic display.
Again, thank you so much for your quick replies.
Stephan
Here some screenshots to illustrate the issue:
Original in MIM
(top row: deformed baseline CT (rigid transform + deformable reg),
center: end study CT,
bottom: fusion)
When leaving out the rigid transformation (or applying it above the deformable one, instead of below), the result is less noisy, but still does not at all reproduce the deformation in MIM.
@stephan Import of deformable DICOM SROs is implemented but not well tested by any means. Also, export of such objects is not yet added. Luckily we have funding for fixing and improving this feature in SlicerRT, and according ot the timeline, it will be done quite soon (Nov 15 to Dec 31). Once we get there, I will fix loading of this object for your dataset as well.
In the meantime can you please send us the log after you load the deformable SRO? It’s in About / Report a problem. Thanks!
The log file was too long to paste it here (mainly because the two lines
[CRITICAL][Stream] 23.10.2018 12:19:28 [] (unknown:0) - W: Found element (3751,0104) with VR UN and undefined length, reading a sequence with transfer syntax LittleEndianImplicit (CP-246)
[CRITICAL][Stream] 23.10.2018 12:19:28 [] (unknown:0) - W: Found element (3751,0105) with VR UN and undefined length, reading a sequence with transfer syntax LittleEndianImplicit (CP-246)
are repeated roughly 250 times). I uploaded the log file to the google drive linked above.
I will upload them to the google drive later today.
I’ve checked the data sets and found the followings:
The two CTs are very far from each other and also rotated by 180 deg (probably the pig was put in head-first in one image and feet-first in the other image), which results in larger and more complicated transform as usual. It is not a problem per se, but makes registration a bit harder and may cause complications in some (see below). For future scans, try to place the subject in the scanner in approximately the same position and orientation (up to 45 deg rotation and a few 10 cm translation is fine).
Deformable (grid) transform includes large translation and rotation. This is an issue, as grid transform is only defined in a small region (at the region of the baseline image) undefined everywhere else, which causes issues computing transformation near the region’s boundary and computing inverted transform (that is needed for transforming target points, meshes, or performing various quantifications).
As a next step, configure MIM to separate transformation to bulk pre/post rigid component and a remaining deformable component. Large translation and rotation must not be included in the deformable transform component. There might be additional issues but it is difficult to investigate the issue with a deformable transform that does not behave well.
You may also check out SlicerElastix extension for intensity-based image registration. All you need is to rotate one of the images by 180deg to compensate for the head-first/feet-first mismatch and SlicerElastix registers the two volumes fully automatically, quite accurately, even with just using the default settings. See this animation that compares the “baseline” image registered to the “base” image:
It seems that the deformation is mainly a change in size:
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.
Exactly. I’ve tested this specifically and found that the large translation and rotation component in the deformable transform is the same as the separate linear transform, so the deformable transform already contains the same rigid transform, but baked into the displacement field. If there is no option in MIM to save the rigid component in pre/post transform or as a separate transform then it should be reported as a bug to MIM developers.
The grid transform is certainly not well conditioned. It may be still usable for some things, for example, transform the moving image that it was created from, but not for much else.
From what I can tell, SlicerRT seem to imports the transform correctly. However, it is odd that we cannot even make it work for transforming one image to the other, so maybe something else is wrong, too, but investigation is difficult because the transform is not well behaved.
The best would be to play a bit more with MIM to see if you can get a better deformable transform out of it. Also, please share the (anonymized) DICOM images as well, to make sure that there is no error in the DICOM->NRRD conversion.
Thank you for these clarifications.
I will play with MIM then and try to separate the rigid transform from the deformable one.
I’ll keep you posted on the progress.
