Is this reason for a patch release?

That would also help to avoid problems like T29388

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

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.

Unfortunately not solved. Same error.

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.

Shortcut to reproduce the crash:

• Start the Workbench
• If not already opened, open the Segmentation View
• Close the project or close the Standard Display
• Load any segmentation

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.

The interesting part here is that m_Time of mitk::BaseController is not supposed to be nullptr in particular as m_Slice is a valid stepper. My first guess is that a partly deconstructed controller is triggered here.

The crash happens in mitk::SliceNavigationController::GetSelectedTimeStep() as m_Time (mitk::Stepper::Pointer) is accessed while it is a nullptr. The events that lead to this situation are that the mitk::ToolManager notifies QmitkSlicesInterpolator via OnToolManagerWorkingDataModified(). This method calls SetCurrentContourListID() in turn, which executes the crashing line of code:

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.

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?

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?

Deleted branch from rMITK MITK: feature/T28578-MxN-development.

3. The relevance of the labels list outside models? Perhaps, this entry can be used to describe all labels and their label ids used in the host app. And, models can then refer to label ids in their respective labels entries.

2. Lack of consistency in models->labels entries. For some models eg. deepedit there are label ids along with names, effectively assuming a Map datatype and for others, eg. deepgrow_2d it's a list. of label names. This creates unnecessary corner cases while parsing using strongly typed languages, like C++.

1. There is no indication in the JSON on which models are interactive click guided, scribble guided or automatic. Eg. Deepedit can be interactive click-guided or automatic, GMM+GraphCut is scribble guided, Segmentation Spleen is purely automatic. Hence, the JSON parameter type can be made more consistent for easy grouping.

Deleted branch from rMITK MITK: release/T29377-2022-Week-43.

Pushed new branch to rMITK MITK: release/T29377-2022-Week-43.

Hm, I disagree. :-)

These variables need to point to the location where CMake's find_package() will find the packages. For example, for ITK it would need to point to the equivalent of the MITK-superbuild/ep/lib/cmake/ITK-5.2 folder, where the ITKConfig.cmake and ITKConfigVersion.cmake files are located.

With -DEXTERNAL_ITK_DIR=/usr/local it still downloads and builds ITK.

The superbuild has advanced variables for that:

• EXTERNAL_ITK_DIR
• EXTERNAL_HDF5_DIR
• EXTERNAL_BOOST_ROOT

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

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.