https://github.com/NifTK/MITK/commit/ebeef57db48eecace0938f446613185d091cef38

https://github.com/NifTK/MITK/commit/472a5d62e4c4ac94411f2b392264f110ff53ce9f

Note that in terms of T8802, these might be not the right directions. However, this should be handled in the interactor, in my opinion.

https://github.com/MITK/MITK/pull/162

What do you exactly mean by the following?

In T22112#87236, @espak wrote:

these might be not the right directions. However, this should be handled in the interactor, in my opinion.

I don't really understand if this is a "complete" fix or induces trouble somewhere else.

these might be not the right directions

I mean that in T8802 someone wrote that in axial window scrolling up should *not* go towards the top of the head but towards the neck / legs because that's what clinicians like. It was not clear to me if he meant the same for the other orientations. If yes, you might not want to take the second commit.

My point was that you have to set the inverse direction property of the stepper when you initialise the slice navigation controller. This should tell which direction means 'up' and 'down' in terms of world coordinates. This is necessary so that 'Next()' and 'Previous()' mean always the same in world space, even if the reference geometry was a non-image world geometry or an image geometry with flipped or permuted axes, or from an oblique image or whatever.

Whether you want to go 'up' in the world when you scroll up or you want to go down that's a matter of convention, but you must know in which way is up. The first commit sets this.

The convention can be handled in the interactor, e.g. you can have different xml configurations for different conventions. I did not check if the direction has changed compared to what you have now. Up goes up, right or forwards now, and down goes down, left or backwards.

I noticed two issues:

If the view direction is Original then the world axis should be calculated from the input geometry.

Wrong indentation.

I updated the PR. Just some tidying up.

As I noted in the comment in the source, the 'inverseDirection' property of the stepper might not the right place to handle this, as it is turned on-off in ping-pong mode.

So, consider the PR as a proposal, but you might want a different fix for this.

Thinking more about it, I think this is invalid. The scrolling direction was wrong because the renderer geometries had different handedness. The coronal renderer was left-handed, the other two was right-handed. This means that scrolling up in the coronal window brought you to the slice that was *ahead* of the current slice, not behind. Scrolling up in the other two renderers brought you to the slice behind the current one, as expected.

The handedness of the renderers has been fixed for T20180, so when the fix is merged for T20180, this can be closed.

Note that the fix for T20180 changes the scrolling direction for the coronal window, but this is correct because in the coronal window the patient is facing towards you. The patient's right is on the left side of the screen. (Just like in axial.) So, if you scroll up, you should go to the slice behind the current one, i.e. towards the back of the patient.