Hi there! 🙂

@kislinsk Do you have any opinion regarding this issue ?

Pushed new branch T26150-MergeAgainWithCherryPicks.

Pushed new branch T26157-FixMacOSInstaller.

Okay, all the Qt-related startup errors are fixed. But, on some PCs there is still the following one-time error even without --BlueBerry.clean:

• Fall back to classic versioning if MITK_REVISION_DESC is not set (I guess when building MITK from the source tarball)...

Pushed new branch T26152-PreciseVersioning.

Uh, I'm carefully optimistic that this really fixed the start of the MitkWorkbench. :-) Will test on Monday at another Ubuntu machine that has/had the Qt version mismatch error.

There's more going on on a clean Ubuntu 18.04 VM with GCC and starting MitkWorkbench for the first time. Basically no plugin is able to start because of broken linkage to libQt5Svg. That's probably a hot candidate for the version mismatch error on systems with a system version of that lib.

Pushed new branch T26150-UbuntuGCCWorkbenchStart.

Pushed new branch T26100-FixOrderOfVariables.

Thank you! 👍🏻

Added a simple check for the dimension. I will have to take a closer look at the 4D (maybe 2D) support in the next weeks unless there are volunteers who can take more care of it.

Pushed new branch T25798-FixDICOMSegWriterConfidenceLevelCheck.

TODO: Paths in MITK_EXTENSION_DIRS should be in canonical form, i.e., a backslash crashes the plugin list parsing of CTK which we are using.

Merged into master but not yet into releases/2018-04 until it was tested more thoroughly with Diffusion.

Looks promising, I completely moved all Diffusion code into a seperate directory and built the DiffusionRelease configuration. Double checking with @neher next week, testing Linux, macOS, and installers.

Status update: currently testing with MITK Diffusion as extension.

Pushed new branch T26100-ApplicationExtensions.

Pushed new branch T26099-BuildConfigurationExtensions.

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 as soon as I activate the Fill tool. I added a check to BaseRenderer::GetTimeStep(mitk::BaseData) to trigger a breakpoint when the timestep is > 100. 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:

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?

If you load a DICOM image and create a segmentation based on that, you could write a DICOM Seg. For that case, the writer works for me.
Unfortunately not for 4d images and I will report a task for that. T25801

Pushed new branch T25798-DICOMSegWriterConfidenceLevelCheck.

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?

Ok. Is this for the bugfix release? When is the 'deadline' for this?
Still I don't think that's the best way. Maybe we could rank the writer lower or something similar, so that people, who know when they can write DICOM SEGs, could use the writer. I will have a look at the GetWriterConfidenceLevel() checks asap.

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.

Sorry, I missed this task. Maybe we should add a condition to the confidence level check and do not return unsupported in general. I think at the moment most checks are done IN the writer and not before. What was the actual problem?

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.

When I close the segmentation view before I remove the files from the Data Manager, the workstation does not crash

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...

Unfortunately I'm still not able to reproduce. Maybe you can come over and show me your steps personally. :-)