PS: Chrome upload works but data doesn't show up in meta

I don't see that 1. is an issue. Further improvements were done in the scope of T27996 and T27420.

Unclaime as I currently have no time to work on it. Will take on it again, if I have time or some else;)

It basically seems as if some m_FastMarchingFilter->Modified(); or similar is missing, after the seed points have been removed (to trigger the new green preview segmentation, which would be empty without seed points).

So I looked into it and the function behind the clear button actually is called OnClearSeeds so I was wondering what the expected result should be

1. remove the seed point(s) but leave the green preview segmentation
2. remove the seed point(s) and the green preview segmentation to start all over again

As it is a public API change I suggest that you tag this task with Noteworthy and write a line about the breaking change or in case it is not trivial a short migration guide.

So I tested it with Orthanc (without CGET only):
With 2018.04.2 retrieve works. With the current develop branch MITK crashes with the same exception:

Also to discuss with Jonas and Klaus that Anything can be reused from JIP?

You mean more explicit control? I would guess that we also have control about which version of CTP and its configuration we use.

We just use the default CTP stages for DIMSE-send etc. - currently we don't have any influence on the binaries / parameters used. (And have no idea if things go wrong)

Thanks for the answers!

Deleted branch bugfix/T26449-XNAT-OpenSSL.

This also happens for the rotation mode. The proposed changes fix both.

Pushed new branch bugfix/T26449-XNAT-OpenSSL.

It is not acceptable that there is a hidden manual process involved. There's legacy code in the XNAT plugin's CMakeLists.txt that tries to do that automatically but fails as it copies/installs the wrong files. To make the whole thing more visible, I will add the following two CMake cache variables to set the two DLLs. Manual copying and installing shouldn't be neccessary anymore then.

All experimental CI clients succeeded. Merged into develop.

Deleted branch feature/T27383-UpdateExternalToolkits.

Poco 1.10.1 isn't a trivial update. It's known that Poco messes around with all the defines of Windows.h and there's a compiler definition POCO_NO_UNWINDOWS to control it that we use. However, something changed in Poco and all kinds of compiler and linker errors pop up even in unrelated modules and plugins as header declarations and implementations may differ, or method names are suddenly masked by definitions. It's hard to narrow it down as we seem to use a mix of both modes. So I call it a night for this task with all the updates mentioned above. Everything else is probably worth own dedicated tasks if necessary. The next big update we should focus on is ITK, though.

No, the data has not been sent before.
There were only completely different images already stored.
Also OHIF was not showing any of the new sent data at all.

Have you checked, if the dataset (or the slices) are already in the PACs. In my case (I got the error, when sending data from airflow to the PACs), the files creating the 409 were already in DCM4CHE.

Regarding 1: This is done to ensure that you are notfied if a problem arrises in the dcmsend step?

Yes, exactly and we have full control over the binary and parameters used for the data-transfer (eg storescu, dcmsend or DICOMweb-send etc.)

Got similar issues with a "normal" data import.
So I just sent a couple images and got many of the following errors in CTP:

Oh sorry, I thought it was clear, because the title is wDB related:
I used the wDB. I did not test it with a different PACs system, but I can try and report back...

Our current version of ITK does not compile with OpenCV 3.4.12.

@gaoh Could you please specify which PACs you used to provoke the error. Or did it have this problem with multiple systems?

Eigen update to v3.3.8 does not work. We have to wait for v3.3.9 which is going to be released in the next few days, according to https://gitlab.com/libeigen/eigen/-/issues/2011.

Pushed new branch feature/T27383-UpdateExternalToolkits.

I close this task as it is very likely fixed in T26164: DICOM Query/Retrieve doesn't work at least in Ubuntu release installers. Please re-open if it is not the case for you by using the workaround or building the latest develop version . :-)

Fixed in T26164: DICOM Query/Retrieve doesn't work at least in Ubuntu release installers.

@nolden FYI: you can (auto-)link tasks and Differentials by either

Deleted branch bugfix/T28002-ImprovePackageDependsFiles.

• Regarding 1: This is done to ensure that you are notfied if a problem arrises in the dcmsend step?
• Regarding 2: Do we have a test to verify if the problem still exists before we go into production with this? @gaoh: Was this a problem on the CTP side or on the DICOM4CHE side? So, did also other PACS like orthanc had the same problem?
• Regarding 3: This road I would only go, if we also have a test suite ready to benchmark the performance and to ensure that we don't have the same problem problem. What kind of reciever would you use here.

PACKAGE_DEPENDS now properly supports Boost, OpenMesh, OpenMP, OpenSSL, and Python3. For example: