In T26543#243885, @floca wrote:

@kalali please indicate that it has breaking changes in your commit message and how to handle them/migrate. thanks.

Would be nice if a note is added to the documentation that the MitkPluginGenerator is currently not active. :)

@kalali please indicate that it has breaking changes in your commit message and how to handle them/migrate. thanks.

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.

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

Unfortunately not solved. Same error.