diff --git a/Documentation/Doxygen/1-Overview/Overview.dox b/Documentation/Doxygen/1-Overview/Overview.dox
index 5f25f2edf4..7001ad9872 100644
--- a/Documentation/Doxygen/1-Overview/Overview.dox
+++ b/Documentation/Doxygen/1-Overview/Overview.dox
@@ -1,88 +1,88 @@
/**
\mainpage
![MITK Logo][logo]
The [Medical Imaging Interaction Toolkit][mitk] (MITK) is a free and versatile open-source software project for the development of medical image processing applications. It can be used as a C++ toolkit or application framework for software development.
Below you can find documentation targeting different
usage scenarios:
You may want to use MITK as an application
You may want to use the MITK Workbench as an end user and will find user manuals in \ref UserManualPortal and \ref PluginListPage.
You may want to develop your own software framework, and use some of MITK's data structures and algorithms
You may want to use MITK as a toolkit and probably benefit most from the \ref BuildInstructionsPage and MITK API Documentation.
You may want to use the MITK and BlueBerry software framework to develop your own software
Here you have again two options:
You may want to use the MITK Workbench and extend its capabilities
You may want to use MITK as a software framework and writing your own modules and plugins for MITK. You may want to read the \ref BuildInstructionsPage and \ref StartingDevelopment. Also, you might want to take a look at our \ref CMAKE_FAQ.
You may want to create your own application based on MITK
This is probably the most common way to use MITK. You may want to use MITK as a software framework and build your own project and application using MITK. You may want to read \ref HowToNewProject and the general information in \ref StartingDevelopment. Also, you might want to take a look at our \ref CMAKE_FAQ.
About MITK
MITK is an open-source framework that was originally developed as a common framework for Ph.D. students in the Division of Medical and Biological Informatics (MBI) of the German Cancer Research Center. MITK aims to support the development of leading-edge medical imaging software with a high degree of interaction.
MITK re-uses virtually anything from VTK and ITK. Thus, it is not a competitor to VTK or ITK at all, but an extension, which tries to ease the combination of both, and to add features not supported by VTK or ITK.
Research institutes, medical professionals and companies alike can use MITK as a basic framework for their research and even commercial (thorough code research needed) software due to the BSD-like software license.
Research institutes will profit from the high level of integration of ITK and VTK, enhanced with data management, advanced visualization and interaction functionality in a single framework that is supported by a wide variety of researchers and developers. You don't need to reinvent the wheel over and over and can concentrate on your work.
Medical Professionals will profit from MITK and MITK applications by using its basic functionalities for research projects. Nonetheless, they will be better off, unless they are programmers themselves, to cooperate with a research institute developing with MITK to get the functionality they need. MITK and MITK applications are not certified medical products and may be used in a research setting only. They must not be used in patient care.
License
Copyright (c) [German Cancer Research Center][dkfz].
MITK is available as free open-source software under a [BSD-style license][license].
MiniApps are small command line tools. Generally the purpose of each of these tools is designed to fulfill one simple task,
e.g. resample an image or extract image statistics of a given region of interest (ROI).
They are intended to provide command line access to a variety of features of MITK, thus facilitating batched processing of data.
Usage
Each MiniApp should provide information about its usage. If it is called without parameters it will output help information about expected inputs, outputs and parameters.
Below you can see the help output of the MitkGibbsTracking MiniApp:
\code
$./MitkGibbsTracking
-i, --input, input image (tensor, ODF or FSL/MRTrix SH-coefficient image)
-p, --parameters, parameter file (.gtp)
-m, --mask, binary mask image (optional)
-s, --shConvention, sh coefficient convention (FSL, MRtrix) (optional), (default: FSL)
-o, --outFile, output fiber bundle (.fib)
-f, --noFlip, do not flip input image to match MITK coordinate convention (optional)
\endcode
Integrating a command line tool into MITK Workbench
The executable file has be to be announced in MITK Workbench. This can be done in Preferences window:
Click 'Window' -> 'Preferences', and select 'Command Line Modules'. You can add directories containing executable files or you can select single executable files.
Click 'OK' button.
The configured command line tools are now available via the drop-down box of the Command Line Modules tab.
\warning The build configuration of your MiniApp should match the build configuration of your MITK application. This is especially relevant for developers. Combining a Release application and Debug MiniApp or vice versa might not work.
Available MiniApps in MITK
\ref mitkBasicImageProcessingMiniAppsPortalPage
\ref mitkClassificationMiniAppsPortalPage
Technical Information
-MiniApps follow the Slicer Execution Model in describing themselves via xml:
+MiniApps follow the Slicer Execution Model in describing themselves via xml:
\code
$./GibbsTracking --xml
Fiber Tracking and Processing MethodsGibbs TrackingGerman Cancer Research Center (DKFZ)
...
\endcode
\note Full conformity is still a work in progress.
*/
diff --git a/Documentation/Doxygen/2-UserManual/UserManualPortal.dox b/Documentation/Doxygen/2-UserManual/UserManualPortal.dox
index 36d07ca892..a9d38ec4a3 100644
--- a/Documentation/Doxygen/2-UserManual/UserManualPortal.dox
+++ b/Documentation/Doxygen/2-UserManual/UserManualPortal.dox
@@ -1,17 +1,17 @@
/**
\usersguidemainpage{UserManualPortal} MITK User Manual
To get an introduction to the usage of any MITK based application please read \ref MITKWorkbenchManualPage. It will give you an overview of most of the common questions, such as how to load or save data or navigate within it. This is a good starting point for first questions.
For more specific information on how a plugin operates you can find the plugin documentation in \ref PluginListPage. The Plugin documentation usually explains the functionality in depth and should solve most problems you might encounter with the plugin. Depending on the application you are using you might have only some or all of the listed plugins available.
Lastly, if your question is not answered here, please use our Mailinglist to let us know about your problem.
-Alternatively, you can contact us directly.
+Alternatively, you can contact us directly.
easily create portable or installable versions of your MITK-based applications.
created packages include all MITK and 3rd party libraries necessary for running the application on other systems
distribute your binary application to other people without giving them your source code or putting them in the need for setting up a development environment themselves, eg for evaluation of your tool.
\note This does not install the MITK headers (like an SDK). If you want to develop applications based on MITK you still have to compile MITK yourself.
\section DeploymentPagePlatform Platform specific notes
\subsection DeploymentPagePlatformLinux Linux
You can create a tarball (.tar.gz) of your MITK application which includes all necessary non-system libraries by following these steps:
Set the %CMake Variable CMAKE_BUILD_TYPE to either "Debug" or "Release". Any other type (or leaving the variable empty) will not work.
If you are using third-pary libraries not shipped with MITK, you might need to add the paths to the third-party libs to your LD_LIBRARY_PATH environment variable (not necessary if you use RPATH in your shared libraries).
Type "make package" in your build-tree. This will create a tarball in your build-tree directory.
\note Libraries in system locations (/lib/, /lib32/, /lib64/, /usr/lib/, /usr/lib32/,/usr/lib64/, and /usr/X11R6/) will not be included in the tarball. If you want to distribute Qt (for example), you have to do a custom Qt installation outside of these directories.
\subsection DeploymentPagePlatformWindows Windows
-You can create a Zip file (.zip) or an NSIS 2 installer (needs an installation of NSIS) for Windows platforms. Only "Release" builds are supported during packaging, the results of trying to package "Debug" builds are undefined.
+You can create a Zip file (.zip) or an NSIS 3 installer (needs an installation of NSIS) for Windows platforms. Only "Release" builds are supported during packaging, the results of trying to package "Debug" builds are undefined.
In Visual Studio, build the "PACKAGE" project, this will create a .zip file and a .exe NSIS installer (if NSIS is installed).
On some systems, it might still be necessary to install the Microsoft Visual C++ Redistributable Package to start the installed application successfully.
\note It is possible to include the Microsoft Visual C++ Redistributable Package in the application installer.\n
A CMake variable "CMAKE_(Your Visual Studio Version)_REDISTRIBUTABLE" will be created. It has to be set to the appropriate executable (vcredist_x86.exe or vcredist_x64.exe), which will then be part of both the NSIS installer and the ZIP Archive.\n
In the case of the NSIS installer it will be automatically run if no appropriate redistributable is present on the target system.\n
Please note that it is not possible to automatically check the provided redistributable matches the Visual Studio version used to build the installer.
\subsection DeploymentPagePlatformMacOS macOS
You can create a drag'n drop disk image (.dmg) file for macOS. The procedure is pretty much the same as for Linux.
\note On macOS, libraries in system locations as pointed out in the Linux section \b and libraries located in /System/Library will not be copied. If you want to distribute any libraries from these locations, you have to install them somewhere else prior to configuring your MITK build.
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Concepts/DICOMTesting.dox b/Documentation/Doxygen/3-DeveloperManual/Concepts/DICOMTesting.dox
index b16019d910..c9cacceb51 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Concepts/DICOMTesting.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Concepts/DICOMTesting.dox
@@ -1,154 +1,154 @@
/**
\page DICOMTesting MITK DICOM testing
\section DICOMTesting_introduction Introduction
Reading DICOM data into mitk::Images is a complicated business since DICOM and MITK have very different ideas of images.
DICOMITKSeriesGDCMReader (formerly: DicomSeriesReader) brings DICOM and MITK as close together as possible by offering methods to load DICOM CT and MR images
into mitk::Images, optionally grouping slices to 3D+t images.
Since there are so many possible sources for mistakes with any change to this loading process, testing the many
assumptions implemented in DICOMITKSeriesGDCMReader is worthwhile. This document describes what and how theses kind of tests are implemented.
\section DICOMTesting_problem Problem description
The task of loading DICOM files into mitk::Images is a challenge because of major differences
in the way that DICOM and MITK represent images:
- DICOM images
+ are mostly stored as one slice per file
+ do not describe how they can be arraged into image stacks with orthogonal axis
+ sometimes they cannot be arranged in image stacks as described above (e.g. tilted gantry)
- mitk::Image (at least its mature areas)
+ represents image stacks with orthogonal axis (nothing like a tilted gantry)
+ have a concept of a fourth dimension (time steps)
Because image processing applications based on MITK still need a way to load DICOM images into
mitk::Image objects, MITK needs a way to build image stacks and this needs to be well tested.
For more background information, see David Clunie's most valuable posts on comp.protocols.dicom, e.g.:
- - http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/6db91972e161f0d4/6e0304ac264a6eb5
- - http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/e9bd1497bea3e66b/187a7dc8810613d2
- - http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/5d80bb0b7fafcb81/cf96119e3b024ed8
- - http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/4568635e083a3fba/e2a8ceec23032601
+ - https://groups.google.com/g/comp.protocols.dicom/c/bbkZcuFh8NQ
+ - https://groups.google.com/g/comp.protocols.dicom/c/6b0Ul76j5ms
+ - https://groups.google.com/g/comp.protocols.dicom/c/XYC7C3-vy4E
+ - https://groups.google.com/g/comp.protocols.dicom/c/RWhjXgg6P7o
\section DICOMTesting_testidea Test principle
The general idea for DICOM loaing tests is to run a set of known DICOM files through DICOMITKSeriesGDCMReader's methods
GetSeries() and LoadDicomSeries() to generate mitk::Images. These images are then compared to expected image properties,
such as the number of individual mitk::Images, positions, orientations, spacings, etc.
Stored expectations look like this (should be self-explanatory):
\verbatim
-- Image 1
Pixeltype: s
BitsPerPixel: 16
Dimension: 4
Dimensions: 64 64 6 1
Geometry:
Matrix: 5.25 0 0 0 5.2468 0.139598 0 -0.183222 3.99757
Offset: -159.672 -309.974 -69.0122
Center: 0 0 0
Translation: -159.672 -309.974 -69.0122
Scale: 1 1 1
Origin: -159.672 -309.974 -69.0122
Spacing: 5.25 5.25 4
TimeBounds: 0 1
-- Image 2
Pixeltype: s
BitsPerPixel: 16
Dimension: 4
Dimensions: 64 64 41 1
Geometry:
Matrix: 5.25 0 0 0 5.25 0 0 0 4
Offset: -160.672 -311.672 -285
Center: 0 0 0
Translation: -160.672 -311.672 -285
Scale: 1 1 1
Origin: -160.672 -311.672 -285
Spacing: 5.25 5.25 4
TimeBounds: 0 1
\endverbatim
\section DICOMTesting_implementation Implementation
\section DICOMTesting_implementation_utils Test helpers (applications and classes)
Application DumpDICOMMitkImage
Takes a list of DICOM images, loads them using TestDICOMLoading, then dumps information
about the resulting mitk::Images to standard output.
This application is helpful when defining reference data for tests.
Application VerifyDICOMMitkImageDump
Takes a list of DICOM images and loads them using TestDICOMLoading.
Takes a dump file as generated by DumpDICOMMitkImage, parses it and
compares it to actually generated mitk::Images.
This application is used to implement the majority of test cases. They all
load images, then verify the expected result structure.
Class TestDICOMLoading
\section PageDICOMLoadingTests_testcaseimplementation Test case implementation
Individual test cases are stored in the MITK-Data repository and constructed by Core/Code/Testing/DICOMTesting/Testing/CMakeLists.txt
The CMake file parses given directories for subdirectories containing specific test cases. Each directory contains two files:
- File "input": lists DICOM files that should be loaded for this test case
- File "expected.dump": contains the image properties in the above mentioned dump format
Each test case is translated into a CTest test which evaluates the return value of a call to VerifyDICOMMitkImageDump.
\section PageDICOMLoadingTests_testcases Implemented test cases
From test set \b TinyCTAbdomen (see description.txt in this directory for details on test images):
- singleslice : just a single slice (should work and contain meaningful spacing)
- two_slices : two slices, spacing should be calculated correctly
- all : load a "normal" series as a single 3D block
- 3D_and_T : load a small set of slices with multiple time-steps
- diff_orientation : load a set of files containing two differently oriented image blocks; at least two images (110,111) have minor errors in small decimal digits
- diff_orientation_gaps : load a set of files containing two differently oriented image blocks, each missing slices, so blocks must be split
- diff_spacing : load a set of files containint two set of slices with different spacings
- gap : load slices that cannot form a single 3D block, because single slices are missing
- gaps : slices missing in differnt locations, so multiple splits needed
- unsorted_gaps : as before, just file names are unsorted
- single_negative_spacing : from reported bug related to single MR images with misleading spacing information
- tilted_gantry : slice origins do not align along first slice normal (happens with tilted gantries)
- interleaved : two volumes of slices with origins along the same line. The volumes' slices interleave in their border region. This test is meant to correctly sort apart the two blocks instead of generating many two-slices groups in the interleaved region.
- CR-MONO1-10-chest-spacing-none : CR image without spacing information - (1.0, 1.0) should be assumed
- CR-MONO1-10-chest-spacing-pixelspacing : CR image with only "Pixel Spacing" tag - this should be used as spacing
- CR-MONO1-10-chest-spacing-imagerpixelspacing : CR image with only "Imager Pixel Spacing" tag - this should be used as spacing
- CR-MONO1-10-chest-spacing-calibrated : CR image with BOTH "Imager Pixel Spacing" and "Pixel Spacing" defined - "Pixel Spacing" should be used
- OT-MONO2-8-colon : Secondary Capture image with gray value pixels - should be loaded
- OT-PAL-8-face : Secondary Capture image with PALETTE pixel values - can be loaded, but display is not correct yet
From test set \b TiltHead (see description.txt in this directory for details on test images):
- head_ct_tilt : load a series with gantry tilt and check its orientation
\section DICOMTesting_othertests Specific other tests
This list is meant to provide an up-to-date list of all implemented DICOM loading tests.
If you ever find this outdated, please update it or make the persons who invalidated the list update it.mitkDICOMTestingSanityTest_*
These tests implement basic testing of the implemented helper classes. The tests use DICOMITKSeriesGDCMReader to load
a number of DICOM image. They verify:
- DICOMITKSeriesGDCMReader recognizes all input files as DICOM images
- DICOMITKSeriesGDCMReader generates a number of mitk::Images from the DICOM images
- the number of mitk::Images matches a number given on the command line or CTest's add_test()
- helper methods in class TestDICOMLoading make minimal sense (comparison of an image dump to itself must be valid)
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Concepts/DataInteraction.dox b/Documentation/Doxygen/3-DeveloperManual/Concepts/DataInteraction.dox
index 3bf3794ae1..374ae959a6 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Concepts/DataInteraction.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Concepts/DataInteraction.dox
@@ -1,230 +1,230 @@
/**
\page DataInteractionPage Interaction Concepts
\tableofcontents
\section DataInteractionPage_Introduction Introduction to Interaction in MITK
Interaction is a very important task in medical image processing software. Therefore MITK provides a special interaction concept
that provides the developer with an easy way to develop and maintain user interaction separately from the algorithms processing the input.
This allows e.g. for common interaction schemes to be re-used in different contexts.
The core of the interaction concept is based on entities called \b DataInteractors that listen for certain pre-defined events and execute
actions when such an event is triggered.\n
In the following the different components of the interaction concept are explained.
First a a high-level overview about how the different components interact is given, then some parts are explained in more detail.
\subsection FurtherReadingInteraction Topics related to interaction - further information:
See the \ref DataInteractionTechnicalPage page for a more technical explanation. \n
Consult \ref HowToUseDataInteractor for usage information.\n
See \ref SectionImplementationDataInteractor for an example on how to implement a new mitk::DataInteractor \n
for information about how to create new events refer to ImplementNewEventsPage.\n
The documentation of the depricated former concept can be found at \ref InteractionPage.
\n
For a list of changes with respect to the previous interaction concept please refer to the \ref InteractionMigration
\section DataInteractionPage_HandlingSection Event Handling & GUI Toolkit Abstraction
The following sequence diagram gives an exemplary overview of the process from creating an event until executing an action in the mitk::DataInteractor.
This diagram assumes the usage of the Qt framework, but also shows that the interaction concept itself is implemented independent of any specific
graphical user interface toolkit.
\imageMacro{event_handling.png,"",16}
a user event is triggered and send to MITK
this layer serves as an adapter from the GUI toolkit (here Qt) events to MITK internal events (later referred to as \link mitk::InteractionEvent InteractionEvents\endlink).
once the event is adapted it is send to a mitk::Dispatcher, which is linked to a render window, to be handled.
on the mitk::Dispatcher level all objects are known that can react to incoming events (mitk::DataInteractor and mitk::InteractionEventObserver instances)
a mitk::DataInteractor is offered an event and checks its mitk::EventConfig object, which returns if a variant of this event has been defined for this DataInteractor.
if the DataInteractor has a variant for the event, it consults its state machine to check if the input can be handled in the current state
the actions associated with a state change (transition) are executed and the event is successfully handled.
\section DataInteractionPage_EventPage Events
Events can describe any sort of user input, such as key strokes, mouse clicks or touch gestures.
These events are mapped from an UI framework like Qt to an MITK internal representation
and send to the mitk::Dispatcher which in turn deals with further processing of the event.
These events are not limited to classical input devices but can be extended at will, by introducing new classes which e.g. describe
events from tracking devices, etc. Refer to \subpage ImplementNewEventsPage to see how new events and thereby input devices can be integrated.
For an overview of available Events see mitk::InteractionEvent, for on overview of parameters see the \subpage DataInteractionTechnicalPage.
\section DataInteractionPage_InteractionEventHandlerSection InteractionEventHandler
Is the term describing objects in general that can handle events. These objects can be divided into two groups, namely
\link mitk::DataInteractor DataInteractors\endlink and mitk::InteractionEventObserver. Their difference is that mitk::DataInteractor instances are
linked with a mitk::DataNode which they manipulate, whereas mitk::InteractionEventObserver instances do not have a mitk::DataNode and therefore
are not supposed to manipulate any data.
\dot
digraph linker_deps {
node [shape=record, fontname=Helvetica, fontsize=10];
a [ label="InteractionEventHandler" ];
d [ label="{EventStateMachine|HandleEvent()}" ];
b [ label="{DataInteractor|PerformAction()}" ];
a -> d;
d -> b;
}
\enddot
\subsection DataInteractionPage_DataInteractorsSection DataInteractors
DataInteractors are specialized mitk::InteractionEventHandler which handle events for one spefific DataNode. They are implemented following a concept called state machines
-(see e.g. Wikipedia ).
+(see e.g. Wikipedia ).
\subsubsection DataInteractionPage_StateMachinesSection StateMachines
A specific events action is usually desired to depend on the content of the data object and the state of the interaction.
For example when adding a line by clicking with the mouse, the first two clicks are supposed to add a point.
But the second click should additionally finish the interaction and a subsequent third click should be ignored.
State machines provide a great way to model such interaction in which the same user interaction can trigger different actions
depending on the current state. Therefore DataInteractors work with so called state machine patterns.
The basic idea here is that each interaction can be described by states
and transitions which in turn trigger actions.
These patterns define a workflow and different patterns can be applied to the same mitk::DataInteractor and cause this mitk::DataInteractor
to perform different user interactions.
This principle is best described by an example.
Imagine a mitk::DataInteractor with the functionality (1) to add Points at a given mouse position and connect them by a line and (2) check if two
points are on the same position. Using this mitk::DataInteractor, different mitk::StateMachine patterns/descriptions
can be given which each cause the mitk::DataInteractor to perform different interaction schemes.
State machine pattern 1:
We want the user to draw a line. A simple state machine could express this by three states like this:
\dot
digraph linker_deps {
node [shape=circle, fontname=Helvetica, fontsize=10];
a [ label="NoPoints" ];
b [ label="OnePoint" ];
c [ label="TwoPoints" ];
a -> b [label="MousePress/AddPoint",fontname=Helvetica, fontsize=10];
b -> c [label="MousePress/AddPoint",fontname=Helvetica, fontsize=10];
{ rank=same; a b c }
}
\enddot
With each MousePress event the AddPoint function is called and adds a point at the mouse position, unless two points already exist.
State machine pattern 2:
The same mitk::DataInteractor can also operate after the following state machine, which models the interaction to input a closed contour.
The mitk::DataInteractor can detect an AddPoint event on an already existing point and will trigger a PointsMatch event.
\dot
digraph {
node [shape=circle, fontname=Helvetica, fontsize=10];
a [ label="StartState" ];
b [ label="ClosedContour"];
a -> a [label="MousePress/AddPoint",fontname=Helvetica, fontsize=10];
a -> b [label="PointsMatch/AddPoint",fontname=Helvetica, fontsize=10];
}
\enddot
In this way state machines provide both, a nice and structured way to represent interaction tasks and description of the interaction which is separated from the code.
One DataInteractor can be re-used for different tasks by simply exchanging the state machine pattern. These patterns are described in XML files.
\subsubsection DataInteractionPage_DefinitionStateMachine Definition of a State Machine
The definition is made up out of four components.
States - represent the current status of the interaction
Transitions - describe the events needed to change from one state to another
-
Conditions - are executed, before a transition is taken
+
Conditions - are executed, before a transition is taken
Actions - are executed, when a transition is taken and conditions for that transition have passed
Each state machine needs exactly one designated start state into which the state machine is set in the beginning.
An example of a state machine describing the interaction of example 2 looks like this:
\code
\endcode
Example 1: State machine pattern, that describes adding points to a contour until the PointsMatch event is triggered.
For a more detailed description of state machine patterns see here.
\subsection DataInteractionPage_InteractionEventObserverSection InteractionEventObserver
mitk::InteractionEventObserver instances are objects which will receive all user input and are intended for observation only,
they should never modify any DataNodes.
For mitk::InteractionEventObserver it is optional to use the state machine functionality, the default is without. How to use the state machine functionality
is described in the documentation of mitk::InteractionEventObserver::Notify.
\dot
digraph event_observer {
node [shape=record, fontname=Helvetica, fontsize=10];
c [ label="{InteractionEventObserver|Notify()}" ];
a [ label="InteractionEventHandler" ];
b [ label="{EventStateMachine|HandleEvent()}" ];
d [ label="{MyCustomObserver|PerformAction()}" ];
c -> d;
a -> b;
b -> d [style="dashed",label="optional"];
}
\enddot
\subsection DataInteractionPage_ConfigurationSection Configuration
In a lot of cases it is preferable to implement interactions independent of a specific event (e.g. left click with mouse), such that it is possible
to easily change this. This is achieved through configuration of \link mitk::InteractionEventHandler InteractionEventHandlers\endlink.
This allows to change the behavior at runtime.
The mitk::InteractionEventHandler class provides an interface to easily modify the user input that triggers an action by loading a different
configuration. This allows to implement
user-specific behavior of the software on an abstract level and to switch it at runtime.
This is achieved through XML files describing a configuration. These files can be loaded by the mitk::InteractionEventHandler and will lead to an internal mapping
from specific user input to an abstract description of the event given in the config file.
In order to do this we distinguish between a specific event and an event variant. A specific event is described by its event class, which determines the
category of an event, e.g. the class mitk::MousePressEvent, and its parameter which make this event unique, e.g. LeftMouseButton pressed and no modifier keys pressed.
The event variant is a name that is assigned to a specific event, and to which an mitk::InteractionEventHandler listens.
To illustrate this, an example is given here for two different configuration files. We assume that a mitk::InteractionEventHandler listens to the
event variant 'AddPoint', two possible config files could then look like this:
\code
\endcode
Example 2: Event description of a left click with the mouse
and
\code
\endcode
Example 3: Event description of a left click with the mouse while pressing the shift-key
If the mitk::InteractionEventHandler is loaded with the first configuration the event variant 'MousePress' is triggered when the user performs a mouse click,
while when the second configuration is loaded 'MousePress' is triggered when the user performs a right click while pressing the shift button.
In this way all objects derived from mitk::InteractionEventHandler can be configured. For a detailed description about how to create the XML file see the
\ref DataInteractionTechnicalPage page.
\section DataInteractionPage_DispatcherSection Dispatcher
Instances of mitk::Dispatcher receive all events and distribute them to their related mitk::DataInteractor instances. This is done by ordering
the DataInteractors according to the layer of their
mitk::DataNode in descending order. Then the event is offered to the first mitk::DataInteractor, which in turn checks if it can handle the event. This is done
for each mitk::DataInteractor until the first processes the event, after this the other DataInteractors are skipped and all InteractionEventObservers are notified.
\section DataInteractionPage_Examples Examples
Examples can be found at \subpage InteractionHowTo
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Concepts/Persistence.dox b/Documentation/Doxygen/3-DeveloperManual/Concepts/Persistence.dox
index 0f9cd9f10d..54aa3ba289 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Concepts/Persistence.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Concepts/Persistence.dox
@@ -1,65 +1,65 @@
/**
\page PersistenceConceptPage Persistence Concept
\tableofcontents
In general, persistence referes to the capability of an application to permanently store data, settings, states, etc. so that they outlive a restart. Normal data objects, such as images, surfaces, etc., which are visible in the data storage of MITK can be saved easily by the save/load functions, see \ref DataManagementPage for more details. This page focus on the persistence of settings, configurations, object states and parameters of the application. Depending on the component, e.g. plugin, module, etc., where you want to store your settings, MITK offers various ways to do so:
-# For code inside UI independent modules with low dependencies to other libraries the mitk::PersistenceService inside the MITK persistence module can be used to store parameters by using the mitk::PropertyList class: \ref PersistenceMITKService
-# UI dependent code where the Qt library is available can use QSettings: \ref PersistenceQTSetting
-# If the UI setting of Plugins should be stored permanently, the persistence features of blueberry can be used: \ref PersistenceBlueberry
-# Extended features, which include persistence, are provided by the configuration service. \ref PersistenceConfigurationService
\section PersistenceMITKService MITK Persistence Service
For persistence of member variables and parameters, the interface mitk::IPersistenceService in the MITK core provides an API to store variables permanently by means of mitk::PropertyList objects. These properties can be stored inside a MITK scene together with the data so that the user loads data and restores the application state at once. The current actual implementation of this interface can be found in the module Persistence. The class mitk::PersistenceService offers a rather simple way to store variables permanently.
To enable MITK persistence inside your class, simply include the persistence interface and use PERSISTENCE_GET_SERVICE_METHOD_MACRO in the private part of your class, as shown in the next code snippet:
\code
#include
//[...]
private:
PERSISTENCE_GET_SERVICE_METHOD_MACRO
\endcode
You can then access a persistent property list by using a unique id, e.g. the name of your plugin. Variables can be added to this property list and will be available after restarting the application.
\code
mitk::PropertyList::Pointer propList = this->GetPersistenceService()->GetPropertyList("org.mitk.myUniqueModule");
//set a variable:
propList->Set("deviceNumber", m_Controls->GrabbingDeviceNumber->value());
//get a variable:
int grabbingDeviceNumber = 0;
propList->Get("deviceNumber", deviceNumber);
\endcode
When a MITK scene with stored property list is loaded within MITK the list will change automatically. However a class can be informed by the service object by when the list is changed by adding it as observer to the service object.
\code
this->GetPersistenceService()->AddPropertyListReplacedObserver(this);
\endcode
An example implementation for the use of the mitk::PersistenceService can be found in the module OpenCVVideoSupport (class QmitkOpenCVVideoControls) and in the corresponding unit test mitkPersistenceTest in the Persistence module.
\section PersistenceQTSetting Qt Settings
Within the UI dependent modules inside MITK, the Qt::settings class can also be used to store variables permanently. The following code snippet shows an example:
\code
//in the header:
#include
//[...}
QSettings m_MySettings;
//in the cpp file:
//initialize the settings object (e.g. constructor):
m_MySettings("MyClass","MyDescription")
//store settings:
m_MySettings.setValue("identifier",value);
//load settings:
int intExample = m_MySettings.value("identifier").toInt();
\endcode
However, integration into a MITK scene file is not possible with Qt::settings.
\section PersistenceBlueberry Persistence Features of Blueberry
-In blueberry, the view states can be saved and restored which is described here: MITK.org: Save and Restore your View State. Additionally, there is a possibility to make the preferences of a view persistent, which is documented in the class API documentation of the persistence service.
+In blueberry, the view states can be saved and restored which is described here: MITK.org: Save and Restore your View State. Additionally, there is a possibility to make the preferences of a view persistent, which is documented in the class API documentation of the persistence service.
\section PersistenceConfigurationService Configuration Service
An implementation of a configuration service is planned for MITK in near future but not available yet.
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Concepts/QVTKRendering.dox b/Documentation/Doxygen/3-DeveloperManual/Concepts/QVTKRendering.dox
index 856f7a5267..beac96cfda 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Concepts/QVTKRendering.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Concepts/QVTKRendering.dox
@@ -1,128 +1,128 @@
/**
\page QVTKRendering Rendering Concept
\tableofcontents
The MITK rendering pipeline is derived from the VTK rendering pipeline.
\section QVTKRendering_Pipeline_VTK VTK Rendering Pipeline
\imageMacro{RenderingOverviewVTK.png,"Rendering in VTK",12}
In VTK, the vtkRenderWindow coordinates the rendering process. Several vtkRenderers may be associated to one vtkRenderWindow.
All visible objects, which can exist in a rendered scene (2D and 3D scene), inherit from vtkProp (or any subclass e.g. vtkActor).
A vtkPropAssembly is an assembly of several vtkProps, which appears like one single vtkProp.
MITK uses a new interface class, the "vtkMitkRenderProp", which is inherited from vtkProp. Similar to a vtkPropAssembly, all MITK rendering stuff is performed via this interface class.
Thus, the MITK rendering process is completely integrated into the VTK rendering pipeline. From VTK point of view, MITK renders like a custom vtkProp object.
-More information about the VTK rendering pipeline can be found at http://www.vtk.org and in the several VTK books.
+More information about the VTK rendering pipeline can be found at https://vtk.org/ and in the several VTK books.
\section QVTKRendering_Pipeline_MITK MITK Rendering Pipeline
This process is tightly connected to VTK, which makes it straight forward and simple. We use the above mentioned "vtkMitkRenderProp" in conjunction with the mitk::VtkPropRenderer for integration into the VTK pipeline. The QmitkRenderWindow does not inherit from mitk::RenderWindow, but from the QVTKWidget, which is provided by VTK.
The main classes of the MITK rendering process can be illustrated like this:
\imageMacro{qVtkRenderingClassOverview.png,"Rendering in MITK",16}
A render request to the vtkRenderWindow does not only update the VTK pipeline, but also the MITK pipeline. However, the mitk::RenderingManager still coordinates the rendering update behavior.
Update requests should be sent to the RenderingManager, which then, if needed, will request an update of the overall vtkRenderWindow. The vtkRenderWindow then starts to call the Render() function of all vtkRenderers, which are associated to the vtkRenderWindow. Currently, MITK uses specific vtkRenderers (outside the standard MITK rendering pipeline) for purposes, like displaying a gradient background (mitk::GradientBackground), displaying video sources (QmitkVideoBackround and mitk::VideoSource), or displaying a (department) logo (mitk::ManufacturerLogo), etc..
Despite these specific renderers, a kind of "SceneRenderer" is member of each QmitkRenderWindow. This vtkRenderer is associated with the custom vtkMitkRenderProp and is responsible for the MITK rendering.
The vtkRenderer calls four different functions in vtkMitkRenderProp, namely RenderOpaqueGeometry(), RenderTranslucentPolygonalGeometry(), RenderVolumetricGeometry() and RenderOverlay(). These function calls are forwarded to the mitk::VtkPropRenderer.
Then, depending on the mapper type (OpenGL- or VTK-based), OpenGL is enabled or disabled. In the case of OpenGL rendering, the Paint()-method of each individual mapper is called. If the mapper is VTK-based, the four function calls are forwarded to mitk::VtkMapper and within these methods the corresponding VtkProp is evaluated.
Both strategies are illustrated in the sequence diagrams below:
\imageMacro{qVtkRenderingSequenceVTK.png,"Sequence diagram for MITK VTK rendering",16}
In MITK, VTK-based mapper are more common and we recommend on implementing VTK-based mappers. However, MITK supports OpenGL-based mappers as well.
\imageMacro{qVtkRenderingSequenceGL.png,"Sequence diagram for MITK OpenGL rendering",16}
\section QVTKRendering_Mapper MITK Mapper Architecture
Mappers are used to transform the input data in tangible primitives, such as surfaces, points, lines, etc. The base class of all mappers is mitk::Mapper. The mapper hierarchy reflects the two possible ways to render in MITK: Subclasses of mitk::Mapper control the creation of rendering primitives
that interface to the graphics library (e.g. via OpenGL, vtk). The mapper architecture is illustrated in the following UML diagram:
\imageMacro{qVtkRenderingMapper.jpg,"Mapper architecture",16}
mitk::Mapper::Update() calls the time step of the input data for the specified renderer and checks whether the time step is valid and calls method mitk::Mapper::GenerateDataForRenderer(), which is reimplemented in the individual mappers and should be used to generate primitives.
mitk::Mapper::SetDefaultProperties() should be used to define mapper-specific properties.
\section QVTKRendering_programmerGuide User Guide: Programming hints for rendering related stuff (in plugins)
\li The QmitkRenderWindow can be accessed like this: this->GetRenderWindowPart()->GetRenderWindow("axial");
\li The vtkRenderWindow can be accessed like this: this->GetRenderWindowPart()->GetRenderWindow("axial")->GetVtkRenderWindow();
\li The mitkBaseRenderer can be accessed like this: mitk::BaseRenderer* renderer = mitk::BaseRenderer::GetInstance(this->GetRenderWindowPart()->GetRenderWindow("sagittal")->GetRenderWindow());
\li An update request of the overall QmitkStdMultiWidget can be performed with: mitk::RenderingManager::GetInstance()->RequestUpdateAll() or alternatively with the shorthand this->RequestRenderWindowUpdate();
\li A single QmitkRenderWindow update request can be done like this: mitk::RenderingManager::GetInstance()->RequestUpdate(this->GetRenderWindowPart()->GetRenderWindow("axial")->GetVtkRenderWindow());
\li be aware that GetRenderWindowPart() can return null if the editor is closed. This is a common reason for nullpointer exceptions.
\note The usage of ForceImmediateUpdateAll() is not desired in most common use-cases.
\subsection QVTKRendering_distinctRenderWindow Setting up a distinct Rendering-Pipeline
It is sometimes desired to have one (or more) QmitkRenderWindows that are managed totally independent of the 'usual' renderwindows defined by the QmitkStdMultiWidget.
This may include the data that is rendered as well as possible interactions. In order to achieve this, a set of objects is needed:
\li mitk::RenderingManager -> Manages the rendering
\li mitk::DataStorage -> Manages the data that is rendered
\li mitk::GlobalInteraction -> Manages all interaction
\li QmitkRenderWindow -> Actually visualizes the data
The actual setup, respectively the connection, of these classes is rather simple:
\code
// create a new instance of mitk::RenderingManager
mitk::RenderingManager::Pointer renderingManager = mitk::RenderingManager::New();
// create new instances of DataStorage and GlobalInteraction
mitk::DataStorage::Pointer dataStorage = mitk::DataStorage::New();
mitk::GlobalInteraction::Pointer globalInteraction = mitk::GlobalInteraction::New();
// add both to the RenderingManager
renderingManager->SetDataStorage( dataStorage );
renderingManager->SetGlobalInteraction( globalInteraction );
// now create a new QmitkRenderWindow with this renderingManager as parameter
QmitkRenderWindow* renderWindow = new QmitkRenderWindow( parent, "name", renderer, renderingManager );
\endcode
That is basically all you need to setup your own rendering pipeline.
Obviously you have to add all data you want to render to your new DataStorage. If you want to interact with this renderwindow, you will also have
to add additional Interactors/Listeners.
\note Dynamic casts of a mitk::BaseRenderer class to an OpenGLRenderer (or now, to an VtkPropRenderer) should be avoided. The "MITK Scene" vtkRenderer and the vtkRenderWindow as well, are therefore now included in the mitk::BaseRenderer.
\subsection QVTKRendering_userGuideMapper How to write your own Mapper
If you want to write your own mapper, you first need to decide whether you want to write a VTK-based mapper or a GL-based mapper.
We recommend to write a VTK-based mapper, as VTK is easy to learn and some GL-based mappers can have unexpected site effects.
However, you need to derive from the respective classes.
In the following we provide some programming hints for writing a Vtk-based mapper:
\li include mitkLocalStorageHandler.h and derive from class BaseLocalStorage as a nested class in your own mapper. The LocalStorage instance should
contain all VTK ressources such as actors, textures, mappers, polydata etc.
The LocalStorageHandler is responsible for providing a LocalStorage to a concrete mitk::Mapper subclass. Each RenderWindow / mitk::BaseRenderer is
assigned its own LocalStorage instance so that all contained ressources (actors, shaders, textures, ...) are provided individually per window.
\li GenerateDataForRenderer() should be reimplemented in order to generate the primitives that should be rendered. This method is called in each Mapper::Update() pass, thus,
all primitives that are rendered are recomputed. Employ LocalStorage::IsGenerateDataRequired() to determine whether it is necessary to generate the primitives again. It is not
necessary to generate them again in case the scene has just been translated or rotated.
\li For 2D mappers, it is necessary to determine the 3D primitives close to the current plane that should be drawn. Use
planeGeometry = renderer->GetSliceNavigationController()->GetCurrentPlaneGeometry() to get the current plane. The distance to it can be determined by using planeGeometry->DistanceFromPlane(point).
\li Reimplement GetVtkProp(), that should return the specific VtkProp generated in GenerateDataForRender() (e.g. a single actor or a propassembly, which is a combination of different actors).
The VtkProp is picked up in one of the four render passes and thus integrated into the VTK render pipeline.
\li SetDefaultProperties() should be used to define mapper-specific properties.
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Concepts/TestsGeneral.dox b/Documentation/Doxygen/3-DeveloperManual/Concepts/TestsGeneral.dox
index 0c3174a87d..10d3d23308 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Concepts/TestsGeneral.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Concepts/TestsGeneral.dox
@@ -1,104 +1,104 @@
/**
\page GeneralTests General: Tests in MITK
\tableofcontents
\section GeneralTestsIntroduction Testing in MITK
The basic idea about unit testing is to write a test for every unit (e.g. function) of your software, which automatically checks if the code still returns the expected result for a defined input. The goal is to isolate units as much as possible, in order to be efficient with fixing errors.
If this is performed on a low level, this is called unit testing. On higher levels, where various circumstances (such as configuration files, internet connection, hardware, or even input/output) may influence the outcome of the test, this is called integration testing.
MITK uses CppUnit, which is a framework for efficient and fast test writing, to support developers in test coding. Furthermore MITK offers currently three types of tests: classic unit tests, rendering tests and interaction tests. Although our unit tests often involve data input (or output), we still consider them to be unit tests.
\warning Most of our units tests have been written before adopting CppUnit and have not yet been updated. Therefore we do not recommend to look at a random test for an example of coding a test.
This pages gives a general introduction to our test framework. Rendering tests are explained in more detail in the section \ref RenderingTests and interaction tests the section \ref InteractionTestingHowTo. The following sections will explain how to write your own tests with MITK and how to run them.
\section GeneralTestsAdding Adding a test to your module
Generally, functional code you want to test using unit tests will be located in a module. For an overview of the directory structure see \ref NewModulePageCreateFolder and how to add the files comprising your test compare \ref NewModulePageCreateTestingEnvironment
\subsection GeneralTestsAddingFramework Test and test class/suite
CppUnit and MITK distinguish between the term test class and test, which is important to understand. A test is simply a call of a single function and a comparison against a reference.
The ideal way to write a test is:
\code
result = myGreatFunction(myParameter);
ASSERT_EQUAL(result, reference);
\endcode
which is just 2 lines of code at the best. Sometimes objects and data may be initialized in a test, but usually this should be done in the setUp() method (see below). If possible, avoid multiple assertions in order to be efficient in error localization and for better readability. For instance, if you instantiate an object and test if its data is not NULL, this is already a complete test and you do not want to repeat this comparison in other tests.
All tests check different things and just one at a time. Remember: The goal is to have isolated unit tests and avoid large, confusing tests which are hard to maintain.
\note The reference should never be computed and ideally be a distinct and well defined (often hard coded) value. You don't care where you reference comes from, you just want to ensure that your test actually results in the reference value.
A test class (also called suite) is a set of tests and often associated to a single functional class in MITK. A test class refers to a TestSuite in CppUnit. These terms are easily confused, so we suggest to use the term test suite for a collection of tests (which is often in a single file), and the term "test" for a single test (usually many per file).
In order to create a test class you need to create a new class deriving from mitk::TestFixture. While a purist approach would be to create a new mitk::TestFixture for each method of your class (resulting in as many test source files as your class has methods), we usually follow a more pragmatic approach within MITK. In most cases we suggest having one test source file per class. If your class source file is called mitkGreatClass.cpp we suggest the name mitkGreatClassTest.cpp for your test source file. For very complex and long classes splitting this into several tests may be advisable. Additionally, rendering tests and interaction tests should always get their own test class/suite to mark them as obvious integration tests, because the goal is to isolate unit tests from integration tests. The dashboard for continuous integration will automatically show the results of a test suite and summarize the output. If you run your test manually (e.g. with ctest -VV), you will see the detailed output of all tests of the suite.
In order to use CppUnit via MITK you will need to include the corresponding files and register your test:
\code
#include
#include
…
MITK_TEST_SUITE_REGISTRATION(mitkImageEqual)
\endcode
\subsection GeneralTestsAddingHow How to structure your test
As mentioned before, all test suites derive from mitk::TestFixture. A suggested name for your test suite would be \c \TestSuite .
You then create a suite and register your tests. A suggested naming convention for test methods is \c \_\_\ . We suggest not to add the word test, because that is most likely the only thing the reader knows anyway about your test, as he is reading a test suite.
An example:
\code
class mitkImageEqualTestSuite : public mitk::TestFixture
{
CPPUNIT_TEST_SUITE(mitkImageEqualTestSuite);
MITK_TEST(Equal_CloneAndOriginal_ReturnsTrue);
MITK_TEST(Equal_InputIsNull_ReturnsFalse);
MITK_TEST(Equal_DifferentImageGeometry_ReturnsFalse);
MITK_TEST(Equal_DifferentPixelTypes_ReturnsFalse);
…
CPPUNIT_TEST_SUITE_END();
…
}
\endcode
You also may provide a setUp() and a tearDown() function. These will be called before/after each test and should be used to make sure that each test works independently and on freshly initialized members and memory to maximize isolation. That way you avoid only testing whether a function works after another function has already been called. See CppUnit documentation for more information. For an example test suite including tests see \ref GeneralTestsExample
\section GeneralTestsRunning Running your test suite
-The build system of MITK generates a test driver which includes all test suites that have been added to the project. Alternatively you can run MITK test suites by using the program ctest. This is the way all MITK tests run on the continuous dart clients of MITK. The results of these runs can be found at http://cdash.mitk.org.
+The build system of MITK generates a test driver which includes all test suites that have been added to the project. Alternatively you can run MITK test suites by using the program ctest. This is the way all MITK tests run on the continuous dart clients of MITK. The results of these runs can be found at https://cdash.mitk.org/.
If you use the test driver, you only need to start the executable. If you start it without parameters, it will then give you an overview of all tests which are included in this test driver and you can choose one by typing a number. Alternatively, you can give your test driver the name of your test suite as parameter. If you want to use ctest instead of the test driver you need to start a command line, go to the binary directory of MITK and call ctest. To avoid errors, check if your path variable contains all relevant paths to start MITK.
\section GeneralTestsParameterInput Adding parameters to your test
If possible, the setUp() method of the test suite should provide all necessary inputs for the respective tests. MITK provides several helper classes to generate synthetic test data, such as the mitk::ImageGenerator. If you have to load data from the hard disc for your test, you can use the method GetTestDataFilePath(string fileName). For an example of loading data from the MITK_DATA_DIR check the mitkIOUtilTestSuite.
\section GeneralTestsPredefinedAssertions Predefined assertions
-MITK and CppUnit offer predefined assertions, i.e. helper methods which will help to compare your data against a certain reference. All basic types are covered by CppUnit assertions, such as CPPUNIT_ASSERT. For examples, please check the CppUnit documentation. MITK further offers comparison tools for floating point numbers, vectors, images, surfaces and point sets. A complete list of assertion macros is given in \ref MITKTestingAPI.
+MITK and CppUnit offer predefined assertions, i.e. helper methods which will help to compare your data against a certain reference. All basic types are covered by CppUnit assertions, such as CPPUNIT_ASSERT. For examples, please check the CppUnit documentation. MITK further offers comparison tools for floating point numbers, vectors, images, surfaces and point sets. A complete list of assertion macros is given in \ref MITKTestingAPI.
An example to compare images:
\code
MITK_ASSERT_EQUAL(image, reference, "Checks if image is equal to a reference");
\endcode
By default, the method uses an mitk::eps for floating point comparison, but this can be adapted. It can be necessary to write your own assertion for your own data meeting your special requirements. Recommended examples are all equal test suites for basic data types (mitkImageEqualTest, mitkSurfaceEqualTest and mitkPointSetEqualTest).
\section GeneralTestsExample An example
\include Examples/FirstSteps/NewModule/test/mitkExampleDataStructureTest.cpp
\section GeneralTestsFurtherInfo Further information
-More examples can be found in the corresponding bugsquashing presentation.
+More examples can be found in the corresponding bugsquashing presentation.
*/
\section GeneralTestsDeprecatedOldTestingStyle Deprecated macros
All tests with MITK_TEST_BEGIN(); and MITK_TEST_END(); use the deprecated old MITK testing style. If possible, they should be replaced with the new CppUnit style as explained before. Most of these test classes contain very unfortunate examples and should not be regarded as reference.
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/AboutTesting/AboutTestingPage.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/AboutTesting/AboutTestingPage.dox
index 71f56ac001..bd179e4c49 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/AboutTesting/AboutTestingPage.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/AboutTesting/AboutTestingPage.dox
@@ -1,14 +1,14 @@
/**
\page AboutTestingPage Testing
-Testing is a very important part of ensuring code quality. We use CDash for testing whether MITK builds on a variety of platforms and configurations. You can find our dashboard here.
+Testing is a very important part of ensuring code quality. We use CDash for testing whether MITK builds on a variety of platforms and configurations. You can find our dashboard here.
Additionally we support tests of software function as well. More detailed information on testing in MITK can be found below.
\subpage GeneralTests
\subpage RenderingTests
\subpage DICOMTesting
\subpage InteractionTestingHowTo
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/Architecture.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/Architecture.dox
index 4387b2c242..920d0adbbf 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/Architecture.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/Architecture.dox
@@ -1,47 +1,47 @@
/**
\page Architecture The Architecture of MITK
MITK is an open source software toolkit for medical image processing, subsequent data analysis and integration of medical hardware.
It is designed with the aim of providing a modular and reusable code base to enable rapid development of new features. Following
this design philosophy, MITK includes many specialized modules.
This document is aimed at giving an overview of the general structure of MITK. It will give you an introduction to the coding
and design concepts behind the toolkit.
\section OverviewPage_DesignOverview Design Overview
MITK is designed to be used either as a pure software library or as a complete application framework. Thus, a user
of MITK can decide if he or she simply wants to add a new plug-in to the existing application framework or to implement an
own application by using MITK as a software library. Depending on the type of use MITK uses different software libraries, which is
shown in the next figure for overview.
\imageMacro{MitkOverview.png,"Overview of MITK",16}
As shown above, MITK uses the following libraries.
The Visualization Toolkit (VTK), which provides powerful visualization capabilities
and low-level support for interaction such as picking methods, rotation, movement and scaling of objects.
-
The Common Toolkit (CTK), which focuses on DICOM support and a plug-in framework.
+
The Common Toolkit (CTK), which focuses on DICOM support and a plug-in framework.
-
These are the main libraries MITK is based on. For more functionality you can optionally include other libraries as well. A list of used libraries can be found \ref thirdpartylibs "here" .
Based on these libraries, MITK includes the following features:
High level interactions with data.
Specialized medical imaging algorithms (e.g. segmentation)
Support of 3D + t data.
Complete application framework, expandable by plug-ins
Standard tools for medical imaging as default plug-ins (e.g. measurement, segmentation)
Many specialized modules for different topics on medical imaging (e.g. image guided therapy, live image/ultrasound data processing)
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/FirstSteps/NewDataType.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/FirstSteps/NewDataType.dox
index 6bfdac56cf..d54a5a3686 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/FirstSteps/NewDataType.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/FirstSteps/NewDataType.dox
@@ -1,52 +1,52 @@
/**
\page NewDataTypePage How to create a new custom data type
\tableofcontents
\section NewDataTypePagePrerequisites Prerequisites and further reading
We will use some concepts during this tutorial which we assume you are aware of, as well as taking advantage of infrastructure which needs to be set up. The following is a list of prerequisites which should be present to effectively use this tutorial.
An understanding of the general \ref DataManagementPage
An understanding about the \ref ModularizationPage "modularization of MITK"
We also assume you have created your own module "NewModule" ( \ref NewModulePage )
Some concepts will only be briefly touched upon in this tutorial, for a more concise presentation of these concepts please refer to the following further reading.
A general understanding of how the \ref ReaderWriterPage concept works
If you want to know more about the mitk rendering see \ref QVTKRendering
\section NewDataTypePageCreatingANewDataType Creating a new data type
A new data type needs to derive from mitk::BaseData in order to be handled by the mitk::DataStorage via mitk::DataNode. An example of a very simple data type is provided in the example module. This type encapsulates a string.
\include mitkExampleDataStructure.h
Overloading mitk::Equal to work with your data type will enable you to write simpler, standardized tests.
\section NewDataTypePageAddingReadersAndWriters Adding readers and writers
In order for your data type to be read from and written to disk, you need to implement readers and writers. In order for your readers/writers to be registered and available even if your module has not been loaded (usually after just starting the application), it is advisable to implement them separately in a autoload module. The default location for this is "YourModuleName/autoload/IO".
More information regarding implementing IO and MimeTypes is available at \ref ReaderWriterPage. An example MimeType is implemented for the example data structure.
\include mitkExampleIOMimeTypes.h
\note{ You do not need to create your own class to manage your MimeTypes. Instead they can be defined within the Reader/Writer. }
\section NewDataTypePageAddingMappers Adding a mapper
If your data type needs a special way to render its data for the user, you need to implement a new mapper. More information can be found at \ref QVTKRendering.
If you meet any difficulties during this How-To, don't hesitate to ask on the MITK mailing list mitk-users@lists.sourceforge.net!
People there are kind and will try to help you.
-If you notice that there is an error, or that the code has changed so the way shown here is no longer correct, please open a bug report a http://bugs.mitk.org .
+If you notice that there is an error, or that the code has changed so the way shown here is no longer correct, please open a bug report at https://phabricator.mitk.org/maniphest/ .
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/FirstSteps/NewPlugin.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/FirstSteps/NewPlugin.dox
index 8fdb863ee5..8b5ffda3e2 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/FirstSteps/NewPlugin.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/FirstSteps/NewPlugin.dox
@@ -1,97 +1,96 @@
/**
\page NewPluginPage How to create a new MITK Plugin
The MITK Plugin Generator is a command line tool to simplify the process of creating your own MITK project
-(optional) and plugins. It can either be downloaded here
-or used from an existing MITK build.
+(optional) and plugins.
The Plugin Generator takes the following command line arguments:
\verbatim
./MitkPluginGenerator -h
A CTK plugin generator for MITK (version 1.2.0)
-h, --help Show this help text
-o, --out-dir Output directory (default: /tmp)
-l, --license Path to a file containing license information (default: :/COPYRIGHT_HEADER)
-v, --vendor The vendor of the generated code (default: German Cancer Research Center (DKFZ))
-q, --quiet Do not print additional information
-y, --confirm-all Answer all questions with 'yes'
-u, --check-update Check for updates and exit
-n, --no-networking Disable all network requests
Plugin View options
-vc, --view-class The View's' class name
-vn, --view-name * The View's human readable name
Plugin options
-ps, --plugin-symbolic-name * The plugin's symbolic name
-pn, --plugin-name The plugin's human readable name
Project options
--project-copyright Path to a file containing copyright information (default: :/LICENSE)
--project-name The project name
--project-app-name The application name
[* - options are required]
\endverbatim
If a project name is provided via the --project-name argument, the new plugin will be generated
as part of a new project.
\section NewPluginOnly Creating a new MITK plugin
Here is an example call to the Plugin Generator, creating one plugin with the symbolic name
com.mycompany.myplugin and a View named My View:
\verbatim
./MitkPluginGenerator --plugin-symbolic-name org.mycompany.myplugin --view-name "My View"
\endverbatim
If you did not already specify the final location of the plugin via the --out-dir argument, move the
directory (in our example /tmp/org.mycompany.myplugin) to your existing project. Do not forget to add the
plugin in your project's build system (usually in the file <your-project>/Plugins/Plugins.cmake).
\section NewPluginWithProject Creating a new MITK project
\subsection NewPluginProjectPrerequisites Prerequisites
MITK-based projects created with the Plugin Generator need the same prerequisites as MITK itself. See the
\ref BuildInstructionsPage for MITK for details.
Here is an example call to the Plugin Generator, creating the same plugin as above but integrated in a new project:
\verbatim
./MitkPluginGenerator --plugin-symbolic-name org.mycompany.myplugin --view-name "My View" --project-name "MyProject" --project-app-name "MyApp"
\endverbatim
The generated project is completely self-contained and can be configured via CMake immediately. When building the
generated project, it will first download all required dependencies (like MITK itself). For an explanation of the
project's build directory layout and how to configure MITK from your project's superbuild CMake configuration,
see \ref HowToNewProject.
\subsection NewPluginLimitations Limitations
The Plugin Generator supports only a very limited set of possible configuration options. For more customizations of your
project or plugin, you must familiarize yourself with CMake and the generated build system.
Further, the generator is not able to modify existing projects, it can only create new ones.
\section NewPluginBuildSystem Build system for plugins
Just put new files in your plugin's \c src or \c src/internal directory and edit the \c files.cmake file there.
If you have any fancy stuff like external libraries and include directories you should have a look at the CMake manual and general MITK build system documentation.
\section NewPluginTroubleshooting Troubleshooting
\par I get "Could not find library" messages and similar stuff when I try to start my project's executable.
This is mostly due to wrong environment settings. On Windows, make sure that you use the supplied batch files to start
Visual Studio or your project's executable. If you still get errors, double check the value of the PATH variable in
your batch files (it must contain MITK's binary directory and paths to the ITK, VTK and Qt libraries.
\par
On Linux, set your LD_LIBRARY_PATH variable accordingly.
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/CMakeFAQ.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/CMakeFAQ.dox
index d6ec7bbcae..b63ac30697 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/CMakeFAQ.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/CMakeFAQ.dox
@@ -1,41 +1,41 @@
/**
\page CMAKE_FAQ CMake FAQ
\section CMAKE_FAQ_General A general comment
MITK uses %CMake for configuration. If you want to develop either using MITK as a toolkit or by extending the capabilities of the applications provided by us, we recommend using %CMake for your own project too.
While it might be possible to use MITK in conjunction with other options, such as QMake or setting up your own project manually it will invariably involve a lot of work and probably hacks as well.
As we do have no experience with this, we will not be able to help you.
Be prepared to do a lot of tweaking on by yourself.
-This guide does not try to give a general introduction to CMake, instead it tries to answer some basic questions that might arise for those new to %CMake, to help you get started on MITK. For a more comprehensive introduction on %CMake see here.
+This guide does not try to give a general introduction to CMake, instead it tries to answer some basic questions that might arise for those new to %CMake, to help you get started on MITK. For a more comprehensive introduction on %CMake see here.
We will assume in this guide, that the path to your source is /MITK/.
\section CMAKE_FAQ_Question Basic Questions
\subsection CMAKE_FAQ_Question_WhereGetIt Where do I get CMake and what version do I need?
See \ref BuildInstructions_Prerequisites.
\subsection CMAKE_FAQ_Question_NewPluginNothing I coded a new plugin for the Workbench and nothing happened. Why?
The correct way to create a new plugin is described in \ref NewPluginOnly. Do note that you need to move the source to the MITK/Plugins directory and you will have to add the plugin to the config file (most likely MITK/Plugins/Plugins.cmake). After that see \ref CMAKE_FAQ_Question_HowDoIActivatePlugin.
\subsection CMAKE_FAQ_Question_HowDoIActivatePlugin I want to use a plugin, how do I activate it?
Start %CMake
Configure
Set the variable MITK_BUILD_\ to TRUE
Configure again
Generate
Start a build using your development environment
\subsection CMAKE_FAQ_Question_HowDoIActivateModule I want to use a module, how do I activate it?
Modules are build automatically if a plugin that requires them is activated. See \ref CMAKE_FAQ_Question_HowDoIActivatePlugin.
\subsection CMAKE_FAQ_Question_HowOwnToolkits MITK always downloads the toolkits, but I want to use my own.
This is covered in \ref HowToNewProjectCustomizingMITKConfigure.
\subsection CMAKE_FAQ_Question_HowOwnProjectMITK I want to use an MITK plugin in my own project but I can not find it.
See \ref HowToNewProjectAddingMITKFunctionality.
-*/
\ No newline at end of file
+*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Coding.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Coding.dox
index ecf1e27618..21d8b77d3b 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Coding.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Coding.dox
@@ -1,53 +1,53 @@
/**
\page CodingPage Coding
\section CodingPageGeneral General Information
-Conceptually MITK is mainly geared to ITK (The Insight Toolkit).
+Conceptually MITK is mainly geared to ITK (The Insight Toolkit).
Thus, most of the ITK coding concepts can be transferred to MITK.
-The ITK coding concepts can be found in the free ITK software guide, downloadable at ITKs homepage.
+The ITK coding concepts can be found in the free ITK software guide.
The main ITK concepts which one should look into before using MITK are:
SmartPointers
Pipelining and Filters
\section CodingPageStyle Coding Style
MITK provides coding style guidelines. When implementing code which should be added to the project,
these guidelines should be followed in order to keep a unified coding style all over MITK. The style
is geared to a common c++ coding style combined with some extension of used libraries, e.g. the use of
itk smart pointers. The MITK style guide is provided on the page \ref StyleGuideAndNotesPage .
If you are new to coding with MITK please also consider that MITK is using different pre defined macros,
which might look confusing. An overview on these macros is given in section \ref CodingPageMITKMacros.
\section CodingPageMITKMacros Macros in MITK
MITK uses different macros to simplify implementation, but these macros might look confusing at first. Some
of these macros are derived from ITK, others are defined in MITK itself. The most important macros are defined
in the file mitkCommon.h, but there are some other headers which also define macros, e.g. mitkTestingMacros.h
and mitkExceptionMacros.h.
In the following the most important macros are shown for overview, more details are available in the corresponding header files.
\code
//These macros come from ITK:
itkNewMacro(Class);//this macro creates the constructor for smart pointers
//it calls the default c++ constructor of the class
//the default constructor should be declared protected
itkFactorylessNewMacro(Class); //like the itkNewMacro macro but does not use object factories
itkGetMacro(Name,Class); //these macros create getters and setters
itkSetMacro(Name,Class); //automatically, but you need the corresponding
itkGetConstMacro(Name,Class); //member variable m_Name in your class
itkSetConstMacro(Name,Class);
//The following macros are defined in MITK itself:
mitkClassMacro(Class,Superclass); //macro is needed in every header of a MITK class
mitkNewMacro1Param(Class,ParamType); //like the ITK new macro, but with one parameter
//you need a constructor with one parameter as well
//the same macro exists for 2,3 and 4 parameters
mitkExceptionClassMacro(Class,Superclass); //special macro for MITK exception classes
\endcode
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/DocumentationExample.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/DocumentationExample.dox
index 9dcd711aad..0ac05f6a34 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/DocumentationExample.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/DocumentationExample.dox
@@ -1,22 +1,22 @@
/**
\page DocumentationExample Example Class Documentation
This page will try to give an example of some of the most commonly used commands and techniques for documenting
your code using doxygen. The corresponding source file can be found \ref DocumentationExampleTheSourceFile "below".
For the generated documentation page see DocumentationExample .
\section DocumentationExampleAdvanced Advanced Doxygen Usage
For more information on doxygen and its use you can take a look at one of the following resources.
\section DocumentationExampleTheSourceFile The Source File
\verbinclude DocumentationExample.h
-*/
\ No newline at end of file
+*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/StyleGuideAndNotes.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/StyleGuideAndNotes.dox
index b8432d91e4..6ad26976e2 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/StyleGuideAndNotes.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/StyleGuideAndNotes.dox
@@ -1,467 +1,466 @@
/**
\page StyleGuideAndNotesPage The MITK Style Guide and Technical Notes
\tableofcontents
The following document is a description of the accepted coding style for the Medical Imaging Interaction Toolkit (MITK). Developers who wish to contribute code to MITK should read and adhere to the standards described here.
\section StyleGuideAndNotesPage_NameConventions Naming Conventions
\li Using case change to indicate separate words
@code
ImageFilter
PixelType
DataStorage
NodePredicateProperty
@endcode
\li Underscores are not used e.g. Image_Filer, _Node
\li Variable names should convey the meaning behind the code
@code
BoundingBox::Pointer boundingBox = BoundingBox::New();
@endcode
\li Names are generally spelled out
@code
mitk::DataNode* node;
@endcode
\li Abbreviation are allowable when in common use e.g. ROI for Region of
Interest
\subsection StyleGuideAndNotesPage_NamingClasses Naming Classes
\li Classes are named beginning with a capital letter
\li Classes are named according to the following general rule:
@code
class name =
@endcode
\li Examples of concepts \n
Accessor: Access and convert between types e.g. NullScalarAccessor \n
Container: A container of objects such as points or images e.g. VectorContainer \n
Filter: A class that participates in the data processing pipeline e.g. AddImageFilter \n
Mapper: Transform data from one form into another e.g. ContourMapper2D \n
Reader/Writer: A class that reads/writes a single data object e.g. VtkSurfaceReader \n
\subsection StyleGuideAndNotesPage_NamingFiles Naming Files
\li MITK classes like @a ExampleClass should be in namespace @a mitk and their corresponding files should be named @a mitkExampleClass.h/.cpp.
@code
mitk::DataStorage
@endcode
\li Qt specific MITK classes like @a QmitkListView should have the prefix Qmitk in their class names and their corresponding files should be named @a QmitkListView.h/.cpp.
@code
QmitkDataStorageComboBox
@endcode
\li Header Files ends with an .h and
\li Implementation Files with an .cpp or .txx for a template class
\subsection StyleGuideAndNotesPage_NamingMethodsandFunctions Naming Methods and Functions
\li Functions and methods are named beginning with a capital letter
\li Referring to class methods in code, an explicit this-> pointer should be
used
@code
mitk::DataStorage::SetOfObjects::ConstPointer all = this->GetAll();
@endcode
\subsection StyleGuideAndNotesPage_NamingSignalSlots Naming Signal/Slots Methods and Functions
\li Slots are named according to the following general rule
@code
On[variable name who send the signal][signal]();
@endcode
\li Example
@code
connect( loadImagePushButton, SIGNAL( clicked(bool ) ),
SLOT( OnLoadImagePushButtonClicked( bool ) ) );
void mitk::Image::OnLoadImagePushButtonClicked( bool )
{
... Do something ...
}
@endcode
\li Signals are named according to the following general rule
@code
Signal[MethodName]();
@endcode
\li Example
@code
emit SignalFinishedSegmentation();
@endcode
\subsection StyleGuideAndNotesPage_NamingClassDataMembers Naming Class Data Members
\li Class data members are prefixed with m_
@code
m_Volumes
m_OffsetTable
m_ImageMask
@endcode
\li An exception to this rule, Qt class Data members are not prefixed and begin with a lower-case letter
@code
loadImageButton
closeImageAction
@endcode
\subsection StyleGuideAndNotesPage_NamingLocalVariables Naming Local Variables
\li Local variables first letter is lower-case
@code
offset
data
slicesIt
@endcode
\subsection StyleGuideAndNotesPage_NamingQtVariables Naming Qt Variables
\li GUI variables ends with name of used QT tool.
@code
QPushButton* loadImagePushButton;
QAction* closeImageAction;
QCheckBox* hideImageCheckBox;
QRadioButton* binaryImageRadioButton;
@endcode
\subsection StyleGuideAndNotesPage_NamingTypedefs Naming Typedefs
\li Typedefs must end in the word Type
@code
typedef TPixel PixelType;
typedef itk::Image< TPixel, VImageDimension > ImageType;
typedef std::list ImageListType;
@endcode
\section StyleGuideAndNotesPage_Pointer Pointer
\subsection StyleGuideAndNotesPage_DeclarationofPointers Declaration of Pointers
\li Position of * pointers are connected with the variable
@code
int *counter;
@endcode
\li Analog to references
@code
int &counter;
@endcode
\subsection StyleGuideAndNotesPage_SmartPointer SmartPointer
\li SmartPointers must be used for classes that have itk::Object as a base
class.
\li Assignment of a just created instance to a normal pointer results in a
crash, since the reference count is decreased immediately to zero and the
object is destroyed.
@code
itk::Object::Pointer object = itk::Object::New();
@endcode
\li Static declarations are also forbidden and result into an exception when
the scope of the variable is left, because the destructor is called while the
reference count is still greater than zero.
\li Note that using smart pointers requires using real (normal) pointers when
setting input. If you want to return a newly created smart pointer that
is not also kept within the class (e.g., if you write a Clone method), you
have to return a smart pointer on output (compare itkMacro.h). If the
smart pointer is kept within the class, returning a real (normal) pointer
is sufficient.
\li Testing a SmartPointer against NULL is done with the IsNull() and Is-
NotNull() methods. A simple ==NULL issues a warning.
\section StyleGuideAndNotesPage_Namespace Namespace
\li MITK classes should be in namespace @a mitk
@code
mitk::Image::Pointer mitk::ImageGenerator::MakeImage()
{
// already in namespace mitk here!
Image::Pointer image = mitk::Image::New();
ImageDecorator::Pointer decorator = mitk::ImageDecorator::New();
d->Decorate( image );
return image;
}
@endcode
\li Constants in MITK for mitk::Operation and mitk::Action are set in
namespace, so don't forget to add prefix mitk::
@code
switch (actionId)
{
case mitk::AcMOVESELECTED:
....Do something ...
break;
default:
break;
}
@endcode
\section StyleGuideAndNotesPage_CodeLayoutandIndentation Code Layout and Indentation
\subsection StyleGuideAndNotesPage_GeneralLayout General Layout
\li Each line of code should take no more than 120 characters.
\li Use lots of whitespace to separate logical blocks of code, intermixed with
comments
\li DO NOT USE TABS. The standard indention is 2 spaces (see ITK Style Guide). Configure your
editor accordingly.
\li DO NOT USE trailing whitespaces
\li Declaration of variables should be one declaration per line
@code
int sliceNumber;
char* stringName;
ImageType::Pointer image;
@endcode
\subsection StyleGuideAndNotesPage_ClassLayout Class Layout
\li Copyright
@code
/*============================================================================
The Medical Imaging Interaction Toolkit (MITK)
Copyright (c) German Cancer Research Center (DKFZ)
All rights reserved.
Use of this source code is governed by a 3-clause BSD license that can be
found in the LICENSE file.
============================================================================*/
@endcode
\li Includes [A .. Z]
@code
#include "... .h"
@endcode
\li Namespace
@code
namespace mitk
{
@endcode
DO NOT litter your header with "using namespace;"!
\li Class (Template)
@code
template
class ClassName : public ImageBase
{
@endcode
\li Typedefs
@code
public:
....typedefs....
@endcode
\li Methods
@code
public:
....methods....
protected:
....methods....
private:
....methods....
@endcode
\li QT Signals
@code
signals:
Signal...();
@endcode
\li QT Slots
@code
public slots:
On...();
protected slots:
On...();
@endcode
\li Data Member
@code
private/protected:
....class data members....
};
}
#endif
@endcode
\section StyleGuideAndNotesPage_UseofBraces Use of Braces
\li Used to delimit the scope of an if, for, while, switch.
\li Braces are placed on a line by themselves:
@code
for ( unsigned int i = 0; i < 3; ++i )
{
... do something ...
}
@endcode
or
@code
if ( condition )
{
... do something ...
}
else if ( other condition )
{
... do something ...
}
else
{
... do something ...
}
@endcode
\li You can choose to use braces on a line with a code block when the block
consists of a single line:
@code
if ( condition ) { foo = 1; }
else if ( condition2 ) { foo = 3; }
else { return; }
@endcode
or
@code
for ( unsigned int i = 0; i < 3; ++i) { x[i] = 0.0; }
@endcode
\section StyleGuideAndNotesPage_IncludeGuards Include Guards
\li \#include guard is a particular construct used to avoid the problem of
double inclusion when dealing with the \#include directive.
\li Naming convention for \#include guards is: ClassName_h
\li Following example demonstrates a problem that can arise if \#include guards
are missing: Here, the file child.cpp has indirectly included two copies of the text in the
header file grandfather.h. This causes a compilation error, since the structure
type foo is apparently defined twice.
@code
grandfather.h struct foo
{
int m Member;
};
father.h #include "grandfather.h"
child.h #include "grandfather.h"
#include "father.h"
@endcode
\subsection StyleGuideAndNotesPage_Useofincludeguards Use of \#include guards
\li Here, the first inclusion of grandfather.h causes the macro grandfather h to
be defined. Then, when child.cpp includes grandfather.h the second time,
the \#ifndef test fails, and the preprocessor skips down to the \#endif, thus
avoiding the second definition of struct foo. The program compiles correctly.
@code
grandfather.h #ifndef grandfather h
#define grandfather h
struct foo
{
int m Member;
};
father.h #include "grandfather.h"
child.h #include "grandfather.h"
#include "father.h"
@endcode
\section StyleGuideAndNotesPage_TechnicalNotes Some Technical Notes
\li Use forward declarations in header files wherever possible. Only include those header files in a header file
that are really necessary. Include the rest in the implementation file.
\li For classes inheriting directly or indirectly from @a itk::LightObject (most of the MITK-classes do so), the
class definition should include the mitkClassMacro. Additionally, if the class can be instantiated (normally the case,
if the class is not abstract) and has @em only a constructor without parameters, the constructor should be declared
protected and the @a itkFactorylessNewMacro should be used to create a @a New() method for instantiation. Here is an example:
@code
class ExampleClass : public SuperClassOfTheExampleClass
{
public:
mitkClassMacro(ExampleClass, SuperClassOfTheExampleClass)
itkFactorylessNewMacro(Self)
[...]
protected:
ExampleClass();
virtual ~ExampleClass();
}
@endcode
\li Set- and Get-methods can be created with the macros @a itkSetObjectMacro(name,type) and
@a itkGetObjectMacro(name,type), respectively, if the @a type is derived from @a itk::LightObject or
-@a itk::Object. There are also macros for other types, e.g., strings, see
-itkMacro.h.
+@a itk::Object.
\li When using inner classes of a parent class which is templated, you have
to use the keyword @a typename for gcc 3.x and standard compliance. For example,
@a TreeChangeListener is an inner class of @a Tree, therefore use:
@code
class LinkedTree : public Tree
{
public:
typedef typename LinkedTree::TreeChangeListener TreeChangeListener;
[...]
}
@endcode
Another example:
@code
typename std::vector::iterator pos = treeChangeListenerList.begin();
@endcode
@a iterator is an inner class of @a vector.
\li Constants in MITK for mitk::Operation and mitk::Action are set in namespace, so don't forget to add prefix @a mitk::
@code
switch (actionId)
{
case mitk::AcMOVESELECTED:
@endcode
Prefixes for the constants are to be used like corresponding others. See file @a Interactions\\mitkBaseInteraction\\mitkInteractionConst.h for further details.
\section StyleGuideAndNotesPage_AutomaticCodeFormatting Automatic Code Formatting
We offer a .clang-format file, which can be used to automatically format code acceptably.
-For an explanation of the different options check out http://clang.llvm.org/docs/ClangFormatStyleOptions.html
+For an explanation of the different options check out https://clang.llvm.org/docs/ClangFormatStyleOptions.html
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step01.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step01.dox
index b37513c15c..31959c88f0 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step01.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step01.dox
@@ -1,27 +1,27 @@
/**
\page Step01Page MITK Tutorial - Step 1: Displaying an image
\li Path to files used in this step: \n
-http://mitk.org/download/tutorial-data/Pic3D.nrrd
+https://www.mitk.org/download/tutorial-data/Pic3D.nrrd
\imageMacro{step1_result.png,"",6.22}
Open your IDE. All steps can be found among the listed projects.
The first program shows how to display an image in a 2D view. The picture above is a screenshot of the program.
The program has to be executed using the image file Pic3D.nrrd.
If you are using Visual Studio start MITK.sln in your bin\\ subdirectory to start it with all required paths set.
To set the image file path in Visual Studio, right click on "MitkStep1"-project and go to 'Properties -> Configuration Properties -> Debugging'.
Now insert the image file path to Pic3D.nrrd in the "Command Arguments" text field.
Then right click on the "MitkStep1"-project again and select "Set as StartUp Project". Start to run the code. Use this also in the following steps.
\imageMacro{configureVisualStudioProperties.png,"",11.85}
The code is divided into parts I through V. First of all a DataTree has to be created. Then data has to be read from a file which afterwards has to be put into the tree. Part IV creates a window and passes the tree to it. The last part deals with some Qt-specific initialization.
\include Step1.cpp
\ref Step00Page "[Previous step]" \ref Step02Page "[Next step]" \ref TutorialPage "[Main tutorial page]"
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step02.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step02.dox
index 4d64b09c38..849f9b41bd 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step02.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step02.dox
@@ -1,29 +1,29 @@
/**
\page Step02Page MITK Tutorial - Step 2: Load one or more data sets
\li \ref Step2.cpp "Step2.cpp" \n
Contains the code for this example.
\li Path to files used in this step: \n
-http://mitk.org/download/tutorial-data/Pic3D.nrrd (image) \n
-http://mitk.org/download/tutorial-data/lungs.vtk (surface)
+https://www.mitk.org/download/tutorial-data/Pic3D.nrrd (image) \n
+https://www.mitk.org/download/tutorial-data/lungs.vtk (surface)
\image html step2_result.png
\dontinclude Step2.cpp
This program shows how to load multiple data sets.
The picture above shows the result of the program when reading both the image file and the surface file.
In order to obtain the result the program has to be executed using the image file Pic3D.nrrd and the surface file lungs.vtk.
The code for this example equals the code of Step 1 except for part II and part III which are changed as follows:
\skipline Part II
\until mitk::IOUtil::Load(argv[i],*storage);
\line }
\ref Step01Page "[Previous step]" \ref Step03Page "[Next step]" \ref TutorialPage "[Main tutorial page]"
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step03.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step03.dox
index 606a7bf27e..67ed0d56ad 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step03.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step03.dox
@@ -1,49 +1,49 @@
/**
\page Step03Page MITK Tutorial - Step 3: Create 3D view
\li \ref Step3.cpp "Step3.cpp" \n
Contains the code that both creates a 3D view and turns volume rendering on.
\li Path to files used in this step: \n
-http://mitk.org/download/tutorial-data/Pic3D.nrrd (image) \n
-http://mitk.org/download/tutorial-data/lungs.vtk (surface)
+https://www.mitk.org/download/tutorial-data/Pic3D.nrrd (image) \n
+https://www.mitk.org/download/tutorial-data/lungs.vtk (surface)
As in the previous step, one or more data sets (many images, surface and other formats) may be loaded. The difference is that they are displayed in a 3D view.
The QmitkRenderWindow is now used for displaying a 3D view, by setting the used mapper-slot to Standard3D.
Since volume-rendering is a (rather) slow procedure, the default is that images are not displayed in the 3D view.
\li Step 3a works for default condition for surface mesh. To run this tutorial with Step 3a, pass the argument as "lungs.vtk" (without quotes).
\li Step 3b works for surface mesh with volume rendering. To run this tutorial with Step 3b, pass the arguments as "Pic3D.nrrd lungs.vtk" (without quotes).
\section Step3aSection Step 3a - Volume rendering turned off
\imageMacro{step3a_result.png,"",6.22}
\dontinclude Step3.cpp
Tell the renderer to create a 3D view:
\skipline // Use it as a 3D view!
\skipline renderWindow.GetRenderer()->SetMapperID
The rest of the code remains unchanged.
The picture above shows the result of the program when reading both the image and the surface file.
As volume rendering is off the image is not visible.
\section Step3bSection Step 3b - Volume rendering turned on
\imageMacro{step3b_result.png,"",6.22}
Volume Rendering is now turned on as shown in the picture above.
\dontinclude Step3.cpp
The property "volumerendering" has to be enabled on the node containing the image.
\skipline Check
\until node->SetProperty
\ref Step02Page "[Previous step]" \ref Step04Page "[Next step]" \ref TutorialPage "[Main tutorial page]"
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step04.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step04.dox
index 32ec61e7c2..3eec800c47 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step04.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step04.dox
@@ -1,69 +1,69 @@
/**
\page Step04Page MITK Tutorial - Step 4: Use several views to explore data
\li \ref Step4.cpp "Step4.cpp"\n
Contains the code of step 4a + b.
\li Path to files used in this step: \n
-http://mitk.org/download/tutorial-data/Pic3D.nrrd (image) \n
-http://mitk.org/download/tutorial-data/lungs.vtk (surface)
+https://www.mitk.org/download/tutorial-data/Pic3D.nrrd (image) \n
+https://www.mitk.org/download/tutorial-data/lungs.vtk (surface)
As in Step 2 and Step 3 one or more data sets may be loaded.
This now creates three views on the data.
The QmitkRenderWindow is used for displaying a 3D view as in Step 3, but without volume-rendering.
Furthermore two 2D views for slicing through the data are created.
The class QmitkSliceWidget is used, which is based on the class QmitkRenderWindow, but additionally provides sliders to slice through the data. We create two instances of
QmitkSliceWidget, one for axial and one for sagittal slicing.
Step 4b enhances the program in that the two slices are also shown at their correct position in 3D as well as intersection-line, each in the other 2D view.
As in the previous steps, to obtain the result the program has to be executed using the image file Pic3D.nrrd and the surface file lungs.vtk.
\section Step4aSection Step 4a - Create axial and sagittal view
\imageMacro{step4a_result.png,"",11.01}
\dontinclude Step4.cpp
Create a Qt horizontal box for the layout:
\skipline QHBox
Then create a renderwindow:
\skipline QmitkRenderWindow
\until SetMapperID
Create a 2D view for slicing axially:
\skipline view2
\until view2.SetData
Then create a 2D view for slicing sagitally.
\skipline view3
\until view3.SetData
The toplevelWidget is now the new main widget:
\skipline qtapplication
\skipline toplevelWidget.show
\section Step4bSection Step 4b - Display slice positions
\imageMacro{step4b_result.png,"",11.01}
We now want to see the position of the slice in 2D and the slice itself in 3D.
Therefore it has to be added to the tree:
\dontinclude Step4.cpp
\skipline ds->Add(view2.GetRenderer()
\skipline ds->Add(view3.GetRenderer()
Slice positions are now displayed as shown in the picture.
\dontinclude Step4.cpp
\ref Step03Page "[Previous step]" \ref Step05Page "[Next step]" \ref TutorialPage "[Main tutorial page]"
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step05.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step05.dox
index 88b5e6dfad..07b2b344b7 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step05.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step05.dox
@@ -1,40 +1,40 @@
/**
\page Step05Page MITK Tutorial - Step 5: Interactively add points
\li \ref Step5.cpp "Step5.cpp"\n
Contains the code for this step.
\li Path to files used in this step: \n
-http://mitk.org/download/tutorial-data/Pic3D.nrrd (image) \n
-http://mitk.org/download/tutorial-data/lungs.vtk (surface)
+https://www.mitk.org/download/tutorial-data/Pic3D.nrrd (image) \n
+https://www.mitk.org/download/tutorial-data/lungs.vtk (surface)
In addition to Step 4 where 3 views were created on the data, we now want to interactively add points.
A node containing a PointSet as data is added to the data tree and a PointSetDataInteractor is associated with the node, which handles the interaction.
The @em interaction @em pattern is defined in a state-machine, stored in an external XML file. Thus, we need to load a state-machine.
A state machine describes interaction pattern with different states (states beeing something like "a point is selected") and transitions to these states (e.g. "select a point").
These transitions are associated with actions. In this way it is possible to model complex interaction schemes.
By what these transitions and actions are triggered is described in a configuration file. It maps user events to identifiers that are used in the state machine patterns.
In this way the user interaction can be changed by simply loading a different configuration file for a state machine, and the user may add points now with a right click instead of
left click + SHIFT, as in our case.
Therefore after loading the state machine pattern the PointSetDataInteractor is also given a event configuration file.
More information about interaction in MITK can be found \ref InteractionPage "here".
In order to add a point the shift key has to be pressed while left clicking in a render window.
You can also move points or remove them (left click while pressing ALT).
\image html step5_result.png
\dontinclude Step5.cpp
A PointSet and a node for it have to be created to be able to interactively adding points:
\skipline mitk::PointSet
\until interactor->SetDataNode(pointSetNode)
\ref Step04Page "[Previous step]" \ref Step06Page "[Next step]" \ref TutorialPage "[Main tutorial page]"
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step06.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step06.dox
index 9ca0db2336..f4aa9a82c9 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step06.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step06.dox
@@ -1,117 +1,117 @@
/**
\page Step06Page MITK Tutorial - Step 6: Use an interactive region-grower
The source is now split among several files:
\li \ref Step6.cpp "Step6.cpp"
\li \ref Step6.h "Step6.h"
\li \ref Step6RegionGrowing.txx "Step6RegionGrowing.txx"
\li \ref Step6RegionGrowing1.cpp "Step6RegionGrowing1.cpp"
\li \ref Step6RegionGrowing2.cpp "Step6RegionGrowing2.cpp"
\li \ref Step6main.cpp "Step6main.cpp"
\li Path to files used in this step: \n
-http://mitk.org/download/tutorial-data/Pic3D.nrrd (image)
+https://www.mitk.org/download/tutorial-data/Pic3D.nrrd (image)
In this step the program is enhanced by the possibility to start a region-grower at interactively added points.
We will see how MITK images can be accessed as ITK images.
We now load the image file Pic3D.nrrd only since the surface will be the result of the region-growing.
Add points in the image by pressing SHIFT+left mouse key, then adjust the thresholds and press 'Start region growing'.
\imageMacro{step6_result.png,"",13.55}
The class Step6 inherits from QWidget and provides methods for setting up the widgets.
Step6RegionGrowing.cpp contains a method for performing the region-growing. Step6main.cpp contains main.
Like in ITK and VTK class member names start with m_ followed by the proper member name starting with a capital letter (e.g. m_Tree).
Function names start with capital letters. To learn more about style conventions in MITK read \ref StyleGuideAndNotesPage "The MITK Style Guide".
\dontinclude Step6.cpp
The widgets are initialized as in the previous steps but with an additional QVBox for a button to start the segmentation:
\skipline Create controlsParent
\until hlayout->addWidget(m_LineEditThresholdMax)
This creates a button to start the segmentation and its clicked() signal is connected to the method StartRegionGrowing():
\dontinclude Step6.cpp
\skipline QPushButton *startButton
\skipline connect(startButton
\section AccessMTIKImagesAsITKImagesSection Access MITK images as ITK images
ITK images are templated whereas mitk::Images are not. To use ITK filters with MITK images, we have to convert from MITK to ITK. To do so, first
define an access method, which is templated as an ITK image is:
\code
template
MyAccessMethod(itk::Image* itkImage)
{
...
}
\endcode
If you don't understand this template syntax, you should read any C++ text book. Understanding template syntax is crucial to successfully using ITK.
To call this templated method with an (untemplated) mitk::Image, you can use the AccessByItk macro from mitkImageAccessByItk.h. This macro checks for
the actual image type of the mitk::Image and does any neccessary conversions. Look into "Modules / Adaptor classes" for more information.
\code
AccessByItk(mitkImage, MyAccessMethod)
\endcode
\dontinclude Step6RegionGrowing.txx
In this step our access method is called RegionGrowing() (defined in \ref Step6RegionGrowing.txx "Step6RegionGrowing.txx"):
\skipline template
\until } //RegionGrowing()
Additionally the access function has to be instantiated for all datatypes and two/three dimensions as some compilers have memory problems without this explicit instantiation, some even need instantiations in separate files for 2D/3D: \n
For 2D in \ref Step6RegionGrowing1.cpp "Step6RegionGrowing1.cpp" :
\dontinclude Step6RegionGrowing1.cpp
\skipline InstantiateAccessFunctionForFixedDimension
... and for 3D in \ref Step6RegionGrowing2.cpp "Step6RegionGrowing2.cpp":
\dontinclude Step6RegionGrowing2.cpp
\skipline InstantiateAccessFunctionForFixedDimension
\dontinclude Step6.cpp
The method StartRegionGrowing() finally calls our access method RegionGrowing():
\skipline Step6::StartRegionGrowing
\until }
\section ConvertingITKMITKSection Converting ITK images to MITK images and vice versa
In some cases it is useful to simply convert between ITK and MITK images. The direction ITK to MITK is easy, since mitk::Image can handle most data types. The direction MITK to ITK is more critical, since ITK images have to be instantiated with a fixed pixel type and fixed dimension at compile time.
\li \code mitk::Image mitk::ImportItkImage(itk::Image<...>) \endcode
\li \code mitk::CastToItkImage(mitkImage, itk::Image<...>) \endcode
\section ConnectingMITKToVTKSection Connecting MITK images to VTK
Images are not converted or copied: The data array is just accessed via an encapsulating VTK object.
\li \code vtkImageData* mitk::Image::GetVtkImageData(int time = 0) \endcode
\section SurfacesMITKToVTKSection MITK Surfaces to VTK and vice versa
Again: not a conversion, just accessing.
\li \code vtkPolyData* mitk::Surface::GetVtkPolyData(int time = 0) \endcode
\li \code mitk::Surface::SetVtkPolyData(vtkPolyData*, int time = 0) \endcode
\ref Step05Page "[Previous step]" \ref Step07Page "[Next step]" \ref TutorialPage "[Main tutorial page]"
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step07.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step07.dox
index 91827ef670..318d8faa76 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step07.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step07.dox
@@ -1,21 +1,21 @@
/**
\page Step07Page MITK Tutorial - Step 7: Convert result of region growing into a surface
\li \ref Step7.cpp "Step7.cpp"\n
\li \ref Step7.h "Step7.h"\n
\li \ref Step7main.cpp "Step7main.cpp"\n
\li Path to files used in this step: \n
-http://mitk.org/download/tutorial-data/Pic3D.nrrd (image)
+https://www.mitk.org/download/tutorial-data/Pic3D.nrrd (image)
In this step the result of the previous step is converted into a surface by means of a VTK filter.
Step7 inherits from Step6. It enhances the method StartRegionGrowing() by processing the result image.
\dontinclude Step7.cpp
\skipline if (m_ResultImage
\until }
\ref Step06Page "[Previous step]" \ref Step08Page "[Next step]" \ref TutorialPage "[Main tutorial page]"
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step08.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step08.dox
index d4de241f01..565524c888 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step08.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step08.dox
@@ -1,25 +1,25 @@
/**
\page Step08Page MITK Tutorial - Step 8: Use QmitkStdMultiWidget as widget
\li \ref Step8.cpp "Step8.cpp"\n
\li \ref Step8.h "Step8.h"\n
\li \ref Step8main.cpp "Step8main.cpp"\n
\li Path to files used in this step: \n
-http://mitk.org/download/tutorial-data/Pic3D.nrrd (image)
+https://www.mitk.org/download/tutorial-data/Pic3D.nrrd (image)
In this step a QmitkStdMultiWidget is used. It offers four views of the data.
From top left to bottom left the views are initialized as axial, sagittal and coronar. The bottom right view is initialized as 3D view.
\image html step8_result.png
Step8 inherits from Step6. The method SetupWidgets() is changed: A QmitkStdMultiWidget is used instead of one QmitkRenderWindow and two instances of QmitkSliceWidget.
\dontinclude Step8.cpp
\skipline Part Ia
\until levelWindowWidget->SetDataStorage(m_DataStorage);
\ref Step07Page "[Previous step]" \ref Step09Page "[Next step]"
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step09.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step09.dox
index 30574b17d4..e3da27c87c 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step09.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Step09.dox
@@ -1,80 +1,80 @@
/**
\page Step09Page MITK Tutorial - Step 9: A plug-in
MITK uses a very modular concept to maximize reusability and portability. A MITK application based on the BlueBerry
application framework (for example the MITK Workbench) consists of several bundles (or plug-ins). A bundle can contain
resources and program logic. It can also contribute so-called Views to the main application, which provide a specific
user interface for controlling the bundles functions.
The creation of a MITK plug-in is considerably facilitated by using the MITK PluginGenerator as described in \ref NewPluginPage if you want to add a new view to an existing plugin see \ref NewViewPage.
The mentioned tool was used to create a plug-in called org.mitk.example.gui.regiongrowing.
Let's first take a look at which files the PluginGenerator has created:
\verbatim
documentation\doxygen\
modules.dox......................... Doxygen file for documenting your plug-in
resources\
icon.png............................ The icon of your plug-in. GIMP or other programs (including your text editor)
can be used to change this
src\internal\
QmitkRegionGrowingView.cpp.......... The most important file, implementing behaviour
QmitkRegionGrowingView.h............ Header file of the functionality
QmitkRegionGrowingViewControls.ui... XML file of the Qt Designer, describes buttons, combo boxes, etc. of your controls
CMakeLists.txt \...................... Build system related files for CMake
files.cmake /
manifest_headers.cmake................ Information about your plug-in
plugin.xml ........................... BlueBerry integration
\endverbatim
If you are not familiar with Qt development, please look into
-this Qt company page describing .ui files (no, forget about the please, DO it!)
+this Qt company page describing .ui files
The C++ files implement a subclass of QmitkAbstractView. In this special case of QmitkRegionGrowing, we added the option to set some seed points and run a region grower. If you are interested in the concrete changes necessary to turn a freshly generated QmitkRegionGrowing into an integrated one:
The plug-in will be build as part of MITK Workbench. Do use it start MITK Workbench an select the region growing view in the view menu.
To add a mitk::PointSet for the seed points:
QmitkRegionGrowingView.h
Add includes and forward declarations:
\snippet QmitkRegionGrowingView.h includes
Add the point set and a pointer to a QmitkPointListWidget as a private member:
\snippet QmitkRegionGrowingView.h members
QmitkRegionGrowingView.cpp
CreateQtPartControl():
\snippet QmitkRegionGrowingView.cpp cpp-createqtpartcontrol
To use the ITK region grower:
QmitkRegionGrowingView.h
Add the private method:
\snippet QmitkRegionGrowingView.h itkimageprocessing
QmitkRegionGrowingView.cpp
Add includes:
\snippet QmitkRegionGrowingView.cpp cpp-includes
DoImageProcessing():
\snippet QmitkRegionGrowingView.cpp cpp-doimageprocessing
And add the new method:
\snippet QmitkRegionGrowingView.cpp cpp-itkimageaccess
Have fun using MITK!
If you meet any difficulties during your first steps, don't hesitate to ask on the MITK mailing list mitk-users@lists.sourceforge.net!
People there are kind and will try to help you.
\ref Step08Page "[Previous step]" \ref Step10Page "[Next Step]" \ref TutorialPage "[Main tutorial page]"
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Tutorial.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Tutorial.dox
index 602e1fb0f5..d0a5a7a5fe 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Tutorial.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/GettingToKnow/Tutorial/Tutorial.dox
@@ -1,49 +1,49 @@
/**
\page TutorialPage The MITK Tutorial
If you have set up and compiled MITK already and want to know more about developing with MITK you might want to read the \ref TutorialSection. If you want help setting up MITK and creating your own project using MITK you should take a look at \ref HowToNewProject.
\section TutorialFirstSteps First steps in MITK
If you are absolutely new to MITK you might want to read up on setting up MITK to use in your development. The following pages will help you in this task.
\subpage HowToNewProject "A comprehensive guide to setting up your own MITK project"
\ref BuildInstructionsPage "Building MITK"
\ref CMAKE_FAQ
\section TutorialSection Tutorial chapters
This tutorial will give you an introduction to developing with MITK.
We will start with configuring MITK to compile the tutorial, continue to show how to
display and do basic interaction with images, and finally show how to build a plug-in and add new interactions.
The source code of the examples can be found in Examples/Tutorial/ \n
Visit \ref TroubleshootingPage for a guide to miscellaneous issues and their resolution. \n
Two data files are used to execute the example code.
\li Pic3D.nrrd \n
-This file contains an image and can be downloaded from http://mitk.org/download/tutorial-data/Pic3D.nrrd .
+This file contains an image and can be downloaded from https://www.mitk.org/download/tutorial-data/Pic3D.nrrd .
\li lungs.vtk \n
-This file contains a surface and can be downloaded from http://mitk.org/download/tutorial-data/lungs.vtk .
+This file contains a surface and can be downloaded from https://www.mitk.org/download/tutorial-data/lungs.vtk .
\li \subpage Step00Page "Step 0: Getting started"
\li \subpage Step01Page "Step 1: Displaying an image"
\li \subpage Step02Page "Step 2: Load one or more data sets"
\li \subpage Step03Page "Step 3: Create 3D view"
\li \subpage Step04Page "Step 4: Use several views to explore data"
\li \subpage Step05Page "Step 5: Interactively add points"
\li \subpage Step06Page "Step 6: Use an interactive region-grower"
\li \subpage Step07Page "Step 7: Convert result of region growing into a surface"
\li \subpage Step08Page "Step 8: Use QmitkStdMultiWidget as widget"
\li \subpage Step09Page "Step 9: A plug-in"
\li \subpage Step10Page "Step 10: How to use Interactor and how to implement new ones"
More advanced How-Tos can be found at \ref FirstSteps .
Enjoy MITK!
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/BuildInstructions.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/BuildInstructions.dox
index 0c585c0c97..c7b64520ce 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/BuildInstructions.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/BuildInstructions.dox
@@ -1,216 +1,216 @@
/**
\page BuildInstructionsPage Build Instructions
\tableofcontents
\section BuildInstructions_Introduction Introduction
The CMake-based build system of MITK supports a "superbuild" process,
meaning that it will download, configure, and build all required third-party
libraries (except Qt) automatically. These instructions will show you how to use
the MITK superbuild.
\note This page explains explicitly how to build MITK itself. If you want to
create your own project based on MITK, the process described below is completely
automated. Please see \ref HowToNewProject.
For more advanced users, the last sections explains how to inject custom build
libraries into the superbuild process.
\section BuildInstructions_Prerequisites Prerequisites
You need:
- -# Git from http://git-scm.com (there are also numerous third-party graphical
+ -# Git (there are also numerous third-party graphical
clients available). We recommend using Git, but see below for a way how to
get the current source code without using it.
- -# CMake (version \minimumCMakeVersion or higher)
- -# Qt 5.12 if you plan to develop Qt-based
+ -# CMake (version \minimumCMakeVersion or higher)
+ -# Qt 5.12 if you plan to develop Qt-based
applications
-# If you are using macOS you need an XCode installation and the
Command Line Tools as it provides the neccessary compilers and SDKs
\section BuildInstructions_Qt A note about Qt
As we do not provide Qt in the MITK superbuild you need to install Qt manually.
-The Qt Company provides online installers
+The Qt Company provides online installers
for all supported platforms.
\section BuildInstructions_Get_Source Get a source tree
Since MITK is under active development we recommend to use Git to check out
the latest stable release from the homepage. If you decide to use the most
current nightly release, make sure to get a stable tree: Check the
-MITK dashboard
+MITK dashboard
before checking out. If the build tree is not clean, you can specify an
older revision for the checkout or get a stable tar ball from
-www.mitk.org.
+www.mitk.org.
To clone MITK's current Git repository do:
\code
git clone https://phabricator.mitk.org/source/mitk.git MITK
\endcode
\section BuildInstructions_Build_With_CMake Build MITK with CMake
Create a new directory for the superbuild binary tree, change to it and call CMake:
In the shell (assuming your current directory is the same as the one where you
issued the git clone command):
\code
mkdir MITK-superbuild
cd MITK-superbuild
ccmake ../MITK
\endcode
If you use Windows or prefer to use the CMake GUI, start the CMake GUI and enter the
location of the source tree and binary tree, choose a suitable generator
and configure the project.
CMake will present you a couple of options, these are the most important ones:
- CMAKE_PREFIX_PATH The path to your Qt installation, e.g., C:/Qt/5.12.6/msvc2017_64 or /home/user/Qt/5.12.6/gcc_64
- MITK_USE_ACVD Build MITK code which depends on ACVD (this
will download and build ACVD)
- MITK_USE_BLUEBERRY Build the BlueBerry application framework
- MITK_USE_Boost_LIBRARIES If you need binary Boost libraries,
specify them here.
- MITK_USE_OpenCV Build MITK code which depends on OpenCV (this
will download and build OpenCV 2.4)
- MITK_USE_Python3 Enables Python wrapping in MITK. This will also
configure ITK, VTK, and OpenCV (if enabled) to build Python wrappers.
- MITK_USE_Qt5 Build MITK code which depends on Qt 5
If you are satisfied with the configuration of your MITK superbuild, generate
the project files with CMake by pressing "Generate".
Linux and macOS users usually just enter "make" (optionally
supplying the number threads to be used for a parallel build):
\code
make -j6
\endcode
Windows users using Visual Studio can open the generated
MITK-superbuild.sln solution file in the MITK-superbuild
directory and start the build by building the BUILD_ALL project.
\section BuildInstructions_Customize Customize your MITK superbuild
The MITK superbuild configures MITK as well as all external libraries. The
build directories of these libraries, and of MITK itself are located inside
the MITK-superbuild directory. For example, the directory layout may
look like:
\code
MITK-superbuild
|- ep "external projects"
|-bin
|-lib
|-include
|-src
|- MITK-build
\endcode
To change the configuration of the MITK build itself, choose the MITK-build directory
as the binary directory in the CMake GUI (not the MITK-superbuild directory).
After generating the project files, build the MITK project by either issuing "make"
in the MITK-build directory (Linux, macOS), or by opening MITK-build/MITK.sln (Windows).
You may also change the configuration of any project configured via the
superbuild process. Make sure to also build the changed project and also the
projects which depend on it.
\section BuildInstructions_Running Running Applications
On Linux, just execute the application you want to run. MITK executables are
located in MITK-superbuild/MITK-build/bin
On Windows, the PATH environment variable must contain the directories
containing the third-party libraries. This is automatically done from Visual Studio.
For running the applications directly use the generated batch files in the
MITK-superbuild/MITK-build/bin.
\section BuildInstructions_Documentation Documentation
-If you have the Doxygen documentation tool
+If you have the Doxygen documentation tool
installed, you get a new project (Visual Studio) or "make" target named "doc".
You can build this to generate the HTML documentation of MITK in the
Documentation/Doxygen directory of your MITK-build binary tree or in the
MITK_DOXYGEN_OUTPUT_DIR CMake variable (if specified).
\section BuildInstructions_Extending Extend MITK on your own (using the application framework BlueBerry)
Please see \ref NewPluginPage
\section BuildInstructions_As_Toolkit Use MITK in your own project (as a toolkit)
To use MITK in your external project, add the CMake command
find_package(MITK REQUIRED) to your CMakeLists.txt and make use of
the CMake macros mitk_create_module() and
mitk_create_executable() provided by MITK.
Here is a very basic example CMakeLists.txt including MITK as a project:
\code
cmake_minimum_required(VERSION 3.10 FATAL_ERROR)
project(MyProject)
find_package(MITK 2018.04.02 REQUIRED)
add_executable(MyApp main.cpp)
target_link_libraries(MyApp MitkCore)
\endcode
with the main.ccp being
\code
#include
#include
int main()
{
MITK_INFO << "Hello world!";
return 0;
}
\endcode
\section BuildInstructions_Advanced_Customization Superbuild customization
You can inject pre-build third-party libraries into the MITK superbuild by
setting certain CMake variables before the first configure step. MITK will
then use these third-party libraries instead of downloading and building them
by itself. Note that you must take care of configuring those libraries with all options
MITK requires.
The variables listed below are provided for injecting third-party libraries.
Their occurrence in the CMake GUI or in ccmake may depend on specific
MITK_USE_* options set to ON. You may also use the variable names below without
the EXTERNAL_ prefix, for example when providing their values on a
command line call to CMake.
- EXTERNAL_BOOST_ROOT Set this variable to your custom Boost
installation
- EXTERNAL_CTK_DIR Set this variable to your CTK binary tree
(the directory containing the CTKConfig.cmake file)
- EXTERNAL_CableSwig_DIR Set this variable to your CableSwig
binary tree for Python wrapping (the directory containing the
CableSwigConfig.cmake file)
- EXTERNAL_DCMTK_DIR Set this variable to your DCMTK binary
tree (the directory containing the DCMTKConfig.cmake file)
- EXTERNAL_GDCM_DIR Set this variable to your GDCM binary
tree (the directory containing the GDCMConfig.cmake file)
- EXTERNAL_ITK_DIR Set this variable to your ITK binary tree
(the directory containing the ITKConfig.cmake file)
- EXTERNAL_OpenCV_DIR Set this variable to your OpenCV binary
tree (the directory containing the OpenCVConfig.cmake file)
- EXTERNAL_VTK_DIR Set this variable to your VTK binary tree
(the directory containing the VTKConfig.cmake file)
To set CMake options before the first configure step is invoked, supply them
on the command line, i.e.
\code
ccmake -DITK_DIR:PATH=/opt/ITK-release ../MITK
\endcode
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox
index cd5bd5e6f0..ca78ac4728 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox
@@ -1,255 +1,254 @@
/**
\page HowToNewProject Creating a new MITK project
\tableofcontents
This page is intended to give a comprehensive guide to setting up your own MITK based
project. It will use the application framework provided by MITK and is probably the
preferred way for most users.
The first part of this document is a tutorial aimed at newcomers to MITK and possibly
%CMake and tries to give as much help as possible on setting up your own project. If
you are looking for more technical information about customizing MITK, the structure
of the superbuild or packaging you might want to read the
\ref HowToNewProjectAdvancedInformation.
If you have set up your MITK project already and want to start developing you could
take a look at \ref TutorialPage.
\section HowToNewProjectGettingStarted Getting Started
To bootstrap your project MITK offers two convenient options:
Use the MITK Plugin Generator, a command line tool used to generate a customized
- MITK project and/or MITK plug-ins (available for download
- here).
+ MITK project and/or MITK plug-ins.
Both options will provide you with a project which contains a "superbuild" mechanism
to automatically download, configure, and build MITK as a dependency of your own project.
The MITK Plugin Generator generates code using the supplied command line arguments,
whereas the MITK project template needs immediate modifications to customize it to
your naming schemes. However, the project template will potentially contain more
code demonstrating features of MITK.
\note Using the MITK Plugin Generator is recommended for beginners.
\section HowToNewProjectPrerequisites Prerequisites
What ever option you choose, a MITK-based project needs essentially the same
prerequisites as MITK itself. Please see \ref BuildInstructions_Prerequisites for
details.
\note If you use one of the two options above you will \b not \b need to build MITK
yourself. This will be done automatically.
\section HowToNewProjectCreatingSourceDir Preparing your source directory
In order to start developing with MITK, you first have to set up the source directory
for your project.
\subsection HowToNewProjectSourceUsingGenerator Using the MITK Plugin Generator
The usage of the Plugin Generator for creating a new project is described in
\ref NewPluginWithProject, please have a look there.
\subsection HowToNewProjectSourceUsingTemplate Using the MITK Project Template
Download the project as a tarball or zipball and extract it to your desired source
directory.
\note This is a template. You must modify it such that it fits the needs of
your particular project. Especially you should do a global search and replace for
the string "awesome" to rename the template application and plug-in. You may want
to rename some files too.
\section HowToNewProjectGeneratingCMake Generating your binary with CMake
After you have set up your source directory you can proceed to generate your binary
directory using %CMake. Depending on your operating system and preferences you might
want to use "cmake-gui" or "ccmake" (shell). This document assumes you are using
cmake-gui.
Start "cmake-gui" and enter your source (e.g. "D:\AwesomeProject") and binary
directory (e.g. "D:\AwesomeProject-superbuild").
Upon first pressing "Configure" you will be prompted to select your generator.
This determines what project files will be generated by %CMake. Set this to the
development tool you are intending to use (e.g. "Visual Studio 2010 64Bit" or
"linux makefiles".
Press "Configure" until no new variables appear and then "Generate". Now all
project files have been generated into your binary directory.
Double-check that the right Qt version is used.
Now you are ready to compile your code. Depending on your choice of tool this will
be done differently, we cover two possibilities here.
\subsection HowToNewProjectCompilingLinuxMakefiles Compiling using linux makefiles
In the shell, switch to your binary directory.
type "make" and hit enter
\subsection HowToNewProjectCompilingVisualStudio Compiling using visual studio
We assume your application is called "AwesomeApp" and your project "AwesomeProject"
and your binary directory is "D:\AwesomeProject-superbuild\". Replace names and
paths accordingly.
Close %CMake and open "D:\AwesomeProject-superbuild\AwesomeProject-superbuild.sln".
Your Visual Studio should appear and by pressing F7 you start the compilation.
This will clone the MITK source code, build it, and then start building your own
project.
After the superbuild compilation has finished, close the superbuild solution file and start
the build solution file "D:\AwesomeProject-superbuild\AwesomeProject-build\AwesomeProject.sln"
Set the "AwesomeApp" project as start-up project (right click > "Set as StartUp
Project") and press "F5" to start your MITK AwesomeApp.
\note Just opening AwesomeProject.sln from your explorer by double-cliking won`t
allow you to start or debug your application because the required environment
variables would be missing. Use the supplied batch files or set your PATH variable
accordingly.
\section HowToNewProjectAddingMITKFunctionality I want to use some MITK plugin but
it is not available
Due to the sheer number of MITK plugins not every plugin is activated by default.
To activate a specific plugin (again replace paths as needed):
Start "cmake-gui" and set the binary directory to
"D:\AwesomeProject-superbuild\MITK-superbuild\MITK-build\", the source will
adjust automatically and you will see new settings appear.
Navigate to the plugin you want to use (e.g. "MITK_BUILD_org.mitk.gui.qt.segmentation")
and tick the checkbox behind it
Press "Configure" until no new variables appear and then "Generate".
Build MITK using your development tool (as in
\ref HowToNewProjectCompilingLinuxMakefiles or \ref HowToNewProjectCompilingVisualStudio
only in the "D:\AwesomeProject-superbuild\MITK-superbuild\MITK-build\" directory )
Start "cmake-gui" and set the binary directory to
"D:\AwesomeProject-superbuild\AwesomeProject-build\", the source will adjust
automatically and you will see new settings appear.
Press "Configure" until no new variables appear and then "Generate".
Build your project
Start your application
\note If you want to use an application provided by MITK (e.g. MITK Workbench) you
have to tick the appropriate checkbox as well (in this case MITK_BUILD_APP_Workbench)
and build MITK. Do note, that this application will be located in the bin directory
of the "D:\AwesomeProject-superbuild\MITK-superbuild\MITK-build\" folder.
\section HowToNewProjectAdvancedInformation Information for advanced users
\subsection HowToNewProjectCustomizingMITK Customizing MITK
The %CMake scripts from the Plugin Generator of the project template provide some
handy options which allow you to customize the MITK build used in your project.
You can either inject an already build MITK to be used by your project or configure
some MITK options directly in your project's superbuild configuration if MITK is
going to be build inside your project.
\subsubsection HowToNewProjectCustomizingMITKInjectMITK Inject a MITK build
By setting the \b EXTERNAL_MITK_DIR \b variable in your project's superbuild
%CMake configuration to a MITK build directory (containing the MITKConfig.cmake)
you can skip the MITK build process.
If MITK is the only external project in your project, you might want to disable
the superbuild of your project completely (set _USE_SUPERBUILD
to OFF or edit your CMakeLists.txt file to set it to OFF by default) and set
the \b MITK_DIR \b %CMake variable to your MITK build directory.
\subsubsection HowToNewProjectCustomizingMITKConfigure Configure the MITK superbuild
If MITK is being build inside your project's superbuild process, you can enable
the use of certain third-party libraries inside of MITK. The following variables
control the MITK configuration:
\b MITK_USE_BLUEBERRY Enable the use of the BlueBerry application framework
\b MITK_USE_CTK Download, compile, and use CTK in MITK
\b MITK_USE_DCMTK Download, compile, and use DCMTK in MITK
\b MITK_USE_OpenCV Download, compile, and use OpenCV in MITK
\b MITK_USE_Python3 Download and compile 1CableSwig and enable Python
wrapping in ITK, VTK, OpenCV, and MITK
\b MITK_USE_Qt5 Use the Qt 5 framework in MITK
You can also inject already build third-party libraries from inside your project's
superbuild in the MITK superbuild by using any of the following %CMake variables:
\b MITK_CTK_DIR Reuse a CTK build directory in MITK.
\b MITK_CableSwig_DIR Reuse a 1CableSwig build directory in MITK.
\b MITK_DCMTK_DIR Reuse a DCMKT build directory in MITK.
\b MITK_GDCM_DIR Reuse a GDCM build directory in MITK.
\b MITK_ITK_DIR Reuse a ITK build directory in MITK.
\b MITK_OpenCV_DIR Reuse a OpenCV build directory in MITK.
\b MITK_VTK_DIR Reuse a VTK build directory in MITK.
If the corresponding \b MITK_USE_ \b option is set to on, the MITK
superbuild will use the provided build directory instead of building the
project itself.
You can also control the source code location for MITK in your project's
superbuild configuration by using the following %CMake variables:
\b MITK_SOURCE_DIR The path to the MITK source directory. If the value
for this variable is non-empty, the variables below are ignored.
\b MITK_GIT_REPOSITORY The Git repository containing the MITK source code.
\b MITK_GIT_TAG The hash id, tag or branch name used for a checkout
from MITK_GIT_REPOSITORY.
\subsubsection HowToNewProjectProjectStructure Project Structure
If you are using the superbuild feature of the generated project (the default),
you might want to familiarise yourself with the layout of your build tree.
The top-level build directory which you specified in %CMake when configuring
your project will contain all the required dependencies.
Suppose we call our project MyProject and the build directory is
"C:\MyProject-superbuild". Then the layout looks something like this:
MyProjectLayout.png The top-level directory contains the source code and the
build directories from the dependencies of your project. In the current case,
the only dependency of MyProject is MITK, which in turn has downloaded and built
its own dependencies (CTK, DCMTK, ITK, etc.). The "real" build tree for your
project is located in MyProject-superbuild/MyProject-build, so point the
%CMake-GUI to this build directory if you want to change the set of enabled
plug-ins for example.
Further, you should open the MyProject.sln solution file (for Visual Studio)
or execute "make" in the MyProject-superbuild/MyProject-build/ directory.
Only for the very first time or if you want to update and newly build the
project's dependencies should you use the project files in the
MyProject-superbuild directory directly.
The same applies for the MyProject-superbuild/MITK-superbuild directory. This
directory contains the MITK superbuild, nested inside your project's superbuild.
If you want to change %CMake options for MITK, use the
MyProject-superbuild/MITK-superbuild/MITK-build build directory.
\imageMacro{HowToNewProject-MyProjectLayout.png,"Layout of MyProject",4.02}
\subsubsection HowToNewProjectPackaging Packaging
The project template and the generated projects by the Plugin Generator come
with full packaging support. You can create deployable packages of your project
for all supported operating systems my building the PACKAGE target. On Linux,
this will create a tarball, on MacOS a .dmg file, and on Windows a zipball and
an NSIS installer (if NSIS is installed and found).
You can read more about deployment \ref DeploymentPage "here".
*/
diff --git a/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/ThirdPartyLibs.dox b/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/ThirdPartyLibs.dox
index 315fe01900..de49eef830 100644
--- a/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/ThirdPartyLibs.dox
+++ b/Documentation/Doxygen/3-DeveloperManual/Starting/SettingUpMITK/ThirdPartyLibs.dox
@@ -1,111 +1,107 @@
/**
\page thirdpartylibs Third-party libraries
The following third-party libraries can be used with MITK by default and can, in part, be automatically downloaded during superbuild.
\par ACVD
-http://www.creatis.insa-lyon.fr/site/en/acvd
+https://www.creatis.insa-lyon.fr/site7/en/acvd
\par ANN
-http://www.cs.umd.edu/~mount/ANN/
+https://www.cs.umd.edu/~mount/ANN/
\par Boost
-http://www.boost.org/
+https://www.boost.org/
\par C++ REST SDK
https://github.com/Microsoft/cpprestsdk/
\par CppUnit
-http://sourceforge.net/projects/cppunit/
+https://sourceforge.net/projects/cppunit/
\par CTK
-http://www.commontk.org/
+https://commontk.org/
\par DCMTK
-http://dicom.offis.de/dcmtk.php.en
+https://dicom.offis.de/dcmtk
\par Eigen
http://eigen.tuxfamily.org/index.php?title=Main_Page
\par GDCM
-http://gdcm.sourceforge.net/
+https://gdcm.sourceforge.net/
\par HDF5
https://support.hdfgroup.org/HDF5/
\par ITK
-http://www.itk.org/
+https://itk.org/
\par MatchPoint
-https://www.dkfz.de/en/sidt/projects/matchpoint/info.html
-
-\par NumPy
-
-http://www.numpy.org/
+https://www.dkfz.de/en/sidt/projects/MatchPoint/info.html
\par OpenCL
https://www.khronos.org/opencl/
\par OpenCV
-http://opencv.willowgarage.com/wiki/Welcome
+https://opencv.org/
\par OpenIGTLink
http://openigtlink.org/
\par PCRE
-http://www.pcre.org/
+https://www.pcre.org/
\par POCO
-http://pocoproject.org
+https://pocoproject.org/
\par Python
https://www.python.org/
\par Qt
-http://www.qt.io/
+https://www.qt.io/
\par Qwt
http://qwt.sourceforge.net/
\par SWIG
-http://swig.org/
+http://www.swig.org/
\par tinyxml
-http://sourceforge.net/projects/tinyxml/
+http://www.grinninglizard.com/tinyxml/
\par VIGRA
-http://ukoethe.github.io/vigra/
+https://ukoethe.github.io/vigra/
\par VTK
-http://www.vtk.org/
+https://vtk.org/
\par zlib
-https://github.com/madler/zlib/
+https://zlib.net/
For copyright information on any of the above toolkits see the corresponding home page or the corresponding source folder.
*/
diff --git a/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkRegionGrowingUserManual.dox b/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkRegionGrowingUserManual.dox
index ca5f150f72..6facf2b2f3 100644
--- a/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkRegionGrowingUserManual.dox
+++ b/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkRegionGrowingUserManual.dox
@@ -1,29 +1,29 @@
/**
\page org_mitk_views_regiongrowing The Region Growing View
\imageMacro{regiongrowing.png,"Icon of the Region Growing View",2.00}
Available documentation sections:
- \ref QmitkRegionGrowingUserManualOverview
- \ref QmitkRegionGrowingUserManualUsage
\section QmitkRegionGrowingUserManualOverview Overview
-The Region growing view provides a programming example, showing developers how to create new views for MITK with a graphical user interface (GUI) that also uses some ITK image filters.
+The Region growing view provides a programming example, showing developers how to create new views for MITK with a graphical user interface (GUI) that also uses some ITK image filters.
-For the programmers: this functionality is the result of tutorial step 9
+For the programmers: this functionality is the result of tutorial step 9
\section QmitkRegionGrowingUserManualUsage Usage
you can set a number of seed points by clicking into the render windows while holding down the shift key.
when clicking "Start region growing", a region growing algorithm starts. This algorithm is gray values based. The gray values are determined from the gray values at all point positions plus/minus a safety margin of 30 (Hounsfield units).
*/
diff --git a/Examples/Plugins/org.mitk.example.gui.selectionserviceqt/documentation/doxygen/SelectionServiceQt.dox b/Examples/Plugins/org.mitk.example.gui.selectionserviceqt/documentation/doxygen/SelectionServiceQt.dox
index b917f2ccbe..01c0933553 100644
--- a/Examples/Plugins/org.mitk.example.gui.selectionserviceqt/documentation/doxygen/SelectionServiceQt.dox
+++ b/Examples/Plugins/org.mitk.example.gui.selectionserviceqt/documentation/doxygen/SelectionServiceQt.dox
@@ -1,47 +1,47 @@
/**
\page BlueBerryExampleSelectionServiceQt Qt Model/View selections
\brief An example application plug-in with a minimal selection service based on Qt selection models.
\image html SelectionServiceQT.png
In this example the selection service is used to connect the selection of the radio buttons from one
view with the selection of the list of the other view. The SelectionView holds a QListWidget that provides
the user selection (qt selection provider) for the selection listener (ListenerView). The radio buttons of
the listener view are changed according to the selection in the QListWidget. Vice versa the radio buttons
(the selection listener) does not provide any selection events. If the user changes the radio button state
the QListWidget is not altered.
- For additional informations on the selection service concept see http://www.mitk.org/wiki/Article_Using_the_Selection_Service
+ For additional informations on the selection service concept see https://www.mitk.org/wiki/Article_Using_the_Selection_Service
The berry::QtSelectionProvider class implements the interface berry::ISelectionProvider. Due to the model/view concept in Qt, the workbench
provides the berry::QtSelectionProvider class for Qt viewers which must be provided with a QItemSelectionModel.
In the SelectionView.h we declare a pointer that holds the selection provider...
\snippet SelectionView.h Qt Selection Provider
...and in the SelectionView.cpp we set the selection model to the model of the QListWidget (m_SelectionList)
\snippet SelectionView.cpp Qt Selection Provider registration
Now that the QListWidget of the SelectionView sends out selection events we need a listener implementation. In the ListenerView.h
we need to include the ISelectionListener which is a simple class with just one method.
The method that implements the selection listener functionality of ISelectionListener and the pointer that holds the selection listener is declared...
\snippet ListenerView.h Qt Selection Listener method and pointer
...and implemented in the cpp-file:
\snippet ListenerView.cpp Qt Selection Listener method implementation
Now the name of the selected list element is passed to a method that toggles the radio buttons of the ListenerView accordingly.
View complete source files:
\li \github{Examples/Plugins/org.mitk.example.gui.selectionserviceqt/src/internal/SelectionView.cpp,SelectionView.cpp}
\li \github{Examples/Plugins/org.mitk.example.gui.selectionserviceqt/src/internal/SelectionView.h,SelectionView.h}
\li \github{Examples/Plugins/org.mitk.example.gui.selectionserviceqt/src/internal/ListenerView.cpp,ListenerView.cpp}
\li \github{Examples/Plugins/org.mitk.example.gui.selectionserviceqt/src/internal/ListenerView.h,ListenerView.h}
[\ref BlueBerrySelectionServiceIntro] [Next: \ref BlueBerryExampleSelectionServiceMitk] [\ref BlueBerryExamples]
*/
diff --git a/Modules/BasicImageProcessing/documentation/UserManual/mitkBasicImageProcessingMiniAppsPortalPage.dox b/Modules/BasicImageProcessing/documentation/UserManual/mitkBasicImageProcessingMiniAppsPortalPage.dox
index 822131b53a..c78a2e14d3 100644
--- a/Modules/BasicImageProcessing/documentation/UserManual/mitkBasicImageProcessingMiniAppsPortalPage.dox
+++ b/Modules/BasicImageProcessing/documentation/UserManual/mitkBasicImageProcessingMiniAppsPortalPage.dox
@@ -1,45 +1,45 @@
/**
\page mitkBasicImageProcessingMiniAppsPortalPage MITK Basic Image Processing Mini Apps
\tableofcontents
-The Basic Image Processing Mini Apps bundle the functionality that is commonly neeeded for the processing of medical images. As all other MiniApps, they follow the Slicer Execution Model in describing themselves via xml. You can simply obtain a description by calling the MiniApp without any parameter. If the MiniApp is calles with the option "--xml" a XML description of all possible parameter is added.
+The Basic Image Processing Mini Apps bundle the functionality that is commonly neeeded for the processing of medical images. As all other MiniApps, they follow the Slicer Execution Model in describing themselves via xml. You can simply obtain a description by calling the MiniApp without any parameter. If the MiniApp is calles with the option "--xml" a XML description of all possible parameter is added.
\section bipmasec1 Description of Mini Apps
\subsection bipmasub1 mitkFileConverter
-Allows to convert a file from one type to another file type, for example to convert an image, saved in the nifti format to an image saved in the .nrrd format.
+Allows to convert a file from one type to another file type, for example to convert an image, saved in the nifti format to an image saved in the .nrrd format.
\subsection bipmasub2 mitkForwardWavelet
Calculates the forward wavelet transformation of an image. The output will consist of multiple images, which will be saved in the format \%id%\, where \ and \ are specified by the user and %id% is a consecutive number.
\subsection bipmasub3 mitkImageAndValueArithmetic
Mathematical operations with two operants, the individual voxels of the image and a specified floating point value. By default, the floating point value is the right operand.
\subsection bipmasub4 mitkImageTypeCovnerter
-Convert the data fromat that is used to save a voxel of an image.
+Convert the data fromat that is used to save a voxel of an image.
\subsection bipmasub5 mitkLaplacianOfGaussian
Calculate the Laplacian of Gaussian of an image with the specified sigma value.
\subsection bipmasub6 mitkMaskOutlierFiltering
-Can be used to clean an segmentation. The mean and standard deviation of the intensities which are masked is calculated and then all mask voxels are removed that cover image voxels which are not within a 3 sigma range.
+Can be used to clean an segmentation. The mean and standard deviation of the intensities which are masked is calculated and then all mask voxels are removed that cover image voxels which are not within a 3 sigma range.
\subsection bipmasub7 mitkMaskRangeBasedFiltering
-Removing all voxels from a mask that cover image voxels which are outside of a given range. The range can be either specified by a lower limit, a upper limit, or both at the same time.
+Removing all voxels from a mask that cover image voxels which are outside of a given range. The range can be either specified by a lower limit, a upper limit, or both at the same time.
\subsection bipmasub8 mitkMultiResolutionPyramid
-Calculate a Multi-Resolution Pyramid of the given image. The resolution is reduced by factor 2 for each step.
+Calculate a Multi-Resolution Pyramid of the given image. The resolution is reduced by factor 2 for each step.
\subsection bipmasub9 mitkResampleImage
Resample a mask to a new spacing
\subsection bipmasub10 mitkResampleMask
-Similar to mitkResampleImage, but specificly tailored to resampling a mask.
+Similar to mitkResampleImage, but specificly tailored to resampling a mask.
-\subsection bipmasub11 mitkSingleImageArithmetic
+\subsection bipmasub11 mitkSingleImageArithmetic
Applies single operand mathematical operations to each voxel of an image
-\subsection bipmasub12 mitkTwoImageArithmetic
+\subsection bipmasub12 mitkTwoImageArithmetic
Applied two operand mathematical operations to each voxels of two images.
*/
diff --git a/Modules/Chart/documentation/mitkChart.dox b/Modules/Chart/documentation/mitkChart.dox
index a1a7e98a13..affdaa3755 100644
--- a/Modules/Chart/documentation/mitkChart.dox
+++ b/Modules/Chart/documentation/mitkChart.dox
@@ -1,256 +1,256 @@
/**
\page ChartModule Chart Module
\tableofcontents
\section ChartModule_brief Description
The MITK chart module is able to show different types of charts in a widget with customizable labels.
\imageMacro{complexExample.png,"Example chart",10}
-\subsection Chart_Technical Technical background
+\subsection Chart_Technical Technical background
-The module uses the java script library plotly to display the chart in a QWebEngineView (that renders html/js content).
+The module uses the java script library plotly to display the chart in a QWebEngineView (that renders html/js content).
For examples, please visit https://plot.ly/javascript/.
\subsection Chart_GUI GUI
\note Be sure that the dependency to the Chart Module is resolved in the CMakeLists.txt of the plugin: MODULE_DEPENDS MitkChart.
-Open the ui file of the plugin. Then add a widget (we always use the name chartWidget in the following) at the desired position. Change the class of the widget to a user-defined widget (right click → user defined classes, see http://doc.qt.io/qt-5/designer-using-custom-widgets.html). Set "QWidget" as base class. Set "QmitkChartWidget" as class name and "QmitkChartWidget.h" as include file.
+Open the ui file of the plugin. Then add a widget (we always use the name chartWidget in the following) at the desired position. Change the class of the widget to a user-defined widget (right click → user defined classes, see https://doc.qt.io/qt-5/designer-using-custom-widgets.html). Set "QWidget" as base class. Set "QmitkChartWidget" as class name and "QmitkChartWidget.h" as include file.
\imageMacro{userDefinedWidget.png,"User defined widget",10}
\subsection Chart_data Data
-The most important functionality is to add data to the chartWidget. Either one dimensional or two dimensional data can be used. One-dimensional data has the same interval between values on the x-axis (and no x-axis values) while the two-dimensional data has arbitrary x-axis difference values (and given x-axis values).
+The most important functionality is to add data to the chartWidget. Either one dimensional or two dimensional data can be used. One-dimensional data has the same interval between values on the x-axis (and no x-axis values) while the two-dimensional data has arbitrary x-axis difference values (and given x-axis values).
An example for one-dimensional data is the temperature for each month of a year: std::vector temperatureHD = {1.8, 3.1, 6.3, 10.2, 14.5, 17.4, 19.4, 18.9, 15.5, 11.2, 5.8, 2.6}. The first entry corresponds (implicitly) to the temperature in january, two second to the temperature in february the last entry to the temperature in december. Thus, the x values have same intervals. The given temperature values are defined as y-axis values.
An example for two-dimensional data is the people living in a city in different years: std::map peopleHeidelberg={{1975, 129368 }, { 1985, 134724 },{ 1990, 136796 },{ 2010, 147312 }}.
Thus, the x-values are given as their intervals are different (10 years, 5 years, 10 years). Each x value is connected to an y-value that represents the amount of people (1975 → 129368, 1985 → 134724, ...).
Data is added by calling chartWidget->AddData1D(temperatureHD, "Heidelberg") or chartWidget->AddData2D(peopleHeidelberg, "Heidelberg"), where the second argument is a label for the data entry.
\imageMacro{2DDataExample.png,"2D data example: Heidelberg has fewer entries and their x-range (years) is smaller than Freiburg",8}
-As the data labels are used as identifier, they have to be unique. This is checked. If non-unique entries are entered, they are made unique by adding numbers. Example:
+As the data labels are used as identifier, they have to be unique. This is checked. If non-unique entries are entered, they are made unique by adding numbers. Example:
\code{.cpp}
chartWidget->AddData1D(temperatureHD, "Heidelberg")
chartWidget->AddData1D(temperatureOslo, "Heidelberg")
\endcode
will result in the labels "Heidelberg" and "Heidelberg0", whereas "Heidelberg0" refers to temperatureOslo.
If you want to add more data, just call chartWidget->AddData1D(data, label, chartType) or chartWidget->AddData2D(data, label, chartType) as often as desired. Then, call chartWidget->Show(). The ranges of x- and y-axis are adjusted automatically.
To delete single data entries, call chartWidget->RemoveData(label) and update the chart area with chartWidget->Show(). All data can be cleared by calling chartWidget->Clear().
\subsection Chart_type Chart type
The default chart type is bar. To use a different type, you have to change it.
Seven chart types are available:
bar
line
spline
pie
are
area_spline
scatter
See below examples of all types:
\imageMacro{barChartTemperature.png,"Example bar chart",4}
\imageMacro{lineChartTemperature.png,"Example line chart",4}
\imageMacro{splineChartTemperature.png,"Example spline chart",4}
\imageMacro{pieChartExample.png,"Example pie chart",4}
\imageMacro{areaChartTemperature.png,"Example area chart",4}
\imageMacro{areaSplineChartTemperature.png,"Example spline area chart",4}
\imageMacro{scatterChartTemperature.png,"Example scatter chart",4}
Call e.g. chartWidget->SetChartType(label, QmitkChartWidget::ChartType::line) for changing the chart type. Note that it is not directly displayed. To change the chart type for all data entries and display the result, call chartWidget->SetChartTypeForAllDataAndReload(QmitkChartWidget::ChartType::line).
All chart types except pie chart can be also used mixed (different chart types in the same chart). Pie charts are handled differently. The input data sum is regarded as 100%. The values of all data entries are summed. Example:
\code{.cpp}
chartWidget->AddData1D({5}, "entry1", QmitkChartWidget::ChartType::pie);
chartWidget->AddData1D({2}, "entry2", QmitkChartWidget::ChartType::pie);
chartWidget->AddData1D({3}, "entry3", QmitkChartWidget::ChartType::pie);
\endcode
The pie chart has then entries of 50%, 20% and 30%. Calling chartWidget->AddData1D({5,2,3}, "entry", QmitkChartWidget::ChartType::pie) leads to a pie chart with one class having 100%. Calling
\code{.cpp}
chartWidget->AddData1D({2,2,1}, "entry1", QmitkChartWidget::ChartType::pie);
chartWidget->AddData1D({1,1}, "entry2", QmitkChartWidget::ChartType::pie);
chartWidget->AddData1D({3}, "entry3", QmitkChartWidget::ChartType::pie);
\endcode
leads to the first result again (50%, 20% and 30%) as entries are summed.
\warning pie charts differ significantly from the other chart types. Be aware of the differences.
\subsection Chart_labels Labels
Four labels can be set to custom strings. These are
the data labels,
the x-axis label,
the y-axis label and
the title of the chart
Data labels provide the name for data legend entries ("Heidelberg" for our 1D data \ref{Chart_data} as it is the average temperature in Heidelberg) and are given by the second argument of AddData1D and AddData2D. They are also displayed in the legend. An example x-Axis and y-axis label would be month and temperature, respectively.
The data label argument is mandatory. All other labels are optional and empty strings by default.
chartWidget->SetXAxisLabel("month") and chartWidget->SetYAxisLabel("temperature") ensures the labeling of x- and y-Axis in the chart. No labels are defined as default.
chartWidget->SetTitle("temperature chart") adds a title to the chart.
\note The legend position (of data labels) can be set by chartWidget->SetLegendPosition(QmitkChartWidget::LegendPosition::bottom).
\note To hide the legend, call chartWidget->SetShowLegend(false).
\subsection Chart_show Displaying the chart
Finally, the chart is displayed by calling chartWidget->Show(bool). If the optional parameter is set to true, a subchart is shown additionally. That's useful for ensuring the overview if the user wants to zoom in.
\subsection Chart_dataAttributes Changing visualization attributes of data
Besides the chart type, the following attributes of a data entry can be changed:
color,
linesyle and
data points shown
this is done by referencing the data entry by its label (e.g. "Heidelberg" above): chartWidget->SetColor("Heidelberg", "green"), chartWidget->SetColor("Heidelberg", "#FF4500"), chartWidget->SetLineStyle("Heidelberg", LineStyle::dashed) and chartWidget->SetShowDataPoints(false).
\note SetShowDataPoints is a global attribute and valid for all data entries due to technical reasons.
Colors are chosen automatically by plotly if not given. However, if some data entries have given colors and some have not, same colors may appear for different data entries. Color can be given as strings (natural names like red or hexadecimal numbers like \c \#FF0000 . For color selection, the following reference is helpful: https://www.w3schools.com/cssref/css_colors.asp)
Line style only can be set if ChartType is QmitkChartWidget::ChartType::line. It is ignored otherwise. Also, if a non-existing label is given, the command is ignored. The default linestyle is LineStyle::solid.
\section Chart_example Example
\subsection Chart_exampleBarChart Bar chart
To create and visualize a bar chart with two data sets, x/y-axis labels and data labels, the following code is used:
\code{.cpp}
std::vector temperatureHD = {1.8, 3.1, 6.3, 10.2, 14.5, 17.4, 19.4, 18.9, 15.5, 11.2, 5.8, 2.6};
std::vector temperatureOslo = {-4.3, -4, -0.2, 4.6, 10.8, 15.2, 16.4, 15.2, 10.8, 6.4, 0.7, -2.8};
chartWidget->AddData1D(temperatureHD, "Heidelberg", QmitkChartWidget::ChartType::bar);
chartWidget->AddData1D(temperatureOslo, "Oslo", QmitkChartWidget::ChartType::bar);
chartWidget->SetXAxisLabel("month");
chartWidget->SetYAxisLabel("temperature");
chartWidget->Show();
\endcode
The order when AddData1D() is called influences the colors of the bars and the order of the shown data. The third argument of chartWidget->AddData1D() is superfluous and only for completeness as QmitkChartWidget::ChartType::bar is the default chart type. After Show() is called, the chart is visualized.
The chart type for all data entries can be changed to spline and directly showed:
\code{.cpp}
chartWidget->SetChartTypeForAllDataAndReload(QmitkChartWidget::ChartType::spline);
\endcode
the equivalent code is:
\code{.cpp}
chartWidget->SetChartType("Heidelberg", QmitkChartWidget::ChartType::spline);
chartWidget->SetChartType("Oslo", QmitkChartWidget::ChartType::spline);
chartWidget->Show();
\endcode
The temperature of another city can be added:
\code{.cpp}
std::vector temperatureRome = {8.1, 8.7, 8.7, 11.6, 18.8, 22.8, 25.4, 25.7, 21.4, 17.6, 12.6, 8.9};
chartWidget->AddData1D(temperatureRome, "Rome");
chartWidget->Show(true);
\endcode
As Show(true) is used, a subchart is shown.
\subsection Chart_examplePieChart Pie chart
A pie chart (the same as in \ref Chart_type ) can be generated with the following code:
\code{.cpp}
chartWidget->AddData1D({5}, "Heidelberg", QmitkChartWidget::ChartType::pie);
chartWidget->AddData1D({3}, "Oslo", QmitkChartWidget::ChartType::pie);
chartWidget->AddData1D({2}, "New York", QmitkChartWidget::ChartType::pie);
chartWidget->Show();
\endcode
\note Only one pie chart at a time can be displayed.
\subsection Chart_exampleMixedChart Mixed chart
Chart types and attributes like colors and line styles can be mixed as seen in the code example below (example result is the chart in \ref ChartModule_brief ):
\code{.cpp}
std::vector temperatureHD = {1.8, 3.1, 6.3, 10.2, 14.5, 17.4, 19.4, 18.9, 15.5, 11.2, 5.8, 2.6};
std::vector temperatureOslo = {-4.3, -4, -0.2, 4.6, 10.8, 15.2, 16.4, 15.2, 10.8, 6.4, 0.7, -2.8};
chartWidget->AddData1D(temperatureHD, "Heidelberg", QmitkChartWidget::ChartType::line);
chartWidget->AddData1D(temperatureOslo, "Oslo", QmitkChartWidget::ChartType::area);
chartWidget->SetColor("Heidelberg", "green");
chartWidget->SetColor("Oslo", "blue");
chartWidget->SetLineStyle("Heidelberg", QmitkChartWidget::LineStyle::dashed);
chartWidget->SetXAxisLabel("month");
chartWidget->SetYAxisLabel("temperature");
chartWidget->Show();
\endcode
\note Pie chart as chart type is an exception. Pie charts can't be displayed with other data entries having other chart types.
\subsection Chart_exampleRemoveData Removing data
Data also can be removed again (using the previous example \ref Chart_exampleMixedChart as base):
\code{.cpp}
chartWidget->RemoveData("Heidelberg");
chartWidget->Show();
\endcode
Only the date entries labeled "Oslo" remain.
Also all data can be removed:
\code{.cpp}
chartWidget->Clear();
chartWidget->Show();
\endcode
The chart is empty now.
\subsection Chart_example2DData Chart with 2D data
A line chart with two-dimensional data is the following example (the same as in \ref Chart_data ):
\code{.cpp}
std::map peopleHD = { {1975, 129368 }, { 1985, 134724 },{ 1990, 136796 },{ 2010, 147312 } };
std::map peopleFreiburg = { { 1969, 165960 },{ 1973, 174997 },{ 1982, 178545 },{ 2001, 208294 },{ 2015, 222203 } };
chartWidget->AddData2D(peopleHD, "Heidelberg", QmitkChartWidget::ChartType::line);
chartWidget->AddData2D(peopleFreiburg, "Freiburg", QmitkChartWidget::ChartType::line);
chartWidget->SetXAxisLabel("year");
chartWidget->SetYAxisLabel("people");
chartWidget->Show();
\endcode
Hence, 2D data is having the following assignment: year → people. In the vector peopleHD, four values are defined, in the vector peopleFreiburg, five values are defined. The defined years are different for Heidelberg (1975-2010) than for Freiburg (1969-2015).
\warning mixing AddData2D and AddData1D in a chart is strongly discouraged. It will work, however the visualization may be odd due to implicit and explicit given x values.
\subsection Chart_imageStatistics image statistics plugin
An example of the use of QmitkChartWidget in MITK can be found in the image statistics plugin. The \c chartWidget is named \c m_Controls->m_JSHistogram there.
*/
diff --git a/Modules/Classification/documentation/UserManual/mitkClassificationMiniAppsPortalPage.dox b/Modules/Classification/documentation/UserManual/mitkClassificationMiniAppsPortalPage.dox
index 2f8f90c12c..32778b37b1 100644
--- a/Modules/Classification/documentation/UserManual/mitkClassificationMiniAppsPortalPage.dox
+++ b/Modules/Classification/documentation/UserManual/mitkClassificationMiniAppsPortalPage.dox
@@ -1,19 +1,19 @@
/**
\page mitkClassificationMiniAppsPortalPage MITK Classification Mini Apps
\tableofcontents
-The Classification Mini Apps bundle the functionality that is commonly neeeded for the processing and learning with medical images. As all other MiniApps, they follow the Slicer Execution Model in describing themselves via xml. You can simply obtain a description by calling the MiniApp without any parameter. If the MiniApp is calles with the option "--xml" a XML description of all possible parameter is added.
+The Classification Mini Apps bundle the functionality that is commonly neeeded for the processing and learning with medical images. As all other MiniApps, they follow the Slicer Execution Model in describing themselves via xml. You can simply obtain a description by calling the MiniApp without any parameter. If the MiniApp is calles with the option "--xml" a XML description of all possible parameter is added.
\section mcmasec1 Description of Mini Apps
\subsection mcmasub1 mitkCLGLobalImageFeatures
Allows to calculate features that describe the masked area. Can be used to obtain radiomics features.
\subsection mcmasub2 mitkCLN4
Allows to calculate a bias normalization.
\subsection mcmasub3 mitkCLStaple
Allows to combine multiple segmentations into a single segmentation using the STAPLE algorithm
*/
diff --git a/Modules/IGT/Documentation/doxygen/IGTModule.dox b/Modules/IGT/Documentation/doxygen/IGTModule.dox
index 166360cc87..db913f7312 100644
--- a/Modules/IGT/Documentation/doxygen/IGTModule.dox
+++ b/Modules/IGT/Documentation/doxygen/IGTModule.dox
@@ -1,78 +1,78 @@
/**
\page NavigationGeneralModulePage IGT Navigation Module
\section IGTGeneralModulePageOverview Overview
Navigation modules consist of IGT (Tracking devices), US (Ultrasound) and TOF (3D range imaging) modules. Each module is separated into UI dependent and independent modules (e.g. IGT and IGTUI module). The navigation modules are based on the OpenCVVideoSupport modules and OpenIGTLink modules. In addition, there is the basic module IGTBase, which holds general functionality for all navigation modules.
-Most navigation modules support hardware devices. A current list of all supported devices can be found here: Hardware Support.
+Most navigation modules support hardware devices. A current list of all supported devices can be found here: Hardware Support.
\section IGTModules IGT modules
The module IGT integrates image guided therapy (IGT) functionality to MITK. The main features of MITK-IGT are:
handling and processing of medical imaging data which is available through MITK itself
support of tracking devices
a concept for processing tracking data
MITK-IGT consists of two layers for hardware control (Tracking Layer) and processing of tracking data (Navigation Layer). Additionally it offers components for rapid development of graphicalt user interfaces (GUIs) of navigation applications. To separate UI functionality from the rest of the code UI classes are encapsulated in the separate module IGT-UI.
The IGT documentation contains the following pages:
\ref IGTConcepts - A general overview of the concepts used within the IGT module for acquiring and processing tracking data
\ref IGTTutorialOverview - This tutorial will guide you step by step through all plugins, modules and documentation pages. It contains the following steps:
\ref org_mitk_gui_qt_igttracking - Step 1: This tutorial step explains the usage of the most important IGT plugins
\ref IGTTutorialStepFilterPipeline - Step 2: This tutorial step on how to implement an IGT filter pipeline
\ref IGTTutorialStepVisualization - Step 3: This tutorial step creates a simple render window to visualize tracking tools.
\ref IGTTutorialStepSimplePlugin - Step 4: This tutorial step shows you how to create a simple plugin for tracking
\ref IGTTutorialStepTrackingLab - Step 5: This tutorial step gives step-by-step explanations on how to use the example tracking lab by registering a book of your choice.
\ref IGTTutorialStepAdvanced - Step 6: This step revises the code of the IGT plugins from the first step in more depth
\ref IGTTutorialStepOpenIGTLink - Step 7: This tutorial step gives an overview about OpenIGTLink in MITK
\ref IGTHowToImplementATrackingDevice - Step 8: This guideline is for an implementation of your own tracking device
\ref org_mitk_gui_qt_igttracking - Overview of all tracking views which could be used for your application
\ref org_mitk_views_igttrackingtoolbox - Connect your tracking device and start tracking
\ref org_mitk_views_igtnavigationtoolmanager - Edit your tool storage
\ref org_mitk_views_navigationdataplayer - Play your navigation data, e.g. recorded with the tracking toolbox
\ref org_mitk_gui_qt_igtexample - Overview of the example plugin
\ref org_imageguidedtherapytutorial - The plugin which is created in Step \ref IGTTutorialStepSimplePlugin
\ref org_igttrackinglab - The IGT-TrackingLab view which is described in step \ref IGTTutorialStepTrackingLab
\ref org_openigtlinkexample OpenIGTLink client example
\ref org_openigtlinkproviderexample OpenIGTLink server example
\ref org_openigtlinkplugin An extended OpenIGTLink example
\section USModules US modules
\li The ultrasound user manual: \ref USModulePage
\section TOFModules TOF modules
\ref org_toftutorial
An explanation on how to create a TOF Module can be found here:
\li \subpage GeneratingDeviceModulesPage
-*/
\ No newline at end of file
+*/
diff --git a/Modules/OpenCL/Documentation/doxygen/MitkOpenCL.dox b/Modules/OpenCL/Documentation/doxygen/MitkOpenCL.dox
index 5d97240a63..bbe20e21d7 100644
--- a/Modules/OpenCL/Documentation/doxygen/MitkOpenCL.dox
+++ b/Modules/OpenCL/Documentation/doxygen/MitkOpenCL.dox
@@ -1,49 +1,48 @@
/**
\page MitkOpenCL_Example Examples
This is a list of available examples:
- \subpage MitkOpenCL_BinaryThresholdFilter
*/
/**
\page MitkOpenCL_Overview OpenCL Module
The MITK OpenCL Module provides a basic class structure to allow usage of OpenCL-accelerated parallel computing.
Build Instructions
-The MITK OpenCL module needs an OpenCL Device ( most likely a graphics card, but works also on some CPUs ) and the corresponding driver. Furthermore the OpenCL library and the headers are needed. A list of supported hardware is provided by Khronos.org . For the driver and the libraries please look at the support pages of the hardware manufacturer. Quick Links to the most likely of them:
+The MITK OpenCL module needs an OpenCL Device ( most likely a graphics card, but works also on some CPUs ) and the corresponding driver. Furthermore the OpenCL library and the headers are needed. A list of supported hardware is provided by Khronos.org . For the driver and the libraries please look at the support pages of the hardware manufacturer. Quick Links to the most likely of them:
- NVIDIA OpenCL Page
-- AMD/ATI OpenCL Page
-- Intel OpenCL SDK
+- Intel OpenCL SDK
To activate the module, you have to activate the CMake option
\verbatim
MITK_USE_OpenCL
\endverbatim
The build system tries to find the OpenCL library and the include path automatically. If this attempt failes, you will be prompted to manually specify following variables:
\verbatim
OPENCL_INCLUDE_DIRS
OPENCL_LIBRARIES
\endverbatim
Detailed description
For own implementations, the OpenCL Module allows for building up a filtering pipeline in MITK Style ( see more in \ref PipelineingConceptPage ). The OpenCL filter can be simply connected also to an existing MITK image filtering pipeline since the mitk::OclImageToImageFilter provide a SetInput and GetOutput methods expecting an mitk::Image and returning it respectively.
Examples
Here is a list of \subpage MitkOpenCL_Example "examples":
- \ref MitkOpenCL_BinaryThresholdFilter
*/
diff --git a/Plugins/org.mitk.gui.qt.basicimageprocessing/documentation/UserManual/QmitkBasicImageProcessing.dox b/Plugins/org.mitk.gui.qt.basicimageprocessing/documentation/UserManual/QmitkBasicImageProcessing.dox
index e67b1b862b..8a06e1fe2a 100644
--- a/Plugins/org.mitk.gui.qt.basicimageprocessing/documentation/UserManual/QmitkBasicImageProcessing.dox
+++ b/Plugins/org.mitk.gui.qt.basicimageprocessing/documentation/UserManual/QmitkBasicImageProcessing.dox
@@ -1,126 +1,126 @@
/**
\page org_mitk_views_basicimageprocessing The Basic Image Processing
\imageMacro{QmitkBasicImageProcessing_ImageProcessing_48.png,"Icon of the Basic Image Processing Plugin",2.00}
\tableofcontents
\section QmitkBasicImageProcessingUserManualSummary Summary
This view provides an easy interface to fundamental image preprocessing and enhancement filters.
It offers filter operations on 3D and 4D images in the areas of noise suppression, morphological operations, edge detection and image arithmetics,
as well as image inversion and downsampling.
Please see \ref QmitkBasicImageProcessingUserManualOverview for more detailed information on usage and supported filters.
If you encounter problems using the view, please have a look at the \ref QmitkBasicImageProcessingUserManualTrouble page.
\section QmitkBasicImageProcessingUserManualOverview Overview
This view provides an easy interface to fundamental image preprocessing and image enhancement filters.
It offers a variety of filter operations in the areas of noise suppression, morphological operations, edge detection and image arithmetics.
Currently the view can be used with all 3D and 4D image types loadable by MITK.
2D image support will be added in the future.
All filters are encapsulated from the Insight Segmentation and Registration Toolkit (ITK, www.itk.org).
\imageMacro{QmitkBasicImageProcessing_BIP_Overview.png,"MITK with the Basic Image Processing view",16.00}
This document will tell you how to use this view, but it is assumed that you already know how to use MITK in general.
\section QmitkBasicImageProcessingUserManualFilters Filters
This section will not describe the fundamental functioning of the single filters in detail, though.
-If you want to know more about a single filter, please have a look at http://www.itk.org/Doxygen316/html/classes.html
+If you want to know more about a single filter, please have a look at https://itk.org/Doxygen/html/index.html
or in any good digital image processing book. For total denoising filter, please see Tony F. Chan et al., "The digital TV filter and nonlinear denoising".
Available filters are:
\a Single image operations
Noise Suppression
Gaussian Denoising
Median Filtering
Total Variation Denoising
Morphological Operations
Dilation
Erosion
Opening
Closing
%Edge Detection
Gradient Image
Laplacian Operator (Second Derivative)
Sobel Operator
Misc
Threshold
Image Inversion
Downsampling (isotropic)
\a Dual image operations
Image Arithmetics
Add two images
Subtract two images
Multiply two images
Divide two images
Binary Operations
Logical AND
Logical OR
Logical XOR
\section QmitkBasicImageProcessingUserManualUsage Usage
All you have to do to use a filter is to:
Load an image into MITK
Select it in data manager
Select which filter you want to use via the drop down list
Press the execute button
A busy cursor appeares; when it vanishes, the operation is completed. Your filtered image is displayed and selected for further processing.
(If the checkbox "Hide original image" is not selected, you will maybe not see the filter result imideately,
because your filtered image is possibly hidden by the original.)
For two image operations, please make sure that the correct second image is selected in the drop down menu, and the image order is correct.
For sure, image order only plays a role for image subtraction and division. These are conducted (Image1 - Image2) or (Image1 / Image2), respectively.
Please Note: When you select a 4D image, you can select the time step for the filter to work on via the time slider at the top of the GUI.
The 3D image at this time step is extracted and processed. The result will also be a 3D image.
This means, a true 4D filtering is not yet supported.
\section QmitkBasicImageProcessingUserManualTrouble Troubleshooting
I get an error when using a filter on a 2D image.
2D images are not yet supported...
I use a filter on a 4D image, and the output is 3D.
When you select a 4D image, you can select the time step for the filter to work on via the time slider at the top of the GUI.
The 3D image at this time step is extracted and processed. The result will also be a 3D image.
This means, a true 4D filtering is not supported by now.
A filter crashes during execution.
Maybe your image is too large. Some filter operations, like derivatives, take a lot of memory.
Try downsampling your image first.
All other problems.
Please report to the MITK mailing list.
-See http://www.mitk.org/wiki/Mailinglist on how to do this.
+See https://www.mitk.org/wiki/MITK_Mailinglist on how to do this.
*/
diff --git a/Plugins/org.mitk.gui.qt.cmdlinemodules/documentation/UserManual/cmdlinemodules.dox b/Plugins/org.mitk.gui.qt.cmdlinemodules/documentation/UserManual/cmdlinemodules.dox
index ea56159ff5..8ff0940ab7 100644
--- a/Plugins/org.mitk.gui.qt.cmdlinemodules/documentation/UserManual/cmdlinemodules.dox
+++ b/Plugins/org.mitk.gui.qt.cmdlinemodules/documentation/UserManual/cmdlinemodules.dox
@@ -1,168 +1,168 @@
/**
\page org_mitk_views_cmdlinemodules The Command Line Modules View
\imageMacro{cmdlinemodules_Icon.png,"Icon of the Command Line Modules View",2.00}
\tableofcontents
\section CLIPrefix Contribution
-This plugin was developed at the Centre For Medical Image Computing (CMIC),
-part of University College London (UCL) and contributed back to the
-MITK community with thanks.
+This plugin was developed at the Centre For Medical Image Computing (CMIC),
+part of University College London (UCL) and contributed back to the
+MITK community with thanks.
\section CLIIntroduction Introduction
This view provides the facility to run third party command line programs, and load the data back
into the DataManager for immediate visualisation. All that is required is that the command line application can be called
with an argument of --xml and respond with a valid XML description of the necessary parameters,
and currently, that if the program requires images, they must be NifTI images.
This view can then generate a Graphical User Interface (GUI) dynamically from the XML to enable the
user to interact with the command line application. This provides an easy to use, and potentially
very flexible way to integrate almost any third party, medical imaging, command line application.
As a high level introduction, this view performs the following steps:
\li The view searches for available programs to run, and for each valid module, stores the XML document describing
the interface, and populates a searchable list of available programs.
\li When a program is selected, the GUI is generated.
\li The user can then set the necessary parameters and run the program.
\li Multiple programs can be launched in succession and run simultaneously, and where available on the host platform,
the user can pause, resume or cancel running jobs and see console output for each job.
As a consequence of the very flexible nature of this plugin, these instructions can only describe how to launch
command line modules in a general sense. The examples shown have been constructed by the latest version of the NiftyReg package.
Futher information on the NiftyReg package, including links to the source code, can be found on the wiki page here.
NiftyReg provides valid XML descriptors to enable the integration of the NiftyReg affine (RegAladin) and and non-rigid (RegF3D) image registration algorithms, as well
as utility programs to resample an image, and calculate a Jacobian image. These same XML descriptors work within
-Slicer and MITK based applications.
+Slicer and MITK based applications.
\section CLIPreferences Preferences
The first time that the Command Line Modules View is launched, it is advisable to set the user preferences for the view. Please refer
to Figure 1.
\imageMacro{cmdlinemodules_Preferences.png,"Figure 1. The Command Line Modules Preferences Page",16.00}
Each of these preferences is now explained in some detail.
\li show debug output: If checked will output more messages to the console for debugging purposes.
\li show advanced widgets: If selected, additional widgets appear in the front-end for advanced users.
\li XML time-out (secs): Sets the time-out for the retrieval of the XML.
\li XML validation mode: The user may select a different mode for XML validation. If this is changed, the application will
need to be restarted. There are 3 modes available. If the user selects "strict" mode, the XML schema produced by the
-command line application must exactly conform to
+command line application must exactly conform to
this definition. For "none", there will be no validation. For "weak" validation, the application will report errors,
but try to carry on and load as many modules as possible. The XML validation errors are available as tool-tips on
the tab widget when the module is launched. Many third party modules included with Slicer currently have
incorrect XML (typically, mis-ordered XML tags), and so the "weak" or "none" mode may assist in loading them.
By default the "weak" mode is chosen so that only valid modules are loaded.
\li max concurrent processes: Sets the maximum number of concurrent jobs that can be run via this interface. The default is 4.
When the maximum number is reached, the green "Run" button is disabled until a job finishes.
The next 7 preferences are to control where the view will search for valid command line programs. By default these are off
as the searching process can take a long time and slow down the startup time of the GUI. The options provided are:
\li scan installation dir: This is the directory where the actual application is stored.
\li scan installation dir/cli-modules: Scans the sub-directory called cli-modules under the application installation directory.
\li scan home dir: Scan the users home directory. (See QDir::homePath().)
\li scan home dir/cli-modules: Scans the sub-directory called cli-modules under the users home directory.
\li scan current dir: Scan the current working directory. (See QDir::homePath().)
\li scan current dir/cli-modules: Scans the sub-directory called cli-modules under the current working directory.
\li scan CTK_MODULE_LOAD_PATH: Scans the directory or list of directories defined by the environment variable CTK_MODULE_LOAD_PATH.
A list is colon separated on Linux/Mac, and semi-colon separated on Windows.
In most cases, it is suggested that the user will leave these options unchecked, as the user can also
specify custom directories, and even cherry-pick specific command line programs to load. Figure 2 shows
a selection box that enables the user to specify custom directories to scan, and Figure 3. shows a selection
box that enables the user to select specific modules. Picking specific directories, and specific executables
will most likely make the application quicker to launch.
\imageMacro{cmdlinemodules_PreferencesAdditionalDirectories.png,"Figure 2. The User can specify specific directories to scan.",7.90}
\imageMacro{cmdlinemodules_PreferencesAdditionalModules.png,"Figure 3. The User can specify specific command line programs to load.",7.92}
These directory and file selection boxes enable directories or files to be added, removed and updated in a similar fashion.
The user must make sure that the list of files selected in the "additional modules" section are not already contained within
the directories specified in the "additional module directories" section.
In addition, the preferences page provides:
\li temporary directory: Images stored in the DataManager are first written to a temporary folder as
-Nifti images before being passed to each command line program.
+Nifti images before being passed to each command line program.
This temporary directory will default to a platform specific temporary folder, but the user may select their preferred choice
of temporary workspace.
\section CLIUsage Usage
When the view is launched, a simple interface is presented, as shown in Figure 4.
\imageMacro{cmdlinemodules_Initial.png,"Figure 4. The initial interface\, with no command line programs available.",8.66}
In this example, all the above check-box preferences were off, and the "additional module directories"
was empty, and the "additional modules" list was empty so no command line applications were found.
The "Search" box displays zero entries, and there is nothing to search.
If the available search paths contain programs that are compatible (i.e. runnable) with this view,
the name of the programs are displayed in the "Search" box in a nested menu, shown in Figure 5.
\imageMacro{cmdlinemodules_WithPrograms.png,"Figure 5. When valid paths are set\, and programs are discovered\, the menu is recalculated to show available programs.",10.54}
When a program is selected, the relevant interface is displayed, by default as collapsed group boxes to save space.
Each section can be individually expanded if necessary to see the parameters.
\imageMacro{cmdlinemodules_NiftyReg.png,"Figure 6. An example program\, showing parameters for NiftyReg's program RegAladin.",10.24}
In this example, the parameters are displayed for NiftyReg
-produced at UCL, and more specifically for the affine registration program called
+produced at UCL, and more specifically for the affine registration program called
RegAladin. The interface can contain a wide variety of controls. If a parameter for a command line program is an input image,
then the widget displayed is linked to the DataManager, so that as new images are loaded, the correct image can be easily
selected from the combo box.
At this stage, multiple tabs can be opened, with one tab for each command line program. Figure 7 shows 2 tabs,
for the RegAladin and RegF3D programs.
\imageMacro{cmdlinemodules_F3D.png,"Figure 7. Multiple tabs can be opened\, one for each command line program.",10.24}
The main view provides some simple controls:
\li Green arrow: Launch (run) the command line executable of the currently selected tab.
\li Yellow undo arrow: Resets the GUI controls of the currently selected tab to default values, if and only if the original XML specified a default value.
At this stage, nothing has been launched. When the user hits the green arrow button, a job is launched.
Each running job is shown as a new progress reporting widget under the main tabbed widget, as shown in Figure 8.
\imageMacro{cmdlinemodules_NiftyRegRunning2.png,"Figure 8. Multiple programs can be run\, each with individual controls and console output.",10.24}
The controls for each running job are:
\li Blue pause button: If supported on the host platform, this button will be enabled and can be toggled off (pause) or on (resume).
\li Red square: If supported on the host platform, this button will kill the command line program.
\li Black cross: Will remove the progress reporting widget from the GUI.
When the user hits the green arrow in the main view:
\li The currently selected tab is designated the "current" job, and contains the "current" set of parameters.
\li A new progress reporting widget is created.
\li The current parameters are copied to the progress reporting widget. In Figure 8. a parameters section
is visible, and by default is collapsed, as they are simply for referring back to.
\li All the output for the command line program is shown in the console widget, with a separate console for each job.
\li Each new progress reporting widget is simply stacked vertically (newest is top-most), and it is up to the
user to delete them when they are finished.
It is easy to run multiple jobs. The green button simply launches the job corresponding to the current tab repeatedly.
It is up to the user to make sure that any output file names are changed between successive invocations of the same command
line module to avoid overwritting output data.
In addition, each set of parameters contains an "About" section containing details of the contributors, the licence and acknowledgements and also
a "Help" section containing a description and a link to any online documentation.
These documentation features are provided by the developers of the third party plugin, and not by the host program.
If information is missing, the user must contact the third party developers.
\section CLITechnicalNotes Technical Notes
From a technical perspective, the Command Line Modules View is a simple view, harnessing the power of the CTK
-command line modules framework. For technical information see the CTK wiki page
+command line modules framework. For technical information see the CTK wiki page
and obviously the CTK code base.
*/
diff --git a/Plugins/org.mitk.gui.qt.cmdlinemodules/documentation/doxygen/modules.dox b/Plugins/org.mitk.gui.qt.cmdlinemodules/documentation/doxygen/modules.dox
index d8a6d2bd25..21b3313b85 100644
--- a/Plugins/org.mitk.gui.qt.cmdlinemodules/documentation/doxygen/modules.dox
+++ b/Plugins/org.mitk.gui.qt.cmdlinemodules/documentation/doxygen/modules.dox
@@ -1,18 +1,18 @@
/**
\defgroup org_mitk_gui_qt_cmdlinemodules org.mitk.gui.qt.cmdlinemodules
\ingroup MITKPlugins
\brief This plugin, provided by University College London (UCL), written by Matt
- Clarkson (m.clarkson@ucl.ac.uk) uses the CTK (http://www.commontk.org) Command
+ Clarkson (m.clarkson@ucl.ac.uk) uses the CTK (https://commontk.org/) Command
Line Modules library to run command line programs as an external process.
*/
/**
\defgroup org_mitk_gui_qt_cmdlinemodules_internal Internal
\ingroup org_mitk_gui_qt_cmdlinemodules
\brief This subcategory includes the internal classes of the org.mitk.gui.qt.cmdlinemodules plugin. Other
plugins must not rely on these classes. They contain implementation details and their interface
may change at any time. We mean it.
*/
diff --git a/Plugins/org.mitk.gui.qt.common.legacy/documentation/doxygen/modules.dox b/Plugins/org.mitk.gui.qt.common.legacy/documentation/doxygen/modules.dox
index f895c8411e..bd669c5afb 100755
--- a/Plugins/org.mitk.gui.qt.common.legacy/documentation/doxygen/modules.dox
+++ b/Plugins/org.mitk.gui.qt.common.legacy/documentation/doxygen/modules.dox
@@ -1,19 +1,19 @@
/**
\defgroup org_mitk_gui_qt_common_legacy org.mitk.gui.qt.common.legacy
\ingroup MITKPlugins
\brief Provides legacy classes and functionality common for MITK plug-ins.
-
+
\deprecated This plug-in is deprecated. Old plug-ins having a dependency on it should
- migrate to the org_mitk_gui_qt_common Plug-in using http://www.mitk.org/wiki/ViewsWithoutMultiWidget
-
+ migrate to the org_mitk_gui_qt_common Plug-in using https://www.mitk.org/wiki/Views_Without_Multi_Widget
+
*/
/**
\defgroup org_mitk_gui_qt_common_legacy_internal Internal
\ingroup org_mitk_gui_qt_common_legacy
\brief This subcategory includes the internal classes of the org.mitk.gui.qt.common.legacy plugin. Other
plugins must not rely on these classes. They contain implementation details and their interface
may change at any time. We mean it.
*/
diff --git a/Plugins/org.mitk.gui.qt.dicombrowser/documentation/UserManual/QmitkDicom.dox b/Plugins/org.mitk.gui.qt.dicombrowser/documentation/UserManual/QmitkDicom.dox
index e90b0a2e04..d69c4c5e55 100644
--- a/Plugins/org.mitk.gui.qt.dicombrowser/documentation/UserManual/QmitkDicom.dox
+++ b/Plugins/org.mitk.gui.qt.dicombrowser/documentation/UserManual/QmitkDicom.dox
@@ -1,118 +1,118 @@
/**
\page org_mitk_editors_dicombrowser The Dicom Browser Plugin
\imageMacro{dicombrowser-dox.svg,"Icon of the DICOM Plugin",2.00}
\note This article requires a basic knowledge of the DICOM Standard.
\tableofcontents
\section org_mitk_gui_qt_dicomOverview Overview
The DICOM editor is an experimental editor which allows for loading of DICOM images as well as server communication.
It features a highly experimental query/retrieve (you need to configure your PACS correspondingly) as well as a DICOM browser.
The DICOM browser allows you to navigate the DICOM folder/cd depending on its metadata (patient/study/series)
and import selected series for viewing in your MITK based application.
It also allows you to store your dicom data in an internal database so you can easily access often used dicom images.
-It is based on the commonTK (CTK) DICOM funcionality.
+It is based on the commonTK (CTK) DICOM funcionality.
\section org_mitk_gui_qt_dicomDataHandling Data handling
\imageMacro{QmitkDicom_PluginControls.png,"The dicom Plugin controls",7.37}
In the image above you see the start page of the dicom plugin. On top of the start page you see four buttons. The Local Storage,
the Import CD, the Import Folder and the Query Retrieve button. If you press one of these buttons, the dicom plugin will switch to your local dicom image storage or will start importing dicom images
from CD or a folder on your hard drive or it will open the query retrieve screen.
Click the 'Local Storage' button to open the local storage screen.
Click the 'Import CD' button to import DICOM data from a CD.
Click the 'Import Folder' button to import DICOM date from a directory.
Click the 'Query Retrieve' button to open the query retrieve screen.
\subsection org_mitk_gui_qt_dicomStorage Data storage
\imageMacro{QmitkDicom_PluginExtended.png,"The DICOM data storage",16.00}
If you open the dicom plugin the dicom data storage will be displayed. You are able to see all your stored dicom image data.
You can browse your data by clicking on the left arrow beside the name of your data. There are three levels available.
The first level is the patient level where you can see the patient data. On the second level you can see the dicom studies for the patient.
on the third level you can see all available series refering to it's study.
You can delete the data by selecting it and pressing the delete button.
Be careful if you have selected a patient or a study all refering data be deleted.
So if you delete a patient the patient and all studies and series refered to the patient will be deleted.
If you delete a study all series of the study will be deleted.
If you want to view the dicom data you have to select a series and click on the View button.
The data will appear in the DataManager and will be dispayed.
\imageMacro{QmitkDicom_DisplayDataManager.png,"Viewed image",16.00}
Click on the arrow on the left of your data to expand or hide dicom data levels.
Click the 'Delete' button to delete selected DICOM data.
Click the 'View' button to view DICOM data.
\subsection org_mitk_gui_qt_dicomImport Data import
\imageMacro{QmitkDicom_ImportDialog.png,"The import dialog checked",9.53}
There are two diffrent ways to import DICOM data.
The First one is to directly imort it into your DICOM data storage. To achieve this you should toggle the checkbox 'Copy on import'.
The second approach is, to have a look at the data first before importing it.
To do that you simply don't check 'Copy on import'.
This will leed you to the leed you to the 'External Dicom Data' screen which provides you a preview of the data containing in youre choosen folder.
You can import the data here by selecting it and pressing the 'Download' button.
It is also possible to view DICOM series directly in Mitk by selecting it here and pressing the 'View' button.
Click 'Import Folder' or 'Import CD' button to open the import dialog.
Enable the 'Copy on import' checkbox and choose a folder to import into data storage directly.
Disable the 'Copy on import' checkbox to get to the 'External Dicom Data' screen.
Click on the arrow on the left of your data to expand or hide dicom data levels.
Click the 'Download' button to download selected DICOM data to your DICOM data storage.
Click the 'View' button to view DICOM data.
\section org_mitk_gui_qt_dicomQueryRetrieve Query/Retrieve
\warning This plugin is experimental and not all of the described features behave as expected.
\note The query retrieve plugin only works if the PACS you are calling knows your machine settings.
There are also issues when you are running a firewall.
The query retrieve workflow allows you to get DICOM data from a server.
\imageMacro{QmitkDicom_QueryRetrieve.png,"The query retrieve screen",16.00}
\subsection org_mitk_gui_qt_dicomQuery Query
\imageMacro{QmitkDicom_Nodes.png,"The DICOM network configuration",11.26}
By performing a DICOM query you will ask a server for it's DICOM data.
This requires to setup the DICOM network configuration of your system and the server.
By clicking on 'Add Server' a new plain server field will appear. Now you can give it a name of your choice.
Fill the servers "DICOM name" the AETitle. Type in it's url, it's port and the specific DICOM protocoll you want to use for image transfer.
\note I recommend not to use CGET because most of the PACS systems (Image Servers) don't support that protocoll.
You can configure the DICOM network configuration of your machine by editing the 'Calling AETiltle', the 'Storage AETitle' and The 'Storage Port' text fields.
But normaly you don't have to change your configuration.
\imageMacro{QmitkDicom_FilterWidget.png,"The DICOM search options",3.66}
After you have finished your network configuration and before you start the query you should use the 'Search Options' to specify your query.
Otherwise all data on the server will be queried and you will have to wait for a long time.
You can specify your query by searching for a specific patient name or a study or a serie or a specific DICOM object by it's id.
You are allowed to include or exclude DICOM modalities from your query and you can specify a specific time in which the DICOM images you are searching fo might been captured.
When you finished that you can click the query button and the queried DICOM data will appear.
Click on the 'Add Server' button.
Edit 'Name' field.
Edit 'AETitle' field.
Edit 'Adress' field.
Edit 'Port' field.
Set search options.
Click on 'Query' button.
\subsection org_mitk_gui_qt_dicomRetrieve Retrieve
\imageMacro{QmitkDicom_Retrieve.png,"The queried DICOM data.",15.22}
After the query you are able to select the queried data and click the 'Retrieve' button.
This will store the queried DICOM data into your DICOM storage.
Click on the 'Local Storage' button and work with your new data.
Click on the 'Retrieve' button to retrieve the data to your DICOM storage.
Click on the 'Local Storage' button.
*/
diff --git a/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkMITKIGTTrackingToolbox.dox b/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkMITKIGTTrackingToolbox.dox
index af0a780b45..1e80ec7f9f 100644
--- a/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkMITKIGTTrackingToolbox.dox
+++ b/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkMITKIGTTrackingToolbox.dox
@@ -1,93 +1,93 @@
/**
\page org_mitk_views_igttrackingtoolbox The MITK-IGT Tracking Toolbox
\imageMacro{iconTrackingToolbox.png,"Icon of the MITK-IGT Tracking Toolbox",2.00}
\tableofcontents
\section QmitkMITKIGTTrackingToolboxIntroduction Introduction
The MITK-IGT Tracking Toolbox is a view which allows you to connect to a tracking device, track and visualize navigation tools and write the tracked data into a log file.
This page gives an overview of the view and is at the same time part of the IGT tutorial step \ref org_mitk_gui_qt_igttracking. All parts containing instructions
for the tutorial begin with the bold printed label Tutorial.
\imageMacro{QmitkIGTTracking_ScreenshotMitk.png,"MITK Screenshot with the TrackingToolbox activated",16.00}
\section QmitkMITKIGTTrackingToolboxWorkflow General workflow Introduction
-Currently the devices Polaris, Aurora (both Northern Digital Inc. (NDI); Waterloo, Ontario, Canada), MicronTracker (Claron Technology, Inc.; Toronto, Ontario, Canada) and Optitrack (NaturalPoint) are supported (see Hardware Tracking Device Support). Different tracking hardware can be used via OpenIGTLink connections (see \ref IGTTutorialStepOpenIGTLink "Open IGT Link tutorial"
+Currently the devices Polaris, Aurora (both Northern Digital Inc. (NDI); Waterloo, Ontario, Canada), MicronTracker (Claron Technology, Inc.; Toronto, Ontario, Canada) and Optitrack (NaturalPoint) are supported (see Hardware Tracking Device Support). Different tracking hardware can be used via OpenIGTLink connections (see \ref IGTTutorialStepOpenIGTLink "Open IGT Link tutorial"
). For this Tracking Toolbox tutorial, we will use a virtual tracking device, which allows you to use simulated tracking data. This is very helpful if you want to test or implement some tracking application and don't have the hardware always available.
A general Workflow with the Tracking Toolbox may be:
Configuration of a tracking device
Adding or loading a toolfile which holds tool definitions
Start tracking
Logging tracked data
Tutorial: In the following sections, we will get familiar with each of these points using the Virtual Tracking Device.
\section QmitkMITKIGTTrackingToolboxConnecting Tracking Device Configuration
The tracking device can be specified in the tracking device configuration section located in the upper area of the tracking tab. As shown in the screenshot below, you choose your tracking device in the drop down menu.
If you use a real tracking system, you might need to set some parameters like the serial port for Aurora or Polaris or the host name for your OpenIGTLink connection. Most implemented tracking device include an option to test your conection. Therefore you just need to press the button "test connection". The results are displayed in the small black box on the right.
Tutorial: For a first introduction, please select the virtual tracking device in the drop-down-menu. You should see an option to add some jittering to the simulated data.
\imageMacro{QmitkIGTTracking_ConfigurationWidget.png,"Tracking Device Configuration",8.55}
\section Tracking Tools
For tracking, you need information about your tools. You can either add single tools, load previously created tool storages or for some devices auto-detect all available tools. The best way to edit tools after creation/loading is \ref org_mitk_views_igtnavigationtoolmanager view. Creation of new tools or loading of existing tool storages can be done within the Tracking Tool Widget.
\imageMacro{QmitkIGTTracking_NavigationToolManagement_TrackingTools.png, "The tracking tool widget for adding or loading tools.",9.00}
All added or loaded tools will then be displayed in grey as shown in the screenshot below. If you start tracking they will become green if the tools were found and red if they were not found inside the tracking volume.
\imageMacro{QmitkIGTTracking_TrackingToolsWidget.png,"Added Tracking Tools",9.08}
\subsection QmitkMITKIGTTrackingToolboxAddingTools Adding tools
The most simple step to begin with is to add new tools with this widget. The same widget is also available within \ref org_mitk_views_igtnavigationtoolmanager view and the single parameters are explained there in more detail.
\imageMacro{QmitkIGTTracking_NavigationToolManagementAddTool.png,"Adding a new tool", 9.00}
Tutorial: Please click the "Add single tool" button and make sure, that the Virtual Tracker is selected in the drop-down-menu (the tracking device configured in the first step must always match your tools!). You might want to give your tool a new name in the "Basic Information" section and load a surface for visualization in the "Tool Visualization" section (a surface file can be found in your binary folder if you did compile MITK by yourself: MITK-superbuild\MITK-Data\IGT-Data\ClaronTool.stl). If you don't have any surface data, you can just select "use simple cone". Click on "Finished" and repeat this step to add a second tool.
\subsection QmitkMITKIGTTrackingToolboxLoadingTools Loading tools
To load tools which can be tracked you need a predefined tracking tool storage. You can use the MITK \ref org_mitk_views_igtnavigationtoolmanager view to define a navigation tool storage or to save the tools created within the last step in a toolstorage.
Navigation tool storages can be loaded by pressing the button "Load Tools". Please ensure that the tracking device type of the tools matches the chosen tracking device, otherwise you will get an error message if you try to start tracking.
\subsection QmitkMITKIGTTrackingToolboxAutoDetection Auto detection of tools (only Aurora)
If you use the Aurora system you also have the possibility to automatically detect the connected tools. In this case a tracking tool storage is created by the software.
In the Tracking Device Configuration widget, a button "Auto Detection" appears. If you press this button the software connects to the system and automatically detects all connected tools. You will then be asked whether you want to save the detected tools as a tool storage to the hard drive. You might want to do this if you want to use or modify this tool storage later. In the automatically detected tool storage the tools are named AutoDetectedTools1, AutoDetectedTools2, and so on. Small spheres are used as tool surfaces. After autodetection the detected tools are loaded automatically even if you did not save them.
\section QmitkMITKIGTTrackingToolboxStartTracking Start/stop tracking
To start tracking, you first need to connect to your tracking device ("connect" button). If your tools or tool storage don't match the tracking device or if no connection can be established, this might give an error message here.
\imageMacro{QmitkIGTTracking_TrackingControl.png,"Tracking Control to start tracking.", 9.00}
If connected succesfully, the start tracking button is enabled. As soon as you clicked this button, the tool information and tools will be highlighted red or green (un-/successful tracking) and in case of successful tracking, it's position will be updated and the tools are visualized in the 3D view of MITK.
Note that options may not be changed after connecting the tracking device.
You can start, freeze, unfreeze and stop the tracking as long as you are connected. If you want to finish your tracking, please stop an disconnect your tracking device.
Tutorial: Please click "connect" and "start tracking". Both tools should move within the tracking volume, the position data should be updated in the tool widget and be highlighted green. You can freeze, unfreeze and stop/restart the tracking as often as you like. When finished, please stop and disconnect.
\section QmitkMITKIGTTrackingOptions Options
In the options tab you can enable or disable the visualization of the tracking volume and of the tool quaternions. If enabled, the tool quaternions are shown in the tool information. You can also define the update rate of the tracking data. The update rate should not be set higher than the update rate of the tracking system. Other options might be available here depending on the newest developement within MITK-IGT.
\imageMacro{QmitkIGTTracking_Options.png,"Recorded logging data.", 9.00}
\section QmitkMITKIGTTrackingToolboxLogging Logging features
The logging feature of the Tracking Toolbox supports logging in XML or CSV format.
If your device is tracking, you are able to log the tracking data by using the logging tab. You first must define a file name. You can then choose whether you want comma seperated (csv) or xml format. Press "Start Logging" to start logging. You can also limit the number of logged frames, which will cause the logging to stop automatically after the given number.
\imageMacro{QmitkIGTTracking_LoggingWidget.png,"Tracking options.", 9.00}
Tutorial: Please connect and start tracking as you already did in the last step, switch to the logging tab, specify a csv file and start logging for a view seconds. Stop the tracking after a short period of time. You should now find the specified file which should look similar to the following screenshot and contain position data for both tools:
\imageMacro{QmitkIGTTracking_LogFile.png,"Recorded logging data.", 9.00}
Return to the overview of the IGT Tracking Plugin views: \ref org_mitk_gui_qt_igttracking
-*/
\ No newline at end of file
+*/
diff --git a/Plugins/org.mitk.gui.qt.mitkworkbench.intro/documentation/UserManual/QmitkMITKWorkbenchUserManual.dox b/Plugins/org.mitk.gui.qt.mitkworkbench.intro/documentation/UserManual/QmitkMITKWorkbenchUserManual.dox
index 66d0526156..d7ebfef0a5 100644
--- a/Plugins/org.mitk.gui.qt.mitkworkbench.intro/documentation/UserManual/QmitkMITKWorkbenchUserManual.dox
+++ b/Plugins/org.mitk.gui.qt.mitkworkbench.intro/documentation/UserManual/QmitkMITKWorkbenchUserManual.dox
@@ -1,17 +1,17 @@
/**
org_mitkworkbench Using The MITK Workbench
QMitkMitkWorkbenchManualOverview What is the MITK Workbench
The MITK Workbench is not only used by medical researchers but also by developers. As such the kind and number of views it contains is highly variable and dependent on the specific build. Typically it contains no special perspectives and whatever views the developer deemed desirable. Be aware, that it may contain views which are work in progress and may behave erratically.
-If you have been given such an executable by someone, please refer to the appropriate section of the online documentation for up to date usage information on any module.
+If you have been given such an executable by someone, please refer to the appropriate section of the online documentation for up to date usage information on any module.
-Nightly online documentation
+Nightly online documentation
-If you are using a nightly installer, the MITK Workbench will contain nearly all views available in MITK and as such most likely will seem confusing. Again the list of modules might be a good starting point if you want to have a rough idea of what could be of interest to you.
+If you are using a nightly installer, the MITK Workbench will contain nearly all views available in MITK and as such most likely will seem confusing. Again the list of modules might be a good starting point if you want to have a rough idea of what could be of interest to you.
For a basic guide to MITK see \ref MITKUserManualPage .
*/
diff --git a/Plugins/org.mitk.gui.qt.pharmacokinetics.mri/documentation/UserManual/Manual.dox b/Plugins/org.mitk.gui.qt.pharmacokinetics.mri/documentation/UserManual/Manual.dox
index 126c9e07f2..91ea443d33 100644
--- a/Plugins/org.mitk.gui.qt.pharmacokinetics.mri/documentation/UserManual/Manual.dox
+++ b/Plugins/org.mitk.gui.qt.pharmacokinetics.mri/documentation/UserManual/Manual.dox
@@ -1,104 +1,104 @@
/**
\page org_mitk_views_pharmacokinetics_mri The DCE MR Perfusion DataFit View
\imageMacro{pharmacokinetics_mri_doc.svg,"Icon of the DCE MR Perfusion View",3.0}
\tableofcontents
\section FIT_DCE_Introduction Introduction
-In dynamic contrast-enhanced (DCE) MRI, pharmacokinetic (PK) modeling can be used to quantify tissue physiology.
-Parameters describing the tissue microvasculature can be derived by fitting a pharmacokinetic model, e.g. a compartment model, to the dynamic data.
+In dynamic contrast-enhanced (DCE) MRI, pharmacokinetic (PK) modeling can be used to quantify tissue physiology.
+Parameters describing the tissue microvasculature can be derived by fitting a pharmacokinetic model, e.g. a compartment model, to the dynamic data.
This view offers a comprehensive set of tools to perform pharmacokinetic analysis.
\section FIT_DCE_Contact Contact information
If you have any questions, need support, find a bug or have a feature request, feel free to contact us at www.mitk.org.
\subsection FIT_DCE_Cite Citation information
If you use the view for your research please cite our work as reference:\n\n
Debus C and Floca R, Ingrisch M, Kompan I, Maier-Hein K, Abdollahi A, Nolden M, MITK-ModelFit: generic open-source framework for model fits and their exploration in medical imaging – design, implementation and application on the example of DCE-MRI. https://doi.org/10.1186/s12859-018-2588-1 (BMC Bioinformatics 2019 20:31)
\section FIT_DCE_Data_and_ROI_Selection Time series and mask selection
\imageMacro{dce_mri_maskAndFittingStrategy.png, "Time series and mask selection.", 10}
In principle, every model can be fitted on the entire image. However, for model configuration reasons (e.g. AIF required) and computational time cost, this is often not advisable.
Therefore, apart from the image to be fitted (Selected Time Series), a ROI segmentation can be defined (Selected Mask), within which model fitting is performed.
The view currently offers Pixel based and/or ROI based averaged fits of time-varying curves. The ROI based fitting option becomes enabled, if a mask is selected.
\section FIT_DCE_General_models Supported models
Currently the following pharmacokinetic models for gadolinium-based contrast agent are available:
- The Descriptive Brix model \ref FIT_DCE_lit_ref1 "[1]"
- A semi-quantitative two/three segment linear model (2SL/3SL)
- The standard tofts model \ref FIT_DCE_lit_ref2 "[2]"
- The extended Tofts model \ref FIT_DCE_lit_ref3 "[3]"
- The two compartment exchange model (2CXM) \ref FIT_DCE_lit_ref4 "[4, 5]"
\section FIT_DCE_Settings Model settings
\imageMacro{dce_mri_modelSettings.png, "Model settings of the view for the standard Tofts model.", 10}
\subsection FIT_DCE_Settings_model Model specific settings
Selecting one of the \ref FIT_DCE_General_models "supported models" will open below tabs for further configuration of the model.
- The descriptive Brix model requires only definition of the duration of the bolus, i.e. the overall time of the injection (Injection Time [min]).
- The 3SL is a semi-quantitative descriptive model that distinguishes three different segments of the signal: A constant baseline, the initial fast rise (wash-in) and the final slow rise / signal decrease (washout). Each of these segments is approximated by a linear curve, with change points in-between. It requires no further configuration.
- The standard Tofts model, the extended Tofts model and the 2CXM are compartment models that require the input of the concentration time curve in the tissue feeding artery, the arterial input function (AIF).
In the DCE MR Perfusion Datafit View, the arterial input function can be defined in several ways. For patient individual image derived AIFs, select the radio button Select AIF from Image.
In that case, a segmentation ROI for the artery has to be selected. This can be done by clicking on the AIF Mask selection widget and selecting a suitable AIF segmentation from the data loaded in the Data Manager. In cases where the respective artery does not lie in the same image as the investigated tissue (e.g. in animal experiments, where a slice through the heart is used for AIF extraction), a dedicated AIF image can be selected using the corresponding Dedicated AIF image selection widget.
-An alternative option is to define the AIF via an external file by selecting Select AIF from File (e.g. for population derived AIFs or AIFs from blood sampling). By clicking the Browse button, one can select a csv file that holds the AIF values and corresponding timepoints (in tuple format (Time, Value)).
+An alternative option is to define the AIF via an external file by selecting Select AIF from File (e.g. for population derived AIFs or AIFs from blood sampling). By clicking the Browse button, one can select a csv file that holds the AIF values and corresponding timepoints (in tuple format (Time, Value)).
Caution: the file must not contain a header line, but the first line must start with Time and Intensity values.
Furthermore, the Hematocrit Level has to be set (from 0 to 1) for conversion from whole blood to plasma concentration. It is set as default to the literature value of 0.45.
\subsection FIT_DCE_Settings_start Start parameter
\imageMacro{dce_mri_start.png, "Example screenshot for start parameter settings.", 10}
In cases of noisy data it can be useful to define the initial starting values of the parameter estimates, at which optimization starts, in order to prevent optimization results in local optima.
Each model has default scalar values (applied to every voxel) for initial values of each parameter, however these can be adjusted.
Moreover, initial values can also be defined locally for each individual voxel via starting value images. To load a starting value image, change the Type from scalar to image. This can be done by double-clicking on the type cell.
-In the Value column, selection of a starting value image will be available.
+In the Value column, selection of a starting value image will be available.
\subsection FIT_DCE_Settings_constraint Constraints settings
\imageMacro{dce_mri_constraints.png, "Example screenshot for constraints settings.", 10}
To limit the fitting search space and to exclude unphysical/illogical results for model parameter estimates, constraints to individual parameters as well as combinations can be imposed.
Each model has default constraints, however, new ones can be defined or removed by the + and – buttons in the table.
The first column specifies the parameter(s) involved in the constraint (if multiple parameters are selected, their sum will be used) by selection in the drop down menu.
The second column Type defines whether the constraint defines an upper or lower boundary.
Value defines the actual constraint value, that should not be crossed, and Width allows for a certain tolerance width.
\subsection FIT_DCE_Settings_concentration Signal to concentration conversion settings
\imageMacro{dce_mri_concentration.png, "Example screenshot for concentration conversion settings.", 10}
Most models require contrast agent concentration values as input rather than raw signal intensities (i.e. all compartment models).
The DCE MR Perfusion DataFit View offers a variety of tools for the conversion from signal to concentration:
by means of relative and absolute signal enhancement, via a T1-map calculated by the variable flip angle method, as well as a special conversion for turbo flash sequences.
For the conversion methods, a baseline image prior to contrast agent arrival is required.
-In many data sets, multiple baseline images are available. The Baseline Range Selection allows for selection of a range of time frames, from which the average image (along the time dimension) is calculated and set as baseline input image.
+In many data sets, multiple baseline images are available. The Baseline Range Selection allows for selection of a range of time frames, from which the average image (along the time dimension) is calculated and set as baseline input image.
Remark: The number of the first time frame is 0.
\section FIT_DCE_Fitting Executing a fit
In order to distinguish results from different model fits to the data, a Fitting name can be defined.
As default, the name of the model and the fitting strategy (pixel/ROI) are given. This name will then be appended by the respective parameter name.\n\n
For development purposes and evaluation of the fits, the option Generate debug parameter images is available.
Enabling this option will result in additional parameter maps displaying the status of the optimizer at fit termination.
In the following definitions, an evaluation describes the process of cost function calculation and evaluation by the optimizer for a given parameter set.
- Stop condition: Reasons for the fit termination, i.e. criterion reached, maximum number of iterations,...
- Optimization time: The overall time from fitting start to termination.
- Number of iterations: The number of iterations from fitting start to termination.
- Constraint penalty ratio: Ratio between evaluations that were penalized and all evaluations. 0.0 means no evaluation was penalized; 1.0 all evaluations were. Evaluations that hit the failure threshold count as penalized, too.
- Constraint last failed parameter: Ratio between evaluations that were beyond the failure threshold. 0.0 means no evaluation was a failure (but some may be penalized).
- Constraint failure ratio: Index of the first (in terms of index position) parameter, which failed the constraints in the last evaluation.
After all necessary configurations are set, the button Start Modelling is enabled, which starts the fitting routine.
Progress can be seen in the message box on the bottom. Resulting parameter maps will afterwards be added to the Data Manager as sub-nodes of the analyzed 4D image.
\section FIT_DCE_lit References/Literature
- \anchor FIT_DCE_lit_ref1 [1] Brix G, Semmler W, Port R, Schad LR, Layer G, Lorenz WJ. Pharmacokinetic parameters in CNS Gd-DTPA enhanced MR imaging. J Comput Assist Tomogr. 1991;15:621–8.
- \anchor FIT_DCE_lit_ref2 [2] Tofts PS, Kermode AG. Measurement of the blood-brain barrier permeability and leakage space using dynamic MR imaging. 1. Fundamental concepts. Magn Reson Med. 1991;17:357–67.
- \anchor FIT_DCE_lit_ref3 [3] Sourbron SP, Buckley DL. On the scope and interpretation of the Tofts models for DCE-MRI. Magn Reson Med. 2011;66:735–45.
- \anchor FIT_DCE_lit_ref4 [4] Brix G, Kiessling F, Lucht R, Darai S, Wasser K, Delorme S, et al. Microcirculation and microvasculature in breast tumors: Pharmacokinetic analysis of dynamic MR image series. Magn Reson Med. 2004;52:420–9.
-- \anchor FIT_DCE_lit_ref5 [5] Sourbron, Buckley. Tracer kinetic modelling in MRI: estimating perfusion and capillary permeability - pdf. Phys Med Biol. 2012. http://iopscience.iop.org/article/10.1088/0031-9155/57/2/R1/pdf. Accessed 1 May 2016.
+- \anchor FIT_DCE_lit_ref5 [5] Sourbron, Buckley. Tracer kinetic modelling in MRI: estimating perfusion and capillary permeability - pdf. Phys Med Biol. 2012. https://iopscience.iop.org/article/10.1088/0031-9155/57/2/R1/pdf. Accessed 1 May 2016.
*/
diff --git a/Plugins/org.mitk.gui.qt.radiomics/documentation/doxygen/tutorial_gui/RadiomicsTutorial_GUI_00_PortalPage.dox b/Plugins/org.mitk.gui.qt.radiomics/documentation/doxygen/tutorial_gui/RadiomicsTutorial_GUI_00_PortalPage.dox
index 6d7f5351bf..315c0640e1 100644
--- a/Plugins/org.mitk.gui.qt.radiomics/documentation/doxygen/tutorial_gui/RadiomicsTutorial_GUI_00_PortalPage.dox
+++ b/Plugins/org.mitk.gui.qt.radiomics/documentation/doxygen/tutorial_gui/RadiomicsTutorial_GUI_00_PortalPage.dox
@@ -1,22 +1,22 @@
/**
\page org_mitk_views_radiomicstutorial_gui_portal GUI based Radiomics Tutorial
-This is an basic tutorial to show how MITK Phenotyping can be used to perform the individual steps of an radiomics study. It assumes that you have MITK Phenotyping running on your server, and focuses on the usage of the graphical interface.
+This is an basic tutorial to show how MITK Phenotyping can be used to perform the individual steps of an radiomics study. It assumes that you have MITK Phenotyping running on your server, and focuses on the usage of the graphical interface.
-In order to use the Tutorial you need an 3D image. We will use the Pic3D.nrrd image, which can be downloaded from http://mitk.org/download/tutorial-data/Pic3D.nrrd . So if you want to have a better comparability between our results and your results, we suggest that you use this image as well. However, feel free to use your own image if you want.
+In order to use the Tutorial you need an 3D image. We will use the Pic3D.nrrd image, which can be downloaded from https://www.mitk.org/download/tutorial-data/Pic3D.nrrd . So if you want to have a better comparability between our results and your results, we suggest that you use this image as well. However, feel free to use your own image if you want.
-The tutorial is designed along the steps that would be perfomed within a radiomics study until to the point where the radiomic features are obtained and the statistical analysis would be necessary. This should be done in the tool of choice of the scientist. Please be aware: This is not a real study, and you might perfom some steps differently or additional steps in a real radiomics study. The main aim of this study is to give the reader an idea how to perfom individual steps in MITK.
+The tutorial is designed along the steps that would be perfomed within a radiomics study until to the point where the radiomic features are obtained and the statistical analysis would be necessary. This should be done in the tool of choice of the scientist. Please be aware: This is not a real study, and you might perfom some steps differently or additional steps in a real radiomics study. The main aim of this study is to give the reader an idea how to perfom individual steps in MITK.
-The first step is to make MITK Phenotyping and the MITK Workbench familiar to you. If you know the basic of the MITK Workbench, you can skip this step.
+The first step is to make MITK Phenotyping and the MITK Workbench familiar to you. If you know the basic of the MITK Workbench, you can skip this step.
\subpage org_mitk_views_radiomicstutorial_gui_01_basic
-The second step is to create a segmentation for the next steps. If you want to create the segmentations with a different tool, you can also skip this step.
+The second step is to create a segmentation for the next steps. If you want to create the segmentations with a different tool, you can also skip this step.
\subpage org_mitk_views_radiomicstutorial_gui_02_Segmentation
The third step is to preprocess the images. This step could also be perfomed before creating the segmentation, which is actually suggested. But it is common that the segmentations are already created for a study. Therefore, we put this step after the segmentation creation process.
\subpage org_mitk_views_radiomicstutorial_gui_03_preprocessing
The fourth and last step of this tutorial covers the calculation of the features with the graphical interface. We only use a limited amount of features, feel free to calculate more features in one step.
\subpage org_mitk_views_radiomicstutorial_gui_04_featurecalulation
-*/
\ No newline at end of file
+*/
diff --git a/Plugins/org.mitk.gui.qt.ultrasound/documentation/UserManual/QmitkUltrasound.dox b/Plugins/org.mitk.gui.qt.ultrasound/documentation/UserManual/QmitkUltrasound.dox
index 647b299416..3db5043352 100644
--- a/Plugins/org.mitk.gui.qt.ultrasound/documentation/UserManual/QmitkUltrasound.dox
+++ b/Plugins/org.mitk.gui.qt.ultrasound/documentation/UserManual/QmitkUltrasound.dox
@@ -1,95 +1,95 @@
/**
\page org_mitk_gui_qt_ultrasound The Ultrasound Plugin
\imageMacro{QmitkUltrasound_Icon.png,"Icon of the Ultrasound Plugin",2.12}
\tableofcontents
\section org_mitk_gui_qt_ultrasoundOverview Overview
This plugin offers a simple interface to create and manage ultrasound devices.
Devices, once configured, will be stored and loaded on the next start of MITK.
One can configure several aspects of the images acquired.
Last but not least, this plugin makes the configured devices available as a
microservice, exposing them for further usage in other plugins.
\section org_mitk_gui_qt_ultrasoundPrerequisites Prerequisites
To make use of this plugin, you obviously require an ultrasound device.
The device must have a video output or must be one of the supported API devices
(at the moment only Telemed LogicScan 128 is supported as an API device.
Typical video outputs are: HDMI, DVI, VGA and S-Video.
You also need a Video-Grabber that can acquire the image data from the
ultrasound device. In principal, this plugin is compatible with any grabber
that allows the operating system to access it's functionality.
However, not all grabbers are created equal. Make sure your grabber supports
the video-out offered by your ultrasound device and that it can achieve a
satisfying framerate. We have made good experiences with epiphan Grabbers and
currently recommend the Epiphan
+href="https://www.epiphan.com/products/dvi2usb-3-0/">Epiphan
DVI2USB 3.0 device which supports HDMI, DVI and VGA, but less costly
grabbers certainly are an option.
\section org_mitk_gui_qt_ultrasoundCreateDevice Creating an Device
To configure an ultrasound device as a video device, connect it to the grabber
and the grabber to the computer. Start the ultrasound device and open the
ultrasound plugin. The devicemanager will open.
\imageMacro{QmitkUltrasound_DeviceManagement.png,"MITK Screenshot With the Device Manager Activated",7.54}
Any currently configured devices are listed in the box, which accordingly is
empty now.
The creation of API devices depends on the device. A Telemed device would be
listed in the box if this version of MITK was compiled with support for Telemed
devices (see \link USHardwareTelemedPage \endlink). Such a device requires no
configuration.
Click "New Video Device" if you want to create a new video device.
\imageMacro{QmitkUltrasound_NewVideoDevice.png,"The 'New Device' form",7.62}
In the appearing form, enter descriptive data on your device in the
corresponding fields. Manufacturer and model will be used to display the device
in MITK.
You may choose the video source ID if more than one is available (as is the
case on laptops with built-in webcams). Try 0 and 1. If the wrong camera is
addressed, simply try the next ID.
Most ultrasound images are grey scale, so using a grey scale conversion doesn't
take information away from the image, but makes processing images significantly
faster. Only uncheck this box if you require color.
Click "Add Video Device" to save your changes.
\imageMacro{QmitkUltrasound_DeviceManagement2.png,"Devicemanager With a Configured Device",7.64}
An ultrasound device in MITK can be activated or removed. Removing may not be
available for some API devices. The device you just created is available to all
other plugins in MITK, but does not yet generate image data. Activating the
device will start image generating.
\section org_mitk_gui_qt_ultrasoundUseDevice Using an Ultrasound Device
Click the device, then click "Activate Device". The device is now activated and
generates image data continuously. The device is listed in the box on the
bottom of the view now. Viewing of the image data can be started by selecting
the device in this list and click the "Start Viewing" button.
\imageMacro{QmitkUltrasound_Imaging.png,"US Imaging Tab for a Video Device",7.60}
You can adjust the cropping parameters to reduce the acquired image size which
will further increase speed and remove unnecessary information.
All changes are saved and restored whenever MITK is started.
If an API device was selected, buttons for controlling the b mode imaging may
be available. This depends on the implementation of a control interface for
this specific device in MITK.
\imageMacro{QmikUltrasound_BModeControls.png,"B Mode Controls for an API Device",7}
*/