Pushed new branch T26107-MoveMITKDiffusionToSeparateRepo.

Regarding the segmentation data type the PolySeg project should be kept in mind as it offers flexibility in the representation of the segments.
They also define a segmentation and a segment class although neither of them directy "is" the data. A segment keeps a list of representations (i.e. vtkDataObjects in their case) that actually hold the image / surface / contour data.
Making the segment directy inherit from Image creates a strong bond to the representation as labelmask (binary or fractional) but leaves out representation of contours and surfaces for example.
In this regard one proposal would roughly follow this class layout:

Pushed new branch T26413-Nifti2-Diffusion.

Pushed new branch T26453-CMakeGeneratorPlatform.

If we think about establishing a new Git Workflow, we might rethink this. It might be useful to have some mainline that only consists of squashed commits so each feature is represented by a single entry. However, the current scenario does neither force one or the other way to do it so we have both merge- and squash commits which makes it a bit arbitrary, in my opinion.

merge --no-ff is now the default of arc land. It's equal to using arc land --merge.

Pushed new branch T26452-DoNotSquash.

Built Mesa. Same result. Mesa keeps reporting OpenGL 3.1 with GLSL 1.40. If we figure out how to squeeze the correct OpenGL context out of Mesa, it could be the breakthough.

Here are the DLLs we used for the BlackSwan demo.

This issue can be solved by copying the following DLLs to the exe path of the workbench:

According to https://mesamatrix.net/, Mesa (llvmpipe) should be able to 100% support OpenGL 3.3 with GLSL 3.30 and hence OpenGL 3.2 with GLSL 1.50. Next test: build Mesa by myself.

I did the same for the Qt contextinfo example. When creating a 2.1 context Mesa is reporting:

Wrote my own minimal Qt application with QVTKOpenGLNativeWidget and it basially has the same problems.

Sorry for jumping in late. I'm afraid currently we are anyway not testing any encoding stuff sufficiently.

Was resolved with T19683.

Please check this: T25535
@kislinsk: What changed your mind?

Pushed new branch T25424-FindPython3New.

Pushed new branch T26438-DisableIcu.

Pushed new branch T26437-CMake-3.14.

Cherry-picked into releases/2018-04. Peter's fixes do not affect code available there.