That would also help to avoid problems like T29388

@kompan and I created this guide some time ago. We can reuse it, extend it and put the content into the Phabricator wiki: https://hub.dkfz.de/f/7173768

If D744 is landed, we can close this task. The issue will be addressed here: T29369: [Segmentation Utilities] Handle / select different labels independently.

With {D744} we only have a single Segmentation Utilities view. Labels operation should be added to this and then the issue of this task needs to be considered.

I think it actually is an issue or at least unexpected. The level window seems to have trouble with color images in general.

Thank you 🙏

Here's the first batch of clean-up action. Needs to be continued!

In T24398#241998, @floca wrote:

Our side or also the CTK part.

Hm, lets put it as known issue and discuss its priority when we plan the spring release.

thank you for looking into that matter.

In T24398#241991, @kislinsk wrote:

I noticed that the whole plugin is a complete mess BTW and urgently needs at least some clean up to see all the potentials for improvements and bug fixes. :/

Our side or also the CTK part.

We discussed on it.

Could be the same issue like in T28816: [Segmentation] "New Segmentation" dialog to small

Pushed new branch to rMITK MITK: feature/T29295-monai-segmentation-tool.

Pushed new branch to rMITK MITK: bugfix/T27578-RemoveTCPWrappersDependency.

Looking closer into the issue I wonder why it should not work without TCP Wrappers. It is an optional dependency of DCMTK which, regarding to storescp, adds two access control cmd-line arguments that we are not using anyway as far as I can see. So maybe it is just an issue since we so an explicit requirement check and then of course DO link against it. If we would explicitly disable it in DCMTK and remove the check in our CMake script, it should probably work already,

I would recommend to file a ticket in the DCMTK bug tracker since it is a dependency of dcmnet.

ok, but then the GPU problem is also feasible! If it is for a pre-known time-limited usage, like in an interactive session, I don't see a problem assigning a GPU to the container.

In T29243#240152, @gaoh wrote:

What is the advantage of running nnunet in MITK in kaapana, over directly running nnunet in kaapana?

If you have a bunch of data, then the airflow workflow is the way to go.

To point 1, in Kubernetes you can mount any path/volume to the desired mounting point. So I could just mount the directory in the MITK container in e.g. /models

Will be fixed in conjunction with T25105: UpdateStatusBar duplicates business logic.

@j762e If you work in the task (which would be great ;), please claim it.

In newer versions of ITK the GrowCut.remote.cmake is added by default to Remote Modules (eg. https://github.com/InsightSoftwareConsortium/ITK/tree/master/Modules/Remote).
Our version of ITK (https://www.mitk.org/download/thirdparty/) doesn't include that yet.
rMITKc94224c7fe81 is a "workaround" to still add the Remote Module without changing the present version of ITK on our server and might be reverted in future.

Pushed new branch to rMITK MITK: feature/T28851-AddITKGrowCutTool.

Deleted branch from rMITK MITK: feature/T28354-cmake_faq.

Deleted branch from rMITK MITK: bugfix/T27701-PluginGenerator.

Resolved with T28285: DICOM with 'ä' in filename not readable on Windows.

My changes related to this task were mainly to clear some classes and remove uncertainty (see T28617: Inconsistent view initialization in rendering manager).
As far as I see it some changes have been made in the subtask T28490: Segmentation plugin: "new" segmentation should not run reinit! and the respective D523: This was mainly concerned with NOT resetting the view / camera using a newly introduced parameter "resetCamera".

In general yes, the behavior is correct if needed, but in this case it was caused by an incorrect/missing time point mapping between image and mask.

What is here still open?