Manually Adjusting Transform - Applied Object Seems to Jump Around; Matrixes Not Edited As Expected

[tpal_1 (Tara Palnitkar)]

Operating system: Mac OS Monterey 12.7.1
Slicer version: 5.6.1 (and 5.2.2)

I have had consistent issues when manually adjusting transforms in Slicer 5.2.2 and Slicer 5.6.1. It seems that minor changes result in the transformed image “jumping”, as if the origin has changed. For instance: If I change the LR value to be 1, then 1.2, then back to 0 (doing no other steps in the meantime) I would expect the final result to be nothing or the identity transform. However, it results in a shift of -2.4.

When I adjust the LR value to be 1, the transform matrix acts as expected

[1 0 0 1
0 1 0 0
0 0 1 0
0 0 0 1]

Then, changing the LR value slightly more to be 1.2, suddenly the matrix jumps to be completely different:

[1 0 0 -1.2
0 1 0 0
0 0 1 0
0 0 0 1]

and finally, setting the value back to 0 yields:

[1 0 0 -2.4
0 1 0 0
0 0 1 0
0 0 0 1]

I have noticed the same behavior in other axes/rotations/etc. I’m attaching a few snapshots showing the above example.

I understand that this might be related to another question: Transformation questions, reset plane angle when adjust another one[possible bug] and the note in transforms about resetting sliders to 0.

However, as-is, this still doesn’t seem to be performing as expected, and it makes it essentially impossible to make any manual adjustments to a transform (for instance, for creating an initialization for a registration or for manually adjusting the position of a model, etc).

Is there anything I should be doing differently? And if not, is there any way to address this?

Thanks!

[muratmaga]

As far as I know, the last column is the translation values. So, if you are entering 1.2, it is shifting the image to the R by 1.2 mm. This is equivalent to using the sliders for translation and in the L/R sliders shifting to 1.2mm. So that’s expected and normal.

It not a typical case you want to edit the transformation matrix manually. What are you trying to do ?

[muratmaga]

@tpal_1

If I change the LR value to be 1, then 1.2, then back to 0 (doing no other steps in the meantime) I would expect the final result to be nothing or the identity transform.

That’s exactly observsing in my end:
No displacement

2.5 mm L/R shift

Back to where we started:

[tpal_1 (Tara Palnitkar)]

My issue is that when I enter 1 the shift is to the right (as expected) by 1, but then if I amend it to be 1.2, the result is actually a shift to the LEFT (ie -1.2).

In your example if after the first change to 2.5 you changed it to be 2.7 do you see the same behavior?

We use this functionality fairly regularly, to manually place models in expected places and/or make small-adjustments to registrations.

[muratmaga]

Changes are not cumulative. if you enter 1 and then retype it 1.2, the expected shift is 1.2, not 2.2. Were you expecting to be 2.2?

Because simply altered the origin in X coordinate by 1.2, instead of 1.0.

[tpal_1 (Tara Palnitkar)]

I would expect the result to be1.2. 2.2 would also make sense to me, but not -1.2, which is what I’m seeing.

[muratmaga]

That’s not what I am seeing, if I enter a positive value, image is shifting to the right (on the screen it is reversed due to the convention. But you can verify on the 3D rendering. I am using the MRHead sample data.

If this is not happening, check the IJK2RAS matrix of your volume, which you can find under volumes.

[tpal_1 (Tara Palnitkar)]

I have the same issue even with the sample MRHead data.

A single adjustment results in the expected shift (in this example, a shift to the right of 10mm). Subsequently editing the 10.0 value to be 10.5 results in a shift to the left of 10.5mm.

The IJK2RAS matrix looks as expected to me.

[pieper (Steve Pieper (Isomics, Inc.))]

I cannot replicate what you are describing @tpal_1

I do the following:

• Start a fresh Slicer
• Load MRHead from SampleData
• Add a linear transform and apply it to the MRHead
• Type 10 into the upper right element of the linear transform → Head moves 1cm
• Type 10.5 into the element → head moves another .5 mm

No negative element is introduced.

[tpal_1 (Tara Palnitkar)]

Thanks for looking @pieper.

I consistently have this happen, even following your steps.
Additionally, it makes no difference whether I hit enter after entering the 10.0 or whether I stay in the box and just continue editing.

[tpal_1 (Tara Palnitkar)]

I have noticed that this issue only happens when entering decimal amounts (ie changing from 10.0 to 10.5) but not changing the whole value.

It seems to be resolved when instead of inserting a 5 after the decimal point, I instead replace the ‘0’ following the decimal point.

So changing the value from ‘10.0000’ to ‘10.50000’ causes the negative introduction I’m seeing, but changing the value from ‘10.0000’ to ‘10.5000’ does not.

Is there possibly some part of the code that requires a certain number of decimal places causing this issue?

[muratmaga]

So your issue is as you enter the decimal point, a negative sign is automatically inserted? Does it happen in other fields as well? Does this happen in any other module? E.g., if you enter the value into translation field (as opposed to the matrix), do see a sign change as well?

I can’t seem to replicate this on mac with 5.6.1. I increased the precision to 5 decimal place to see if that has an effect, it doesn’t seem to do anything.

Do you have any customizations done to via the slicerrc.py or some other means?

[tpal_1 (Tara Palnitkar)]

I’m only editing the translation/rotation fields (the values next to the sliders), not the matrix itself. But this happens in any translation and any rotation.

I don’t believe I have any customizations, and I re-downloaded 5.6.1 directly from the website before doing these latest tests.

I think it’s easiest to demonstrate my problem by a screen recording, which I’m including a link to here: https://youtu.be/hgrFwzy9wVA

[muratmaga]

really bizarre, Can’t replicate on my end.
@lassoan @pieper ?

[pieper (Steve Pieper (Isomics, Inc.))]

No, I can’t replicate that either. There must be something we’re not seeing…?

[tpal_1 (Tara Palnitkar)]

This does only happen for me in local reference frame.

Additionally, I know colleagues of mine have the same issue, but admittedly we might be working with similar setups, although again I don’t think any of us has changed anything behind the scenes.

[pieper (Steve Pieper (Isomics, Inc.))]

Can you replicate this using the MRHead SampleData? Maybe you can share a file for which this happens, or at least show the Volume Information from the volumes module. Maybe local mode is the issue. Typing directly in the upper right element of the mattrix should do a global LR translation.

[tpal_1 (Tara Palnitkar)]

@pieper

This happens regardless of the volume I use.

I have done this on the MRHead data, as in the above screenshots and recording https://www.youtube.com/watch?v=hgrFwzy9wVA

Again, this issue doesn’t occur when I edit the matrix itself, but rather the fields next to the sliders for LR, AP, IS and rotations.

[pieper (Steve Pieper (Isomics, Inc.))]

Okay, thanks, yes, I can replicate this now. It seems there’s some interaction between using the local mode and the code that manages the number of decimals being displayed.

I can replicate with these steps:

• Load MRHead, create and apply linear transform to it
• Switch to local transformation mode
• Click left of the decimal point in the LR translation slicer text box and type 1
  => head moves to patient right, upper right element of matrix is 1
• Use arrow to move to the right of the decimal point and type 5
  => head moves to patient left, upper right element is -1.5
• Type more 5s into and the matrix element gets more and more negative

Until this can be investigated and resolved I would avoid the slider and edit the matrix directly. Is there a reason that doesn’t work in your use case>

[tpal_1 (Tara Palnitkar)]

Thank you! Yes, we can work around this for now, but it will be great to have it resolved!

Is there some way that I should flag this as a bug officially?