Use this project to tag tasks and other stuff that should be discussed in the weekly MITK meeting.
Sat, Jan 23
Deleted branch from rMITK MITK: feature/T27992-CmdLineAppsInWorkbenchReleaseConfig.
Pushed new branch to rMITK MITK: feature/T27992-CmdLineAppsInWorkbenchReleaseConfig.
I asked in the general Slack channel for command-line apps in use. It boils down to the file converters in CoreCmdApps. Other mentions are too specific for the WorkbenchRelease configuration and are related to the Classification module. We should consider adding a phenotyping build configuration, though.
Thu, Jan 21
@kislinsk anyone from the MITK CI team who could take over?
Wed, Jan 20
@floca I might have found a dataset, where even the new number is not enough:
Sure. Could you point me to the nightly installers again?
Tue, Jan 19
@floca thanks for the report! I added a comment to the dcmqi issue you created.
Changes have landed . @neher could you test again using a nightly build?
Just submitted a Differential
OK, then increasing the DCMQI version to 1.2.3 before our next release seems to be the most sensible fix, doen't it?
Mon, Jan 18
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.
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 may drift away 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.
Is your statement also valid for 5e-5? Beause 1e-5 would not be enough in that case.
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 the purpose of geometries.
Sun, Jan 17
The problem seems to be that DCMQI rounds the the orientation matrix values at the 5th decimal place when storing to DCM Seg.
Fri, Jan 15
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.
Thu, Jan 14
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 a a few possibilities to provide credentials if that's an issue. See here for examples: https://phabricator.mitk.org/T27960#214043
Mon, Jan 11
Ok. Found the problem. Should now be fixed with the new diff. At least it works on my PC now with the test files.
I set the GIT_TAG of DCMQI locally to v1.2.3 and I can confirm that the data from above can be loaded.