"Rotate to volume plane" flips image orientation as seen in the slice viewer

I recently discovered a rather disturbing regression. When I examine an axial image that was acquired in an oblique plane, it appears that the image is effectively flipped when “Rotate to volume plane” is toggled.

In the video below, I demonstrate this problem with today’s nightly and this prostate T2w MRI series

To explain, I first scroll through slices in the superior direction (towards the head), and as expected the bladder is closer to the head than the apex of the prostate. I then rotate to the volume plane, and do the same, and now when I scroll the image in the same direction, it scrolls in the direction of the apex. As seen in the 3d viewer, the direction is changed as compared to the original one. I say the image is “flipped”, because based on the slider position reported by the red viewer, the plane position showing bladder in Axial view shows apex in the Reformat view!

This is indeed a regression, since when I do the same operation in the latest stable release, the behavior is consistent with my expectations.

The change in behavior is the result of some recent improvements of this feature (you don’t need to reset manually to Axial/Sagittal/Coronal standard orientation and reapply “rotate to volume plane”, no need for guess which standard orientation will show a single-slice volume, etc). Part of this was standardization of coordinate axes directions, so that slice X, Y, and normal directions are always in a right-handed coordinate system (before this, it was left-handed for axial and sagittal orientations and right-handed and coronal).

I agree that the left/right-handedness should not flip, so this should be fixed.

Since all other coordinate systems in Slicer are right-handed, I would find it more intuitive to make all slice coordinate systems consistently right-handed, too. Do you have any preference for making slice XYZ coordinate system left or right handed?

Maybe we could postpone standardization of default orientations and just keep whatever handedness the slice coordinate system during rotate to volume plane operation.

Andras, I just think that this is a breaking change, and in this particular situation the orientation should not change after rotating to volume plane. When I first saw this, I was confused for several minutes trying to figure out if something was wrong with the acquisition, or the image was flipped during conversion. I think the current behavior is a bug. By the way radiologists sometime report finding location by slice position.

I have fixed flipping of left/right-handedness when “rotate to volume plane” is clicked (https://github.com/Slicer/Slicer/commit/ea79c943d168f637cb3347bda199d47bbb111890).

Is there any preference in which slider direction corresponds to which anatomical direction? Current default directions are inconsistent from software design standpoint (sometimes left, other times right handed coordinate system), but if there is a strong user preference for slider/anatomical direction mapping then they may be left as is.


Displayed slice position was not impacted. Only slice offset direction -> slider direction mapping was flipped in some cases.

Thank you! I will test it next week.

I am confused by this question. I thought Slicer uses RAS coordinate system, which means that coordinates increase as we move in the IS direction. If I am in Axial (or in Oblique view that is “close” to Axial), I expect that if I move from apex to base of the prostate, my slider position will increase.

If you look at the first screencapture I attached, the slice position was indeed different when the axis is flipped. The same numeric location of the slider position can be either in the apex or base of the prostate, depending on whether you did rotate to volume plane or not. Maybe there is some other way to look at it, but if I think of a radiologist, who looks at the slider position, and for whom 3d view is usually a nuisance, I think they would be really scratching their heads seeing this.

If slice positioning slider is moved to the right then the slice is moved towards slice normal direction (third column of SliceToRAS matrix). This is independent of what coordinate system is used.

This is a good point. Slice position in oblique views is simply the signed distance from the origin along the slice normal direction. Therefore, for oblique views, the numeric value has no absolute meaning (the same physical position may correspond to infinite number of different displayed numeric values). Maybe we should hide the numerical value from the slice slider when the slider is not aligned to world coordinate system axes to make sure users don’t want to interpret it as some anatomical coordinate.

I confirm that the issue is fixed in the nightly, thank you @lassoan!

1 Like