We could protect the code from being formatted by surrounding the lines containing the symbolic names with

//clang-format off
Code here...
//clang-format on

Pushed new branch T22339-color-rainbow-sequence.

For the image test, the missing image geometry flag wasn't the actual problem. The problem is that mitk::Image::Initialize() has a parameter called flipped. As you changed a similar signature in the InitializeByStandardPlane() methods of a geometry, this bool flag was now passed as number of slices (false -> 0). I fixed it by making the Initialize() method deprecated and adding a new signature without the flag.

Pushed new branch T22254-Fixes.

These tests fail, as I see:
http://cdash.mitk.org/viewTest.php?onlyfailed&buildid=643361

Some other tests fail after the geometry changes on our dart clients. So it's not over yet. :)

Pushed new branch T22302-Fix_integration_branch.

Thank you, everything was successfully merged into the master branch and the release branch. I guess there are some PRs that need to be closed manually now?

My guess is that the minus sign has to be removed from line 750 and 773.

Sorry, forgot to add the line numbers:

Pushed new branch T22187-watershed-tool-multilabel.

The direction can be either way, as you can create left or right handed systems as well. If right handed, the direction is the same as the cross product of the righ and bottomvectors. If left-handed then the normal points in the opposite direction. You can create left-handed plande geometries by specifying negative thickness.

Which asserts?
Line 468 and 496 here?
https://phabricator.mitk.org/source/mitk/browse/T22254-GeometryFixesAsProposed/Modules/Core/test/mitkPlaneGeometryTest.cpp;4261ef7a44c7e44b4a7b38a9781533235a366293

@espak The asserts in the PlaneGeometryTests that fail are always because of the normal pointing in the opposite direction as expected by the test. In one example the frontside parameter when initializing the plane geometry is set to false and then its normal is checked against (-normal). Is it expected that the normals after your changes in these cases are flipped?

Just to let you know, I started working on the two tests above again after the holidays. The SlicedGeometry3DTest is done, the PlaneGeometryTest follows.

Pushed new branch T22337-remove-msvs-batch-files.

Pushed new branch T22302-Fix_missing_batch_plugin.

Can confirm on current release beta branch. the segmentation result is added as a regular image instead of a labelset image.

Pushed new branch T19726-update-multilabel-documentation.

Created a pull request for ACVD a month ago, but it wasn't integrated yet, so we should consider patching it instead. Anyways, known issue for the upcoming release.

We are not able to fix this for the upcoming release. This might be a fundamental issue and require major changes in the very basics.

Pushed new branch T22329-update-gui-elements-on-multilabel-start.

Works fine now with the current master also on Win7 64 bit.

I can not reproduce this on Windows 10 64 bit.

Pushed new branch T19933-Outline-of-segmentation-fix-rebase.

In T22076#90853, @goch wrote:

I will revisit this issue once T19933 has been merged to check what open issues remain and open a corresponding task.

Pushed new branch T19933-Outline-of-segmentation-fix.

The segmentation outline can now be turned off and on on the segmentation preference page. This option holds both for single and multi label segmentations.
But since the preference page does only work if the corresponding plugin is opened in the MITK workbench, the segmentation plugin (single label) has to be activated (not necessarilly focused / visible).

Fixed remaining compile errors in tests. We need to adapt the following two tests:

• mitkPlaneGeometryTest
• mitkSlicedGeometry3DTest

Turned out to be a configuration error of the wDB, do not use duplicate AETitles.

my OS is Ubuntu 16.04. Could this be the problem?

Retrieve works for me on ubuntu 15.04 as well.

Works fine, flag -fpermissive needs for DCMTK still

That's totally possible. The PlaneGeometry API was already a bit messy, and my commit made it worse by adding 'top' at the end. (Some functions had 'top' somewhere at the beginning already, not directly before the 'frontside' and 'rotated' args as usual.)

Had to fix a a wrong signature as the top parameter was present twice, but now it looks very promising in the first tests.

Pushed new branch T22076-AssortedLabelSetFixes.

Pushed new branch T22302-MatchPoint_move_properties_to_data_object.

I wrote out every resliced image (texture) while rotating the slice above the "magical" 7°. At this point, it is the first time that the slice/plane is long enough so that the texture needs to be one pixel higher than before. In general, this is as expected, as the texture needs to grow while the plane gets longer (with its maximum length when reaching from corner to corner at approx. 45°). However, the interpolation in these bigger textures is one pixel off, which is the actual error of the VTK reslicer. See the GIF below. An extra row of pixels is appearing at the top even though the image is basically the same:

This GIF compares the actual texture that is generated in the 2D image mapper against the rendered texture in the render window. It demonstrates the drift towards the bottom. As the images don't have the same aspect ratio (!), I scaled one of them to the width of the other one. In the render window snapshot, the last row of pixels is actually present but didn't fit into the GIF, so no image information is cut off in MITK. The drifting effect starts immediately when the slice is rotated more than ~7° and disappears immediately when within the same interval at around 180°. The drift is the same for all angles in between.

Thank you for the explanation, Miklos. I'll give it another try tomorrow, as I'm currently in the middle of another complicated bug. :-/

yeah, works for me too on Win7 64bit.

A bit of an explanation about the last commit:

I did just test it on the current master and it works for me on Windows 10 64 Bit.

When creating a surface out of the segmentation, it perfectly aligns with the outline. It really is the image texture, that is generated or mapped wrongly. To check for the latter case, I will try to write out the texture of the rendered image and compare it to the actual rendering.

Here one can see clearly that the drift increases from top to bottom and that it is really the outline, not the image.

Sorry, silly mistake. :-(

Having true synchronization would require more work than the resulting ease of use would be worth. The active label is set inside the labelset and has no connection to the node, which would require throwing events and listening to all changes of all labelsetimages and changing the color properties accordingly. On the other hand just synchronizing the color change for the active label and the color property can be done in the mapper (provided we only have one active label and do not intend to support multiple).
This however does not provide any benefit without the active label detection.

I think the problem is the vtkTransform in mitk::LabelSetImageVtkMapper2D::TransformActor() or something similar as the coordinates of the outline points seem to be correct, which is easy to verify, as they are in continuous index space and always without decimals. It looks like the transformation either has numerical issues or is applied in the wrong way, i.e., before a scale operation you have to make sure to translate to the origin first for uniform scaling. The image above could be explained by such a non-uniform scaling.

Pushed new branch T22088-disable-color-for-labelsetimages.

will take day or two to verify

It appears that the drift of the outline is larger at distant pixels (compare drift at top and bottom).

See also : T22183

@floca Any suggestions on how we should do it?