diff --git a/Core/Documentation/Doxygen/Concepts/DataInteraction.dox b/Core/Documentation/Doxygen/Concepts/DataInteraction.dox index 8d4be67bc1..d9a4eaa91c 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 InteractionPage_Introduction Introduction to Interaction in MITK +\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 HandlingSection Event Handling & GUI Toolkit Abstraction +\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
  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 EventPage Events +\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 InteractionEventHandlerSection InteractionEventHandler +\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 DataInteractorsSection DataInteractors +\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 StateMachinesSection StateMachines +\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 DefinitionStateMachine Definition of a State Machine +\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 InteractionEventObserverSection InteractionEventObserver +\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 ConfigurationSection Configuration +\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 DispatcherSection Dispatcher +\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 01447e6b83..44e4d91895 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 DispatcherSection Dispatcher +\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 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 DispatcherEventDistSection Event Distribution +\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 StateMachineSection State Machine & Configuration +\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/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExtensionPointsIntro.dox b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExtensionPointsIntro.dox index 714b3d367b..c3685a5d21 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" \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" 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 Examples Examples +\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/BlueBerrySelectionServiceIntro.dox b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerrySelectionServiceIntro.dox index 860c7cc20d..570521ea87 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" 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" -\section WhatCanBeSelected What can be selected? +\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 Examples +\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/Modules/Segmentation/DataManagement/mitkContourModel.h b/Modules/Segmentation/DataManagement/mitkContourModel.h index f5c04594bb..2530d1cef7 100644 --- a/Modules/Segmentation/DataManagement/mitkContourModel.h +++ b/Modules/Segmentation/DataManagement/mitkContourModel.h @@ -1,397 +1,397 @@ /*=================================================================== The Medical Imaging Interaction Toolkit (MITK) Copyright (c) German Cancer Research Center, Division of Medical and Biological Informatics. All rights reserved. This software is distributed WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See LICENSE.txt or http://www.mitk.org for details. ===================================================================*/ #ifndef _MITK_CONTOURMODEL_H_ #define _MITK_CONTOURMODEL_H_ #include "mitkCommon.h" #include "SegmentationExports.h" #include "mitkBaseData.h" #include namespace mitk { /** \brief ContourModel is a structure of linked vertices defining a contour in 3D space. The vertices are stored in a mitk::ContourElement is stored for each timestep. The contour line segments are implicitly defined by the given linked vertices. By default two control points are are linked by a straight line.It is possible to add vertices at front and end of the contour and to iterate in both directions. Points are specified containing coordinates and additional (data) information, see mitk::ContourElement. For accessing a specific vertex either an index or a position in 3D Space can be used. The vertices are best accessed by using a VertexIterator. Interaction with the contour is thus available without any mitk interactor class using the api of ContourModel. It is possible to shift single vertices also as shifting the whole contour. A contour can be either open like a single curved line segment or closed. A closed contour can for example represent a jordan curve. - \section mitkPointSetDisplayOptions + \section mitkContourModelDisplayOptions Display Options The default mappers for this data structure are mitk::ContourModelGLMapper2D and mitk::ContourModelMapper3D. See these classes for display options which can can be set via properties. */ class Segmentation_EXPORT ContourModel : public BaseData { public: mitkClassMacro(ContourModel, BaseData); itkNewMacro(Self); mitkCloneMacro(Self); /*+++++++++++++++ typedefs +++++++++++++++++++++++++++++++*/ typedef mitk::ContourElement::VertexType VertexType; typedef mitk::ContourElement::VertexListType VertexListType; typedef mitk::ContourElement::VertexIterator VertexIterator; typedef std::vector< mitk::ContourElement::Pointer > ContourModelSeries; /*+++++++++++++++ END typedefs ++++++++++++++++++++++++++++*/ /** \brief Possible interpolation of the line segments between control points */ enum LineSegmentInterpolation{ LINEAR, B_SPLINE }; /*++++++++++++++++ inline methods +++++++++++++++++++++++*/ /** \brief Get the current selected vertex. */ VertexType* GetSelectedVertex() { return this->m_SelectedVertex; } /** \brief Deselect vertex. */ void Deselect() { this->m_SelectedVertex = NULL; } /** \brief Deselect vertex. */ void SetSelectedVertexAsControlPoint(bool isControlPoint=true) { if(this->m_SelectedVertex && (this->m_SelectedVertex->IsControlPoint != isControlPoint) ) { m_SelectedVertex->IsControlPoint = isControlPoint; this->Modified(); } } /** \brief Set the interpolation of the line segments between control points. */ void SetLineSegmentInterpolation(LineSegmentInterpolation interpolation) { this->m_lineInterpolation = interpolation; this->Modified(); } /** \brief Get the interpolation of the line segments between control points. */ LineSegmentInterpolation GetLineSegmentInterpolation() { return this->m_lineInterpolation; } /*++++++++++++++++ END inline methods +++++++++++++++++++++++*/ /** \brief Add a vertex to the contour at given timestep. The vertex is added at the end of contour. \pararm vertex - coordinate representation of a control point \pararm timestep - the timestep at which the vertex will be add ( default 0) @Note Adding a vertex to a timestep which exceeds the timebounds of the contour will not be added, the TimeSlicedGeometry will not be expanded. */ void AddVertex(mitk::Point3D &vertex, int timestep=0); /** \brief Add a vertex to the contour at given timestep. The vertex is added at the end of contour. \param vertex - coordinate representation of a control point \param timestep - the timestep at which the vertex will be add ( default 0) @Note Adding a vertex to a timestep which exceeds the timebounds of the contour will not be added, the TimeSlicedGeometry will not be expanded. */ void AddVertex(VertexType &vertex, int timestep=0); /** \brief Add a vertex to the contour. \pararm vertex - coordinate representation of a control point \pararm timestep - the timestep at which the vertex will be add ( default 0) \pararm isControlPoint - specifies the vertex to be handled in a special way (e.g. control points will be rendered). @Note Adding a vertex to a timestep which exceeds the timebounds of the contour will not be added, the TimeSlicedGeometry will not be expanded. */ void AddVertex(mitk::Point3D &vertex, bool isControlPoint, int timestep=0); /** \brief Add a vertex to the contour at given timestep AT THE FRONT of the contour. The vertex is added at the FRONT of contour. \pararm vertex - coordinate representation of a control point \pararm timestep - the timestep at which the vertex will be add ( default 0) @Note Adding a vertex to a timestep which exceeds the timebounds of the contour will not be added, the TimeSlicedGeometry will not be expanded. */ void AddVertexAtFront(mitk::Point3D &vertex, int timestep=0); /** \brief Add a vertex to the contour at given timestep AT THE FRONT of the contour. The vertex is added at the FRONT of contour. \pararm vertex - coordinate representation of a control point \pararm timestep - the timestep at which the vertex will be add ( default 0) @Note Adding a vertex to a timestep which exceeds the timebounds of the contour will not be added, the TimeSlicedGeometry will not be expanded. */ void AddVertexAtFront(VertexType &vertex, int timestep=0); /** \brief Add a vertex to the contour at given timestep AT THE FRONT of the contour. \pararm vertex - coordinate representation of a control point \pararm timestep - the timestep at which the vertex will be add ( default 0) \pararm isControlPoint - specifies the vertex to be handled in a special way (e.g. control points will be rendered). @Note Adding a vertex to a timestep which exceeds the timebounds of the contour will not be added, the TimeSlicedGeometry will not be expanded. */ void AddVertexAtFront(mitk::Point3D &vertex, bool isControlPoint, int timestep=0); /** \brief Insert a vertex at given index. */ void InsertVertexAtIndex(mitk::Point3D &vertex, int index, bool isControlPoint=false, int timestep=0); /** \brief Return if the contour is closed or not. */ bool IsClosed( int timestep=0); /** \brief Concatenate two contours. The starting control point of the other will be added at the end of the contour. */ void Concatenate(mitk::ContourModel* other, int timestep=0); /** \brief Returns a const VertexIterator at the start element of the contour. @throw mitk::Exception if the timestep is invalid. */ VertexIterator IteratorBegin( int timestep=0); /** \brief Close the contour. The last control point will be linked with the first point. */ virtual void Close( int timestep=0); /** \brief Set isClosed to false contour. The link between the last control point the first point will be removed. */ virtual void Open( int timestep=0); /** \brief Set isClosed to given boolean. false - The link between the last control point the first point will be removed. true - The last control point will be linked with the first point. */ virtual void SetIsClosed(bool isClosed, int timestep=0); /** \brief Returns a const VertexIterator at the end element of the contour. @throw mitk::Exception if the timestep is invalid. */ VertexIterator IteratorEnd( int timestep=0); /** \brief Returns the number of vertices at a given timestep. \pararm timestep - default = 0 */ int GetNumberOfVertices( int timestep=0); /** \brief Returns the vertex at the index position within the container. */ virtual const VertexType* GetVertexAt(int index, int timestep=0) const; /** \brief Check if there isn't something at this timestep. */ virtual bool IsEmptyTimeStep( int t) const; /** \brief Mark a vertex at an index in the container as selected. */ bool SelectVertexAt(int index, int timestep=0); /** \brief Mark a vertex at a given position in 3D space. \pararm point - query point in 3D space \pararm eps - radius for nearest neighbour search (error bound). \pararm timestep - search at this timestep @return true = vertex found; false = no vertex found */ bool SelectVertexAt(mitk::Point3D &point, float eps, int timestep=0); /** \brief Remove a vertex at given index within the container. @return true = the vertex was successfuly removed; false = wrong index. */ bool RemoveVertexAt(int index, int timestep=0); /** \brief Remove a vertex at given timestep within the container. @return true = the vertex was successfuly removed. */ bool RemoveVertex(VertexType* vertex, int timestep=0); /** \brief Remove a vertex at a query position in 3D space. The vertex to be removed will be search by nearest neighbour search. Note that possibly no vertex at this position and eps is stored inside the contour. @return true = the vertex was successfuly removed; false = no vertex found. */ bool RemoveVertexAt(mitk::Point3D &point, float eps, int timestep=0); /** \brief Shift the currently selected vertex by a translation vector. \pararm translate - the translation vector. */ void ShiftSelectedVertex(mitk::Vector3D &translate); /** \brief Shift the whole contour by a translation vector at given timestep. \pararm translate - the translation vector. \pararm timestep - at this timestep the contour will be shifted. */ void ShiftContour(mitk::Vector3D &translate, int timestep=0); /** \brief Clear the storage container at given timestep. All control points are removed at timestep. */ virtual void Clear(int timestep); /*++++++++++++++++++ method inherit from base data +++++++++++++++++++++++++++*/ /** \brief Inherit from base data - no region support available for contourModel objects. */ virtual void SetRequestedRegionToLargestPossibleRegion (); /** \brief Inherit from base data - no region support available for contourModel objects. */ virtual bool RequestedRegionIsOutsideOfTheBufferedRegion (); /** \brief Inherit from base data - no region support available for contourModel objects. */ virtual bool VerifyRequestedRegion (); /** \brief Get the updated geometry with recomputed bounds. */ virtual const mitk::Geometry3D* GetUpdatedGeometry (int t=0); /** \brief Get the Geometry3D for timestep t. */ virtual mitk::Geometry3D* GetGeometry (int t=0) const; /** \brief Inherit from base data - no region support available for contourModel objects. */ virtual void SetRequestedRegion( const itk::DataObject *data); /** \brief Expand the timebounds of the TimeSlicedGeometry to given number of timesteps. */ virtual void Expand( int timeSteps ); /** \brief Update the OutputInformation of a ContourModel object The BoundingBox of the contour will be updated, if necessary. */ virtual void UpdateOutputInformation(); /** \brief Clear the storage container. The object is set to initial state. All control points are removed and the number of timesteps are set to 1. */ virtual void Clear(); /** \brief overwrite if the Data can be called by an Interactor (StateMachine). */ void ExecuteOperation(Operation* operation); protected: ContourModel(); ContourModel(const mitk::ContourModel &other); virtual ~ContourModel(); //inherit from BaseData. called by Clear() virtual void ClearData(); //inherit from BaseData. Initial state of a contour with no vertices and a single timestep. virtual void InitializeEmpty(); //Shift a vertex void ShiftVertex(VertexType* vertex, mitk::Vector3D &vector); //Storage with time resolved support. ContourModelSeries m_ContourSeries; //The currently selected vertex. VertexType* m_SelectedVertex; //The interpolation of the line segment between control points. LineSegmentInterpolation m_lineInterpolation; }; itkEventMacro( ContourModelEvent, itk::AnyEvent ); itkEventMacro( ContourModelShiftEvent, ContourModelEvent ); itkEventMacro( ContourModelSizeChangeEvent, ContourModelEvent ); itkEventMacro( ContourModelAddEvent, ContourModelSizeChangeEvent ); itkEventMacro( ContourModelRemoveEvent, ContourModelSizeChangeEvent ); itkEventMacro( ContourModelExpandTimeBoundsEvent, ContourModelEvent ); itkEventMacro( ContourModelClosedEvent, ContourModelEvent ); } #endif