When using a segmentation tool that creates a preview (e.g. Threshold), the preview is invisible if the current label is not shown (via the eye icon). When the label is made visible again, the preview stays invisible. The only way to make it visible is to deactivate the tool and select it again. (however, the tool still works correctly when confirming the segmentation, just the preview is not shown).
Description
Revisions and Commits
rMITK MITK | |||
Restricted Differential Revision | rMITKb28140233b8b Correctly show preview nodes | ||
Restricted Differential Revision | rMITK4dfb2f180948 Set the label of the preview node to visible |
Related Objects
- Mentioned In
- T29226: 2022 Week 28 (Mid July)
- Mentioned Here
- T29143: [MultiLabel Segmentation] Creating a segmentation "as new segmentation" fails
Event Timeline
I can confirm the behavior.
I debugged a little bit and found the following:
The preview-image is an own data node (e.g. Threshold preview), stored in the data storage / shown in the data manager. The QmitkLabelSetWidget::OnVisibleButtonClicked-function only retrieves the current working image and sets its visible-state.
Question: Why is the threshold preview data node invisible in the first place?
Inside mitk::AutoSegmentationWithPreviewTool::ResetPreviewNode auto newPreviewImage = workingImage->Clone(); is called, which "clones" the visibility state of the working image / label set image.
We can explicitly set the visibility here to always show a preview node, regardless of the visibility state of the corresponding label.
I added a differential for this case: D651?vs=on&id=3308#toc
However, I was wondering if cloning is the right thing to do: This will also clone all other - for the current preview irrelevant - layers and labels to the preview node / preview image, which could be avoided. You can verify this by creating a preview node (e.g. using the Threshold tool) and store this node to disk, re-load it and select in in the segmentation plugin view.
This might also be related to T29143#237012.
I updated the differential to solve this problem, but this needs to be discussed: D651?vs=3308&id=3310#toc