This task is invalid since we moved the functionality of the render window manager to render window specific drop-down menus. More discussion about the concept will happen in T29297: [mxn multi widget] Optimize data accessibility inside render windows.

We will add the two suggested changes as a hotfix / release patch because

• we should definitely avoid workbench crashes
• also old legacy segmentations / scene files will provoke the crash

In T29388#243635, @floca wrote:

The seg predicate of the view is wrong. Should not be able to select the nifti at all.

Also seg in nifti form have to be converted into label image currently via context menu "convert to segmentation".

I added a first fix to avoid crashes. More changes are required:
Inside QmitkSegmentationView::UpdateGUI() the two functions m_Controls->layersWidget->UpdateGUI() and m_Controls->labelsWidget->UpdateGUI() are called. They both require the working image to be a LabelSetImage, otherwise the GUI elements will stay deactivated. Also, since no layer is available the toolselectionboxes stay deactivated.

I looked into this and although I understand the problem, the issue does not really exist, as far as I can see:

• changing the slice via scrolling will call SliceNavigationController::SelectSliceByPoint
• calling SliceNavigationController::SelectSliceByPoint will call SliceNavigationController::SendCreatedWorldGeometryUpdate
• calling SliceNavigationController::SendCreatedWorldGeometryUpdate will InvokeEvent(GeometryUpdateEvent(m_CreatedWorldGeometry, m_Slice->GetPos()))
• invoking the event will lead to a call to BaseRenderer::UpdateGeometry

-> until here I agree with the task description

In T28989#233817, @kalali wrote:

mitk::Tool::CanHandle:

In T28989, @kalali wrote:

The basic mitk::Tool restricts the data that can be handled to reference-data - working-data pairs, where

• the reference-data is valid

Why is it not required for the working-data to be valid? This is a requirement for all following CanHandle-functions (working data needs to be an mitk::LabelSetImage or an mitk::Image) that override the basic function, so why not put it in the basic class function?

@kompan and I created this guide some time ago. We can reuse it, extend it and put the content into the Phabricator wiki: https://hub.dkfz.de/f/7173768

It seems as if there is a mapping between the SliceNavigationController::ViewDirection and PlaneGeometry::PlaneOrientation, which makes it unnecessary to keep the direction / orientation in both classes.

All related tasks have been resolved so we can close this task as well. The "issue" still remains but we are exploiting it on purpose now using the changes made in {D686}, to show pixel information dynamically (position under the mouse cursor) in the status bar.
With the changes made in {D749} we now have the possibility to explicitly show image pixel information for the crosshair position in the newly introduced pixel value view.

In T29025#243469, @kislinsk wrote:

In T29025#243461, @kalali wrote:

I stumbled upon this while working on T28752: [Segmentation] Move Segmentation utilities widgets to SegmentationUI module. I would like to tackle this issue and already started looking into this. Do you already have an idea how to approach it or do we want to discuss it next week?

I already implemented most of it as core service a while ago but then was interrupted by something else. As far as I remember it is nearly complete except for the equivalent of BlueBerry's preference storage. I will look for the branch the upcoming week and push it. Never assigned the task, sorry.

Required for T28752: [Segmentation] Move Segmentation utilities widgets to SegmentationUI module / T27133: [Segmentation] Is QmitkDataSelectionWidget needed anymore?.

I stumbled upon this while working on T28752: [Segmentation] Move Segmentation utilities widgets to SegmentationUI module. I would like to tackle this issue and already started looking into this. Do you already have an idea how to approach it or do we want to discuss it next week?

The warning was reverted for the StdMultiWidget. More changes (problems were already mentioned here in this task) will be further implemented using T29335: [Segmentation] Show interactive warning for uninitialized render window geometry.

Could you explicitly "reinit" the reference node and see if that changes anything?

I guess the second issue is not yet fixed and will be covered in T29369: [Segmentation Utilities] Handle / select different labels independently.

If D744 is landed, we can close this task. The issue will be addressed here: T29369: [Segmentation Utilities] Handle / select different labels independently.

In general with {D744} being landed the multilabel utilities do not exist anymore so this task is obsolete.
We could discuss how to handle multiple labels for the single segmentation utilities, though, but I opened a new task for this: T29369: [Segmentation Utilities] Handle / select different labels independently.

The way the masking is done inside the QmitkImageMaskingWidget of the segmentation-plugin is different but it works as expected and is easy to understand.
As written in the task description the QmitkImageMaskingWidget of the multilabelsegmentation-plugin provided different options, but they were not used so I think we are safe here.

With {D744} being landed we can finally move the widgets to the SegmentationUI module.

With {D744 } being landed we need to check if this also applies for the single remaining Segmentation Utilities view.

With {D744} we only have a single Segmentation Utilities view. Labels operation should be added to this and then the issue of this task needs to be considered.

I added a task in the "smoothed polygon" section:
Task

extend one segmentation to multiple neighboring slices to create a “3D” segmentation

Result

The segmentation mask is rendered on multiple neighboring slices.

I removed the „Smoothed surface creation“ Preference section from the Segmentation - Options checklist.

We discussed this and we decided to remove the options from the preferences completely. This will be done in the mentioned task T28793: [Segmentation][Multilabel][Options] Changing only decimation rate has no visible effect in "Create smoothed polygon model".

We discussed this and we decided to remove the options from the preferences completely. That means, that

• the user cannot change the smoothing hint / value
• the user cannot change the decimation rate
• the checklists don't need to ask for changing these values
• the smoothing will use the default values (set inside QmitkCreatePolygonModelAction::Run)
  • "smoothing hint" = true (will always use image spacing as hint)
  • "smoothing value" = 1.0
  • "decimation rate" = 0.5
  • "closing ratio" was not used at all
  • note that different default values are given in ShowSegmentationAsSurface::Initialize (and other functions of this class), but are overwritten / reset by the polygon action.

I modified the 2D Segmentation checklist accordingly, taking also T29349: [SEG] Improve/correct button names of live wire/lasso tool. into account:

• UI element strings were updated
• section for "Lasso" tool was added

Maybe I can clarify a few things:

1. I think it is important to also show helper nodes. In the basic simple case this leads to only showing the widget planes but in other scenarios helper nodes might be important to inspect. However, we could think about adding a checkbox inside a node-selection dialog to show / hide helper nodes, if the list of nodes is too long in scenarios with many helper nodes.

While I was looking into T29352: Segmentation Options Checklist - "Create Smoothed Polygon" Seems Not to Work I remembered this task. A small differential for this task has been added. The purpose is to clean the interface for those classes that don't need the extra functions / properties and provide an additional interface solely (for now) for the QmitkCreatePolygonModelAction.