We have a major issue with our current way of 2-d image rendering. In fact, it seems to be a combination of a few issues, which makes it hard to identify the actual reason. This is why I believe that the same issue was reported may times in the past years through different observations. I really didn't search thoroughly for now and already identified some tasks, which I try to group by the derived issues that are caused by the actual problem.
Mismatch of surfaces with image features they suppose to be congruent with:
- T7079: mitkExtractImageFilter shifts the coronal plane for one slice
- T10996: Outlines for binary images are shifted
- T16412: Contour of a segmentation doesn't appear at the expected position on tilted images
- T18776: Segmentation outlines do not match voxels when using rotated planes
- T19652: Segmentation: Add-Tool contouring on specific data sets fails on rotated planes.
Mismatch of images that are supposed to be congruent with each other:
- T10785: Spacing of a worldGeometry of several images is not the greatest common divisor of all spacings
- T11948: ComputeBoundingGeometry3D grid wrong (world geometry calculation)
- T16159: Depends on #11948: Crosshair position is wrong in axial view after reinit on other image
- T16747: New sampling concept for image mapper
Possibly related geometry issues:
Tasks blocked by aftereffects:
The actual issue(s)
I believe that the surfaces/contours in the first group of tasks are actually correct, but the image rendering in rotated planes is off because of VTK image reslice quirks. This is demonstrated very well in T18776.
The second group of tasks reveal a fundamental design flaw in our 2-d image mappers, which sample all images into a single texture instead of keep them seperate in different textures. This was addressed in T16747 but then cancelled because of the amount of work necessary to replace the current, massive, and monolithic 2-d image mapper.
Both tasks groups have in common, that the actual data is correct, but the rendering is off.
The third group of tasks may be truly different issues but it is related to the overall issue, as we really need to have reliable geometries to address and validate the actual rendering issues.
Last but not least there is at least T5050, which unquestionably is a simple bug. However, it is entangled in the 2-d image rendering and some other code locations of MITK, which implement workarounds for the actual bug. I believe that the bug was consciously introduced or at least accepted back in the days when the 2-d images rendering was written and there wasn't another way to get the VTK-based image reslicing working as expected. Indeed it seems to be impossible to do so, which is why I wrote an ITK-based alternative in T23971.
How to address the issue(s)
- Verify/resolve geometry-related issues
- Write a visual debugger utility for inspecting geometries
- Design and implement a new 2-d image mapper that doesn't need to resample images
- Decouple the extraction of 2-d slices and use mitk::ExtractSliceFilter2 as reference implementation
- Write a (faster?) VTK-based slice extraction and use the reference implementation for validation
- Redesign the cross-hair which no longer simply consists of three textures