Tried looking into how the translation sliders change when changing rotation sliders. It seems the bug arises from vtkTransform. When calculating the rotation matrix, the translation values in the transformation matrix are also changed. Need to check using a dummy project using vtkTransform. Will report back more on this later.

Found the reason: https://github.com/sankhesh/Slicer/blob/master/Libs/MRML/Widgets/qMRMLUtils.cxx#L89

The reason translation values change when changing rotation values is we post-multiply the transformation matrix. This is done (instead of the usual pre-multiplication) in cases of euler angles where the axes are not fixed but moving. I am not clear why we make this assumption for Slicer. I will check with JC, the original author of this code to get more info.

@sankhesh: Consider discussion with Alex Yarmarkovich, the original author of the code available in Slicer3. See http://viewvc.slicer.org/viewvc.cgi/Slicer3/trunk/Base/GUI/vtkSlicerTransformEditorWidget.cxx?r1=1435&r2=1434&pathrev=1435

As a hacky workaround you can paste this line into the python console to set the properties of the sliders. Go into the transforms module first to create the widgets and then run this:

for s in findChildren(findChildren(text='LR')[0].parent().parent().parent(),className='qMRMLLinearTransformSlider'): s.singleStep = 0.0001; s.decimals = 5; s.pageStep = 0.001

Fixed 1) in r22152

Resolving this issue since two child issues have been resolved. See 0002480 and 0002584

Closing resolved issues that have not been updated in more than 3 months

May I suggest to re-open this issue? I don't think it's fixed and people have asked about it over the years. I forgot, too, about the incantation that'll do the trick, the one by @pieper above, or

for s in findChildren(className='qMRMLLinearTransformSlider'): s.singleStep = 0.1; s.decimals = 2; s.pageStep = 1

Still, I suggest something like adding two buttons: Stepx10 and Step/10 with an indication of current increment (1mm as default). There's plenty of room on the line with the Min and Max (that still apparently may mess up your transformation if you change them). Rotation is less important in my opinion because default is 0.1 degree and PgUp/PgDn does 1 degree.

(The other annoyance is that the "Identity" button should be "Default" , which should reset to the original loaded transform (or identity). I couldn't find the ticket for that.)

Thanks @nick_silzer - you are right there's a lot of room for improvement here and I like the design you propose. This would be a good task for a new developer wanting to learn while doing something useful.

Probably this issue has not got enough attention because manual translation by adjusting a slider is so much worse, compared to registration using landmarks (or automatic intensity-based image registration).

Fundamental issues with slider-based manual registration process:

• it is an iterative process (you need to adjust multiple sliders several times, while looking at multiple views to check alignment), therefore time required to complete the registration is unpredictable and can be quite significant if both rotation and translation must be aligned
• assessment of alignment is difficult, as you need to display two images overlaid on top of each other, which makes details hard to see on both images; especially when there is non-rigid deformation between the two images
• it only supports rigid registration

Landmark registration (Landmark registration module in Slicer core; Fiducial registration wizard module in SlicerIGT) does not have any of the issues: you specify a set of anatomical landmarks (3 or more) on each image or model and you are guaranteed to get the final, correct, rigid or non-rigid registration directly , without the need for any iterations.

You may also use fully automatic intensity-based image registration, which similarly do not have any of the above-described fundamental issues.

Do you have any specific reason to use sliders for manual registration?

@lassoan There are three use cases in my work that depend on manual transforms:

a) Defining a ROI box aligned with an arbitrary plane -- for say MIP inspection of volume of interest or mimicking a thick slice setting.

[If possible I avoid using the reformat widget because of the UI problem that the 3D viewer becomes electrified: in practice, I can't tumble/rotate without messing up carefully placed reformat vectors because I always loose track in my mind of all the current lock and activate mode status of widgets and what -- and in any case it's cumbersome to toggle them on and off. In this sense, manual transforms are frustration-free!]

b) The initial transform for automated registration in case of volumes that are clipped (on purpose, or by clinical use such as CT sinus v. CT head). With a little practice, a rough initial transform is easy to make.

c) Fiddling with calculated transforms and masks; I stuff the calculated transform under a temporary tuner transform or play with it directly.