I tested this and as far as I can see this bug is still valid. However, we have already opened related tasks (T28763: [Multilabel Segmentation] Fill / Erase tool does not fully respect multiple labels and T29078: [Segmentation] Erase tool has unclear edge cases) and it seems as if we have to make a decision, how the fill / erase tools should behave, so I opened T29132: [MultiLabel Segmentation] Define desired behavior of fill / erase tool.

I couldn't find a good solution to this. Some points that are problematic:

• opening the context-menu using right-click will select the item / row
• disabling specific columns / cells is not possible with a table widget
  • using a table view and a customized model would allow this, but
    • then it wouldn't be possible to click a button inside this cell
  • using simple checkboxes instead of the icon-buttons could work but then the previously highlighted selection is lost (and no new selection is highlighted)

@kahl So are you working on this? If not, could you remove yourself as the assignee of this task?

In T29087#236321, @kalali wrote:

@floca I'm not sure if this was your intention but it seems as if D622 also solves this issue - at least I'm not able to reproduce this, given the description, with your changes.

@floca I'm not sure if this was your intention but it seems as if D622 also solves this issue - at least I'm not able to reproduce this, given the description, with your changes.

I tested this with the related review and the differential solves this issue.

I tested this with the related review and the differential solves this issue.

I tested this with the related review and the differential solves this issue.

I tested this with the related review and the fix c042953a0088 solves this issue.

In T29047#235873, @kislinsk wrote:

After this was merged, we should add a note to the label set preset section about the newly introduced default label set preset T29107 (I didn't want to create more merge-conflicts than necessary for you). :-)

In T29090#236258, @kalali wrote:

I think you mean T26959: [Segmentation] Newly created LabelSet segmentation is not displayed as "outline binary".

I think you mean T26959: [Segmentation] Newly created LabelSet segmentation is not displayed as "outline binary".

The change is easily done and a 3 liner. But I think it is very close to the topic dicussed lately about how to visualize labels, active labels and previews properly in the future. (I am not able to find the task right now. @kalali brought it up and we discussed it in one of our latest MITK meetings (~1 month ago)).

As we want to change the behavior of Otsu and nnUnet to allow the generation/return of multiple labels, the UI element you refer to will be dropped. Therefore I would also drop this idea, as the parts it would optimize are deprecated.

I was able to reproduce this on Windows 10, but the behavior seems to be very inconsistent. When testing with Pic3D.nrrd and brain.nrrd, I took the following steps:

• load the image
• create a new segmentation
• draw with the Add- / Region growing - tool in one of the views
• draw again with the same tool in a different view

The behavior then differs depending on which views were used. Generally, when first drawing in the axial view and then in either of the other two, the second addition is not drawn interactively but only shown when letting go of the mouse button. This sometimes also occurs when going coronal -> sagittal or sagittal -> coronal, but never when doing the axial view second.
This only happens when using the same tool in both views without deactivating. If I switch the tool or deactivate and re-activate it, the second drawing works perfectly fine.

I am not able to reproduce this problem on Windows 10 using brain.nrrd as test image

Pushed new branch to rMITK MITK: bugfix/T29087-Fix_autosegtool_label_awarness.

From what I can see, the level window is reset to its original state after pressing "Confirm Segmentation". The darkening / changed level window is only temporary to help adjusting the parameters of the region growing. To me this seems like a feature, not a bug. At least it is by design, anyway.

I guess this task is related: T27613: Improve reinit behavior.

In T27510#231230, @kalali wrote:

@m907r While working on the image statistics tasks you could write down your insights on how the front-end and the back-end are designed and how they are restructured to gradually add information for this task. This will help us write a clean / improve the developer-manual for the image statistics plugin / module.

Maybe this is related: T28763: [Multilabel Segmentation] Fill / Erase tool does not fully respect multiple labels.

I edited the task description since it is a general issue regarding data node removal, not restricted to image cropper bounding boxes. The rational for that is that (1) the scene adapts/focusses on the left overs so that the scene is always as tight as possible in its extents and (2) the global geometry is in sync with the remaining geometries which is for example important for segmentation which may require you to do manual reinits on images to sync with their geometry.

• Erase works on the whole slice (for the currently selected label) when clicking on the background label and the clicked region touches every single border pixel.
• Erase works only for the selected label but still the preview snaps to other labels if clicked into them resulting basically in a no-op.

Might be related: T28827: [Segmentation][Interpolation] Color of 3D interpolated segmentations is red, not green.

Good idea, done.

@kislinsk Could you add commit-links or similar to show how this was resolved?

Related: T29088: [Checklist] 3D Segmentation - Checklist and MITK UI Inconsistencies

@kislinsk I'm not sure if this is the same issue as the child issues. I guess here the problem is, that the Otsu Tool writes to the first label, although the second one is selected.
The linked issues in the subtasks in contrast all mention that a tool overwrites a label - as far as I understood they write the output to the correct label, but the previous one is just erased (which is a known problem and was already mentioned in T28991: [Segmentation] 3D tools overwrite / remove previous mask if reconfirmed.

@floca Are you really working on this? This issue was mentioned again in the tested checklist in T28768: Region Growing in its current state is unintuitive.

@isensee Ping!

Naming and coloring is now fixed in the release branch. Names and colors of new labels will be unique across all layers.

Also: Changing the color of a label in layer != 0, requires a click in a render window to make the changed color visible.

I guess the wrong signal of the widget is connected here as the number should only be applied after it is completely entered. The correct signal should be editingFinished().

Request for discussion: The green color is chosen deliberately as it is the typical preview color in MITK segmentation. We should discuss it should be different here and what are the implications regarding overriding/merging with existing labels.

Since we will have changes regarding the number of tools and the number of tools is even different for different operating systems (for example nnUNet is only available on Linux), we should probably not write a specific number into the checklist.

After this was merged, we should add a note to the label set preset section about the newly introduced default label set preset T29107 (I didn't want to create more merge-conflicts than necessary for you). :-)

Merged into the current release branch.