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/

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

In T28302#220479, @gaoh wrote:

The normal WorkbenchRelease configuration should be even better suited for the future...

+1

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?

Okay. Currently running the first test with the PhenotypingRelease configuration and tag set to v2021.02. So the file name will be automatically versioned and will appear at https://www.mitk.org/download/kaapana/phenotyping/ once the build succeeds.

I would like to have files versioned / with different names. If it's necessary to have a download link that doesn't change I can help with a script to create a "latest" link, had that for MITK nightlies back in the days

To all: Do you want to version files or do you want to simply override existing old installers when generating new ones (which happens with custom set revisions descriptions as done in a few docker files above)?

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 T28311#220415, @gaoh wrote:

would be to give it the name of the Instance UID.

Understood, but thats not that easy yet, as the Instance UID is currently generated by DCMQI in the writing process. But that is something we should alter somewhen anyways, as we already need this UID within MITK.
So I guess we take one of the other choices as mitigation strategy.

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.

It is the "\" in the node name.

Nvidia AIAA WorkbenchRelease binaries are building or were already deployed.

It seems as if datanode->GetBoolProperty("binary", binary, renderer) inside mitkImageVtkMapper2D always results in binary being false. This might be true for our LabelSet images, but the properties view still shows the property binary as true, e.g. for segmentations created with the classic segmentation view.

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

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?

Deleted branch from rMPT MITK-ProjectTemplate: release/T28000-v2021.02.

Pushed new branch to rMPT MITK-ProjectTemplate: release/T28000-v2021.02.

Deleted branch from rMPT MITK-ProjectTemplate: release/T28000-v2021.01.

Deleted branch from rMITK MITK: bugfix/T28000-BumpDevelVersion.

Pushed new branch to rMITK MITK: bugfix/T28000-BumpDevelVersion.

Deleted branch from rMITK MITK: bugfix/T28000-BumpDevelVersion.

Deleted branch from rMITK MITK: release/T28000-v2021.02.

Pushed new branch to rMITK MITK: bugfix/T28000-BumpDevelVersion.