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.

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.

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.

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: