In T28127#217365, @kislinsk wrote:

It depends. NODE_PREDICATE_GEOMETRY_DEFAULT_CHECK_PRECISION is only for checking in predicates;

As long as nobody has missused it so far, it is just used for that. ;) At least I have introduced it with this purpose and only used it there.

Pushed new branch T28017-VTK9-CodeIssues2.

Deleted branch from rMPT MITK-ProjectTemplate: bugfix/T28171-MigrateToCurrentMITKDevelopBranch.

Pushed new branch to rMPT MITK-ProjectTemplate: bugfix/T28171-MigrateToCurrentMITKDevelopBranch.

Deleted branch from rMPT MITK-ProjectTemplate: bugfix/T28170-TestHooks.

Pushed new branch to rMPT MITK-ProjectTemplate: bugfix/T28170-TestHooks.

Deleted branch from rMPT MITK-ProjectTemplate: bugfix/T28170-TestHooks.

Pushed new branch to rMPT MITK-ProjectTemplate: bugfix/T28170-TestHooks.

Deleted branch from rMPT MITK-ProjectTemplate: bugfix/T28170-TestHooks.

It depends. NODE_PREDICATE_GEOMETRY_DEFAULT_CHECK_PRECISION is only for checking in predicates; not for constant use throughout MITK while are there calculations after calculations after calculations and so the values would drift away further from the actual truth, right? So for a temporary fix, I'm okay. But we should definitely check what is going on in DCMQI and fix on that side preferably.

In T28127#217306, @kislinsk wrote:

1e-5 should still be conservative enough for the purpose of geometries.

Is your statement also valid for 5e-5? Beause 1e-5 would not be enough in that case.

Deleted branch bugfix/T28164-CopyrightDate.

Pushed new branch bugfix/T28164-CopyrightDate.

Thanks for looking into this issue as well. :-) I think 1e-5 is okay. We/you already introduced NODE_PREDICATE_GEOMETRY_DEFAULT_CHECK_PRECISION not long ago since we had similar issues and 1e-5 should still be conservative enough for the purpose of geometries.

The problem seems to be that DCMQI rounds the the orientation matrix values at the 5th decimal place when storing to DCM Seg.

Pushed new branch feature/T28118-Refactor_SegTool2D_and_derived_classes.

I understand. :-) Just wanted to give you more options to think about as it is probably only a temporal solution. Sooner or later (currently read "later"), our minimum version requirements won't match again with the OS-provided Qt version. So we cannot run away from it forever I guess. :D

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.

Thank. New command-line interface looks nice, but the challenge is where to put the credentials, especially if you want to put the script open source like in the Kaapana dockerfiles.

As it already works (?) and we will stay at least another year with Qt 5 we can do this. But in general, do you know of the new Qt Installer Framework with command-line interface? It's much easier now to install Qt with a single command and there are a few possibilities to provide credentials if that's an issue. See here for examples: https://phabricator.mitk.org/T27960#214043

Fiber mapper issue: https://vtk.org/doc/nightly/html/classvtkOpenGLPolyDataMapper.html#a80cc4bf99b408c63cad0a59c0388ffae

Deleted branch feature/T28155-MakeQtLogMessagesOptional.

Pushed new branch feature/T28155-MakeQtLogMessagesOptional.

Since we need to patch VTK anyway, I took the opportunity to upgrade from VTK 9.0.0 to 9.0.1.

Deleted branch bugfix/T28151-FixVTKOnMacOSXCode12.

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

Pushed new branch bugfix/T28151-FixVTKOnMacOSXCode12.

Deleted branch bugfix/T27717-FixMacOSInstallerOpenApp.

Pushed new branch bugfix/T27717-FixMacOSInstallerOpenApp.

It works when any argument is passed to the workbench via the open command, e.g., open MitkWorkbench.app --args --BlueBerry.newInstance. My first guess that the additions in rMITKf54a83e2 cannot handle 0 arguments when the implicit -psn argument is sneaked into argv by macOS.

Ok. Found the problem. Should now be fixed with the new diff. At least it works on my PC now with the test files.

Was removed in rMITK66bb0d67 and forgotten to get restored in rMITK02a46548.

Deleted branch bugfix/T28137-FixMissingContextMenuEntries.

Pushed new branch bugfix/T28137-FixMissingContextMenuEntries.

Thanks @kalali, nice find and hint. A sneaky line is missing in DataManager's plugin.xml: <extension-point id="contextMenuActions" name="Context menu actions"/>.