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.

please ask tanja before I say something wrong.

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

Ya, you are right. I didn't think it through. A Group cannot have overlapping labels. Hence, when asked to Ignore Label lock, would mean it has to go when Otsu-generated labels are confirmed.

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

No that should not happen. What is the rest of the stack trace? Does it fail to clone a layer image or the LabelSetImage itself?

I don't understand the propblem. It behaves like it should. If you ignore locks and transfer all otsu labels, all other labels of a group will be wiped (but still the label exist, as tools do not delete label instances but only pixels), because otsu covers all pixels.

Fixed with D837

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.

Pushed new branch to rMITK MITK: feature/T29606-Add_MatchPoint_MiniApps.

🙏

Tested on the latest MITK 2023.04 release installer for Windows 10.
Problem doesn't exist anymore. Fixed.

As we now have preferences at the module level that can be done even in a better way. Now the mapper can set the default node settings for rendering if not already done. No need to have it handled by the reading code anymore.

I reeopened because I would like to llok into the feature branch at least and see what might be of interest:

@a178n Could you verify if the problem still exist or if it is fixed?