Page MenuHomePhabricator

Segmentation outlines do not match voxels when using rotated planes
Closed, WontfixPublic

Assigned To
Authored By
Feb 25 2015, 3:01 PM
Referenced Files
F41120: gif.gif
Dec 20 2016, 6:00 PM
F41111: output.mp4
Dec 20 2016, 4:33 PM
Unknown Object (File)
Dec 20 2016, 4:29 PM
F41085: stdmulti.widget3.gif
Dec 20 2016, 4:18 PM
F41031: Capture.PNG
Dec 20 2016, 11:02 AM
F41027: Capture.JPG
Dec 20 2016, 10:35 AM
F40710: Capture.JPG
Dec 19 2016, 2:33 PM


to reproduce.

create a segmentation, then rotate slices and start segmenting sth.

the segmentation outlines will not match the voxel outlines of the image data.
this happens only in outline binary mode ->
the error is within the outline binary function
(non-outline display is correct)

NB: Christoph knows more ...

Event Timeline

This bug could not be fixed during the 2015.05 release.
Setting target_milestone to AfterNextRelease

still not fixed for 2016-03 release. Should be fixed though. Increasing importance for now.

Just found the same bug....

Supplemental to this:
Since the integration of multilabel segmentations, the property "outline binary" has no effect on this. The rendering of the contour remains incorrect even if outline binary is disabled.

kislinsk added a subscriber: kislinsk.

It appears that the drift of the outline is larger at distant pixels (compare drift at top and bottom).

Capture.JPG (953×572 px, 38 KB)

I think the problem is the vtkTransform in mitk::LabelSetImageVtkMapper2D::TransformActor() or something similar as the coordinates of the outline points seem to be correct, which is easy to verify, as they are in continuous index space and always without decimals. It looks like the transformation either has numerical issues or is applied in the wrong way, i.e., before a scale operation you have to make sure to translate to the origin first for uniform scaling. The image above could be explained by such a non-uniform scaling.

I consider to get rid of the whole mapper as it is and replace it by a simple edge shader.

Here one can see clearly that the drift increases from top to bottom and that it is really the outline, not the image.

Oops, it maybe is the image. In the example image below, some image pixels are 14 display pixels high, and others are 15 display pixels high. The outline pixel borders are always 14 display pixels high. Sometimes they appear to start one display pixel off because of sampling artifacts but at a second look it is always 14 pixels.

Capture.PNG (493×479 px, 10 KB)

Capture.JPG (1×1 px, 127 KB)

When creating a surface out of the segmentation, it perfectly aligns with the outline. It really is the image texture, that is generated or mapped wrongly. To check for the latter case, I will try to write out the texture of the rendered image and compare it to the actual rendering.

This GIF compares the actual texture that is generated in the 2D image mapper against the rendered texture in the render window. It demonstrates the drift towards the bottom. As the images don't have the same aspect ratio (!), I scaled one of them to the width of the other one. In the render window snapshot, the last row of pixels is actually present but didn't fit into the GIF, so no image information is cut off in MITK. The drifting effect starts immediately when the slice is rotated more than ~7° and disappears immediately when within the same interval at around 180°. The drift is the same for all angles in between.

stdmulti.widget3.gif (1×910 px, 309 KB)

I wrote out every resliced image (texture) while rotating the slice above the "magical" 7°. At this point, it is the first time that the slice/plane is long enough so that the texture needs to be one pixel higher than before. In general, this is as expected, as the texture needs to grow while the plane gets longer (with its maximum length when reaching from corner to corner at approx. 45°). However, the interpolation in these bigger textures is one pixel off, which is the actual error of the VTK reslicer. See the GIF below. An extra row of pixels is appearing at the top even though the image is basically the same:

gif.gif (920×910 px, 205 KB)

kislinsk lowered the priority of this task from High to Normal.Jan 9 2017, 1:28 PM
kislinsk moved this task from Focus Tasks to Backlog on the MITK (2016-11) board.

We are not able to fix this for the upcoming release. This might be a fundamental issue and require major changes in the very basics.

Hi there! 🙂

This task was auto-closed according to our Task Lifecycle Management.
Please follow this link for more information and don't forget that you are encouraged to reasonable re-open tasks to revive them. 🚑

Best wishes,
The MITK devs