@kislinsk : I just noticed we had some earlier discussions and there is a branch which fixes two minor issues, not sure if relevant for option (1):

This is resolved, dart client is running on my workstation

Clang 10 on Linux configuration is running now nightly on my desktop machine. "WorkbenchRelease" is green, "All" unfortunately hits an internal clang error [1][2]. Setting this up on ubuntu would probably solve this, or some update on fedora.

http://gdcm.sourceforge.net/wiki/index.php/Color_Space_Transformations

Just checked GDCM 3.0.7 if by chance the issue was fixed there, unfortunately not.

@jsolislemus Sorry for the long delay, I kind of missed your comment and related discussions happened in T27669

@schererj we just discussed this in the MITK meeting. Could you try something? It would be interesting to compare the outputs of

Since we have this task now I suggest to deactivate them "somewhere globally" and discuss later how to proceed. My guess would be it is quite some effort. Having tests for the generator, packging and the extension mechanism is very important I think, but I'm not sure what the current tests cover and if it's worth to fix.

I'm setting up a clang 10 dart client right now. If that is submitting successfully I would close the task

Added FS-E IT since this is coming from DKFZ radiology

soon'ish == 2 weeks ;)

@norajitr We discussed this today in the MITK 2020 meeting and it stays on the high priority list, no promises regarding a date for a fix but at least some investigation of the underlying cause should happen soon'ish

I am re-opening this since I think this will also become more relevant with the foreseeable use of other REST APIs from MITK , e.g. how did the nvidia segmentation tool resolve this issue for the windows installer? @kislinsk could you comment?

@floca : thanks. Not the whole trick but helped a lot. I will follow up with more geometry questions later ;)

I put a _non-shareable_ dataset in /ad/fs/E132-Projekte/Share/MarcoToMitkTeam .

Sorry, did not see your claim, was already working on it. Proposed fix in D308

Pushed new branch feature/T27438-fix-gcc10-errors.

I changed the superbuild to use ITK 5 with compatibilty and fixed some straightforward issues. This branch can be used for further investigations @floca : some ideas about the geometry issues would be very helpful. The migration guide has an overview on the topic but my experience in that area is limited

Pushed new branch feature/T27437-migrate-to-ITK-5.

Seems the reason this passes on all official clients is Debug vs Release. We currently only test release which ignores asserts. Thus, this should be investigated properly by tracing the problem, Windows and Linux are both affected

I got some data now which shows a problem with MITK 2018.4 but works with the current master. I don't see though the RWV thing. Can't remember exactly how I investigated this back then. Let's hope the more robust handling of DICOM fixed this as @floca noted , I informed the reporting users that they should comment if this should be investigated again.

I'm currently trying to get access to the relevant data again.

Does the MITK team have access rights on the NAKO dataset? Then I would suggest an example from there.

Tests don't fail anymore

@norajitr or someone else: is there an example image in MITK Data to show this behavior?
@norajitr do you know when this stopped working?

Ok, on fedora there is a newer xvfb version which includes a new option for a more robust choice of a suitable display number which seems to fix the issue for me.

Diffusion still shows this:

Strong agree on dicombrowser and avoiding the term editor ...

Probably not relevant anymore and VS2013 is not supported anymore

Test finished successfully after 2h11min ... Still room for optimitzation but this task is resolved ;)

In T27177#196477, @thomass wrote:

As stated before, we encountered more examples that raised the unknown exception, so I don’t agree to lower the priority on that.

In T27289#197725, @j762e wrote:

But I think the reason for the different results might be that opencppcoverage does not use any testfiles and cannot load pictures because it cannot find these and there is no option to pass them to opencppcoverage.

If I look at the outputs side by side there is e.g. a difference in the SetSecondaryMask method: it's called 24 times in the CDash run but in the OpenCppCoverage it's red. Which tests did you execute? I think if I remember correctly the numbers in the CTest/CDash result are aggregated over all tests in the default config. Could this make the difference?

This was reported as relevant for medical expert segmentation work

We discussed this in the MITK meeting today and identified two possible reasons.

Nice work! I ran into this as well just a few hours ago and thought it would be nice to evaluate alternative Qt platform options for tests ;)

The modality of the referenced image is a so-called Enhanced CT Image originating from a 3D C-Arm. It is a current limitation of dcmqi to handle these multiframe series as input, see https://github.com/QIICR/dcmqi/issues/217 . It's not an easy fix in dcmqi and we already discussed with the developers. For now I think we have to keep this in our backlog.

@thomass Which version did you test this with?

Pushed new branch T24402-clang-format-improvements.

Pushed new branch T27084-fix-plugin-generator-tests.

Just tested this, works for me. If this is still an issue please re-open.