We also need to fix the Boost binary build on macOS.

Deleted branch from rMITK MITK: bugfix/T28546-macOSCatalina.

Pushed new branch to rMITK MITK: bugfix/T28546-macOSCatalina.

• For now I will disable SWIG (and PCRE) builds on macOS and require it to be provided (for example via Homebrew brew install swig).
• I already renamed everything in Jenkins, Phabricator, and Git hooks
• The macOS codename extraction can be easily fixed adding the backslash to the extraction regex

Without looking into it yet, I think the Nvidia solution for accelerated remote desktop is currently by far the most promising as it tackles the actual issue.

A few things that impact the handling of huge images:

The tool was already removed from the last release because people tend to use the Add/Subtract tool for the same tasks anyway and we could reduce code/complexity.

And we seem to have a huge leak here. Even after deleting all the nodes again, half of my RAM is still in use.

As it is an inexpensive operation my first guess would be an issue related to the amount of used memory. For example, the image above eats 3,5 GB, Activating the interpolation already triples it. Confirming adds at least another 3,5 GB. That could also explain why it is so slow (swapping). But at this point it is just a first assumption. On a 16 GB Windows machine I was able to complete the interpolation without crash but it took a while.

Maybe @thomass is still reading. :) I think she reported the same thing some weeks ago but I cannot find it. It's just a missing RequestRenderWindowUpdate().

Hm, I cannot answer this without looking into this in detail but a first step could be to improve the AssertImageForLevelWindowProperty function or maybe even encapsule the CPPUNIT_ASSERT_MESSAGE calls in that function instead the other way around since the error message one does receive currently doesn't tell much about what actually failed since it could be any or all of the three checks.

Deleted branch from rMITK MITK: release/T28473-2021-Week-17.

Pushed new branch to rMITK MITK: release/T28473-2021-Week-17.

@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.