This may be somewhat similar and / or related to T19935

For 4D images the crash occurs in

mitk::RegionGrowingTool::OnMousePressed

due to

m_WorkingSlice->GetTimeGeometry()->GetGeometryForTimeStep(m_LastEventSender->GetTimeStep())

returning a nullptr, as GetTimeGeometry() only has a single timestep even for 4D images.

For me a multi component crash does not happen anymore.

Pushed new branch T22412-prevent-regiongrowing-timestep-crash.

The 3D+t problem should now be fixed. However, my solution is by no means an elegant one.

Currently the RegionGrowingTool gets it working/reference slices via its base class FeedbackContourTool. Previously the RegionGrowingTool assumed these slices to be 2D+t, however the FeedBackContourTool only returns a 2D slice, albeit of the correct timestep.

This was changed, the RegionGrowingTool now assumes to already have the correct timestep.

When generating the contourmodel the timestep of the working slice is internally used by the ImageToContourModelFilter. So the resulting contourmodel is written for timestep 0. This in turn results in the mapper not displaying it, as the current timestep of the contourmodel is empty.

I circumvented this problem by, for timesteps != 0, copying the contourmodel to a new one with the correct timestep before rendering and back afterwards for the segmentation generation.

This crutch should be removed when redesigning the tools.

In T22412#215903, @kalali wrote:

In T22412#93426, @goch wrote:

This crutch should be removed when redesigning the tools.

@floca I stumbled upon this and I was wondering if this crutch can be removed with the changes made in T27490.

May be. We would need to test it.
@neher do we have suiteable testdata?

@neher or @jaegerp can someone provide test data? Otherwise I would close this task for now, because I cannot check or reproduce the problem without data.

In T22412#93055, @kislinsk wrote:

Also crashes with normal 4D images. In Multilabel segmentation 2D region crowing, too.

I'm not exactly sure what that means. Can we also use our default 3D data to test? Does it have to be nifty?