I think the handling of multiple labels depends on each action and needs to be handled separately.

• Boolean Operations: I see a few options here
  • low effort: only allow for segmentations with one label. If there is more than one label, show a message that this is not possible
  • higher effort: completely rework the selection. Let the user select two specific labels (from the same or different segmentations) and work on these, either replacing the first label or adding a new label (or instance) to that segmentation
• Contour to Image & Surface to Image:
  • low effort: leave it as is, still works at the moment
  • higher effort: introduce the option to add the newly created segmentation as a new label / instance to an existing segmentation
• Image Masking:
  • low effort: leave it as is, still works at the moment (using all labels of a segmentation)
  • higher effort: introduce the option to select which labels/instances should be considered for masking
• Morphological Operations: Currently don't crash, but always use label 1
  • I think the most senseful solution would be to let the user select a specific label for the operation to work on. Multiple at the same time probably only get in each other's way and make it unnecessarily complicated.

First draft available here: https://hub.dkfz.de/f/55114850

Updated logic to use only Normal and center to generate unique hash for a plane. Updated D847

nnUNet(v1) won't be removed until nnUnet v2 is introduced.

I can reproduce the crash.

It is technically possible but it would require about a person month to complete, so we decided for now we do not want start implementation as it is as important as other tasks that we have to accomplish.

Deleted branch from rMITK MITK: bugfix/T30159-DisableITKPathLengthCheckOnWindows.

Pushed new branch to rMITK MITK: bugfix/T30159-DisableITKPathLengthCheckOnWindows.

@floca Is this something we are already aware of (saving as .dcm crashes)?

Sounds good Ralf - happy to help!

@fedorov Thank you for your quick reply and verification for my assumption (I hoped, that I might have overlooked some broader interpretablility...)

" increase monotonically by 1" could be interpreted as "no holes allowed". We should clarify if this is the case.

👍
I would propose to also standardizeand align some of the properties for the frames to be either in sync with MITK terminology or with DICOM.

I tried to implement this feature using the below snippet in DoUpdatePreview method.
The image get written successfully however there is no level window effect in the output image. Looks normal. What's going on?

mitk::LevelWindow levelWindow;
this->GetToolManager()->GetReferenceData(0)->GetLevelWindow(levelWindow);
MITK_INFO << "levelWindow.GetLowerWindowBound(): " << levelWindow.GetLowerWindowBound();
MITK_INFO << "levelWindow.GetUpperWindowBound(): " << levelWindow.GetUpperWindowBound();
MITK_INFO << "levelWindow.GetWindow(): " << levelWindow.GetWindow();
MITK_INFO << "levelWindow.GetLevel(): " << levelWindow.GetLevel();

1. Done
2. If the geometry is to be defined right in the file itself, I vote against a ReferenceGeometry type of "Geometry" but rather actually a "Geometry" JSON object. So it is either having a reference to something else that defines the geometry or specifying the geometry right in the file without any redirections.
3. Done, also added "Type" to "Frames", which is "Box" for, well... boxes.

@kislinsk thank you for the explanations. They do make sense.

Thanks for the feedback. 🙏

Thank you for the first draft. I had the following first thoughts:

from @neher : clscreenshot sounds like something that might be useful, but i never used it

Multistage Vertebra Segmentation
Multistage Vertebra Segmentation is an auto segmentation workflow involving multiple models namely, localization_spine, localization_vertebra & segmentation_vertebra (unexposed).
There could be several issues in this:

1. localization_spine: In practice, this gives me binary mask even though there is a whole of labels exposed in the API. This is in compliance with the documentation. But then the labels it claims to segment in the API don't make sense.

CUDA memory not cleared when out-of-memory exception occurs
Not all models have the same VRAM requirement.
When a model cannot run inferencing due to torch.cuda.OutOfMemoryError, exception occurs at server side clogging the GPU. Even if another model which could have potentially ran on the GPU, this clogging blocks it. Ideally TORCH.CUDA.EMPTY_CACHE should have been called to make room for next inferencing calls.

So far only CLGlobalImageFeatures is claimed to be needed.

Pushed new branch to rMITK MITK: feature/T29644-sam-doku.

Update: Wrapper exists now at https://github.com/ASHISRAVINDRAN/sam-mitk

Python wrapper now automatically downloads model type. The feature lifted off from MITK c++ code base

Fabian has reported than nnUNet(v2) python codebase can run to Windows.

yes, issue exists the last time I tested.

Valid. Will be /is regarded in the refactoring.