Ivo agrees, that the current behavior is wrong and that Matt's proposal is correct. The Problem might be in the Mapper.

Mail by IVO:

stimme dir und ihm zu. Er hat völlig recht und hat nichts falsch gemacht. Zudem eine sehr schöne Bug-Beschreibung. Und ein guter Test, zumindest für einen manuellen Check. Mir ist im Moment leider schleierhaft, woher es kommen könnte.

2nd Mail:

inzwischen glaube ich, dass es ein Mapper-Problem ist: damit in 3D alles auf ein und dieselbe Textur-Fläche gerendert werden kann, wird (auch für die 2D Darstellung) ein "geeignet" großes Bild aus dem Volumen herausgeschnitten. Bei diesem Herausschneidevorgang wird interpoliert und wenn dann so wenige Pixel vorliegen, wie im Beispiel, fällt das auf.

we found out that the reason for this behavior lies in
Mitk::ImageVtkMapper2D::GenerateDataForRenderer(..)
 
Here the “reslicer”, which is resampling the images, is creating shifted results. The shift is only noticeable if the images are really really small (like in your case).
 
Reslicer is taking an input image with its geometry and another desired geometry. Then it “resamples” the image, so it fits to the new geometry. The new, desired geometry is the world geometry, the smallest geometry, which contains all existing geometries. It is created by taking the bounds of the largest image (the 3x3 image with spacing 2,2 = world bounds are going from 0 to 6). The spacing is the lowest existing spacing (the spacing of the 5x5 image is 1,1.. this is taken).
 
So the world geometry has the spacing 1,1 and 6 pixels in y and x direction. Reslicer is now trying to resample the image with 5 pixels into an image with 6 pixels. Here it encounters a problem… visible in the pixel shift.

Possible solutions:
The world geometry is calculated in the function
mitk::DataStorage::ComputeBoundingGeometry3D
Here we could adjust that a smaller pixel spacing is taken. But it is not clear how to determine, what would be a good pixel spacing. Actually, it could be really really small, depending on how many images you have.

Another solution: Reconstruct the image mapper, so the images are always mapped in their “own” geometry and the world geometry is only used to “focus” the 2D renderwindow. But this might increase calculation time, when working with several images. Also the 3D renderwindow mechanism won’t work anymore then. So far it takes a “texture” of the size of the world geometry, which is created in the 2D mapper using the current reslicer mechanism and puts it onto a plane.

We are not sure how to solve the problem in a satisfying way, yet. Also it only occurs when having really small images, so the priority of fixing is not that high..

I observed the same thing in T2907 and attached some bigger test images (still low resolution).

Also, the effect IS visible with full resolution images because the image contents is shift visually. I observed this when visually checking the results of T11106. Toggling between two images is not a typical use case, however we don't know the use cases of all MITK toolkit users. Image fusion could be one case where this error might be relevant.

Markus F. works on T10174, which could contribute to the solution. Markus, right?

What is the status of this bug? I don't think it is realistic to fix this for the upcoming release, is it?. Changed Target Milestone.

Markus is currently rewriting the ImageMapper. See T8165.

His changes might fix this bug. Please consult with Markus.

This bug could not be fixed for release 2013-06. Setting target milestone to next release

Bastian, what is the status of this bug? Did the changes fixed the bug?

The bug is not fixed yet and is still present in the current master.

Current release is finished. Reseting target milestone...

This bug is still present. A refactoring of the renderer seems necessary to finally solve it.