Only 1 MB attachment allowed, so i put the Image to T:\Temp\Extracted2DMitralValve.nrrd

CastToItk apparently does not alter m_Direction, so no rotation considered here

We began to change some stuff in the Geometry3D class.
Need to discuss a couple of things in the MITK meeting

Ingmar + Basti: Probably related to: 8477

Work in Progress: Currently we are changing the geometry class in a branch on
my computer.

General Aim:

• try to make it more comprehensible
• get rid of unused functions
• get rid of redundant parameters
• have a "safer" interface (e.g. no public function for changing the

WorldToIndex Transformmatrix directly)

• provide an matrix for orientation/rotation
• try to be as close as ITK as possible

After some discussion with Jan und Caspar, we found out, that it IS possible, to determine the Scaling and Rotation Matrix out of a composed TransformMatrix.
So, when the user sets the IndexToWorld Transformation Matrix directly, we can read out Spacing and Rotation Matrix out of that.
That means, for the new Geometry we could offer a SetTransformationMatrix Method, which sets up a nice and clean geometry!
(Need to check if that still applies if a Translation was applied to the given Transformationmatrix)

(Need to check if that still applies if a Translation was applied to the given
Transformationmatrix)

This does not affect here. For a 3D translation you would need an 4x4 Matrix. So we and (itk) usually put that translation in an separate 3D vector (itk::AffineGeometryFrame).

SO:

• a "SetTransformationMatrix(matrix3x3)" that automatically sets spacing and rotation is possible

(In reply to comment #7)

After some discussion with Jan und Caspar, we found out, that it IS possible,
to determine the Scaling and Rotation Matrix out of a composed TransformMatrix.

FYI: For the current Geometry3D there is a function GetRotation(const mitk::Geometry3D * geometry, TMatrixType& itkmatrix) in /Core/Code/DataManagement/mitkMatrixConvert.h.

So, when the user sets the IndexToWorld Transformation Matrix directly, we can
read out Spacing and Rotation Matrix out of that.
That means, for the new Geometry we could offer a SetTransformationMatrix
Method, which sets up a nice and clean geometry!

Except for numerical errors, of course ...

(Need to check if that still applies if a Translation was applied to the given
Transformationmatrix)

I am planning to implement the following behaviour:

2D images are generally "still" supported, like it is now.
You can load them, perform segmentations or anything and save them.

Whenever the a 2D MITK image is converted to an 2D ITK image, it is checked, if geometry information will be lost. In that case a warning is given to the console.

When you save a 2D Image, it is checked, if geometry information will be lost.

• if not: Just save it normally
• If yes: PopUp a warning, offering the use to save it as a 3D image with 1 slice in z-direction, but a 3D geometry OR save it with a standard geometry.