diff --git a/Core/Documentation/Doxygen/Concepts/CodingGeneral.dox b/Core/Documentation/Doxygen/Concepts/CodingGeneral.dox new file mode 100644 index 0000000000..2dab6af5f9 --- /dev/null +++ b/Core/Documentation/Doxygen/Concepts/CodingGeneral.dox @@ -0,0 +1,53 @@ +/** +\page CodingPage Coding + +\section CodingPageGeneral General Information +Conceptually MITK is mainly geared to ITK (The Insight Toolkit). +Thus, most of the ITK coding concepts can be transferred to MITK. + +The ITK coding concepts can be found in the free ITK software guide, downloadable at ITKs homepage. + +The main ITK concepts which one should look into before using MITK are: + + +\section CodingPageStyle Coding Style +MITK provides coding style guidelines. When implementing code which should be added to the project, +these guidelines should be followed in order to keep a unified coding style all over MITK. The style +is geared to a common c++ coding style combined with some extension of used libraries, e.g. the use of +itk smart pointers. The MITK style guide is provided on the page \ref StyleGuideAndNotesPage . +If you are new to coding with MITK please also consider that MITK is using different pre defined macros, +which might look confusing. An overview on these macros is given in section \ref CodingPageMITKMacros. + +\section CodingPageMITKMacros Macros in MITK +MITK uses different macros to simplify implementation, but these macros might look confusing at first. Some +of these macros are derived from ITK, others are defined in MITK itself. The most important macros are defined +in the file mitkCommon.h, but there are some other headers which also define macros, e.g. mitkTestingMacros.h +and mitkExceptionMacros.h. + +In the following the most important macros are shown for overview, more details are available in the corresponding header files. +\code +//These macros come from ITK: + +itkNewMacro(Class);//this macro creates the constructor for smart pointers + //it calls the default c++ constructor of the class + //the default constructor should be declared protected + +itkGetMacro(Name,Class); //these macros create getters and setters +itkSetMacro(Name,Class); //automatically, but you need the corresponding +itkGetConstMacro(Name,Class); //member variable m_Name in your class +itkSetConstMacro(Name,Class); + +//The following macros are defined in MITK itself: + +mitkClassMacro(Class,Superclass); //macro is needed in every header of a MITK class + +mitkNewMacro1Param(Class,ParamType); //like the ITK new macro, but with one parameter + //you need a constructor with one parameter as well + //the same macro exists for 2,3 and 4 parameters + +mitkExceptionClassMacro(Class,Superclass); //special macro for MITK exception classes +\endcode +*/ diff --git a/Core/Documentation/Doxygen/Concepts/Concepts.dox b/Core/Documentation/Doxygen/Concepts/Concepts.dox index 4caf8cec74..ed3c3a2d15 100644 --- a/Core/Documentation/Doxygen/Concepts/Concepts.dox +++ b/Core/Documentation/Doxygen/Concepts/Concepts.dox @@ -1,17 +1,30 @@ /** \page Concepts MITK concepts The following items describe some issues about MITK on a more abstract level. -If you want to start using MITK, you also want to see \ref Development +-# \subpage OverviewPage +-# \subpage CodingPage "Coding Concepts" + -# \ref CodingPageGeneral + -# \ref CodingPageStyle + -# \ref CodingPageMITKMacros + -# \subpage MicroServices_Overview +-# Data Concepts + -# \subpage DataManagementPage + -# \subpage MitkImagePage + -# \subpage PropertiesPage + -# \subpage GeometryOverviewPage + -# \subpage PipelineingConceptPage +-# \subpage QVTKRendering +-# \subpage InteractionPage +-# \subpage LoggingPage +-# \subpage ExceptionPage +-# Testing Concept + -# \subpage GeneralTests + -# \subpage RenderingTests +-# \subpage ModularizationPage "Modularization Concept" + -# \ref ModularizationPageOverview + -# \ref ModularizationPageHowTo -\li \subpage OverviewPage -\li \subpage QVTKRendering -\li \subpage InteractionPage -\li \subpage ExceptionPage -\li \subpage LoggingPage -\li \subpage PropertiesPage -\li \subpage GeometryOverviewPage -\li \subpage MicroServices_Overview -\li \subpage RenderingTests +If you want to start using MITK, you also want to see the chapter \ref Development. */ diff --git a/Core/Documentation/Doxygen/Concepts/DataManagement.dox b/Core/Documentation/Doxygen/Concepts/DataManagement.dox new file mode 100644 index 0000000000..cfae3c848f --- /dev/null +++ b/Core/Documentation/Doxygen/Concepts/DataManagement.dox @@ -0,0 +1,56 @@ +/** + +\page DataManagementPage The Data Management Concept + +As MITK is used to process large and diverse data the management thereof becomes an important issue. +In order to abstract the management of data from the actual format of the data it is encapsulated. + +\section DataManagementPageEncapsulation Data Encapsulation + +All data objects, like images or surfaces, are contained in DataNodes. These DataNodes describe the data +itself (mitk::BaseData and derived classes), how they can be rendered in 2D or 3D (a list of mitk::Mapper), +what mitk::Interactor is associated with it, and a list of arbitrary properties (name, visibility, opacity, etc.). +Information about the position of a data object in space/time is stored in a Geometry, which is attached to the +data object itself, not to the node. + +\subsection DataManagementPageBaseData BaseData + +mitk::BaseData is the base class for all data objects. It itself inherits from itk::DataObject. + +\subsection DataManagementPageDataNode DataNode + +This class encapsulates a BaseData object and provides uniform handling. + +\subsection DataManagementPageDataStorage DataStorage + +The MITK DataStorage manages and stores DataNodes. Besides adding and removing nodes it provides advanced +functionality such as getting a list of all DataNodes currently in the DataStorage which match a specific +type (e.g. image, surface ) or have a specific name or other property. + +There can be different DataStorages. + +A usage example for a class deriving from QmitkAbstractView: +\code + mitk::DataNode::Pointer resultNode = mitk::DataNode::New(); // create data node + std::string nameOfResultImage = node->GetName(); // get property "name" of the original node,this is a convenience method + nameOfResultImage.append("Otsu"); // extend the "name" to "nameOtsu" + resultNode->SetProperty("name", mitk::StringProperty::New(nameOfResultImage) ); // write name property to new node + resultNode->SetProperty("binary", mitk::BoolProperty::New(true) ); // set binary property of new node true + resultNode->SetData( mitk::ImportItkImage ( filter->GetOutput() ) ); // set data of new node + + this->GetDataStorage()->Add(resultNode, node); // add new node to datastorage +\endcode + +\section DataManagementPageOwnType Adding an own data type + +To extent MITKs capabilities by adding a custom data type there are several things which should be done. +Depending on whether the data type is completely unlike any of the existing ones, or derived from one of +them some steps can possibly be omitted. + +
    +
  1. Add your data type +
  2. Add reader and writer and register them +
  3. Add mapper +
+ +*/ diff --git a/Core/Documentation/Doxygen/Concepts/Exceptions.dox b/Core/Documentation/Doxygen/Concepts/Exceptions.dox index e3f3149380..5bc0ca762d 100644 --- a/Core/Documentation/Doxygen/Concepts/Exceptions.dox +++ b/Core/Documentation/Doxygen/Concepts/Exceptions.dox @@ -1,92 +1,92 @@ /** \page ExceptionPage Error Handling and Exception Concept \ref ExceptionHandling "1. General Exception Handling" \ref SpecializedExceptionHandling "2. Defining and Using Specialized Exceptions" \section ExceptionHandling General Exception Handling In MITK, errors during program execution are handled by the well known exception handling concept which is part of the C++ language. In case of unexpected exceptional behaviour or errors during program execution MITK classes throw exceptions. MITK exceptions are always objects of the class mitk::Exception or of one of its subclasses. \subsection Throw Throwing of exceptions Exceptions should always be thrown by using the predefined exception macros. If you want to throw a mitk::Exception in your code, simply use the following macro. \verbatim //This command will throw a mitk::Exception and add a message. //The macro will also add filename and line number to the exception //object. mitkThrow() << "Here comes your exception message"; \endverbatim You can also stream more complex messages, e.g. adding integers or other variables to your exception messages, like shown in the following example. \verbatim mitkThrow() << "This time we show the values of some variables:" << m_MyObject->GetSize() << m_MyInteger; \endverbatim \subsection Doc Documentation of exceptions If you throw exceptions in your code, please also document this in your doxygen comments by using the "@throws " tag. This will help users of your class to catch and handle the exceptions in a proper way. An example how to document exception throwing is given below. \verbatim class myExampleClass { /** Documentation * @brief This method does [...] * @throws mitk::Exception This exception is thrown, when the following error occures: [...] */ void MyExampleMethod() { //here comes your code //here happens an exception mitkThrow() << "An exception occured because [...], method can't continue."; } } \endverbatim In general, exceptions emit no logging messages by default because they are intended to be catched by overlying classes. This classes should then decide what to do, e.g. to log an error message or handle the exception in another way. See the logging documentation for more details on error logging. \subsection Catch Catching exceptions -Exceptions should be catched by overlying classes, when they can handle them in a proper way. Catching exceptions is very simple, use the standard try-catch block to do so. An example is given below. +Exceptions should be caught by overlying classes, if they can handle them in a proper way. Catching exceptions is very simple, use the standard try-catch block to do so. An example is given below. \verbatim try { //call of a method which may throw an exception myObject->MyExampleMethod(); } catch (mitk::Exception e) { //This code is executed if an exception of the given type was thrown above. //For example log an error message here or do some other proper handling of the exception. } \endverbatim -Please do not use "catch (...)" because normally your class can't garantee to handle all exceptions in a proper way without differentiate them. +Please do not use "catch (...)" because normally your class can't garantee to handle all exceptions in a proper way without differentiating them. \section SpecializedExceptionHandling Defining and Using more Specialized Exceptions The basic MITK exception concept was kept very simple and should suffice in many cases. But you can also use more specialized exceptions, if needed. Nevertheless all MITK exceptions should be subclasses of mitk::exception. You can define your own exception classes by simply implementing new classes which derive from mitk::exception. Thus, you can catch your exception seperately when needed. The mitkExceptionClassMacro helps to keep implementing new exception classes as simple as possible, like shown in the following code example. \verbatim #include class mitk::MySpecializedException : public mitk::Exception { public: mitkExceptionClassMacro(mitk::MySpecializedException,mitk::Exception); }; \endverbatim To throw your specialized exception you should use the corresponing macro, which is shown in the next code snippet. \verbatim mitkThrowException(mitk::MySpecializedException) << "this is error info"; \endverbatim */ \ No newline at end of file diff --git a/Core/Documentation/Doxygen/Concepts/Interaction.dox b/Core/Documentation/Doxygen/Concepts/Interaction.dox index 99cf22ec85..1eb2bd879f 100644 --- a/Core/Documentation/Doxygen/Concepts/Interaction.dox +++ b/Core/Documentation/Doxygen/Concepts/Interaction.dox @@ -1,122 +1,120 @@ /** \page InteractionPage Interaction and Undo/Redo Concepts \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. +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 \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, cause 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. +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. is an Object is picked of a set of points will be full after the addition of one point. +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 \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 the object, the state machine handles the interaction, 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 the object taken care of. +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 Interaction/mitkBaseInteraction/StateMachine.xml). +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/Interactions/StateMachine.xml and Plugins/org.mitk.gui.qt.application/resources/StateMachine.xml, the duplication is currently needed due to design decisions). The structure is the following (from \ref InteractionPage_ExampleA) : \code - - - - - - - - + + + + + + + + \endcode -The identification numbers (ID) inside a state machine has 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 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. -So a state machine is defined through a few lines of xml-code, which is loaded at runtime. This allows us to change the sequence in interaction in the xml-file and restart the application, where the changes are applied right away. +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, that 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. +\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_StartupInteraction Loading Statemachines at Runtime -During startup all state machine-patterns are checked for not having states, that have no transitions leading out of it (dead states), or states, that have no transitions leading into it (magic states) [Bin99 p. 183]. If an error is found, an error-message will be displayed \b and the state machine will be loaded. - -See mitk::StateMachineFactory - \subsection InteractionPage_InteractionEvents Events -During runtime, events are thrown from e.g. the mouse to the operation 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. +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. \b Note that 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. +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 (can 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. +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/Logging.dox b/Core/Documentation/Doxygen/Concepts/Logging.dox index de6aef863d..fb722220b6 100644 --- a/Core/Documentation/Doxygen/Concepts/Logging.dox +++ b/Core/Documentation/Doxygen/Concepts/Logging.dox @@ -1,78 +1,78 @@ /** \page LoggingPage Logging Concept Available sections: --# \ref Sec1 "Basic Information on Logging" --# \ref Sec2 "Categorize your Logging Messages" --# \ref Sec3 "Logging Levels" --# \ref Sec4 "Conditional Logging" +-# \ref LoggingPageSection1 "Basic Information on Logging" +-# \ref LoggingPageSection2 "Categorize your Logging Messages" +-# \ref LoggingPageSection3 "Logging Levels" +-# \ref LoggingPageSection4 "Conditional Logging" -\section Sec1 Basic Information on Logging +\section LoggingPageSection1 Basic Information on Logging To use logging in MITK you can stream your messages into a logging stream, similar to the "std::cout" stream in standard c++. A simple example is shown next. \code MITK_INFO << "Here comes my message"; \endcode -Please only use the MITK_INFO (respectively MITK_WARN, MITK_ERROR, MITK_FATAL, MITK_DEBUG, see section "Logging levels" for more details) in MITK, the std::cout stream should not be used. +Please only use the MITK_INFO (respectively MITK_WARN, MITK_ERROR, MITK_FATAL, MITK_DEBUG, see \ref LoggingPageSection3 for more details) in MITK, the std::cout stream should not be used. You can also log object information, like shown in the next example. \code MITK_INFO << "I want to log my vector size: " << m_vector.getSize(); \endcode All logged information will be displayed in the console and be written to a logging file in the MITK binary folder. Advanced users may want to know that this behavior is controlled by the logging backend class, which can be adapted if you want to change the behavior. This is everything you need to know about simple logging. Further reading will show you how you can categorize your logging message and what logging levels are. -\section Sec2 Categorize your Logging Messages +\section LoggingPageSection2 Categorize your Logging Messages You may also want to categorize your logging messages, so you can assign messages to your specific topic. You can simply add classes and subclasses to your MITK logging messages by using brackets, like shown in the next example. \code MITK_INFO << "no class"; MITK_INFO("MyClass") << "single class"; MITK_INFO("MyClass")("MySubClass") << "class with subclass"; \endcode This classes makes it easy to e.g. simply filter all logging messages only for relevant information. -\section Sec3 Logging Levels +\section LoggingPageSection3 Logging Levels MITK offers different logging levels. You may mostly want to use MITK_INFO, but please consider using the other levels, e.g. when logging debug information or errors. Debug (MITK_DEBUG): These messages are designed for debug output, used to debug your source code. They are only displayed if you turn the CMake-Variable MBILOG_ENABLE_DEBUG_MESSAGES on. You can also use the debug message in release mode, output only depends on the CMake-Variable. Example: \code MITK_DEBUG << "Result of method LoadPicture(): true." \endcode Info (MITK_INFO): For standard information messages that inform about expected changes/results in the program flow. Info messages should be important and understandable for the users of the program. Example: \code MITK_INFO << "The picture test.pic has been loaded successfully." \endcode Warning (MITK_WARN): Warning messages should inform about unexpected or potentially problematic states in the program flow that do not lead directly to an error. Thus, after a warning the program should be able continue without errors and in a clear state. Example: \code MITK_WARN << "The picture test.pic was not loaded because access was denied." \endcode Error (MITK_ERROR): Error messages notify the user about corrupt states in the program flow. Such states may occur after unexpected behavior of source code. Example: \code MITK_ERROR << "Error while adding test.pic to the data storage, aborting." \endcode Fatal (MITK_FATAL): Fatal messages report corrupt states in the program flow that lead directly to a crash of the program. Example: \code MITK_FATAL << "Memory allocation error during instantiation of image object." \endcode -\section Sec4 Conditional Logging -Another feature of the logging mechanism is that you can directly give conditions if your message should be logged. These bool values or expressions can be defined in brackets. An example is shown next. +\section LoggingPageSection4 Conditional Logging +Another feature of the logging mechanism is that you can directly give conditions for logging your message. These bool values or expressions can be defined in brackets. An example is shown next. \code MITK_INFO(x>1000) << "x is too large"; //logs only if x > 1000 \endcode */ \ No newline at end of file diff --git a/Core/Documentation/Doxygen/Concepts/MitkImage.dox b/Core/Documentation/Doxygen/Concepts/MitkImage.dox new file mode 100644 index 0000000000..fb5f91314e --- /dev/null +++ b/Core/Documentation/Doxygen/Concepts/MitkImage.dox @@ -0,0 +1,71 @@ +/** +\page MitkImagePage MITK Image + +Available Sections: + +-# \ref MitkImagePage_Introduction "Introduction to MITK Image" + -# \ref MitkImagePage_SlicedData "SlicedData and Geometry" + -# \ref MitkImagePage_ImageData "ImageData" + -# \ref MitkImagePage_Properties "Image Properties" +-# \ref MitkImagePage_WorkingWith "Working with MITK Image" + -# \ref MitkImagePage_Cloning "Cloning a MITK Image" + -# \ref MitkImagePage_Inheriting "Inheriting from MITK Image" + + + +\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 + +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 + +\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_WorkingWith Working with MITK Image + +\subsection MitkImagePage_Cloning Cloning a MITK Image +When duplicating an image, be sure to duplicate all data that you want to transfer. This includes Geometry, the visual Data and any properties necessary. 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 and, if necessary, it's properties. + +\verbatim +mitk::Image::Pointer new = mitk::Image::New(); // Create new, empty image +new->Initialize(old); // new no has the geometry information from old image +new->SetVolume(old->GetData()); // new now additionally contains the old images visual data +new->SetPropertyList(old->GetPropertyList()) // new now additionally contains the old image's properties +\endverbatim + + +\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. + + + +*/ \ No newline at end of file diff --git a/Core/Documentation/Doxygen/Concepts/Modularization.dox b/Core/Documentation/Doxygen/Concepts/Modularization.dox new file mode 100644 index 0000000000..58d0f02c4e --- /dev/null +++ b/Core/Documentation/Doxygen/Concepts/Modularization.dox @@ -0,0 +1,44 @@ +/** + +\page ModularizationPage Modular MITK + +MITK has been designed to be modular and flexible, to facilitate reuse of existing code and functionality if possible. As such there are several levels of modularization which can be chosen when working with MITK, depending on the use case. + +\section ModularizationPageOverview Overview + +The general hierarchy of modularization runs micro service, module, view, plug-in, perspective and finally application. + +\subsection ModularizationPageMicroServices Micro Services + +A \ref MicroServices_Overview "micro service" is a reusable component provided by MITK modules. It can be accessed by other MITK modules or MITK plug-ins via its declared interface. + +\subsection ModularizationPageModules Modules + +Modules can be found in the MITK/Modules directory (with the exception of the core module in MITK/Core). Each module is a shared library that provides algorithms, data structures and similar code. Many modules are gui independent. A module is only build if it is required by other code, e.g. if a plug-ins is activated that requires it. + +\subsection ModularizationPageViews Views + +One of the smallest units in the MITK application framework (\ref FurtherReading "Blueberry") is a \e view. A view is always part of a plug-in and provides one specific function, such as grouping all gui elements needed for providing segmentation algorithms or loading dicom images. Views usually contain any code which communicates with the user, performs input checking and similar, but no advanced algorithms. + +\subsection ModularizationPagePlugInBundles Plugins + +The next smallest unit is a CTK Plug-in (the term \e Bundle is used interchangeably). They can be found in MITK/Plugins or MITK/BlueBerry/Bundles. Plugins can be individually switched on and off during the CMake configuration. + +A plugin usually represents a solution to a specific problem, such as segmentation or data management. As such they may provide any number of views and other contributions to the MITK application framework. + +If you want to create your own MITK plugin you find further information \ref NewPluginPage "here". + +\subsection ModularizationPagePerspectives Perspectives + +Perspectives represent a configuration for the MITK application framework (specifically, for the \e Workbench) needed for a specific workflow. They allow the arrangement of different views (contributed by different plug-ins) to reflect the usage scenario, such as a data loading view in the top right, a segmentation view to the right and a visualization view to the bottom right. A perspective is provided by arbitrary plug-ins as an extension (contribution) to the application framework. + +\subsection ModularizationPageApplications Applications + +A specific selection of plug-ins together with custom configuration data defines the functionality for an application. The application corresponds to an executable and enables very specific program behaviour and configuration. + +Example applications can be found in the MITK/Applications directory. + +\section ModularizationPageHowTo How to create your own application + +It is suggested to use the project generator provided by MITK unless one knows what one is doing. See \ref NewPluginWithProject "here" for more information. +*/ diff --git a/Core/Documentation/Doxygen/Concepts/Overview.dox b/Core/Documentation/Doxygen/Concepts/Overview.dox index 1891b083fb..f5def8bb90 100644 --- a/Core/Documentation/Doxygen/Concepts/Overview.dox +++ b/Core/Documentation/Doxygen/Concepts/Overview.dox @@ -1,52 +1,47 @@ /** -\page OverviewPage Overview on the Medical Imaging Interaction Toolkit (MITK) +\page OverviewPage Introduction: Overview on the Medical Imaging Interaction Toolkit (MITK) -Four issues are important for advanced interactive medical imaging software: -
    -
  • the data, not only the original images, but also other data like segmentation results, -surfaces, vessel-trees, etc., -
  • the algorithms to extract information from the data or to generate new data, -
  • the visualization of the data, which requires information about the position of the data -in space and time and -
  • to allow the user to conveniently interact with the data. -
+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. -Today, there are two major open-source toolkits for visualization and image processing: -
    -
  • the Visualization Toolkit (VTK), which provides "a wide variety -of visualization algorithms including scalar, vector, tensor, texture, and volumetric methods; -and advanced modeling techniques such as implicit modelling, polygon reduction, mesh smoothing, -cutting, contouring, and Delaunay triangulation. In addition, dozens of imaging algorithms have -been directly integrated to allow the user to mix 2D imaging / 3D graphics algorithms and data." -(from the Visualization Toolkit (VTK) ). -
  • the Insight Toolkit (ITK), which provides registration and -segmentation algorithms. -
+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. -ITK provides powerful algorithms, but is not designed for visualization or interaction. VTK has -powerful visualization capabilities, but only low-level support for interaction such as picking -methods, rotation, movement and scaling of objects. Support for high level interactions with data -as, for example, the interactive construction and modification of deformable models, and -undo-capabilities is outside the scope of VTK. Furthermore, it is designed to create \em one -\em kind of view on the data. There is no special assistance to realized multiple, different -views of the data (as a multiplanar reconstruction and a 3D rendering). Finally, VTK supports only -2D and 3D data, not 3D+t data, which are required for some medical applications, and there is -currently no convenient possibility to combine VTK with ITK. +\section OverviewPage_DesignOverview Design Overview -The aim of MITK is to use VTK and ITK, allow an easy combination of both and extend them with those -features, which are outside the scope of both. +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. -\section OverviewPage_DesignOverview Design Overview +\image html MitkOverview.png "Overview of MITK" + +Like shown above, MITK uses the following libraries. +
    +
  • The Insight Toolkit (ITK), which provides registration and +segmentation algorithms, but is not designed for visualization or interaction. + +
  • The Visualization Toolkit (VTK), which provides powerful visualization capabilities + and low-level support for interaction such as picking methods, rotation, movement and scaling of objects. -The basic design concept of MITK is model-view-controller (MVC). Although some people think MVC is -out-of-date, it is useful in this case (and also we do not really use pure MVC): we have data -(\em model), on which we want to have different @em views and we want to interact with the data -(\em controller), which should result in a simultaneous and consistent update of all views. +
  • The Common Toolkit (CTK), which focuses on DICOM support and a plug-in framework. + +
  • The Qt Cross-platform application and UI framework (Qt) as a framework for UI and application + support. +
+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:
    -
  • data management classes -
  • -
-... - */ +
  • High level interactions with data. +
  • Specialized medical imaging algorithms (e.g. segmentation) +
  • Support of 3D + t data. +
  • Complete application framework, expandable by plug-ins +
  • Standard tools for medical imaging as default plug-ins (e.g. measurement, segmentation) +
  • Many specialized module for different topics on medical imaging (e.g. diffusion imaging, image guided therapy, live image/ultrasound data processing) + + +*/ diff --git a/Core/Documentation/Doxygen/Concepts/Pipelining.dox b/Core/Documentation/Doxygen/Concepts/Pipelining.dox new file mode 100644 index 0000000000..2f936b0fab --- /dev/null +++ b/Core/Documentation/Doxygen/Concepts/Pipelining.dox @@ -0,0 +1,94 @@ +/** +\page PipelineingConceptPage The Pipelining Concept + +Available Sections: + +-# \ref PipelineingConceptPage_Introduction "Introduction to Pipelining" +-# \ref PipelineingConceptPage_InMITK "Pipelining in MITK" + -# \ref PipelineingConceptPage_Update "The Update() Mechanism" + -# \ref PipelineingConceptPage_Hierarchy "Pipeline Hierarchy" +-# \ref PipelineingConceptPage_WorkWith "Working with Filter" + -# \ref PipelineingConceptPage_Setup "Setting Up a Pipeline" + -# \ref PipelineingConceptPage_Implement "Writing your own Filter" + + +\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 segements 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 + +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 + +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 + +\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 + +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/Properties.dox b/Core/Documentation/Doxygen/Concepts/Properties.dox index 1a9cb7236d..ead012076b 100644 --- a/Core/Documentation/Doxygen/Concepts/Properties.dox +++ b/Core/Documentation/Doxygen/Concepts/Properties.dox @@ -1,226 +1,233 @@ /** -\page PropertiesPage The MITK Property Concept +\page PropertiesPage Properties \section PropertyConcept The Concept Behind MITK Properties Properties belong to a datanode and contain information relevant to the handling of the node by MITK. They provide a place to store additional information which is not part of the actual data, and as such have no reason to be contained within the data/file itself, but might be needed for such things as rendering (e.g. transfer functions) or interaction (e.g. the name of the node). -Propteries can be read an set: +Propteries can be read and set: \code -mitk::ColorProperty::Pointer colorProperty = dynamic_cast(node->GetProperty("color")); +//1: Read a property +mitk::Property::Pointer readProperty = node->GetProperty("color"); //read the property "color" from the data node +mitk::ColorProperty::Pointer colorProperty = dynamic_cast(readProperty); //cast this property to the subtype ColorProperty -node->SetProperty( "IsTensorVolume", mitk::BoolProperty::New( true ) ); +//2: Write a property +mitk::BoolProperty::Pointer newProperty = mitk::BoolProperty::New( true ); //create a new property, in this case a boolean property +node->SetProperty( "IsTensorVolume", newProperty ); //add this property to node with the key "IsTensorVolume" \endcode \section ListOfIndependentProperty A List Of Module Independent Properties +This section lists most of the known properties in MITK according to where they are used. Not every node needs each +(or even close to) of these properties. + \subsection FileManagement File Management
    • path - The physical path the file was loaded from
    • name - The node name in the datamanager
    • selected - Whether the node is selected in the datamanager
    \subsection GenericRenderingProperty Generic Rendering Properties
    • color - Color the surface, grey value image, whatever should be rendered in (default is usually white). There is a special mitk::ColorProperty and you can use the Getter/Setter methods to access it. The color is defined with three values (RGB) in the range between 0.0 and 1.0. \remark If you are inside a mapper you can use the following code to access the color: \code float rgb[3]={1.0f, 1.0f, 1.0f}; GetColor( rgb, BaseRenderer ); \endcode (The BaseRenderer is usually known inside a mapper). \warning -This property will not effect images if you set the property "use color" +This property will not affect images if you set the property "use color" to false. In that case a user-defined lookuptable will be used.
    • in plane resample extent by geometry - Toggles: Resampling grid corresponds to the current world geometry. This means that the spacing of the output 2D image depends on the currently selected world geometry, and *not* on the image itself.
    • Resampling grid corresponds to the input geometry. This means that the spacing of the output 2D image is directly derived from the associated input image, regardless of the currently selected world geometry.
    • layer - Controls which image is considered "on top" of another. In the case that two should inhabit the same space, the higher layer occludes lower layer. So far it works for images and pointsets. The layer property applies only for similar datatypes. Pointsets are always rendered in front of images and the layer will not have any effect.
    • levelwindow - In general, grayscale images contain values between 0 and 255. Therefore, the default window boundaries are set respectively. For displaying the image within a certain range, ie. 50 - 200, this property can be used to adjust the minimum and maximum boundary.
    • LookupTable - This property contains a user defined lookuptable, which can be used to map scalar values to color values. Example: If an image contains a value of 128, in the resulting image the passed lookuptable could map this value to red (255, 0, 0). \warning This property will not effect images if you set the property "use color" to true. In that case color properties and a default lookuptable are used. Example for setting up a lookuptable in MITK: \code #include #include #include #include [...] vtkSmartPointer vtkLUT = vtkSmartPointer::New(); vtkLUT->SetRange(100,200); //define your table here vtkLUT->Build(); //pass the table to MITK mitk::LookupTable::Pointer mitkLookupTable = mitk::LookupTable::New(); mitkLookupTable->SetVtkLookupTable(vtkLUT); mitk::LookupTableProperty::Pointer LookupTableProp = mitk::LookupTableProperty::New( mitkLookupTable ); result->SetProperty( "LookupTable", LookupTableProp ); result->SetBoolProperty("use color", false); result->Update(); \endcode
    • opacity - Alpha (or transparency) value of the node/image/surface etc.. The range of the opacity is between 0.0 and 1.0. \remark If you are inside a mapper you can use the following code to access the opacity: \code float opacity=1.0f; GetOpacity( opacity, BaseRenderer ); \endcode (The BaseRenderer is usually known inside a mapper).
    • reslice interpolation - This property takes effect in swivel mode or crosshair rotaiton only. The interpolation modes "Nearest", "Linear", and "Cubic" are available and effect the pixel outcome along the rotated plane.
    • texture interpolation - This property toggles interpolation of the texture. If enabled, edges between image pixels are blurred. If disabled, edges remain sharp.
    • use color - This property toggles the use of a user-defined lookuptable for the rendering. True: use the LUT; False: use the color propery. Example for setting up a lookuptable in MITK: \code #include #include #include #include [...] vtkSmartPointer vtkLUT = vtkSmartPointer::New(); vtkLUT->SetRange(100,200); //define your table here vtkLUT->Build(); //pass the table to MITK mitk::LookupTable::Pointer mitkLookupTable = mitk::LookupTable::New(); mitkLookupTable->SetVtkLookupTable(vtkLUT); mitk::LookupTableProperty::Pointer LookupTableProp = mitk::LookupTableProperty::New( mitkLookupTable ); result->SetProperty( "LookupTable", LookupTableProp ); result->SetBoolProperty("use color", false); result->Update(); \endcode
    • visible - toggle node/image/surface being rendered at all
    \subsection SurfaceRenderingProperties Surface Rendering Properties
    • back color - in 2D, color of the normals outside the surface
    • back normal lenth (px) - in 2D, length of the normals in pixels (When decreasing it the color using the front color is shorter?)
    • color mode - (From VTK) Control how the scalar data is mapped to colors. By default (ColorModeToDefault), unsigned char scalars are treated as colors, and NOT mapped through the lookup table, while everything else is. Setting ColorModeToMapScalars means that all scalar data will be mapped through the lookup table.
    • draw normals 2d - in 2D, toggles the presence of normals
    • front color - in 2D, color of the normals inside the surface
    • front normal lenth (px) - in 2D, length of the normals in pixels (When decreasing it the color using the back color is shorter?)
    • invert normals - in 2D, switch front/back normals
    • line width - in 2D, controls the thickness of the line where the surface intersects the plane (and normals)
    • material.ambientCoefficient - in 3D ambient lighting
    • material.diffuseCoefficient - in 3D scattering of light
    • material.interpolation - Choose which interpolation algorithm to use for surface construction
    • material.representation - Choose the representation to draw the mesh in (Surface, Wireframe, Point Cloud)
    • material.specularCoefficient - in-/decrease non-scattered reflection
    • material.specularPower - control percentage of non-scattered reflection
    • material.wireframeLineWidth - width of the wires if wireframe representation is
    • scalar mode - (From VTK) Control how the filter works with scalar point data and cell attribute data. By default (ScalarModeToDefault), the filter will use point data, and if no point data is available, then cell data is used. Alternatively you can explicitly set the filter to use point data (ScalarModeToUsePointData) or cell data (ScalarModeToUseCellData). You can also choose to get the scalars from an array in point field data (ScalarModeToUsePointFieldData) or cell field data (ScalarModeToUseCellFieldData). If scalars are coming from a field data array, you must call SelectColorArray before you call GetColors. When ScalarMode is set to use Field Data (ScalarModeToFieldData), you must call SelectColorArray to choose the field data array to be used to color cells. In this mode, if the poly data has triangle strips, the field data is treated as the celldata for each mini-cell formed by a triangle in the strip rather than the entire strip.
    • scalar visibility - (From VTK) Turn on/off flag to control whether scalar data is used to color objects.
    • selected - whether the node is selected
    • shader - which shader to use for surface rendering, currently the options are "fixed" and "mitkShaderLightning"
    \subsection VolumeRenderingProperties Volume Rendering Properties
    • TransferFunction - contains transfer function for use in coloring image
    • volumerendering - Should the volume be rendered or not
    • volumerendering configuration - Choice between Composite und MIP
    • volumerendering.cpu.ambient - ambient lighting
    • volumerendering.cpu.diffuse - in-/decrease light dispersion
    • volumerendering.cpu.specular - in-/decrease non-scattered reflection
    • volumerendering.cpu.specular.power - control percentage of non-scattered reflection
    • volumerendering.gpu.ambient - same as cpu with gpu
    • volumerendering.gpu.diffuse - same as cpu with gpu
    • volumerendering.gpu.reducesliceartifacts - Reduce slice artifacts
    • volumerendering.gpu.specular - same as cpu with gpu
    • volumerendering.gpu.specular.power - same as cpu with gpu
    • volumerendering.gpu.usetexturecompression - use texture compression
    • volumerendering.ray.ambient - same as cpu with ray
    • volumerendering.ray.diffuse - same as cpu with ray
    • volumerendering.ray.specular - same as cpu with ray
    • volumerendering.ray.specular.power - same as cpu with ray
    • volumerendering.usegpu - Whether to use the GPU for rendering or not
    • volumerendering.uselod - Whether to use the Level Of Detail mechanism or not
    • volumerendering.usemip - Whether to utilize maximum intensity projection
    • volumerendering.useray - Whether to use raycasting or not
    \remark Uselod can be active with usegpu, usemip, useray, but any of the latter can not be used with another one of them. \subsection PointSetProperties Point Set Properties
    • close contour - Toggles whether the first and the last point of a contour (connecting pieces between following points of a pointset) are connected.
    • contourcolor - Determines the color of the contour (connecting pieces between following points of a pointset). Visible only if "show contour" is active.
    • contoursize - Represents the diameter of the contour (which is kind of a tube between the following points of a pointset). Visible only if "show contour" is active.
    • distance decimal digits - Sets the number of decimal places for the euclidean point to point distance which can be displayed by activating "show distances".
    • point 2D size - The positions of points in the 2D view are represented by crosses. "point 2D size" determines the size of this crosses.
    • point line width - The positions of points in the 2D view are represented by crosses. "point line width" determines the thickness of this crosses.
    • pointsize - The positions of points in the 3D view are represented by spheres. "pointsize" determines the diameter (size) of this spheres.
    • selectedcolor - Sets the color for selected points from a pointset.
    • show angles - If "show contour" is active the angles between two contour parts can be shown.
    • show contour - Connects following points of a pointset by drawing connecting pieces between this points.
    • show distance lines - Shows all angles and lines of the contour (in 2D views) even if they are not on the view's current slice.
    • show distances - Draws lines between following points (in 2D views) and displays the euclidean distance between this points.
    • show points - Toggles if the points are visible or not in the view.
    • updateDataOnRender - If "true" the pointset is updated before rendering. If the pointset is part of a filter pipeline this also causes an update to the pipeline which sometimes may be not desired so it can be switched of by setting it to false.
    Information on properties not in this list can be found in the appropriate module. \subsection PropertiesPageSeeAlso See Also
    • \subpage PlanarPropertiesPage
    • \subpage SegmentationPropertiesPage
    */ diff --git a/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox b/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox index 1f1f070925..6b59d650e6 100644 --- a/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox +++ b/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox @@ -1,107 +1,83 @@ /** -\page QVTKRendering Rendering in MITK by means of the QT-VTK widget - -\brief This page describes the MITK rendering mechanism switching to the QTVTK widget. MITK releases with version > 0.8 use this new rendering pipeline. Several changes in contrast to the established old rendering pipeline are explained in the following. - - +\page QVTKRendering Rendering Concept +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" -\li In VTK, the vtkRenderWindow coordinates the rendering process. Several vtkRenderers may be associated to one vtkRenderWindow. -\li All visible objects, which can exist in a rendered scene (2D and 3D scene), inherit from vtkProp. -\li A vtkPropAssembly is an assembly of several vtkProps, which appears like one single vtkProp. -\li 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. -\li 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. +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 -In contrast to the former MITK rendering pipeline, the new process is tightly connected to VTK, which makes it straight forward and simple. -In consequence, several MITK classes have been dropped out: - -\li Qmitk::SelectableGLWidget and all inheritors -\li mitk::RenderWindow -\li mitk::VtkRenderWindow and all inheritors -\li mitk::OpenGLRenderer -\li mitk::SimpleTextRendering - -Instead, we use the above mentioned "vtkMitkRenderProp" in conjunction with a new mitk::VtkPropRenderer for integration into the VTK pipeline. Also, the QmitkRenderWindow does not inherit -from mitk::RenderWindow, but from the QVTKWidget, which is provided by VTK. +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" -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 behaviour. -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. +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. -A sequence diagramm, which illustrates the actions after calling the Render() function of the MITK-Scene vtkRenderer is shown below: +A sequence diagram, which illustrates the actions after calling the Render() function of the MITK-Scene vtkRenderer is shown below: \image html qVtkRenderingSequence.png "Sequence overview MITK scene rendering" +\section QVTKRendering_programmerGuide User Guide: Programming hints for rendering related stuff (in plugins) +\li The QmitkRenderWindow can be accessed like this: this->GetRenderWindowPart()->GetRenderWindow("transversal"); +\li The vtkRenderWindow can be accessed like this: this->GetRenderWindowPart()->GetRenderWindow("transversal")->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("transversal")->GetVtkRenderWindow()); - -\section QVTKRendering_programmerGuide User Guide: Changes in programming of rendering related stuff - -\li Within a functionality the vtkRenderWindow can be accessed like this: vtkRenderWindow* vtkRenWin = m_MultiWidget->mitkWidget4->GetRenderWindow(); -\li Within a functionality the mitkBaseRenderer can be accessed like this: mitk::BaseRenderer* renderer = mitk::BaseRenderer::GetInstance(m_MultiWidget->mitkWidget4->GetRenderWindow()); -\li An update request of the overall QmitkStdMultiWidget can be performed with: m_MultiWidget->RequestUpdate(); -\li An update of the overall QmitkStdMultiWidget can be forced with: m_MultiWidget->ForceImmediateUpdate(); -\li A single QmitkRenderWindow update request can be done like this: mitk::RenderingManager::GetInstance()->RequestUpdate(m_MultiWidget->mitkWidget4->GetRenderWindow()); -\li A single QmitkRenderWindow update can be forced like this: mitk::RenderingManager::GetInstance()->ForceImmediateUpdate(m_MultiWidget->mitkWidget4->GetRenderWindow()); -\li Getting a BaseRenderer by the widget name can be done like this: mitk::BaseRenderer::GetByName("mitkWidget1"); +\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: - -\li 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. - - - +\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. */ diff --git a/Core/Documentation/Doxygen/Concepts/RenderingTests.dox b/Core/Documentation/Doxygen/Concepts/RenderingTests.dox index 2c60491f2a..2dbe0bd4ec 100644 --- a/Core/Documentation/Doxygen/Concepts/RenderingTests.dox +++ b/Core/Documentation/Doxygen/Concepts/RenderingTests.dox @@ -1,97 +1,97 @@ namespace mitk{ /** \page RenderingTests Automatic Rendering Tests Available sections: -# \ref RenderingTests_WhatIsARenderingTest "What is an automatic rendering test?" -# \ref RenderingTests_HowToCreateATest "How to create a rendering test" \section RenderingTests_WhatIsARenderingTest What is an automatic rendering test? An automatic rendering test is a powerful tool to test rendering results automatically via dashboard. Regarding rendering lots of different sources influence the output on the screen (e.g. different mappers, renderes, camera settings or the algorithm creating the data). Thus, during the rendering process of an image many different classes are involved and can have impact on the output. A minor change in an important class (e.g. mitkVtkPropRenderer) can have major impact on the actual rendering. An automatic rendering test takes an arbitrary object as input (e.g. image, surface, point set), renders this into an mitkRenderWindow, makes a screen shot of that renderwindow and finally compares that screen shot to a given reference. Of course, the reference has to be defined by the user. Internally, a VTK test method is used to compare both screen shots and measure differences. In case of failure, a difference can be generated to show exactly which pixels are rendered incorrectly. Implementing automatic rendering tests for algorithms ensures that algorithms deliver the same output as they used to do in previous version of MITK. \section RenderingTests_HowToCreateATest How to create your own automatic rendering test To create an automatic rendering test you should use an existing test as example (e.g. mitkImageVtkMapper2DTest). -1. Adding the test to CMake +\subsection RenderingTests_HowToCreateATest_Sub1 Adding the test to CMake Like adding any test with parameters to CMake, you have to add a custom test to the files.cmake and the corresponding CMakeLists.txt: For instance a test for the mitkImageVtkMapper2D has to be added like this: files.cmake \code set(MODULE_CUSTOM_TESTS ... mitkImageVtkMapper2D.cpp ) \endcode CMakeLists.txt \code mitkAddCustomModuleTest(mitkImageVtkMapper2D_rgbaImage640x480 mitkImageVtkMapper2D #custom name of the test and executable ${MITK_DATA_DIR}/RenderingTestData/rgbaImage.png #input image to load in data storage -V ${MITK_DATA_DIR}/RenderingTestData/ReferenceScreenshots/rgbaImage640x480REF.png #corresponding reference screenshot ) \endcode -The first parameter defines a name for the test on the dashboard. This is a feature to distinguish +The first parameter defines a custom name for the test. This is a feature to distinguish between tests with different inputs. In this example the test is named mitkImageVtkMapper2D_rgbaImage640x480 to show that this test is using the test image rbgaImage640x480 as input. -The next parameters sets test name (i.e. the name of the test class). Here: mitkImageVtkMapper2D. +The next parameters sets test executable name (i.e. the name of the test class). Here: mitkImageVtkMapper2D. The next parameter(s) are used to pass the input to the test. For instance, it is possible to set multiple objects as input for a test (e.g. /path/to/img1.jpg /path/to/img2.pic /path/to/pointset.mps). All test data for core tests should be placed into the MITK-DATA repository inside the folder: -${MITK_DATA_DIR}/RenderingTestData/ -It is possible to create another folders for other modules/bundles. +${MITK_DATA_DIR}/RenderingTestData/. It is possible to create other folders for different modules or bundles. The option -V defines the path to the reference screen shot and is internally used by VTK. The reference -screen shot is highly important and has to be triple-checked if is correct!!! The +screen shot is highly important and has to be proven if is correct. The mitkRenderingTestHelper offers means to capture a screen shot of a renderwindow. Capturing a reference screen shot should happen just once and NOT be a permanent part of the test. It is also possible to set the option -T /path/to/directory/. This option is internally used by VTK -to save a difference image. This is meant for debugging and should not be used on the dashboard. +to save a difference image. This is meant for debugging and should not be used for the final implemenation of a test. -2. Coding the test +\subsection RenderingTests_HowToCreateATest_Sub2 Coding the test + Writing the test code is pretty straight forward. In the example of the mitkImageVtkMapper2DTest the input parameters are added to a datastorage and rendered into a render window via the mitkRenderingTestHelper. Last, the vtkTesting macro is called to compare the given reference to the data rendered in the renderwindow: \code int retVal = vtkRegressionTestImage( renderingHelper.GetVtkRenderWindow() ); //retVal meanings: (see VTK/Rendering/vtkTesting.h) //0 = test failed //1 = test passed //2 = test not run //3 = something with vtkInteraction MITK_TEST_CONDITION( retVal == 1, "VTK test result positive" ); \endcode If the content of the previously filled renderwindow does not equal the reference, the test will fail. Feel free to modify the data before rendering. E.g. create a surface from the loaded image and render that surface afterwards or add compute QBalls for an image and render those. Happy testing! */ } diff --git a/Core/Documentation/Doxygen/Concepts/TestsGeneral.dox b/Core/Documentation/Doxygen/Concepts/TestsGeneral.dox new file mode 100644 index 0000000000..4e0992f1a5 --- /dev/null +++ b/Core/Documentation/Doxygen/Concepts/TestsGeneral.dox @@ -0,0 +1,93 @@ +/** +\page GeneralTests General: Tests in MITK + +Two types of standardizes automated tests are provided by MITK. These types are unit tests and rendering tests . This section will describe unit testing in MITK, while more information on rendering tests can be found in the section \ref RenderingTests. + +-# \ref GeneralTestsSection1 "Basic Information on Unit Testing" +-# \ref GeneralTestsSection2 "Adding a Unit Test to MITK" + -# \ref GeneralTestsSection2_1 "Structure your test method" +-# \ref GeneralTestsSection3 "Run a Unit Test with MITK" +-# \ref GeneralTestsSection4 "MITK Testing Macros" + +\section GeneralTestsSection1 Basic Information on Unit Testing + +The basic idea about unit testing is to write a test for every class (unit) of your software. The test should then run all methods of the tested class and check if the results are correct. Thus, the testing environment for MITK allows for simple implementation of corresponding test methods for MITK classes. + +The build system of MITK generates a test driver which includes all tests that have been added to the project. Alternativly you can run MITK tests by using the program ctest. This is the way all MITK tests run on the continous dart clients of MITK. The results of these runs can be found at http://cdash.mitk.org. + +The following sections will explain how to write your own tests with MITK and how to run them. The last section will describe the testing macros of MITK in detail. + +\section GeneralTestsSection2 Adding a Unit Test to MITK + +To add a test, you simply need to create a new file "mitkMyTest.cpp" in the folder "Testing" of the software module to which you want to add the test. The file must contain such a method: \code int mitkMyTest(int argc, char* argv[]) \endcode This method is automatically called by the test driver. A header file to this cpp file is not needed. An example for a simple test method is shown next. + +\code +int mitkMyTest(int argc, char* argv[]) +{ + MITK_TEST_BEGIN("MyTest"); + MITK_TEST_CONDITION_REQUIRED(true,"Here we test our condition"); + MITK_TEST_END(); +} +\endcode + +Additionaly you've to add the test file to the files.cmake of your testing directory. In the files.cmake you'll find a command "SET(MODULE_TESTS [...])", this is where you've to add the filename of your test. This will add your test to the test driver. A possible files.cmake where a test have already been added is shown next. +\code +SET(MODULE_TESTS + mitkMyTest.cpp + [...] +) +\endcode +Finally you only have to run cmake one your project and then compile the test driver. Don't forget to turn "BUILD_TESTING" on, when running cmake. + +\subsection GeneralTestsSection2_1 Structure your test method + +When implementing more complex test methods you might want to structure them, e.g. by using sub methods. This is also possible. You can create a test class and add static methods which can then be called in your main test method. This is a simple way to keep a clear structure in your test file. An example for such a structured test file is shown next. + +\code +//first: your test class with static methods, if it comes before the main test method +// like shown here, you still don't need a header and you can keep your code as +// simple as possible +class mitkMyTestClass +{ +public: + + static void TestInstantiation() + { + //do your instantiation test here + } + + static void TestMethod1() + { + //do a test of method 1 here + } +};//do not forget the semicolon at this place! + +//secondly: your main test method +int mitkMyTest(int argc, char* argv[]) +{ + MITK_TEST_BEGIN("MyTest"); + mitkMyTestClass.TestInstantiation(); + mitkMyTestClass.TestMethod1(); + MITK_TEST_END(); +} +\endcode + +\section GeneralTestsSection3 Run a Unit Test with MITK + +After building and compiling MITK, there are two ways to run your test. Firstly, you can run your test using the executable test driver. Secondly, you can use the external program ctest. + +If you use the test driver, you only need to start the executable. If you start it without parameters, it will then give you an overview of all tests which are included in this test driver and you can choose one by typing a number. + +\note This way you can not set additional input, such as images. + +Alternatively you can give your test driver the name of your test as parameter. Then this test will be started directly. You are also allowed to give more parameters which are then given to the main test method as parameters (argv[]). + +If you want to use ctest instead of the test driver you need to start a command line, go to the binary directory of MITK and call ctest. To avoid errors, check if your path variable contains all relevant paths to start MITK. + +\section GeneralTestsSection4 MITK Testing Macros + +MITK offers testing macros to simplify testing, e.g. to test your testing conditions. These macros can be found in the header mitkTestingMacros.h . + + + +*/ diff --git a/Core/Documentation/Doxygen/Concepts/images/introduction/MitkOverview.png b/Core/Documentation/Doxygen/Concepts/images/introduction/MitkOverview.png new file mode 100644 index 0000000000..e9dd638ac6 Binary files /dev/null and b/Core/Documentation/Doxygen/Concepts/images/introduction/MitkOverview.png differ diff --git a/Core/Documentation/Doxygen/Concepts/images/mitkimage/mitkimagehierarchy.png b/Core/Documentation/Doxygen/Concepts/images/mitkimage/mitkimagehierarchy.png new file mode 100644 index 0000000000..b73b652c63 Binary files /dev/null and b/Core/Documentation/Doxygen/Concepts/images/mitkimage/mitkimagehierarchy.png differ diff --git a/Core/Documentation/Doxygen/Concepts/images/mitkimage/mitkimagememory.png b/Core/Documentation/Doxygen/Concepts/images/mitkimage/mitkimagememory.png new file mode 100644 index 0000000000..706532efcc Binary files /dev/null and b/Core/Documentation/Doxygen/Concepts/images/mitkimage/mitkimagememory.png differ diff --git a/Core/Documentation/Doxygen/Concepts/images/pipelining/pipelining_example_ct.png b/Core/Documentation/Doxygen/Concepts/images/pipelining/pipelining_example_ct.png new file mode 100644 index 0000000000..1583a91853 Binary files /dev/null and b/Core/Documentation/Doxygen/Concepts/images/pipelining/pipelining_example_ct.png differ diff --git a/Core/Documentation/Doxygen/Concepts/images/pipelining/pipelining_example_us.png b/Core/Documentation/Doxygen/Concepts/images/pipelining/pipelining_example_us.png new file mode 100644 index 0000000000..00f1c88427 Binary files /dev/null and b/Core/Documentation/Doxygen/Concepts/images/pipelining/pipelining_example_us.png differ diff --git a/Core/Documentation/Doxygen/Concepts/images/pipelining/pipelining_hierarchy.png b/Core/Documentation/Doxygen/Concepts/images/pipelining/pipelining_hierarchy.png new file mode 100644 index 0000000000..f469bcd0fa Binary files /dev/null and b/Core/Documentation/Doxygen/Concepts/images/pipelining/pipelining_hierarchy.png differ diff --git a/Core/Documentation/Doxygen/Concepts/images/pipelining/pipelining_update.png b/Core/Documentation/Doxygen/Concepts/images/pipelining/pipelining_update.png new file mode 100644 index 0000000000..103c5f8e0e Binary files /dev/null and b/Core/Documentation/Doxygen/Concepts/images/pipelining/pipelining_update.png differ diff --git a/Documentation/Doxygen/Modules/DataTreeAndIterators.dia b/Documentation/Doxygen/Modules/DataTreeAndIterators.dia deleted file mode 100644 index 36154f9f6b..0000000000 Binary files a/Documentation/Doxygen/Modules/DataTreeAndIterators.dia and /dev/null differ diff --git a/Documentation/Doxygen/Modules/DataTreeAndIterators.png b/Documentation/Doxygen/Modules/DataTreeAndIterators.png deleted file mode 100644 index ed59e55435..0000000000 Binary files a/Documentation/Doxygen/Modules/DataTreeAndIterators.png and /dev/null differ diff --git a/Documentation/Doxygen/Modules/DataTreeNodeFactoryMechanism.png b/Documentation/Doxygen/Modules/DataTreeNodeFactoryMechanism.png deleted file mode 100644 index aaa32efca7..0000000000 Binary files a/Documentation/Doxygen/Modules/DataTreeNodeFactoryMechanism.png and /dev/null differ diff --git a/Documentation/Doxygen/Modules/DataTreeNodeFactoryMechanism.vsd b/Documentation/Doxygen/Modules/DataTreeNodeFactoryMechanism.vsd deleted file mode 100644 index 1a52334470..0000000000 Binary files a/Documentation/Doxygen/Modules/DataTreeNodeFactoryMechanism.vsd and /dev/null differ diff --git a/Documentation/Doxygen/Modules/ModuleApplications.dox b/Documentation/Doxygen/Modules/ModuleApplications.dox deleted file mode 100644 index f40b1724ce..0000000000 --- a/Documentation/Doxygen/Modules/ModuleApplications.dox +++ /dev/null @@ -1,14 +0,0 @@ -/** - \defgroup Application Application-level Classes - - This category includes classes on the application-level, e.g., pre-defined widgets. - - It also includes the concept to organize an application in so-called "functionalities" (subclasses of - QmitkFunctionality). Each functionality can have its own workspace area (or share one workspace - with other functionalities) and a control area. Functionalities are added to an instance of - QmitkFctMediator, which organizes the switching between the functionalities. This is a - "toolbox-in-the-large", e.g., for combining and switching between one functionality for - segmentation and another for registration. - -*/ - diff --git a/Documentation/Doxygen/Modules/ModuleApplicationsFunctionalities.dia b/Documentation/Doxygen/Modules/ModuleApplicationsFunctionalities.dia deleted file mode 100644 index 97e71347e2..0000000000 Binary files a/Documentation/Doxygen/Modules/ModuleApplicationsFunctionalities.dia and /dev/null differ diff --git a/Documentation/Doxygen/Modules/ModuleApplicationsFunctionalities.dox b/Documentation/Doxygen/Modules/ModuleApplicationsFunctionalities.dox deleted file mode 100644 index 22b31a6e07..0000000000 --- a/Documentation/Doxygen/Modules/ModuleApplicationsFunctionalities.dox +++ /dev/null @@ -1,119 +0,0 @@ -/** - \defgroup Functionalities Functionalities - \ingroup Application - - - -This is a preliminary version and not yet official documentation. - - - -Available sections: - - \ref overviewApplicationFunctionalities - - \ref inthisgroupApplicationFunctionalities - - \ref notinthisgroupApplicationFunctionalities - - \ref implementApplicationFunctionalities - - \ref seealsoApplicationFunctionalities - - \ref futureApplicationFunctionalities - - - \section overviewApplicationFunctionalities Rationale and overview - -Functionalities facilitate the structured combination of modules for specific tasks. -They combine a user interface with algorithmic function. A functionality consists of (compare screen-shot) - -\li an identification (name of the functionality, icon, tool-tip, ...) -\li a workspace area, where the main interaction with data objects is taking place -\li a control area containing GUI elements to set parameters of the used algorithms -\li the algorithmic implementation (not visible to the user) - -Communication between functionalities is largely based on the data tree. Each -functionality accesses the data objects contained in the tree, changes them and/or -creates new data objects. Other functionalities can continue to work on the changed -and/or newly created data tree entries. By that, functionalities can communicate -without becoming dependent on each other. - -\image html PartsOfAFunctionaliy.jpg "The visible parts of a functionality. The algorithmic implementation, which is also part of a functionality has no visual representation." - - - \subsection inthisgroupApplicationFunctionalities What belongs into this group - -A functionality should comprise a complete set of controls that are necessary to -complete a certain task, where the task should be on a reasonably high level that makes -sense for the user of the application. -Before you consider a new functionality, check if the feature you want to implement could -instead be implemented as a \ref Widgets "widget" that can be used in different contexts. -Possible examples for functionalities are: - - - "Segmentation": a tool for segmentation that comprises several controls (selection of the - image to be segmented, list of available segmentations, selection of tools for segmentation) - - "Movie generation": when you have a scene ready for presentation and want to generate - a movie from it, with animation through slices, rotation in 3D, stepping through time, etc. - - "Vessel editing": a complete set of tools for working with a vessel tree (creating from segmentation, - editing, annotation, searching, etc. - - \subsection notinthisgroupApplicationFunctionalities What does not belong into this group - -A set of controls that could possibly be of use in more than one context should not -be a functionality, but rather a widget. Widgets are good for sub-tasks from the user's -point of view. -Some examples for things that should not be implemented as functionality - - - a control that allows to select an image - - a control that lists available segmentations - - a control that shows information about certain scene elements - - \section implementApplicationFunctionalities Practical issues - -Technically a functionality is a derivative class of QmitkFunctionality. The -functionality object gets an mitk::DataTreeIteratorBase when it is created and -has to return on request QWidgets for its main widget and its control area, and -a QAction (Combination of icon, description and keyboard shortcut) for its identification. - -The functionality can own and use arbitrary objects to create and manipulate -objects of the data tree. - -A functionality is meant to exist only with the context of an application. It is -the application's task to create an environment, where it can place the main and -control widgets of functionalities, and to create a data tree. - -Since the intention is to combine several functionalities in one application, -there is a "functionality mediator" of class QmitkFctMediator. A single instance -of this object is created by the application and it is told about every -functionality that should be available for the application. It is then the -mediator's job to arrange the correct switching between functionalities, which -involves calling the functionalities' Activated() and Deactivated() methods and -hiding/showing the correct main and control widgets for each functionality. - -The diagram below shows the important classes related to a functionality. - -\image html ModuleApplicationsFunctionalities.png "Classes related to a functionality" - - \section seealsoApplicationFunctionalities See also - - Documentation you should read - - \li \ref Widgets - \li \ref SampleApp - - Classes you should be aware of: - - \li QmitkFunctionality - \li QmitkFctMediator - \li mitk::DataTree - - If you want to enhance the SampleApp, you should read the directions on \ref NewFunctionalityPage "how to create a new functionality". - - \section futureApplicationFunctionalities Plans for the future - -One idea for future development is to change the current use of functionalities in a way that -different functionalities can be active at the same time. This would allow the user to select -and arrange a sensible set of functionalities for his or her specific task at run-time. This would -allow for more flexible applications. - -Implementing this idea would probably require changes to existing functionalities, since currently -authors of functionalities can assume that nothing else is manipulating the data tree when their -functionality is active. - -*/ - diff --git a/Documentation/Doxygen/Modules/ModuleApplicationsFunctionalities.png b/Documentation/Doxygen/Modules/ModuleApplicationsFunctionalities.png deleted file mode 100644 index 43488f8500..0000000000 Binary files a/Documentation/Doxygen/Modules/ModuleApplicationsFunctionalities.png and /dev/null differ diff --git a/Documentation/Doxygen/Modules/ModuleApplicationsWidgets.dox b/Documentation/Doxygen/Modules/ModuleApplicationsWidgets.dox deleted file mode 100644 index c1548da105..0000000000 --- a/Documentation/Doxygen/Modules/ModuleApplicationsWidgets.dox +++ /dev/null @@ -1,7 +0,0 @@ -/** - \defgroup Widgets Widgets - \ingroup Application - - This category includes widget classes (mainly for Qt). - -*/ diff --git a/Documentation/Doxygen/Modules/ModuleDataManagement.dox b/Documentation/Doxygen/Modules/ModuleDataManagement.dox deleted file mode 100644 index e6f919743f..0000000000 --- a/Documentation/Doxygen/Modules/ModuleDataManagement.dox +++ /dev/null @@ -1,27 +0,0 @@ -/** - -\defgroup DataManagement Data Management Classes -\ingroup Core - -\brief This category includes the data classes themselves (images, surfaces, -etc.) as well as management classes to organize the data during run-time in a -tree structure, called the data tree (mitk::DataTree). - -\section DataManagementOverview Overview - -There are two things in MITK: data itself and the organization of data in a -tree. The data tree is used for communication between different parts of an -application: The renderer uses it to find the things to render, functionalities -use it to find "all images" or "all surfaces", and the event handling uses it to -distribute events to interactors. - -For a list of all possible kind of data, look at \ref Data. \ref IO lists -classes that help to read and write data sets. - -For an explanation of the data tree, iterators and tree nodes, refer to -\ref DataTree. - -\ref Geometry groups all classes that describe the spatial/temporal position and -orientation of data sets. - -*/ diff --git a/Documentation/Doxygen/Modules/ModuleDataTree.dox b/Documentation/Doxygen/Modules/ModuleDataTree.dox deleted file mode 100644 index 2db8d6bf83..0000000000 --- a/Documentation/Doxygen/Modules/ModuleDataTree.dox +++ /dev/null @@ -1,58 +0,0 @@ -/** - -\defgroup DataTree Data Tree Classes -\ingroup DataManagement - -\brief This subcategory includes the data tree classes, which organizes the data during run-time in a tree structure. - -\section overviewDataTree Overview - -All data objects, like images or surfaces, are contained in DataNodes. These -DataNodes describe the data itself (mitk::BaseData), how they can be rendered in -2D or 3D (a list of mitk::Mapper), what mitk::Interactor is associated with it, and a list -of arbirary properties (name, visibility, opacity, etc.). Information about the -position of a data object in space/time is stored in a Geometry, which is -attached to the data object itself, not to the node. - -Tree nodes are organized in a data tree for communication between different -parts of an application, e.g. functionalities and the rendering process. -mitk::DataTree is just a typedef to the ITK tree container class. To access and -modify data trees, we use iterators (mitk::DataTreeIteratorBase). - -To clarify the relation between the tree, its nodes and iterators, have a look -at the following diagram. The main point of this diagram is, that you need an -iterator to change the tree. A tree node does not know about the tree! -Once again: a tree node does not know about the tree! - -\image html DataTreeAndIterators.png "The data tree, its nodes and iterators" - -To modify a tree, you can use an iterator's Add(), Set() or Remove() methods -(among others): - -\code - mitk::DataTreeIteratorBase* iterator = GetAnIterator(); //whatever - mitk::DataNode* node = GetMyNode(); - mitk::DataNode* node2 = GetMyNode(); - - if ( iterator.IsNotNull() ) - { - iterator->Add( node ); // add as child to the current position - - iterator->Set( node2 ); // set the node of the current position - - iterator->Remove(); // remove the current position (and all its children) - } - -\endcode - -To access the data behind an iterator, use Get(): - -\code - if ( iterator.IsNotNull() ) - { - mitk::DataNode* datanode = iterator->Get(); - mitk::BaseData* = datanode->GetData(); - } -\endcode - -*/ diff --git a/Documentation/Doxygen/Modules/ModuleDatamanagementIO.dox b/Documentation/Doxygen/Modules/ModuleDatamanagementIO.dox deleted file mode 100644 index c0c32af17a..0000000000 --- a/Documentation/Doxygen/Modules/ModuleDatamanagementIO.dox +++ /dev/null @@ -1,258 +0,0 @@ -/** - \defgroup IO IO Classes - \ingroup DataManagement - - \brief This subcategory includes the IO classes to read or write data objects. - - Available sections: - - \ref DataNodeFactory - - \ref XMLWriterAndXMLReader - - \ref XMLFile - - \ref XMLWriter - - \ref XMLWriterCodeSnippets - - \ref XMLReader - - \ref XMLReaderCodeSnippets - - \section DataNodeFactory DataNodeFactory - - The mitk::DataNodeFactory creates instances of mitk::DataNodes filled with data read from a given file. - This class reads files, creates an appropriate mitk::BaseData and adds the BaseData to a mitk::DataNode. - This filter may produce one or more outputs (i.e. mitk::DataNodes). The number of generated nodes can be retrieved by a call of GetNumberOfOutputs(). - If you want to add a new file type, you have to register the factory of the file reader in the class mitk::BaseDataIO. - - \image html DataNodeFactoryMechanism.png "A short overview of the factory mechanism of the DataNodeFactory." - - The mitk::DataNodeFactory calls the mitk::BaseDataIO. - BaseDataIO registers the defined factories of the file readers. - After registration each registered factory will be asked if it can read the file specified by the filename. - If the asked factory can read the file it instantiates the adequate reader. The reader reads the file and returns as output a pointer of BaseData. - It is possible that a reader has more than one output. The BaseData is stored in a vector of BaseData. - The pointer of this vector is returned to the DataNodeFactory. A node is created for each element of the vector. - - Between BaseDataIO and the ObjectFactoryBase there is still an adapter (mitk::IOAdapter). - The instantiated reader returns a pointer of mitk::BaseProcess. In the class BaseProcess there couldn't be defined the necessary function CanReadFile(). - So we need an adapter class to handle this. - - \section XMLWriterAndXMLReader XMLWriter and XMLReader - - The mitk::XMLWriter and mitk::XMLReader give the possibility to write and to read XML files. - These classes were developed with the aim to store and to load the MITK datatree (mitk::DataTree). - To avoid external dependencies of the MITK these classes are realized without XML parsers like DOM or SAX. - Only dependencies to ITK and VTK are existing. - - \subsection XMLFile XML file - - Mentioned before, the focus of this classes is to store and to load the MITK datatree (mitk::DataTree) with XML. - In the following you can see the body of a typical XML file of a MITK image that was kept as a node in the datatree. - - \image html SceneXML.png "A typical XML file of a MITK image." - - Initial point is the DataTree class. So \ is the root element. - The hierarchy of the datatree is reflected again in the hierarchy of the XML nodes. - At large the XML nodes represent classes. The name of the class is stored with the XML attribute "CLASS_NAME". - Generally data is stored with attributes. - - \subsection XMLWriter XMLWriter - - Technically the XMLWriter class is derived from mitkBaseXMLWriter class. The constructor needs the filename of the XML file at least. - - The following diagram displays the main components: - \image html XMLWriterOverview.png "Classes related to XMLWriter" - - For writing a XML file the following funtions are important. - - \li mitk::XMLIO::WriteXML() - \li mitk::XMLIO::WriteXMLData() - \li mitk::BaseXMLWriter::BeginNode() - \li mitk::BaseXMLWriter::EndNode() - \li mitk::XMLWriter::WriteProperty() - - Easily speaking the mitk::XMLIO class manages the input and the output of the XML file. - New classes that should be written to the XML file have to be derived from the XMLIO class. - New classes should also be declared in the mitk::MapClassIDToClassName class. - Calling the function WriteXML() writes automatically a complete node of the referenced class to the XML file. - The function WriteXML() calls sequential the functions BeginNode(), WriteProperty(), WriteXMLData() and EndNode(). - A new XML node is initialized with the function BeginNode("nameOfNewNode"). - The function WriteXMLData() writes the data of the referenced class. - This function has to be overwritten in new classes. The data is stored with XML attributes. - These attributes can be written with the function WriteProperty("key", value). - The parameter "key" specifies the name of the attribute and the parameter "value" the data. - Different datatypes are supported. For details you can look in the mitk::BaseXMLWriter and mitk::XMLWriter class. - The function EndNode() writes the end tag of the started XML node to the XML file. - - It is also possible to write custom data apart from classes to the XML file (e.g. data of complex datatypes). - In this case you can call BeginNode(),(WriteProperty()), (WriteXMLData()) and EndNode() manually to write XML nodes and attributes. - But watch out for the closing tag of each XML node. Each start tag needs an end tag. - - It is prefered to define common key words (e.g. name of attriubtes) in the XMLNodes class. - Class specific key words should be defined in the class itself (e.g. XML_NODE_NAME). - - The nodes of the datatree contain different data like images, surfaces or vessels. - These base data is stored in the respectively fitting dataformat. - Such files are called source files and are referenced in the XML file. - - To manage these references there are different functions implemented in the mitk::XMLWriter class. - - \li mitk::XMLWriter::SetSaveSourceFiles() - \li mitk::XMLWriter::SetSourceFileName() - \li mitk::XMLWriter::SetSubFolder() - \li mitk::XMLWriter::SetOriginPath() - \li mitk::XMLWriter::GetNewFileName() - \li mitk::XMLWriter::GetRelativePath() - \li mitk::XMLWriter::GetAbsolutePath() - \li mitk::XMLWriter::GetSubFolder() - - A special feature of the XMLWriter is to store the source files relative to the XML file. - If no filename is set a new filename is generated. - - \subsection XMLWriterCodeSnippets XMLWriter code snippets - - Initialize and start the XMLWriter - - \code - #include - #include - - //... - - const *char filename = "Scene.xml"; - mitk::XMLWriter xmlWriter(filename); - mitk::myClass::Pointer myClass; - - xmlWriter.BeginNode("root"); - myClass->WriteXML(xmlWriter); - xmlWriter.EndNode(); - \endcode - - - Overwrite the function WriteXMLData of a new class - - myClass.h - - \code - #include - - class myClass: public XMLIO - - public - - //... - - static const std::string XML_NODE_NAME; - - virtual bool WriteXMLData(XMLWriter &xmlWriter); - \endcode - - myClass.cpp - - \code - #include - - //... - - static const std::string XML_NODE_NAME = "myClass"; - // defines the XML nodename - - bool mitk::myClass::WriteXMLData(XMLWriter &xmlWriter); - { - xmlWriter.WriteProperty("MY_NUMBER", this->GetNumber()); - xmlWriter.BeginNode("uselessNode"); - xmlWriter.WriteProperty("USELESS_INFO", "useless info"); - xmlWriter.EndNode(); - return true; - } - \endcode - - \subsection XMLReader XMLReader - - The mitk::XMLReader reads a stream and parses XML element tags and corresponding attributes. - Technically the XMLReader class is derived from vtkXMLParser class. - The constructor needs the filename ((path)+filename) of the XML file and a datatree iterator (mitk::DataTreeIteratorBase) of the datatree. - - The following diagram displays the main components: - \image html XMLReaderOverview.png "Classes related to XMLReader" - - For reading a XML file the following funtions are important. - - \li mitk::XMLIO::ReadXMLData() - \li mitk::XMLReader::Goto() - \li mitk::XMLReader::GotoNext() - \li mitk::XMLReader::GotoParent() - \li mitk::XMLReader::CreateObject() - \li mitk::XMLReader::GetAttribute() - - As mentioned in the section before the mitk::XMLIO class manages the input and the output of the XML file. - New classes that should be read data from the XML file have to be derived from the mitkXMLIO class. - In new classes the function ReadXMLData() have to be overwritten. - Easily speaking this function reads the data from the XML file, provides for instantiation of new objects and sets the data. - With the Goto functions it is possible to navigate the parser through the XML document. - To get the root XML node call the function Goto("root"). Be careful with the hierarchy of the XML nodes and the actual position of the parser. - The function Goto() is looking always for child nodes and function GotoNext() is looking for further XML nodes in the same hierarchy. - For creation of new objects of the read class (the class is specified in the XML attribute "CLASS_NAME") the function CreateObject() has to be called. - The creation of the asked object is only successful when the new class has already be defined in the mitk::ObjectFactory class. - If the asked XML node is reached, the data stored in XML attributes, can be read by the function GetAttribute("key", value). - The parameter "key" specifies the name of the attribute and the parameter "value" keeps the data. - Different datatypes are supported. For details you can look in the mitk::XMLReader class. - When the parser should climb up in the XML tree hierarchy the function GotoParent() does a good job. - - The source file management - - If the reference to the source file is stored relative to the XML file you need the path of the XML file to calculate the absolute path. - This operation is done automatically and you get the absolute path when calling the attribute "FILENAME". - It is also possible to get the path of the source file by calling the function GetSourceFilePath(). - - \subsection XMLReaderCodeSnippets XMLReader code snippets - - Initialize and start the XMLReader - - \code - #include - - //... - - std::string filename = "Scene.xml"; - mitk::DataTreePreOrderIterator it(m_Tree); - mitk::XMLReader::Load(&it, filename); - \endcode - - - Overwrite the function ReadXMLData of a new class - - myClass.h - - \code - #include - - class myClass: public XMLIO - - public - - //... - - virtual bool ReadXMLData(XMLReader &xmlReader); - \endcode - - myClass.cpp - - \code - #include - #include - - //... - - bool mitk::myClass::ReadXMLData(XMLReader &xmlReader); - { - int value; - - if(xmlReader.Goto("myClass")){ - mitk::fictiveClass::Pointer myFictiveObject = dynamic_cast(xmlReader.CreateObject().GetPointer()); - if (xmlReader.GetAttribute("myNumber", value)) - this->SetNumber(value); - myFictiveObject->ReadXMLData(xmlReader); // further elements can be read - xmlReader.GotoParent(); // now we are back on parent tag - } - return true; - } - \endcode - -*/ diff --git a/Documentation/Doxygen/Modules/PartsOfAFunctionaliy.jpg b/Documentation/Doxygen/Modules/PartsOfAFunctionaliy.jpg deleted file mode 100644 index 876772b43f..0000000000 Binary files a/Documentation/Doxygen/Modules/PartsOfAFunctionaliy.jpg and /dev/null differ diff --git a/Documentation/Doxygen/Modules/PartsOfAFunctionaliy.xcf b/Documentation/Doxygen/Modules/PartsOfAFunctionaliy.xcf deleted file mode 100644 index 1b2b6b026f..0000000000 Binary files a/Documentation/Doxygen/Modules/PartsOfAFunctionaliy.xcf and /dev/null differ diff --git a/Documentation/Doxygen/Modules/SceneXML.png b/Documentation/Doxygen/Modules/SceneXML.png deleted file mode 100644 index 42136c722d..0000000000 Binary files a/Documentation/Doxygen/Modules/SceneXML.png and /dev/null differ diff --git a/Documentation/Doxygen/Modules/XMLReaderOverview.png b/Documentation/Doxygen/Modules/XMLReaderOverview.png deleted file mode 100644 index 8d5789d4c1..0000000000 Binary files a/Documentation/Doxygen/Modules/XMLReaderOverview.png and /dev/null differ diff --git a/Documentation/Doxygen/Modules/XMLReaderOverview.vsd b/Documentation/Doxygen/Modules/XMLReaderOverview.vsd deleted file mode 100644 index 474dedbcc0..0000000000 Binary files a/Documentation/Doxygen/Modules/XMLReaderOverview.vsd and /dev/null differ diff --git a/Documentation/Doxygen/Modules/XMLWriterOverview.png b/Documentation/Doxygen/Modules/XMLWriterOverview.png deleted file mode 100644 index a8b62f592e..0000000000 Binary files a/Documentation/Doxygen/Modules/XMLWriterOverview.png and /dev/null differ diff --git a/Documentation/Doxygen/Modules/XMLWriterOverview.vsd b/Documentation/Doxygen/Modules/XMLWriterOverview.vsd deleted file mode 100644 index 54a382ef99..0000000000 Binary files a/Documentation/Doxygen/Modules/XMLWriterOverview.vsd and /dev/null differ