Compensated for 2. Text was revised in T27677.

https://phabricator.mitk.org/D443

I can confirm this fixes the issue, I can merge it tomorrow

I would consider three different variants:

1. Keep CTP as receiver -> move the dcmsend from ctp-pipeline to airflow (unknown end of transfer issue)
2. Keep CTP as receiver and change the DICOMweb send pipline-step to the old DIMSE step (possible issue with missing slices <-> really fast)
3. Don't use CTP at all -> Start a DICOM receiver in Airflow as a sensor and trigger DAGs at arrival (performance unknown)

Pushed new branch T28017-VTK9-CodeIssues.

In T27573 we discussed the problem of data transfer from CTP to DCM4CHE.
So basically it is a kind of similar problem: A datatransfer between CTP and DCM4CHE fails.
The problem is then, CTP just keeps the data in the queue (here) or inserts in the quarantine folder (T27573).
Anyway, we do not get notified, that there is a problem.

It sounds nice, but I also think that we can run into cumbersome situations w.r.t. package management and version control with this approach: If the web app is located within the package, for each change to the package itself, it has to be investigated how the change affects the web app. The developer also has to adapt and test the web app then. This also means that for each package release, a corresponding web app has to be provided. In my opinion it makes more sense to focus either on the package or the web app during the development. Probably, we want to improve the web app that is based on a fixed package version x most frequently. This use case is then hampered by this approach as the package itself also evolves.

Pushed new branch T28017-VTK9.

After reading the itk::NumericTraits documentation and looking into the actual definitions of ZeroValue() I guess the fix could be:

TARGET_DEPENDS parameters are directly passed to target_link_libraries() and bypass the PACKAGE_DEPENDS mechanism.

Public API change: Depending on VTK does not add a transitive dependency to Qt5 Widgets anymore, except, when the required VTK components have a public dependency to Qt5 Widgets of course.

Fixed VTK and TinyXML-2 so far.

Pushed new branch bugfix/T28002-ImprovePackageDependsFiles.

Holy moly, I just learned that the package depends files work completely different than I thought/was told the past 9 years. Instead of fixing the mitk_use_modules() function we just need to use the package depends files correctly.

So for the current develop:
With or without CGET activated. When trying to Retrieve a dataset after Query, I get an Exception:

• mitk_create_module() passes PACKAGE_DEPENDS to _mitk_parse_package_args()
  • The PACKAGE[|COMPONENT1[+COMPONENT2]...] syntax is processed and the following variables are set in parent scope:
    • <PUBLIC|PRIVATE|INTERFACE>_PACKAGE_NAMES: Lists of package names for different visibilities
    • PACKAGE_NAMES: Joined lists from above (may contain duplicates!)
    • <PUBLIC|PRIVATE|INTERFACE>_<PACKAGE>_REQUIRED_COMPONENTS: Lists of components for different visibilities and packages
• mitk_create_module() passes PACKAGE_NAMES to mitk_check_module_dependencies()
  • mitk_check_module_dependencies() passes PACKAGE_NAMES to _mitk_parse_package_args()
    • Notice that PACKAGE_NAMES does not contain visibilities anymore, so everything is put into PRIVATE_PACKAGE_NAMES by default
  • Nevertheless, all visibility lists are joined into package_names and duplicates are removed (why not just use PACKAGE_NAMES in the first place and remove duplicates?)
  • For each package, check if MITK_USE_<package> is not set and add package to _MISSING_DEP in parent scope together with missing modules
• Also: Duplicates in PACKAGE_NAMES were removed by mitk_check_module_dependencies()
• The module is disabled if there are any missing dependencies
• PACKAGE_DEPENDS is passed to mitk_use_modules() as PACKAGES parameter

@jsolislemus There's a workaround if you can't wait for the next release which would also verify if your issue is fixed:

@thomass could you check if the problem was realy just cuased by slow network drive and is solved. If this is the case, could you close the task? If the problem still exists, may be the issue solved by Stefan is a solution.

@gaoh could you check if the problem is solved either with the branch or as soon as it is in develop?

I would see it positiv. No sense crying over spilt milk. Thanks for solving that problem!

apparently a vtkLoopUpTable is set automatically so the property as such cannot be used to handle custom vtkLookUpTables

Hi, from what I've been reading, it seems this issue might be fixed? I read on T26264 that it might be fixed with a CMake variables related to the DCMTK dictionaries; although I'm not sure how could I implement it myself, while waiting for the next release (we're still developing on top of 2018.04.2). Thanks a lot for the effort, this error seemed very difficult to pinpoint.

Mixed feelings here: On one hand I'm happy that we, with a single trivial line of CMake code, finally fixed a decade old severe issue we had in MITK without really noticing it causing quite some inconvenience for our users and we were not able to reproduce it over the years. Maybe we even lost some users right before they actually used MITK because "it cannot open my DICOM files". On the other hand, we fixed a decade old severe issue with a single line of CMake code.

I think the only reason that they are not part of the release installers is simply that they are not enabled in the WorkbenchRelease build configuration. The actual todo is to specify what CLI apps we want to include I guess.

🤞

Changes in header files: git diff -U0 ff0027ee 8e328dab *.h > output.txt

Let's see if the Nightly installers tomorrow morning are able to load Sarah's DICOM files. 🤞

Deleted branch bugfix/T26164-AlwaysUseDCMTKBuiltInDICOMDictionaries.

Pushed new branch bugfix/T26164-AlwaysUseDCMTKBuiltInDICOMDictionaries.

Everything you need to know about the DICOM dictionaries and how DCMTK is handling them is described here: https://github.com/InsightSoftwareConsortium/DCMTK/blob/master/dcmdata/docs/datadict.txt

Verified on macOS. I downloaded the dictionary and exported DCMDICTPATH. The MITK Workbench was able to load the DICOM files correctly afterwards. 🎉

I made the variable thread-safe by making it an atomic.

Deleted branch bugfix/T28001-FixRESTClientTest.

Pushed new branch bugfix/T28001-FixRESTClientTest.

Deleted branch bugfix/T27999-RemovePhotoacoustics.

Pushed new branch bugfix/T27999-RemovePhotoacoustics.