In T29396#243822, @kalali wrote:

Yes that's what I found out too. I wanted to test something by changing the threshold tool to accept a vector image and work with AccessVectorPixelTypeByItk_n and itk::VectorImage<TPixel, VImageDimension> VectorImageType; but let's discuss how we want to prioritize this.

Yes that's what I found out too. I wanted to test something by changing the threshold tool to accept a vector image and work with AccessVectorPixelTypeByItk_n and itk::VectorImage<TPixel, VImageDimension> VectorImageType; but let's discuss how we want to prioritize this.

And we should add this case to our checklist in order to test seg not also with 3D and 3D+t, but also vector images.

The problem is that Peter used a vector image. and now the mask is a vector image too, this is why the accessors do complain. I guess we have to fix the function that generates the plain segmentation image based on the image as template.

@floca The error seems to be inside AccessFixedTypeByItk_n, which produces a _accessByItkPixelTypeException (from inside Modules/Core/include/mitkImageAccessByItk.h

I looked into this and can verify the behavior.
I debugged and the crash happens inside ``
I tested other 3D tools, e.g. "Threshold" or "UL Threshold" (and even Otsu) and the following error message is shown:

Pixel type vector is not in (int)( unsigned int)( short)( unsigned short)( char)( unsigned char)(double)( float)

When initializing the plane nodes inside CrosshairManager DataNode::SetMapper is called which results in the node's m_Mapper variable to hold a PlaneGeometryDataMapper2D at position 1 (mapper slot id is Standard2D = 1).
But if DataNode::GetMapper is called later with MapperSlotId = 1 the list m_Mappers is completely empty and a new mapper is created via the BoundingShapeObjectFactory.

Somehow it seems as if the BoundingShapeObjectFactory is the last factory to be checked for extra factories to create valid mappers and this one is then used (it overwrites previously existing mappers). I wonder why this does not happen for the StdMultiWidget.

It seems as if there is something wrong with mitk::CoreObjectFactory::CreateMapper but I have to go a little bit deeper. Maybe this is also related to {D755} because the crosshair planes do not get a specific mapper set.

I added T24704: [Multi widget] Rules for updating the render windows as a somewhat related task.

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".

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.