Page MenuHomePhabricator

DisplayGeometry origin changes unexpectedly when zooming
Closed, ResolvedPublic

Description

This happens in 2014.03 but did not happen in 2013.09.

When you zoom by mouse interaction, the Zoom action of the DisplayIteractor is called. It checks if the movement was along the 'zoom direction' (that can be 'updown' or 'leftright'), and calculates the distance of movement. If the movement is orthogonal to the zoom direction, the distance will be zero.

The scale factor is calculated based on the distance, in this case it will be 1.0, i.e. no zooming.

However, the mitk::DisplayGeometry::ZoomWithFixedWorldCoordinates is called in this case as well. This would not be a problem, if it would not change the scale factor and the origin, but unfortunately only the scale factor remains constant, the origin is changed, and the modification event is sent.

As a result, if you listen to the DisplayGeometry modification events, you will interpret the change as panning the image instead of moving.

Event Timeline

I meant "... as panning the image instead of zooming".

User lichtenn has pushed new remote branch:

bug-17830-trac-3517-display-geometry-zoom-with-1.0-factor

I could not reproduce the case that the origin changes while the scale factor remains constant.

Anyway, I agree that it is unnecessary to call mitk::DisplayGeometry::ZoomWithFixedWorldCoordinates, and therefore Modified(), if the scale factor is 1.0.

(In reply to Nils Lichtenberg from comment #4)

I could not reproduce the case that the origin changes while the scale
factor remains constant.

Did you try to attach a listener to the display geometry modification events? I did, and when it was notified, the origin was different but the scale factor was not. I did not notice any obvious abnormal behaviour visually, just by watching the Display while zooming, though. I mean, not with the MITK display.

Anyway, I agree that it is unnecessary to call
mitk::DisplayGeometry::ZoomWithFixedWorldCoordinates, and therefore
Modified(), if the scale factor is 1.0.

I got to the same conclusion, it's probably not worth more investigation than that. :) Even if also the origin remained unchanged, there is no point calling the zoom function with 1.0 factor.

[e26039]: Merge branch 'bug-17830-trac-3517-display-geometry-zoom-with-1-0-facto

Merged commits:

2014-06-11 14:31:34 Nils Lichtenberg [6e939e]
Merge remote-tracking branch 'pullReq-17830/bug-17830-trac-3517-display-geometry-zoom-with-1.0-factor' into bug-17830-trac-3517-display-geometry-zoom-with-1.0-factor


2014-05-31 12:45:09 Miklos Espak [c530a3]
Do not zoom with 1.0 factor

Signed-off-by: Miklos Espak <m.espak@ucl.ac.uk>