Page MenuHomePhabricator | MITK

Revisit 2-d image rendering
Open, NormalPublic

Description

Introduction

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:

Mismatch of images that are supposed to be congruent with each other:

Possibly related geometry issues:

No task yet:

The world plane geometry (used in 2D mappers) may be erroneous. Especially when having data with spacing values other than 1. For debugging, use branch T23742-ProofOfConceptForNewSegmentationDataType, commit rMITK72feb1c2937a to get an idea of what is going on. Activate the segmentation2 view and click on its Test button to add a segment node. The segment mapper just draws the world plane geometry in this commit. You can easily change the dimensions and spacing of the segment in QmitkSegmentation2View.cpp. E.g., change all spacing values to 2. You should also deactivate "Constrain zoomin and panning" in the preferences to be able to zoom out far enough to really understand the big picture. It might be the crosshair that is wrong, both origin and extent when using a uniform spacing of 2.

Tasks blocked by aftereffects:

NOTE: I will update the lists above when searching more thorougly for related tasks.

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

Related Objects