Note: the reason for the precision loss is probably related to the tiny xml serializer. When writing real-type values in XML text format and reading them in again, some of the prevision is lost. Maybe tiny xml can be configured to write real-type values with higher precision.

The precision loss is not related to the tiny xml serializer. It already happens in the test case which was attached. While inserting test case data into the float vector the numbers are only allowed to have 6 valid digits plus comma, e.g.:
1.123456 gets rounded to 1.12346
0.0123456 doesn´t get rounded, because it is in the boundaries
(leading 0 are encoded by the floating point mechanism)

Thanks for looking into this. I also had another look at the affected classes. All the MITK Geometry classes use "float" instead of "double" for defining ITK transforms, vectors etc. You're right that this is probably the reason for the precision loss.

The tiny xml serialization uses double, which would be precice enough for 14 or more decimal digits, but it only gets fed with floats because of MITK...

In cases where we need increased precision, it might be worth to use double instead of float for transforms etc.

In many situations in MITK, the floating point type is defined by "ScalarType" (defined in mitkVector.h). We could try what happens if we redefine this with "double".

Daniel, any thoughts here? :)

I wouldn't mind using double values for mitk::ScalarType but I remember some discussions with algorithm group members who had concerns. I could imagine that some code pieces could be blown up by changing to double.

Tobi, Klaus, could you prepare that subject for a MITK meeting?

I checked this bug again and talked to Mathias Seitel.

It seems that the test case does not fail because the double<->float precision issue. This tests creates different PlanarObjects in the standard plain geometry (100.0 / 100.0). Four points are used to place the PlanarObjects into this plain.

In the attached test case a PlanarCross with a float geometry is created. This geometry has the float coordinates (1.123456, 1.123456) and the spacing (0.0123456, 0.0123456).

Furthermore, I figured out that there is an other problem related to the float geometry.
If only a PlanarCross with a float geometry is used for the test, the test will fail.
If only a PlanarCross with a plane geometry is used, the test passes.
If any PlanarObject in addition to the PlanarCross with a float geometry is used in the test, the test also passes.

I debugged into the code and it fails at:
Method: DeserializePlanarFiguresFromMemoryBuffers
Line: reader->Update();

I will continue with this in the next bug squashing.

[05451b]: Merge branch 'bug-4155-PlanarFigureIOTest'

Merged commits:

2011-03-02 18:26:47 Thomas Kilgus [6c5da9]
I figured out that two things were wrong:

1. the points for the preciseGeometry should be converted to the coordinates system of the preciseGeometry.
2. The comparePlanarFigure method was testing if the class names are equal and would return false if not.

If the NAMES are equal, the other conditions were required to be equal for a successful test. But a PlanarCross with a preciseGeometry is obviously not equal to a PlanarCross with a planeGeometry.

In conclusion, the test was wrong and never anything in the IO at all ... I added various planarFigures to the test which also use the preciseGeometry to have a better test coverage.

Merging "applicazion modules" component with "ExtApp plugins"