Page MenuHomePhabricator

ComputeBoundingGeometry3D grid wrong (world geometry calculation)
Closed, WontfixPublic


Hi Everyone,

I have a problem whereby I am seeing a half voxel shift in my millimetre to voxel calculations, and I believe the following example using this mornings build of ExtApp illustrates it.

I have a 3x3 test image with voxel size 2mm x 2mm, and a 5x5 test image with voxel sizes 1mm x 1mm.
The origin for both images should be the centre of the first voxel.

If I load JUST the 3x3 image, the geometry as expected. The first voxel has index 0,0 and millimetre location 0,0.
If I load JUST the 5x5 image, again, it is as expected.

If I load BOTH the 3x3 and the 5x5 I would expect the smaller 5x5 image to be centred symmetrically within the 3x3 image, and this is not the case. It looks like the corners are aligned rather than the centre of the first voxel.

Please find attached my 3x3 image and 5x5 image, and some screenshots.
In the screenshots

first screenshot = 3x3 image = OK
second screenshot = 5x5 image = OK
third screenshot = overlay = PROBLEM????
fourth screenshot = my expectation.

Did I do something wrong, or it my expected behaviour wrong?

Many thanks


Related Objects

Event Timeline

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
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
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.

kislinsk claimed this task.
kislinsk added a project: Auto-closed.
kislinsk added a subscriber: kislinsk.

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

kislinsk removed kislinsk as the assignee of this task.May 26 2020, 12:05 PM
kislinsk removed a subscriber: kislinsk.