During our testing event there were no suggestions for new layouts people would like, so this task will be closed and any layouts that are requested in the future can be added on demand.

What exactly was the model again? Just an exponential decay?

This is more of the stack trace:

MitkCore.dll!mitk::ImageDataItem::GetData() Zeile 131
MitkCore.dll!mitk::Image::Image(const mitk::Image & other) Zeile 83
MitkMultilabel.dll!mitk::LabelSetImage::LabelSetImage(const mitk::LabelSetImage & other) Zeile 75
MitkMultilabel.dll!mitk::LabelSetImage::InternalClone() Zeile 494
MitkMultilabel.dll!mitk::LabelSetImage::Clone() Zeile 33
MitkSegmentationUI.dll!ModifyLabelProcessing<3>(mitk::LabelSetImage * labelSetImage, itk::SmartPointer<mitk::SurfaceInterpolationController> surfaceInterpolator, unsigned int timePoint) Zeile 203
MitkSegmentationUI.dll!QmitkSlicesInterpolator::OnModifyLabelChanged(const itk::Object * caller, const itk::EventObject & __formal) Zeile 1915

Can reproduce. When debugging, the error is caused while trying to clone a LabelSetImage. While creating a new mitk::Image from a reference, it tries to get:

ImageDataItemPointer volume = other.GetVolumeData(0);
this->SetVolume(volume->GetData(), 0);

but volume is nullptr.
I'm not sure if this just needs a nullptr safeguard (and eventually an additional default initialization?) or if this should not be able to happen in the first place.

This is behavior as intended. The "reset" is basically a reinit to the specified image. When there is an image higher in the list, it is rendered on top, just as in the standard display and the data manager.
I have added a hint in the checklist to make it clear this is how it is supposed to work.

This task should be revised / kept in mind when reworking the interpolation in general

This task should be revised / checked if the problem still exists when the interpolation controller has been reworked.

I think this is caused because the interpolator gets notified of a new group being added as soon as that happens, but before a new label has been added to the group. When trying to update the interpolation, it tries to get the value of the active label inside QmitkSlicesInterpolator::OnInterpolationActivated(), which causes the error because there is no active label set.

I have added a fix for this in D810. It only includes a fix to OnAcceptInterpolationClicked and does not refactor AcceptAllInterpolations, which is still quite clunky. But this should at least solve the buggy behavior.

Since this is probably not going to be fixed until this release, I have added a safeguard in PlanarFigureMapper2D::MitkRender() that completely skips rendering of planar figures in all windows that don't belong to the StdMultiWidget, to avoid unexpected behavior and crashes.
When this task is tackled, that needs to be removed!

It was discussed and agreed upon, that it does not make sense to adapt this behavior in the Data Manager. If we want a clean implementation of the "set focus on planar figure"-feature, it should belong in the corresponding view (i.e. Measurement) instead of the Data Manager.
As this is not currently a specifically requested feature, this task will be closed.

In T29504#246386, @kalali wrote:

This is not solved with {D795}, right? I can still see slicer->GetRenderer() in line 926, so the render window is still retrieved from the slice navigation controller, which requires the getter to be available in the slice navigation controller.