@nolden which priority does this have? In a long run, we probably replace the elasticsearch kibana stack with another technology

Hey Marco, I had uploaded the models there back in the days:

Thanks. I think restricted access to code and models makes a big difference in the sense of preparatory work, code cleaning. model licensing etc.. ;) So that's why we thought it would be good first step to resolve all technical issues. Moving code and models to a public location would be another thing then.

Ok, but this makes not a big difference, right?
Here's what I think would be good for us:

• A single Dockerfile build-able without any local files
• The needed source-code should be downloaded via a direct git clone within the Dockerfile
• Internal usage would allow to pass credentials as build-args to git
• Models should be downloaded via curl during the build-process as well
• There should be two stages:
  1. Download and build source-code + download and unzip models
  2. Execution environment (incl. the models) - but without build dependencies, build tree etc

Thanks @schererj , maybe one information was missing: as a first step we thought about making this build-able internally, so as part of the Kaapana/Dcipher-internal repo (option 2 in my comment above from March 25th)

The problem is the MBI branch, which is afaik not public.
If there is a working Dockerfile, which can be publicly build, I'm happy to include it.
Additionally the models need to be put somewhere to be downloaded (also public in this case).
Hope this helps.

@norajitr thanks for the follow up. Could you attach the two (?) Dockerfiles here and post the network drive path? Maybe someone else from Kaapana (internal) could have a look then, too.

After talking with Marco, I have looked for the whereabouts of dockerfiles (liver-mri and multiorgan-seg), working commits for MITK (a0dedffb74d) and for MBI-builds (56ad5bf7064) and trained models. @schererj: I sent you this information via email in October 2020, and shared the trained models on the network drives. Can you confirm? What information do you need to keep the shape models operational?

Checked again, no idea how to fix it. The Browser seems to remove the mime type of the object... so either i remove the file check completely or we find a way of how the browser can be enabled to deal with mime types:

Is this ticket then realy priority "wishlist"? (Stefan put it there because it was not triaged at all) A solution (what ever it maybe) seems to be more relevant to Kaapana then just wishlist.

Discussion from Tech meeting (Hanno, Klaus, Marco)

I was able to reproduce the error. I will take a look

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

check with microk8s - kata microk8s current system

Not sure if this is related:

Resolved, error was in the docker container

Issue in landing page tfda, base pods .

Sounds strange to me.
Is the error still there, if yes can you send me the instance, where this is happening? :)

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:)

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

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

Another issue I have regularly:

This could be an option.
We should still try to solve the multiple issues with CTP.
I'm not sure if there is a single source of failure - but I have a lot of trouble with it.

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

Missing tags in the Seg, so it is an error in the file.

This should be resolved.

This should be resolved.

@neher is there a connection to T28053 ?

Duplicate of T28291

@neher is this still an issue? I think we have all the SEGs working now, or?

At least the container should crash if this happens -> then it will be restarted.

Just had another of the out of memory issues:
-> Even with the new increased memory!

The fix was merged upstream and this task will be resolved with the merge of the current release branch this week.

Oh, it's even simpler. I see that in DCMQI it is only float. max_digits10 is 9 for float and according to the documentation its purpose is exactly for serializing and deserializing floating point numbers without losing any precision, even though the intermediate text representation may not be exact.

@floca When DICOM says 16 characters/bytes, does it include a trailing \0 character or is it really a fixed array of size 16?