Pushed new branch T23988-cest-normalization-handle-zero-division.

Has been merged

Seems to have been solved with the switch to external directories in T23775: "ExtensionPoint" support for SuperBuild. External autoload modules are included in the installer.

I agree that the viewer has too many signals and selection capability for my understanding of a viewer.

@goyette I assume you meant to add this comment to T23248, T22929, T23985 or most likely T22065? I do not see a connection to this task?

On Ubuntu I need to add -fPIC to the CXX compiler flags in cmake to have a successful cotire based build. Otherwise I had the following error message

cc1plus: error: /MITK-build/Modules/QtWidgets/test/cotire/MitkQtWidgetsTestDriver_CXX_prefix.hxx.gch: created and used with different settings of -fpic [-Werror]

Pushed new branch T23756-cotire.

Pushed new branch T23920-fix-debug-leaks.

Pushed new branch T23922-unresolved-external-symbol.

Pushed new branch T23268-some-more-clang-fixes2.

Solved for now by checking whether the context is valid in mitkDICOMIOHelper.cpp, gives a warning instead of crashing if the context does not exist. This should solve the dashboard crashes, but will not guarantee all DICOMQI tags of interest are registered correctly. However they should work as well as before.

Pushed new branch T23810-MitkDICOMQIIO-crash.

Moving the this->AddDICOMTagsToService(); line from the constructor somewhere else removes the crash.

Call stack is

MitkDICOMReader.dll!us::GetModuleContext() Line 57	
MitkDICOMReader.dll!mitk::GetDicomTagsOfInterestService() Line 32	
MitkDICOMQIIO.dll!mitk::DICOMSegmentationIO::AddDICOMTagsToService() Line 59	
MitkDICOMQIIO.dll!mitk::DICOMSegmentationIO::DICOMSegmentationIO() Line 54	
MitkDICOMQIIO.dll!mitk::DICOMQIIOModulActivator::Load(us::ModuleContext * context) Line 50	
CppMicroServices.dll!us::Module::Start() Line 160	
CppMicroServices.dll!us::ModuleRegistry::Register(us::ModuleInfo * info) Line 129

Seems to be a lot of manual effort as well you have to extract all include paths (from e.g. the CMakeFiles/ModuleName.dir/flags.make). Call it on the source directory with these paths and manually integrate the suggestions offered.

I did just run include what you use on MitkCore and accepted the suggested changes. This results in a number of errors like

mitkPlaneGeometryDataToSurfaceFilter.cpp:111:22: error: unknown type name 'AbstractTransformGeometry'
mitkPlaneGeometryDataToSurfaceFilter.cpp:118:32: error: no member named 'GetPlane' in 'mitk::PlaneGeometry'
mitkCoreObjectFactory.cpp:194:27: error: no member named 'PlaneGeometryDataVtkMapper3D' in namespace 'mitk'; did you mean 'PlaneGeometryDataMapper2D'?
mitkCoreObjectFactory.cpp:80:7: error: deleting pointer to incomplete type 'mitk::LegacyFileReaderService' may cause undefined behavior
mitkOperationEvent.cpp:106:30: error: 'OperationEvent' does not refer to a value
mitkSurfaceToSurfaceFilter.cpp:75:23: error: member access into incomplete type 'OutputType' (aka 'mitk::Surface')
mitkRenderingManager.cpp:293:64: error: too many arguments to function call, expected single argument '_arg', have 2 arguments
error: "Do not include itkExceptionObject.h directly,  include itkMacro.h instead."

Pushed new branch T23268-some-more-clang-fixes.

Probably, the dicom folder read implementation was a bit cobbled together and could probably use some more thought.

I approve. Although the offending commit should be one of three
http://cdash.mitk.org/index.php?project=MITK&date=2017-11-15&display=project

Thanks for the info. Quoting from the link you posted above:

One current use case of error bars is in the CEST view:

Unfortunately not an option due to GPLv3 license
http://doc.qt.io/qt-5/qtmodules.html#gpl-licensed-addons

Basically but not quite. When queried for a time step it does not have it should return the closest time step. However there should not be an exception visible to the user in any case.

If the data node only has a const pointer to the data it only can return a const pointer to that data, but there are bound to be several places where algorithms want to edit the data in place and only have access to the node initially.

Do we need ICU for anything?

@hentsch can you verify the visualization is now as it should be?

Pushed new branch T23491-contour-visualizationi-crash.

Pushed new branch T23165-update-mitk-data.

If you take a look at rMITK543b4afe7f13: Use VisualStudio user files to automatically configure debug/release you can see that I indeed only added it to the MITK.vcxproj.user.in for 64 bit.

This was originally done in T19719: Automatically configure visual studio project to contain correct debug/release path

If I see it correctly you have not yet pushed that test data to rMD MITK-Data ?

I think you are right, that they are too specifically tailored to your use case to reasonably include in the as-is very general purpose segmentation plug-in. We might reconsider if we encounter those specfic use cases ourselves in the future and want an adapted segmentation for that. However we are grateful for you sharing your tool and making it available for others who might indeed have the same requirements.

Pushed new branch T23537-support-dicom-spacing.

To fix the crash and make sure that GetPen() has a chance of returning anything but a null pointer

diff --git a/Modules/ContourModel/Rendering/mitkContourModelGLMapper2DBase.cpp b/Modules/ContourModel/Rendering/mitkContourModelGLMapper2DBase.cpp
index df2fc88..5342b1c 100644
--- a/Modules/ContourModel/Rendering/mitkContourModelGLMapper2DBase.cpp
+++ b/Modules/ContourModel/Rendering/mitkContourModelGLMapper2DBase.cpp
@@ -64,6 +64,10 @@ void mitk::ContourModelGLMapper2DBase::ApplyColorAndOpacityProperties(mitk::Base
   // check for opacity prop and use it for rendering if it exists
   GetDataNode()->GetOpacity(rgba[3], renderer, "opacity");