Deleted branch from rMITK MITK: bugfix/T30456-UpgradeITK.

• Instead of depending on Eigen, depend on ITK|ITKEigen3.
• Prefix header paths with itkeigen/, e.g. itkeigen/Eigen/Dense instead of Eigen/Dense

ITK's Eigen interferes with our separate external dependency, so I will remove our own and change the dependencies to ITK's Eigen, which is just fine regarding its version.

Pushed new branch to rMITK MITK: bugfix/T30456-UpgradeITK.

I fixed MatchPoint with rMP6a425290639f: Merge branch 'T30456-FixWrongClassNameInITKMacro'.

Deleted branch from rMITK MITK: bugfix/T29634-UpgradeITK-v5.2.1-v5.3.0.

Pushed new branch to rMITK MITK: bugfix/T29634-UpgradeITK-v5.2.1-v5.3.0.

thanks for taking care. 🙏

they are ok

@floca Can you check the two commits in the branch above if they are okay for merging?

I will migrate MatchPoint in this branch: https://phabricator.mitk.org/source/matchpoint/history/T29634-MigrateToITKv5.3/

Hi there! 🙂

I will put this up for grabs as it does not make sense to start a new project now. Personally I will investigate further after the Conan evaluation report has been written.

One long term solution would also be to create an own Litmus Conan recipe and use this external Litmus package inside MatchPoint.

I was trying to test if I can forward the ITK_USE_FILE variable inside the ExternalProject call to Litmus, as we did in the change for the CMAKE_PREFIX_PATH. I realized that neither the CMAKE_PREFIX_PATH nor the ITK_USE_FILE is correctly forwarded and accessible inside Litmus CMake configuration.

I started looking into this and some changes need to be made in order to get some errors out of the way:

• Conan-center recipes are built without CMake find / config files, as mentioned here: In short: Conan creates own find / config files so they are removed from the original package.

https://phabricator.mitk.org/source/matchpoint/history/T28446-MigrateToITKv5.1/

Solved with the new icon set.

Hi there! 🙂

Hi there! 🙂

Hi there! 🙂

Hi there! 🙂

@kislinsk Stefan, you said you reworked this pragma for MITK? Does it implie any changes for 3rd party projects?

Pushed new branch T24550-MPAlgorithmControlCleanUserManual.

Pushed new branch T24546-algorithmControlBrowserSelectionEmptyDefault.

Pushed new branch T24429-New_MatchPoint_for_mitk_2018-04.

The reason is that we have no explizit LazyKernel writer that can take care.
The ExpandingFieldKernel could take care of, but MITK (for good reason -> saving a registration with field inversion would take unnecessary long) does not allow expanding, so the ExpandingFieldKernel is out.

I cannot reproduce it (neither on the master nor on the new eMITK extension feature branch). I have used CMake 3.8.x and CMake 3.10.

I use CMake 3.10 and MITK compiled with MatchPoint.

Does this problem still exist? I cannot reproduce it with my builds and the current MITK master?

You are right. Let me rephrase it to make it clearer. I see a bug in the MatchPoint code which needs a little treat.

I wouldn't call it a bug. Name conflicts of this type are not that unusual and usually one can easily get away with using the global namespace explicitly when using std::... all the time isn't an option: write ::map instead of map.

Indeed. We should change it to a less error prone alternative.

fixed by T22463

Pushed new branch T22302-Fix_integration_branch.

Pushed new branch T22302-Fix_missing_batch_plugin.