@floca Please delete the feature branch mentioned above if this task is resolved.

In T27437#223356, @al-sabr wrote:

Can this also be matched with this other task I created?

https://phabricator.mitk.org/T28454

I only need help in one place if that part is cleared then I already refactored the Core to reflect the changes suitable for version 3.6.0 of CppMicroServices.

In T27437#223241, @al-sabr wrote:

Is this task finished or if not when is it planned?

Pushed new branch to rMITK MITK: feature/T27437-ITK-v5.1.

https://phabricator.mitk.org/source/matchpoint/history/T28446-MigrateToITKv5.1/

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.

We now have some manuals but we still need an example-based guide for reviews/Arcanist.

Deleted branch from rMITK MITK: release/T28420-2021-Week-12.

Pushed new branch to rMITK MITK: release/T28420-2021-Week-12.

Deleted branch from rMITK MITK: bugfix/T28413-PatchOpenJPEGInITKForMSVC16.9.

Pushed new branch to rMITK MITK: bugfix/T28413-PatchOpenJPEGInITKForMSVC16.9.

Yes, as soon as there is a new tag that includes your necessary changes, just change the tag and click on build.

Started with Ubuntu 18.04 and 20.04 clients by adding the following script before the actual build. This is roughly what we are doing already in the Dashboard script.

I had a first quick check and for example T1.nrrd and S.nrrd (and S.nrrd converted to LabelSetImage) have the same geometries. My first assumption would have been that they are different. @floca Any idea?

Currently not actively working on this. Packaging seems to work for the moment except for Python (never did). I think this task will soon be revived with the work on Python in MITK by Kim-Celine and Ashis.