Oh I forgot to mention: the segmentation is saved as dicom-seg.

Pushed new branch bugfix/T28151-FixVTKOnMacOSXCode12.

Deleted branch bugfix/T27717-FixMacOSInstallerOpenApp.

Pushed new branch bugfix/T27717-FixMacOSInstallerOpenApp.

It works when any argument is passed to the workbench via the open command, e.g., open MitkWorkbench.app --args --BlueBerry.newInstance. My first guess that the additions in rMITKf54a83e2 cannot handle 0 arguments when the implicit -psn argument is sneaked into argv by macOS.

Ok. Found the problem. Should now be fixed with the new diff. At least it works on my PC now with the test files.

Was removed in rMITK66bb0d67 and forgotten to get restored in rMITK02a46548.

Deleted branch bugfix/T28137-FixMissingContextMenuEntries.

Pushed new branch bugfix/T28137-FixMissingContextMenuEntries.

Thanks @kalali, nice find and hint. A sneaky line is missing in DataManager's plugin.xml: <extension-point id="contextMenuActions" name="Context menu actions"/>.

Will be fixed (is fixed already) by the rework done in T28118.

Pushed new branch T28143-AbsSpectraCorrection.

The scene is created successfully if following (deprecated) properties are disabled in mitkDICOMImageBlockDescriptor.cpp:

In T28118#216941, @floca wrote:

Regarding the selection, I think you are rigt and there should ultimatly be no difference. But for the current strive for getting things cleaned up and in shape, it is of lower priority. I am happy, if we get through with the fundamental rework and time consistency stuff for this release.

In T28118#216794, @kalali wrote:

Looking through the checklists I found that the 2D tools of the segmentation view are different than the 2D tools of the Multilabel segmentation (one more: Fast Marching is missing).

What do you mean with different. Different in there behavior or a different selection of tools.

There are some issues / open questions regarding the MultiLabel Segmentation options:
T26959: [Segmentation] Newly created LabelSet segmentation is not displayed as "outline binary", T27712: Preference "Show as volume rendering" does not display segmentation volume in 4-window view, T27498#216892, T28137: Extension point for org.mitk.gui.qt.datamanager.contextMenuActions does not work anymore.

I just realized that the auto-selection mode of the Data node selection mode in the preferences pages of the Segmentation and MultiLabel Segmentation does not work anymore. I did not look into it but it might be related to the new selection concept.

There are some major issues / open questions regarding the MultiLabel Segmentation View, which make it difficult to define tests and create checklists. These issues / questions should be addresses first to understand the utilities view better: T27809: [Segmentation Utilities] "Labels" tabs in operations of Utilities view is empty, T27810: [Multilabel Segmentation] Inconsistencies and unclear functionality in operations of Utilities view, T28134: [Multilabel Segmentation] No warning triggered when using different mask geometries / dimensions in Utilities View, T28135: [MultiLabel Segmentation] Utilities view cannot handle non-binary multilabel segmentations.

Similar to T28111: Extend "Checkliste MultiLabel Segmentierung – 2D Segmentierung" I updated the document and added content to explicitly tests different image types / segmentation types, labels and layers.
I copied the modified document to E130-Daten\Release\Checklisten\MITK Workbench Release and named it Checkliste MultiLabel Segmentierung – 3D Segmentierung.

Looking through the checklists I found that the 2D tools of the segmentation view are different than the 2D tools of the Multilabel segmentation (one more: Fast Marching is missing). The 3D tools of the multi label segmentation even contain only the Threshold tool.
Thinking about the idea of the MultiLabel segmentation (and that our normal segmentation view also generates labelset images) it should actually not make any difference and thus the tools should be the same (2D and 3D are of course different).
Also, there seems to be a lot of redundancy UI-wise so even having multiple segmentation views and the 2D / 3D tool view for both views seems unnecessary. I would keep that in mind while refactoring the tools. But I am open for discussion on this topic.

In T28113#216778, @kalali wrote:

I haven't made up my mind about the best way to go, I'm open for suggestions. I just wanted to state that even the checklists state something different. So to align the tests with what the workbench actually does, we should clarify, how the tools actually behave or should behave.

In T28113#216776, @floca wrote:

• If the tool is deactivated (explicitly, by selecting another tool, by closing the view) all unconfirmed contours will be removed.

And this is not the case right now. Currently, a mask will be generated and drawn into the image.

I haven't made up my mind about the best way to go, I'm open for suggestions. I just wanted to state that even the checklists state something different. So to align the tests with what the workbench actually does, we should clarify, how the tools actually behave or should behave.

Regarding the issue itself: I think it is a fundamental question of the capability of the tool. Auto confirm when closing the contour would
Pro: be a faster UX
Contra: won't allow to alter live wires before confirmation.

In T28113#216737, @kalali wrote:

I just found out that the Checklists also states the following:

Deaktiveren des Live Wire Tools
  Tool Icon verschwindet vom Mouse Cursor
  Die gelben Konturen werden weiterhin angezeigt, können aber nicht mehr bearbeitet werden

So even the experienced behavior does not fit the checklist test. We should clarify which workflow we want to provide.

Will be fixed (is fixed already) by the rework done in T28118.