@full Is this still an issue (with the current release)?

In T30157#253717, @fedorov wrote:

offer the feature to take an instance UID that is an int as the pixel value.

Not sure if I understand it correctly, but ... DICOM UID cannot have int as the value - this would violate VR constraints.

offer the feature to take an instance UID that is an int as the pixel value.

T29204 should be done before as we need to store the information in an appropriate way. The most important thing is that we have then a property to store the instance UID. The default UID is the pixelvalue if not overwritten by the user or another configuration. Regarding the persistance of the pixel value I see two option:
a) Live with the fact (and document it) that DICOM Seg is not "loss less" regarding the pixel value. So after saving to and loading from DICOM Seg your label will have the same (class) name and instance UID but might have a different pixel value.
b) offer the feature to take an instance UID that is an int as the pixel value. But this is only possible if we assure in our UI that you cannot use/change into an instance UID in a Segmentation that is alrready used there by another label.
Currently I would lean to a) and generate a new ticket for b) and see if we need it in the future.

• Boolean Operations
  • chosen: high effort
  • Can be used so that the other functions can do everything
  • Work only on one image, select two labels
• Contour to Image & Surface to Image
  • chosen: low effort seems more senseful. The functionality can be achieved via other tools (e.g. boolean)
• Image Masking
  • chosen: low effort
• Morphological Operations
  • as proposed
  • Pick an image & pick a label
  • Include options like in picking tool, i.e. generate a new layer when doing an operation, lock labels (to make sure other labels are not overwritten e.g. for a dilution)
• Add a new tool: Transfer Label could be used to transfer a label from one image to another (if the same image is selected twice, it's just a rename)

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.

I tested this again with the current version of MITK (develop branch) and can see no problems. Interpolation works without problems on my laptop (Windows 10, 32GB RAM)