Have you been able to reproduce this bug?

Bug is still there. We were not able to fix it yet.
Maybe postpone it.

Still could not fix it, postponed to 3M4 release.
Would be happy if someone else could have a look at it.

Summary:
We figured out, that in fact the interpolation PREVIEW is displaced! When you press accept, that preview is moving a little and becomes the CORRECT interpolation. We need to figure out, why that preview is displaced.

We began with the method "QmitkSlicesInterpolator::OnAcceptInterpolationClicked()", which is called when the accept button is clicked. It creates an OverwriteSliceImageFilter Object, which selects the specific slice out of the 3D segmentation volume and overwrites that slice with the 2D image "m_FeebackNode". So it can be assumed that m_FeedbackNode contains the interpolation at that moment. m_FeebackNode is filled when the function "Interpolate" is called.

The weird thing is, that the displayed preview interpolation is also just displaying m_FeedbackNode. And between displaying that preview and the pressing the accept button, there is no call of the "interpolate" function, which would alter the content of m_FeedbackNode.

We'll take a shot at it.

We assume the problem to be due to the mapping in the mitkContourMapper2D, as selecting the top left pixel of a couple of slices works. The offset contours are not shown, as they are mapped outside of the image, but MITK does not crash and accepts the segmentation afterwards. This behaviour suggests the interpolated pixels not being out of bounds.

We found the problem.

It is a very essential problem with handling Geometries. When changing from a "normal" Geometry to an "image" Geometry (and the other way around), changes in the origin coordinates must be made, since "normal" geometries have their origin in the bottom left corner, while "image" geometries have their origin in the center of the bottom left pixel (+0.5,+0.5,+0.5).

To fix it, we have to modify some fundamental functions like mitk::image::setGeometry. We are working on this.

Patch for Geometries and Segmentation Tools

The attached Patch corrects geometries behaviour and fixes the behaviour of the segmentation tools.

With this Patch the selected pixels will be the segmented pixels. Also the interpolation between slices will be correct. It should kill most of the 0.5-Offset bugs.

We had to make some more changes .. a new (better) patch is coming soon

Killed the bug locally by changing mitk::image::setGeometry and creating the function
mitk::Geometry3D::ChangeImageGeometryConsideringOriginOffset(bool isAnImageGeometry)

Please have a look at the NEW patch for all the changes. However, it is not clear, how many bugs will created by this! Have to talk to Ivo before proceeding...

A newer patch with all the changes to fix this bug

Newest Patch for Geometries and Segmentation Tools

Ivo and me agreed on a final solution. You can see it in the newest patch, attached to this bug. We would like to commit it like this.

The behaviour of mitk::image::setGeometry will not change! It will just give a warning, if the geometry parameter has no "isImageGeometry" flag on true and give recommodations how to adjust the geometry to center-based.

The class mitk::Geometry3D and its inherited classes now provide a function "ChangeImageGeometryConsideringOriginOffset(..)", which can be used to switch from and to center-based.

The ExtractImageFilter is actually the source of this bug, where the interpolation moves down, because it was not correctly adjusted to center-based geometry behaviour. It is now calling "ChangeImageGeometryConsideringOriginOffset(..)" to correct this.

Marco told me about this bug and I just took a look at it. Thanks for correcting such hard to understand issues!

(In reply to comment #13)

The class mitk::Geometry3D and its inherited classes now provide a function
"ChangeImageGeometryConsideringOriginOffset(..)", which can be used to switch
from and to center-based.

First I wanted to write about the name of the method. It took be quite some minutes to understand what you are doing here. I think the amount of work you and others spent on fixing this issue justifies an easy-to-read summary of the issue with usage examples in Doxygen. You could either put this in to the Geometry3D documentation or into a separate document about geometries in general (then link from Geometry3D).

The ExtractImageFilter is actually the source of this bug, where the
interpolation moves down, because it was not correctly adjusted to center-based
geometry behaviour. It is now calling
"ChangeImageGeometryConsideringOriginOffset(..)" to correct this.

Markus E., do you know about this change? Could this be related to a screenshot issue you have been working on? (just a hint, no answer required here)

[SVN revision 28568]
FIX (#5557): Adjust Geometries to center-based behaviour if they are image-geometries

Basically all the changes were:

• give a warning, when trying to add a non-image-geometry onto an image using setGeometry
• for each kind of geomety a function called "ChangeImageGeometryConsideringOriginOffset" has been implemented to add/remove the offset for center-based behavior
• Comments for several functions improved

Please have a look at the Doxygen page for Geometries for an detailled description.

Now we are still working on tests for the geometry functions.

[SVN revision 28633]
FIX (#5557): Small Bugfix: The function "GetCornerPoint" was adding 0.5 offset manually, if it was an imagegeometry. This has been removed.

[SVN revision 28634]
FIX (#5557): Adjusted Geometry Tests

[SVN revision 28636]
COMP (#5557): The function "FitGeometry" was adding 0.5 offset, if it is an imagegeometry! No manual 0.5 offset correction allowed anymore!!! See geometry doc!

Are you sure this is correct? AFAIR, it IS necessary to substract the 0.5 offset there, because a corner is really in the corner and not in the middle of a pixel. And be careful: is is probably not a small change/fix.

(In reply to comment #17)

[SVN revision 28633]
FIX (#5557): Small Bugfix: The function "GetCornerPoint" was adding 0.5 offset
manually, if it was an imagegeometry. This has been removed.

I am not completely convinced that the general rule is true for this case. mitk::BoundingObject uses geometries with the origin in the center.
mitk::BoundingObject::FitGeometry tries to fit the geometry around a given one in a way that the corner points match. Because mitk::BoundingObject uses a non-image geometry, but the passed geometry may be an image-geometry, mitk::BoundingObject::FitGeometry might need to react accordingly.

(In reply to comment #19)

[SVN revision 28636]
COMP (#5557): The function "FitGeometry" was adding 0.5 offset, if it is an
imagegeometry! No manual 0.5 offset correction allowed anymore!!! See geometry
doc!

[SVN revision 28691]
FIX (#5557): Undid bad changes in mitk::Geometry3D::GetCornerPoint and mitk::BoundingObject::FixGeometry

[SVN revision 28692]
COMP (#5557): Updated SlicedGeometry3D Test. mitk::Geometry3D::GetCornerPoint should apparently return the same value, wether it is an imageGeometry or not.

[SVN revision 28812]
COMP (#5557): Updated TimeSlicedGeometry Test.

Now, all Tests and all changes have been done!

ToDo: Tell the MITK Users about the changes and ask them to report strange behaviour, those geometry changes could have caused.

[SVN revision 28816]
FIX (#5557): Corrected signed/unsigned comparison

All geometry changes have been committed and tested successfully.