That is what I assumed... the labels created by multi-label plugin always contain only two values, if I am not mistaken: 0 and x with x e [1,2,3,...]. One could check for the label values and if there is only two different ones, use these two. This does not include the case when a label was created externally,e.g., by U-Net and contains several values in a single image.

Down prioritized it, because survey indicated currently low relevance.

Thanks Hanno. I think @schererj is the original author, so maybe he can comment or we discuss it in the meeting.

I checked some of the most important plugin views and their storage inspectors / selection widgets and couldn't find something that needs to be tackled right now. I will close this task for now but we should keep an eye on the "helper nodes" appearing in some selection dialogs of specific plugin views.
And I agree that the the local plugin view should care for the right predicate.

So I tried it out. The problem are not the containeres (opensearch and opensearch-dashboard), but our plugin (workflow-trigger).
The plugin workflow-trigger has some package dependencies based on elastic/kibana. These dependencies have to be changed to the once of opensearch-dashboard.
So I tried to change it, but I get some yarn build issues.
So I am having different issues, probably it would be easier to restart the plugin form fresh. But for this, I would like to know, how the current plugin was created, to get an understanding, on how to create a similar one.
So the current issue is, that the package is searching for specific files, probably an opensearch-dashboard has to have a specific dir-order:

In T28490#226519, @kalali wrote:

Also, this solution still does not preserve the zoom but that's the next step.

We discussed this and two important points were made:

• The difference between RenderWindowManager::InitializeViews(RenderingManager::GetInstance(), image->GetTimeGeometry()); and RenderWindowManager::InitializeViewsByBoundingObjects(RenderingManager::GetInstance(), dataStorage); is reasonable and important - even for a single data node (e.g. brain.nrrd, where the image itself is somehow rotated / tilted).
• We definitely want to reset the geometry automatically such that the current view geometry of the renderer matches with the segmentation geometry. That way the user can immediately start drawing. We don't want the user to have to care for the correct geometry aligning manually.

In T28490#226107, @kalali wrote:

We need to look deeper into the segmentation plugin to find out if it is possible to create and draw a segmentation without a correctly initialized reference image.

So I dug a little bit deeper using brain.nrrd as test data:

In T28490#226107, @kalali wrote:

So my conclusion from this: [...] It seems as there is a difference between the initialization that is performed when loading the image and the initialization that is performed when calling InitializeViews or using the reinit-action from the context menu.

I see no difference between calling InitializeViews with the new Enum value NO_UPDATE and not calling InitializeViews at all, solely using mitk::RenderingManager::GetInstance()->RequestUpdateAll() to correctly set the rendering geometry without changing the view after a new segmentation nodes has been created.
However, both variants do not allow segmenting on the new segmentation node as the warning message shows, stating that a reinit should be performed on the segmentation image. The warning message appears in the scenario where I changed the camera view before creating a new segmentation:

I looked into this (to be honest, I did not read Amirs last comment): I totally agree. I fixed the issue, which was not to complicated, but there is a lot of spaghetti code involved. I agree with Amirs suggestion to not fix it this way.

I tested it again with feedback from @kalali and @s434n. The behavior that the tool has is ok for now. I adapted the checklist accordingly. We found some minor issues, that we propose to fix on the near future:

To add to this: Point 2 sounds reasonable and that's what happens when the MITK mode is activated: The Segmentation Tool deactivates the left mouse click of the MITK mode.
However, this is not implemented for the PACS mode and would require additional complex logic.

André, Amir and I discussed the problem a bit and found multiple problems and ideas. The general question is: what is the intended behavior? Some options are:

1. only one interaction can be active at any time. This would mean activating a segmentation tool would deactivate any PACS functionality and vice versa. Not really what we want, since it prohibits using regular MITK interaction behavior (e.g. zooming with the right mouse button) while segmenting
2. only one left-mouse-button interaction is active at any time. Activating a segmentation tool would automatically disable left-mouse-button usage for display purposes
3. multiple interactors can operate on the same events, i.e. PACS + segmentation at the same time is intended behavior, if the user wishes to do so. To make this useful, it should be possible to deactivate PACS interaction, either by allowing to click a button again to deselect it or by providing an additional button that does nothing on left clicks.

The problem really seems to be the disabling / resetting of interactors that was mentioned in an earlier comment, even with the fix that corrects the resetting when the tool is deactivated again. Correct usage would be:

1. moving around the gui, using PACS
2. selecting a segmentation tool (which deactivates other interactors)
3. only using the segmentation tool, without changing the view
4. deactivating the segmentation tool (and thus reenabling previous interactors)
5. -> everything works as intended

When a PACS tool is selected after step 2, this messes up the active interaction and after the segmentation tool is deactivated it resets to what was previously selected, before the tool was activated.

So this task as an _evaluation_ task has a high priority in my opinion. If it turns out to be a bigger thing to replace please stop and we should discuss again

If this is not a big deal, i.e. if it really works after switching to the replacement there would be a big benefit. So it would be great if someone could at least try it and report some results, like how much work it would be. After that we could decide how to prioritize, but from my understanding it would make our Kaapana license task much easier

When I install Kaapana using installation script the containerd version is 1.2.5 which is 2 years old.

@nolden which priority does this have? In a long run, we probably replace the elasticsearch kibana stack with another technology

Additionally, I would not auto-confirm as a default. As a user I would first finish the outline and then correct it if needed. I would be really frustrated, if that is then not possible anymore.