- User Since
- Sep 3 2018, 11:01 AM (136 w, 19 h)
Thu, Apr 8
Tue, Apr 6
Mon, Mar 29
Wed, Mar 24
Mon, Mar 22
after tests of the system, the problem might be at the airflow part, this has to be tested
Tue, Mar 16
Mon, Mar 15
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
Mar 11 2021
Mar 10 2021
Mar 4 2021
Mar 1 2021
Feb 24 2021
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?
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
Feb 23 2021
Get an Openstack instance (e.g. Ubuntu 20.04 DKFZ image,...)
Feb 22 2021
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
Feb 19 2021
Feb 18 2021
Feb 17 2021
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.
Feb 16 2021
so maybe a Regex is needed, or just a default file name..
Feb 12 2021
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...
Feb 5 2021
Feb 1 2021
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...
Jan 29 2021
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.
Jan 28 2021
Jan 27 2021
Jan 20 2021
@floca I might have found a dataset, where even the new number is not enough:
Jan 15 2021
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.
Jan 14 2021
Jan 13 2021
Oh I forgot to mention: the segmentation is saved as dicom-seg.
Jan 7 2021
Dec 21 2020
Dec 17 2020
Dec 16 2020
Dec 15 2020
Dec 10 2020
We need a dataset to reporduce the problem, to setup a testsetup.
Dec 1 2020
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:
Nov 30 2020
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...
Nov 26 2020
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.
Nov 25 2020
So for the current develop:
With or without CGET activated. When trying to Retrieve a dataset after Query, I get an Exception:
Nov 24 2020
Nov 17 2020
The CTP thread responsible for sending the data to the PACs crashed: