[SVN revision 29606]
FIX (#6788): If a contourmarker is added the marker`s Geometry was always include for computing the boundingbox when a global reinit was performed. I set a property so that the node won't be included for the boundingbox computation any more. But there is still an error in the slice navigation controller.

Renamed this bug from "SliceNavigationController doesn`t jump exactly to the geometry specified by a point and normal if the planes are rotated" to the present name. This is rather a feature request than a bug so I changed that too.

First of all a little summary of what is the present state:

• Due to the segmentation in rotated image slices the need occurred to save the exact position of a rotated slice. This is neccessary if you want to edit a previously drawn contour. (It is nearly impossible to hit the exact rotated position again manually)

• The mitkSliceNavigationController offers a function called "ReorientSlices" which needs the rotated plane's normal and one of its points. In this function a RotationOperation is generated and executed on the current geometry of the selected SliceNavigationController.

• The problem is now that the normal of received rotated plane is correct BUT its axes vectors are different from the original ones. So its rake is correct but the position of the axes vectors is wrong and hence the complete geometry.

• What we need now is the possibility to allow a rotation which takes the axes of the original plane into account. The result should be a plane which the same normal, position, axes and extent as the original plane.

After a meeting with Mathias Seitel I have some suggestions:

1. Save somehow the Geometry of the rotated plane's SliceNavigationController and try to set it when it is neccessary. But the question is here if that solution is not a contradiction the the SliceNavigationController's concept.

2. Or better: Create a new RotationOperationType (which incorporates the axes) and execute it on the according plane. Of course there should be an according function in the SliceNavigationController like ReorientSlicesAxesCorrect. In this function we create the new RotationOperation (e.g. OpRotateAxes) and execute it on the SliceNavigationController's geometry. (The mitkPlaneGeometry has already a function that initializes a standard plane by axes)

In each case we must think of a possibility to save the informations of the rotated plane. Neither a geometry nor an operation can be stored in the datamanager or persistently.

Any comments or suggestions?

Ok I created a new type of rotation operation which takes the axes and some more informations. Furthermore I adapted the Geometry Classes and the mitkSliceNavigationController so that they can handle this new operation.

So far it looks like the axes of the new geometry are correct after a performed rotation but the origin is wrong.
As I can see the origin is adapted to the rotated plane's extent in the function "ReinitializePlanes( const Point3D &center, const Point3D &referencePoint )"
but I don't what is exactly done there and why this is done.

All I understand is that in this function a new directed spacing and a new extent are calculated and the origin is adapted with respect to the original image's center.

Can anyone explain that to me (Mathias perhaps :-))?

(In reply to comment #4)

Can anyone explain that to me (Mathias perhaps :-))?

Do you have a git branch with your work done so far?

(In reply to comment #5)

Do you have a git branch with your work done so far?

Yes I made some but I am not sure whether I pushed it yet. The branch is called
"bug-6788-wrong-rotation-with-slicenavigationcontroller". If you can't find it I will push the branch at the next tuesday (then I will be at the office again)

Thank you so far!

The branch is pushed but maybe I found the error. I could be that the point of rotation is wrong. Before you have a look at the branch let me first try the rotation with the correct point.

Resetting all bugs without active assignee flag to "CONFIRMED". Change status to IN_PROGRESS if you are working on it.

I finally got it. Now it is possible to store any rotated (or not rotated) position and restore it at any time from any other position.

I wrote the mitkPlanePositionManager which holds operations. These operation are RestorePlanePositionOperations and are executed on a geometry.
This leads to a complete reorientation of the slicedstack.

As I wrote in T9051 the question now is how to allow the navigation between rotated slices via the user interface.

Wrote ChangeRequest

[f9b3f8]: Merge branch 'bug-6788-Integrate-PlanePositionManager'

Merged commits:

2011-11-09 14:52:33 Andreas Fetzer [52f238]
Removed singleton pattern of mitkPlanePositionManager

Replaced/emulated singleton with micro services, adapted tests and segmentation
bundle

2011-11-04 16:06:30 Andreas Fetzer [bba3ac]
Finished writing test

Enhanced SliceNavigationControllerTest
Refactored PlanePositionManager
Enhanced Geometry3D so that it can deal with the new OperationType
Fixed an issue in SlicedGeometry3D
Refactored PlanePositionManagerTest

2011-11-03 17:15:59 Andreas Fetzer [7c4f57]
Changed PlanePositionManager and finished test

Now no datastorage can be set. This must be handled seperately.
Fixed remove position function.

2011-10-28 15:25:33 Andreas Fetzer [dc20df]
Continued writing the test

2011-10-27 16:40:45 Andreas Fetzer [d1cbc9]
Started writing a test for PlanePositionManager

Testing whether informations are stored/added/removed correctly
Started writing test for restoring a certain planeposition.

2011-10-26 18:45:20 Andreas Fetzer [5d8757]
Created testfile for PlanePositionManager

2011-10-26 14:22:03 Andreas Fetzer [5a8572]
Added the mitkPlanePositionManager and the RestorePlanePositionOperation, which hold
all the neccessary informations for restoring a specific geometry

Additional I adapted the SNC and the Sliced- and PlaneGeometry so that they
can handle the new functionality.

At least I incorporated the PPM for the segmentation bundle.

[444666]: Merge branch 'bug-6788-Integrate-PlanePositionManager'

Conflicts:
Mo

Merged commits:

2011-11-15 15:30:02 Andreas Fetzer [21071a]
COMP

Made a workaround so that GetModuleContext() is possible for CTK Plugins.
This should be replaced as soon as CTK Plugin Context is available