Successfully tested the Microk8s integration of Kata in a container env (Google Cloud Instance)

Except for the GPU installation/configuration with Kata all others as 1-2 days of work. GPU is definitely possible with Kata, but there are multiple installation and drivers and kernel configurations are recommended by them, and I am not much familiar with GPU installation and configurations before in a server system, rest everything I will change to a sub task now.

It seems to me that most of this points are at least 1-2 work days worth of time. If this right it would make sense to turn them into subtasks. Then we also have a clearer burn up, because one can explicitly marke sub tasks as done...

That's good to hear so I'm not missing something. However, I never paid attention to this and I'm still wondering why that's the case.
So in my tests I need to find a way to predict the correct outcome in order to make the test succeed.

Pushed new branch to rMITK MITK: bugfix/T27711-rename-image-selection-label.

Just as a side note. As far as I know, the data storage interace gives no guarantees regarding the order (aplied sorting criteria) of returned node sets. So any implementation that relies on such an order is likely to fail.

I used the following code snippet to test the retrieval of the data nodes

void setUp() override
{
  for (int i = 0; i < 3; ++i)
  {
    m_LevelWindowManager = mitk::LevelWindowManager::New();
    m_DataManager = mitk::StandaloneDataStorage::New();

@kislinsk:
So I took a closer look into this and I found out the following:
Inside mitkLevelWindowTest:

• m_DataNode1: 0x00000221c86a80f0
• m_DataNode2: 0x00000221c86a6930
• m_DataNode3: 0x00000221c86a7bf0

We also found out that the current LevelWindowManagerTest fails: https://cdash.mitk.org/testDetails.php?test=774190&build=12215
The problem is the modified LevelWindowManager in combination with the mentioned random tests: The random tests can lead to all nodes having an invalid rendering mode. The LevelWindowManager has been modified in T28250 which conflicts with the current level window manager test.

I tried to add

long long

to the list. That caused my superbuild to crash. Then I added

int64_t

The superbuild worked, but now the workbench crashes during the load attempt with:

There was a discrepancy regarding how the RtStruts are displayed. When loading via DICOMBrowser, they were now visible on stdmulti.widget2 and 3. Is this the desired behavior? On there planes, one can only see "dots". We should discuss this.

Hi,
Currently, we have only 3 responses (including Fabian's).
Here is the data:

In T28523#225188, @kleina wrote:

What is the status here? This is on "unbreak now", but no assignee. Is there something to evaluate yet?

Good point. @a178n I put you as asignee for now as you started the survey. How many answers do we have already. If it is a low number, then could you send a reminder. So that we can compile the result for internal read through next Wednesday?

Same goes for MultiLabel Segmentation.

While we are doing that: The measurement Plugin does not have a label at all. I would suggest having this consistent.

What is the status here? This is on "unbreak now", but no assignee. Is there something to evaluate yet?

As discussed with @s434n, I will discard my diff D466 for now, because it caused some unwanted interactions with the LayoutAnnotationRenderer. The quick fix of D506 solves the problem that in Geldosimetry and OverlayManager the colorbarAnnotation is not displayed on the right at the center (placed too heigh and is cutoff in the render window).

Pushed new branch to rMITK MITK: bugfix/T28544-difference-RT-data-loading.

This is a bigger topic, connected to the refactoring of the segmentation and should be handled in multiple sub-tasks, to split the topic into smaller issues.

I will start looking into this to give some examples of important warnings / errors that the user should know about.

We should look into this and focus on the mentioned related task by @kislinsk to start with separating the two processes:

1. matching the geometry of the images for interaction
2. resetting the view of render windows to see the new segmentation

In T28135#225112, @kalali wrote:

@floca Is this something worth looking into before the refactoring is done?

I would say: no.

@floca Is this something worth looking into before the refactoring is done? If we stick with LabelSetImages and the basic backend of the utilities, I don't see a reason for this to be postponed.

Maybe an option inside the node selection dialog would work here?

Is this an issue we need to address? Did anyone else experience this behavior?

I understand the reasoning behind that feature request, but I think it should be discussed. At least it contradicts one of the key assumptions of the new selection concept: relevance criteria is defined localy in the view.

I was able to reproduce the bug for all morphological operations (Dilation, Erosion, ...) and also in all orientations (axial, coronal, sagittal). Other segmentation utilities all work without problem.

Wasn't able to reproduce it anymore, too.

I could not reproduce this.

I reported the cmakebuilder-plugin issue to Jenkins: https://issues.jenkins.io/browse/JENKINS-65893

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

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

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