My previous reasoning fails on the fact that the coronal (aka. frontal) renderer has a left-handed coordinate system at the moment, while the sagittal and axial ones are right-handed.

Closing this. The original intention with the flipped normal direction was probably to keep the handedness. To have the image rendered with eyes up in the render window, the sagittal axis has to be flipped. However, flipping only one axis changes the handedness.

I created separate tickets to save some commits from the PR:

PR sent:
https://github.com/MITK/MITK/pull/151

PR sent:

This bug report was based on the assumption that mitk::PlaneGeometry objects are actual 2D planes with 0 'thickness'. However, as I see now, plane geometries are created with 1 voxel thickness everywhere.

I re-run the unit tests, all of them still pass with the patch on MITK-Data above. (What also means that the unit tests do not cover checking the upper bounds, actually.)

I have updated the PR with one more fix for mitk::DataStorage::ComputeBoundingBox(). The spacings were mixed up that led to incorrect upper bound values with images with anisotropic voxels.

Thinking more about the perfectly correct solution would be to use the same direction for each orientation, as in the reference geometry.

I have a view that contains a viewer based on QmitkStdMultiWidget. The view has to show the contents of the focused render window of the main display but from a different orientation.

https://github.com/MITK/MITK/pull/149

Thanks for discussing this.

I sent a new pull request after the code style changes in MITK.

Pull request:

Putting the origin in the front flips the image upside down in the axial window. The other coordinate could be put to the bottom, though, so that the axial slices are counted from bottom to top, at least. This would not change the visualisation. (Bottom-Left-Front)

I close this because I found that the geometry I created was wrong.

Here are the new reference data files for mitkSurfaceVtkMapper2D3DTest, mitkTextOverlay3DRendering3DTest_ball and mitkTextOverlay3DColorRenderingTest_ball, respectively:

I found that these four tests pass if I comment out line 221 in mitkSlicedGeometry3D.cpp:

These four unit tests still fail, everything else passes.

New pull request sent:

I just updated the pull request with two new commits.

https://github.com/MITK/MITK/pull/144

Weird. I did it yesterday and force pushed the branch.

The change disables the assertions in GDCM for debug builds on Mac.

A similar problem has been reported on the mailing list.

On Linux I get this error when trying to run MitkWorkbench from the current master:

A similar problem has been reported on the mailing list.

Same with 10.10.

I tried Linux just now. I randomly picked a few of the tests and they all passed.

@kolbch

I fixed a few unit tests, but some are still broken:

Several other unit tests fail with the same error:

I made some investigation in the meantime. The patch brakes a few unit tests. I have a fix for some of the failing tests. I will update pull request.

I had to introduce some command line options, e.g. for opening images with a given data node name, or setting properties of the images (e.g. level-window) or define source node-derived node relationships for the images to open.

I close this because I found a workaround that does not need MITK modifications.

Pull request sent:

I am wondering what would be the most straightforward way to fix the second issue. Maybe providing a comparison operator for the map based on the layer of the nodes would be enough?

Yes, Christoph added back the focus events after the meeting. This issue came up later.

https://github.com/MITK/MITK/pull/136

I do not know if there is already a convention about how to name this kind of flags. Feel free to change the name. I mean if you consider to merge this at all. :-)

https://github.com/MITK/MITK/pull/134

macros to overcome assumption about tool and tool gui class names

I found a way of resolving this issue in our codebase, without modifying MITK. I created a macro that defines an 'alias' to our class that is in the mitk namespace, and registers that class with the MITK macro. The same had to be done for tool GUI classes, as QmitkToolSelectionBox assumes that the GUI class name has a "Qmitk" prefix and "GUI" suffix added to the tool class name.

https://github.com/MITK/MITK/pull/129

macros to overcome assumption about tool and tool gui class names

https://github.com/MITK/MITK/pull/128

That is weird. How can it be?

https://github.com/MITK/MITK/pull/125

https://github.com/MITK/MITK/pull/124

You are welcome. :)

https://github.com/MITK/MITK/pull/121

https://github.com/MITK/MITK/pull/120

This is invalid, the actual problem was that the specification of the IPartListener functions have changed and my implementation did not override the empty implementations any more. The smart pointers are passed as constant reference now. This could be mentioned in the release notes.

Sorry, this has been fixed in 88c75e48f766b1a606c223875f577cc6599f4561.

The arguments are swallowed in mitk::BaseApplication::main().

Do you have a plan how to fix this? It is high priority for me, and I'm happy to work on it. I do not see, though, where are the arguments swallowed.

This works for me, at least the arguments are passed down this way. I have not tried if the files are actually opened.

I agree, the proper fix would need that change in CTK. Thanks!

Pull request sent:
https://github.com/MITK/MITK/pull/114

I close this because I could work around this without introducing this feature to BlueBerry.

Good, I am fine with that. I leave the patch on our fork then. The microservice based approach sounds good. Please try to find a solution that does not automatically registers unneeded tools. Thanks so much!

I updated the branch. Also registered all the MITK tools for the segmentation plugin. The list is probably longer than it needs to be. Remove the tools that are not needed by the plugin.

Do you agree with the concept of this fix?

The commit is not ready to merge, you would also need to call ToolManager::RegisterTool() for the needed tool classes from the segmentation plugin and the tests.

Sorry, this fixes the boost configuration on RHEL 6 with devtoolset-3, but breaks it on Ubuntu 14.04.

Matt came up with this fix that works for us:

This is the error if the regex contains the optional patch number:

Pull request sent:

As I see, PR 36 has been superseded by PR 39 which has been merged to master in commontk/PythonQt.

The commit was based on 2014.10.0 but the current master has the same issue.