Hi there! 🙂

theoretically yes, but I guess it is not relevant. Since we now use the tasklist feature. And before that, I used the described workaround. So this is not needed anymore.

@gaoh is this still an open issue?

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.

Since in the input image a required tag is missing, MITK cannot provide a fix, allowing a success in dcmqi

In T28886#232894, @kalali wrote:

Please check if the problem persists now with T28903: [Segmentation] Monitoring of segmentation nodes in views is error prone/ not safe. merged into develop.

Input data to reproduce the error:

We discussed in the meeting:

1. Exception handling is a good idea and should be the way to handle it. So mitk has to throw the exception and not show a success.
2. Since in the input image a required tag is missing, MITK cannot provide a fix, allowing a success in dcmqi