Discussion result: nice to have wären auch die Informationen des "first pass" (-> welche reader configuratoin, findet wieviele volumes und welche Dateien werden verwendet) schön.

To make our live a bit easier. I would say it is a data problem ;).

oh so I forgot to send it: But this is, what my browser had cashed: "Yes, so I recently tested it, with the current release."
But also, if I remember correctly, this was due to the Phantom dataset we have as the default dataset:
I removed a few slices at the end, and now it is working.

@gaoh Ping

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

yes, that will help. Also, this worklist will be quite helpful, allowing a new form of "batch-processing".

@gaoh maybe also the worklist feature covered by T29159 would also help/suffice? Than you could explicitly define the output path.

Yes, so I changed it already, and I am using the seriesUID as name for the images. Additionally, I had to add the layer property: Because by introducing the image name property, somehow the layer is also set (to a high number, probably). When I create a new SEG without setting the layer of the image to 0, the SEG is only put on top, when opening the data manager.

@gaoh could you join the discussion?
Also may be the worklist feature T29159 would be an additional way to circumvent it.?!?

@gaoh Would you be so kind and verify that the problem still exists? Thanks.