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

Pushed new branch T25944-UpgradePocoToVersion1.9.

These are the details of the time geometry of 3D+t-Heart. The 103 seems to come from the time bounds at the bottom:

The actual error is happening sooner. I added a check to BaseRenderer::GetTimeStep(mitk::BaseData) to trigger when the timestep is > 100, which triggers even before I start to fill. Eventually TimeGeometry::TimePointToTimeStep() is called on the data and the time point is already 103. The time point is calculated in BaseRenderer::GetTime() by calling TimeStepToTimePoint() on the world geometry of the renderer.

Sometimes I have to change the timesteps multiple times to run into this error. The message differs a little bit, though:

@floca I think I remember you worked on theme-specific warning colors at the last hacking week. Can you give us a hint how to use it, please? :-)

Wohoo, nice surprise, 3D+t is already working, I totally forgot that I fixed it before Christmas when I focussed on the race condition thingy. I'll create a new installer and if it works for you, @full, I'll merge it into the release branch.

I am able now to create surfaces either smoothed or not (only 3D now, though) but the former case seemed to work only on a single PC. I found the reason. QmitkCreatePolygonModelAction once was copied from the segmentation plugin to the multilabel plugin and for a certain time, the actions appeared twice in the context menu as both plugin.xml files added the context menu entries. This was then fixed so that only the segmentation plugin adds the actions as it should also work without the multilabel plugin. However, I just noted that there's a race condition as still both plugin activators register their classes with the same class name. So the eventual implementation that is chosen is totally up to a race condition.

Ah, nice, I see. Testing 3d images was obviously too obvious for me. :D If the 4d case isn't fixed until the bugfix release, we could also check for the dimensionality to decide if the writer supports the image, right?

Almost forgot: Deadline for the first bugfix release is probably middle of January.

Yeah, one could lower the confidence level, but it still would expose a broken writer to the user, so I see no reason to enable it until it is fixed. or do I miss something? How could someone suddenly write DICOM SEGs?

The problem is that the writer currently isn't able to write anything (at least I was not able to find something that might work). AFAIR, Marco updated DCMQI a few months ago to at least prevent the writer from crashing, which doesn't happen anymore, but the update didn't intent to completely fix the writer.

Pushed new branch T25799-MakeSegmentationToSurfaceConversionTruelyMultilabelAware.

Pushed new branch T25798-DeactivateDICOMSEGWriter.

When saving nodes manually, the path property is now set to the saved file name. Consecutive saves then default to the same directory.

Actually I think this could be further improved in case of saving a node without a path property that is derived from another node.

Pushed new branch T25791-ImproveSelectionOfInitialDirectoryInOpenAndSaveFileDialogs.

Tool GUIs work as well now. Merged into releases/2018-04. I documented the feature in the example tool of the project template and wrote the Nvidia guys.

I created a branch with the same name in rMPT MITK-ProjectTemplate. It provides an example segmentation tool with a styled icon and a custom state machine. It does not yet come with a tool GUI, which I will add tomorrow.

• Theme-adaptive SVG icons are now supported as tool icons
• Tool state machines external to the MitkSegmentation module are now supported

Pushed new branch T25784-ExtensibleToolSelectionBox.

Here's the solution: We extend the segmentation views to also add all tools to the appropriate category by regex-matching their class name to either SegTool2D$ or SegTool3D$ (for example, their class name ends in either SegTool2D or SegTool3D like MyAwesomeSegTool2D).

Can you please try to crash it again at your workstation, but this time close the segmentation view before you delete the nodes.

Guess what, cannot reproduce this... :/

Also cannot reproduce it with Ubuntu 16.04.

Peter showed me the bug at his workplace. I cannot reproduce it with Windows. Trying to crash it with Ubuntu as well...