I had a look on it. The idea that time was to change the navigation data player in a way that in can be handled as any other tracking device. @rosst and @wildes invested a lot of work, but unfortunately we found out that there are some problems when doing this and it never fully worked. As far as I can remember we decided to keep the navigation data player as a separate view in the end. Anyway, thanks to @rosst and @wildes for their efforts. It would have been a nice feature, but is not that important in the end. I would agree to close the bug and not merge the changes.

Pushed new branch T26370-BuildConfigurationNavigationModulesNotWorking.

Pushed new branch T25535-FixLinkerErrorWhenAnacondaIsInstalled.

Thanks a lot, solution works for me. Is there any reason to not add the fix to the master?

Seems as if the name is the problem. When renaming the file to "NavigationModules.cmake" it works again.

... also not working with cmake 3.13.1

Seems as if implementation was never finished.

If we disable openigtlink, all IGT modules/Plugins won't work. This is not an option for me. I think the main problem is to configure the build system in the right way.

Cool! Thanks for taking care for this. I'm looking forward to use the Epiphan grabber directly again (current workaround: PLUS Server and OpenIGTLink). If you need any help please let me know. There also is a nice chat support on the Epiphan page.

Pushed new branch T25777-StereoGrabbingView.

Started implementation in the branch, but doesn't work yet. Benjamin, can you fix this at the community day?

I think the main problem is the 3D rendering update. With the suggestions written down in the last comments we can however reach about 20 fps which is ok for the demos. We wont fix this now.

Pushed new branch T25608-SimpleOpenCVExample.

A possible workaround is to use PLUS for the connection to the Epiphan grabber and then connect to it via OpenIGTLink:
(1) Start a PLUS server (2.6.0 / 64bit was tested) with the default device set for a Epiphan frame grabber (PlusDeviceSet_Server_EpiphanVideoCapture.xml)
(2) Open MITK, create a new video device in the US view and choose "OIGTL Client".
(3) Activate the device and it should work

Tested the setup with two Epiphan framegrabbers of the same type and DVI/VGA video sources. The problem is always there. A OpenCV minimal example works fine, but if we paste exactly the same code to a MITK plugin the problem is there. Seems as if OpenCV doesn't like MITK running in the background for this specific frame grabber. With a framegrabber from another manufacturer (TERRATEC G1) or with a webcam video source there was no problem during the tests.

Pushed new branch T25494-InstallerCleanup-not-for-master.

The final version implemented by the students is available here: https://github.com/Alfred-Franz/MITK/tree/T24520-AblationPlanning

Pushed new branch T25494-CleanupHummelProtocolMeasurements.

Pushed new branch T25478-RenderingManagerContinousUpdate.

I also tried to move the update code of the US plugin to a thread, but it seems as if the USDevice class is not thread safe.

Moved update code of tracking toolbox to a thread. Works for the moment, with the following problems:

1. Seems as if the TrackingToolStatusWidget doesn't like if it's updated from another thread. Some buttons in the same UI part are blinking from time to time. If we don't update the widget from the thread there is no problem but we don't see the tool status.
2. Updating the color of the tool itself (green for valid / red for invalid) is not done at the moment, because some information is missing in the thread. Do we really need this feature?
3. Update rate is constant for now. The update loop in the thread can wait a certain time if we hand over a update rate from the UI.

Pushed new branch T25478-MoveUpdateCodeToThreads.

Pushed new branch T25477-Add-StandardICP.

Pushed new branch T24287-v2018.04-beta-integration-2018-09.

I just tried to build the current beta branch with Ubuntu 18.04 and NavigationModules configuration. I merged this branch, but the build failed. It seems OpenIGTLink was correctly downloaded by the superbuild, but later this error occurred: