@kleesiek Sorry. Just saw that it dropped of the radar. In the meantime the new release installer is out. Could you test it with the current workbench release? Thanks.

@kalali That is a good idea and proposal for how to proceed.

Reply from Gvisor Team

Will be fixed with D480.

Hm, while D480 resolves the issue, I think that the original approach for handling the Multilabel colormap in T23589 is already a workaround. Changing the level window to the maximum possible range is just an emulation of "do not use the level window". We actually have that mode in MITK already. The Image Rendering.Mode property is usually set to LOOKUPTABLE_LEVELWINDOW_COLOR but there is also LOOKUPTABLE_COLOR which is exactly what we need here. The thing is, that LOOKUPTABLE_COLOR is not implemented correctly in the 2-d image mapper, as the level window filter is not reset and instead is using the previously set range. So I will extent D480 to actually use the correct mode and fix the 2-d image mapper.

If the image is converted to a segmentation (context menu -> Convert to segmentation), it is rendered correctly even though the very same lookup table is used. So I guess the issue is to be found within the 2d image mapper.

The lookup table is set correctly but the rendered colors do not match.

This really shouldn't happen. A first look at the code revealed that the intention is to have at least 25 different colors for values 1-26 and after that repeatedly cycle through 12 colors.

Found the issue. After setting the colormap to "Multilabel" in QmitkDataNodeColorMapAction::OnActionTriggered, the previous LUT is checked if it is a "Multilabel" LUT, instead of the new LUT. Hence the observation above that it works when applying it twice.

This issue was already resolved by @kalali in T23589: Multilabel Segmentations not loaded with multilabel colormap, resp. {D172} for MITK v2018.04.2 but I can confirm that the issue exists for the example image.