Since you also mentioned different editors: Not sure if this is also related but one of the terminal outputs of the testers was:

I will go through the source tree and as a rule of thumb I will just add nullptr checks if the render window part is only used for rendering updates and add the OPEN strategy if more is done with the reference and there is not already a nullptr check.

I tested it in debug mode and the fix is pretty simple. The crashes occurs in lines like GetRenderWindowPart()->RequestUpdate() when GetRenderWindowPart() returns a nullptr. I guess there are quite a few unchecked lines like this in MITK.

I got the same result as kislinsk, the crash only occurs when the documentation is open and not in the background

When I reproduced the issue with MatchPoint, it didn't happen when the documentation was in the background (i.e. the documentation is not the active editor). I guess this is a good starting point for debugging.

With the modelfit inspector it most often crashed, if the user clicked on a datanode in the datastorage

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 like the idea of open sourcing the code and making models available as well. If we can roughly clarify how the workload/hurdles would look like in reality, I can also imagine to back the process. Licensing and publication of trained models arises more often lately, thus any solution here can probably also be fruitful for similar endeavors.

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

We are going to rewrite the 2-d LabelSetImage mapper and write a 3-d LabelSetImage mapper this year, where this will be addressed. We should at least clean up the duality of the contour properties (binary vs. labelset.contour). We should probably allow to show the contour without any filling and we should clean up the coupling between contours and active label.

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

@kleina can ou review the branch somewhen if the change is OK?

I just saw that the default option is already implemented. Then I would just remove it in the playground or explain that both ways are possible. Because otherwise people might think that they always have to do it.

@kleina Please check my comments and if nothing stands against it: 1) spawn a task to cover it. 2) cover it 😉 .

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.

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

It was by accident auto closed by a typo in the task ID of commit mentioned above. rMITK9d7992a7815d does fix T28255.

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

Interesting catch. There is no call to regex_match in our code. If I understand it correctly the stack object is just created to check if an exception happens during construction, but maybe this is just another variant of the issue described for the library. A possible workaround could be to explicitly create and destroy the regex objects in our code, with explicit exception catching and re-throwing.

Okay, nice. Last question: You currently have both a PhenotypingRelease and a ClassificationCmdApps configuration. The apps of the latter one are also included in the former configuration. Is it fine to just go for PhenotypingRelease then at the cost of a little larger tarball as also the workbench application is included? @schererj

@norajitr maybe a bit more background on the ticket for you:

I think the points are wrong ordered. First we should clarify (management decission) that it should go into a release/open-source and if tobi has the time to backing the process.
If this is cleare, the technical assesement of what has to be done to have it in master and under CI/testing can be evaluated/quantified.

I didn't really look into this but it reminds me of something I stumbled over a few weeks ago. There's a bug in C++ 14 regex regarding temporary strings: https://cplusplus.github.io/LWG/issue2329

Thanks for reporting. We recently rewrote the Python integration in MITK. Its status is at ~80% and it will get merged as soon as we figured out the packaging for Python in MITK (branch feature/T27923-python-dev). The QtPython module was removed as we do not longer depend on CTK/PythonQt for the Python integration.

I gave @schererj and @gaoh rights to start the Kaapana MITK build jobs and to read the configurations: https://ci.mitk.org/job/MITK/job/Kaapana/

I looked into it and I have the impression that there is a lot of unnecessary complexity created in order to generate a valid UI state. The problem, as far as I can see, lies in the overuse of if-statements and having functions that have way to many responsibilities. This is a typical "clean code" task and I suggest to go through the whole QmitkSegmentationView.cpp file and apply some best practices of writing clean code.
But since it is not clear how much effort we want to put into it (thinking of T28142), it might be wise to not work on this right now but to use a general refactoring task (parent task) to fix the mentioned bug.
I advise also to have a look https://phabricator.mitk.org/file/data/7bghshzurxwupnipv3dl/PHID-FILE-n2hwm6xv2mil3ola47sq/QtStateMachineFramework.pdf.

• FileConverter: Covered by regular release (see MITK Volume below)
• Phenotyping: https://www.mitk.org/download/kaapana/phenotyping/
• Radiomics: Covered by Phenotyping
• FlowBench: https://www.mitk.org/download/kaapana/flowbench/
• MITK Volume: https://www.mitk.org/download/kaapana/workbench/