I am really enjoying 3D slicer for 3D to 2D landmark registration, thanks for the great work.
There is one problem I am facing often: I want to continue working on a saved registration, but when I reopen the scene, all the landmarks are put to the origin. When I open the images first and load the landmarks separately, the same thing happens when opening the landmark registration module. When I just open one set of landmarks, at least they will be displayed correctly in the landmark registration module, but I have to redo the landmarks for the other image (volume). Is there a way to avoid this?
Thanks for any advice!
Hi @mbrammerloh -
It should be working to save/restore the state of the LandmarkRegistration module. I just tried it with some of the sample data and going to mrb file and back worked as expected. The module uses a simple naming scheme to recognize the correspondence between volumes and fiducial lists, so maybe if your volumes have unusual names or if you renamed anything it could break. It will automatically create lists if it doesn’t find an appropriate one, so you want to have your volumes and data loaded before entering the module.
Also note that this issue about not being able to select the landmarks is still outstanding but will hopefully be fixed either in VTK itself or in Slicer with the new markups infrastructure..
thank you for your advice, I think my “funny” file names were the problem. The landmarks were not recognized and new ones popped up, that makes sense.
PS: I am mainly working with Slicer 4.8.1 to avoid the landmark selection issue and am looking forward to the fix
Hi again, now I am again facing the same problem. I have not renamed anything and use just numbers and letters in my filenames. But when I open first volume one, then landmarks of volume 1, then volume 2 and landmarks of volume two, then open the landmark registration modlule, the following is the result: I end up with 8 instead of 4 landmarks, number 0 and 4, 1 and 5 and so forth on the same spot. The location is correct in volume 1, but in volume 2 they are placed incorrectly, that is, at the location in absolute space where the landmarks of volume 1 are, which in volume 2 of course is nonsense.
Another strange thing is that when I open the transformed volume in Slicer, it is not displayed as before, but somewhere else. This is really strange, because the original landmark registration in Slicer succeeded and was displayed correctly. Then I saved it, and when loading just the transformed volume, I get something different than before. On top of that: If I use ants to apply the transformation generated with slicer on the volume I want to transform, and use the first image as a reference image, it works fine and the volumes are registered as first seen in Slicer.
Maybe there is some problem with the nifti files I use? Is it possible that somewhere some header information is not used?
Hmm, I’m not seeing this behavior.
I did the following:
- load two volumes (I used the two brain tumor examples in SampleData)
- enter LandmarkRegistration and set them as fixed and moving
- turn on affine registration
- add/edit some landmarks
- save the scene
- close the scene
- reload the scene
- go back to LandmarkRegistration and re-select the volumes
After this everything seems to be as expected. Nifti files shouldn’t make any difference.
Note that the volume named -transformed is underneath the transform node when registering and saving, but if you reload it outside of the scene it won’t have been transformed.
Ok, I think it was again a problem with naming, after choosing very simple names it got better.
Thank you for the hint on the transform, that really helped me understanding the way Slicer is structured a little more
Now I can reopen the scene and in Landmark registration all landmarks are placed correctly. But somehow the _transformed volume is not rendered any more, the display seems to be frozen. Any idea why this is happening?
Thank you for any further advice.
(PS: I think having file names with dashes or underscores are very often used nowadays, so maybe the file name decoder could be adjusted in a way accounting for that. But this is rather an optional idea, not the real problem here.)
Alright, now it works, opening the same file, nothing changed. Really wondering what causes this behaviour.
Sorry for bothering you with not reproducible bugs…