After suspecting whether python process using std::async would be causing the issue, like below:

m_Future = std::async(std::launch::async, &mitk::SegmentAnythingPythonService::start_python_daemon, this);

I tried starting python process using basic std::thread like shown below:

std::thread([&](){mitk::SegmentAnythingPythonService::start_python_daemon();}).detach();

there is no change in behavior.
The issue root cause still eludes me.

Pushed new branch to rMITK MITK: feature/T29560-totalseg-label-update.

After meeting, it was decided to remove the quotes from label names.

It's agreed in the meeting that the status quo is inconsistent.

Yes, after commenting the 4 lines in the mitkExtractSliceFilter I am getting 3 component image.
Also, found out that the following works instead of commenting the snippet out:
Comment vectorComponentExtractor->SetComponents(m_Component); and pass on exact component needed to vectorComponentExtractor->SetComponents(0,1,2);.

Checklists updated

Oh ok. Yes, I can the see the pixel type "rgb". Also, when I save the mitk::Image object using IOUtils::Save, I can see (in python) that the written image is 3 channel.
But the issue still occurs, channel is information is ultimately lost here in mitk::SegWithPreviewTool::UpdatePreview:

After a little debugging, I see that even DataNode::GetData() returns single channel Image.
eg. dynamic_cast<const Image *>(m_SegmentationInputNode->GetData())
SegPreviewTool class uses this image for further processing.

Anyway after discussing with Ralf, the problem at hand - implementing levelwindow effect of input images to SAM, is solved using itk::IntensityWindowingImageFilter.

Updated document: https://hub.dkfz.de/f/55254009

1. I am seeing the array in python after writing it out IOUtil::Save(mitkImage, imagePath);. That's 4 channel image. ie. 32x32x4.
2. I use vtkMitkLevelWindowFilter because you recommended(?) and also its used by MITK for its levelwindow processing and at few other occasions. So this data type change is widely affecting MITK. But whether its compensated somewhere else or not is not clear for me.

But for SAM tool- Thanks for the tip, I will try out vtkImageMapToColors and see.

Hi,
I finally could apply levelwindow Filter on image successfully for SAM tool.
But that seems to opened up another can of worms 😅 (?)
The vtkMitkLevelWindowFilter gives me 2D 4 channel image. But the channels are duplicate. I verified using numpy/python. Presumably. I can just take out one channel slice and that should be it.
But I observe somethings not correct:

1. I convert vtk image to mitk image using the following syntax:

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 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();

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.

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.

A practical solution is to shift the download feature into the python wrapper.

After discussion with @kislinsk, it's presumed that Ubuntu 22.04 comes with OpenSSL 3 which is incompatible to OpenSSL 1.1.1. Qt from the online installer was built against OpenSSL 1.1.1, though. That's why it is not working. It probably works Ubuntu setups with system Qt 5 which I guess is patched to work with system OpenSSL 3.
Therefore, so the way out, without any fixes to get this running on Ubuntu 22.04 is on the actual build machine when using system Qt5.

Code test and patched for 2D image support.

I am not sure what happens when 2D 3 channel is loaded for segmentation. Never tested the behaviour of the SegWithPreviewTool API. From my side, I need to update the wrapper to accommodate for 3 channel images. Of course, it's a straightforward change but at the moment, 3-channel won't work.