Is most probably a Qt bug:
https://bugreports.qt.io/browse/QTBUG-69030
Should be fixed with Qt 5.12
The QtWebEngineView is full of bugs 😠

Pushed new branch T26024-FiberfoxMotionHoles.

@steint Can't reproduce it with the current master. Can you try it again?

part of T25785

This feature has to be implemented in MaskGenerator, where the functionality of adding multiple masks could be given.

The tests show unreliable errors.
Testing a few times in a row, sometimes the tests runs through without any problems, sometimes they fail.
Looking at the logs there are two tests that can fail.
-> TestRecomputeOnModifiedMask
-> TestImageMaskingEmpty
There is nothing written at the tests about failing any conditions, but they display an error called "unknown label"

I read through the logs after testing and the tests now fail completely when on of the conditions isn´t met.
I compared the testing logs with the master and noticed, that the fails existed before but the test didn´t notify accordingly.

I looked through MITK-Data for smaller images that could be used for the test.
Found some that seemed noteworthy:

I can setup a Horos instance (=OsiriX fork since free edition of osirix is limited and not userfriendly anymore) if needed. This can be done in the science network to avoid any firewall issues when trying to QR from a SIDT computer.

Pushed new branch T26011-UpdateTestingMacros.

This old macros could be the reason for T25716

Pushed new branch T26008-ChartWidget.

Pushed new branch T26003-StreamlineBadCast.

Looks like the Slicer warning is important, but still it succeeds in loading the data. The numerical error is rather low. Found this discussion which also links to the python code Slicer is using and which emits the warning. Could be of some use for further investigations. https://discourse.slicer.org/t/dicom-scalar-volume-load-irregular-geometry-warning-overly-stringent/3761/14

I guess there's something wrong with the original image matrix.
MITK tries to fix the normal to be perpendicular, which leads to a matrix that can't be inverted anymore.

In m_Pic3DImageMask2, only one label is used whereas 2 are used in m_Pic3DImageMask.
And the test is supposed to test the second label: ComputeStatisticsNew(m_Pic3DImage, imgMaskGen.GetPointer(), nullptr, 2);, where 2 is the label.

Is there a specific reason why the test TestPic3DImageMaskStatistics_label2 sets m_Pic3DImageMask instead of m_Pic3DImageMask2?

I have the issue again with other data data from a cooperation partner. Also Slicer has issues with the original DICOM data set:

Tested again on release mode, all tests work as intended

Hail to the new statistics plugin! One more reason why your epic effort was well invested 😄

Only the old statistics plugin was affected. In the new plugin, all is ok.

@hentsch So does that mean it was false alarm or do I missinterpret something?

I checked TestPic3DImageMaskStatistics_label2 and TestUS4DCylImageMaskStatistics_time1_label_2 via code changes (not possible via GUI). The values are consistent between test and GUI.
I can confirm that in TestUS4DCylAxialPlanarFigureMaskStatistics_time1 everything is the same too (see T24653)

Breaking down the tests to avoid a timeout I noticed that a lot of these test fail
Right now the only test I can confirm passing are the several TestCase-tests and TestUnitializedImage

Looking at the code I didn´t see the results of the GUI differing from the expected values of the test, maybe you looked at the wrong timestep because your GUI data matches with timestep 0.
Setting the US4D label1 is possible right now, but the GUI fails at label2.
But there are still results not matching up:
TestPic3DImageMaskStatistics_label2´s expected results and GUI data don´t add up.

Pushed new branch T25999-CmdParserTypes.

Pushed new branch T25998-compilationErrorsDiffusion.

Thank you for clarification! Indeed, this is an important remark! Seems that we checked on an outdated website for minimum compiler version before fixing this.

Pushed new branch T25989-displayingLineChart.

Pushed new branch T25975-newPlotlyVersion.

There's already a property for this: labelset.contour.width.

still relevant. Very annoying is the bug that contours are not visible in each slice

Just as a remark (but I think an important one).

Pushed new branch T25979-FixImageStatisticsContainerCompilerError.

Pushed new branch T25977-Shortcuts-for-multilabel-segmentation.

after discussion with @kislinsk
Is ok in Plugins directory

Pushed new branch T25873-themeChange.