I changed the bug title, since the segmented region is not shown in the 3D view at all, independent of which segmentation tool used.

A new mapper for multilabel images is required to fix this issue.

Specifically it is not visible on the 2D planes in the 3D render window, this error is unrelated to volume rendering.

User engelhsa has pushed new remote branch:

bug-19522-CreateNewMultilabelMapper3D

The issue is almost fixed now (see branch bug-19522-CreateNewMultilabelMapper3D).

The multilabel rendering had to be included into the "normal" image mapper 3D (PlaneGeometryDataVtkMapper3D) to enable rendering of all kinds of image data at the same time.

Therefore, the PlaneGeometryDataVtkMapper3D had to be extended (instead of writing an own mapper for Multilabelimages).

Rendering of various multilabel images with and without other grey level images have been tested.

However, testing "Multilayer"-Multilabel images is still an open issue, since such kind of data was not available to me.

I will now integrate the latest developments made by Caspar concerning Multilabel to test this use case.
personal/goch/ml-integration

Summary of problem description

Actual behavior

Segmentations are not dislayed on the 2D plane geometry in the 3D renderwindow.

Expected behavior

Segmentations should be displayed as red regions on the 2D plane geometry as before.

Cause of the bug

The binary representation previously used for storing segmentation results was replaced by a multilabel representation.
There is currently only a 2D multilabel mapper (mitkLabelSetImageVtkMapper2D) for displaying the results in the 2D render windows, which can be found in the Mulitlabel Module.
However, there is no specific 3D mapper for multilabel images and the general PlaneGeometryDataVtkMapper3D (in core) lacks support for multilabel data.

Proposed solution

3D rendering of a specific image type such as multilabel images can not be achieved by an own 3D mapper for this image type, since PlaneGeometryDataVtkMapper3D is the class which is completely responsible for rendering the (red, blue, green) tubes, the planes and for texturizing of the planes.
Therefore, the PlaneGeometryDataVtkMapper3D core class had to be extended in order to display multilabel images *and* other images at the same time.
Since the multilabel-image represenation is not part of the core, we had to work with getter methods to make the required actors available to the 3D mapper.

In the future, it would be nice to have a more modular approach, which allows for an easy integration of specific non-core-related image types into the visualization. However, this was out of scope for this bug.

Affected classes

Modules/Core ...

mitkImageVtkMapper2D
mitkPlaneGeometryDataVtkMapper3D
mitkVtkMapper

Modules/Multilabel ...

mitkLabelSetImageVtkMapper

How will the bugfix get tested?

Rendering tests using different (multilayer-) multilabel images

User engelhsa has pushed new remote branch:

bug-19522-IntegrationAndTestMultilayer

User engelhsa has pushed new remote branch:

bug-19522-MultilabelbranchMerge

Pushed new branch bug-19522-IntegrationLatestMasterWithMultiLabelPlugin.

As asked on the ML, is there any update on this?

If I remember it correctly, the bug was almost resolved.
However, in the last session I was working on it I observed that there was still a problem for rendering labels on layers >1, but I had no chance to dig deeper here. It probably has something to do with the new data structure that was used in the mapper.

I'm not sure what has changed but it doesn't work anymore. I think those lines are wrong now and make the application crashes when we later use dataSetMapper, texture or imageActor.

imageActor = vtkActor::New();
imageActor->SetMapper(dataSetMapper);
imageActor->SetTexture(texture);

// Make imageActor the sole owner of the mapper and texture
dataSetMapper->UnRegister(NULL);
texture->UnRegister(NULL);

Maybe vtk7 replaced some smart pointer with raw pointer?

In T19522#68902, @goch wrote:

Specifically it is not visible on the 2D planes in the 3D render window, this error is unrelated to volume rendering.

I looked at this problem again and I was thinking: What are we talking about here? The branch has been deleted so I'm not able to look at the proposed changes.

When I open an image and create a simple segmentation (e.g. use Add-Tool to add a mask on a single slice) this mask is not visible on any 2D plane in the 3D render window. No need to interpolate to see the mentioned bug.
However, I was wondering if this was ever possible? From the description in T19522#68906 it seems to be the case, but this seems to be long ago. I suggest to discuss this first and set the priority of this task.

Edit:
I already linked a task (T27712) and now that I look again at it it might be clearer what is the intended behavior. I can see the segmented slices (mask slices) inside the 3D-Render-Window (without the need for interpolation) when using MITK 2018 Release Installer.

Beware of a few things. T28211: [Image Rendering] Color change/ Opacity strange behaviour (only in Windows installers) also fixed rendering of image slices in 3-d, so I suggest to use the latest release branch to test anything related instead of the snapshot installers.

Interpolations aside (which are shown as surfaces in the 3-d window), the other bug described here is still true, but there shouldn't be any difference between v2018.04 and the latest release branch that included the fixes of T28211. The bug is actually a missing feature. LabelSetImages were never implemented in the plane geometry 3-d mapper. Good news is, that this mapper just reuses the textures from the 2-d image mappers. So it should boil down to only a few extra lines in the plane geometry 3-d mapper to make them visible.

Do you mind, if I have a quick look, too?

I don't mind, I'm not planing to fix this before the release, so if you have time. I'm testing this with the develop branch and comparing it with the MITK 2018 installer.