thanks again, for solving this issue! So in the current kaapana develop the tasklist feature is now integrated!

So the last changes in the branch, are basically the changes I made, so that she could modify the code, already used for the dicomweb/kaapana interaction, to simply apply it for this modul. Since it would have been quite similar. I guess, when the changes of the rest module are done: We (AIH-Cluster will take care of restarting the MITK-Kaapana interaction). I think this could be then a not so complicated add-on.

Oh yes, I also forgot about this, the final state was, as I remember correctly, that she did not succeed in producing meaningful results.

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.

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.

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".

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.

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

Yes, sorry I didn't highlight it ;):

In the current setup, the transfer is handled from airflow. This is also the case in the wDB-gateway. This stress test should therefore perform the same way and work. I have also a different test with random data, that work up to a limit. The system has now different recovery possibilities and can therefore handle large (random sorted) datasets better. I guess that there are sometimes sill errors, but since the system then restarts, no-one notices it. But there are still limits (depending mainly on the server (RAM)).
So I would also say this ticket is resolved for now. On a long run, changing the whole import process could remain a valid option.

so, this is what we have tried so far:
helm updated to 3.6
microk9s to 1.22
first problem: v1beta1 version cannot be used anymore --> changed to v1 in the repo
next problem: our treafik is not compatible anymore (with 1.22)

So I tried it out. The problem are not the containeres (opensearch and opensearch-dashboard), but our plugin (workflow-trigger).
The plugin workflow-trigger has some package dependencies based on elastic/kibana. These dependencies have to be changed to the once of opensearch-dashboard.
So I tried to change it, but I get some yarn build issues.
So I am having different issues, probably it would be easier to restart the plugin form fresh. But for this, I would like to know, how the current plugin was created, to get an understanding, on how to create a similar one.
So the current issue is, that the package is searching for specific files, probably an opensearch-dashboard has to have a specific dir-order:

The same issue seems to apply to the normal workbench, so this container has also to be updated to the current master

after tests of the system, the problem might be at the airflow part, this has to be tested

T28207 describes how to test it without the wDB. When searching for DICOM query retrieve there are already different tasks open with all similar problems

I cannot reproduce the error. When sending the data to an instance the data gets imported. When debugging CTP locally there also seems to be no problem. For me also it looks like the problem is not directly in the CTP but in the java library (dcm4che). Did the files got triggered/send to airflow? Did they get stuck in a quarantine folder of the CTP, and if so in which?

In T27968#220733, @schererj wrote:

This is one of my model DICOMs (not 100% sure if this will reproduce it).
If not I can try to make bigger parts.

Download-link from my instance

Just a remark: The download link does not work for me. I get forbidden access. This is also the case, even if I am logged into the platform. But since there is only one folder in minio I also found it without the link:)

Can you send me a dataset to reproduce it? I could try to debug CTP, but it looks like it is not even a problem in CTP but in org.dcm4chri

Get an Openstack instance (e.g. Ubuntu 20.04 DKFZ image,...)

Can you reproduce the error? If so, we can do something like: https://stackoverflow.com/questions/12096403/java-shutting-down-on-out-of-memory-error

In T28302#220475, @kislinsk wrote:

@gaoh

I noticed that the only plugins enabled in the "MitkVolume" configuration are the segmentation plugins. Do you explicitly want to have this "slim" version or is the official WorkbenchRelease configuration more sufficient?

In T28302#220185, @floca wrote:

And MITK volume (aka the normal workbench) uses the Release build with segmentation=ON

Maybe we should then just label it MITK Workbenches to avoid confusion and reduce (redundant) artefacts.

In case of kaapana, the name is currently irrelevant: directly in the next operator, the dcm files are send to the PACs anyway and then the file is deleted.
What would make sense, regading the naming in the PACs and when downloading files, would be to give it the name of the Instance UID.

so maybe a Regex is needed, or just a default file name..

Ah so the idea is not to build it, but to directly use a CI binary.
So MITK flow uses:

# Generate Ninja build script for MITK to build a minimum configuration with apps in Release mode into MITK-superbuild directory
RUN cmake -G Ninja -S MITK -B MITK-superbuild
RUN cmake -S MITK -B MITK-superbuild -D CMAKE_BUILD_TYPE:STRING=Release -D BUILD_TESTING:BOOL=OFF -D MITK_BUILD_CONFIGURATION:STRING=FlowBenchSegmentationRelease -D MITK_CUSTOM_REVISION_DESC:STRING=MitkFlow
RUN cmake --build MITK-superbuild
RUN cmake --build MITK-superbuild/MITK-build --target package 
RUN mkdir /opt/final_package
RUN cp /opt/MITK-superbuild/MITK-build/MITK-MitkFlow-linux-x86_64.tar.gz /opt/final_package/MITK-MitkFlow-linux-x86_64.tar.gz

And MITK volume (aka the normal workbench) uses the Release build with segmentation=ON

For MITK-flow and MITK-volume I will switch to the new release (release/T28000-v2021.02). It was only on a develop branch, because there were some bug fixes, not yet in a master branch.
But now with the new release...

To be honest, I just did not understand the checklist correctly. If you know the outcome and read the checklists, they are fine. But for me, it was like a new test starting with loading and testing 3D Data again. So I misunderstood the line Bei den folgenden Aktionen stets mehrere Label, auch auf unterschiedlichen Layern testen. as beeing a new test, because it had of kind of title character. And that is why I thought, I would start with a 3d Image again...

The other options "Show as volume rendering" and "Enable auto-selection mode" are not working as described. Or I didn't get the description..

Ah it seems I was mistaking, at least the transparent overlay works, the color mismatch remains.

Ah, when changing the Preference of Segmenation, the mask is changed... How can I create a "Multilabel Mask"?

Yes, it is exactly as you described: static -> all timesteps, dynamic -> toolbox to apply to all timesteps or not.

@floca I might have found a dataset, where even the new number is not enough:
edit:
E130-Personal:\Gao\mitk-testdata\

yes exactly, the problem with the scripted version, ist still, that it is necessary to provide credentials. That was fine, as long we were the only ones creating the containers.
The version of @nolden downloading the packages in ubuntu allows others to just build the container, without having to provide credentials at all.

Oh I forgot to mention: the segmentation is saved as dicom-seg.

We need a dataset to reporduce the problem, to setup a testsetup.

So I tested it with Orthanc (without CGET only):
With 2018.04.2 retrieve works. With the current develop branch MITK crashes with the same exception:

Have you checked, if the dataset (or the slices) are already in the PACs. In my case (I got the error, when sending data from airflow to the PACs), the files creating the 409 were already in DCM4CHE.

Oh sorry, I thought it was clear, because the title is wDB related:
I used the wDB. I did not test it with a different PACs system, but I can try and report back...

In T27573 we discussed the problem of data transfer from CTP to DCM4CHE.
So basically it is a kind of similar problem: A datatransfer between CTP and DCM4CHE fails.
The problem is then, CTP just keeps the data in the queue (here) or inserts in the quarantine folder (T27573).
Anyway, we do not get notified, that there is a problem.

So for the current develop:
With or without CGET activated. When trying to Retrieve a dataset after Query, I get an Exception:

The CTP thread responsible for sending the data to the PACs crashed: