diff --git a/Applications/PluginGenerator/PluginTemplate/documentation/UserManual/Manual.dox b/Applications/PluginGenerator/PluginTemplate/documentation/UserManual/Manual.dox index 56feaaae05..8351db4f16 100755 --- a/Applications/PluginGenerator/PluginTemplate/documentation/UserManual/Manual.dox +++ b/Applications/PluginGenerator/PluginTemplate/documentation/UserManual/Manual.dox @@ -1,18 +1,18 @@ /** \page $(plugin-target) $(plugin-name) -\image html icon.xpm "Icon of $(plugin-name)" +\imageMacro{icon.png,"Icon of $(plugin-name)",2.00} Available sections: - \ref $(plugin-target)Overview \section $(plugin-target)Overview Describe the features of your awesome plugin here */ diff --git a/BlueBerry/Bundles/org.blueberry.ui.qt.log/documentation/UserManual/blueberrylogview.dox b/BlueBerry/Bundles/org.blueberry.ui.qt.log/documentation/UserManual/blueberrylogview.dox index 92453eb6f4..024eabec99 100644 --- a/BlueBerry/Bundles/org.blueberry.ui.qt.log/documentation/UserManual/blueberrylogview.dox +++ b/BlueBerry/Bundles/org.blueberry.ui.qt.log/documentation/UserManual/blueberrylogview.dox @@ -1,16 +1,16 @@ /** \page org_blueberry_ui_qt_log The Logging Plugin -\image html Logging.png "Icon of the Module" +\imageMacro{Logging.png,"Icon of the Module",2.00} This plug-in records all logging output of events and progress as specified in the source code with time of occurence, level of importance (Info, Warning, Error, Fatal, Debug), the message given and where it happens. The logging starts once the plug-is started. A screenshot of the provided Logging view is shown next. -\image html LogView.png "Screenshot of the Logging Module" +\imageMacro{LogView.png,"Screenshot of the Logging Module",16.00} There are different features available in the view. The filter text field allows for searching all log events containing a certain substring. Using the button "Copy to clipboard" on the bottom right you can copy the current content of the logging view to your clipboard. This enables you to insert the logging information to any text processing application. You can also show more information on every logging message by activating the two checkboxes. In the simple view, leaving both checkboxes unchecked, you'll see logging messages and logging levels. A brief description of the logging levels can be found in the \ref LoggingPage "logging concept documentation". The checkbox "Category" adds a column for the category. The checkbox "Show Advanced Field" shows method, filename and linenumber where the logging message was emitted as well as the running time of the application. The next figure shows all information which can be shown in the Logging Module. -\image html LogViewExplain.png "Details on the Vizualized Logging Information" +\imageMacro{LogViewExplain.png,"Details on the Vizualized Logging Information",16.00} */ diff --git a/BlueBerry/Bundles/org.blueberry.ui.qt.objectinspector/documentation/UserManual/blueberryobjectinspector.dox b/BlueBerry/Bundles/org.blueberry.ui.qt.objectinspector/documentation/UserManual/blueberryobjectinspector.dox index 260687c30b..d26c5c1079 100644 --- a/BlueBerry/Bundles/org.blueberry.ui.qt.objectinspector/documentation/UserManual/blueberryobjectinspector.dox +++ b/BlueBerry/Bundles/org.blueberry.ui.qt.objectinspector/documentation/UserManual/blueberryobjectinspector.dox @@ -1,8 +1,8 @@ /** \page org_blueberry_ui_qt_objectinspector The Object Browser -\image html ObjectBrowser.png "Icon of the Module" +\imageMacro{ObjectBrowser.png,"Icon of the Module",2.00} This view is only a debugging tool for berry::Object derived classes. */ \ No newline at end of file diff --git a/CMake/QBundleTemplate/documentation/Manual/Manual.dox b/CMake/QBundleTemplate/documentation/Manual/Manual.dox index abec43a1ef..7b764026fa 100755 --- a/CMake/QBundleTemplate/documentation/Manual/Manual.dox +++ b/CMake/QBundleTemplate/documentation/Manual/Manual.dox @@ -1,13 +1,13 @@ /** \page @PLUGIN_ID@ @PLUGIN_NAME@ -\image html icon.png "Icon of @PLUGIN_NAME@" +\imageMacro{icon.png,"Icon of @PLUGIN_NAME@",2.00} Available sections: - \ref @PLUGIN_ID@Overview \section @PLUGIN_ID@Overview This is the description for the @PLUGIN_NAME@. */ diff --git a/Core/Documentation/Doxygen/Concepts/DataInteraction.dox b/Core/Documentation/Doxygen/Concepts/DataInteraction.dox index d9a4eaa91c..8c2a60803e 100644 --- a/Core/Documentation/Doxygen/Concepts/DataInteraction.dox +++ b/Core/Documentation/Doxygen/Concepts/DataInteraction.dox @@ -1,224 +1,224 @@ /** \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. -\image html event_handling.png +\imageMacro{event_handling.png,"",16}
  1. a user event is triggered and send to MITK
  2. 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).
  3. once the event is adapted it is send to a mitk::Dispatcher, which is linked to a render window, to be handled.
  4. on the mitk::Dispatcher level all objects are known that can react to incoming events (mitk::DataInteractor and mitk::InteractionEventObserver instances)
  5. 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.
  6. 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
  7. 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 ). \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 three components. 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::InteractioinEventHandler 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. */ diff --git a/Core/Documentation/Doxygen/Concepts/DataInteractionTechnical.dox b/Core/Documentation/Doxygen/Concepts/DataInteractionTechnical.dox index 44e4d91895..aaf338b57f 100644 --- a/Core/Documentation/Doxygen/Concepts/DataInteractionTechnical.dox +++ b/Core/Documentation/Doxygen/Concepts/DataInteractionTechnical.dox @@ -1,115 +1,115 @@ /** \page DataInteractionTechnicalPage Interaction Concept Implementation \tableofcontents This page describes some technicalities of the implementation and the workflow, for a detailed list of tutorials see \ref FurtherReadingInteraction . \section DataInteractionTechnicalPage_Introduction Description of Interaction Concept Implementation in MITK \section DataInteractionTechnicalPage_DispatcherSection Dispatcher After an event is received by the mitk::Dispatcher it is given to a mitk::DataInteractor that has to decide if it can process this event. On a high level this is done by the mitk::EventStateMachine. First the state machine asks if the received event is known in the configuration. If it is, the matching variant name is returned. Then the state machine checks if there exists a transition in its current state that is triggered by this event variant. If this is the case all actions that are associated with this transition are queried and executed. The actions themselves are implemented on mitk::DataInteractor level. The following diagram illustrates the process: -\image html sm_and_config.png +\imageMacro{sm_and_config.png,"",16} Each mitk::BaseRenderer creates a mitk::BindDispatcherInteractor object which encapsulates the connection between the mitk::DataStorage and the mitk::Dispatcher, and thereby allowing a mitk::DataInteractor to register with a mitk::Dispatcher when only knowing the mitk::DataNode. mitk::BindDispatcherInteractor creates a new mitk::Dispatcher object and registers for mitk::DataNode events at the mitk::DataStorage, as a callback function the dispatchers AddDataInteractor() and RemoveDataInteractor() functions are set. \dot digraph { node [shape=record, fontname=Helvetica, fontsize=10]; a [ label="{BaseRenderer|m_BindDispatcherInteractor}"]; b [ label="{BindDispatcherInteractor|m_Dispatcher\n m_DataStorage}" ]; c [ label="Dispatcher" ]; d [ label="DataStorage" ]; a -> b; b -> c; b -> d; } \enddot This way the mitk::Dispatcher is notified about all changes regarding DataNodes that are shown in the mitk::BaseRenderer. When a node is added, remove or modified the mitk::Dispatcher can check if a mitk::DataInterator is set, and accordingly add or remove this mitk::DataInteractor from its internal list. \dot digraph { node [shape=record, fontname=Helvetica, fontsize=10]; d [ label="DataInteractor" ]; a [ label="DataNode" ]; b [ label="DataStorage" ]; c [ label="Dispatcher" ]; e [ label="BaseRenderer"] edge [fontname=Helvetica, fontsize=10] d -> a [label="SetDataInteractor(this)"]; a -> b [label="Modified()"]; b -> c [label="NodeModified(dataNode)"]; e -> c [label="HandleEvent(interactionEvent)"]; { rank=same; b c a } { rank=same; e } } \enddot Events that are generated within the scope of the mitk::BaseRenderer are sent to the associated mitk::Dispatcher to be handled. \subsection DataInteractionTechnicalPage_DispatcherEventDistSection Event Distribution A mitk::Dispatcher can operate in different processing modes, which determine how the interactor that receives an event is chosen. These modes are managed and set by the mitk::Dispatcher itself. \section DataInteractionTechnicalPage_StateMachineSection State Machine & Configuration A mitk::EventStateMachine points to a \b state, which in turn references \b transitions (which describe a change from one state to another) and \b actions (indicating which functions are executed when a transition is taken). \dot digraph { node [shape=record, fontname=Helvetica, fontsize=10]; d [ label="{StateMachine|m_CurrentState}" ]; a [ label="{StateMachineState|m_Transitions}" ]; b [ label="{StateMachineTransitions|m_Actions}"]; c [ label="{StateMachineAction}"]; edge [fontname=Helvetica, fontsize=10] d -> a [label="1 : 1"]; a -> b [label="1 : n"]; b -> c [label="1 : n"]; } \enddot */ diff --git a/Core/Documentation/Doxygen/Concepts/GeometryOverview.dox b/Core/Documentation/Doxygen/Concepts/GeometryOverview.dox index 0de56b2e00..d0327a4b4e 100644 --- a/Core/Documentation/Doxygen/Concepts/GeometryOverview.dox +++ b/Core/Documentation/Doxygen/Concepts/GeometryOverview.dox @@ -1,134 +1,134 @@ namespace mitk{ /** \page GeometryOverviewPage Geometry Overview \tableofcontents \section GeometryOverviewPage_Introduction Introduction to Geometries Geometries are used to describe the geometrical properties of data objects in space and time.\n To use the geometry classes in the right way you have to understand the three different coordinate types present in MITK:\n\n -\image html CoordinateTypes.png +\imageMacro{CoordinateTypes.png,"",16}
The different coordinate types\n\n
\n -# World coordinates: - World coordinates are describing the actual spacial position of all MITK objects regarding a global coordinate system, normally specified by the imaging modality - World coordinates are represented by mitk::Point3D objects. - The geometry defines the offset, orientation, and scale of the considered data objects in reference to the world coordinate systems. - World coordinates are always measured in mm - If you are dealing with an image geometry, the origin of an image is pointing to the CENTER of the bottom-left-back voxel.\n - If you are NOT dealing with an image geometry (no defined discrete Voxels), the origin is pointing to the bottom-left-back CORNER - Index coordinates can be converted to world coordinates by calling BaseGeometry::IndexToWorld()\n\n -\image html worldcoordinateSystem.png +\imageMacro{worldcoordinateSystem.png,"",16}
Corner-based coordinates\n\n
-\image html WorldcoordinateSystemCenterBased.png +\imageMacro{WorldcoordinateSystemCenterBased.png,"",16}
Center-based image-coordinates\n\n
\n -# Continuous index coordinates: - Dividing world coordinates through the pixel spacing and simultanously taking the offset into account leads to continuous index coordinates inside your dataobject.\n So continuous coordinates can be float values! - Continuous index coordinates are represented by mitk::Point3D objects. - They can be obtained by calling BaseGeometry::WorldToIndex(), where &pt_mm is a point in worldcoordinates.\n -# Index coordinate system: - Index coordinates are discrete values that address voxels of a data object explicitly. - Index coordinates are represented by mitk::Index3D objects. - Basically they are continuous index coordinates which are rounded from half integer up. - E.g. (0,0) specifies the very first pixel of a 2D image, (0,1) the pixel of the next column in the same row - If you have world coordinates, they can be converted to discrete index coordinates by calling BaseGeometry::WorldToIndex()\n\n \section GeometryOverviewPage_PointsAndVector Difference between Points and Vectors Like ITK, MITK differenciate between points and vectors. A point defines a position in a coordinate system while a vector is the distance between two points. Therefore points and vectors behave different if a coordinate transformation is applied. An offest in a coordinate transformation will affect a transformed point but not a vector. An Example:\n If two systems are given, which differ by a offset of (1,0,0). The point A(2,2,2) in system one will correspont to point A'(3,2,2) in the second system. But a vector a(2,2,2) will correspond to the vector a'(2,2,2). \section GeometryOverviewPage_Concept The Geometry Concept As the superclass of all MITK geometries BaseGeometry holds: - a spacial bounding box which is axes-parallel in index coordinates (often discrete indices of pixels), to be accessed by BaseGeometry::GetBoundingBox() - a time related bounding box which holds the temporal validity of the considered data object in milliseconds (start and end time), to be accessed by BaseGeometry::GetTimeBounds().\n The default for 3D geometries is minus infinity to plus infinity, meaning the object is always displayed independent of displayed time in MITK. - position information in form of a Euclidean transform in respect to world coordinates (i.e. a linear transformation matrix and offset) to convert (discrete or continuous) index coordinates to world coordinates and vice versa,\n to be accessed by BaseGeometry::GetIndexToWorldTransform()\n See also: \ref GeometryOverviewPage_Introduction "Introduction to Geometries" - Many other properties (e.g. origin, extent, ...) which can be found in the \ref BaseGeometry "class documentation" - VERY IMPORTANT:\n A flag called isImageGeometry, which indicates whether the coordinates are center-based or not!\n See also: \ref GeometryOverviewPage_Introduction "Introduction to Geometries" and \ref GeometryOverviewPage_Putting_Together "IMPORTANT: Putting it together for an Image"\n\n Every data object (sub-)class of BaseData has a TimeGeometry which is accessed by BaseData::GetTimeGeometry(). This TimeGeometry holds one or more BaseGeometry objects which describes the object at specific time points, e.g. provides conversion between world and index coordinates and contains bounding boxes covering the area in which the data are placed. There is the possibility of using different implementations of the abstract TimeGeometry class which may differ in how the time steps are saved and the times are calculated. There are two ways to represent a time, either by a TimePointType or a TimeStepType. The first is similar to the continous index coordinates and defines a Time Point in milliseconds from timepoint zero. The second type is similar to index coordinates. These are discrete values which specify the number of the current time step going from 0 to GetNumberOfTimeSteps(). The conversion between a time point and a time step is done by calling the method TimeGeometry::TimeStepToTimePoint() or TimeGeometry::TimePointToTimeStep(). Note that the duration of a time step may differ from object to object, so in general it is better to calculate the corresponding time steps by using time points. Also the distance of the time steps does not need to be equidistant over time, it depends on the used TimeGeometry implementation. Each TimeGeometry has a bounding box covering the whole area in which the corresponding object is situated during all time steps. This bounding box may be accessed by calling TimeGeometry::GetBoundingBoxInWorld() and is always in world coordinates. The bounding box is calculated from all time steps, to manually start this calculation process call TimeGeometry::Update(). The bounding box is not updated if the getter is called. The TimeGeometry does not provide a transformation of world coordinates into image coordinates since each time step may has a different transformation. If a conversion between image and world is needed, the BaseGeometry for a specific time step or time point must be fetched either by TimeGeometry::GetGeometryForTimeStep() or TimeGeometry::GetGeometryForTimePoint() and then the conversion is calculated by using this geometry. The TimeGeometry class is an abstract class therefore it is not possible to instantiate it. Instead a derived class must be used. Currently the only class that can be chosen is ProportionalTimeGeometry() which assumes that the time steps are ordered equidistant. To initialize an object with given geometries call ProportionalTimeGeometry::Initialize() with an existing BaseGeometry and the number of time steps. The given geometries will be copied and not referenced! Also, the BaseGeometry is an abstract class and derived classes must be used. The most simple implementation, i.e. the one to one implementation of the BaseGeometry class, is the class Geometry3D. SlicedGeometry3D is a sub-class of BaseGeometry, which describes data objects consisting of slices, e.g., objects of type Image (or SlicedData, which is the super-class of Image). Therefore, Image::GetTimeGeometry() will contain a list of SlicedGeometry3D instances. There is a special method SlicedData::GetSlicedGeometry(t) which directly returns\n a SlicedGeometry3D to avoid the need of casting. The class SlicedGeometry3D contains a list of PlaneGeometry objects describing the slices in the image.We have here spatial steps from 0 to GetSlices(). SlicedGeometry3D::InitializeEvenlySpaced (PlaneGeometry *planeGeometry, unsigned int slices) initializes a stack of slices with the same thickness, one starting at the position where the previous one ends. PlaneGeometry provides methods for working with 2D manifolds (i.e., simply spoken, an object that can be described using a 2D coordinate-system) in 3D space.\n For example it allows mapping of a 3D point on the 2D manifold using PlaneGeometry::Map(). \n An important subclass of PlaneGeometry is the DisplayGeometry which describes the geometry of the display (the monitor screen). Basically it represents a rectangular view on a 2D world geometry.\n The DisplayGeometry converts between screen and world coordinates, processes input events (e.g. mouse click) and provides methods for zooming and panning.\n -\image html DisplayGeometry.png +\imageMacro{DisplayGeometry.png,"",16}
Display Geometry\n\n
Finally there is the AbstractTransformGeometry which describes a 2D manifold in 3D space, defined by a vtkAbstractTransform. It is a abstract superclass for arbitrary user defined geometries.\n An example is the ThinPlateSplineCurvedGeometry.\n \subsection GeometryOverviewPage_Putting_Together IMPORTANT: Putting it together for an Image Please read this section accurately if you are working with Images! The definition of the position of the corners of an image is different than the one of other data objects: As mentioned in the previous section, world coordinates of data objects (e.g. surfaces ) usually specify the bottom left back corner of an object. In contrast to that a geometry of an Image is center-based, which means that the world coordinates of a voxel belonging to an image points to the center of that voxel. E.g: -\image html PixelCenterBased.png +\imageMacro{PixelCenterBased.png,"",16}
Center-based voxel\n\n
If the origin of e.g. a surface lies at (15,10,0) in world coordinates, the origin`s world coordinates for an image are internally calculated like the following:
(15-0.5*X-Spacing\n 10-0.5*Y-Spacing\n 0-0.5*Z-Spacing)\n
If the image`s spacing is (x,y,z)=(1,1,3) then the corner coordinates are (14.5,9.5,-1.5). If your geometry describes an image, the member variable isImageGeometry must be changed to true. This variable indicates also if your geometry is center-based or not.\n The change can be done in two ways:\n -# You are sure that your origin is already center-based. Whether because you adjusted it manually or you copied it from another image.\n In that case, you can call the function setImageGeometry(true) or imageGeometryOn() to set the bool variable to true. -# You created a new geometry, did not manually adjust the origin to be center-based and have the bool value isImageGeometry set to false (default).\n In that case, call the function ChangeImageGeometryConsideringOriginOffset(true). It will adjust your origin automatically and set the bool flag to true.\n If you experience displaced contours, figures or other stuff, it is an indicator that you have not considered the origin offset mentioned above.\n\n An image has a TimeGeometry, which contains one or more SlicedGeometry3D instances (one for each time step), all of which contain one or more instances of (sub-classes of) PlaneGeometry.\n As a reminder: Geometry instances referring to images need a slightly different definition of corners, see BaseGeometry::SetImageGeometry. This is usualy automatically called by Image.\n\n \section GeometryOverviewPage_Connection Connection between MITK, ITK and VTK Geometries -\image html ITK_VTK_MITK_Geometries.png +\imageMacro{ITK_VTK_MITK_Geometries.png,"",16} \n\n - VTK transformation for rendering - ITK transformation for calculations - Both automatically updated when one is changed\n Attention:Not automatically updated when changed hardcoded. Example: geometry->GetVtkMatrix()->Rotate(....) */ } diff --git a/Core/Documentation/Doxygen/Concepts/Interaction.dox b/Core/Documentation/Doxygen/Concepts/Interaction.dox index 4c5cb5b923..1aff8413b9 100644 --- a/Core/Documentation/Doxygen/Concepts/Interaction.dox +++ b/Core/Documentation/Doxygen/Concepts/Interaction.dox @@ -1,127 +1,127 @@ /** \deprecated \page InteractionPage Interaction and Undo/Redo Concepts \note The following page refers to the deprecated interaction frame work. Please refer to \ref DataInteractionPage for information about the current one. \tableofcontents \section InteractionPage_Introduction Interaction in MITK \b Interaction is one of the most important tasks in clinically useful image processing software. Due to that, MITK has a special interaction concept, with which the developer can map the desired interaction. For a simple change in interaction he doesn't have to change the code. All information about the sequence of the interaction is stored in an XML-file that is loaded by the application during startup procedure at runtime. That even allows the storage of different interaction patterns, e.g. an interaction behaviour like in MS PowerPoint, in Adobe Photoshop or like the interaction behaviour on a medical image retrieval system. \section InteractionPage_Statemachines_Implementation Statemachines to implement Interaction The interaction in MITK is implemented with the concept of state machines (by Mealy). This concept allows to build the steps of interaction with different states, which each have different conditions, very alike the different interactions that may have to be build to develop medical imaging applications. Furthermore state machines can be implemented using object oriented programming (OOP). Due to that we can abstract from the section of code, that implements the interaction and focus on the sequence of interaction. What steps must the user do first before the program can compute a result? For example he has to declare three points in space first and these points are the input of a filter so only after the definition of the points, the filter can produce a result. The according interaction sequence will inform the filter after the third point is set and not before that. Now the filter after an adaption only needs two points as an input. The sequence of the interaction can be easily changed if it is build up as a sequence of objects and not hard implemented in a e.g. switch/case block. Or the user wants to add a point in the scene with the right mouse button instead of the left. Wouldn't it be nice to only change the definition of an interaction sequence rather than having to search through the code and changing every single if/else condition? \subsection InteractionPage_Statemachine State Machine So a separation of the definition of a sequence in interaction and its implementation is a useful step in the development of an interactive application. To be able to do that, we implemented the concept of state machines with several classes: States, Transitions and Actions define the interaction pattern. The state machine itself adds the handling of events, that are sent to it. -\image html statemachine.jpg +\imageMacro{statemachine.jpg,"",16} \subsubsection InteractionPage_ExampleA Example A: A deterministic Mealy state machine has always one current state (here state 1). If an event 1 is sent to the state machine, it searches in its current state for a transition that waits for event 1 (here transition 1). The state machine finds transition 1, changes the current state to state2, as the transition points to it and executes actions 1 and 2. Now state 2 is the current state. The state machine receives an event 2 and searches for an according transition. Transition 2 waits for event 2, and since the transition leads to state 2 the current state is not changed. Action 3 and 4 are executed. Now Event 3 gets send to the state machine but the state machine can't find an according transition in state 2. Only transition 2 , that waits for event 2 and transition 4, that waits for event 4 are defined in that state. So the state machine ignores the event and doesn't change the state or execute an action. Now the state machine receives an event 4 and finds transition 3. So now the current state changes from state 2 to state 1 and actions 5 and 1 are executed. Several actions can be defined in one transition. The execution of an action is the active part of the state machine. Here is where the state machine can make changes in data, e.g. add a Point into a list. See mitk::StateMachine, mitk::State, mitk::Event, mitk::Action, mitk::Transition, mitk::Interactor \subsection InteractionPage_GuardState Guard States Guard States are a special kind of states. The action, that is executed after the state is set as current state, sends a new event to the state machine, which leads out of the guard state. So the state machine will only stay in a guard state for a short time. This kind of state is used to check different conditions, e.g. if an Object is picked or whether a set of points will be full after the addition of one point. -\image html statemachine_guard.jpg +\imageMacro{statemachine_guard.jpg,"",16} \subsubsection InteractionPage_ExampleB Example B: Event 1 is sent to the state machine. This leads the current state from state 1 into state check. The action 1 is executed. This action checks a condition and puts the result into a new event, that is sent and handled by the same (this) state machine. E.g. is the object picked with the received mouse-coordinate? The event, that is generated, will be Yes or No. In case of event No, the state machine sets the current state back to state 1 and executes action 2. In case of event Yes, the state machine changes the state from state check into state 2 and executes action 3, which e.g. can select said object. \subsection InteractionPage_XMLDefinitionStatemachine Definition of a State machine Due to the separation of the definition of an interaction sequence and its implementation, the definition has to be archived somewhere, where the application can reach it during startup and build up all the objects (states, transitions and actions) that represent the sequence of a special interaction. In MITK, these informations are defined in an XML-file (usually in Core/Code/Resources/Interactions/Legacy/StateMachine.xml) \note Please note that since this is a resource which is compiled into the executable, changes you make to this file will only be reflected in application behavior after you recompile your code. The structure is the following (from \ref InteractionPage_ExampleA) : \code \endcode The identification numbers (ID) inside a state machine have to be unique. Each state machine has to have one state, that is defined as the start-state of that state machine. This means, initially, the current state of the state machine is the start-state. The Event-Ids seen above are also defined in the statemachine.xml file. They specify a unique number for a combination of input-conditions (key, mouse and so on). See \ref InteractionPage_InteractionEvents for further informations. The statemachine is compiled into an application at compile time. The definition of one single state machine is called the \a statemachine-pattern. Since this pattern is build up during startup with objects (states, transitions and actions) and these objects only hold information about what interaction may be done at the current state, we can also reuse the pattern. \note You as a developer don't necessarily have to implement your own XML-File! We already have defined some interaction-patterns (e.g. for setting Points in 2D or 3D) which you can use and adapt. \subsubsection InteractionPage_ReusePattern Reuse of Interaction Patterns If we for example have a pattern called "pointset", which defines how the user can set different points into the scene and there is an instance of a state machine called "PointSetInteractor". This state machine has a pointer pointing to the current state in its assigned state machine pattern. Several events are send to the state machine, which moves the pointer from one state to the next, according to the transitions, and executes the actions, referenced in the transitions. But now a new instance of the class "PointSetInteractor" has to be build. So we reuse the pattern and let the current state pointer of the new object point to the start state of the pattern "pointset". The implementation of the actions is \b not done inside a class of the pattern (\a state, \a transition, \a action), it is done inside a state machine class (see the reference for mitkStatemachine). \subsection InteractionPage_InteractionEvents Events During runtime, events are thrown from e.g. the mouse to the operating system, are then send to your graphical user interface and from there it has to be send to the MITK-object called \a mitkEventMapper. This class maps the events received with an internal list of all events that can be understood in MITK. The definition of all understandable events is also located in the XML-File the state machines are defined in. If the received event can be found in the list, an internal mitk-eventnumber is added to the event and send to the object \a mitkGlobalInteraction. See mitk::Event, mitk::GlobalInteraction \subsection InteractionPage_GlobalInteraction GlobalInteraction This object administers the transmission of events to registered state machines. There can be two kinds of state machines, the ones that are only listening and ones that also change data. Listening state machines are here called Listeners and state machines that also change data are called Interactors. \note The discrimination between \a Listener and \a Interactor is only made in mitkGlobalInteraction. As Listener an object derived from class StateMachine can be added and removed from GlobalInteraction and as Interactor an object derived from class Interactor can be added and removed. See the interaction class diagram for further information. To add or remove a state machine to the list of registered interactors, call \a AddInteractor or \a RemoveInteractor of \a GlobalInteraction or to add or remove a listener call \a AddListener of \a RemoveListener. Listeners are always provided with the events. Interactors shall only be provided with an event, if they can handle the event. Because of that the method CanHandleEvent is called, which is implemented in each Interactor. This method analyses the event and returns a value between 0 (can't handle event) and 1 (Best choice to handle the event). Information, that can help to calculate this jurisdiction can be the bounding box of the interacted data and the picked mouse-position stored in the event. So after the object \a GlobalInteraction has received an event, it sends this event to all registered Listeners and then asks all registered Interactors through the method \a CanHandleEvent how good each Interactor can handle this event. The Interactor which can handle the event the best receives the event. Also see the documented code in \a mitkGlobalInteraction. To not ask all registered interactors on a new event, the class \a Interactor also has a mode, which can be one of the following: deselected, subselected (deprecated since HierarchicalInteraction has been removed), selected. These modes are also used for the event mechanism. If an interactor is in a state, where the user builds up a graphical object, it is likely that the following events are also for the build of the object. Here the interactor is in mode selected as long as the interactor couldn't handle an event. Then it changes to mode deselected. The mode changes are done in the actions through operations (described further down) and so declared inside the interaction pattern. See mitk::GlobalInteraction \subsection InteractionPage_Interactors Interactors The class \a Interactor is the superclass for all state machines, that solve the interaction for a single data-object. An example is the class \a mitkPointSetInteractor which handles the interaction of the data \a mitkPointSet. Inside the class \a mitkPointSetInteractor all actions, defined in the interaction-pattern "pointsetinteractor", are implemented. Inside the implementation of these actions (\a ExecuteAction(...) ), so called \a mitkOperations are created, filled with information and send to the \a mitkUndoController and to \a mitkOperactionActor (the data, the interaction is handled for). See mitk::Interactor \subsection InteractionPage_ExecOperations Executing Operations The class mitkOperation and its subclasses basically holds all information needed to execute a certain change of data. This change of data is only done inside the data-class itself, which is derived from the interface \a mitkOperationActor. Interactors handle the interaction through state-differentiation and combine all informations about the change in a \a mitkOperation and send this operation-object to the method ExecuteOperation (of data-class). Here the necessary data is extracted and then the change of data is performed. When the operation-object, here called do-operation, is created inside the method \a ExecuteAction (in class \a mitkInteractor), an undo-operation is also created and together with the do-operation stored in an object called \a OperationEvent. After the Interactor has sent the do-operation to the data, the operation-event-object then is sent to the instance of class \a mitkUndoController, which administrates the undo-mechanism. See mitk::Operation, mitk::OperationActor \subsection InteractionPage_UndoController UndoController The instance of class \a mitkUndoController administrates different Undo-Models. Currently implemented is a limited linear Undo. Only one Undo-Model can be activated at a time. The UndoController sends the received operation events further to the current Undo-Model, which then stores it according to the model. If the method \a Undo() of UndoController is called (e.g. Undo-Button pressed from ) the call is send to the current Undo-Model. Here the undo-operation from the last operation event in list is taken and send to the data, referenced in a pointer which is also stored in the operation-event. A call of the method \a Redo() is handled accordingly. See mitk::UndoController, mitk::LimitedLinearUndo \subsection InteractionPage_references References [Bin99] Robert V. Binder. Testing Object-Oriented Systems: Models, Patterns, and Tools. Addison-Wesley, 1999 */ diff --git a/Core/Documentation/Doxygen/Concepts/MitkImage.dox b/Core/Documentation/Doxygen/Concepts/MitkImage.dox index 82686e179f..e50f1c58ff 100644 --- a/Core/Documentation/Doxygen/Concepts/MitkImage.dox +++ b/Core/Documentation/Doxygen/Concepts/MitkImage.dox @@ -1,152 +1,152 @@ /** \page MitkImagePage MITK Image \tableofcontents \section MitkImagePage_Introduction Introduction to MITK Image The MITK Image obviously is a very central class to MITK and one of those you are most likely to work with. This section will get you up and running with the basics. Consider this document a prerequisite for the Pipelining Introduction and the \ref GeometryOverviewPage. -\image html mitkimagehierarchy.png +\imageMacro{mitkimagehierarchy.png,"",16} Image is a direct descendant of SlicedData which itself inherits from BaseData. In MITK, BaseData is the common DataType from which all other Datatypes stem. SlicedData specifies this class to contain image slices, a typical example being a CT scan, and introduces properties and methods necessary to give the data a well defined geometry. Image further specializes the concept to allow for multiple channels, volumes and slices as well as additional information like image properties. For the sake of this introduction, we will have a look at three different aspects: 1. SlicedData and Geometry 2. ImageData 3. Image Properties \subsection MitkImagePage_SlicedData SlicedData and Geometry The mother class of Image introduces a fundamental aspect: Image geometry. It defines the image's spatial context: Dimension and orientation. A more in depth introduction is given here: \ref GeometryOverviewPage \subsection MitkImagePage_ImageData ImageData Objects of the class Image store the actual image data. It is important to discern four different concepts: 1. Channels, which can be of a specific data type e.g. an intensity image or a vector field. Each channel consists of one or more... 2. Volumes, which contain data of a certain type. A volume is represented by ImageDataItems that define volume properties. Inside of a channel, each volume must be of the same type (float, int, etc.). Each volume consists of several... 3. Slices, which each contain a two-dimensional image slice. There is also the pointer m_CompleteData that references all of the data (i.e. all volumes) as a singular array. This member is helpful, when one wants to copy image data from one image to another. -\image html mitkimagememory.png +\imageMacro{mitkimagememory.png,"",16} \subsection MitkImagePage_Properties Image Properties Lastly, we'll talk about properties. Properties are a set of additional information mainly used to save DICOM information. The functionality is introduced very early in the image's lineage, in BaseData. The system works quite similar to a hashmap by using property keys and properties. For further reference, see BaseData::GetProperty() or, for a simple example implementation, USImage::GetMetadata(). \section MitkImagePage_AccessImageData Access image data Since many modules and plugins in MITK work with the same images, it can be difficult to comprehend and control all ongoing image accesses. Thus, we decided to introduce the concept of image accessors. They are responsible for organisation of image access and for keeping data consistent. Every Image manages its image accessors and thus is responsible for them. In the following subsections, image accessors are explained and their use is depicted. Code examples are added to make understanding easier. \subsection MitkImagePage_ImageAccessors Image accessors Image accessors provide an image access, which is -# controlled and surveilled: at all time it is known how many instances have access to a specific image part. -# consistent and thread-safe: a lock-mechanism allows a concurrent read access on image parts and guarantees a consistent data state during access. -# restricted to an image part: it is possible to restrict access to a specific image part (e.g. volume or slice), which is represented in an ImageDataItem. -# simple and comfortable through pixel index: get- and set-methods are provided to access pixel values easily (see next section). The existing instantiable image accessor classes are: mitk::ImageReadAccessor, mitk::ImageWriteAccessor and mitk::ImageVtkAccessor. They all inherit from mitk::ImageAccessorBase, which mainly contains the lock functionality and a representation of the specified image area. The classes mitk::ImageReadAccessor and mitk::ImageWriteAccessor provide access to an mitk::Image or mitk::ImageDataItem and supply a (const) void* pointer, while mitk::ImageVtkAccessor supports Vtk image access in a legacy mode (you should not instantiate it). -\image html mitkimageaccessorhierarchy.png +\imageMacro{mitkimageaccessorhierarchy.png,"",16} \subsection MitkImagePage_HowToGetAccess How to get access Although the concept of image accessors is extensive, the use of image accessors is simple. Requesting an image access consists only of creating an instance of an image accessor. The constructor of an image accessor requires a pointer to the mitk::Image class and optionally an image part (e.g. mitk::ImageDataItem), which restricts the access of an image accessor to a specific image sector (e.g. Volume, Slice). Since the constructor can throw a mitk::Exception, it is necessary to order an image accessor within a try block. Possible exceptions are invalid images, wrong dimensions, etc. which cannot be accepted. If only a pointer to image data is needed, following code example shows how to get a const or non-const pointer. mitk::ImageReadAccessor only provides a const void* pointer while mitk::ImageWriteAccessor provides a void* pointer to image data. \verbatim // we assume you already have an mitk::Image::Pointer image try { mitk::ImageReadAccessor readAccess(image, image->GetVolumeData(0)); const void* cPointer = readAccess.GetData(); mitk::ImageWriteAccessor writeAccess(image); void* vPointer = writeAccess.GetData(); } catch(mitk::Exception& e) { // deal with the situation not to have access } \endverbatim A more convenient way to access image data is provided by the classes mitk::ImagePixelReadAccessor and mitk::ImagePixelWriteAccessor. They are equipped with set- and get-methods, which allow an index-based access. Both classes are templated and need to know about pixel type and image dimension at compile time. That means, both parameters need to be defined with arrow brackets when calling the constructor. \verbatim // we assume you already have an mitk::Image::Pointer image try { itk::Index<2> idx = {{ 12, 34 }}; mitk::ImagePixelReadAccessor readAccess(image, image->GetSliceData(2)); short value = readAccess.GetPixelByIndex(idx); mitk::ImagePixelWriteAccessor writeAccess(image, image->GetSliceData(4)); writeAccess.SetPixelByIndex(idx, 42); } catch(mitk::Exception& e) { // deal with the situation not to have access } \endverbatim \subsection MitkImagePage_AdditionalProperties Additional properties It is possible to commit options to the constructor affecting the behavior of an image accessor. Properties have to be specified using enum flags (e.g. mitk::ImageAccessorBase::ExceptionIfLocked) and can be unified by bitwise operations. The flag ExceptionIfLocked causes an exception if the requested image part is locked. Usually the requesting image accessor waits for the locking image accessor. \verbatim try { mitk::ImageReadAccessor imageAccess(image, image->GetSliceData(2), mitk::ImageAccessorBase::ExceptionIfLocked); const void* pointer = imageAccess.GetData(); } catch(mitk::MemoryIsLockedException& e) { // do something else } catch(mitk::Exception& e) { // deal with the situation not to have access } \endverbatim \section MitkImagePage_WorkingWith Working with MITK Image \subsection MitkImagePage_Cloning Cloning a MITK Image In order to clone an image, you can simply call the inherited method Clone(). It returns an itk::SmartPointer and works also with const image pointers. \verbatim mitk::Image::Pointer testMethod(const mitk::Image* image) { mitk::Image::Pointer nIm = image->Clone(); return nIm; } \endverbatim Cloning can also be done manually by copying the Geometry, the visual Data and further properties separately. The simplest way to achieve this is to first call Image::Initialize(const Image * image). This will copy the geometry information, but not the data or the properties. Afterwards, copy the image's data (e.g. with SetVolume) and, if necessary, it's properties with SetPropertyList(image->GetPropertyList()). \subsection MitkImagePage_Inheriting Inheriting from MITK Image In general, one should try to avoid inheriting from mitk Image. The simple reason for this is that your derived class will not cleanly work together with the Filters already implemented (See the chapter on Pipelining for Details). If however, mitk Image does not offer the functionality you require it is possible to do so. See the documentation for various examples of classes that inherit from image. */ diff --git a/Core/Documentation/Doxygen/Concepts/Pipelining.dox b/Core/Documentation/Doxygen/Concepts/Pipelining.dox index 8932fe4e1f..1065667ae3 100644 --- a/Core/Documentation/Doxygen/Concepts/Pipelining.dox +++ b/Core/Documentation/Doxygen/Concepts/Pipelining.dox @@ -1,85 +1,85 @@ /** \page PipelineingConceptPage Pipelining Concept \tableofcontents \section PipelineingConceptPage_Introduction Introduction to Pipelining Image processing in MITK draws heavily from the pipelining concept, and a clear understaning of it is crucial when developing with MITK. This document will first clarify the general idea behind pipelining and then discuss some MITK specifics that you should know about. In the real world, a pipeline connects a source of some kind with a consumer of another. So we identify three key concepts: 1. The source, which generates data of some kind. 2. The pipeline, which transports the data. Many different pipeline segments can be switched in line to achieve this. 3. The consumer, which uses the data to do something of interest. The analogy to real pipelines falls a little short in one point: A physical pipeline would never process it's contents, while in software development a pipeline usually does (this is why they are often dubbed filters as well). One might ask why one shouldn't just implement the processing logic in the consumer onject itself, since it onviously knows best what to do with it's data. The two main reasons for this are reusability and flexibility. Say, one wants to display a bone segmentation from a CT-image. Let's also assume for the sake of this introduction, that this is a simple task. One could build a monolithic class that solves the problem. Or one builds a pipeline between the displaying class and the source. We know that bones are very bright in a CT Scan, so we use a treshold filter, and then a segmentation Filter to solve the problem. -\image html pipelining_example_ct.png +\imageMacro{pipelining_example_ct.png,"",16} Now let's further assume that after successfully selling this new technology to a large firm, we plan to do the same with ultrasound imaging technology. The brithness relations in Ultrasound images are basically the same, but ultrasound images are very noisy, and the contrast is significantly lower. Since we used pipelining, this is no problem: We don't need to change our old segmentation class - we just plug two new filters in front of the pipeline: -\image html pipelining_example_us.png +\imageMacro{pipelining_example_us.png,"",16} This may seem trivial, but when working with several input streams from many different devices that themselves stem from many different vendors, pipelining can save the day when it comes to broad range support of different specifications. \section PipelineingConceptPage_InMITK Pipelining in MITK \subsection PipelineingConceptPage_Update The Update() Mechanism The flow of data inside a pipeline is triggered by only one function call to the consumer, which is Update(). Each part of the pipeline then triggers the Update() method of it's antecessor. Finally, the source creates a new batch of data using it's own GenerateData() method, and notifies its successor that new data is available. The pipeline can then start to process the data until the finished data batch is available as an output of the last Filter. -\image html pipelining_update.png +\imageMacro{pipelining_update.png,"",16} \subsection PipelineingConceptPage_Hierarchy The Pipeline Hierarchy Tha base class for all parts of the pipeline except the consumer (which can be of any class) is mitk::Baseprocess. This class introduces the ability to process data, has an output and may have an input as well. You will however rarly work with this class directly. -\image html pipelining_hierarchy.png +\imageMacro{pipelining_hierarchy.png,"",16} Several source classes extend BaseProcess. Depending on the type of data they deliver, these are ImageSource, PointSetSource and SurfaceSource. All of these mark the start of a pipeline. The filters themselves extend one of the source classes. This may not immediately make sense, but remember that a filter basically is a source with an additional input. \section PipelineingConceptPage_WorkWith Working with Filter \subsection PipelineingConceptPage_Setup Setting Up a Pipeline \verbatim // Create Participants mitk::USVideoDevice::Pointer videoDevice = mitk::USVideoDevice::New("-1", "Manufacturer", "Model"); TestUSFilter::Pointer filter = TestUSFilter::New(); // Make Videodevice produce it's first set of Data, so it's output isn't empty videoDevice->Update(); // attacht filter input to device output filter->SetInput(videoDevice->GetOutput()); // Pipeline is now functional filter->Update(); \endverbatim \subsection PipelineingConceptPage_Implement Writing Your Own Filter When writing your first Filter, this is the recommended way to go about: - Identify which kinds of Data you require for input, and which for output - According to the information from step one, extend the most specific subclass of BaseProcess available. E.g. a filter that processes images, should extend ImageToImageFilter. - Identify how many inputs and how many outputs you require. - In the constructor, define the number of outputs, and create an output. \verbatim //set number of outputs this->SetNumberOfOutputs(1); //create a new output mitk::Image::Pointer newOutput = mitk::Image::New(); this->SetNthOutput(0, newOutput); \endverbatim - Implement MakeOutput(). This Method creats a new, clean Output that can be written to. Refer to Filters with similiar task for this. - Implement GenerateData(). This Method will generate the output based on the input it. At time of execution you can assume that the Data in input is a new set. */ \ No newline at end of file diff --git a/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox b/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox index 58e79f043d..3ab3a8c7f5 100644 --- a/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox +++ b/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox @@ -1,127 +1,127 @@ /** \page QVTKRendering Rendering Concept \tableofcontents The MITK rendering pipeline is derived from the VTK rendering pipeline. \section QVTKRendering_Pipeline_VTK VTK Rendering Pipeline -\image html RenderingOverviewVTK.png "Rendering in VTK" +\imageMacro{RenderingOverviewVTK.png,"Rendering in VTK",16} 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. \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: -\image html qVtkRenderingClassOverview.png "Rendering in MITK" +\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: -\image html qVtkRenderingSequenceVTK.png "Sequence diagram for MITK VTK rendering" +\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. -\image html qVtkRenderingSequenceGL.png "Sequence diagram for MITK OpenGL rendering" +\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: -\image html qVtkRenderingMapper.jpg "Mapper architecture" +\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: this->GetRenderWindowPart()->GetRenderingManager()->RequestUpdateAll(); \li A single QmitkRenderWindow update request can be done like this: this->GetRenderWindowPart()->GetRenderingManager()->RequestUpdate(this->GetRenderWindowPart()->GetRenderWindow("axial")->GetVtkRenderWindow()); \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/Core/Documentation/Doxygen/Groups/ModuleGeometry.dox b/Core/Documentation/Doxygen/Groups/ModuleGeometry.dox index e916e59570..2a5bc8dee3 100644 --- a/Core/Documentation/Doxygen/Groups/ModuleGeometry.dox +++ b/Core/Documentation/Doxygen/Groups/ModuleGeometry.dox @@ -1,46 +1,46 @@ namespace mitk { /** \defgroup Geometry Geometry Classes \ingroup Core \brief This subcategory includes the geometry classes, which describe the geometry of the data in space and time. The Geometry3D class holds (see figure) \li a bounding box which is axes-parallel in intrinsic coordinates (often integer indices of pixels), to be accessed by Geometry3D::GetBoundingBox() \li a transform to convert intrinsic coordinates into a world-coordinate system with coordinates in millimeters and milliseconds (floating point values), to be accessed by Geometry3D::GetIndexToWorldTransform() \li a life span, i.e. a bounding box in time in ms (with start and end time), to be accessed by Geometry3D::GetTimeBounds(). The default is minus infinity to plus infinity. -\image html ModuleGeometryFig1.png "Geometry: Bounding box and transform" +\imageMacro{ModuleGeometryFig1.png,"Geometry: Bounding box and transform",14.82} Geometry3D and its sub-classes allow converting between intrinsic coordinates (called index or unit coordinates) and word-coordinates (called world or mm coordinates), e.g. Geometry3D::WorldToIndex. Every data object (sub-)class of BaseData has a TimeGeometry which is accessed by BaseData::GetTimeGeometry(). This TimeGeometry holds one or more Geometry3D objects which describes the object at specific time points, e.g. provides conversion between world and index coordinates and contains bounding boxes covering the area in which the data are placed. There is the possibility of using different implementations of the abstract TimeGeometry class which may differ in how the time steps are saved and the times are calculated. There are two ways to represent a time, either by a TimePointType or a TimeStepType. The first is similar to the continous index coordinates and defines a Time Point in milliseconds from timepoint zero. The second type is similar to index coordinates. These are discrete values which specify the number of the current time step going from 0 to GetNumberOfTimeSteps(). The conversion between a time point and a time step is done by calling the method TimeGeometry::TimeStepToTimePoint() or TimeGeometry::TimePointToTimeStep(). Note that the duration of a time step may differ from object to object, so in general it is better to calculate the corresponding time steps by using time points. Also the distance of the time steps does not need to be equidistant over time, it depends on the used TimeGeometry implementation. Each TimeGeometry has a bounding box covering the whole area in which the corresponding object is situated during all time steps. This bounding box may be accessed by calling TimeGeometry::GetBoundingBoxInWorld() and is always in world coordinates. The bounding box is calculated from all time steps, to manually start this calculation process call TimeGeometry::Update(). The bounding box is not updated if the getter is called. The TimeGeometry does not provide a transformation of world coordinates into image coordinates since each time step may has a different transformation. If a conversion between image and world is needed, the Geometry3D for a specific time step or time point must be fetched either by TimeGeometry::GetGeometryForTimeStep() or TimeGeometry::GetGeometryForTimePoint() and then the conversion is calculated by using this geometry. The TimeGeometry class is an abstract class therefore it is not possible to instantiate it. instead a derived class must be used. Currently the only class that can be chosen is ProportionalTimeGeometry() which assumes that the time steps are ordered equidistant. To initialize an object with given geometries call ProportionalTimeGeometry::Initialize() with an existing Geometry3D and the number of time steps. The given geometries will be copied and not referenced! For each time step of a given object a geometry-object needs to be specified. This are Geometry3D objects of objects of classes which are derived from Geometry3D. For example, images uses the sub-class SlicedGeometry, which contains several Geometry2D objects. Geometry instances referring to images need a slightly different definition of corners, see Geometry3D::SetImageGeometry. This is usualy automatically called by Image. The class SlicedGeometry3D contains a list of Geometry2D objects describing the slices in the data object. It has spatial steps from 0 to GetSlices(). SlicedGeometry3D::InitializeEvenlySpaced (Geometry2D *geometry2D, unsigned int slices) initializes a stack of slices with the same thickness, one starting at the position where the previous one ends. Geometry2D provides methods for working with 2D manifolds (i.e., simply spoken, an object that can be described using a 2D coordinate-system) in 3D space. For example it allows mapping a 3D point on the 2D manifold using Geometry2D::Map. The most important sub-class is PlaneGeometry2D, which describes a planar rectangle. \section ExampleForImage Putting it together for Image Image has a TimeGeometry, which contains one or more SlicedGeometry3D instances (one for each time step), all of which contain one or more instances of (sub-classes of) Geometry2D (usually PlaneGeometry2D). \deprecated For ITK rev. 3.8 and earlier: Converting coordinates from the ITK physical coordinate system (which did not support rotated images for ITK v3.8 and earlier) to the MITK world coordinate system should be performed via the Geometry3D of the Image, see Geometry3D::WorldToItkPhysicalPoint. As a reminder: Geometry instances referring to images need a slightly different definition of corners, see Geometry3D::SetImageGeometry. This is usualy automatically called by Image. */ //\f$-\infty\f$ to \f$+\infty\f$. } diff --git a/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExamples.dox b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExamples.dox index f627a57a3b..f8c9ee8bd9 100644 --- a/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExamples.dox +++ b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExamples.dox @@ -1,22 +1,22 @@ /** \page BlueBerryExamples BlueBerry Examples The following examples give an introduction to Blueberry. The source code of the examples can be found in mitk/Examples/Plugins/ Run the examples by executing startBlueBerryExampleLauncher_release.bat (or startBlueBerryExampleLauncher_debug.bat depending on the configured build type). -\image html BlueBerryExampleLauncherDialog.png +\imageMacro{BlueBerryExampleLauncherDialog.png,"",14.14} All examples can be found among the shown list. \li \subpage BlueBerryExampleMinimalApplication \li \subpage BlueBerryExampleMultiplePerspectives \li \subpage BlueBerrySelectionServiceIntro \li \subpage BlueBerryExampleExtensionPoint \li \subpage BlueBerryExampleCustomViewer */ diff --git a/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExtensionPointsIntro.dox b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExtensionPointsIntro.dox index c3685a5d21..23128dd14c 100644 --- a/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExtensionPointsIntro.dox +++ b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExtensionPointsIntro.dox @@ -1,34 +1,34 @@ /** \page BlueBerryExampleExtensionPoint Extension Points \brief A minimal applictaion that definines an extension point and collects extensions. -# \subpage IntroductionExtensionPoints "Introduction" -# \subpage ExtensionPointDefinition "Extension Point Definition" -# \subpage ExtensionContribution "Extension Contribution" \page IntroductionExtensionPoints Introduction: Extension Point/Extension Concept The BlueBerry application framework provides the concept of extension points and extensions. The main goal is to allow the extension of functionality of a plugin (based on the contract defined by the extension point) by several other plugins. Both the extension point and the extension are defined in the according plugin.xml. -\image html ExtensionPoints.png "Extension Point concept" +\imageMacro{ExtensionPoints.png,"Extension Point concept",5.40} \section SimpleExample Why Extension Points? In the following simple example we have a plugin 'a' and 'b' with two classes 'A' and 'B' in these plugins. -\image html ExtensionPointEx.png "Simple Example" +\imageMacro{ExtensionPointEx.png,"Simple Example",5.10} Plugin 'a' uses the extension point mechanism and creates an extension point that can be extended by other plugins. Now if class 'A' reaches a part that can be extended it asks 'a' if another plugin is registered. If that's the case the functionality of the plugin 'b' that is defined in class 'B' is executed. A plugin can therefore be arbitrary extended. \section BlueBerryExampleExtensionPoint_Examples Examples The two following example plugins describe the usage of the BlueBerry Extension Points. One example defines an extension point and the other example extends the created extension point. \li \ref org_mitk_example_gui_extensionpointdefinition \li \ref org_mitk_example_gui_extensionpointcontribution [\ref BlueBerryExampleExtensionPoint] [Next: \ref ExtensionPointDefinition] [\ref BlueBerryExamples] */ diff --git a/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryIntro.dox b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryIntro.dox index 06e657920c..7323709e08 100644 --- a/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryIntro.dox +++ b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryIntro.dox @@ -1,79 +1,79 @@ /** \page BlueBerryIntro BlueBerry Application Framework BlueBerry is an application framework used in MITK for creating modular and extensible end-user applications. More high-level documentation can be found below: - \subpage BlueBerryWorkbench - \ref BlueBerryExamples Please see the \ref BlueBerryExamples for code examples demonstrating different features of the application framework. The BlueBerry developer reference is available here: - \ref BlueBerryPlugins - \subpage BlueBerryExtPointsIndex \page BlueBerryWorkbench The Workbench: What are Views, Editors, Perspectives? BlueBerry makes use of the Eclipse UI guidlines which state some concepts on how to build up a GUI. The different objects of the platform UI shall be described here: \section Workbench Workbench \li root object of the platform UI \li collection of \ref WorkbenchWindow "windows" -\image html workbench.jpg "The Workbech" +\imageMacro{workbench.jpg,"The Workbech",11.64} \section WorkbenchWindow WorkbenchWindow \li has one \ref Workbench-Page "page" -\image html workbench-window.jpg "Worbench Windows" +\imageMacro{workbench-window.jpg,"Worbench Windows",8.47} \section WorkbenchPage Workbench Page \li denotes to the inner part of the \ref WorkbenchWindow "window", that is: everything except the title bar \li may have one menu bar, one toolbar, one shortcut bar, and one statusbar \li has one or more \ref Perspective "perspectives" -\image html workbench-page.jpg "Workbench Page" +\imageMacro{workbench-page.jpg,"Workbench Page",8.47} \section Perspective Perspective -\image html workbench-window-perspective.png "A Perspective" +\imageMacro{workbench-window-perspective.png,"A Perspective",11.79} \section Part Part \li every \ref Views "View" or \ref Editors "Editor" is called \b Part \subsection Editors Editors \li the StdMultiWidget is an example for an editor in our MainApp \li Contains the primary content, such as a document or image data, which users interact with \li content is the primary focus of attention and a reflection of the primary task \li primary position in the UI \li contributes commands to the workbench's main menu bar and toolbar \li shared in other perspectives -\image html workbench-window-editor-area.png "Editor Area" +\imageMacro{workbench-window-editor-area.png,"Editor Area",11.79} \subsection Views Views -\image html workbench-window-views.png "Views" +\imageMacro{workbench-window-views.png,"Views",11.79} \section ClassDiagram Summary as class diagram -\image html workbench-class-diagram.jpg "class diagram" +\imageMacro{workbench-class-diagram.jpg,"class diagram",13.74} */ diff --git a/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerrySelectionServiceIntro.dox b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerrySelectionServiceIntro.dox index 570521ea87..c15625905e 100644 --- a/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerrySelectionServiceIntro.dox +++ b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerrySelectionServiceIntro.dox @@ -1,40 +1,40 @@ /** \page BlueBerrySelectionServiceIntro Selection Service -# \subpage IntroductionSelectionService "Introduction" -# \subpage BlueBerryExampleSelectionServiceQt -# \subpage BlueBerryExampleSelectionServiceMitk \page IntroductionSelectionService Introduction: Selection Service Concept The selection service provided by the BlueBerry workbench allows efficient linking of different parts within the workbench window: View parts that provide additional information for particular objects and update their content automatically whenever such objects are selected somewhere in the workbench window. For example the "Properties" view in MITK applications behaves in this way: Wherever an element is selected in the workbench this view lists the properties of that element. -\image html MitkSelectionService.png "DataNode properties" +\imageMacro{MitkSelectionService.png,"DataNode properties",16.00} Other aspects of the workbench like the enablement of global actions may also depend on the current selection. Each workbench window has its own selection service instance. The service keeps track of the selection in the currently active part and propagates selection changes to all registered listeners. Such selection events occur when the selection in the current part is changed or when a different part is activated. Both can be triggered by user interaction or programmatically. -\image html SelectionServiceDiagram.png "Selection Service Diagram" +\imageMacro{SelectionServiceDiagram.png,"Selection Service Diagram",11.64} \section BlueBerrySelectionServiceIntro_WhatCanBeSelected What can be selected? From the users point of view a selection is a set of highlighted entries in a viewer like a table or tree widget. A selection can also be a piece of text in an editor. Internally a selection is a data structure holding the model objects which corresponds to the graphical elements selected in the workbench. As pointed out before there are two fundamental different kinds of selections: \li A list of objects \li A piece of text \section BlueBerrySelectionServiceIntro_Examples The following two examples describe different ways of implementing and using the provided selection services. One example is based on the Qt selection model, the other one is based on the MITK Data node selection. \li \ref org_mitk_example_gui_selectionservicemitk \li \ref org_mitk_example_gui_selectionserviceqt Knowing and using the existing selection mechanisms gives your plug-ins a clean design, smoothly integrates them into the workbench and opens them for future extensions. [\ref BlueBerrySelectionServiceIntro] [Next: \ref BlueBerryExampleSelectionServiceQt] [\ref BlueBerryExamples] */ diff --git a/Documentation/Doxygen/DeveloperManual/Starting/Architecture.dox b/Documentation/Doxygen/DeveloperManual/Starting/Architecture.dox index c1553fe018..46a2a38934 100644 --- a/Documentation/Doxygen/DeveloperManual/Starting/Architecture.dox +++ b/Documentation/Doxygen/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 heavily reusable code base to enable rapid development of new features. Following this design philosophy MITK includes many different specialized modules e.g. the Segmentation Module. This document is aimed at giving an overview of the general structure of MITK. Furthermore it will give an introduction into the coding and design concepts behind this toolkit. \section OverviewPage_DesignOverview Design Overview MITK is designed to be used as a pure software library or as a complete application framework. Thus, a user of MITK can decide if he simply wants to add a new plug-in to the existing application framework or if he needs to implement his own application and wants to use 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. -\image html MitkOverview.png "Overview of MITK" +\imageMacro{MitkOverview.png,"Overview of MITK",16} Like shown above, MITK uses the following libraries. These are the main libraries MITK is based on. For further functionality you can optionally include others, a list can be found \ref thirdpartylibs "here" . Based on these libraries, MITK includes the following features: */ diff --git a/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/NewModule.dox b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/NewModule.dox index c2f026a6dc..c3b65b3ceb 100644 --- a/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/NewModule.dox +++ b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/NewModule.dox @@ -1,82 +1,82 @@ /** \page NewModulePage How to create a new MITK Module \section NewModulePageCreateFolder 1) Create a Folder for your Module First, create a folder for your module within /Modules e.g. 'NewModule'. You need to add the new Folder to the CMakeLists.txt in the Module directory as well as well. Open /Modules/CMakeLists.txt, it should be pretty clear how to add the Module, just insert it into the set(module_dirs) section. \code set(module_dirs ... NewModule ) \endcode Inside the folder create a new folder called "Testing", which will later contain the module tests. Also create subfolders for you sourceFiles, for example "NewModuleFilters" and "NewModuleSourceFiles". \section NewModulePageCreateCMakeLists 2) Create CMakeLists.txt Within your module create the following file named CMakeLists.txt with the following content: \code MITK_CREATE_MODULE(NewModule #<-- module name SUBPROJECTS INCLUDE_DIRS NewModuleFilters NewModuleServices #<-- sub-folders of module INTERNAL_INCLUDE_DIRS ${INCLUDE_DIRS_INTERNAL} DEPENDS Mitk #<-- modules on which your module depends on ) ADD_SUBDIRECTORY(Testing) #<-- Directory for tests \endcode Choose a fitting module name. This name should only contain Letters (both upper- and lowercase), no numbers, no underscores etc. This name will be used to qualify your Module within the MITK Framework, so make sure it is unique. Typically, the name will be the same as name of the Folder the Module resides in. It is good practice to create subfolders in your module to structure your classes. Make sure to include these folders in the List of subfolders, or CMake will not find the internal Files. In the DEPENDS section, you can enter the modules that your module requires to function. You will not be able to use classes from modules that are not listed here. \section NewModulePageCreatefilesdotcmake 3) Create files.cmake Next, create a new file and name it files.cmake, containing the following: \code SET(CPP_FILES NewModuleFilters/File1.cpp NewModuleFilters/File2.cpp NewModuleServices/Filter1.cpp ) \endcode Add each .cpp file you create to this file. Also, only add you .cpp files here, not the header files! \section NewModulePageCreateTEstingEnvironment 4) Set up the Test environment We also need to set up a testing environment where you can add your tests. Inside your "Testing" Folder, create a new files.cmake containing the following: \code SET(MODULE_TESTS mitkNewModuleTest.cpp ) \endcode Also, create a new CMakeLists.text: \code MITK_CREATE_MODULE_TESTS() \endcode That's it! Enjoy your new module! After following these steps, it should look something like this: -\image html NewModule.png "Your shiny new module!" +\imageMacro{NewModule.png,"Your shiny new module!",16} */ \ No newline at end of file diff --git a/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/StatemachineEditor.dox b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/StatemachineEditor.dox index ee87043e23..784ba6ecf1 100644 --- a/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/StatemachineEditor.dox +++ b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/StatemachineEditor.dox @@ -1,152 +1,152 @@ /** \page StatemachineEditor How to install and use the Statemachine-Editor \tableofcontents \section StatemachineEditorOverview Overview This plug-in for Eclipse allows you to create new statemachines and change existing statemachines in an graphical editor. You can open existing statemachines from a xml file or create a new statemachine in a new xml file. This document will tell you how to install the plug-in for eclipse and how to use it. \section StatemachineEditorInstallation How to Install the Statemachine-Editor First of all you have to install Eclipse (Eclipse Classic) and the plug-in Graphical Editing Framework (GEF). Furthermore we need the packages JDOM (jdom.jar) and Java3D (vecmath.jar). Caution: There have been problems reported with GEF runtime versions > 3.3.2. A known working configuration is: Eclipse SDK: 3.3.1 J3D: 1.5.1 Jdom: 1.0 GEF runtime: 3.3.2 Java Runtime Environment: jre6 Now you have to unzip the file StateMachines.zip into your eclipse folder. The file is located in your SVN checkout mitk/Modules/MitkExt/Interactions. Start Eclipse and select "File" -> "Import...". -\image html Import.PNG "\b Fig.1: Import" +\imageMacro{Import.PNG,"\b Fig.1: Import",16} In the popup window (Fig.1: Import) select the folder "Plug-in Development" and "Plug-ins and Fragments". Click "Next >". -\image html Import2.PNG "\b Fig.2: Import Plug-ins and Fragments" +\imageMacro{Import2.PNG,"\b Fig.2: Import Plug-ins and Fragments",16} On the page "Import Plug-ins and Fragments" ( Fig.2: Import Plug-ins and Fragments) just click "Next >". -\image html Import3.PNG "\b Fig.3: Selection" +\imageMacro{Import3.PNG,"\b Fig.3: Selection",16} On the page "Selection" ( Fig.3: Selection) select the "StateMachines (1.0.0)" Plug-in and click the "Add ->" button. -\image html Import4.PNG "\b Fig.4: Selection 2" +\imageMacro{Import4.PNG,"\b Fig.4: Selection 2",16} Click "Finish" ( Fig.4: Selection 2). Now you have to make sure that the path to vecmath.jar and jdom.jar is set correctly. -\image html BuildPath.PNG "\b Fig.5: Set build path" +\imageMacro{BuildPath.PNG,"\b Fig.5: Set build path",16} You can find the build path by selecting the project in the "Package Explorer" view. Then go to "Project" -> "Properties" -> "Java Build Path" in the tab "Libraries" (as you can see in Fig.5: Set build path). Now you should be able to start a Run-time Workbench. -\image html Runas.png "\b Fig.6: Start Run-time Workbench" +\imageMacro{Runas.png,"\b Fig.6: Start Run-time Workbench",16} Therefore you have to press the "Run" button and select "Eclipse Application". Click "OK" (Fig.6: Start Run-time Workbench). A new Eclipse workbench opens where we can use the Statemachine-Editor. \section StatemachineEditorManual How to use the Statemachine-Editor In the Eclipse Run-time Workbench we have to create a new Java project first (Fig.7: Create a new Java project). -\image html CreateJavaProject.PNG "\b Fig.7: Create a new Java project" +\imageMacro{CreateJavaProject.PNG,"\b Fig.7: Create a new Java project",16} Then you can select one of the two buttons: \li \ref StatemachineEditorManual1 \li \ref StatemachineEditorManual2 \subsection StatemachineEditorManual1 New Statemachines When you press the button "New Statemachine" the following window will pop up: -\image html NewStatemachine.PNG "\b Fig.8: New Statemachine" +\imageMacro{NewStatemachine.PNG,"\b Fig.8: New Statemachine",16} Here, you have to "Browse..." for your Java-Project as your file container (Fig.8: New Statemachine). -\image html NewStatemachine1.PNG "\b Fig.9: New Statemachine 1" +\imageMacro{NewStatemachine1.PNG,"\b Fig.9: New Statemachine 1",16} Select your Project and click "OK" (Fig.9: New Statemachine 1). -\image html NewStatemachine2.PNG "\b Fig.10: New Statemachine 2" +\imageMacro{NewStatemachine2.PNG,"\b Fig.10: New Statemachine 2",16} As soon as you have selected a container and a File name, the "Finish" button will become enabled (Fig.10: New Statemachine 2). Attention: If the filename has already been used, you have to set another filename to enable the "Finish" button. -\image html NewStatemachine3.PNG "\b Fig.11: New Statemachine 3" +\imageMacro{NewStatemachine3.PNG,"\b Fig.11: New Statemachine 3",16} As a last step you have to enter the location and name for the xml file to be generated (Fig.11: New Statemachine 3). If you want to have predefined events and actions, make sure the "mitkEventAndActionConstants.xml" file is in the same folder. Read on in Section \ref StatemachineEditorManual3. \subsection StatemachineEditorManual2 Statemachines from *.xml When you press the button "Statemachines from *.xml" the following window will pop up: -\image html openstatemachinexml.png "\b Fig.12: Open Statemachine from *.xml" +\imageMacro{openstatemachinexml.png,"\b Fig.12: Open Statemachine from *.xml",16} Here you have to select the xml file, which contains the statemachines (Fig.12: Open Statemachine from *.xml). If you want to have predefined events and actions, make sure the "mitkEventAndActionConstants.xml" file is in the same folder. -\image html specifycontainer.png "\b Fig.13: Select container" +\imageMacro{specifycontainer.png,"\b Fig.13: Select container",16} Here, you have to "Browse..." for your Java-Project as your file container (Fig.13: Select container). -\image html specifycontainer2.png "\b Fig.14: Select container 1" +\imageMacro{specifycontainer2.png,"\b Fig.14: Select container 1",16} Select your Project and click "OK" (Fig.14: Select container 1). -\image html specifycontainer3.png "\b Fig.15: Select container 2" +\imageMacro{specifycontainer3.png,"\b Fig.15: Select container 2",16} As soon as you have selected a container, the "Finish" button will become enabled (Fig.15: Select container 2). Read on in Section \ref StatemachineEditorManual3. \subsection StatemachineEditorManual3 Work with the Editor Now your workspace looks something like this: -\image html application.PNG "\b Fig.16: Workspace" +\imageMacro{application.PNG,"\b Fig.16: Workspace",16} You can open a statemachine from the "Statemachines List" view (Fig.16: Workspace) by performing a double click on the statemachine. An editor opens and on its palette you can find different tools, such as create state or create transition. -\image html openPropertiesView.PNG "\b Fig.17: Open the properties view" +\imageMacro{openPropertiesView.PNG,"\b Fig.17: Open the properties view",16} -\image html application1.PNG "\b Fig.18: Change statename in the properties view" +\imageMacro{application1.PNG,"\b Fig.18: Change statename in the properties view",16} To edit the statename or state ID you have to open the "Properties" view (Fig.18: Change statename in the properties view). You will get it by "Window"->"Show View" -> "Other..." -> "General" -> "Properties" (Fig.17: Open the properties view). -\image html changeEvent.PNG "\b Fig.19: Change Event" +\imageMacro{changeEvent.PNG,"\b Fig.19: Change Event",16} -\image html addAction.PNG "\b Fig.20: Add Action" +\imageMacro{addAction.PNG,"\b Fig.20: Add Action",16} To change a transitions event or action you have to select the transition and open its context menu (Fig.19: Change Event, Fig.20: Add Action). You can connect a transition to another state by drag one end of it and drop it to another state. All these changes are connected with an undo/redo controller. When you save your statemachine it will be saved as an xml file which you either have created with your new statemachine or have opened before. */ \ No newline at end of file diff --git a/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step00.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step00.dox index 01bbe0fb0e..769f2517fd 100644 --- a/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step00.dox +++ b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step00.dox @@ -1,15 +1,15 @@ /** \page Step00Page MITK Tutorial - Step 0: Getting started To build the tutorials follow the \ref BuildInstructionsPage and make sure that MITK_BUILD_EXAMPLES is checked/set to ON. -\image html configureCMake.PNG +\imageMacro{configureCMake.PNG,"",16.00} The tutorial source files can be found in the Examples\\Tutorial\\ subdirectory of the source tree. The tutorial executables are in the bin\\Release\\ or bin\\Debug\\ subdirectory (Windows) respectively the bin\\ subdirectory (Linux/Mac) of the binary tree after compilation (called StepX, corresponding to the tutorial step). \ref Step01Page "[Next step]" \ref TutorialPage "[Main tutorial page]" */ diff --git a/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step01.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step01.dox index 17dfc30bf7..78d4cf9aab 100644 --- a/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step01.dox +++ b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step01.dox @@ -1,22 +1,22 @@ /** \page Step01Page MITK Tutorial - Step 1: Displaying an image -\image html step1_result.png +\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 bin/CMakeExternals/Source/MITK-Data/Pic3D.nrrd. If you are using Visual Studio use the StartVS_release.bat in your bin\\ subdirectory to start it with all required paths set. To set the image file path in Visual Studio, right click on "Step1"-project and go to 'Properties -> Configuration Properties -> Debugging'. Now insert the image file path in the "Command Arguments" text field. Use this also in the following steps. -\image html configureVisualStudioProperties.png +\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/DeveloperManual/Starting/GettingToKnow/Tutorial/Step03.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step03.dox index 6a419a51a6..1f10f8283c 100644 --- a/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step03.dox +++ b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step03.dox @@ -1,48 +1,48 @@ /** \page Step03Page MITK Tutorial - Step 3: Create 3D view 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. In Step 3a the default is kept whereas in Step 3b volume rendering is turned on. As in the previous step, to obtain the result the program has to be executed using the image file bin/CMakeExternals/Source/MITK-Data/Pic3D.nrrd and the surface file src/MITK/Modules/MitkExt/Testing/Data/lungs.vtk. \li \ref Step3.cpp "Step3.cpp" \n Contains the code that both creates a 3D view and turns volume rendering on. \section Step3aSection Step 3a - Volume rendering turned off -\image html step3a_result.png +\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 -\image html step3b_result.png +\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/DeveloperManual/Starting/GettingToKnow/Tutorial/Step04.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step04.dox index 507e4e859b..3be398d420 100644 --- a/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step04.dox +++ b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step04.dox @@ -1,66 +1,66 @@ /** \page Step04Page MITK Tutorial - Step 4: Use several views to explore data 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 bin/CMakeExternals/Source/MITK-Data/Pic3D.nrrd and the surface file src/MITK/Modules/MitkExt/Testing/Data/lungs.vtk. \li \ref Step4.cpp "Step4.cpp"\n Contains the code of step 4a + b. \section Step4aSection Step 4a - Create axial and sagittal view -\image html step4a_result.png +\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 -\image html step4b_result.png +\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/DeveloperManual/Starting/GettingToKnow/Tutorial/Step06.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step06.dox index 6199730d84..82d4baf576 100644 --- a/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step06.dox +++ b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step06.dox @@ -1,112 +1,112 @@ /** \page Step06Page MITK Tutorial - Step 6: Use an interactive region-grower 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 only (bin/CMakeExternals/Source/MITK-Data/Pic3D.nrrd) since the surface will be the result of the region-growing. -\image html step6_result.png +\imageMacro{step6_result.png,"",13.55} 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" The class Step6 inherits from QMainWindow 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 } \until } 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_1 ... and for 3D in \ref Step6RegionGrowing2.cpp "Step6RegionGrowing2.cpp": \dontinclude Step6RegionGrowing2.cpp \skipline InstantiateAccessFunctionForFixedDimension_1 \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/DeveloperManual/Starting/GettingToKnow/Tutorial/Step09.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step09.dox index 20c57353a9..b72da7680d 100644 --- a/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step09.dox +++ b/Documentation/Doxygen/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.xpm............................ The icon of your plug-in. GIMP or other programs (including your text editor) + 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 Digia page describing .ui files (no, forget about the please, DO it!) 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/DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox b/Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox index 214320b027..9185a3dd8f 100644 --- a/Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox +++ b/Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox @@ -1,163 +1,163 @@ /** \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:
  1. 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).
  2. Use the MITK project template as an example project.
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 \b template \b. 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.
  1. Start "cmake-gui" and enter your source (e.g. "D:\AwesomeProject") and binary directory (e.g. "D:\AwesomeProject-superbuild").
  2. 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".
  3. Press "Configure" until no new variables appear and then "Generate". Now all project files have been generated into your binary directory.
  4. 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
  1. In the shell, switch to your binary directory.
  2. 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.
  1. 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.
  2. After the superbuild compilation has finished, close the solution file and start the batch file "D:\AwesomeProject-superbuild\AwesomeProject-build\StartVS_debug.bat" (or _release.bat if you built in Release mode) which opens the "D:\AwesomeProject-superbuild\AweseomeProject-build\AwesomeProject.sln" solution.
  3. 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):
  1. 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.
  2. Navigate to the plugin you want to use (e.g. "MITK_BUILD_org.mitk.gui.qt.segmentation") and tick the checkbox behind it
  3. Press "Configure" until no new variables appear and then "Generate".
  4. Build MITK using your development tool (as in \ref HowToNewProjectCompilingLinuxMakefiles or \ref HowToNewProjectCompilingVisualStudio only in the "D:\AwesomeProject-superbuild\MITK-superbuild\MITK-build\" directory )
  5. 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.
  6. Press "Configure" until no new variables appear and then "Generate".
  7. Build your project
  8. 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_mitkWorkbench ) 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_Boost Download and use Boost in MITK
  • \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_Python Download and compile 1CableSwig and enable Python wrapping in ITK, VTK, OpenCV, and MITK
  • \b MITK_USE_QT Use the Qt 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. -\image html HowToNewProject-MyProjectLayout.png "Layout of MyProject" +\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". */ \ No newline at end of file diff --git a/Documentation/Doxygen/DeveloperManual/Toolkit/ModuleManuals/GeometryMigration.dox b/Documentation/Doxygen/DeveloperManual/Toolkit/ModuleManuals/GeometryMigration.dox index dee3eed592..bd9146de8b 100644 --- a/Documentation/Doxygen/DeveloperManual/Toolkit/ModuleManuals/GeometryMigration.dox +++ b/Documentation/Doxygen/DeveloperManual/Toolkit/ModuleManuals/GeometryMigration.dox @@ -1,148 +1,148 @@ /** \page GeometryMigration Migration Guide to new Geometry Concept \tableofcontents \section GeneralChanges General Changes \subsection OldClasses Old class diagram Until now, all geometry classes inherited from Geometry3D. This inheritance didn't make sense. For example, there is no reason, why we need a Geometry2D and a PlaneGeometry as both describe the same thing. Also, why does a two-dimensional class need to inherit from a three-dimensional class? -\image html oldClasses.png "Old class diagram." +\imageMacro{oldClasses.png,"Old class diagram.",12.70} \subsection NewClasses New class diagram Therefore, we inserted an abstract BaseGeometry class, from which all other geometry classes should inherit. The classes Geometry2D and PlaneGeometry are combined in the new PlaneGeometry class. Also, the LandmarkBasedCurvedGeometry is included in LandmarkProjectorBasedCurvedGeometry. -\image html currentClasses.png "New class diagram." +\imageMacro{currentClasses.png,"New class diagram.",15.32} \section Howto How to adapt your code Most content of the BaseGeometry class consists of functions and variables of the former Geometry3D. Here are some guidelines, how to change your code to the new geometry scheme. \subsection privateVariables Variables are private. All variables of BaseGeometry (former in Geometry3D) are private now. Hence, use the Set and Get methods to access the variables. \subsection geo2d Always use PlaneGeometry instead of Geometry2D. The class Geometry2D does not exist any more. In most cases, you can just replace the Geometry2D by PlaneGeometry. Please pay attention if you use the function "IsAbove(Point3D point)". There were two different implementations in Geometry2D and PlaneGeometry. The default behavior is implemented according to the former function of PlaneGeometry. If you want to use the implementation of the former Geometry2D, please call "IsAbove(point,true)".\n Here are the different implementations: \code bool PlaneGeometry::IsAbove( const Point3D &pt3d_mm , bool considerBoundingBox = false) const { if(considerBoundingBox) { //This is the implementation of former Geometry2D Point3D pt3d_units; BaseGeometry::WorldToIndex(pt3d_mm, pt3d_units); return (pt3d_units[2] > this->GetBoundingBox()->GetBounds()[4]); } else { //This is the implementation of former PlaneGeometry and the default behavior. return SignedDistanceFromPlane(pt3d_mm) > 0; } } \endcode \subsection geo2ddata Rename Geometry2D... classes. All ...Geometry2D... classes and functions are renamed to ...PlaneGeometry... . The new names are for example PlaneGeometryData instead of Geometry2DData. An example for functions is GetGeometry2D, which is now called GetPlaneGeometry. A simple search & replace of Geometry2D should work in most cases.\n\n List of all names changed (excluding variables):
  • Geometry2D
  • Geometry2DData
  • Geometry2DDataToSurfaceFilter
  • Geometry2DDataMapper2D
  • Geometry2DDataVTKMapper
  • GetCurrentWorldGeometry2D
  • GetCurrentWorldGeometry2DNode
  • GetCurrentWorldGeometry2DUpdateTime
  • SetCurrentWorldGeometry2D
  • GetGeometry2DData
  • GetGeometry2D
  • SetGeometry2D
\subsection geo3d In some cases, use BaseGeometry instead of Geometry3D. As there are no classes any more, which inherit from Geometry3D, you cannot insert other classes (i.e. SlicedGeometry3D) for a Geometry3D. If you have trouble, e.g. calling a function which expects a Geometry3D parameter, try one of the following steps:
  • Do you really need a Geometry3D? Maybe you always use e.g. a PlaneGeometry. Change your function to PlaneGeometry.
  • If your function/object needs to be flexible for all geometry classes, change the Geometry3D to BaseGeometry.
  • Try dynamic type casts to BaseGeometry.
\subsection clone Clones of BaseGeometry. The BaseGeometry class is an abstract class. You cannot create an object of BaseGeometry. If you need a clone of BaseGeometry to call a function, use the following code: \code itk::LightObject::Pointer lopointer = geometry.Clone(); Initialize(dynamic_cast(lopointer.GetPointer())); \endcode instead of: \code Geometry3D::Pointer geometry3D = geometry.Clone(); Initialize(geometry3D.GetPointer()); \endcode \subsection object Create an object of BaseGeometry. Again, you cannot create an object of BaseGeometry. However, there are cases, where we need a flexible Variable which can contain objects of any other geometry class later on. This might be the case for member variables, etc. In this case, try: \code mitk::Geometry3D::Pointer geo3D = Geometry3D::New(); mitk::BaseGeometry::Pointer m_geometry = dynamic_cast(geo3D.GetPointer()); \endcode instead of \code mitk::Geometry3D::Pointer m_geometry = mitk::Geometry3D::New(); \endcode \subsection virtual Virtual functions. To ensure a reliable behavior of functions, most functions are not virtual any more. However, if a function needs a different behavior in subclasses, there are virtual Pre- and Post- functions, which allow for additional code. The pre-functions are called at the very beginning of a function, the post-functions at the end. In the BaseGeometry, all pre- and post-functions are empty.\n An example:\n The function "SetIndexToWorldTransform" is not virtual any more. For a PlaneGeometry, we need a perpendicular normal before the transformation is set. Afterwards, we need to apply the transformation to the scaling factors.\n Code of the BaseGeometry class: \code void SetIndexToWorldTransform(mitk::AffineTransform3D* transform) { PreSetIndexToWorldTransform(transform); if(m_IndexToWorldTransform.GetPointer() != transform) { m_IndexToWorldTransform = transform; CopySpacingFromTransform(m_IndexToWorldTransform, m_Spacing); vtk2itk(m_IndexToWorldTransform->GetOffset(), m_Origin); TransferItkToVtkTransform(); Modified(); } PostSetIndexToWorldTransform(transform); } virtual void PreSetIndexToWorldTransform(mitk::AffineTransform3D* transform){}; virtual void PostSetIndexToWorldTransform(mitk::AffineTransform3D* transform){}; \endcode Code of PlaneGeometry: \code void PlaneGeometry::PreSetIndexToWorldTransform(mitk::AffineTransform3D *transform) { EnsurePerpendicularNormal(transform); } void PlaneGeometry::PostSetIndexToWorldTransform(mitk::AffineTransform3D* transform) { m_ScaleFactorMMPerUnitX=GetExtentInMM(0)/GetExtent(0); m_ScaleFactorMMPerUnitY=GetExtentInMM(1)/GetExtent(1); } \endcode \subsection parametric Parametric functions are not part of BaseGeometry. In Geometry3D, there were several "Parametric" functions (e.g. GetParametricExtent, GetParametricTransform), which only called the non-parametric function (e.g. GetExtent, GetIndexToWorldTransform). These functions are removed, please use the non-parametric implementation instead. However, in the AbstractTransformGeometry (and all subclasses), these parametric functions behave different and are still available. \subsection floatspacing There is no float spacing any more. Use GetSpacing instead of GetFloatSpacing. \subsection LandmarkBased Always use LandmarkProjectorBasedCurvedGeometry instead of LandmarkBasedCurvedGeometry. The class LandmarkBasedCurvedGeometry does not exist any more. Please use LandmarkProjectorBasedCurvedGeometry. */ diff --git a/Documentation/Doxygen/UserManual/Applications.dox b/Documentation/Doxygen/UserManual/Applications.dox index bf3cdfa36f..cba372ea38 100644 --- a/Documentation/Doxygen/UserManual/Applications.dox +++ b/Documentation/Doxygen/UserManual/Applications.dox @@ -1,33 +1,33 @@ /** \page ApplicationsPage Using MITK and Applications \tableofcontents \section ApplicationsPageApplications What are Applications? Applications are special versions of MITK which contain functionality aimed at solving a special task. Usually they are aimed at a selective audience or solving a particular problem. As such they focus on certain capabilities of MITK, while ignoring others. The main reason for this is to supply the users of the application with the power of MITK for solving their tasks, without daunting them with an overwhelming number of menus and options. At the same time, this allows the creation of an elegant and easily comprehensible workflow for your task. The Diffusion Imaging Application for example contains all the functionality necessary for the field of neuro-imaging, but does not contain support for ultrasound imaging. A typical example of this would be an application which contains only views related to the analysis of the human brain (particular question) or one which contains only what is necessary for displaying medical data in the classroom (specific audience). \section ApplicationsPageWhatAmIUsing Which Application am I using? If you are unsure which application you are currently using, start the application and have a look in the Title Bar. You should see it's name there. -\image html ApplicationTitle.jpg "The application name is displayed in the title bar" +\imageMacro{ApplicationTitle.jpg,"The application name is displayed in the title bar",16} \section ApplicationsPageApplicationsList List of Applications If you are interested in using a specific application, currently developed by the MITK team you might want to take a look first at the \ref MITKUserManualPage . Further information on any application can be found here:
  • \subpage org_mitkworkbench
  • \subpage org_dti_atlas_application
  • \subpage org_mitk_gui_qt_diffusionimagingapp
*/ \ No newline at end of file diff --git a/Examples/Plugins/org.mitk.example.gui.customviewer/documentation/doxygen/CustomViewerExample.dox b/Examples/Plugins/org.mitk.example.gui.customviewer/documentation/doxygen/CustomViewerExample.dox index 27c69a3c44..bb4a77cf9a 100644 --- a/Examples/Plugins/org.mitk.example.gui.customviewer/documentation/doxygen/CustomViewerExample.dox +++ b/Examples/Plugins/org.mitk.example.gui.customviewer/documentation/doxygen/CustomViewerExample.dox @@ -1,314 +1,314 @@ /** \page BlueBerryExampleCustomViewer A highly customized viewer This documentation is structured as follows: -# \subpage Introduction -# \subpage ViewerPluginCreation -# \subpage MainWindowLayout -# \subpage AddFunctionality -# \subpage GUICustomization \page Introduction Introduction The Custom Viewer Example is a BlueBerry example plugin, developed to demonstrate customization capabilities provided by the BlueBerry application framework. The example plugin implements a GUI customized viewer application. The developed viewer incorporates simple viewer functionality embedded in a customized graphical user interface. Spoken in BlueBerry terms, the following features are provided:
  • Hidden Menu-, Tool- and Statusbars
  • Hidden Editor Area
  • Fixed perspectives
  • Customized main window contents
  • Customized perspectives bar based on QTabBar
  • GUI Customization using Qt-Stylesheets
The custom viewer itself consists of two perspectives, i.e. a viewer perspective and a DICOM perspective. As part of the viewer perspective, an instance of QmitkDataManagerView allows for data selection. Visualization of the selected data is then provided by a simple render window view. According data can either be directly loaded from file or be imported as DICOM data. DICOM import functionality is accessible from the DICOM perspective incorporating the QmitkDicomExternalDataWidget. The GUI-appearance is customized using Qt-Stylesheets in order to give the application a non-native look and feel. This is further emphasized by a Tab-Widget-like presentation of the perspectives using a modified perspective bar based on a QTabBar. In addition to an absence of menu-, tool- and status-bars, simplicity is accentuated by a proper view and perspective design, i.e. the editor area being invisible and views being fixated. The following images depict the viewer- and DICOM-perspectives of the custom viewer. -\image html ViewerPerspective.png "Viewer perspective of the Custom Viewer." +\imageMacro{ViewerPerspective.png,"Viewer perspective of the Custom Viewer.",16.00} -\image html DicomPerspective.png "Dicom perspective of the Custom Viewer." +\imageMacro{DicomPerspective.png,"Dicom perspective of the Custom Viewer.",16.00} Go to the previous page \ref BlueBerryExampleCustomViewer. Or proceed to the next page \ref ViewerPluginCreation. \page ViewerPluginCreation Creating the CustomViewer plugin As we want to develop our Custom Viewer as part of BlueBerry to demonstrate the customization capabilities of the application framework, we have to integrate the components of our example application as BlueBerry plugins in order to make the application framework's functionalities available to our application. For example plugin startup with BlueBerry, a convenience application called BlueBerryExampleLauncher is already provided in the Examples/BlueBerryExampleLauncher directory of MITK. This application acts as a BlueBerry loading mechanism for any example application provided. To make an example application startable by the BlueBerry example launcher, we have to provide a folder inside Examples/Plugins containing all files making up the application plugin itself. Additionally, we have to add entries to the PluginList.cmake in the Examples/Plugins directory for plugin registration and create a new file in the Examples/BlueBerryExampleLauncher/Configurations folder containing the plugin itself as well as any further required plugin. The resulting plugin folder for our custom viewer application consists of several subfolders and files: -\image html CustomViewerDirectory.png "The directory structure for the CustomViewer plugin." +\imageMacro{CustomViewerDirectory.png,"The directory structure for the CustomViewer plugin.",16.00} We can see a documentation and resources folder, a source folder containing all source files, some cmake-related files and a plugin.xml file for the BlueBerry related plugin extension and extension-point declarations. Next, we add some source code to our plugin folder. First, we need a class for our CustomViewer application itself which we derive from the berry:IApplication application class: \dontinclude CustomViewer.h \skip class CustomViewer : public QObject \until void Stop(); In short, this class acts as an entry point for the BlueBerry application runtime. It defines what the application does when it is started (Start()-Method) and before it is ended (Stop()-Method). Our Start()-Method creates a BlueBerry display for GUI-rendering and a WorkbenchAdvisor for workbench control. Then the BlueBerry workbench is created and run given the created display and WorkbenchAdvisor: \snippet MinimalApplicationSnippet.cpp MinimalApplicationClass_StartMethod The Stop()-method does not need to be further defined. In addition, a default perspective identifier is given to define an initial perspective to be shown by the WorkbenchWindow. Later, we well need a proper WorkbenchAdvisor class derived from berry::WorkbenchAdvisor. In it, we will create a WorkbenchWindowAdvisor, which on his part is used to control the WorkbenchWindow's GUI creation. For now, we simply use the berry::WorkbenchWindowAdvisor, which creates the GUI in a default way. As the development of our custom viewer advances, we will want to take part in the GUI creation ourselves, so we will need to customize our own WorkbenchWindowAdvisor accordingly. Now we create a class named ViewerPerspective which is derived from berry::IPerspectiveFactory: \snippet ViewerPerspective.h ViewerPerspectiveClassDeclaration It acts as an initial perspective to be displayed as part of our bulk application plugin. For now, the perspective will remain empty and can, alongside the definition of further perspectives, be provided with views later by overwriting the CreateInitialLayout()-Method. Finally, we need a ctkPluginActivator derived class which is used to customize the starting and stopping of our plugin: \snippet org_mitk_example_gui_customviewer_Activator.h PluginActivatorHeader During plugin-start, we register our plugin classes given the ctkPluginContext by overwriting the start()-Method. \dontinclude org_mitk_example_gui_customviewer_Activator.cpp \skip ::start \until ViewerPerspective \skip PluginContext \until } In order to connect our application and its perspectives to the BlueBerry components we have to declare the according extension-point-contributions inside the plugin.xml file. As can be seen in the image below, our application and its perspectives contribute to the org.blueberry.osgi.applications and org.blueberry.ui.perspectives extension points respectively. -\image html plugin_xml_0.png "Extension point contributions of our initial custom viewer application" +\imageMacro{plugin_xml_0.png,"Extension point contributions of our initial custom viewer application",16.00} When we start the BlueBerryExampleLauncher (either directly or via the provided batch files), we can now choose our bulk application (among others present), and a window is presented showing our empty initial perspective. -\image html MinimalApplicationWindow.png "Our first application window showing one single perspective" +\imageMacro{MinimalApplicationWindow.png,"Our first application window showing one single perspective",16.00} Go to the previous page \ref Introduction. Or proceed to the next page \ref MainWindowLayout. \page MainWindowLayout Main Window Layout: ViewerPerspective and DicomPerspective Now that we have created a bulk plugin for our custom viewer, we intend to customize the way how the main window of our Blueberry application is laid out. We want:
  • No visible menu-, tool- and status-bars
  • Two perspectives: a viewer perspective and a DICOM perspective
  • A tab-bar like perspective bar that allows for perspective switching
  • An open file button for perspective-independent file opening
Customizing the main window contents requires creating a custom WorkbenchWindowAdvisor derived from berry::WorkbenchWindowAdvisor hence this class controls the WorkbenchWindow layout: \snippet CustomViewerWorkbenchWindowAdvisor.h CustomViewerWorkbenchWindowAdvisorClassDeclaration As we mentioned in \ref ViewerPluginCreation, it is the WorkbenchAdvisor class that creates the WorkbenchWindowAdvisor. Hence, we now create our own version of a WorkbenchAdvisor: \snippet CustomViewerWorkbenchAdvisor.h WorkbenchAdvisorDecl Here, we overwrite the CreateWorkbenchWindowAdvisor()-method: \snippet CustomViewerWorkbenchAdvisor.cpp WorkbenchAdvisorCreateWindowAdvisor First, to prevent the WorkbenchWindow from rendering any menu-, tool- and status-bars, we overwrite the PreWindowOpen()-Method of the WorkbenchWindowAdvisor and access the WorkbenchWindowConfigurer helper class instance. Additionally, we set an appropriate title for our application window: \snippet CustomViewerWorkbenchWindowAdvisor.cpp CustomViewerWorkbenchWindowAdvisorPreWindowOpen Then we forge bulk versions of our viewer and dicom perspectives. We already created a bulk version of the viewer perspective earlier (see \ref ViewerPluginCreation). Accordingly, we create our DicomPerspective by defining the perspective class, contributing to the perspectives-extension point, registering the perspective in the plugin activator and adding to the cmake files. For the tab-bar like perspective bar we define a QtPerspectiveSwitcherTabBar derived from QTabBar: \snippet QtPerspectiveSwitcherTabBar.h PerspectiveSwitcherDeclaration The perspective switching functionality is implemented by a SwitchPerspective function, a signal-slot-connection that reacts on tab changes and a perspective listener that on perspective activation consistently switches to the according tab. Within the SwitchPerspective function, we show the perspective according to the current index indicating the currently active tab: \snippet QtPerspectiveSwitcherTabBar.cpp PerspectiveSwitcherSwitchPerspective Here, we have to ignore the first tab change event that can be fired during tab bar configuration. At that time, the perspective layout generally is not yet finished, which subsequently leads to an error. The SwitchPerspective slot is being connected to the tab-change-event during construction. The perspective listener is implemented as a helper friend struct derived from berry::IPerspectiveListener: \snippet QtPerspectiveSwitcherTabBar.cpp SwitchPerspectiveListener In the PerspectiveActivated-Method, we activate the tab according to the activated perspective's ID: \snippet QtPerspectiveSwitcherTabBar.cpp SwitchPerspectiveListenerPerspectiveActivated Now, our tab-bar like perspective bar is ready for use in the customized window layout. The open file functionality will later be implemented as an OpenFile-slot to the WorkbenchWindowAdvisor. Refer to \ref AddFunctionality for details. As such, it can be connected to a perspective-independent push button that will be part of to the application's window contents, together with an instance of the QtPerspectiveSwitcherTabBar. The customization of the window contents takes place within the CreateWindowContents method. That means, we can overwrite the superclass' CreateWindowContents method and lay out every widget of the main window individually. Given the method's berry::Shell parameter, we can extract the application's main window as QMainWindow using the berry::Shell::GetControl()-method: \snippet CustomViewerWorkbenchWindowAdvisor.cpp WorkbenchWindowAdvisorCreateWindowContentsHead Usually, as in the superclass' CreateWindowContents method, the shell ist given to the WindowConfigurer where the Page Composite, i.e. the part holding the perspective's view contents, is added as a single QControlWidget to an HBoxLayout. For our purposes, we want to place the QtPerspectiveSwitcherTabBar and the View-Button alongside the Page Composite. We can achieve that by creating the Page Composite within the CreateWindowContents method, lay it out in the MainWindow together with the other widgets, and give it to the WorkbenchWindowConfigurer for the view control layout process, which will then take place wrapped within our own PageComposite widget: \dontinclude CustomViewerWorkbenchWindowAdvisor.cpp \skip mainWindow->setCentralWidget(CentralWidget); \until PerspectivesLayer->addWidget(OpenFileButton); \skip for correct initial layout \until this->GetWindowConfigurer The OpenFile-Button and the QtPerspectiveSwitcherTabBar will be laid out together in a HBoxLayout called PerspectivesLayer. The PerspectivesLayer will be vertically arranged with the PageComposite widget in a VBoxLayout called CentralWidgetLayout. This CentralWidgetLayout will be assigned a QWidget being set the CentralWidget of our MainWindow. Caveat: we need to call the activate- and update-Methods of our CentralWidgetLayout; otherweise the widgets will not be laid out properly. See Bug-1654 for further details. See our bulk custom viewer application depicted below. -\image html BulkApplicationWindow.png "Our bulk application showing two empty perspectives managed with a tab-bar based perspectives bar" +\imageMacro{BulkApplicationWindow.png,"Our bulk application showing two empty perspectives managed with a tab-bar based perspectives bar",16.00} Go to the previous page \ref ViewerPluginCreation. Or proceed to the next page \ref AddFunctionality. \page AddFunctionality Adding functionality: Data Manager, Render Window, File Opening and DICOM Import Up to now, we have developed a bulk custom viewer application, i.e. a runnable BlueBerry application showing an open file button and two perspectives switched by a custom tab-bar like perspectives bar. Now, we will add the desired functionality for our custom viewer. We want to integrate:
  • A Data Manager, managing Data Nodes related to loaded or DICOM-imported images
  • A Render Window to visualize the Data Nodes
  • File Opening functionality connected to the Open-File-Button
  • DICOM Import functionality
Except for the File Opening functionality, which is already GUI-represented, we need to integrate proper views to our perspectives in order to make the according functionality accessible. Concerning the design of our example application, two options appear straight-forward:
  1. Integrate the view-class source-code to the main-application-plugin (the custom viewer plugin)
  2. Create a proper plugin for the views
Taking into account the plugin dependencies, it can be revealed that the first solution is not an option. Without going into detail, that solution would result in a cyclic dependency scenario, so an adequate plugin activation order would not be achievable at runtime. So we will create a proper plugin for the views we intend to use. This is straightforward as shown in \ref ViewerPluginCreation. For Data Manager functionality we will make use of the QmitkDataManagerView which - being a berry::IVewPart - can externally be integrated to our viewer perspective. The only thing we have to do is add the QMitkDataManagerView to the viewer perspective's CreateInitialLayout()-method: \dontinclude ViewerPerspective.cpp \skip ::CreateInitialLayout \until org.mitk.views.datamanager For the rendering functionality we have to create a proper view class. We derive that view class called SimpleRenderWindowView from QmitkAbstractView (for direct DataStorage access) and from mitk::IRenderWindowPart: \snippet SimpleRenderWindowView.h SimpleRenderWindowViewDeclaration Concrete implementations can for example be adapted from QmitkAbstractRenderEditor. The AbstractRenderWindowViewPrivate helper class is modified with regard to the views-Plugin-Activator: \snippet SimpleRenderWindowView.cpp SimpleRenderWindowViewHelper In CreateQtPartControl() we can now lay out the view controls. For that, we create a QmitkRenderWindow whose Renderer is subsequently be given the DataStorage: \snippet SimpleRenderWindowView.cpp SimpleRenderWindowViewCreatePartControl Finally we add the SimpleRenderWindowView in ViewerPerspective::CreateInitialLayout(): \snippet ViewerPerspective.cpp AddView1 For the DICOM import functionality we derive the DicomView class from QmitkAbstractView: \snippet DicomView.h DicomViewDecl In CreateQtPartControl(), we add a QmitkDicomExternalDataWidget to our view controls (this time e.g. via ui-File): \snippet DicomView.cpp DicomViewCreatePartControl The QmitkDicomExternalDataWidget yields a tree view for DICOM data, as well as a signal for Dicom transfer to the data manager and a slot for DICOM import to the tree view. With the Dicom transfer signal a string containing information about the DICOM series currently selected in the tree view is piggybacked. We use this information in an AddDataNodeFromDICOM slot defined in the DicomView class following the example of the DicomEventHandler class: \snippet DicomView.cpp DicomViewCreateAddDataNodeInformation The file path and seriesUID information are used to load the selected DICOM series into a mitk::DataNode: \snippet DicomView.cpp DicomViewCreateAddDataNodeLoadSeries which can then be added to the DataStorage: \snippet DicomView.cpp DicomViewCreateAddDataNode After that, we activate the viewer perspective to examine the data in the rendering window view. \snippet DicomView.cpp DicomViewCreateAddDataNodeActivatePersp Having a look back to the QmitkDicomExternalDataWidget, while there is already a view button present that triggers Dicom transfer signal emission, we still have to bind DICOM import functionality to a proper import button. We will do this once again in the CreateQtPartControl method (refer to the above snippet). After setting up the view controls containing the QmitkDicomExternalDataWidget and an import button, we render the unused widgets invisible. After connecting the Dicom transfer signal to the AddDataNodeFromDICOM slot and our import button to the DICOM import slot of the QmitkDicomExternalDataWidget, the DicomView is ready for use. Finally, the DicomView is added inside the DicomPerspective::CreateInitialLayout() method: \snippet DicomPerspective.cpp DicomPerspCreateLayout The following images show the Dicom import functionality. -\image html dicomImportFiles.png "The DICOM file import dialog" -\image html dataTree.png "Imported DICOM data shown in the tree view" -\image html DICOMimported.png "Imported DICOM data presented in the render window view" +\imageMacro{dicomImportFiles.png,"The DICOM file import dialog",16.00} +\imageMacro{dataTree.png,"Imported DICOM data shown in the tree view",16.00} +\imageMacro{DICOMimported.png,"Imported DICOM data presented in the render window view",16.00} Now we implement the file open slot already defined earlier (see \ref MainWindowLayout). While it appears that we could simply assign a QmitkFileOpenAction to a QToolButton, this is not possible due to the fact, that by default, the WorkbenchUtil::LoadFiles() method invoked by the QmitkFileOpenAction awaits an editor to be present in the current application. To prevent the method from throwing an exception, we made a workaround by giving the LoadFiles() method an additional parameter that determines whether an editor is to be opened or not: \snippet mitkWorkbenchUtil.cpp UtilLoadFiles Hence, we have to invoke that method manually, e.g. inside an OpenFile-slot implemented inside the WorkbenchWindowAdvisor: \snippet CustomViewerWorkbenchWindowAdvisor.cpp WorkbenchWindowAdvisorOpenFile In it, a dialog is opened that asks for the user for a number of files to open. If any files are given, these are being loaded by the WorkbenchUtil::LoadFiles method. Finally, the viewer perspective is activated: \snippet CustomViewerWorkbenchWindowAdvisor.cpp WorkbenchWindowAdvisorOpenFilePerspActive Before we can examine the loaded data, we have to manually invoke a reinit on it. The render window concept in mitk is actually undergoing some work, where this inconvenience will also be adressed. The images below show the resulting file opening functionality. -\image html OpenFileDialog.png "The open file dialog" -\image html FileOpened.png "Opened file shown in the render window view" +\imageMacro{OpenFileDialog.png,"The open file dialog",16.00} +\imageMacro{FileOpened.png,"Opened file shown in the render window view",16.00} Go to the previous page \ref MainWindowLayout. Or proceed to the next page \ref GUICustomization. \page GUICustomization Customizing the Main Window using Qt-Stylesheets In a final step, we want to further customize the appearance of our mainWindow to give it an distinct non-native look and feel. We want to achieve this by pursuing the following aims:
  • Change the background and widget colors
  • Change the tab-widget and ToolButton style, also with respect to mouse-over-button (hovering) effects
  • Completing the non-native tab-widget like impression of the perspectives by gluing tab-bar and perspective's PageComposite together
  • DICOM Import functionality
For GUI customization, we will modify the Qt-Stylesheets files already used by blueberry applications. Within the Qt-Stylesheet-Files, all widgets can globally and locally be adressed inside the main window for style changes. We have to adress the berry::IQtStyleManager to tell the BlueBerry workbench to use a specific Qt-Stylesheet. This is done inside the WorkbenchAdvisor in the CustomViewerWorkbenchAdvisor::Initialize() method: \snippet CustomViewerWorkbenchAdvisor.cpp WorkbenchAdvisorInit The style manager is taken from the application's plugin context via service reference. Invoking the berry::IQtStyleManager::AddStyle() and berry::IQtStyleManager::SetStyle() methods, the workbench will now use the announced qss-File to style our Workbench Window. In a production system, the stylesheets are usually compiled into the plug-in or application using the Qt resource system. However, during developement of the stylesheets it is often more convenient to reference them using a hard-coded path to the local file system (see live update functionality below). Before we start customization we will first provide some customization convenience. We add an UpdateStyle()-slot to our CustomViewerWorkbenchWindowAdvisor where we explicitly reset the css-File to the style manager: \snippet CustomViewerWorkbenchWindowAdvisor.cpp WorkbenchWindowAdvisorUpdateStyle By integrating an update style button to the Application's main window and connecting this button with the previously defined slot, we can now button-push-update the style on runtime. This will of course only work for stylesheets which are referenced from the local file system. -\image html StyledMainWindow0.png "The unstyled Main Window" +\imageMacro{StyledMainWindow0.png,"The unstyled Main Window",16.00} First we might want to change the background color style by setting the background color of the QWidget#CentralWidget to a linear gradient from light to dark blue: \snippet customstyleSnippet.qss CentralWidgetColor Then, we give the page composite control widget a slight grey border (except for the upper border where no border should be visible) and the same background color as the activated tab widget: \snippet customstyleSnippet.qss PageComposite The image below depicts the style changes. -\image html StyledMainWindow2.png "Background-color changed Central and Composite Control Widgets" +\imageMacro{StyledMainWindow2.png,"Background-color changed Central and Composite Control Widgets",16.00} Concerning the tab-widget style, four states have to be customized: QtPerspectiveSwitcherTabBar::tab (the tab in general), QtPerspectiveSwitcherTabBar::tab:selected (when tab is selected), QtPerspectiveSwitcherTabBar::tab:selected:hover (when tab is selected and the mouse is hovering above), QtPerspectiveSwitcherTabBar::tab:!selected:hover (respectively). All tabs are given round corners using border-top-left- and border-top-right-radius definitions. Additionally, all tabs is provided a gap to its neighbor defining a positive margin right. Selected tabs appear bigger by defining a negative upper margin, and they have no lower frame in the unselected state so a tab-widget appearance is provided. Finally, they have a brighter background color also used by the QWidget#ClientComposite. Hovering tabs are colored yellow and have a visible lower border: \snippet customstyleSnippet.qss Tabs Finally, we customize the Push- and Tool-Buttons in a similar way: \snippet customstyleSnippet.qss Buttons The resulting style-customized main window is shown below (the style update button removed). -\image html StyledMainWindow_final1.png "The final version of our Custom Viewer (viewer perspective)." -\image html StyledMainWindow_final2.png "The final version of our Custom Viewer (DICOM perspective)." +\imageMacro{StyledMainWindow_final1.png,"The final version of our Custom Viewer (viewer perspective).",16.00} +\imageMacro{StyledMainWindow_final2.png,"The final version of our Custom Viewer (DICOM perspective).",16.00} Proceed to the previous page \ref AddFunctionality. */ The custom viewer plugin implements simple viewer functionality presented in a customized look and feel. It was developed to demonstrate extensibility and customizability of the blueberry application framework. As an example for the GUI customization capabilities provided by the BlueBerry application framework, the custom viewer plugin was developed. It features simple viewer functionality presented in a customized look and feel. The custom viewer consists of two perspectives, i.e. a viewer perspective and a DICOM perspective. As part of the viewer perspective, an instance of QmitkDataManagerView allows for data selection. Visualization of the selected data is then performed by a simple render window view. According data can either be directly loaded from file or be imported as DICOM data. DICOM import functionality is accessible from the DICOM perspective incorporating the QmitkDicomExternalDataWidget. The customization of Qt Stylesheets is used to give the application a non-native look and feel. This is further emphasized by a Tab-Widget-like unification of the perspectives with the according perspective bar. In addition to an absence of menu-, tool- and status-bars, simplicity is accentuated by a proper view and perspective design, i.e. the editor area being invisible and views being fixated. TODO: //-for plugin folder creation, do we use the plugin generator? diff --git a/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkColourImageProcessing.dox b/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkColourImageProcessing.dox index dea970f477..bd8d91cf73 100644 --- a/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkColourImageProcessing.dox +++ b/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkColourImageProcessing.dox @@ -1,34 +1,34 @@ /** \page org_mitk_views_colourimageprocessing The Colour Image Processing Module -\image html ColorImageProcessing.png "Icon of the Module" +\imageMacro{ColorImageProcessing.png,"Icon of the Module",2.00} \section QmitkColourImageProcessingUserManualSummary Summary This module allows the user to create coloured images from medical images. Generally, these coloured images would be used in presentations, research papers, or as a teaching aide. \section QmitkColourImageProcessingUserManualOverview Overview The purpose of this module is to create coloured images, which can then be later used in presentations, research papers, or anything else the user desires. Furthermore, different body sections can be assigned a different colour. These images are not particularly useful for further image processing, but provide nice, clear, diagrams. Please note that ultrasound images cannot be coloured. \section QmitkColourImageProcessingUserManualFilters Creating Coloured Images Open an image in mitk, then click on the colour wheel button. Make sure the image you loaded is selected.

\ Image -> RGBAimage

Clicking on this button creates an RGBA image from your medical image, which should appear in your data manager.

\ Image + mask -> RGBAimage

Before clicking on this button, a mask is needed. A mask is generally created using the segmentation tool. Make sure both the mask and image are selected, then click on the image + mask -> RGBA image button. This creates an RGBA image that is coloured only in section defined by the mask.

\ Image + mask + color-> RGBAimage

This functions the same way as the Image + mask -> RGBAimage. The difference is that the user can select the colour of the section represented by the mask. This is done by clicking on the colour next to the Image + mask + color-> RGBAimage button If multiple RGBA images are created with different colours, they can be combined into one image. Ensure that the desired coloured images are selected, then click on the combine RGBA images button. */ diff --git a/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkIsoSurfaceUserManual.dox b/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkIsoSurfaceUserManual.dox index 1e8bb8c1f5..9e45f7e3fb 100644 --- a/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkIsoSurfaceUserManual.dox +++ b/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkIsoSurfaceUserManual.dox @@ -1,37 +1,37 @@ /** \page org_mitk_views_isosurface The Iso Surface Module -\image html IsoSurfaceIcon.png "Icon of the Module" +\imageMacro{IsoSurfaceIcon.png,"Icon of the Module",2.00} Available sections: - \ref QmitkIsoSurfaceUserManualOverview - \ref QmitkIsoSurfaceUserManualFeatures - \ref QmitkIsoSurfaceUserManualUsage - \ref QmitkIsoSurfaceUserManualTroubleshooting \section QmitkIsoSurfaceUserManualOverview Overview IsoSurface is a program module for creating surfaces (e.g. polygon structures) out of images. The user defines a threshold that seperates object and background inside the image. Pixels that belong to the object need grey values below the threshold. Pixles with grey values above the threshold will be ignored. The result is a polygon object that can be saved as an *.stl-object. \section QmitkIsoSurfaceUserManualFeatures Features - Creates a surface by thresholding an image \section QmitkIsoSurfaceUserManualUsage Usage How to create a surface: - Load an image into the program, for example by drag & drop - Look for a meaningful threshold. All pixel grey values of the image that are lower than the threshold will be used to create the surface. All grey values that are higher than the surface will be ignored. You can find the best threshold by using the Volumetry-Functionality or by reading the grey value while clicking on a pixel (see picture 2). - Insert the threshold into the GUI - Press the Button "Create Surface" -\image html IsoSurfaceGUI.png "Graphical User Interface of Iso Surface" +\imageMacro{IsoSurfaceGUI.png,"Graphical User Interface of Iso Surface",16.00} \section QmitkIsoSurfaceUserManualTroubleshooting Troubleshooting */ 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 2b1f8a2467..c738507ce7 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 -\image html regiongrowing.png "Icon of the View" +\imageMacro{regiongrowing.png,"Icon of the 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. 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.imaging/documentation/UserManual/QmitkSimpleExampleUserManual.dox b/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkSimpleExampleUserManual.dox index 12df11bc6d..26fd79a660 100644 --- a/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkSimpleExampleUserManual.dox +++ b/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkSimpleExampleUserManual.dox @@ -1,21 +1,21 @@ /** \page org_mitk_views_simpleexample The Simple Example module -\image html SimpleExample.png "Icon of the Module" +\imageMacro{SimpleExample.png,"Icon of the Module",2.00} \section QmitkSimpleExampleViewUserManualSummary Summary This module is namely a simple example for simple image interaction. It offers:
  • Sliders to navigate through the different slice stacks (Axial, Sagittal, Coronal) and the time steps
  • A "player" for image time series. It automatically steps through all time series with a speed defined by the slider on the right.
  • A button "Re-Initialize Navigators" to reinitialize those sliders to their initial position (Slice and time position 0)
  • A button "Take Screenshot" to take a screenshot of the chosen window (1=Transveral, 2=Sagittal, 3=Coronal, 4=3D View)
  • A button "Take HighDef 3D Screenshot" to take an high resolution screenshot of the 3D scene
  • A button "Generate Movie" whichs takes a movie of the chosen window by scrolling either through all slices (Axial, Sagittal, Coronal) or rotating the 3D scene
  • A selection box where the 3D view can be transformed into either a red-blue stereo or a D4D stereo view
*/ diff --git a/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkSimpleMeasurementUserManual.dox b/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkSimpleMeasurementUserManual.dox index f3aadf2c81..db9d300506 100644 --- a/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkSimpleMeasurementUserManual.dox +++ b/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/QmitkSimpleMeasurementUserManual.dox @@ -1,44 +1,44 @@ /** \page org_mitk_views_simplemeasurement The Simple Measurement Module -\image html SimpleMeasurementIcon.png "Icon of the Module" +\imageMacro{SimpleMeasurementIcon.png,"Icon of the Module",2.00} Available sections: - \ref QmitkSimpleMeasurementUserManualOverview - \ref QmitkSimpleMeasurementUserManualFeatures - \ref QmitkSimpleMeasurementUserManualUsage \section QmitkSimpleMeasurementUserManualOverview Overview SimpleMeasurement is a program module that allows to measure distances, angles and paths on a dataset. \section QmitkSimpleMeasurementUserManualFeatures Features
  • The SimpleMeasurement Module is able to measure:
    • Distances between two points
    • Angles between two lines (defined by three points)
    • Distances along a path
\section QmitkSimpleMeasurementUserManualUsage Usage To use the SimpleMeasurement Module, a data set must first be loaded. This can be done by drag & drop. Choose the simplemeasurement method you need by pressing the according button.
  • Points can be set by "shift-clicking" on the place in the data set.
  • Remove points by pressing the del-button on your keyboard.
  • You can mark a point by clicking on it with the cursor and moving it while the mouse button is still pressed.
What the different modes mean and how to use them:
  • Distances(a): To measure the distance between two points, you have to set two points. The distance will be displayed on the line between the points.
  • Angles(b): Angles can be measured between two lines. For that you have to set three points. The angle will be displayed between the two lines.
  • Path(c): Distances and angles along a path can be measured by setting at least two (for distance) or three (for angles) or more (for longer paths) points. The distance and the angles for each part will be displayed next to the path.
-\image html SimpleMeasurementGUI.png Graphical User Interface of SimpleMeasurement +\imageMacro{SimpleMeasurementGUI.png,"Graphical User Interface of SimpleMeasurement",16.00} */ diff --git a/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/org_mitk_gui_qt_viewinitialization.dox b/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/org_mitk_gui_qt_viewinitialization.dox index f192b11dd4..d6580e7e57 100644 --- a/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/org_mitk_gui_qt_viewinitialization.dox +++ b/Examples/Plugins/org.mitk.example.gui.imaging/documentation/UserManual/org_mitk_gui_qt_viewinitialization.dox @@ -1,8 +1,8 @@ /** \page org_mitk_views_viewinitialitzation The View Initialization Module -\image html viewInitializationIcon.png "Icon of the Module" +\imageMacro{viewInitializationIcon.png,"Icon of the Module",2.00} This view serves as a sandbox for understanding and experimenting with the geometry initialization parameters. For example, to view the axial slices from above instead of from below. It is not intended for end users, but for developers. */ \ No newline at end of file diff --git a/Examples/Plugins/org.mitk.example.gui.opencv/documentation/UserManual/VideoPlayerUserManual.dox b/Examples/Plugins/org.mitk.example.gui.opencv/documentation/UserManual/VideoPlayerUserManual.dox index dc7e5657b3..dfd99dd8f2 100644 --- a/Examples/Plugins/org.mitk.example.gui.opencv/documentation/UserManual/VideoPlayerUserManual.dox +++ b/Examples/Plugins/org.mitk.example.gui.opencv/documentation/UserManual/VideoPlayerUserManual.dox @@ -1,16 +1,16 @@ /** \page org_videoplayer The Video Player Module -\image html videoplayer.gif "Icon of the Module" +\imageMacro{videoplayer.gif,"Icon of the Module",2.00} Available sections: - \ref QmitkVideoPlayerUserManualOverview \section QmitkVideoPlayerUserManualOverview Overview VideoPlayer is a program module that allows to play video files or grab frames directly from a connected camera with an intuitive user interface. Its main purpose is to demonstrate the usage of the OpenCV toolkit in MITK. */ diff --git a/Modules/IGT/Documentation/doxygen/IGTTutorialStep1.dox b/Modules/IGT/Documentation/doxygen/IGTTutorialStep1.dox index e5f4313e39..c927a32024 100644 --- a/Modules/IGT/Documentation/doxygen/IGTTutorialStep1.dox +++ b/Modules/IGT/Documentation/doxygen/IGTTutorialStep1.dox @@ -1,46 +1,46 @@ /** \page IGTTutorialStep1 IGT filter pipeline The IGT tutorial consists of four main parts for construction of a small navigation pipeline using a virtual tracking device. The virtual tracking device produces random tool data (position and orientation) so no additional hardware is required. \section sec1 In Tracking Layer Firstly a new object "tracker" of the type mitk::VirtualTrackingDevice is created, then two tools, named "tool1" and "tool2", are added to this "tracker". Since, the tracking device "tracker" is treated as a virtual tracking device "tool1" and "tool2" are just added to the object by method AddTool(name). \section sec2 In Navigation Layer -\image html IGTTutorialStep1.png +\imageMacro{IGTTutorialStep1.png,"",15.90} Secondly, a new source of the type mitk::TrackingDeviceSource has to be created with outputs for each single tool of a tracker. The source sets the following tracking device by using method SetTrackingDevice as shown below \code source->SetTrackingDevice(tracker); \endcode So now, the source is initialized with the virtual tracking device. Next, the source is connected and tracking is started. In part II, a displacemt filter (object "displacer") is constructed to change the positions of the filtered NavigationData objects with an offset for each direction (X,Y,Z). The given filter has inputs and outputs for each tool, in this example we have 2 tools, hence there exists two inputs and outputs. Every output of the displacement filter object is connected to the recorder object in the next part. In part III, all the NavigationData is recorded with the NavigationDataRecorder. In order to record, we simply create an object "recorder" of the type mitk::NavigationDataRecorder and set the appropriate file to it. Now the displacer object is connected to the recorder object for every output by using a for-loop in the code, the method StartRecording() is called on the next line. Afterwards, the recorder has to be updated a couple of times. In this example the recorder is updating 100 times through the second for-loop statement in part III. This can also be seen as a simulation of a timer by using a for-loop. Part IV explains how the recoded file can be played for further use. After the object "player" of a type mitk::NavigationDataPlayer is created, the required file has to be set to the player and playing has to be started. Here, there exists a new pipeline which functions by reading the recorded file from the harddisc and plays it by using the player as source. During the play, the for-loop makes the file update as in part III. -\image html IGTTutorialStep1-2.png +\imageMacro{IGTTutorialStep1-2.png,"",9.53} The full code of small navigation pipeline is shown below and can be found in MITK-Source/Modules/IGT/Tutorial/mitkIGTTutorialStep1.cpp. This tutorial is an extra target which can be build separately. \include mitkIGTTutorialStep1.cpp \ref IGTTutorialStep2 "[Next step]" \ref IGTTutorialOverview "[IGT Tutorial Overview]" */ diff --git a/Modules/US/Documentation/doxygen/USModule.dox b/Modules/US/Documentation/doxygen/USModule.dox index b17c8e5a55..f7e12ec3e7 100644 --- a/Modules/US/Documentation/doxygen/USModule.dox +++ b/Modules/US/Documentation/doxygen/USModule.dox @@ -1,127 +1,127 @@ /** \page USModulePage The Ultrasound Module \section USModulePageOverview Overview The Ultrasound Module provides a microservice based API for ultrasound devices. The main features are:
  • Microservice-enabled life cycle management, allowing other modules to easily consume USDevice-functionality.
  • Handling and processing of ultrasound image data
  • Metadata for ultrasound images
  • USVideoDevice class which allows to connect any ultrasound device with a video-out via a Frame grabber
    • Fast image preprocessing capabilities (Grey Scale Conversion, Cropping) via OpenCV
    • Advanced image processing functions via mitk filters.
  • Connection of API-Enabled devices (specifically the Telemed LogicScan 128 is implemented)
    • Control of API-enabled Devices via MITK (Widgets for basic B mode controls and probe selection are available)
  • Designed to interact with the \link IGTGeneralModulePage IGT Module \endlink for tracking functionality.
This module requires OpenCV to be enabled in the superbuild options via CMAKE. Its functionality is made available to the User via the \link org_mitk_gui_qt_ultrasound UltrasoundSupport Plugin \endlink \section USDeviceHierarchy Ultrasound Device Hierarchy Ultrasound Devices are managed in a simple hierarchy: -\image html USHierarchy.png +\imageMacro{USHierarchy.png,"",14.92}
  • mitk::USDevice: The common superclass for all ultrasound devices. Deriving from this class will make sure that US-specific GUI-Components will be able to interact with your class. Especially, the Microservice Life cycle is modeled in this Module.
  • mitk::USVideoDevice: This class can be used for every Ultrasound device that is connected to the PC via a Frame grabber or similar Video input device. It offers image preprocessing functionality via OpenCV. The \link org_mitk_gui_qt_ultrasound UltrasoundSupport Plugin \endlink enables the user to create USVideoDevice. There also is a reusable Widget for this Task in the USUI Module.
  • mitk::USApiDevice: This is a work-in-progress class that will contain a common superclass for Devices with API support.
\section USDeviceLifeCycle USDevice Life Cycle Once you a USDevice is constructed, it can be connected via call to mitk::USDevice::Connect(). This will cause the Device to register itself in the Microservice Framework and will make the device available to other Modules, the UltrasoundSupport Plugin and the USDeviceManagerWidget in the USUI Module. The Connect() method is not virtual and should never be overwritten. Instead, override mitk::USDevice::OnConnect(), which will be called during the connection Process and enables you to react to this event. A connected device is available to other modules, but is not acquiring image data. Analogously to Connect, there is a function mitk::USDevice::Activate which will start the image acquisition. Again, this method is not virtual, override mitk::USDevice::OnActivate to react to activation. Matching functions mitk::USDevice::Disconnect(), mitk::USDevice::OnDisconnect, mitk::USDevice::Deactivate, mitk::USDevice::OnDeactivate exist as well. The following diagram illustrates the situation: -\image html USLifecycle.png +\imageMacro{USLifecycle.png,"",16.00} The blue message symbols indicate that the corresponding method of the subclass is called to react to the event. \section USControlInterfaces Control Interfaces for API Devices Capabilities of API-based ultrasound devices are available through control interfaces which are shown below: -\image html USControlInterfaces.png +\imageMacro{USControlInterfaces.png,"",16.00} The control interfaces mitk::USControlInterfaceProbes and mitk::USControlInterfaceBMode are available, while mitk::USControlInteraceDoppler is empty at the moment. Every sublcass of mitk::USDevice can use an implementation of each of these interfaces, but this is not necessary. The mitk::USVideoDevice for examples uses a custom control interface only, which is a subclass of mitk::USAbstractControlInterface. Each custom control interface needs its own Widget (subclassed of QmitkUSAbstractCustomWidget). For mitk::USControlInterfaceProbes, mitk::USControlInterfaceBMode and mitk::USControlInterfaceDoppler there are Widgets available in the USUI module (QmitkUSControlsProbesWidget, QmitkUSControlsBModeWidget, QmitkUSControlsDopplerWidget) which can be used by plugins. Each Widget must get an object of the corresponding control interface on its constructor call. A class diagram showing how the Widgets are connected to the control interfaces can be seen below: -\image html USControlWidgets.png +\imageMacro{USControlWidgets.png,"",16.00} A plugin can use the Widgets by creating a new object of the Widget and setting the corresponding interface object of the mitk::USDevice which should be controlled. How to use custom widgets is described in the class documentation of QmitkUSConcreteCustomWidget. \section USDWidgets Available Widgets There are some Widgets available that can be used for plugin development: a device management Widget, a Widget for creating new mitk::USVideoDevice objects and widgets for the control interfaces of API device. The usage of the Widgets is described in more detail in the \link org_mitk_gui_qt_ultrasound UltrasoundSupport Plugin Documentation\endlink. \subsection USQmitkUSDeviceManagerWidget QmitkUSDeviceManagerWidget The QmitkUSDeviceManagerWidget can view every connected mitk::USDevice and allows the user to activate and deactivate devices. Additionally mitk::USVideoDevice can be created using the QmitkNewVideoDeviceWidget and removed by a corresponding button. \subsection USQmitkNewVideoDeviceWidget QmitkNewVideoDeviceWidget The QmitkNewVideoDeviceWidget allows the user to configure a frame grabber or other video input as a mitk::USVideoDevice. \subsection USControlInterfaceWidgets Control Interface Widgets \section USHardwareTelemed Controlling API Devices of Telemed The features of ultrasound devices of Telemed can be controlled directly via the Ultrasound Module. At the moment, some controls for the b mode are implemented. The device used for development was the "Telemed LogicScan 128". A graphical user interface is integrated into the Ultrasound Plugin. \subsection USHardwareTelemedInstall Install the Telemed SDK The Telemed SDK cannot be shipped with MITK due to legal issues. Instead it can be obtained directly from Telemed. MITK was tested with API version 3.9.0 (2013-02-04). The following packages must be installed:
  • Telemed Drivers Package (MITK was tested with version 1.13.7)
  • Usgfw2 SDK Redistributable (usgfwsetup.exe)
For MITK the file "usgfw2.tlh" is needed. This file may be available in one of the examples folders of the SDK. If not it can be generated by compiling one of the delivered examples (samples_cpp_vs2005). \subsection USHardwareTelemedEnable Enable the Telemed API The Telemed API is available for Windows only and does not work with software compiled for 64 bit. Therefore, you need a 32 bit build of MITK on Windows. To use a Telemed device, activate the corresponding CMake flag: MITK_USE_US_TELEMED_SDK. After a run of CMake the new CMake variable MITK_US_TELEMED_SDK_PATH has to be set to a directory containing the header files of the Telemed SKD (from "SDK\include\USGFWSDK\include") and the file "usgfw2.tlh" (see previous section). Afterwards MITK can be configured and build as usual. \subsection USHardwareTelemedUse Use a Telemed device As soon as the ultrasound module is loaded the device will be made available as a microservice. It can be got from the service registry then and the Ultrasound Plugin shows the device as an available ultrasound device. */ \ No newline at end of file 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 d9a45cd542..6f079ca772 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 Plugin -\image html QmitkBasicImageProcessing_ImageProcessing_48.png "Icon of the Plugin" +\imageMacro{QmitkBasicImageProcessing_ImageProcessing_48.png,"Icon of the 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). -\image html QmitkBasicImageProcessing_BIP_Overview.png "MITK with the Basic Image Processing view" +\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 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. */ 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 b38c90d89b..079451836f 100644 --- a/Plugins/org.mitk.gui.qt.cmdlinemodules/documentation/UserManual/cmdlinemodules.dox +++ b/Plugins/org.mitk.gui.qt.cmdlinemodules/documentation/UserManual/cmdlinemodules.dox @@ -1,172 +1,172 @@ /** \page org_mitk_views_cmdlinemodules The Command Line Modules View -\image html cmdlinemodules_Icon.png "Icon of 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. \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 downloading the latest version (subversion commit 329) of the NiftyReg package, available here, and described further 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. \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. -\image html cmdlinemodules_Preferences.png "Figure 1. The Command Line Modules Preferences Page" +\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 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 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 "strict" 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 home directory: Scan the users home directory. (See QDir::homePath().) \li scan home directory/cli-modules: Scans the sub-directory called cli-modules under the users home directory. \li scan current directory: Scan the current working directory. (See QDir::homePath().) \li scan current directory/cli-modules: Scans the sub-directory called cli-modules under the current working directory. \li scan installation directory: This is the directory where the actual application is stored. \li scan installation directory/cli-modules: Scans the sub-directory called cli-modules under the application installation 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. -\image html cmdlinemodules_PreferencesAdditionalDirectories.png "Figure 2. The User can specify specific directories to scan". -\image html cmdlinemodules_PreferencesAdditionalModules.png "Figure 3. The User can specify specific command line programs to load". +\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. 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. -\image html cmdlinemodules_Initial.png "Figure 4. The initial interface, with no command line programs available." +\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. -\image html cmdlinemodules_WithPrograms.png "Figure 5. When valid paths are set, and programs are discovered, the menu is recalculated to show available programs." +\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. -\image html cmdlinemodules_NiftyReg.png "Figure 6. An example program, showing parameters for NiftyReg's program RegAladin." +\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 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. -\image html cmdlinemodules_F3D.png "Figure 7. Multiple tabs can be opened, one for each command line program." +\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. -\image html cmdlinemodules_NiftyRegRunning2.png "Figure 8. Multiple programs can be run, each with individual controls and console output." +\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 on-line 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: \li The doxygen generated manual page. \li The wiki page. and obviously the CTK code base. */ diff --git a/Plugins/org.mitk.gui.qt.datamanager/documentation/UserManual/QmitkDatamanager.dox b/Plugins/org.mitk.gui.qt.datamanager/documentation/UserManual/QmitkDatamanager.dox index 993e58aff3..d0df37f777 100644 --- a/Plugins/org.mitk.gui.qt.datamanager/documentation/UserManual/QmitkDatamanager.dox +++ b/Plugins/org.mitk.gui.qt.datamanager/documentation/UserManual/QmitkDatamanager.dox @@ -1,98 +1,98 @@ /** \page org_mitk_views_datamanager The DataManager -\image html QmitkDatamanager_Icon.png "Icon of the Module" +\imageMacro{QmitkDatamanager_Icon.png,"Icon of the Module",2.00} \tableofcontents \section QmitkDataManagerIntroduction Introduction The Datamanager is the central componenent to manage medical data like images, surfaces, etc.. After loading one or more data into the Datamanager the data are shown in the four-view window, the so called Standard View. The user can now start working on the data by just clicking into the standard view or by using the MITK-modules such as "Segmentation" or "Basic Image Processing". -\image html QmitkDatamanager_Overview.png "How MITK looks when started" +\imageMacro{QmitkDatamanager_Overview.png,"How MITK looks when started",16.00} \section QmitkDataManagerLoading Loading Data There are three ways of loading data into the Datamanager as so called Data-Elements. The user can just drag and drop data into the Datamanager or directly into one of the four parts of the Standard View. He can as well use the Open-Button in the right upper corner. Or he can use the standard "File->Open"-Dialog on the top. A lot of file-formats can be loaded into MITK, for example
  • 2D-images/3D-volumes with or without several timesteps (*.dcm, *.ima, *.pic, ...)
  • Surfaces (*.stl, *.vtk, ...)
  • Pointsets (*.mps)
  • ...
The user can also load a series of 2D images (e.g. image001.png, image002.png ...) to a MITK 3D volume. To do this, just drag and drop one of those 2D data files into the Datamanager by holding the ALT key. After loading one or more data into the Datamanager they appear as Data-Elements in a sorted list inside the Datamanager. Data-Elements can also be sorted hierarchically as a parent-child-relation. For example after using the Segmentation-Module on Data-Element1 the result is created as Data-Element2, which is a child of Data-Element1 (see Screenshot1). The order can be changed by drag and drop. -\image html QmitkDatamanager_ParentChild.png "Screenshot1" +\imageMacro{QmitkDatamanager_ParentChild.png,"Screenshot1",9.61} The listed Data-Elements are shown in the standard view. Here the user can scale or rotate the medical objects or he can change the cutting planes of the object by just using the mouse inside this view. \section QmitkDataManagerSaving Saving Data There are two ways of saving data from the Datamanger. The user can either save the whole project with all Data-Elements by clicking on "File"->"Save Project" or he can save single Data-Elements by right-clicking->"Save", directly on a Data-Element. When saving the whole project, the sorting of Data-Elements is saved as well. By contrast the sorting is lost, when saving a single Data-Element. \section QmitkDataManagerProperties Working with the Datamanager \subsection QmitkDataManagerPropertiesList List of Data-Elements The Data-Elements are listed in the Datamanager. As described above the elements can be sorted hierarchically as a parent-child-relation. For example after using the Segmentation-Module on Data-Element1 the result is created as Data-Element2, which is a child of Data-Element1 (see Screenshot1). By drag and drop the sorting of Data-Elements and their hierarchical relation can be changed. \subsection QmitkDataManagerPropertiesVisibility Visibility of Data-Elements By default all loaded Data-Elements are visible in the standard view. The visibility can be changed by right-clicking on the Data-Element and then choosing "Toogle visibility". The box in front of the Data-Element in the Datamanager shows the visibility. A green-filled box means a visible Data-Element, an empty box means an invisible Data-Element (see Screenshot1). \subsection QmitkDataManagerPropertiesRepresentation Representation of Data-Elements There are different types of representations how to show the Data-Element inside the standard view. By right-clicking on the Data-Element all options are listed (see Screenshot2 and Screenshot 3).
  • An arbitrary color can be chosen
  • The opacity can be changed with a slide control
  • In case of images a texture interpolation can be switched on or off. The texture interpolation smoothes the image, so that no single pixels are visible anymore.
  • In case of surfaces the surface representation can be changed between points, wireframe or surface.
  • Global reinit updates all windows to contain all the current data. Reinit updates a single data item fits the windows to contain this data item.
-\image html QmitkDatamanager_ImageProperties.png "Screenshot2: Properties for images" -\image html QmitkDatamanager_SurfaceProperties.png "Screenshot3: Properties for surfaces" +\imageMacro{QmitkDatamanager_ImageProperties.png,"Screenshot2: Properties for images",10.56} +\imageMacro{QmitkDatamanager_SurfaceProperties.png,"Screenshot3: Properties for surfaces",11.01} \subsection QmitkDataManagerPropertiesPreferences Preferences For the datamanager there are already some default hotkeys like the del-key for deleting a Data-Element. The whole list is seen in Screenshot4. From here the Hotkeys can also be changed. The preference page is found in "Window"->"Preferences". -\image html QmitkDatamanager_Preferences.png "Screenshot4" +\imageMacro{QmitkDatamanager_Preferences.png,"Screenshot4",16.00} \section QmitkDataManagerPropertyList Property List The Property List displays all the properties the currently selected Data-Element has. Which properties these are depends on the Data-Element. Examples are opacity, shader, visibility. These properties can be changed by clicking on the appropriate field in the "value" column. -\image html QmitkDatamanager_PropertyList.png "Screenshot5: Property List" +\imageMacro{QmitkDatamanager_PropertyList.png,"Screenshot5: Property List",7.85} */ diff --git a/Plugins/org.mitk.gui.qt.dicom/documentation/UserManual/QmitkDicom.dox b/Plugins/org.mitk.gui.qt.dicom/documentation/UserManual/QmitkDicom.dox index 03f4649f38..e0bbb8306a 100644 --- a/Plugins/org.mitk.gui.qt.dicom/documentation/UserManual/QmitkDicom.dox +++ b/Plugins/org.mitk.gui.qt.dicom/documentation/UserManual/QmitkDicom.dox @@ -1,118 +1,118 @@ /** \page org_mitk_gui_qt_dicom The Dicom Plugin -\image html QmitkDicom_Icon.png "Icon of Dicom" +\imageMacro{QmitkDicom_Icon.png,"Icon of Dicom",2.00} \note This article requires a basic knowledge of DICOM. \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. \section org_mitk_gui_qt_dicomDataHandling Data handling -\image html QmitkDicom_PluginControls.png "The dicom Plugin controls" +\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 -\image html QmitkDicom_PluginExtended.png "The DICOM 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. -\image html QmitkDicom_DisplayDataManager.png "Viewed image" +\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 -\image html QmitkDicom_ImportDialog.png "The import dialog checked" +\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. -\image html QmitkDicom_QueryRetrieve.png "The query retrieve screen" +\imageMacro{QmitkDicom_QueryRetrieve.png,"The query retrieve screen",16.00} \subsection org_mitk_gui_qt_dicomQuery Query -\image html QmitkDicom_Nodes.png "The DICOM network configuration" +\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. -\image html QmitkDicom_FilterWidget.png "The DICOM search options" +\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 -\image html QmitkDicom_Retrieve.png "The queried DICOM data." +\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.diffusionimaging/documentation/UserManual/Connectomics/ConnectomicsManual.dox b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/Connectomics/ConnectomicsManual.dox index fa344b2985..37b67bad2d 100644 --- a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/Connectomics/ConnectomicsManual.dox +++ b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/Connectomics/ConnectomicsManual.dox @@ -1,108 +1,108 @@ /** \page org_mitk_diffusionimagingapp_perspectives_connectomics The Connectomics Perspective -\image html connectomics_perspective.png "Icon of the Perspective" +\imageMacro{connectomics_perspective.png,"Icon of the Perspective",2.00} The connectomics perspective is a collection of views which provide functionality for the work with brain connectivity networks. Currently there exist the following views: \subpage org_mitk_views_connectomicsdata provides network generation either from data or synthetically. \subpage org_mitk_views_connectomicsnetworkoperations provides functionalies to operate and process on networks and other data. \subpage org_mitk_views_connectomicsstatistics provides statistical measures for networks. \section org_mitk_diffusionimagingapp_perspectives_connectomicsNetworkRenderingCustomization Network Rendering Customization The rendering of the connectomics networks can be customized by changing the associated properties using the property list. A selection of possible options are:
  • Connectomics.Rendering.Edges.Filtering - Only render edges above a certain threshold
  • Connectomics.Rendering.Edges.Gradient.Parameter - Color the edges according to certain parameters
  • Connectomics.Rendering.Edges.Radius.Parameter - Change the radius of the edges according to certain parameters
  • Connectomics.Rendering.Nodes.Filtering - Only render nodes above a certain threshold
  • Connectomics.Rendering.Nodes.Gradient.Parameter - Color the nodes according to certain parameters
  • Connectomics.Rendering.Nodes.Radius.Parameter - Change the radius of the nodes according to certain parameters
  • Connectomics.Rendering.Scheme - Switch between the MITK rendering scheme using above properties and the very fast, but less customizable rendering scheme for VTK graphs
\section org_mitk_diffusionimagingapp_perspectives_connectomicsTrouble Troubleshooting No known problems. All other problems.
Please report to the MITK mailing list. See http://www.mitk.org/wiki/Mailinglist on how to do this. */ /** \page org_mitk_views_connectomicsdata The Connectomics Network Data View -\image html QmitkConnectomicsDataViewIcon_48.png "Icon of the View" +\imageMacro{QmitkConnectomicsDataViewIcon_48.png,"Icon of the View",2.00} This view can be used to create a network from a parcellation and a fiber image as well as to create synthetic networks. -\image html dataview.png "The user interface" +\imageMacro{dataview.png,"The user interface",4.85} To create a network select first a parcellation of the brain (e.g. as provided by freesurfer ) by CTRL+Leftclick and secondly a fiber image ( as created using a tractography view). Then click on the "Create Network" button.
  • "Use label of end position of fibers" will create a network containing a node for every label a fiber ends in
  • "Extrapolate label" will avoid creating nodes using FreeSurfer white matter labels and instead extrapolate in which grey matter label the fiber would end
Additionally you have the option to create artificial networks, for testing purposes. Currently choices are:
  • A regular lattice, where each node is placed in a cubic pattern and only connected to its neighbours
  • A heterogenic sphere, where one node is placed in the center and connected to all nodes on the shell
  • A random network, where nodes are randomly placed on a spherical shell and randomly connected
*/ /** \page org_mitk_views_connectomicsnetworkoperations The Connectomics Network Operations View -\image html QmitkConnectomicsNetworkOperationsViewIcon_48.png "Icon of the View" +\imageMacro{QmitkConnectomicsNetworkOperationsViewIcon_48.png,"Icon of the View",2.00} This view can be used modify networks and related data. -\image html operationsview.png "The user interface" +\imageMacro{operationsview.png,"The user interface",4.61} Select a parcellation and press "Convert to RGBA" to create a RGBA image. By doing this conversion it is much easier to discern the different parcels. Furthermore MITK supports 3D visualization of an RGBA image. Select a network and press "Create Connectivity Matrix Image" to create a 2D image of the connectivity matrix. By default the weight of a connection is used as grey value. Using the "Rescale" option will rescale the weights so highest one is 255. Using the "Binary" option will result in a binary connectivity matrix. */ /** \page org_mitk_views_connectomicsstatistics The Connectomics Statistics View -\image html QmitkConnectomicsStatisticsViewIcon_48.png "Icon of the View" +\imageMacro{QmitkConnectomicsStatisticsViewIcon_48.png,"Icon of the View",2.00} This view can be used to show statistical analysis of a network. -\image html statisticsview.png "The user interface" +\imageMacro{statisticsview.png,"The user interface",6.58} To calculate network statistics select a network in the datamanager. At this time the following statistics are calculated for the entire network:
  • The number of vertices in the network
  • The number of edges in the network
  • The number of edges which have the same vertex as beginning and end point
  • The average degree of the nodes in the network
  • The connection density the network (the number of edges divided by the number of possible edges)
  • The unweighted efficiency of the network ( 1 divided by average path length, this is zero for disconnected graphs)
  • The global clustering
Furthermore some statistics are calculated on a per node basis and displayed as histograms:
  • The degree of each node
  • The (unweighted) betweenness centrality of each node
  • The spread of shortest paths between each pair of nodes (For disconnected graphs the shortest paths with infinite length are omitted for readability)
*/ diff --git a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkDenoisingViewUserManual.dox b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkDenoisingViewUserManual.dox index 7adb65fd1a..0e0dc1f9d7 100644 --- a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkDenoisingViewUserManual.dox +++ b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkDenoisingViewUserManual.dox @@ -1,62 +1,62 @@ /** \page org_mitk_views_denoisingview DWI Denoising This view provides the user interface to denoise a diffusion weighted image (DWI) with several methods. Available sections: - \ref DwiDenoisingUserManualInputData - \ref DwiDenoisingUserManualOutputData - \ref DwiDenoisingUserManualNonLocalMeans - \ref DwiDenoisingUserManualDiscreteGaussian - \ref DwiDenoisingUserManualReferences \section DwiDenoisingUserManualInputData Input Data Mandatory Input: \li Diffusion weigthed image Optional Input: \li Binary mask to define a denoising area. \section DwiDenoisingUserManualOutputData Output Data \li Denoised DWI: if a mask is set for denoising, all voxel excluding the masked area are set to 0. \section DwiDenoisingUserManualNonLocalMeans Non-local means filter Denoise the input DWI using a non local means algorithm. For more details refer to [1] and [2]. Parameters: \li Searchradius: defines the size of the neighborhood V (Fig. 1 b)) in which the voxels will be weighted to reconstruct the center voxel. The resulting neighborhood size is defined as 2x searchradius + 1 (e.g. a searchradius of 1 generates a neighborhood cube with size 3x3x3). \li Comparisonradius: defines the size of the compared neighborhoods N (Fig. 1 b)) around each voxel. The resulting neighborhood size is defined as 2x comaprisonradius + 1 (e.g. a comparisonradius of 1 generates a neighborhood cube with size 3x3x3). \li Noise variance: the variance of the noise need to be set for filtering. An estimation of the noise varinace will be implemented soon. \li Rician adaption: if checked the non-local means uses an adaption for Rician distributed noise. \li Joint information: if checked the whole DWI is seen as a vector image, weighting each voxels complete vector, instead of weighting each channel seperate. (This might be a bit faster, but is less accurate) -\image html NLM.png Fig. 1: a) View using the Non-local means filter b) 2D illustration of the Non-local means principle [1] +\imageMacro{NLM.png,"Fig. 1: a) View using the Non-local means filter b) 2D illustration of the Non-local means principle [1]",16.00} \section DwiDenoisingUserManualDiscreteGaussian Discrete gaussian filter Denoise the input DWI using a discrete gaussian filter. Parameters: \li Variance: defines the varinance of the gaussian distribution to denoise the image. -\image html GaussianFilter.png Fig. 2: View using the discrete gaussian filter +\imageMacro{GaussianFilter.png,"Fig. 2: View using the discrete gaussian filter",8.04} \section DwiDenoisingUserManualReferences References [1] Wiest-Daesslé et al. Non-Local Means Variants for Denoising of Diffusion-Weigthed and Diffusion Tensor MRI. MICCAI 2007, Part II, LNCS 4792, pp- 344-351. [2] Wiest-Daesslé et al. Rician Noise Removal by Non-Local Means Filtering for Low Signal-to-Noise Ratio MRI: Applications to DT-MRI. MICCAI 2008, Part II, LNCS 5242, pp. 171-179. */ diff --git a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkDiffusionImagingUserManual.dox b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkDiffusionImagingUserManual.dox index 0b01f058f6..858a56f983 100644 --- a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkDiffusionImagingUserManual.dox +++ b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkDiffusionImagingUserManual.dox @@ -1,133 +1,133 @@ /** \page org_mitk_gui_qt_diffusionimaging MITK Diffusion Imaging (MITK-DI) \tableofcontents This module provides means to diffusion weighted image reconstruction, visualization and quantification. Diffusion tensors as well as different q-ball reconstruction schemes are supported. Q-ball imaging aims at recovering more detailed information about the orientations of fibers from diffusion MRI measurements and, in particular, to resolve the orientations of crossing fibers. \section QmitkDiffusionImagingUserManualIssues Known Issues \li Dicom Import: The dicom import has so far only been implemented for Siemens dicom images. MITK-DI is capable of reading the nrrd format, which is documented elsewhere [1, 2]. These files can be created by combining the raw image data with a corresponding textual header file. The file extension should be changed from *.nrrd to *.dwi or from *.nhdr to *.hdwi respectively in order to let MITK-DI recognize the diffusion related header information provided in the files. \section QmitkDiffusionImagingUserManualPreprocessing Preprocessing The preprocessing view gives an overview over the important features of a diffusion weighted image like the number of gradient directions, b-value and the measurement frame. Additionally it allows the extraction of the B0 image, reduction of gradient directions and the generation of a binary brain mask. The image volume can be modified by applying a new mesurement frame, which is useful if the measurement frame is not set correctly in the image header, or by averaging redundant gradient directions. -\image html prepro1.png Preprocessing +\imageMacro{prepro1.png,"Preprocessing",9.97} \section QmitkDiffusionImagingUserManualTensorReconstruction Tensor Reconstruction The tensor reconstruction view allows ITK based tensor reconstruction [3]. The advanced settings for ITK reconstruction let you configure a manual threshold on the non-diffusion weighted image. All voxels below this threshold will not be reconstructed and left blank. It is also possible to check for negative eigenvalues. The according voxels are also left blank. -\image html tensor1.png ITK tensor reconstruction +\imageMacro{tensor1.png,"ITK tensor reconstruction",9.97} A few seconds (depending on the image size) after the reconstruction button is hit, a colored image should appear in the main window. -\image html tensor4.png Tensor image after reconstruction +\imageMacro{tensor4.png,"Tensor image after reconstruction",16.00} To assess the quality of the tensor fit it has been proposed to calculate the model residual [9]. This calculates the residual between the measured signal and the signal predicted by the model. Large residuals indicate an inadequacy of the model or the presence of artefacts in the signal intensity (noise, head motion, etc.). To use this option: Select a DWI dataset, estimate a tensor, select both the DWI node and the tensor node in the datamanager and press Residual Image Calculation. MITK-Diffusion can show the residual for every voxel averaged over all volumes or (in the plot widget) summarized per volume or for every slice in every volume. Clicking in the widget where the residual is shown per slice will automatically let the cross-hair jump to that position in the DWI dataset. If Percentage of outliers is checked, the per volume plot will show the percentage of outliers per volume. Otherwise it will show the mean together with the first and third quantile of residuals. See [9] for more information. -\image html residuals.png The residual widget +\imageMacro{residuals.png,"The residual widget",16.00} The view also allows the generation of artificial diffusion weighted or Q-Ball images from the selected tensor image. The ODFs of the Q-Ball image are directly initialized from the tensor values and afterwards normalized. The diffusion weighted image is estimated using the l2-norm image of the tensor image as B0. The gradient images are afterwards generated using the standard tensor equation. \section QmitkDiffusionImagingUserManualQBallReconstruction Q-Ball Reconstruction The q-ball reonstruction view implements a variety of reconstruction methods. The different reconstruction methods are described in the following: \li Numerical: The original, numerical q-ball reconstruction presented by Tuch et al. [5] \li Standard (SH): Descoteaux's reconstruction based on spherical harmonic basis functions [6] \li Solid Angle (SH): Aganj's reconstruction with solid angle consideration [7] \li ADC-profile only: The ADC-profile reconstructed with spherical harmonic basis functions \li Raw signal only: The raw signal reconstructed with spherical harmonic basis functions -\image html qballs1.png The q-ball resonstruction view +\imageMacro{qballs1.png,"The q-ball resonstruction view",9.99} B0 threshold works the same as in tensor reconstruction. The maximum l-level configures the size of the spherical harmonics basis. Larger l-values (e.g. l=8) allow higher levels of detail, lower levels are more stable against noise (e.g. l=4). Lambda is a regularisation parameter. Set it to 0 for no regularisation. lambda = 0.006 has proven to be a stable choice under various settings. -\image html qballs2.png Advanced q-ball reconstruction settings +\imageMacro{qballs2.png,"Advanced q-ball reconstruction settings",8.00} This is how a q-ball image should initially look after reconstruction. Standard q-balls feature a relatively low GFA and thus appear rather dark. Adjust the level-window to solve this. -\image html qballs3.png q-ball image after reconstruction +\imageMacro{qballs3.png,"q-ball image after reconstruction",16.00} \section QmitkDiffusionImagingUserManualDicomImport Dicom Import The dicom import does not cover all hardware manufacturers but only Siemens dicom images. MITK-DI is also capable of reading the nrrd format, which is documented elsewhere [1, 2]. These files can be created by combining the raw image data with a corresponding textual header file. The file extension should be changed from *.nrrd to *.dwi or from *.nhdr to *.hdwi respectively in order to let MITK-DI recognize the diffusion related header information provided in the files. In case your dicom images are readable by MITK-DI, select one or more input dicom folders and click import. Each input folder must only contain DICOM-images that can be combined into one vector-valued 3D output volume. Different patients must be loaded from different input-folders. The folders must not contain other acquisitions (e.g. T1,T2,localizer). In case many imports are performed at once, it is recommended to set the the optional output folder argument. This prevents the images from being kept in memory. -\image html dicom1.png Dicom import +\imageMacro{dicom1.png,"Dicom import",9.59} The option "Average duplicate gradients" accumulates the information that was acquired with multiple repetitions for one gradient. Vectors do not have to be precisely equal in order to be merged, if a "blur radius" > 0 is configured. \section QmitkDiffusionImagingUserManualFslImport FSL Import FSL diffusion data can be imported with MITK Diffusion. FSL diffusion datasets consist of 3 files: a nifty file (filename.nii.gz or filename.nii), a bvecs file (filename.bvecs), which is a text file containing the gradient vectors, and a bvals file (filename.bvecs), containing the b-values. Due to the system that selects suitable file readers, MITK will not recognize these files as diffusion datasets. In order to make MITK recognize it as diffusion, the extension must be changed from .nii.gz to .fslgz (so the new name is filename.fslgz) or from filename.nii to filename.fsl. The bvecs and bvals files have to be renamed as well(to filename.fsl.bvecs/filenames.fsl.bvecs or to filename.fslgz.bvecs/filename.fslgz.bvals). MITK can also save diffusion weighted images in FSL format. To do this the extension of the new file should be changed to .fsl or .fslgz upon saving the file. -\image html fslsave.png Save a dwi dataset as fsl +\imageMacro{fslsave.png,"Save a dwi dataset as fsl",16.00} \section QmitkDiffusionImagingUserManualQuantification Quantification The quantification view allows the derivation of different scalar anisotropy measures for the reconstructed tensors (Fractional Anisotropy, Relative Anisotropy, Axial Diffusivity, Radial Diffusivity) or q-balls (Generalized Fractional Anisotropy). -\image html quantification.png Anisotropy quantification +\imageMacro{quantification.png,"Anisotropy quantification",9.17} \section QmitkDiffusionImagingUserManualVisualizationSettings ODF Visualization Setting In this small view, the visualization of ODFs and diffusion images can be configured. Depending on the selected image in the data storage, different options are shown here. For tensor or q-ball images, the visibility of glyphs in the different render windows (T)ransversal, (S)agittal, and (C)oronal can be configured here. The maximal number of glyphs to display can also be configured here for. This is usefull to keep the system response time during rendering feasible. The other options configure normalization and scaling of the glyphs. In diffusion images, a slider lets you choose the desired image channel from the vector of images (each gradient direction one image) for rendering. Furthermore reinit can be performed and texture interpolation toggled. This is how a visualization with activated glyphs should look like: -\image html visualization3.png Q-ball image with ODF glyph visibility toggled ON +\imageMacro{visualization3.png,"Q-ball image with ODF glyph visibility toggled ON",16.00} \section QmitkDiffusionImagingUserManualReferences References 1. http://teem.sourceforge.net/nrrd/format.html 2. http://www.cmake.org/Wiki/Getting_Started_with_the_NRRD_Format 3. C.F.Westin, S.E.Maier, H.Mamata, A.Nabavi, F.A.Jolesz, R.Kikinis, "Processing and visualization for Diffusion tensor MRI", Medical image Analysis, 2002, pp 93-108 5. Tuch, D.S., 2004. Q-ball imaging. Magn Reson Med 52, 1358-1372. 6. Descoteaux, M., Angelino, E., Fitzgibbons, S., Deriche, R., 2007. Regularized, fast, and robust analytical Q-ball imaging. Magn Reson Med 58, 497-510. 7. Aganj, I., Lenglet, C., Sapiro, G., 2009. ODF reconstruction in q-ball imaging with solid angle consideration. Proceedings of the Sixth IEEE International Symposium on Biomedical Imaging Boston, MA. 8. Goh, A., Lenglet, C., Thompson, P.M., Vidal, R., 2009. Estimating Orientation Distribution Functions with Probability Density Constraints and Spatial Regularity. Med Image Comput Comput Assist Interv Int Conf Med Image Comput Comput Assist Interv LNCS 5761, 877 ff. 9. J.-D. Tournier, S. Mori, A. Leemans., 2011. Diffusion Tensor Imaging and Beyond. Magn Reson Med 65, 1532-1556. \section QmitkDiffusionImagingUserManualTechnicalDetail Technical Information for Developers The diffusion imaging module uses additional properties beside the ones in use in other modules, for further information see \ref DiffusionImagingPropertiesPage . \section QmitkDiffusionImagingUserManualSubManuals Manuals of componentes The MITK Diffusion tools consist of further components, which have their own documentation, see: \li \subpage org_mitk_views_fiberprocessing \li \subpage org_mitk_views_gibbstracking \li \subpage org_mitk_views_odfdetails \li \subpage org_mitk_views_partialvolumeanalysisview \li \subpage org_mitk_views_screenshotmaker \li \subpage org_mitk_views_stochasticfibertracking \li \subpage org_mitk_views_ivim \li \subpage org_mitk_diffusionimagingapp_perspectives_connectomics \li \subpage org_mitk_views_tractbasedspatialstatistics \li \subpage org_mitk_views_fiberextraction \li \subpage org_mitk_views_fiberprocessing \li \subpage org_mitk_views_odfmaximaextraction \li \subpage org_mitk_views_streamlinetracking \li \subpage org_mitk_views_fiberfoxview \li \subpage org_mitk_views_fieldmapgenerator \li \subpage org_mitk_views_denoisingview */ diff --git a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkFieldmapGeneratorViewUserManual.dox b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkFieldmapGeneratorViewUserManual.dox index ae16bdf3ab..4c972ccea3 100644 --- a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkFieldmapGeneratorViewUserManual.dox +++ b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkFieldmapGeneratorViewUserManual.dox @@ -1,16 +1,16 @@ /** \page org_mitk_views_fieldmapgenerator Fieldmap Generator View This view allows the creation of artificial frequency maps used by Fiberfox to introduce distortions into diffusion weighted images. The generated images can contain a linear frequency gradient and/or multiple 3D gaussian shaped field inhomogeneities. Example: \li Select a reference image with the combo box. The generated fieldmap will feature the same geometry as the selected image. \li Move the crosshair to the any position in the image and click "Place Field Source". \li A position marker will appear in the render windows and in the datamanager, which indicates the position of a 3D gaussian field distortion that will be introduced upon clicking "Generate Fieldmap". \li The strength and variance of the placed sources can be modified by selecting the corresponding data node in the data manager and adjusting the parameters in the lower part of the view (below "Edit Selected Source"). \li To introduce an (additional) linear frequency gradient, specify the gradient below "Add Gradient". \li To finally generate the fieldmap, press "Generate Fieldmap". -\image html fieldmapGenerator.png The Fieldmap Generator View. The render window shows a diffusion weighted image of the brain superimposed by a frequency map with two 3D gaussian field inhomogeneities (red). +\imageMacro{fieldmapGenerator.png,"The Fieldmap Generator View. The render window shows a diffusion weighted image of the brain superimposed by a frequency map with two 3D gaussian field inhomogeneities (red).",16.00} */ diff --git a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkGibbsTrackingViewUserManual.dox b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkGibbsTrackingViewUserManual.dox index dfcb7041ec..c3790e2d0a 100644 --- a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkGibbsTrackingViewUserManual.dox +++ b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkGibbsTrackingViewUserManual.dox @@ -1,40 +1,40 @@ /** \page org_mitk_views_gibbstracking Gibbs Tracking View This view provides the user interface for the Gibbs Tracking algorithm, a global fiber tracking algorithm, originally proposed by Reisert et.al. [1]. \tableofcontents -\image html gibbstrackingview.png The Gibbs Tracking View +\imageMacro{gibbstrackingview.png,"The Gibbs Tracking View",10.12} \section QmitkGibbsTrackingUserManualInputData Input Data Mandatory Input: \li One Q-Ball or tensor image selected in the datamanager Optional Input: \li Mask Image: White matter probability mask. Corresponds to the probability to generate fiber segments in the respective voxel. \section QmitkGibbsTrackingUserManualParameters Q-Ball Reconstruction \li Number of iterations: More iterations causes the algorithm to be more stable but also to take longer to finish the tracking. Recommended: 10^7 to 10^8 iterations. \li Particle length/width/weight controlling the contribution of each particle to the model M \li Start and end temperature controlling how fast the process reaches a stable state. (usually no change needed) \li Weighting between the internal (affinity of the model to long and straigt fibers) and external energy (affinity of the model towards the data). (usually no change needed). \li Minimum fiber length constraint (in mm). Shorter fibers are discarded after the tracking. The automatic selection of parameters for the particle length/width and weight are determined directly from the input image using information about the image spacing and GFA. -\image html gibbstrackingviewadvanced.png Advanced Tracking Parameters +\imageMacro{gibbstrackingviewadvanced.png,"Advanced Tracking Parameters",10.08} \section QmitkGibbsTrackingUserManualTrackingSurveillance Surveilance of the tracking process Once started, the tracking can be monitored via the textual output that informs about the tracking progress and several stats of the current state of the algorithm. If enabled, the intermediate tracking results are displayed in the renderwindows each second. This live visualization should usually be disabled for performance reasons. It can be turned on and off during the tracking process via the according checkbox. The button next to this checkbox allows the visualization of only the next iteration step. \section QmitkGibbsTrackingUserManualReferences References [1] Reisert, M., Mader, I., Anastasopoulos, C., Weigel, M., Schnell, S., Kiselev, V.: Global fiber reconstruction becomes practical. Neuroimage 54 (2011) 955-962 */ diff --git a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkOdfDetailsViewUserManual.dox b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkOdfDetailsViewUserManual.dox index f54439baa9..96495480d4 100644 --- a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkOdfDetailsViewUserManual.dox +++ b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkOdfDetailsViewUserManual.dox @@ -1,8 +1,8 @@ /** \page org_mitk_views_odfdetails ODF Details View This view provides detailed information about the orentation distribution function at the current crosshair position (if a Tensor/Q-Ball image is selected). A visualization of the ODF as well as statistical information are displayed. -\image html odfdetails.png The Gibbs Tracking View +\imageMacro{odfdetails.png,"The Gibbs Tracking View",10.01} */ diff --git a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkOdfMaximaExtractionViewUserManual.dox b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkOdfMaximaExtractionViewUserManual.dox index 812a4aad90..88ae74b3bf 100644 --- a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkOdfMaximaExtractionViewUserManual.dox +++ b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkOdfMaximaExtractionViewUserManual.dox @@ -1,49 +1,49 @@ /** \page org_mitk_views_odfmaximaextraction Peak Extraction View This view provides the user interface to extract the peaks of tensors and the spherical harmonic representation of Q-Balls. Available sections: - \ref OdfMaxUserManualInputData - \ref OdfMaxUserManualOutputData - \ref OdfMaxUserManualMethods - \ref OdfMaxUserManualParameters - \ref OdfMaxUserManualReferences \section OdfMaxUserManualInputData Input Data Mandatory Input: \li DTI image or image containing the spherical harmonic coefficients. The SH coefficient images can be obtain from the Q-Ball reconstruction view by enabling the checkbox in the advanced options. Optional Input: \li Binary mask to define the extraction area. \section OdfMaxUserManualOutputData Output Data \li Vector field: 3D representation of the resulting peaks. Only for visualization purposes (the peaks are scaled additionally to the specified normalization to improve the visualization)! \li #Directions per Voxel: Image containing the number of extracted peaks per voxel as image value. \li Direction Images: One image for each of the extracted peaks per voxel. Each voxel contains one direction vector as image value. Use this output for evaluation purposes of the extracted peaks. \section OdfMaxUserManualMethods Peak Extraction Methods \li If a tensor image is used as input, the output is simply the largest eigenvector of each voxel. \li The finite differences extraction uses a higly sampled version of the image ODFs, extracts all local maxima and clusters the resulting directions that point in a similar direction. \li For details about the analytical method (experimental) please refer to [1]. -\image html crossingmaxima.png Peaks of a fiber crossing extracted using finite differences method. +\imageMacro{crossingmaxima.png,"Peaks of a fiber crossing extracted using finite differences method.",10.12} \section OdfMaxUserManualParameters Input Parameters \li Vector normalization method (no normalization, maximum normalization of the vecors of one voxel and independent normalization of each vecor). \li SH Order: Specify the order of the spherical harmonic coefficients. \li Maximum number of peaks to extract. If more peaks are found only the largest are kept. \li Threshold to discard small peaks. Value relative to the largest peak of the respective voxel. \li Absolute threshold on the peak size. To evaluate this threshold the peaks are additionally weighted by their GFA (low GFA voxels are more likely to be discarded). This threshold is only used for the finite differences extraction method. \section OdfMaxUserManualReferences References [1] Aganj et al. Proceedings of the Thirteenth International Conference on Medical Image Computing and Computer Assisted Intervention 2010 */ diff --git a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkPartialVolumeAnalysisViewManual.dox b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkPartialVolumeAnalysisViewManual.dox index 67f42a982a..cf1a997015 100644 --- a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkPartialVolumeAnalysisViewManual.dox +++ b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkPartialVolumeAnalysisViewManual.dox @@ -1,25 +1,25 @@ /** \page org_mitk_views_partialvolumeanalysisview Partial Volume Analysis The "Partial Volume Analysis" view can be found in the "Quantification" perspective. It allows for robust quantification of diffusion or other scalar measures in the presents of two classes (e.g. fiber vs. non-fiber) and partial volume between them. The algorithm estimates a probabilistic segmentation of the three classes and returns a weighted average of the measure of interest within the each class. -\image html pvanalysisview.png The Partial Volume Analysis View +\imageMacro{pvanalysisview.png,"The Partial Volume Analysis View",16.00} \section QmitkPVAAnalysisUserManualExport Export All measures are automatically written to the clipboard once the estimation is updated. For scalar images, the mean and the variance of the gaussian selected in the radio-box above is copied out. If 'All' is selected, then all means and variances are carried out as a tab-separated list. For tensor images, the values for all scalar measures (FA, MD, RD and AD) are carried out to the clipboard. The histogram export is provided by the button underneath the histogram. The values can be pasted to excel or any text editor. \section QmitkPVAAnalysisUserManualAdvancedSettings Advanced Settings Are not recommended for use yet. \section QmitkPVAAnalysisUserManualSuggestedReadings Suggested Readings Diffusion tensor imaging in primary brain tumors: reproducible quantitative analysis of corpus callosum infiltration and contralateral involvement using a probabilistic mixture model. Stieltjes B, Schlüter M, Didinger B, Weber MA, Hahn HK, Parzer P, Rexilius J, Konrad-Verse O, Peitgen HO, Essig M. Neuroimage. 2006 Jun;31(2):531-42. Epub 2006 Feb 14. PMID: 16478665 */ diff --git a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkStochasticTrackingViewUserManual.dox b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkStochasticTrackingViewUserManual.dox index 0ed40d2add..e77a8039f8 100644 --- a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkStochasticTrackingViewUserManual.dox +++ b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkStochasticTrackingViewUserManual.dox @@ -1,31 +1,31 @@ /** \page org_mitk_views_stochasticfibertracking Stochastic Tracking View This view provides the user interface for the Stochastic Fibertracking algorithm, proposed by Ngo [1]. Available sections: - \ref QmitkStochasticTrackingUserManualInputData - \ref QmitkStochasticTrackingUserManualParameters - \ref QmitkStochasticTrackingUserManualReferences -\image html stochastictrackingview.png Stochastic Tracking View +\imageMacro{stochastictrackingview.png,"Stochastic Tracking View",10.12} \section QmitkStochasticTrackingUserManualInputData Input Data Mandatory Input: \li One DWI Image image selected in the datamanager \li One or more ROIs selected in the datamanager For a successful execution of the stochastic tractography filter, a DWI input and a binary image defining the desired ROI are required. The ROI serves as the origin from where on the fibers are beeing tracked. To generate the seed ROI the segmentation view in the quantification perspective can be used or a binary image can be loaded. \section QmitkStochasticTrackingUserManualParameters Input Parameters \li Parameters such as max. tract length, number of seeds per voxel and likelihood cache size in MB can be controlled individually. \li After successfully setting necessary Input and Parameter, pressing the command button executes the algorithm. \section QmitkStochasticTrackingUserManualReferences References [1] Tri M. Ngo, Polina Golland, and Tri M. Ngo. A stochastic tractography system and applications, 2007 */ diff --git a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkStreamlineTrackingViewUserManual.dox b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkStreamlineTrackingViewUserManual.dox index 8dbd1e69db..c644ee09f1 100644 --- a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkStreamlineTrackingViewUserManual.dox +++ b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkStreamlineTrackingViewUserManual.dox @@ -1,41 +1,41 @@ /** \page org_mitk_views_streamlinetracking Streamline Tracking View This view provides the user interface for basic streamline fiber tractography on diffusion tensor images (single and multi-tensor tracking). FACT and TEND tracking methods are available. Available sections: - \ref StrTrackUserManualInputData - \ref StrTrackUserManualParameters - \ref StrTrackUserManualReferences -\image html streamlinetrackingview.png Streamline Tracking View +\imageMacro{streamlinetrackingview.png,"Streamline Tracking View",10.41} \section StrTrackUserManualInputData Input Data Mandatory Input: \li One or multiple DTI Image images selected in the datamanager. Optional Input: \li FA image used to determine streamline termination. If no image is specified, the FA image is automatically calculated from the input tensor images. If multiple tensor images are used as input, it is recommended to provide such an FA image since the FA maps calculated from the individual input tensor images can not provide a suitable termination criterion. \li Binary mask used to define the seed voxels. If no seed mask is specified, the whole image volume is seeded. \li Binary mask used to constrain the generated streamlines. Streamlines can not leave the mask area. \section StrTrackUserManualParameters Input Parameters \li FA Threshold: If the streamline reaches a position with an FA value lower than the speciefied threshold, it is not tracked any further. \li Min. Curvature Radius: If the streamline has a higher curvature than specified, it is not tracked any further. It is defined as the radius of the circle specified by three successive streamline positions. \li f and g values to balance between FACT [1] and TEND [2,3] tracking. For further information please refer to [2,3] \li Step Size: The algorithm proceeds along the streamline with a fixed stepsize. Default is 0.1*minSpacing. \li Min. Tract Length: Shorter fibers are discarded. \li Seeds per voxel: If set to 1, the seed is defined as the voxel center. If > 1 the seeds are distributet randomly inside the voxel. By default the image values are not interpolated. Enable corresponding checkbox to use trilinear interpolation of the tensors as well as the FA values. Keep in mind that in the noninterpolated case, the TEND term is only applied once per voxel. In the interpolated case the TEND term is applied at each integration step which results in much higher curvatures and has to be compensated by an according choice of f and g. \section StrTrackUserManualReferences References [1] Mori et al. Annals Neurology 1999\n [2] Weinstein et al. Proceedings of IEEE Visualization 1999\n [3] Lazar et al. Human Brain Mapping 2003\n */ diff --git a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkTbssViewUserManual.dox b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkTbssViewUserManual.dox index 200fbfb1c6..a4f88f5c05 100644 --- a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkTbssViewUserManual.dox +++ b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkTbssViewUserManual.dox @@ -1,58 +1,58 @@ /** \page org_mitk_views_tractbasedspatialstatistics The TBSS View -\image html tbss.png "Icon of the View" +\imageMacro{tbss.png,"Icon of the View",2.00} \section QmitkTractbasedSpatialStatistics Summary This view can be used to locally explore data resulting from preprocessing with the TBSS view of FSL This document will tell you how to use this view, but it is assumed that you already know how to use MITK in general and how to work with the TBSS view of FSL. If you encounter problems using the view, please have a look at the \ref QmitkTractbasedSpatialStatisticsUserManualTrouble page. \tableofcontents \section QmitkTractbasedSpatialStatisticsUserManualOverview Overview This view is currently under development and as such the interface as well as the capabilities are likely to change significantly between different versions. This documentation describes the features of this current version. \section QmitkTractbasedSpatialStatisticsUserManualFSLImport FSL Import The FSL import allows to import data that has been preprocessed by FSL. FSL creates output images that typically have names like all_FA_skeletonized.nii.gz that are 4-dimensional images that contain registered images of all subjects. By loading this 4D image into the datamanager and listing the groups with the correct number of subjects, in the order of occurrence in the 4D image, in the TBSS-View using the Add button and clicking the import subject data a TBSS file is created that contains all the information needed for tract analysis. The diffusion measure of the image can be set as well. -\image html fslimport.png "FSL Import" +\imageMacro{fslimport.png,"FSL Import",16.00} \section QmitkTractbasedSpatialStatisticsUserManualRois Regions of Interest (ROIs) To create a ROI the mean FA skeleton (typically called mean_FA_skeleton.nii.gz) that is created by FSL should be loaded in to the datamanager and selected. By using the Pointlistwidget points should be set on the skeleton (make sure to select points with relatively high FA values). Points are set by first selecting the button with the '+' and than shift-leftclick in the image. When the correct image is selected in the datamanager the Create ROI button is enabled. Clicking this will create a region of interest that passes through the previously selected points. The roi appears in the datamanager. Before doing so, the name of the roi and the information on the structure on which the ROI lies can be set. This will be saved as extra information in the roi-image. Before the ROI is calculated, a pop-up window will ask the user to provide a threshold value. This should be the same threshold that was previously used in FSL to create a binary mask of the FA skeleton. When this is not done correctly, the region of interest will possible contain zero-valued voxels. -\image html tbssRoi.png "Regions of Interest (ROIs)" +\imageMacro{tbssRoi.png,"Regions of Interest (ROIs)",16.00} \section QmitkTractbasedSpatialStatisticsUserManualProfiles y selecting a tbss image with group information and a region of interest image (as was created in a previous stap). A profile plot is drawn in the plot canvas. By clicking in the graph the crosshairs jump to the corresponding location in the image. -\image html profiles.png "Profile plots" +\imageMacro{profiles.png,"Profile plots",16.00} \section QmitkTractbasedSpatialStatisticsUserManualFiberPlotting It is also possible to use fiber bundles to plot values in images. However, unlike TBSS this only works on 3D volumes (one subject only). To plot the values of a 3D volume using fiber tracking results, we need, fiber data and two planar circles as Regions of Interest that define the region that must be plotted. For every fiber that passes through both ROIs the values at the corresponding positions in the volume are plotted. Every fiber is resampled to the number of segments specified in the GUI. The average value can also be plotted. The subset of the fibers between the ROIs can be cut out by pressing the Cut button. -\image html trackingplot.png "Plot of fiber tracts" +\imageMacro{trackingplot.png,"Plot of fiber tracts",16.00} \section QmitkTractbasedSpatialStatisticsUserManualTroubleshooting Troubleshooting Please report to the MITK mailing list. See http://www.mitk.org/wiki/Mailinglist on how to do this. \section QmitkTractbasedSpatialStatisticsUserManualReferences References 1. S.M. Smith, M. Jenkinson, H. Johansen-Berg, D. Rueckert, T.E. Nichols, C.E. Mackay, K.E. Watkins, O. Ciccarelli, M.Z. Cader, P.M. Matthews, and T.E.J. Behrens. Tract-based spatial statistics: Voxelwise analysis of multi-subject diffusion data. NeuroImage, 31:1487-1505, 2006. 2. S.M. Smith, M. Jenkinson, M.W. Woolrich, C.F. Beckmann, T.E.J. Behrens, H. Johansen-Berg, P.R. Bannister, M. De Luca, I. Drobnjak, D.E. Flitney, R. Niazy, J. Saunders, J. Vickers, Y. Zhang, N. De Stefano, J.M. Brady, and P.M. Matthews. Advances in functional and structural MR image analysis and implementation as FSL. NeuroImage, 23(S1):208-219, 2004. */ diff --git a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkUserIVIMViewManual.dox b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkUserIVIMViewManual.dox index b46d32f9dd..80d9e24921 100644 --- a/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkUserIVIMViewManual.dox +++ b/Plugins/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkUserIVIMViewManual.dox @@ -1,41 +1,41 @@ /** \page org_mitk_views_ivim Intra-voxel incoherent motion estimation (IVIM) The required input for the "Intra-voxel incoherent motion estimation" (IVIM) is a diffusion weighted image (.dwi or .hdwi) that was acquired with several different b-values. -\image html ivimview.png The IVIM View +\imageMacro{ivimview.png,"The IVIM View",13.91} Once an input image is selected in the datamanager, the IVIM view allows for interactive exploration of the dataset (click around in the image and watch the estimated parameters in the figure of the view) as well as generation of f-, D-, and D*-maps (activate the checkmarks and press "Generate Output Images"). The "neglect b<" threshold allows you to ignore b-values smaller then a threshold for the initial fit of f and D. D* is then estimated using all measurements. The exact values of the current fit are always given in the legend underneath the figure. \section QmitkDiffusionImagingUserManualInputData Region of interest analysis Create region of interest: To create a new segmentatin, open the "quantification" perspective, select the tab "Segmentation", and create a segmentation of the structure of interest. Alternatively, of course, you may also load a binary image from file or generate your segmentation in any other possible way. IVIM in region of interset: Go back to the "IVIM" perspective and select both, the diffusion image and the segmentation (holding the CTRL key). A red message should appear "Averaging N voxels". \section QmitkDiffusionImagingUserManualInputData Export All model parameters and corresponding curves can be exported to clipboard using the buttons underneath the figure. \section QmitkDiffusionImagingUserManualInputData Advanced Settings Advanced users, that know what they are doing, can change the method for the model-fit under "Advanced Settings" on the very bottom of the view. 3-param fit, linear fit of f/D, and fix D* are among the options. \section QmitkDiffusionImagingUserManualInputData Suggested Readings Toward an optimal distribution of b values for intravoxel incoherent motion imaging. Lemke A, Stieltjes B, Schad LR, Laun FB. Magn Reson Imaging. 2011 Jul;29(6):766-76. Epub 2011 May 5. PMID: 21549538 Differentiation of pancreas carcinoma from healthy pancreatic tissue using multiple b-values: comparison of apparent diffusion coefficient and intravoxel incoherent motion derived parameters. Lemke A, Laun FB, Klauss M, Re TJ, Simon D, Delorme S, Schad LR, Stieltjes B. Invest Radiol. 2009 Dec;44(12):769-75. PMID: 19838121 */ diff --git a/Plugins/org.mitk.gui.qt.eventrecorder/documentation/UserManual/Manual.dox b/Plugins/org.mitk.gui.qt.eventrecorder/documentation/UserManual/Manual.dox index 084f311b70..5f491b4a6d 100644 --- a/Plugins/org.mitk.gui.qt.eventrecorder/documentation/UserManual/Manual.dox +++ b/Plugins/org.mitk.gui.qt.eventrecorder/documentation/UserManual/Manual.dox @@ -1,18 +1,18 @@ /** \page org_mitk_gui_qt_eventrecorder Eventrecorder -\image html icon.xpm "Icon of Eventrecorder" +\imageMacro{icon.png,"Icon of Eventrecorder",2.00} Available sections: - \ref org_mitk_gui_qt_eventrecorderOverview \section org_mitk_gui_qt_eventrecorderOverview Describe the features of your awesome plugin here
  • Increases productivity
  • Creates beautiful images
  • Generates PhD thesis
  • Brings world peace
*/ diff --git a/Plugins/org.mitk.gui.qt.ext/documentation/UserManual/MITKUserManual.dox b/Plugins/org.mitk.gui.qt.ext/documentation/UserManual/MITKUserManual.dox index e7e7db89fd..150516b830 100644 --- a/Plugins/org.mitk.gui.qt.ext/documentation/UserManual/MITKUserManual.dox +++ b/Plugins/org.mitk.gui.qt.ext/documentation/UserManual/MITKUserManual.dox @@ -1,115 +1,115 @@ /** \page MITKUserManualPage The MITK User Manual Welcome to the basic MITK user manual. This document tries to give a concise overview of the basic functions of MITK and be an comprehensible guide on using them. \tableofcontents \section MITKUserManualPageOverview 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) at the German Cancer Research Center. MITK aims at supporting 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 at all a competitor to VTK or ITK, 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 will not have to reinvent the wheel over and over and can concentrate on your work. Medical Professionals will profit from MITK and the MITK applications by using its basic functionalities for research projects. But nonetheless they will be better off, unless they are programmers themselves, to cooperate with a research institute developing with MITK to get the functionalitiy they need. MITK and the MITK applications are not certified medical products and may be used in a research setting only. They must not be used in patient care. \section MITKUserManualPageUserInterface The User Interface The layout of the MITK applications is designed to give a clear distinction between the different work areas. The following figure gives an overview of the main sections of the user interface. -\image html MITKUserManual_GUICommented.png "The Common MITK Application Graphical User Interface" +\imageMacro{MITKUserManual_GUICommented.png,"The Common MITK Application Graphical User Interface",16.00} The datamanager and the \ref MITKUserManualPagePerspectives have their own help sections. This document explains the use of: - The \ref MITKUserManualPageMultiWidget - The \ref MITKUserManualPageMenu - The \ref MITKUserManualPageLevelWindow - The \ref MITKUserManualPageMemoryUsage - The \ref MITKUserManualPageViews \section MITKUserManualPageMultiWidget Four Window View \subsection MITKUserManualPageMultiWidgetOverview Overview The four window view is the heart of the MITK image viewing. The standard layout is three 2D windows and one 3D window, with the axial window in the top left quarter, the sagittal window in the top right quarter, the coronal window in the lower left quarter and the 3D window in the lower right quarter. The different planes form a crosshair that can be seen in the 3D window. Once you select a point within the picture, informations about it are displayed at the bottom of the screen. \subsection MITKUserManualPageMultiWidgetNavigation Navigation Left click in any of the 2D windows centers the crosshair on that point. Pressing the right mouse button and moving the mouse zooms in and out. By scrolling with the mouse wheel you can navigate through the slices of the active window and pressing the mouse wheel while moving the mouse pans the image section. In the 3D window you can rotate the object by pressing the left mouse button and moving the mouse, zoom either with the right mouse button as in 2D or with the mouse wheel, and pan the object by moving the mouse while the mouse wheel is pressed. Placing the cursor within the 3D window and holding the "F" key allows free flight into the 3D view. \subsection MITKUserManualPageMultiWidgetCustomizingViews Customizing By moving the cursor to the upper right corner of any window you can activate the window menu. It consists of three buttons. -\image html MITKUserManual_CrosshairModes.png "Crosshair" +\imageMacro{MITKUserManual_CrosshairModes.png,"Crosshair",8.72} The crosshair button allows you toggle the crosshair, reset the view and change the behaviour of the planes. Activating either of the rotation modes allows you to rotate the planes visible in a 2D window by moving the mouse cursor close to them and click and dragging once it changes to indicate that rotation can be done. The swivel mode is recommended only for advanced users as the planes can be moved freely by clicking and dragging anywhere within a 2D window. The middle button expands the corresponding window to fullscreen within the four window view. -\image html MITKUserManual_ViewsChoices.png "Layout Choices" +\imageMacro{MITKUserManual_ViewsChoices.png,"Layout Choices",5.19} The right button allows you to choose between many different layouts of the four window view to use the one most suited to your task. \section MITKUserManualPageMenu Menu \subsection MITKUserManualPageFile File This dialog allows you to save, load and clear entire projects, this includes any nodes in the data manager. \subsection MITKUserManualPageEdit Edit This dialog supports undo and redo operations as well as the image navigator, which gives you sliders to navigate through the data quickly. \subsection MITKUserManualPageWindow Window This dialog allows you to open a new window, change between perspectives and reset your current one to default settings. If you want to use an operation of a certain perspective within another perspective the "Show View" menu allows to select a specific function that is opened and can be moved within the working areas according to your wishes. Be aware that not every function works with every perspective in a meaningful way. The Preferences dialog allows you to adjust and save your custom settings. -\image html MITKUserManual_WindowDropdown.png "Preferences" +\imageMacro{MITKUserManual_WindowDropdown.png,"Preferences",4.89} \subsection MITKUserManualPageHelp Help This dialog contains this help, the welcome screen and information about MITK. \section MITKUserManualPageLevelWindow Levelwindow Once an image is loaded the levelwindow appears to the right hand side of the four window view. With this tool you can adjust the range of grey values displayed and the gradient between them. Moving the lower boundary up results in any pixels having a value lower than that boundary to be displayed as black. Lowering the upper boundary causes all pixels having a value higher than it to be displayed as white. The pixels with a value between the lower and upper boundary are displayed in different shades of grey. This way a smaller levelwindow results in higher contrasts while cutting of the information outside its range whereas a larger levelwindow displays more information at the cost of contrast and detail. You can pick the levelwindow with the mouse to move it up and down, while moving the mouse cursor to the left or right to change its size. Picking one of the boundaries with a left click allows you to change the size symmetrically. Holding CTRL and clicking a boundary adjusts only that value. \section MITKUserManualPageMemoryUsage System Load Indicator The System Load Indicator in the lower right hand corner of the screen gives information about the memory currently required by the MITK application. Keep in mind that image processing is a highly memory intensive task and monitor the indicator to avoid your system freezing while constantly swapping to the hard drive. \section MITKUserManualPageViews Views Each solution for a specific problem that is self contained is realized as a single view. Thus you can create a workflow for your problem by combining the capabilities of different views to suit your needs. One elegant way to do this is by combining views in \ref MITKUserManualPagePerspectives. By pressing and holding the left mouse button on a views tab you can move it around to suit your needs, even out of the application window. \section MITKUserManualPagePerspectives Perspectives The different tasks that arise in medical imaging need very different approaches. To acknowledge this circumstance MITK supplies a framework that can be build uppon by very different solutions to those tasks. These solutions are called perspectives, each of them works independently of others although they might be used in sequence to achieve the solution of more difficult problems. It is possible to switch between the perspectives using the "Window"->"Open Perspective" dialog. See \ref MITKUserManualPageMenu for more information about switching perspectives. */ diff --git a/Plugins/org.mitk.gui.qt.igtexamples/documentation/UserManual/QmitkIGTTtrackingLab.dox b/Plugins/org.mitk.gui.qt.igtexamples/documentation/UserManual/QmitkIGTTtrackingLab.dox index 296697e165..bc83f7909a 100644 --- a/Plugins/org.mitk.gui.qt.igtexamples/documentation/UserManual/QmitkIGTTtrackingLab.dox +++ b/Plugins/org.mitk.gui.qt.igtexamples/documentation/UserManual/QmitkIGTTtrackingLab.dox @@ -1,55 +1,55 @@ /** \page org_igttrackinglab IGT Tutorial Step 4: The IGT-TrackingLab Available sections: - \ref QmitkIGTTrackingLabUsersManualOverview - \ref QmitkIGTTrackingLabUsersManualPrel - \ref QmitkIGTTrackingLabUsersManualConf - \ref QmitkIGTTrackingLabUsersManualIntialReg - \ref QmitkIGTTrackingLabUsersManualPermReg - \ref QmitkIGTTrackingLabUsersManualPtSetRec - \ref QmitkIGTTrackingLabUsersManualCamView \section QmitkIGTTrackingLabUsersManualOverview Introduction The IGT-TrackingLab is the last step of the IGT tutorial. It is a plugin which shows examples usage for many IGT classes and is also an example navigation implemented with IGT. In the following you can learn how to use the plugin by reading this manual together with the source code. \section QmitkIGTTrackingLabUsersManualPrel Preliminaries First connect your tracking device to your PC. Then start the MITK Workbench and configure your tracking device using the \ref org_mitk_views_igttrackingtoolbox "Tracking Toolbox View". \section QmitkIGTTrackingLabUsersManualConf Configuration Select the desired Navigation Data Source. Now it’s time to define which tool shall be used as object marker and which tool shall be used as pointer. Next load the Book surface provided with the example data (e.g. book.stl from the MITK-Data repository which comes with every superbuild or may also be checked out separately) into MITK. Fixate the object marker on a real book of your choice. Now we need to tell MITK that the object marker has been fixated on a physical object. To do this, select the Book as surface in the Object Selection submenu. \section QmitkIGTTrackingLabUsersManualIntialReg Initial Registration Now we need to register the object marker to the surface it's fixed upon, in our case the book. To do this, first press the initial registration button. For MITK to be able to do this registration, we need to 1. Select landmarks on the virtual object (e.g. the corners of the book) Press the plus button in the Image fiducials column. Shift + click on the corners on the book in the MITK Display. 2. Point to the corresponding landmarks in the real world using the pointer. Now press the plus button in the Real world fiducials column and point to the corners on the real book. Press Add current instrument position whenever you targeted a corner to tell MITK this is the desired landmark. Make sure you select the "real" edges in the same order as the edges in the image. Press Register to finalize the initial registration. Now the object marker is registered onto the book. You can see this in the MITK image. If needed the FRE is shown in the widget. \section QmitkIGTTrackingLabUsersManualPermReg Permanent Registration Now everything is set up and registered. We can thus activate permanent registration to continuously track the object, the object marker and the pointer. For this, simply press the Permanent Registration button and select Activate permanent registration. You can now move the book in the real world and see the same movement in the MITK Display. A nice test to see if everything was correctly registered is to target the corners of the book with the pointer and check if the correct corners are pointed to in the MITK Display. \section QmitkIGTTrackingLabUsersManualPtSetRec PointSet Recording A user might now want to track a tool's trajectory. For this, the PointSet Recording was created. First click on PointSet Recording. Now select your tracking source and the tool whose trajectory shall be recorded. Activate the Point Set Recording checkbox. In the MITK Display little green points will now be drawn for every measured position. Deactivate the checkbox to stop recording. The trajectory is saved in the PointSet Recorded Points visible in the Data Manager. \section QmitkIGTTrackingLabUsersManualCamView Camera View Another possible tracking application is the Camera View. Here, a virtual camera is placed at the pointers tip and its images are shown in the MITK Display. Select Camera View and as usual the Tracking Source and the tool you want to place the virtual camera on. Activate the "Activate Needle View" checkbox and move the pointer around the book. You can now see the book from the pointers perspective. You may need to adjust the Needle View Direction and the View Up Vector. This is always relative to your tools coordinate center origin. An example of the NDI pointer tool coordinate system is shown below: -\image html QmitkIGTExamples_Tool.png "The coordinate system of the NDI pointing tool" +\imageMacro{QmitkIGTExamples_Tool.png,"The coordinate system of the NDI pointing tool",16.00} In the above case, the camera should look in inverse z-direction, and the view up vector should probably be set to positive x. Note this is just an example and may be different depending on your pointer. */ diff --git a/Plugins/org.mitk.gui.qt.igtexamples/documentation/UserManual/QmitkIGTTutorial.dox b/Plugins/org.mitk.gui.qt.igtexamples/documentation/UserManual/QmitkIGTTutorial.dox index f6f02b361f..08757baccf 100644 --- a/Plugins/org.mitk.gui.qt.igtexamples/documentation/UserManual/QmitkIGTTutorial.dox +++ b/Plugins/org.mitk.gui.qt.igtexamples/documentation/UserManual/QmitkIGTTutorial.dox @@ -1,14 +1,14 @@ /** \page org_imageguidedtherapytutorial The MITK-IGT Tutorial Module -\image html QmitkIGTExamples_ImageGuidedTherapy.png "Icon of the Module" +\imageMacro{QmitkIGTExamples_ImageGuidedTherapy.png,"Icon of the Module",2.00} \section QmitkIGTTutorialUserManualSummary Summary This module is not meant as a end-user module. It contains tutorial program code that explains how to use the MITK-IGT component. It contains only two buttons. The "Start image guided therapy" button will create a virtual tracking device and a virtual tool. It will move the tool around on random paths in a tracking volume of 200x200x200 mm. The tool is visualized with a cone. If you do not see a cone moving around, you will need to initialize the rendering views correctly. Use the DataManager view to perform a global reinit. */ diff --git a/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkMITKIGTNavigationToolManager.dox b/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkMITKIGTNavigationToolManager.dox index 31bfbb4df8..fe5b8a4884 100644 --- a/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkMITKIGTNavigationToolManager.dox +++ b/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkMITKIGTNavigationToolManager.dox @@ -1,55 +1,55 @@ /** \page org_mitk_views_igtnavigationtoolmanager The MITK-IGT Navigation Tool Manager -\image html QmitkIGTTracking_IconNavigationToolManager.png "Icon of the Module" +\imageMacro{QmitkIGTTracking_IconNavigationToolManager.png,"Icon of the Module",2.12} \section QmitkMITKIGTNavigationToolManager Introduction This view allows for creating and editing NavigationToolStorages. These storages contains naviagtion tools of a tracking device, can be saved permanently and used later for any other IGT application. Available sections: - \ref QmitkMITKIGTNavigationToolManager - \ref QmitkMITKIGTNavigationToolManagerToolOverview - \ref QmitkMITKIGTNavigationToolManagerManagingNavigationToolStorage - \ref QmitkMITKIGTNavigationToolManagerAddingEditingNavigationTools \section QmitkMITKIGTNavigationToolManagerToolOverview Navigation Tools Overview A navigation tool of MITK-IGT represents a tracking tool (e.g. an emt sensor or an optically tracked tool) and it's corresponding data, like it's name and it's surface. A navigation tool is a generalized container for any trackable object in combination with it's additional information. Every navigation tool has different properties which are:
  • Name
  • Unique identifier
  • Tool definition file
  • Serial number
  • Surface for visualization
  • Type of tracking device
  • Type of the tool
  • Tool landmarks
Note that not all properties are needed for all types of tools. A tool definition file, for example, is only needed by optical tracking tools (e.g. a .rom file for Polaris or a toolfile for the MicronTracker). A tool associated with the aurora system is alwalys identified by it's serial number. You can also detect Aurora tools automatically with the TrackingToolbox view and edit the automatically detected tool storage later with this view. \section QmitkMITKIGTNavigationToolManagerManagingNavigationToolStorage Managing Navigation Tool Storage In order to create edit a tool storage container, you can select one of the available tool storages listed in the upper part of the UI. The list shows all tool storages which are available throug the micro services concept of MITK. The list also shows the current tool storage of the IGT tracking toolbox view if it is active. In addition to the listed tool storages, you can load new storages from the hard disc which will then appear in the list and might be edited as all other storage by simply selecting it in the list. You may also save a selected tool storage to the hard disc or create a new one. In the lower part of the UI you always see the list of tools of the tool storage which is currently selected in the upper part. Use the buttons "add", "edit" and "delete" to manage the contained navigation tools. If you click "edit" or "delete" the operation is applied on the currently selected tool, as shown in the screenshot below. -\image html QmitkIGTTracking_NavigationToolManagemantStartScreen.png "Screenshot of the main view of NavigationToolManagent" +\imageMacro{QmitkIGTTracking_NavigationToolManagemantStartScreen.png,"Screenshot of the main view of NavigationToolManagent",10.90} \section QmitkMITKIGTNavigationToolManagerAddingEditingNavigationTools Adding / Editing Navigation Tools If you add or edit a navigation tool, an input mask, as shown in the screenshot below, appears. The tool identifier is filled automatically, if you change it, remember that it is unique in the current storage. Also, choose a valid surface for every tool, this is nessesary for correct tool visualization. The other information depends on the tracking system type. So choose a tool file for the Polaris or the MicronTracker system and type in a serial number for the Aurora system. Two identical tools with the same serial number are also possible, they are assigned by the order in which they are attached to the device. As long as they also have the same surface as representation, this should not be a problem for most of the use cases. The tool type is additional information which is not needed by the tracking device but might be needed by further IGT applications. The same applies to the tool landmarks which might be defined for a tool. There are two different types of landmarks which are designed as described here:
  • Tool Calibration Landmarks: These landmarks may be used clearly define the tools pose only by using landmarks in the tool coordinate system. E.g., two landmarks for a 5DoF tool and three landmarks for a 6DoF tool. These landmarks may be used, e.g., for a point based registration of a tool from image space to tracking space.
  • Tool Registration Landmarks: These landmarks are designed for representing defined landmarks on a tools surface. The number of these landmarks might exeed the number of tool calibration landmarks for reasons of redundancy and averaging. They are used for, e.g., manually registering the pose of a tool by visual markers in a CT scan. If you would use these landmarks to do a point based registration from image space to tracking space later, you might overweight the tool because of two many landmarks compared to other markers.
-\image html QmitkIGTTracking_NavigationToolManagementAddTool.png "Screenshot of add/edit navigation tool screen" +\imageMacro{QmitkIGTTracking_NavigationToolManagementAddTool.png,"Screenshot of add/edit navigation tool screen",9.19} */ \ No newline at end of file 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 dc469c5af2..b4b762c87b 100644 --- a/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkMITKIGTTrackingToolbox.dox +++ b/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkMITKIGTTrackingToolbox.dox @@ -1,64 +1,64 @@ /** \page org_mitk_views_igttrackingtoolbox The MITK-IGT Tracking Toolbox -\image html QmitkIGTTracking_IconTrackingToolbox.png "Icon of the module" +\imageMacro{QmitkIGTTracking_IconTrackingToolbox.png,"Icon of the module",2.12} Available sections: - \ref QmitkMITKIGTTrackingToolboxIntroduction - \ref QmitkMITKIGTTrackingToolboxWorkflow - \ref QmitkMITKIGTTrackingToolboxConnecting - \ref QmitkMITKIGTTrackingToolboxLoadingTools - \ref QmitkMITKIGTTrackingToolboxAutoDetection - \ref QmitkMITKIGTTrackingToolboxStartTracking - \ref QmitkMITKIGTTrackingToolboxLogging - \ref QmitkMITKIGTTrackingOptions \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. Currently the devices Polaris, Aurora (both Northern Digital Inc. (NDI); Waterloo, Ontario, Canada) and MicronTracker (Claron Technology, Inc.; Toronto, Ontario, Canada) are supported. The MicroBird family (Ascension Technology Corporation, Inc.; Burlington, USA) will hopefully follow soon since it is already supported by the tracking layer of IGT. The logging feature of the Tracking Toolbox supports logging in XML or CSV format. -\image html QmitkIGTTracking_ScreenshotMitk.png "MITK Screenshot with the TrackingToolbox activated" +\imageMacro{QmitkIGTTracking_ScreenshotMitk.png,"MITK Screenshot with the TrackingToolbox activated",16.00} \section QmitkMITKIGTTrackingToolboxWorkflow General workflow Introduction A general Workflow with the Tracking Toolbox may be:
  • Configuration of a tracking device
  • Loading a toolfile which holds tool definitions
  • Start tracking
  • Logging tracked data
\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 tracking system connected to a serial port, like Aurora or Polaris, you then need to specifiy the serial port. In case of the MicronTracker you only need to ensure that all drivers are installed correctly and integrated into MITK. If you want to check the connection, press "test connection". The results are displayed in the small black box on the right. -\image html QmitkIGTTracking_ConfigurationWidget.png "Tracking Device Configuration" +\imageMacro{QmitkIGTTracking_ConfigurationWidget.png,"Tracking Device Configuration",8.55} \section QmitkMITKIGTTrackingToolboxLoadingTools Loading tools To load tools which can be tracked you need a predefined tracking tool storage. 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 (see section below). Otherwise you can use the MITK view NavigationToolManager to define a navigation tool storage. There you can create navigation tools with the corresponding toolfiles, visualization surfaces and so on. Please see NavigationToolManager manual for more details. 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. All 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. -\image html QmitkIGTTracking_TrackingToolsWidget.png "Tracking Tools" +\imageMacro{QmitkIGTTracking_TrackingToolsWidget.png,"Tracking Tools",9.08} \section QmitkMITKIGTTrackingToolboxAutoDetection Auto detection of tools (only Aurora) If the Aurora tracking system is used, 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 Tracking can simply be started by pressing "Start Tracking". Note that options may not be changed during tracking. Once tracking has started the tracking volume (only if the option is on) and the tools are visualized in the 3D view of MITK. \section QmitkMITKIGTTrackingToolboxLogging Logging features 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. \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. */ \ No newline at end of file diff --git a/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkNavigationDataPlayer.dox b/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkNavigationDataPlayer.dox index 6eb920e5a8..3d46273e2f 100644 --- a/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkNavigationDataPlayer.dox +++ b/Plugins/org.mitk.gui.qt.igttracking/documentation/UserManual/QmitkNavigationDataPlayer.dox @@ -1,18 +1,18 @@ /** \page org_mitk_views_navigationdataplayer NavigationData Player -\image html QmitkIGTTracking_IconNavigationDataPlayer.png "Icon of NavigationData Player" +\imageMacro{QmitkIGTTracking_IconNavigationDataPlayer.png,"Icon of NavigationData Player",2.00} Available sections: - \ref NavigationDataPlayerOverview \section NavigationDataPlayerOverview The navigation data player plays recorded or artificial navigation data of one ore more tracking tools and visualizes their trajectory. For that purpose select an input file (*.xml only) and select which tracking tool's trajectory should be visualized. If you additionally activate the checkbox "Splines" the trajectory curve will be smoothed via spline interpolation. Press the button "start" for starting the player and the visualization. If "Sequential Mode" is checked, the navigation data are played sequentially without regarding the recorded time steps. You can use the resolution field to define which part of the samples you want to use. E.g. 1 = every sample; 2 = every second sample; 3 = every third sample, ... -\image html QmitkIGTTracking_ScreenshotNavigationDataPlayer.png "Screenshot of the NavigationData Player" +\imageMacro{QmitkIGTTracking_ScreenshotNavigationDataPlayer.png,"Screenshot of the NavigationData Player",16.00} */ diff --git a/Plugins/org.mitk.gui.qt.imagecropper/documentation/UserManual/QmitkImageCropper.dox b/Plugins/org.mitk.gui.qt.imagecropper/documentation/UserManual/QmitkImageCropper.dox index d9566c2baf..1f9328531e 100644 --- a/Plugins/org.mitk.gui.qt.imagecropper/documentation/UserManual/QmitkImageCropper.dox +++ b/Plugins/org.mitk.gui.qt.imagecropper/documentation/UserManual/QmitkImageCropper.dox @@ -1,36 +1,36 @@ /** \page org_mitk_views_imagecropper The Image Cropper Plugin -\image html QmitkImageCropper_Icon.png "Icon of the Plugin" +\imageMacro{QmitkImageCropper_Icon.png,"Icon of the Plugin",2.00} \tableofcontents \section QmitkImageCropperUserManualOverview Overview ImageCropper is a functionality which allows the user to manually crop an image by means of a bounding box. The functionality does not create a new image, it only hides parts of the original image. \section QmitkImageCropperUserManualFeatures Features - Crop a selected image using a bounding box. - Set the border voxels to a specific user defined value after cropping. \section QmitkImageCropperUserManualUsage Usage First select from the drop down menu the image to crop. The three 2D widgets show yellow rectangles representing the bounding box in each plane (axial, sagital, coronal), the lower right 3D widget shows the entire volume of the bounding box.\n - To change the size of bounding box press control + right click and move the cursor up/down or left/right in one of the three 2D views.\n - To change the orientation of the bounding box press control + middle click and move the cursor up/down or left/right in one of the three 2D views.\n - To move the bounding box press control + left click and move the cursor to the wanted position in one of the three 2D views.\n To show the result press the [crop] button.\n To crop the image again press the [New bounding box!] button.\n\n All actions can be undone by using the global undo function (Ctrl+Z).\n To set the border voxels to a specific value after cropping the image, activate the corresponding checkbox and choose a gray value. \section QmitkImageCropperUserManualTroubleshooting Troubleshooting */ diff --git a/Plugins/org.mitk.gui.qt.imagenavigator/documentation/UserManual/QmtikImageNavigator.dox b/Plugins/org.mitk.gui.qt.imagenavigator/documentation/UserManual/QmtikImageNavigator.dox index fadd6eccd9..4cfa135346 100644 --- a/Plugins/org.mitk.gui.qt.imagenavigator/documentation/UserManual/QmtikImageNavigator.dox +++ b/Plugins/org.mitk.gui.qt.imagenavigator/documentation/UserManual/QmtikImageNavigator.dox @@ -1,15 +1,15 @@ /** \page org_mitk_views_imagenavigator The Image Navigator -\image html QmtikImageNavigator_Slider.png "Icon of the Module" +\imageMacro{QmtikImageNavigator_Slider.png,"Icon of the Module",2.00} -\image html QmtikImageNavigator_ImageNavigator.png "Image Navigator" +\imageMacro{QmtikImageNavigator_ImageNavigator.png,"Image Navigator",7.47} Fast movement through the available data can be achieved by using the Image Navigator. By moving the sliders around you can scroll quickly through the slides and timesteps. By entering numbers in the relevant fields you can jump directly to your point of interest. The "Show detail" checkbox enables you to see the world coordinates in millimetres and the index/voxel coordinates. These may be edited to jump to a specific location. */ \ No newline at end of file diff --git a/Plugins/org.mitk.gui.qt.materialeditor/documentation/UserManual/QmitkSurfaceMaterialEditor.dox b/Plugins/org.mitk.gui.qt.materialeditor/documentation/UserManual/QmitkSurfaceMaterialEditor.dox index 0a0d17d669..b18f55b489 100644 --- a/Plugins/org.mitk.gui.qt.materialeditor/documentation/UserManual/QmitkSurfaceMaterialEditor.dox +++ b/Plugins/org.mitk.gui.qt.materialeditor/documentation/UserManual/QmitkSurfaceMaterialEditor.dox @@ -1,10 +1,10 @@ /** \page org_surfacematerialeditor The Surface Material Editor -\image html QmitkSurfaceMaterialEditor_Icon.png "Icon of the Module" +\imageMacro{QmitkSurfaceMaterialEditor_Icon.png,"Icon of the Module",2.00} The Surface Material Editor shows the properties of the selected data that are relevant for the selected shader. These properties can be filtered to find a specific property. The preview window shows the representation of a neutral 3D object with the currently selected settings. -\image html QmitkSurfaceMaterialEditor_Gui.png "The Surface Material Editor" +\imageMacro{QmitkSurfaceMaterialEditor_Gui.png,"The Surface Material Editor",10.92} */ \ No newline at end of file diff --git a/Plugins/org.mitk.gui.qt.measurementtoolbox/documentation/UserManual/QmitkImageStatistics.dox b/Plugins/org.mitk.gui.qt.measurementtoolbox/documentation/UserManual/QmitkImageStatistics.dox index dc7e5b0080..921de2063a 100644 --- a/Plugins/org.mitk.gui.qt.measurementtoolbox/documentation/UserManual/QmitkImageStatistics.dox +++ b/Plugins/org.mitk.gui.qt.measurementtoolbox/documentation/UserManual/QmitkImageStatistics.dox @@ -1,54 +1,54 @@ /** \page org_mitk_views_imagestatistics The Image Statistics View -\image html QmitkMeasurementToolbox_ImageStatisticsIcon.png "Icon of the View" +\imageMacro{QmitkMeasurementToolbox_ImageStatisticsIcon.png,"Icon of the View",2.00} \section QmitkImageStatisticsUserManualSummary Summary This view provides an easy interface to quickly compute some features of a whole image or a region of interest. This document will tell you how to use this view, but it is assumed that you already know how to use MITK in general. Please see \ref QmitkImageStatisticsUserManualDetails for more detailed information on usage and supported filters. If you encounter problems using the view, please have a look at the \ref QmitkImageStatisticsUserManualTrouble page. \section QmitkImageStatisticsUserManualDetails Details Manual sections: - \ref QmitkImageStatisticsUserManualOverview - \ref QmitkImageStatisticsUserManualUsage - \ref QmitkImageStatisticsUserManualTrouble \section QmitkImageStatisticsUserManualOverview Overview This view provides an easy interface to quickly compute some features of a whole image or a region of interest. -\image html QmitkMeasurementToolbox_Interface.png "The interface" +\imageMacro{QmitkMeasurementToolbox_Interface.png,"The interface",9.10} \section QmitkImageStatisticsUserManualUsage Usage After selection of an image or a binary mask of an image in the datamanager, the Image Statistics view shows some statistical information. If a mask is selected, the name of the mask and the name of the image, to which the mask is applied, are shown at the top. For time data the current time step is used for the selected mask and the selected image. If the total number of time steps on the selected mask is less than the current time step, the last time step of the mask is used. If a mask is selected, its used time step will be displayed next to its name like this: (t=0). Check "Ignore zero-valued voxels" to hide voxels with grayvalue zero. Below it is the statistics window which displays the calculated statistical features (such as mean, standard deviation...). Beneath the statistics window is the histogram window, which shows the histogram of the current selection. At top of the histogram window are two radiobuttons. Toggle one of them to either show the histogram as a barchart or as a lineplot. Use mousewheel to zoom in and out the histogram. With the left mouse button the histogram is pannable in zoomed state. If the histogram is displayed as a barchart a tooltip is available by hovering over one of the bins. A tooltip is also available, if an intesity profile is created for a path element as mask. At the bottom of each view is one button. They copy their respective data in csv format to the clipboard. \section QmitkImageStatisticsUserManualTrouble Troubleshooting No known problems. All other problems.
Please report to the MITK mailing list. See http://www.mitk.org/wiki/Mailinglist on how to do this. */ diff --git a/Plugins/org.mitk.gui.qt.measurementtoolbox/documentation/UserManual/QmitkMeasurement.dox b/Plugins/org.mitk.gui.qt.measurementtoolbox/documentation/UserManual/QmitkMeasurement.dox index 4bcea6af8b..b73817c4d0 100644 --- a/Plugins/org.mitk.gui.qt.measurementtoolbox/documentation/UserManual/QmitkMeasurement.dox +++ b/Plugins/org.mitk.gui.qt.measurementtoolbox/documentation/UserManual/QmitkMeasurement.dox @@ -1,120 +1,120 @@ /** \page org_mitk_views_measurement The Measurement View -\image html QmitkMeasurementToolbox_MeasurementIcon.png "Icon of the View" +\imageMacro{QmitkMeasurementToolbox_MeasurementIcon.png,"Icon of the View",2.00} \section QmitkMeasurementUserManualOverview Overview The Measurement view enables the user to interact with 2D images or single slices of 3D image stacks and planar figure data types. It allows to measure distances, angels, pathes and several geometric figures on a dataset. \tableofcontents The workflow to use this view is: -\image html QmitkMeasurementToolbox_Workflow.png +\imageMacro{QmitkMeasurementToolbox_Workflow.png,"",16.00} The workflow is repeatedly useable with the same or different measurement figures, which are correlated to the choosen image and can be saved together with it for future use. On pressing the Measurement icon (see picture below the page title) in the view button line the basic appearance of the view is as follws. -\image html QmitkMeasurementToolbox_BasicScreenEdited.jpg +\imageMacro{QmitkMeasurementToolbox_BasicScreenEdited.jpg,"",16.00} The standard working plane is "Axial" but the other standard viewplanes ("Saggital" and "Coronal") are also valid for measurements. To swap between the view planes refer to the application user manual. \section QmitkMeasurementUserManualFeatures Features The view as it is depicted below offers the following features in the order of apperance on the image from top to bottom: -\image html QmitkMeasurementToolbox_MeasurementView.jpg +\imageMacro{QmitkMeasurementToolbox_MeasurementView.jpg,"",7.60} The first information is the selected image's name (here: DICOM-MRI-Image) followed by the measurement figures button line with the seven measurement figures. From left to right the buttons are connected with the following functions: \subsection SubOne Draw Line Draws a line between two set points and returns the distance between these points. \subsection SubTwo Draw Path Draws a path between several set points (two and more) and calculates the circumference, that is all line's length summed up. Add the final point by double left click. \subsection SubThree Draw Angle Draws two lines from three set points connected in the second set point and returns the inner angle at the second point. \subsection SubFour Draw Four Point Angle Draws two lines that may but must not intersect from four set points. The returned angle is the one depicted in the icon. \subsection SubFive Draw Circle Draws a circle by setting two points, whereas the first set point is the center and the second the radius of the circle. The measured values are the radius and the included area. \subsection SubSix Draw Rectangle Draws a rectangle by setting two points at the opposing edges of the rectangle starting with the upper left edge. The measured values are the circumference and the included area. \subsection SubSeven Draw Polygon Draws a polygon by setting three or more points. The measured values are the circumference and the included area. Add the final point by double left click. Below the buttonline the statistics window is situated, it displays the results of the actual measurements from the selected measurement figures. The content of the statistics window can be copied to the clipboard with the correspondig button for further use in a table calculation programm (e.g. Open Office Calc etc.). -\image html QmitkMeasurementToolbox_ImageProcessed.jpg +\imageMacro{QmitkMeasurementToolbox_ImageProcessed.jpg,"",7.56} The last row contains again a button line to swap from the measurement perspective (activated in the image) to other supported MITK perspectives. \section QmitkMeasurementUserManualUsage Usage This Section is subdivided into four subsections:
  1. Add an image
  2. Work with measurement figures
  3. Save the image with measurement information
  4. Remove measurement figures or image
Let's start with subsection 1 \subsection One Add an image There are two possible ways to add an image to the programm. One is to grap the image with left mouse click from your prefered file browser and simply drag&drop it to the View Plane field. The other way is to use the -\image html QmitkMeasurementToolbox_OpenButton.png +\imageMacro{QmitkMeasurementToolbox_OpenButton.png,"",2.01} button in the upper left corner of the application. A dialog window appears showing the file tree of the computer. Navigate to the wanted file and select it with the left mouse click. Afterwards just use the dialog's open button. The wanted image appears in the View Plane and in the Data Manager the images name appears as a new tree node. Now the image is loaded it can be adjusted in the usual way ( zoom in/out: right mouse button + moving the mouse up and down, moving the image: press mouse wheel and move the mouse to the wished direction, scroll through the slices( only on 3D images): scroll mouse wheel up and down). -\image html QmitkMeasurementToolbox_ImageLoadedScreen.jpg +\imageMacro{QmitkMeasurementToolbox_ImageLoadedScreen.jpg,"",16.00} After the image is loaded the image's name appears in the Data Manager. By left-clicking on the image name the buttonline becomes activated. \subsection Two Work with measurement figures The measurement view comes with seven measurement figures(see picture below), that can be applied to the images. -\image html QmitkMeasurementToolbox_MeasurementFigureButtonLine.jpg +\imageMacro{QmitkMeasurementToolbox_MeasurementFigureButtonLine.jpg,"",7.22} The results of the measurement with each of these figures is shown in the statistics window and in the lower right corner of the view plane. -\image html QmitkMeasurementToolbox_ImageProcessedScreen.jpg +\imageMacro{QmitkMeasurementToolbox_ImageProcessedScreen.jpg,"",6.96} When applying more then one measurement figure to the image the actual measurement figure is depicted in red and the displayed values belong to this measurement figure. All measurement figures become part of the Data Manager as a node of the image tree. \subsection Three Save the image with measurement information After applying the wanted measurement figures the entire scene consisting of the image and the measurement figures can be saved for future use. Therefore just click the right mouse button when over the image item in the Data Manager and choose the item "Save" in the opening item list. Following to that a save dialog appears where the path to the save folder can be set. Afterwards just accept your choice with the save button. \subsection Four Remove measurement figures or image If the single measurement figures or the image is not needed any longer, it can be removed solely or as an entire group. The image can't be removed without simultaneously removing all the dependent measurement figures that belong to the image tree in the Data Manager. To remove just select the wanted items in the data manager list by left-click on it or if several items wanted to be removed left click on all wanted by simultaneously holding the ctrl-button pressed. For more detailed usage of the save/remove functionality refer to the Data Manager User Manual. +\imageMacro{QmitkMeasurementToolbox_MeasurementGUI.png,"Graphical User Interface of Measurement -->",16.00} */ diff --git a/Plugins/org.mitk.gui.qt.moviemaker/documentation/UserManual/QmitkMovieMaker.dox b/Plugins/org.mitk.gui.qt.moviemaker/documentation/UserManual/QmitkMovieMaker.dox index 19101601c6..66032f37de 100644 --- a/Plugins/org.mitk.gui.qt.moviemaker/documentation/UserManual/QmitkMovieMaker.dox +++ b/Plugins/org.mitk.gui.qt.moviemaker/documentation/UserManual/QmitkMovieMaker.dox @@ -1,44 +1,44 @@ /** \page org_mitk_views_moviemaker The Movie Maker View -\image html QmitkMovieMaker_Icon.png "Icon of the View" +\imageMacro{QmitkMovieMaker_Icon.png,"Icon of the View",2.00} Available sections: - \ref QmitkMovieMakerUserManualOverview - \ref QmitkMovieMakerUserManualFeatures - \ref QmitkMovieMakerUserManualUsage \section QmitkMovieMakerUserManualOverview Overview MovieMaker is a functionality for easily creating fancy movies from scenes displayed in MITK widgets. It is also possible to slide through your data, automatically rotate 3D scenes and take screenshots of widgets. \section QmitkMovieMakerUserManualFeatures Features The Movie Maker allows you to create movies and screenshots from within MITK. It can automatically scroll thorugh timesteps and slices while recording a movie. This way, you can record visualizations like a beating heart or a rotating skull. \section QmitkMovieMakerUserManualUsage Usage -\image html QmitkMovieMaker_ControlArea.png "A view of the command area of QmitkMovieMaker" +\imageMacro{QmitkMovieMaker_ControlArea.png,"A view of the command area of QmitkMovieMaker",9.84} \subsection QmitkMovieMakerUserManualWindowSelection Window selection With the first two drop down boxes, you can choose which window you want to step through and which window you want to record in. Left clicking inside a window will set both drop down boxes to that window, but you can choose different windows for stepping and recording. The first drop down box defines the window along which slices will be stepped through if stepping is set to spatial (see below). The second denotes the window from which the content will be recorded. \subsection QmitkMovieMakerUserManualRecordingOptions Recording Options The slider can be used to step through the slices manually while not recording. Start and stop control a preview of what a video would look like. The buttons in the bottom part of this section can be used to create movies (windows only) or screenshots. Clicking opens a file %dialog where a name can be selected. After confirmation, a screenshot or movie is created according to the playing options. \subsection QmitkMovieMakerUserManualPlayingOptions Playing Options The first section controls whether the movie steps through slices (if a 2D view is selected), rotate the shown scene (if a 3D view is selected), or step through time steps (if set to temporal and a time resolved dataset is selected). If set to combined, a combination of both above options is used, with their speed relation set via the S/T Relation Spinbox. In the second section the direction of stepping can be set. Options are: Forward, backward and Ping-Pong, which is back-and-forth.The stepping speed can be set via the spinbox(total time in seconds). Although stepping speed is a total time in sec., this can not always be achieved. As a minimal frame rate of 25 fps is assumed to provide smooth movies, a dataset with only 25 slices will always be stepped through in 1 sec or faster. */ diff --git a/Plugins/org.mitk.gui.qt.moviemaker/documentation/UserManual/QmitkScreenshotMaker.dox b/Plugins/org.mitk.gui.qt.moviemaker/documentation/UserManual/QmitkScreenshotMaker.dox index 5030bcc599..05b657bdeb 100644 --- a/Plugins/org.mitk.gui.qt.moviemaker/documentation/UserManual/QmitkScreenshotMaker.dox +++ b/Plugins/org.mitk.gui.qt.moviemaker/documentation/UserManual/QmitkScreenshotMaker.dox @@ -1,19 +1,19 @@ /** \page org_mitk_views_screenshotmaker The Screenshot Maker This view provides the functionality to create and save screenshots of the data. Available sections: - \ref QmitkScreenshotMakerUserManualUse -\image html QmitkMovieMaker_ScreenshotMakerInterface.png The Screenshot Maker User Interface +\imageMacro{QmitkMovieMaker_ScreenshotMakerInterface.png,"The Screenshot Maker User Interface",7.09} \section QmitkScreenshotMakerUserManualUse Usage The first section offers the option of creating a screenshot of the last activated render window (thus the one, which was last clicked into). Upon clicking the button, the Screenshot Maker asks for a filename in which the screenshot is to be stored. The multiplanar Screenshot button asks for a folder, where screenshots of the three 2D views will be stored with default names. The high resolution screenshot section works the same as the simple screenshot section, aside from the fact, that the user can choose a magnification factor. In the option section one can rotate the camera in the 3D view by using the buttons. Furthermore one can choose the background colour for the screenshots, default is black. */ diff --git a/Plugins/org.mitk.gui.qt.pointsetinteraction/documentation/UserManual/QmitkPointSetInteraction.dox b/Plugins/org.mitk.gui.qt.pointsetinteraction/documentation/UserManual/QmitkPointSetInteraction.dox index 3b1c24f16b..17dfdb2e03 100644 --- a/Plugins/org.mitk.gui.qt.pointsetinteraction/documentation/UserManual/QmitkPointSetInteraction.dox +++ b/Plugins/org.mitk.gui.qt.pointsetinteraction/documentation/UserManual/QmitkPointSetInteraction.dox @@ -1,47 +1,47 @@ /** \page org_mitk_views_pointsetinteraction The Point Set Interaction View -\image html QmitkPointSetInteraction_Icon.png "Icon of the View" +\imageMacro{QmitkPointSetInteraction_Icon.png,"Icon of the View",2.00} Available sections: - \ref QmitkPointSetInteractionUserManualOverview - \ref QmitkPointSetInteractionUserManualDetails \section QmitkPointSetInteractionUserManualOverview Overview This functionality allows you to define multiple sets of points, to fill them with points and to save them in so called PointSets. -\image html QmitkPointSetInteraction_Screenshot.png "MITK with the QmitkPointSetInteraction functionality" +\imageMacro{QmitkPointSetInteraction_Screenshot.png,"MITK with the QmitkPointSetInteraction functionality",16.00} This document will tell you how to use this functionality, but it is assumed that you already know how to navigate through the slices of an image using the four window view. Please read the application manual for more information. \section QmitkPointSetInteractionUserManualDetails Details First of all you have to select a PointSet to use this functionality. Therefore, you have to select the point set in the data manager. If there are currently no point sets in the data tree, you have to first add a new point set to the data tree. This is done by clicking the "Add pointset..." button. -\image html QmitkPointSetInteraction_AddPointSet.png "The Add pointset... dialog" +\imageMacro{QmitkPointSetInteraction_AddPointSet.png,"The Add pointset... dialog",8.64} In the pop-up dialog, you have to specify a name for the new point set. This is also the node for the new data tree item. -\image html QmitkPointSetInteraction_CurrentPointSetArea.png "The Current pointset area" +\imageMacro{QmitkPointSetInteraction_CurrentPointSetArea.png,"The Current pointset area",6.52} The "Current pointset" area contains a list of points. Within this area, all points for the current point set node are listed. To set points you have to toggle the "Set Points" button, the leftmost of the four buttons on the bottom of the view. Points can be defined by performing a left mouse button click while holding the "Shift"-key pressed in the four window view. To erase all points from the list press the next button. The user is prompted to confirm the decision. If you want to delete only a single point, left click on it in the list and then press delete on your keyboard. With the third button, a previously saved point set can be loaded and all of its points are shown in the list and the four window view. The user is prompted to select the file to be loaded. The file extension is ".mps". On the right of this button is the save button. With this function the entire point set can be saved to the harddrive. The user is prompted to select a filename. Pointsets are saved in XML fileformat but have to have a ".mps" file extension. You can select points in the render window, if the "Set Points" button is toggled, with a left mouse button click on them. If you keep the mouse button pressed, you can move the points by moving the mouse and then releasing the mouse button. With the delete key you can remove the selected points. */ \ No newline at end of file diff --git a/Plugins/org.mitk.gui.qt.registration/documentation/UserManual/QmitkDeformableRegistrationUserManual.dox b/Plugins/org.mitk.gui.qt.registration/documentation/UserManual/QmitkDeformableRegistrationUserManual.dox index 17194238d4..1a003a5838 100644 --- a/Plugins/org.mitk.gui.qt.registration/documentation/UserManual/QmitkDeformableRegistrationUserManual.dox +++ b/Plugins/org.mitk.gui.qt.registration/documentation/UserManual/QmitkDeformableRegistrationUserManual.dox @@ -1,52 +1,52 @@ /** \page org_mitk_views_deformableregistration The Deformable Image Registration View Available sections: - \ref DeformableRegistrationUserManualOverview - \ref DeformableRegistrationUserManualDetails \section DeformableRegistrationUserManualOverview Overview This view allows you to register 2D as well as 3D images in a deformable manner. Register means to align two images, so that they become as similar as possible. Registration results will directly be applied to the Moving Image. -\image html QmitkRegistration_DeformableRegistration_small.png "MITK with the DeformableRegistration view" +\imageMacro{QmitkRegistration_DeformableRegistration_small.png,"MITK with the DeformableRegistration view",16.00} This document will tell you how to use this view, but it is assumed that you already know how to navigate through the slices of an image using the multi-widget. \section DeformableRegistrationUserManualDetails Details First of all you have to open the data sets which you want to register and select them in the Data Manager. You have to select exactly 2 images for registration. The image which was selected first will become the fixed image, the other one the moving image. The two selected images will remain for registration until exactly two images were selected in the Data Manager again. While there aren't two images for registration a message is viewed on top of the view saying that registration needs two images. If two images are selected the message disappears and the interaction areas for the fixed and moving data appears. On default only the fixed and moving image are shown in the render windows. If you want to have other images visible you have to set the visibility via the Data Manager. Also if you want to perform a reinit on a specific node or a global reinit for all nodes you have to use the Data Manager. -\image html QmitkRegistration_ImageSelectionDeformable.png "The Image area" +\imageMacro{QmitkRegistration_ImageSelectionDeformable.png,"The Image area",7.56} The upper area is the "Image" area, where the selected images are shown. It is used for changing the colour of the images between grey values and red/green as well as for changing the opacity of the moving image. To do so, just use the "Moving Image Opacity:" slider. In the "Show Images Red/Green" you can switch the color from both datasets. If you check the box, the fixed dataset will be displayed in redvalues and the moving dataset in greenvalues to improve visibility of differences in the datasets. If you uncheck the "Show Images Red/Green" checkbox, both datasets will be displayed in greyvalues. -\image html QmitkRegistration_RegistrationDeformable.png "The Registration area for Demons based registration" +\imageMacro{QmitkRegistration_RegistrationDeformable.png,"The Registration area for Demons based registration",7.56} In the "Registration" area you have the choice between different Demonsbased deformable registration algorithms. There are available: \li Demons Registration \li Symmetric Forces Demons Registration For both methods you have to define the same set of parameters. First you have to decide whether you want to perform a histogram matching. This can be done by selecting "Use Histogram Matching". When it is selected the corresponding parameters are enabled and have to be set. These are the "Number of Histogram Levels", "Number of Match Points" and whether to use a "Threshold at Mean Intensity". For the registration method itself you have to specify the "Number of Iterations" and the "Standard Deviation" within the "Demons Registration" area. If all this is done, you can perform the registration by clicking the "Calculate Transformation" button. Finally, you will be asked where you want the result image and the resulting deformation field to be saved. Therefore you have to select the folder and enter a filename. The results will be added in the DataStorage and can be saved in the Data Manager. */ diff --git a/Plugins/org.mitk.gui.qt.registration/documentation/UserManual/QmitkPointBasedRegistrationUserManual.dox b/Plugins/org.mitk.gui.qt.registration/documentation/UserManual/QmitkPointBasedRegistrationUserManual.dox index f2f8a1ce79..9141b2b83b 100644 --- a/Plugins/org.mitk.gui.qt.registration/documentation/UserManual/QmitkPointBasedRegistrationUserManual.dox +++ b/Plugins/org.mitk.gui.qt.registration/documentation/UserManual/QmitkPointBasedRegistrationUserManual.dox @@ -1,106 +1,106 @@ /** \page org_mitk_views_pointbasedregistration The Point Based Registration View -\image html QmitkRegistration_PointBasedIcon.png "Icon of the View" +\imageMacro{QmitkRegistration_PointBasedIcon.png,"Icon of the View",2.00} Available sections: - \ref PointBasedRegistrationUserManualOverview - \ref PointBasedRegistrationUserManualDetails \section PointBasedRegistrationUserManualOverview Overview This view allows you to register two datasets in a rigid and deformable manner via corresponding PointSets. Register means to align two datasets, so that they become as similar as possible. Therefore you have to set corresponding points in both datasets, which will be matched. The movement, which has to be performed on the points to align them, will be performed on the moving data as well. The result is shown in the multi-widget. -\image html QmitkRegistration_PointBasedRegistration_small.png "MITK with the PointBasedRegistration view" +\imageMacro{QmitkRegistration_PointBasedRegistration_small.png,"MITK with the PointBasedRegistration view",16.00} This document will tell you how to use this view, but it is assumed that you already know how to navigate through the slices of a dataset using the multi-widget. \section PointBasedRegistrationUserManualDetails Details First of all you have to open the data sets which you want to register and select them in the Data Manager. You have to select exactly 2 images for registration. The image which was selected first will become the fixed image, the other one the moving image. The two selected images will remain for registration until exactly two images were selected in the Data Manager again. While there aren't two images for registration a message is viewed on top of the view saying that registration needs two images. If two images are selected the message disappears and the interaction areas for the fixed and moving data appears. The upper area is for interaction with the fixed data. Beneath this area is the interaction area for the moving data. On default only the fixed and moving image with their corresponding pointsets are shown in the render windows. If you want to have other images visible you have to set the visibility via the Data Manager. Also if you want to perform a reinit on a specific node or a global reinit for all nodes you have to use the Data Manager. -\image html QmitkRegistration_FixedDataPointBased.png "The Fixed Data area" +\imageMacro{QmitkRegistration_FixedDataPointBased.png,"The Fixed Data area",7.43} The "Fixed Data" area contains a QmitkPointListWidget. Within this widget, all points for the fixed data are listed. The label above this list shows the number of points that are already set. To set points you have to toggle the "Set Points" button, the leftmost under the QmitkPointListWidget. The views in the QmitkStdMultiWidget were reinitialized to the fixed data. Points can be defined by performing a left click while holding the "Shift"-key pressed in the QmitkStdMultiWidget. You can remove the interactor which listens for left clicks while holding the "Shift"-key pressed by detoggle the "Set Points" button. The next button, "Clear Point Set", is for deleting all specified points from this dataset. The user is prompted to confirm the decision. With the most right button, a previously saved point set can be loaded and all of its points are shown in the QmitkPointListWidget and in the QmitkStdMultiWidget. The user is prompted to select the file to be loaded. The file extension is ".mps". On the left of this button is the save button. With this function all points specified for this dataset and shown in the QmitkPointListWidget are saved to harddisk. The user is prompted to select a filename. Pointsets were saved in XML fileformat but have to have a ".mps" file extension. You can select landmarks in the render window with a left mouse button click on them. If you keep the mouse button pressed you can move the landmark to an other position by moving the mouse and then release the mouse button. With the delete key you can remove the selected landmarks. You can also select landmarks by a double click on a landmark within the QmitkPointListWidget. Using the "Up-Arrow"-button or the "F2" key you can easily move a landmark upwards and bring it further downwards by pressing "F3" or using the "Down-Arrow"-button. Thus the landmark number can be changed. The QmitkStdMultiWidget changes its view to show the position of the landmark. -\image html QmitkRegistration_MovingDataPointBased.png "The Moving Data area" +\imageMacro{QmitkRegistration_MovingDataPointBased.png,"The Moving Data area",7.45} The "Moving Data" area contains a QmitkPointListWidget. Within this widget, all points for the moving data are listed. The label above this list shows the number of points that are already set. To set points you have to toggle the "Set Points" button, the leftmost under the QmitkPointListWidget. The views in the QmitkStdMultiWidget were reinitialized to the moving data. With the "Opacity:" slider you can change the opacity of the moving dataset. If the slider is leftmost the moving dataset is totally transparent, whereas if it is rightmost the moving dataset is totally opaque. Points can be defined by performing a left click while holding the "Shift"-key pressed in the QmitkStdMultiWidget. You can remove the interactor which listens for left mousebutton click while holding the "Shift"-key pressed by detoggle the "Set Points" button. The next button, "Clear Point Set", is for deleting all specified points from this dataset. The user is prompted to confirm the decision. With the button on your right hand side, a previously saved point set can be loaded and all of its points are shown in the QmitkPointListWidget and in the QmitkStdMultiWidget. The user is prompted to select the file to be loaded. The file extension is ".mps". On the left of this button is the save button. With this function all points specified for this dataset and shown in the QmitkPointListWidget are saved to harddisk. The user is prompted to select a filename. Pointsets were saved in XML fileformat but have to have a ".mps" file extension. You can select landmarks in the render window with a left click on them. If you keep the mouse button pressed you can move the landmark to an other position by moving the mouse and then release the mouse button. With the delete key you can remove the selected landmarks. You can also select landmarks by a double click on a landmark within the QmitkPointListWidget. Using the "Up-Arrow"-button or the "F2" key you can easily move a landmark upwards and bring it further downwards by pressing "F3" or using the "Down-Arrow"-button. Thus the landmark number can be changed.The QmitkStdMultiWidget changes its view to show the position of the landmark. -\image html QmitkRegistration_DisplayOptionsPointBased.png "The Display Options area" +\imageMacro{QmitkRegistration_DisplayOptionsPointBased.png,"The Display Options area",7.49} In this area you can find the "Show Images Red/Green" checkbox. Here you can switch the color from both datasets. If you check the box, the fixed dataset will be displayed in redvalues and the moving dataset in greenvalues to improve visibility of differences in the datasets. If you uncheck the "Show Images Red/Green" checkbox, both datasets will be displayed in greyvalues. Before you perform your transformation it is useful to see both images again. Therefore detoggle the "Set Points" button for the fixed data as well as for the moving data. -\image html QmitkRegistration_RegistrationPointBased.png "The Registration area" +\imageMacro{QmitkRegistration_RegistrationPointBased.png,"The Registration area",7.45} The functions concerning the registration are displayed in the "Registration" area. It not only contains the registration method selection and the registration itself but also offers the possibility to save, undo or redo the results. Furthermore a display is implemented, which shows you how good the landmarks correspond. Those features will be explained in following paragraphs. Using the "Method"-selector, you can pick one of those transformations: Rigid, Similarity, Affine and LandmarkWarping. Depending on which one you chose, an additional specifier, "Use ICP" can be set, which leads to the following possibilities for registration: \li Rigid with ICP means only translation and rotation. The order of your landmarks will not be taken into account. E. g. landmark one in the fixed data can be mapped on landmark three in the moving data. You have to set at least one landmark in each dataset to enable the Register button which performs the transformation. \li Similarity with ICP means only translation, scaling and rotation. The order of your landmarks will not be taken into account. E. g. landmark one in the fixed data can be mapped on landmark three in the moving data. You have to set at least one landmark in each dataset to enable the Register button which performs the transformation. \li Affine with ICP means only translation, scaling, rotation and shearing. The order of your landmarks will not be taken into account. E. g. landmark one in the fixed data can be mapped on landmark three in the moving data. You have to set at least one landmark in each dataset to enable the Register button which performs the transformation. \li Rigid means only translation and rotation. The order of your landmarks will be taken into account. E. g. landmark one in the fixed data will be mapped on landmark one in the moving data. You have to set at least one landmark and the same number of landmarks in each dataset to enable the Register button which performs the transformation. \li Similarity means only translation, scaling and rotation. The order of your landmarks will be taken into account. E. g. landmark one in the fixed data will be mapped on landmark one in the moving data. You have to set at least one landmark and the same number of landmarks in each dataset to enable the Register button which performs the transformation. \li Affine means only translation, scaling, rotation and shearing. The order of your landmarks will be taken into account. E. g. landmark one in the fixed data will be mapped on landmark one in the moving data. You have to set at least one landmark and the same number of landmarks in each dataset to enable the Register button which performs the transformation. \li LandmarkWarping means a freeform deformation of the moving image, so that afterwards the landmarks are exactly aligned. The order of your landmarks will be taken into account. E. g. landmark one in the fixed data will be mapped on landmark one in the moving data. You have to set at least one landmark and the same number of landmarks in each dataset to enable the Register button which performs the transformation. The root mean squares difference between the landmarks will be displayed as number, so that you can check how good the landmarks correspond. The "Undo Transformation" button becomes enabled after performing a transformation and allows you to undo it. After doing this, the "Redo Transformation" button is enabled and lets you redo, the just undone transformation(no calculation needed) Saving of the transformed image can be done via the Data Manager. */ diff --git a/Plugins/org.mitk.gui.qt.registration/documentation/UserManual/QmitkRigidRegistrationUserManual.dox b/Plugins/org.mitk.gui.qt.registration/documentation/UserManual/QmitkRigidRegistrationUserManual.dox index 41293486e8..85749f9f63 100644 --- a/Plugins/org.mitk.gui.qt.registration/documentation/UserManual/QmitkRigidRegistrationUserManual.dox +++ b/Plugins/org.mitk.gui.qt.registration/documentation/UserManual/QmitkRigidRegistrationUserManual.dox @@ -1,214 +1,214 @@ /** \page org_mitk_views_rigidregistration The Rigid Registration View -\image html QmitkRegistration_RigidRegistrationIcon.png "Icon of the View" +\imageMacro{QmitkRegistration_RigidRegistrationIcon.png,"Icon of the View",2.00} Available sections: - \ref QmitkRigidRegistrationUserManualOverview - \ref QmitkRigidRegistrationUserManualIssues - \ref QmitkRigidRegistrationUserManualDetails - \ref QmitkRigidRegistrationUserManualReferences \section QmitkRigidRegistrationUserManualOverview Overview This view allows you to register 2D as well as 3D images in a rigid manner. If the Moving Image is an image with multiple timesteps you can select one timestep for registration. Register means to align two images, so that they become as similar as possible. Therefore you can select from different transforms, metrics and optimizers. Registration results will directly be applied to the Moving Image. Also binary images as image masks can be used to restrict the metric evaluation only to the masked area. -\image html QmitkRegistration_RigidRegistration_small.png "MITK with the QmitkRigidRegistration view" +\imageMacro{QmitkRegistration_RigidRegistration_small.png,"MITK with the QmitkRigidRegistration view",16.00} This document will tell you how to use this view, but it is assumed that you already know how to navigate through the slices of an image using the multi-widget. \section QmitkRigidRegistrationUserManualIssues Known Issues Depending on your system the registration can fail to allocate memory for calculating the gradient image for registration. In this case you can try to select another optimizer which is not based on a gradient image and uncheck the checkbox for "Compute Gradient". \section QmitkRigidRegistrationUserManualDetails Details First of all you have to open the data sets which you want to register and select them in the Data Manager. You have to select exactly 2 images for registration. The image which was selected first will become the fixed image, the other one the moving image. The two selected images will remain for registration until exactly two images were selected in the Data Manager again. -\image html QmitkRegistration_ImageArea.png "The Image area" +\imageMacro{QmitkRegistration_ImageArea.png,"The Image area",7.34} While there aren't two images for registration a message is viewed on top of the view saying that registration needs two images. If two images are selected the message disappears and the interaction areas for the fixed and moving data appears. If both selected images have a binary image as childnode a selection box appears which allows, when checked, to use the binary images as image mask to restrict the registration on this certain area. If an image has more than one binary image as child, the upper one from the DataManager list is used. If the Moving Image is a dynamic images with several timesteps a slider appears to select a specific timestep for registration. On default only the fixed and moving image are shown in the render windows. If you want to have other images visible you have to set the visibility via the Data Manager. Also if you want to perform a reinit on a specific node or a global reinit for all nodes you have to use the Data Manager. The colour of the images can be changed between grey values and red/green and the opacity of the moving image can be changed. With the "Moving Image Opacity:" slider you can change the opacity of the moving dataset. In the "Show Images Red/Green" you can switch the color from both datasets. If you check the box, the fixed dataset will be displayed in red-values and the moving dataset in green-values to improve visibility of differences in the datasets. If you uncheck the "Show Images Red/Green" checkbox, both datasets will be displayed in grey-values. -\image html QmitkRegistration_RegistrationArea.png "The Registration area" +\imageMacro{QmitkRegistration_RegistrationArea.png,"The Registration area",7.49} In the "Register" area you can start the registration by clicking the "Calculate Transform" button. The optimizer value for every iteration step is diplayed as LCD number next to the "Optimizer Value:" label. Many of the registration methods can be canceled during their iteration steps by clicking the "Stop Optimization" button. During the calculation, a progress bar indicates the progress of the registration process. The render widgets are updated for every single iteration step, so that the user has the chance to supervise how good the registration process works with the selected methods and parameters. If the registration process does not lead to a sufficient result, it is possible to undo the transformation and restart the registration process with some changes in parameters. The differences in transformation due to the changed parameters can be seen in every iteration step and help the user understand the parameters. Also the optimizer value is updated for every single iteration step and shown in the GUI. The optimizer value is an indicator for the misalignment between the two images. The real time visualization of the registration as well as the optimizer value provides the user with information to trace the improvement through the optimization process. The "Undo Transformation" button becomes enabled when you have performed an transformation and you can undo the performed transformations. The "Redo Transformation" button becomes enabled when you have performed an undo to redo the transformation without to recalculate it. -\image html QmitkRegistration_ManualRegistrationArea.png "The Manual Registration area" +\imageMacro{QmitkRegistration_ManualRegistrationArea.png,"The Manual Registration area",5.95} In the "Manual Registration" area, shown by checking the checkbox Manual Registration, you can manually allign the images by moving sliders for translation and scaling in x-, y- and z-axis as well as for rotation around the x-, y- and z-Axis. Additionally you can automatically allign the image centers with the button "Automatic Allign Image Centers". -\image html QmitkRegistration_Tab2.png "The Advanced Mode tab" +\imageMacro{QmitkRegistration_Tab2.png,"The Advanced Mode tab",7.54} In the "Advanced Mode" tab you can choose a transform, a metric, an optimizer and an interpolator and you have to set the corresponding parameters to specify the registration method you want to perform. With the topmost button you can also load testpresets. These presets contain all parametersets which were saved using the "Save as Testpreset" button. The "Save as Preset" button makes the preset available from the "Automatic Registration" tab. This button should be used when a preset is not intended for finding good parameters anymore but can be used as standard preset. To show the current transform and its parameters for the registration process, the Transform checkbox has to be checked. Currently, the following transforms are implemented (for detailed information see [1] and [2]): \li Translation: Transformation by a simple translation for every dimension. \li Scale: Transformation by a certain scale factor for each dimension. \li ScaleLogarithmic: Transformation by a certain scale factor for each dimension. The parameter factors are passed as logarithms. \li Affine: Represents an affine transform composed of rotation, scaling, shearing and translation. \li FixedCenterOfRotationAffine: Represents an affine transform composed of rotation around a user provided center, scaling, shearing and translation. \li Rigid3D: Represents a 3D rotation followed by a 3D translation. \li Euler3D: Represents a rigid rotation in 3D space. That is, a rotation followed by a 3D translation. \li CenteredEuler3D: Represents a rigid rotation in 3D space around a user provided center. That is, a rotation followed by a 3D translation. \li QuaternionRigid: Represents a 3D rotation and a 3D translation. The rotation is specified as a quaternion. \li Versor: Represents a 3D rotation. The rotation is specified by a versor or unit quaternion. \li VersorRigid3D: Represents a 3D rotation and a 3D translation. The rotation is specified by a versor or unit quaternion. \li ScaleSkewVersor3D: Represents a 3D translation, scaling, shearing and rotation. The rotation is specified by a versor or unit quaternion. \li Similarity3D: Represents a 3D rotation, a 3D translation and homogeneous scaling. \li Rigid2D: Represents a 2D rotation followed by a 2D translation. \li CenteredRigid2D: Represents a 2D rotation around a user provided center followed by a 2D translation. \li Euler2D: Represents a 2D rotation and a 2D translation. \li Similarity2D: Represents a 2D rotation, homogeneous scaling and a 2D translation. \li CenteredSimilarity2D: Represents a 2D rotation around a user provided center, homogeneous scaling and a 2D translation. The desired transform can be chosen from a combo box. All parameters defining the selected transform have to be specified within the line edits and checkboxes underneath the transform combo box. To show the current metric and its parameters for the registration process, the Metric checkbox has to be checked. Currently, the following metrics are implemented (for detailed information see [1] and [2]): \li MeanSquares: Computes the mean squared pixel-wise difference in intensity between image A and B. \li NormalizedCorrelation: Computes pixel-wise cross correlation and normalizes it by the square root of the autocorrelation of the images. \li GradientDifference: Evaluates the difference in the derivatives of the moving and fixed images. \li KullbackLeiblerCompareHistogram[3]: Measures the relative entropy between two discrete probability distributions. \li CorrelationCoefficientHistogram: Computes the cross correlation coefficient between the intensities. \li MeanSquaresHistogram: The joint histogram of the fixed and the mapped moving image is built first. Then the mean squared pixel-wise difference in intensity between image A and B is calculated. \li MutualInformationHistogram: Computes the mutual information between image A and image B. \li NormalizedMutualInformationHistogram: Computes the mutual information between image A and image B. \li MattesMutualInformation[4, 5]: The method of Mattes et al. is used to compute the mutual information between two images to be registered. \li MeanReciprocalSquareDifference: Computes pixel-wise differences and adds them after passing them through a bell-shaped function 1 / (1+x^2). \li MutualInformation[6]: Computes the mutual information between image A and image B. \li MatchCardinality: Computes cardinality of the set of pixels that match exactly between the moving and fixed images. \li KappaStatistic[7]: Computes spatial intersection of two binary images. The desired metric can be chosen from a combo box. All parameters defining the selected metric have to be specified within the line edits and checkboxes underneath the metric combo box. To show the current optimizer and its parameters for the registration process, the Optimizer checkbox has to be checked. Currently, the following optimizers are implemented (for detailed information see [1] and [2]): \li Exhaustive: Fully samples a grid on the parametric space. \li GradientDescent: A simple gradient descent optimizer. \li QuaternionRigidTransformGradientDescent: Variant of a gradient descent optimizer. \li LBFGSB[8, 9]: Limited memory Broyden Fletcher Goldfarb Shannon minimization with simple bounds. \li OnePlusOneEvolutionary[10]: 1+1 evolutionary strategy. \li Powell: Implements Powell optimization using Brent line search. \li FRPR: Fletch-Reeves & Polak-Ribiere optimization using dBrent line search. \li RegularStepGradientDescent: Variant of a gradient descent optimizer. \li VersorTransform: Variant of a gradient descent optimizer. \li Amoeba: Implementation of the Nelder-Meade downhill simplex algorithm. \li ConjugateGradient: Used to solve unconstrained optimization problems. \li LBFGS: Limited memory Broyden Fletcher Goldfarb Shannon minimization. \li SPSA[11]: Based on simultaneous perturbation. \li VersorRigid3DTransform: Variant of a gradient descent optimizer for the VersorRigid3DTransform parameter space. The desired optimizer can be chosen from a combo box. All parameters defining the selected optimizer have to be specified within the line edits and checkboxes underneath the optimizer combo box. To show the current interpolator for the registration process, just check the Interpolator checkbox. Currently, the following interpolators are implemented (for detailed information see [1] and [2]): \li Linear: Intensity varies linearly between grid positions. \li NearestNeighbor: Uses the intensity of the nearest grid position. You can show and hide the parameters for the selection by checking or unchecking the corresponding area. You can save the current sets of parameters with the "Save as Testpreset" or "Save as Preset" buttons. \section QmitkRigidRegistrationUserManualReferences References: 1. L. Ibanez, W. Schroeder and K. Ng, The ITK Software Guide, Kitware Inc, New York, 2005. 2. http://www.itk.org/Doxygen/ 3. Albert C.S. Chung, William M. Wells III, Alexander Norbash, and W. Eric L. Grimson, Multi-modal Image Registration by Minimising Kullback-Leibler Distance, In Medical Image Computing and Computer-Assisted Intervention - MICCAI 2002, LNCS 2489, pp. 525 - 532. 4. D. Mattes, D. R. Haynor, H. Vesselle, T. Lewellen and W. Eubank, "Nonrigid multimodality image registration", Medical Imaging 2001: Image Processing, 2001, pp. 1609-1620. 5. D. Mattes, D. R. Haynor, H. Vesselle, T. Lewellen and W. Eubank, "PET-CT Image Registration in the Chest Using Free-form Deformations", IEEE Transactions in Medical Imaging. Vol.22, No.1, January 2003, pp.120-128. 6. Viola, P. and Wells III, W. (1997). "Alignment by Maximization of Mutual Information" International Journal of Computer Vision, 24(2):137-154. 7. AP Zijdenbos, BM Dawant, RA Margolin , AC Palmer, Morphometric analysis of white matter lesions in MR images: Method and validation, IEEE Transactions on Medical Imaging, 13(4):716-724, Dec. 1994. 8. R. H. Byrd, P. Lu and J. Nocedal. A Limited Memory Algorithm for Bound Constrained Optimization, (1995), SIAM Journal on Scientific and Statistical Computing , 16, 5, pp. 1190-1208. 9. C. Zhu, R. H. Byrd and J. Nocedal. L-BFGS-B: Algorithm 778: L-BFGS-B, FORTRAN routines for large scale bound constrained optimization (1997), ACM Transactions on Mathematical Software, Vol 23, Num. 4, pp. 550 - 560. 10. Martin Styner, G. Gerig, Christian Brechbuehler, Gabor Szekely, "Parametric estimate of intensity inhomogeneities applied to MRI", IEEE TRANSACTIONS ON MEDICAL IMAGING; 19(3), pp. 153-165, 2000. 11. Spall, J.C. (1998), "An Overview of the Simultaneous Perturbation Method for Efficient Optimization," Johns Hopkins APL Technical Digest, vol. 19, pp. 482-492. */ diff --git a/Plugins/org.mitk.gui.qt.remeshing/documentation/UserManual/QmitkRemashing.dox b/Plugins/org.mitk.gui.qt.remeshing/documentation/UserManual/QmitkRemashing.dox index 5bc4e02788..479aca2342 100644 --- a/Plugins/org.mitk.gui.qt.remeshing/documentation/UserManual/QmitkRemashing.dox +++ b/Plugins/org.mitk.gui.qt.remeshing/documentation/UserManual/QmitkRemashing.dox @@ -1,71 +1,71 @@ /** \page org_mitk_gui_qt_remeshing The Remeshing Plugin -\image html QmitkRemashing_Icon.png "Icon of the Remeshing Plugin." +\imageMacro{QmitkRemashing_Icon.png,"Icon of the Remeshing Plugin.",2.00} \tableofcontents \section org_mitk_gui_qt_remeshingOverview Overview The Remeshing View allows you to remesh surfaces. If done right, remeshing can dramatically increase the quality of your surface mesh. However, you might lose precision if you reduce your surface mesh too strong. Even when you keep the detail of your mesh there might be a tiny distance between your original surface and the remeshed surface. Hence, be careful when using remeshed surfaces for evaluation purposes and always keep the original versions. \section org_mitk_gui_qt_remeshingUsage Usage -\image html QmitkRemashing_RemeshingView.png "Basic and advanced mode of the Remeshing View." +\imageMacro{QmitkRemashing_RemeshingView.png,"Basic and advanced mode of the Remeshing View.",13.29} There are two basic and about a handful of advanced settings that influence remeshing. Most of the time you should be able to gain satisfying results by adjusting only the two basic settings or even without changing any of the default parameters. In the following the effects of all settings are described in more detail. Image examples are based on the following surface: -\image html QmitkRemashing_OriginalMesh.png "The surface from which all examples below originate from." +\imageMacro{QmitkRemashing_OriginalMesh.png,"The surface from which all examples below originate from.",10.08} \subsection org_mitk_gui_qt_remeshingBasicSettings Basic Settings The Vertices setting is the number of vertices the remeshed surface will consist of. This is exact as long as Boundary fixing is turned off (default). The maximum number of vertices is limited to the number of vertices of the input surface, however, you can increase this limit by adjusting the Max. # of vertices setting. The Gradation setting controls the distribution of vertices in the remeshed surface. If set to zero the vertices are distributed equally all over the remeshed surface. You can push more vertices towards surface regions with high curvature, i.e., more detailed regions, by increasing this setting. -\image html QmitkRemashing_Gradation10Percent.png "Vertex count reduced to 10 percent, gradation 0 vs. 1." +\imageMacro{QmitkRemashing_Gradation10Percent.png,"Vertex count reduced to 10 percent\, gradation 0 vs. 1.",16.00} \subsection org_mitk_gui_qt_remeshingAdvancedSettings Advanced Settings You can arbirarily increase the maximum adjustable number of vertices by changing the Max. # of vertices setting. Edge splitting is disabled by default and might take a long time during remeshing when enabled. This setting represents a number by which the average edge length of the input surface is multiplied to serve as a threshold which regulates edge splitting. Long edges are split recursively until all edges satisfy the threshold. Edge splitting is useful for surfaces that contain thin and long polygons. -\image html QmitkRemashing_Cylinder.png "A surface that contains extremely long polygons." +\imageMacro{QmitkRemashing_Cylinder.png,"A surface that contains extremely long polygons.",16.00}
-\image html QmitkRemashing_CylinderBad.png "A remeshing attempt without edge splitting." +\imageMacro{QmitkRemashing_CylinderBad.png,"A remeshing attempt without edge splitting.",16.00}
-\image html QmitkRemashing_CylinderGood.png "Increased max. # of vertices, enabled edge splitting, followed by a second remeshing run without edge splitting." +\imageMacro{QmitkRemashing_CylinderGood.png,"Increased max. # of vertices\, enabled edge splitting\, followed by a second remeshing run without edge splitting.",16.00} The Subsampling setting has direct impact on the quality of the remeshed surface. The input surface is recursively subdivided until the total number of vertices exceeds its initial vertex count times this setting. -\image html QmitkRemashing_Subsampling20Percent.png "Vertex count reduced to 20 percent, subsampling 10 vs. 500." +\imageMacro{QmitkRemashing_Subsampling20Percent.png,"Vertex count reduced to 20 percent\, subsampling 10 vs. 500.",16.00} You usually leave the Optimization level set to its default value 1. When disabled, the remeshed surface has usually a slightly smaller volume than the original surface. The optimization process minimizes the distance between the two surfaces but values higher than 1 introduce degenerated triangles to the remeshed surface. If your surface is open, i.e., it has holes in it, boundaries tend to shrink irregularly during remeshing. If the position and smoothness of your surface boundaries are important, you should activate the Boundary fixing setting. This results in additional vertices that make up extra polygons at the remeshed boundaries to keep the original boundaries. -\image html QmitkRemashing_NoBoundaryFixing10Percent.png "Vertex count reduced to 10 percent, no boundary fixing." +\imageMacro{QmitkRemashing_NoBoundaryFixing10Percent.png,"Vertex count reduced to 10 percent\, no boundary fixing.",10.08} */ diff --git a/Plugins/org.mitk.gui.qt.segmentation/documentation/UserManual/QmitkSegmentation.dox b/Plugins/org.mitk.gui.qt.segmentation/documentation/UserManual/QmitkSegmentation.dox index 6127896a07..a7e277595c 100644 --- a/Plugins/org.mitk.gui.qt.segmentation/documentation/UserManual/QmitkSegmentation.dox +++ b/Plugins/org.mitk.gui.qt.segmentation/documentation/UserManual/QmitkSegmentation.dox @@ -1,290 +1,290 @@ /** \page org_mitk_views_segmentation The Segmentation Plugin -\image html QmitkSegmentation_Icon.png "Icon of the Plugin" +\imageMacro{QmitkSegmentation_Icon.png,"Icon of the Plugin",2.00} Some of the features described below are closed source additions to the open source toolkit MITK and are not available in every application. \tableofcontents \section org_mitk_gui_qt_segmentationUserManualOverview Overview The Segmentation perspective allows you to create segmentations of anatomical and pathological structures in medical images of the human body. The perspective groups a number of tools which can be used for:
  • (semi-)automatic segmentation of organs on CT or MR image volumes
  • semi-automatic segmentation of lesions such as enlarged lymph nodes or tumors
  • manual segmentation of any structures you might want to delineate
-\image html QmitkSegmentation_IMGApplication.png "Segmentation perspective consisting of the Data Manager view and the Segmentation view" +\imageMacro{QmitkSegmentation_IMGApplication.png,"Segmentation perspective consisting of the Data Manager view and the Segmentation view",16.00} If you wonder what segmentations are good for, we shortly revisit the concept of a segmentation here. A CT or MR image is made up of volume of physical measurements (volume elements are called voxels). In CT images, for example, the gray value of each voxel corresponds to the mass absorbtion coefficient for X-rays in this voxel, which is similar in many %parts of the human body. The gray value does not contain any further information, so the computer does not know whether a given voxel is part of the body or the background, nor can it tell a brain from a liver. However, the distinction between a foreground and a background structure is required when:
  • you want to know the volume of a given organ (the computer needs to know which %parts of the image belong to this organ)
  • you want to create 3D polygon visualizations (the computer needs to know the surfaces of structures that should be drawn)
  • as a necessary pre-processing step for therapy planning, therapy support, and therapy monitoring
Creating this distinction between foreground and background is called segmentation. The Segmentation perspective of the MITK Workbench uses a voxel based approach to segmentation, i.e. each voxel of an image must be completely assigned to either foreground or background. This is in contrast to some other applications which might use an approach based on contours, where the border of a structure might cut a voxel into two %parts. The remainder of this document will summarize the features of the Segmentation perspective and how they are used. \section org_mitk_gui_qt_segmentationUserManualTechnical Technical Issues The Segmentation perspective makes a number of assumptions. To know what this view can be used for, it will help you to know that:
  • Images must be 2D, 3D, or 3D+t
  • Images must be single-values, i.e. CT, MRI or "normal" ultrasound. Images from color doppler or photographic (RGB) images are not supported
  • Segmentations are handled as binary images of the same extent as the original image
\section org_mitk_gui_qt_segmentationUserManualImageSelection Image Selection The Segmentation perspective makes use of the Data Manager view to give you an overview of all images and segmentations. -\image html QmitkSegmentation_IMGSelection.png Data Manager is used for selecting the current segmentation. The reference image is selected in the drop down box of the control area. +\imageMacro{QmitkSegmentation_IMGSelection.png,"Data Manager is used for selecting the current segmentation. The reference image is selected in the drop down box of the control area.",5.50} To select the reference image (e.g. the original CT/MR image) use the drop down box in the control area of the Segmentation view. The segmentation image selected in the Data Manager is displayed below the drop down box. If no segmentation image exists or none is selected create a new segmentation image by using the "New segmentation" button. Some items of the graphical user interface might be disabled when no image is selected. In any case, the application will give you hints if a selection is needed. \section org_mitk_gui_qt_segmentationUserManualManualKringeling Manual Contouring With manual contouring you define which voxels are part of the segmentation and which are not. This allows you to create segmentations of any structeres that you may find in an image, even if they are not part of the human body. You might also use manual contouring to correct segmentations that result from sub-optimal automatic methods. The drawback of manual contouring is that you might need to define contours on many 2D slices. However, this is moderated by the interpolation feature, which will make suggestions for a segmentation. \subsection org_mitk_gui_qt_segmentationUserManualManualKringeling1 Creating New Segmentations Unless you want to edit existing segmentations, you have to create a new, empty segmentation before you can edit it. To do so, click the "New manual segmentation" button. Input fields will appear where you can choose a name for the new segmentation and a color for its display. Click the checkmark button to confirm or the X button to cancel the new segmentation. Notice that the input field suggests names once you %start typing and that it also suggests colors for known organ names. If you use names that are not yet known to the application, it will automatically remember these names and consider them the next time you create a new segmentation. Once you created a new segmentation, you can notice a new item with the "binary mask" icon in the Data Manager tree view. This item is automatically selected for you, allowing you to %start editing the new segmentation right away. \subsection org_mitk_gui_qt_segmentationUserManualManualKringeling2 Selecting Segmentations for Editing As you might want to have segmentations of multiple structures in a single patient image, the application needs to know which of them to use for editing. You select a segmenation by clicking it in the tree view of Data Manager. Note that segmentations are usually displayed as sub-items of "their" patient image. In the rare case, where you need to edit a segmentation that is not displayed as a a sub-item, you can click both the original image AND the segmentation while holding down CTRL or for Mac OS X the CMD on the keyboard. When a selection is made, the Segmentation View will hide all but the selected segmentation and the corresponding original image. When there are multiple segmentations, the unselected ones will remain in the Data Manager, you can make them visible at any time by selecting them. \subsection org_mitk_gui_qt_segmentationUserManualManualKringeling3 Selecting Editing Tools If you are familiar with the MITK Workbench, you know that clicking and moving the mouse in any of the 2D render windows will move around the crosshair that defines what part of the image is displayed. This behavior is disabled while any of the manual segmentation tools are active -- otherwise you might have a hard time concentrating on the contour you are drawing. To %start using one of the editing tools, click its button the the displayed toolbox. The selected editing tool will be active and its corresponding button will stay pressed until you click the button again. Selecting a different tool also deactivates the previous one. If you have to delineate a lot of images, you should try using shortcuts to switch tools. Just hit the first letter of each tool to activate it (A for Add, S for Subtract, etc.). \subsection org_mitk_gui_qt_segmentationUserManualManualKringeling4 Using Editing Tools All of the editing tools work by the same principle: you use the mouse (left button) to click anywhere in a 2D window (any of the orientations axial, sagittal, or frontal), move the mouse while holding the mouse button and release to finish the editing action. Multi-step undo and redo is fully supported by all editing tools. Use the application-wide undo button in the toolbar to revert erroneous %actions. -\image html QmitkSegmentation_IMGIconAddSubtract.png Add and Subtract Tools +\imageMacro{QmitkSegmentation_IMGIconAddSubtract.png,"Add and Subtract Tools",7.70} Use the left mouse button to draw a closed contour. When releasing the mouse button, the contour will be added (Add tool) to or removed from (Subtract tool) the current segmentation. Hold down the CTRL / CMD key to invert the operation (this will switch tools temporarily to allow for quick corrections). -\image html QmitkSegmentation_IMGIconPaintWipe.png Paint and Wipe Tools +\imageMacro{QmitkSegmentation_IMGIconPaintWipe.png,"Paint and Wipe Tools",7.68} Use the slider below the toolbox to change the radius of these round paintbrush tools. Move the mouse in any 2D window and press the left button to draw or erase pixels. As the Add/Subtract tools, holding CTRL / CMD while drawing will invert the current tool's behavior. -\image html QmitkSegmentation_IMGIconRegionGrowing.png Region Growing Tool +\imageMacro{QmitkSegmentation_IMGIconRegionGrowing.png,"Region Growing Tool",3.81} Click at one point in a 2D slice widget to add an image region to the segmentation with the region growing tool. Moving up the cursor while holding the left mouse button widens the range for the included grey values; moving it down narrows it. When working on an image with a high range of grey values, the selection range can be influenced more strongly by moving the cursor at higher velocity. Region Growing selects all pixels around the mouse cursor that have a similar gray value as the pixel below the mouse cursor. This enables you to quickly create segmentations of structures that have a good contrast to surrounding tissue, e.g. the lungs. The tool will select more or less pixels (corresponding to a changing gray value interval width) when you move the mouse up or down while holding down the left mouse button. A common issue with region growing is the so called "leakage" which happens when the structure of interest is connected to other pixels, of similar gray values, through a narrow "bridge" at the border of the structure. The Region Growing tool comes with a "leakage detection/removal" feature. If leakage happens, you can left-click into the leakage region and the tool will try to automatically remove this region (see illustration below). -\image html QmitkSegmentation_IMGLeakage.png Leakage correction feature of the Region Growing tool +\imageMacro{QmitkSegmentation_IMGLeakage.png,"Leakage correction feature of the Region Growing tool",11.28}
-\image html QmitkSegmentation_IMGIconCorrection.png Correction Tool +\imageMacro{QmitkSegmentation_IMGIconCorrection.png,"Correction Tool",3.77} You do not have to draw a closed contour to use the Correction tool and do not need to switch between the Add and Substract tool to perform small corrective changes. The following figure shows the usage of this tool:
  • if the user draws a line which %starts and ends outside the segmenation AND it intersects no other segmentation the endpoints of the line are connected and the resulting contour is filled
  • if the user draws a line which %starts and ends outside the segmenation a part of it is cut off (left image)
  • if the line is drawn fully inside the segmentation the marked region is added to the segmentation (right image)
-\image html QmitkSegmentation_IMGCorrectionActions.png %Actions of the Correction tool illustrated. +\imageMacro{QmitkSegmentation_IMGCorrectionActions.png,"%Actions of the Correction tool illustrated.",13.50}
-\image html QmitkSegmentation_IMGIconFill.png Fill Tool +\imageMacro{QmitkSegmentation_IMGIconFill.png,"Fill Tool",3.81} Left-click inside a segmentation with holes to completely fill all holes. -\image html QmitkSegmentation_IMGIconErase.png Erase Tool +\imageMacro{QmitkSegmentation_IMGIconErase.png,"Erase Tool",3.79} This tool removes a connected part of pixels that form a segmentation. You may use it to remove so called islands (see picture) or to clear a whole slice at once (hold CTRL while clicking). -\image html QmitkSegmentation_IMGIconLiveWire.png LiveWire Tool +\imageMacro{QmitkSegmentation_IMGIconLiveWire.png,"LiveWire Tool",3.01} The LiveWire Tool acts as a magnetic lasso with a contour snapping to edges of objects. -\image html QmitkSegmentation_IMGLiveWireUsage.png Steps for using LiveWire Tool +\imageMacro{QmitkSegmentation_IMGLiveWireUsage.png,"Steps for using LiveWire Tool",16.00}
  • (1) To start the Tool you have to double click near the edge of the object you want to segment. The initial anchor point will snap to the edge within a 3x3 region.
  • (2) Move the mouse. You don't have trace the edge of the object. The contour will automatically snap to it.
  • (3) To fix a segment you can set anchor points by single left mouse button click.
  • (4) Go on with moving the mouse and setting anchor points.
  • (5) To close the contour double click on the initial anchor point.
  • (6) After closing the contour can be edited by moving, inserting and deleting anchor points.
The contour will be transfered to its binary image representation by deactivating the tool. \subsection org_mitk_gui_qt_segmentationUserManualManualKringeling5 Interpolation Creating segmentations for modern CT volumes is very time-consuming, because structures of interest can easily cover a range of 50 or more slices. The Manual Segmentation View offers two helpful features for these cases:
  • 3D Interpolation
  • 2D Interpolation

The 3D interpolation is activated by default when using the manual segmentation tools. That means if you start contouring, from the second contour onwards, the surface of the segmented area will be interpolated based on the given contour information. The interpolation works with all available manual tools. Please note that this is currently a pure mathematical interpolation, i.e. image intensity information is not taken into account. With each further contour the interpolation result will be improved, but the more contours you provide the longer the recalculation will take. To achieve an optimal interpolation result and in this way a most accurate segmentation you should try to describe the surface with sparse contours by segmenting in arbitrary oriented planes. The 3D interpolation is not meant to be used for parallel slice-wise segmentation. -\image html QmitkSegmentation_3DInterpolationWrongRight.png 3D Interpolation HowTo +\imageMacro{QmitkSegmentation_3DInterpolationWrongRight.png,"3D Interpolation HowTo",16.00} You can accept the interpolation result by clicking the "Accept" - button below the tool buttons. In this case the 3D interpolation will be deactivated automatically so that the result can be postprocessed without any interpolation running in background. During recalculation the interpolated surface is blinking yellow/white. When the interpolation has finished the surface is shown yellow with a small opacity. Additional to the surface, black contours are shown in the 3D render window. They mark the positions of all the drawn contours which were used for the interpolation. You can navigate between the drawn contours by clicking on the „Position“ - Nodes in the datamanager which are located below the selected segmentation. If you don't want to see these nodes just unckeck the „Show Position Nodes“ Checkbox and these nodes will be hidden. If you want to delete a drawn contour we recommend to use the Erase-Tool since Redo/Undo is not yet working for 3D interpolation.
The 2D Interpolation creates suggestions for a segmentation whenever you have a slice that
  • has got neighboring slices with segmentations (these do not need to be direct neighbors but could also be a couple of slices away) AND
  • is completely clear of a manual segmentation -- i.e. there will be no suggestion if there is even only a single pixel of segmentation in the current slice.
Interpolated suggestions are displayed in a different way than manual segmentations are, until you "accept" them as part of the segmentation. To accept single slices, click the "Accept" button below the toolbox. If you have segmented a whole organ in every-x-slice, you may also review the interpolations and then accept all of them at once by clicking "... all slices". \section org_mitk_gui_qt_segmentationUserManualOrganSegmentation Organ Segmentation \note This feature is only available in our 3M3 Demo Application (http://www.mint-medical.de/productssolutions/mitk3m3/mitk3m3/#downloads) but not in the open source part of MITK The manual contouring described above is a fallback option that will work for any kind of images and structures of interest. However, manual contouring is very time-consuming and tedious. This is why a major part of image analysis research is working towards automatic segmentation methods. The Segmentation View comprises a number of easy-to-use tools for segmentation of CT images (Liver) and MR image (left ventricle and wall, left and right lung). \subsection org_mitk_gui_qt_segmentationUserManualOrganSegmentation1 Liver on CT Images On CT image volumes, preferrably with a contrast agent in the portal venous phase, the Liver tool will fully automatically analyze and segment the image. All you have to do is to load and select the image, then click the "Liver" button. During the process, which takes a minute or two, you will get visual progress feedback by means of a contour that moves closer and closer to the real liver boundaries. \subsection org_mitk_gui_qt_segmentationUserManualOrganSegmentation2 Heart, Lung, and Hippocampus on MRI While liver segmentation is performed fully automatic, the following tools for segmentation of the heart, the lungs, and the hippocampus need a minimum amount of guidance. Click one of the buttons on the "Organ segmentation" page to add an average %model of the respective organ to the image. This %model can be dragged to the right position by using the left mouse button while holding down the CTRL key. You can also use CTRL + middle mouse button to rotate or CTRL + right mouse button to scale the %model. Before starting the automatic segmentation process by clicking the "Start segmentation" button, try placing the %model closely to the organ in the MR image (in most cases, you do not need to rotate or scale the %model). During the segmentation process, a green contour that moves closer and closer to the real liver boundaries will provide you with visual feedback of the segmentation progress. The algorithms used for segmentation of the heart and lung are method which need training by a number of example images. They will not work well with other kind of images, so here is a list of the image types that were used for training:
  • Hippocampus segmentation: T1-weighted MR images, 1.5 Tesla scanner (Magnetom Vision, Siemens Medical Solutions), 1.0 mm isotropic resolution
  • Heart: Left ventricle inner segmentation (LV Model): MRI; velocity encoded cine (VEC-cine) MRI sequence; trained on systole and diastole
  • Heart: Left ventricular wall segmentation (LV Inner Wall, LV Outer Wall): 4D MRI; short axis 12 slice spin lock sequence(SA_12_sl); trained on whole heart cycle
  • Lung segmentation: 3D and 4D MRI; works best on FLASH3D and TWIST4D sequences
\subsection org_mitk_gui_qt_segmentationUserManualOrganSegmentation99 Other Organs As mentioned in the Heart/Lung section, most of the underlying methods are based on "training". The basic algorithm is versatile and can be applied on all kinds of segmentation problems where the structure of interest is topologically like a sphere (and not like a torus etc.). If you are interested in other organs than those offered by the current version of the Segmentation view, please contact our research team. \section org_mitk_gui_qt_segmentationUserManualLesionSegmentation Lesion Segmentation \note This feature is only available in our 3M3 Demo Application (http://www.mint-medical.de/productssolutions/mitk3m3/mitk3m3/#downloads) but not in the open source part of MITK Lesion segmentation is a little different from organ segmentation. Since lesions are not part of the healthy body, they sometimes have a diffused border, and are often found in varying places all over the body. The tools in this section offer efficient ways to create 3D segmentations of such lesions. The Segmentation View currently offers supoprt for enlarged lymph nodes. To segment an enlarged lymph node, find a more or less central slice of it, activate the "Lymph Node" tool and draw a rough contour on the inside of the lymph node. When releaseing the mouse button, a segmentation algorithm is started in a background task. The result will become visible after a couple of seconds, but you do not have to wait for it. If you need to segment several lymph nodes, you can continue to inspect the image right after closing the drawn contour. If the lymph node segmentation is not to your content, you can select the "Lymph Node Correction" tool and drag %parts of the lymph node surface towards the right position (works in 3D, not slice-by-slice). This kind of correction helps in many cases. If nothing else helps, you can still use the pure manual tools as a fallback. \section org_mitk_gui_qt_segmentationUserManualPostprocessing Things you can do with segmentations As mentioned in the introduction, segmentations are never an end in themselves. Consequently, the Segmentation view adds a couple of "post-processing" %actions to the Data Manager. These %actions are accessible through the context-menu of segmentations in Data Manager's list view -\image html QmitkSegmentation_IMGDataManagerContextMenu.png Context menu items for segmentations. +\imageMacro{QmitkSegmentation_IMGDataManagerContextMenu.png,"Context menu items for segmentations.",10.58}
  • Create polygon %model applies the marching cubes algorithms to the segmentation. This polygon %model can be used for visualization in 3D or other things such as stereolithography (3D printing).
  • Create smoothed polygon %model uses smoothing in addition to the marching cubes algorithms, which creates models that do not follow the exact outlines of the segmentation, but look smoother.
  • Statistics goes through all the voxels in the patient image that are part of the segmentation and calculates some statistical measures (minumum, maximum, median, histogram, etc.). Note that the statistics are ALWAYS calculated for the parent element of the segmentation as shown in Data Manager.
  • Autocrop can save memory. Manual segmentations have the same extent as the patient image, even if the segmentation comprises only a small sub-volume. This invisible and meaningless margin is removed by autocropping.
\section QmitkSegmentation_UserManualSurfaceMasking Surface Masking You can use the surface masking tool to create binary images from a surface which is used used as a mask on an image. This task is demonstrated below: -\image html QmitkSegmentation_FromSurfaceBefore.png Load an image and a surface. +\imageMacro{QmitkSegmentation_FromSurfaceBefore.png,"Load an image and a surface.",16.00} Select the image and the surface in the corresponding drop-down boxes (both are selected automatically if there is just one image and one surface) -\image html QmitkSegmentation_FromSurfaceAfter.png Create segmentation from surface +\imageMacro{QmitkSegmentation_FromSurfaceAfter.png,"Create segmentation from surface",16.00} After clicking "Create segmentation from surface" the newly created binary image is inserted in the DataManager and can be used for further processing \section org_mitk_gui_qt_segmentationUserManualTechnicalDetail Technical Information for Developers For technical specifications see \subpage QmitkSegmentationTechnicalPage and for information on the extensions of the tools system \subpage toolextensions . */ diff --git a/Plugins/org.mitk.gui.qt.segmentation/documentation/UserManual/QmitkSegmentation_Technical.dox b/Plugins/org.mitk.gui.qt.segmentation/documentation/UserManual/QmitkSegmentation_Technical.dox index 83bc33bab3..0881222a0e 100644 --- a/Plugins/org.mitk.gui.qt.segmentation/documentation/UserManual/QmitkSegmentation_Technical.dox +++ b/Plugins/org.mitk.gui.qt.segmentation/documentation/UserManual/QmitkSegmentation_Technical.dox @@ -1,101 +1,101 @@ /** \page QmitkSegmentationTechnicalPage Technical design of QmitkSegmentation \li \ref QmitkSegmentationTechnicalPage2 \li \ref QmitkSegmentationTechnicalPage3 \li \ref QmitkSegmentationTechnicalPage4 \section QmitkSegmentationTechnicalPage2 Introduction QmitkSegmentation was designed for the liver resection planning project "ReLiver". The goal was a stable, well-documented, extensible, and testable re-implementation of a functionality called "ERIS", which was used for manual segmentation in 2D slices of 3D or 3D+t images. Re-implementation was chosen because it seemed to be easier to write documentation and tests for newly developed code. In addition, the old code had some design weaknesses (e.g. a monolithic class), which would be hard to maintain in the future. By now Segmentation is a well tested and easily extensible vehicle for all kinds of interactive segmentation applications. A separate page describes how you can extend Segmentation with new tools in a shared object (DLL): \ref toolextensions. \section QmitkSegmentationTechnicalPage3 Overview of tasks We identified the following major tasks:
  1. Management of images: what is the original patient image, what images are the active segmentations?
  2. Management of drawing tools: there is a set of drawing tools, one at a time is active, that is, someone has to decide which tool will receive mouse (and other) events.
  3. Drawing tools: each tool can modify a segmentation in reaction to user interaction. To do so, the tools have to know about the relevant images.
  4. Slice manipulation: drawing tools need to have means to extract a single slice from an image volume and to write a single slice back into an image volume.
  5. Interpolation of unsegmented slices: some class has to keep track of all the segmentations in a volume and generate suggestions for missing slices. This should be possible in all three orthogonal slice direction.
  6. Undo: Slice manipulations should be undoable, no matter whether a tool or the interpolation mechanism changed something.
  7. GUI: Integration of everything.
\section QmitkSegmentationTechnicalPage4 Classes involved The above blocks correspond to a number of classes. Here is an overview of all related classes with their responsibilities and relations: -\image html QmitkSegmentation_InteractiveSegmentationClasses.png +\imageMacro{QmitkSegmentation_InteractiveSegmentationClasses.png,"",16.00}
  1. Management of images: mitk::ToolManager has a set of reference data (original images) and a second set of working data (segmentations). mitk::Tool objects know a ToolManager and can ask the manager for the currently relevant images. There are two GUI elements that enable the user to modify the set of reference and working images (QmitkToolReferenceDataSelectionBox and QmitkToolWorkingDataSelectionBox). GUI and non-GUI classes are coupled by itk::Events (non-GUI to GUI) and direct method calls (GUI to non-GUI).
  2. Management of drawing tools: As a second task, ToolManager manages all available tools and makes sure that one at a time is able to receive MITK events. The GUI for selecting tools is implemented in QmitkToolSelectionBox.
  3. Drawing tools: Drawing tools all inherit from mitk::Tool, which is a mitk::StateMachine. There is a number of derivations from Tool, each offering some helper methods for specific sub-classes, like manipulation of 2D slices. Tools are instantiated through the itk::ObjectFactory, which means that there is also one factory for each tool (e.g. mitk::AddContourToolFactory). For the GUI representation, each tool has an identification, consisting of a name and an icon (XPM). The actual drawing methods are mainly implemented in mitk::SegTool2D (helper methods) and its sub-classes for region growing, freehand drawing, etc.
  4. Slice manipulation: There are two filters for manipulation of slices inside a 3D image volume. mitk::ExtractImageFilter retrieves a single 2D slice from a 3D volume. mitk::OverwriteSliceImageFilter replaces a slice inside a 3D volume with a second slice which is a parameter to the filter. These classes are used extensively by most of the tools to fulfill their task. mitk::OverwriteSliceImageFilter cooperates with the interpolation classes to inform them of single slice modifications.
  5. Interpolation of unsegmented slices: There are two classes involved in interpolation: mitk::SegmentationInterpolationController knows a mitk::Image (the segmentation) and scans its contents for slices with non-zero pixels. It keeps track of changes in the image and is always able to tell, which neighbors of a slice (in the three orthogonal slice directions) contain segmentations. The class also performs this interpolation for single slices on demand. Again, we have a second class responsible for the GUI: QmitkSlicesInterpolator enables/disables interpolation and offers to accept interpolations for one or all slices.
  6. Undo: Undo functionality is implemented in mitk::OverwriteSliceImageFilter, since this is the central place where all image modifications are made. The filter stores a binary difference image to the undo stack as a mitk::ApplyDiffImageOperation. When the user requests undo, this ApplyDiffImageOperation will be executed by a singleton class DiffImageApplier. The operation itself observes the image, which it refers to, for itk::DeleteEvent, so no undo operation will be executed on/for images that have already been destroyed.
  7. GUI: The top-level GUI is the functionality QmitkSegmentation, which is very thin in comparison to ERIS. There are separate widgets for image and tool selection, for interpolation. Additionaly, there are some methods to create, delete, crop, load and save segmentations.
**/ diff --git a/Plugins/org.mitk.gui.qt.segmentation/documentation/UserManual/QmitkSegmentation_ToolExtensionsGeneralOverview.dox b/Plugins/org.mitk.gui.qt.segmentation/documentation/UserManual/QmitkSegmentation_ToolExtensionsGeneralOverview.dox index 810ad82073..65e305f05f 100644 --- a/Plugins/org.mitk.gui.qt.segmentation/documentation/UserManual/QmitkSegmentation_ToolExtensionsGeneralOverview.dox +++ b/Plugins/org.mitk.gui.qt.segmentation/documentation/UserManual/QmitkSegmentation_ToolExtensionsGeneralOverview.dox @@ -1,180 +1,180 @@ /** \page toolextensions How to extend the Segmentation view with external tools
  • \ref ToolExtensionsGeneralOverview2
  • \ref ToolExtensionsGeneralOverview3
    • \ref ToolExtensionsGeneralOverview31
    • \ref ToolExtensionsGeneralOverview32
    • \ref ToolExtensionsGeneralOverview33
  • \ref ToolExtensionsGeneralOverview4
  • \ref ToolExtensionsGeneralOverview5
  • \ref ToolExtensionsGeneralOverview6
\section ToolExtensionsGeneralOverview2 Introduction The application for manual segmentation in MITK (Segmentation view) comes with a tool class framework that is extensible with new tools (description at \ref QmitkSegmentationTechnicalPage). The usual way to create new tools (since it is mostly used inside DKFZ) is to just add new files to the MITK source code tree. However, this requires to be familiar with the MITK build system and turnaround time during development might be long (recompiling parts of MITK again and again). For external users who just want to use MITK as a library and application, there is a way to create new segmentation tools in an MITK external project, which will compile the new tools into a shared object (DLL). Such shared objects can be loaded via the ITK object factory and its autoload feature on application startup. This document describes how to build such external extensions. Example files can be found in the MITK source code in the directory ${MITK_SOURCE_DIR}/QApplications/ToolExtensionsExample/. \section ToolExtensionsGeneralOverview3 What might be part of an extension The extension concept assumes that you want to create one or several new interactive segmentation tools for Segmentation or another MITK functionality that uses the tools infrastructure. In the result you will create a shared object (DLL), which contains several tools and their GUI counterparts, plus optional code that your extension requires. The following sections shortly describe each of these parts. \subsection ToolExtensionsGeneralOverview31 Tool classes A tool is basically any subclass of mitk::Tool. Tools are created at runtime through the ITK object factory (so they inherit from itk::Object). Tools should handle the interaction part of a segmentation method, i.e. create seed points, draw contours, etc., in order to parameterize segmentation algorithms. Simple algorithms can even be part of a tool. A tools is identified by icon (XPM format), name (short string) and optionally a group name (e.g. the group name for Segmentation is "default"). There is a naming convention: you should put a tool called \c mitk::ExternalTool into files called \c mitkExternalTool.h and \c mitkExternalTool.cpp. This is \e required if you use the convenience macros described below, because there need to be ITK factories, which names are directly derived from the file names of the tools. For the example of mitk::ExternalTool there would be a factory called \c mitk::ExternalToolFactory in a file named \c mitkExternalToolFactory.cpp. \subsection ToolExtensionsGeneralOverview32 GUI classes for tools Tools are non-graphical classes that only implement interactions in renderwindows. However, some tools will need a means to allow the user to set some parameters -- a graphical user interface, GUI. In the Qt3 case, tool GUIs inherit from QmitkToolGUI, which is a mixture of QWidget and itk::Object. Tool GUIs are also created through the ITK object factory. Tools inform their GUIs about state changes by messages. Tool GUIs communicate with their associated tools via direct method calls (they know their tools). See mitk::BinaryThresholdTool for examples. Again a naming convention: if the convenience macros for tool extension shared objects are used, you have to put a tool GUI called \c QmitkExternalToolGUI into a files named \c QmitkExternalToolGUI.cpp and \c QmitkExternalToolGUI.h. The convenience macro will create a factory called \c QmitkExternalToolGUIFactory into a file named \c QmitkExternalToolGUIFactory.cpp. \subsection ToolExtensionsGeneralOverview33 Additional files If you are writing tools MITK externally, these tools might depend on additional files, e.g. segmentation algorithms. These can also be compiled into a tool extension shared object. \section ToolExtensionsGeneralOverview4 Writing a CMake file for a tool extension Summing up the last section, an example tool extension could comprise the following files: \verbatim mitkExternalTool.h \ -mitkExternalTool.xpm >--- implementing mitk::ExternalTool (header, icon, implementation) +mitkExternalTool.png >--- implementing mitk::ExternalTool (header, icon, implementation) mitkExternalTool.cpp / QmitkExternalToolGUI.h ,-- implementing a GUI for mitk::ExternalTool QmitkExternalToolGUI.cpp / externalalgorithm.h \ externalalgorithm.cpp \ externalalgorithmsolver.h >-- a couple of files (not related to MITK tools) externalalgorithmsolver.cpp / \endverbatim This should all be compiled into one shared object. Just like ITK, VTK and MITK we will use CMake for this purpose (I assume you either know or are willing to learn about www.cmake.org) A CMake file for the above example would look like this: \code project( ExternalTool ) find_package(ITK) find_package(MITK) find_package(Qt3) add_definitions(${QT_DEFINITIONS}) set( TOOL_QT3GUI_FILES QmitkExternalToolGUI.cpp ) set( TOOL_FILES mitkExternalTool.cpp ) set( TOOL_ADDITIONAL_CPPS externalalgorithm.cpp externalalgorithmsolver.cpp ) set( TOOL_ADDITIONAL_MOC_H ) MITK_GENERATE_TOOLS_LIBRARY(mitkExternalTools) \endcode Basically, you only have to change the definitions of \c TOOL_FILES and, optionally, \c TOOL_QT3GUI_FILES, \c TOOL_ADDITIONAL_CPPS and \c TOOL_ADDITIONAL_MOC_H. For all .cpp files in \c TOOL_FILES and \c TOOL_QT3GUI_FILES there will be factories created assuming the naming conventions described in the sections above. Files listed in \c TOOL_ADDITIONAL_CPPS will just be compiled. Files listed in \c TOOL_ADDITIONAL_MOC_H will be run through Qts meta object compiler \c moc -- this is neccessary for all objects that have the Q_OBJECT macro in their declaration. \c moc will create new files that will also be compiled into the library. \section ToolExtensionsGeneralOverview5 Compiling the extension For compiling a tool extension, you will need a compiled version of MITK. We will assume MITK was compiled into /home/user/mitk/debug. You need to build MITK with BUILD_SHARED_CORE turned on! You build the tool extension just like any other CMake based project: \li know where your source code is (e.g. /home/user/mitk/tool-extension-src) \li change into the directory, where you want to compile the shared object (e.g. /home/user/mitk/tool-extension-debug) \li invoke cmake: ccmake /home/user/mitk/tool-extension-src \li configure (press c or the "configure" button) \li set the ITK_DIR variable to the directory, where you compiled ITK \li set the MITK_DIR variable to the directory, where you compiled MITK: /home/user/mitk/debug \li configure (press "c" or the "configure" button) \li generate (press "g" or the "generate" button) This should do it and leave you with a or project file or Makefile that you can compile (using make or VisualStudio). \section ToolExtensionsGeneralOverview6 Configuring ITK autoload If the compile succeeds, you will get a library mitkExternalTools.dll or libmitkExternalTools.so. This library exports a symbol \c itkLoad which is expected by the ITK object factory. On application startup the ITK object factory will search a list of directories from the environment variable \c ITK_AUTOLOAD_PATH. Set this environment variable to your binary directory (/home/user/mitk/tool-extension-debug). The ITK object factory will load all shared objects that it finds in the specified directories and will test if they contain a symbol (function pointer) \c itkLoad, which is expected to return a pointer to a itk::ObjectFactoryBase instance. If such a symbol is found, the returned factory will be registered with the ITK object factory. If you successfully followed all the steps above, MITK will find your mitk::ExternalTool on application startup, when the ITK object factory is asked to create all known instances of mitk::Tool. Furthermore, if your mitk::ExternalTool claims to be part of the "default" group, there will be a new icon in Segmentation, which activates your tool. Have fun! (And Windows users: welcome to the world of DLLs) **/ diff --git a/Plugins/org.mitk.gui.qt.toftutorial/documentation/Manual/Manual.dox b/Plugins/org.mitk.gui.qt.toftutorial/documentation/Manual/Manual.dox index e8726726bb..5154385490 100644 --- a/Plugins/org.mitk.gui.qt.toftutorial/documentation/Manual/Manual.dox +++ b/Plugins/org.mitk.gui.qt.toftutorial/documentation/Manual/Manual.dox @@ -1,13 +1,13 @@ /** \page org_toftutorial ToFTutorial -\image html icon.png "Icon of ToFTutorial" +\imageMacro{icon.png,"Icon of ToFTutorial",16} Available sections: - \ref ToFTutorialOverview \section ToFTutorialOverview This is the description for the ToFTutorial. */ 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 858c8a8809..871d5ee270 100644 --- a/Plugins/org.mitk.gui.qt.ultrasound/documentation/UserManual/QmitkUltrasound.dox +++ b/Plugins/org.mitk.gui.qt.ultrasound/documentation/UserManual/QmitkUltrasound.dox @@ -1,68 +1,68 @@ /** \page org_mitk_gui_qt_ultrasound The Ultrasound Plugin -\image html QmitkUltrasound_Icon.png "Icon of Ultrasound" +\imageMacro{QmitkUltrasound_Icon.png,"Icon of Ultrasound",2.12} \tableofcontents \section org_mitk_gui_qt_ultrasoundOverview 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-out of one kind or another. Typical video-outs 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 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, connect the ultrasound device to the grabber and the grabber to the computer. Start the ultrasound device and open the ultrasound plugin. The devicemanager will open. -\image html QmitkUltrasound_DeviceManagement.png "MITK Screenshot with the devicemanager activated" +\imageMacro{QmitkUltrasound_DeviceManagement.png,"MITK Screenshot with the devicemanager activated",7.54} Any currently configured devices are listed in the box, which accordingly is empty now. Click "New Device". -\image html QmitkUltrasound_NewVideoDevice.png "The 'New Device' form" +\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). On Windows, try -1 (defaults to the first available source). On Linux and Mac try 0 and 1. If the wrong camera is address, 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 Device to save your changes. -\image html QmitkUltrasound_DeviceManagement2.png "Devicemanager with configured device" +\imageMacro{QmitkUltrasound_DeviceManagement2.png,"Devicemanager with configured device",7.64} \section org_mitk_gui_qt_ultrasoundActivateConnect Activation and Connection A ultrasound device in MITK can be connected and activated. The device you just created automatically is now connected. A connected device is available to all other plugins in MITK, but does not jet generate image data. Disconnecting the device causes it to be deleted and not be available anymore. Click the device, then click "Activate Device". The device is now activated and generates image data continuously. Click the "US-Imaging Tab" -\image html QmitkUltrasound_Imaging.png "US Imaging Tab" +\imageMacro{QmitkUltrasound_Imaging.png,"US Imaging Tab",7.60} Select the device and click "Start Viewing". The US-Image should appear. 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. */ diff --git a/Plugins/org.mitk.gui.qt.volumevisualization/documentation/UserManual/QmitkVolumeVisualization.dox b/Plugins/org.mitk.gui.qt.volumevisualization/documentation/UserManual/QmitkVolumeVisualization.dox index 8f0eb81d7d..bc0f69919b 100644 --- a/Plugins/org.mitk.gui.qt.volumevisualization/documentation/UserManual/QmitkVolumeVisualization.dox +++ b/Plugins/org.mitk.gui.qt.volumevisualization/documentation/UserManual/QmitkVolumeVisualization.dox @@ -1,143 +1,143 @@ /** \page org_mitk_views_volumevisualization The Volume Visualization Plugin -\image html QmitkVolumeVisualization_Icon.png "Icon of the Plugin" +\imageMacro{QmitkVolumeVisualization_Icon.png,"Icon of the Plugin",2.00} \tableofcontents \section QVV_Overview Overview The Volume Visualization Plugin is a basic tool for visualizing three dimensional medical images. MITK provides generic transfer function presets for medical CT data. These functions, that map the gray-value to color and opacity, can be interactively edited. Additionally, there are controls to quickly generate common used transfer function shapes like the threshold and bell curve to help identify a range of grey-values. -\image html QmitkVolumeVisualization_Overview.png "" +\imageMacro{QmitkVolumeVisualization_Overview.png,"",16.00} \section QVV_EnableVRPage Enable Volume Rendering \subsection QVV_LoadingImage Loading an image into the application Load an image into the application by
  • dragging a file into the application window.
  • selecting file / load from the menu.
Volume Visualization imposes following restrictions on images:
  • It has to be a 3D-Image Scalar image, that means a normal CT or MRT.
  • 3D+T are supported for rendering, but the histograms are not computed.
  • Also be aware that volume visualization requires a huge amount of memory. Very large images may not work, unless you use the 64bit version.
\subsection QVV_EnableVR Enable Volumerendering -\image html QmitkVolumeVisualization_Checkboxen.png "" +\imageMacro{QmitkVolumeVisualization_Checkboxen.png,"",8.21} Select an image in datamanager and click on the checkbox left of "Volumerendering". Please be patient, while the image is prepared for rendering, which can take up to a half minute. \subsection QVV_LODGPU The LOD & GPU checkboxes Volume Rendering requires a lot of computing resources including processor, memory and graphics card. To run volume rendering on smaller platforms, enable the LOD checkbox (level-of-detail rendering). Level-of-detail first renders a lower quality preview to increase interactivity. If the user stops to interact a normal quality rendering is issued. The GPU checkbox tries to use computing resources on the graphics card to accelerate volume rendering. It requires a powerful graphics card and OpenGL hardware support for shaders, but achieves much higher frame rates than software-rendering. \section QVV_PresetPage Applying premade presets \subsection QVV_Preset Internal presets There are some internal presets given, that can be used with normal CT data (given in Houndsfield units). A large set of medical data has been tested with that presets, but it may not suit on some special cases. Click on the "Preset" tab for using internal or custom presets. -\image html QmitkVolumeVisualization_InternalPresets.png "" +\imageMacro{QmitkVolumeVisualization_InternalPresets.png,"",8.30}
  • "CT Generic" is the default transferfunction that is first applied.
  • "CT Black&White" does not use any colors, as it may be distracting on some data.
  • "CT Cardiac" tries to increase detail on CTs from the heart.
  • "CT Bone" emphasizes bones and shows other areas more transparent.
  • "CT Bone (Gradient)" is like "CT Bone", but shows from other organs only the surface by using the gradient.
  • "MR Generic" is the default transferfunction that we use on MRT data (which is not normalized like CT data).
  • "CT Thorax small" tries to increase detail.
  • "CT Thorax large" tries to increase detail.
\subsection QVV_CustomPreset Saving and loading custom presets After creating or editing a transferfunction (see \ref QVV_Editing or \ref QVV_ThresholdBell), the custom transferfunction can be stored and later retrieved on the filesystem. Click "Save" (respectively "Load") button to save (load) the threshold-, color- and gradient function combined in a single .xml file. \section QVV_ThresholdBell Interactively create transferfunctions Beside the possibility to directly edit the transferfunctions (\ref QVV_Editing), a one-click generation of two commonly known shapes is given. Both generators have two parameters, that can be modified by first clicking on the cross and then moving the mouse up/down and left/right. The first parameter "center" (controlled by horizontal movement of the mouse) specifies the gravalue where the center of the shape will be located. The second parameter "width" (controlled by vertical movement of the mouse) specifies the width (or steepness) of the shape. \subsection Threshold Click on the "Threshold" tab to active the threshold function generator. -\image html QmitkVolumeVisualization_Threshold.png "" +\imageMacro{QmitkVolumeVisualization_Threshold.png,"",8.21} A threshold shape begins with zero and raises to one across the "center" parameter. Lower widths results in steeper threshold functions. \subsection Bell Click on the "Bell" tab to active the threshold function generator. -\image html QmitkVolumeVisualization_Bell.png "" +\imageMacro{QmitkVolumeVisualization_Bell.png,"",8.23} A threshold shape begins with zero and raises to one at the "center" parameter and the lowers agains to zero. The "width" parameter correspondens to the width of the bell. \section QVV_Editing Customize transferfunctions in detail \subsection QVV_Navigate Choosing grayvalue interval to edit -\image html QmitkVolumeVisualization_Slider.png "" +\imageMacro{QmitkVolumeVisualization_Slider.png,"",8.23} To navigate across the grayvalue range or to zoom in some ranges use the "range"-slider. All three function editors have in common following:
  • By left-clicking a new point is added.
  • By right-clicking a point is deleted.
  • By left-clicking and holding, an exisiting point can be dragged.
  • By pressing arrow keys, the currently selected point is moved.
  • By pressing the "DELETE" key, the currently selected point is deleted.
  • Between points the transferfunctions are linear interpolated.
There are three transferfunctions to customize: \subsection QVV_GO Grayvalue -> Opacity -\image html QmitkVolumeVisualization_Opacity.png "grayvalues will be mapped to opacity." +\imageMacro{QmitkVolumeVisualization_Opacity.png,"grayvalues will be mapped to opacity.",8.04} An opacity of 0 means total transparent, an opacity of 1 means total opaque. \subsection QVV_GC Grayvalue -> Color -\image html QmitkVolumeVisualization_Color.png "grayvalues will be mapped to color." +\imageMacro{QmitkVolumeVisualization_Color.png,"grayvalues will be mapped to color.",8.81} The color transferfunction editor also allows by double-clicking a point to change its color. \subsection QVV_GGO Grayvalue and Gradient -> Opacity -\image html QmitkVolumeVisualization_Gradient.png "" +\imageMacro{QmitkVolumeVisualization_Gradient.png,"",8.85} Here the influence of the gradient is controllable at specific grayvalues. */ diff --git a/Plugins/org.mitk.gui.qt.xnat/documentation/UserManual/Manual.dox b/Plugins/org.mitk.gui.qt.xnat/documentation/UserManual/Manual.dox index d86c17ec23..51cdb11bf4 100644 --- a/Plugins/org.mitk.gui.qt.xnat/documentation/UserManual/Manual.dox +++ b/Plugins/org.mitk.gui.qt.xnat/documentation/UserManual/Manual.dox @@ -1,25 +1,25 @@ /** \page org_mitk_gui_qt_xnat XNAT Plugin -\image html icon.xpm "Icon of XNAT Plugin" +\imageMacro{icon.png,"Icon of XNAT Plugin",2.00} Available sections: - \ref org_mitk_gui_qt_xnatOverview \section org_mitk_gui_qt_xnatOverview Overview This plug-in is a new possibility of communication with a XNAT server in MITK. It takes data from the server, shows it as hierarchy in the main window of the plug-in as editor and it works like a normal browser. There is also a view, where the XNAT hierarchy is displayed as tree structure. Editor and view can communicate with each other, so the editor updates for a selection in the view. The session data must be configured in Preferences -> XNAT Connection. The benefits of this plug-in are:
  • Browsing through the XNAT hierarchy
  • Jumping to higher levels of the hierarchy with breadcrumbs
  • Downloading data
  • Visualisation of data
*/