diff --git a/Documentation/Doxygen/Concepts.dox b/Core/Documentation/Doxygen/Concepts/Concepts.dox similarity index 93% rename from Documentation/Doxygen/Concepts.dox rename to Core/Documentation/Doxygen/Concepts/Concepts.dox index ef8ccad6c4..e2477919d5 100644 --- a/Documentation/Doxygen/Concepts.dox +++ b/Core/Documentation/Doxygen/Concepts/Concepts.dox @@ -1,15 +1,15 @@ /** \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 \li \subpage GeometryOverviewPage \li \subpage InteractionPage \li \subpage OverviewPage \li \subpage MicroServices_Overview \li \subpage PropertiesPage -\li \subpage Rendering +\li \subpage QVTKRendering \li \subpage RenderingTests */ diff --git a/Documentation/Doxygen/GeometryOverview.dox b/Core/Documentation/Doxygen/Concepts/GeometryOverview.dox similarity index 91% rename from Documentation/Doxygen/GeometryOverview.dox rename to Core/Documentation/Doxygen/Concepts/GeometryOverview.dox index 5e762569d6..1a6d25bf68 100644 --- a/Documentation/Doxygen/GeometryOverview.dox +++ b/Core/Documentation/Doxygen/Concepts/GeometryOverview.dox @@ -1,133 +1,133 @@ namespace mitk{ /** \page GeometryOverviewPage Geometry Overview Available sections: --# \ref Section_1 "Introduction to Geometries" --# \ref Section_2 "The Geometry Concept" - -# \ref Subsection_21 "IMPORTANT: Putting it together for an Image" --# \ref Section_3 "Connection between MITK, ITK and VTK Geometries"\n\n +-# \ref GeometryOverviewPage_Introduction "Introduction to Geometries" +-# \ref GeometryOverviewPage_Concept "The Geometry Concept" + -# \ref GeometryOverviewPage_Putting_Together "IMPORTANT: Putting it together for an Image" +-# \ref GeometryOverviewPage_Connection "Connection between MITK, ITK and VTK Geometries"\n\n -\section Section_1 Introduction to Geometries +\section GeometryOverviewPage_Introduction Introduction to Geometries Geometries are used to describe the geometrical properties of data objects in space and time.\n To use the geometry classes in the right way you have to understand the three different coordinate types present in MITK:\n\n \image html CoordinateTypes.png
The different coordinate types\n\n
\n -# World coordinates: - World coordinates are describing the actual spacial position of all MITK objects regarding a global coordinate system, normally specified by the imaging modality - The geometry defines the offset, orientation, and scale of the considered data objects in reference to the world coordinate systems. - World coordinates are always measured in mm - If you are dealing with an image geometry, the origin of an image is pointing to the CENTER of the bottom-left-back voxel.\n - If you are NOT dealing with an image geometry (no defined discrete Voxels), the origin is pointing to the bottom-left-back CORNER - Index coordinates can be converted to world coordinates by calling Geometry3D::IndexToWorld()\n\n \image html worldcoordinateSystem.png
Corner-based coordinates\n\n
\image html WorldcoordinateSystemCenterBased.png
Center-based image-coordinates\n\n
\n -# Continuous index coordinates: - Dividing world coordinates through the pixel spacing and simultanously taking the offset into account leads to continuous index coordinates inside your dataobject.\n So continuous coordinates can be float values! - They can be obtained by calling Geometry3D::WorldToIndex(), where &pt_mm is a point in worldcoordinates.\n -# Index coordinate system: - Index coordinates are discrete values that address voxels of a data object explicitly. - Basically they are continuous index coordinates which are rounded from half integer up. - E.g. (0,0) specifies the very first pixel of a 2D image, (0,1) the pixel of the next column in the same row - If you have world coordinates, they can be converted to discrete index coordinates by calling Geometry3D::WorldToIndex()\n\n -\section Section_2 The Geometry Concept +\section GeometryOverviewPage_Concept The Geometry Concept As the superclass of all MITK geometries Geometry3D holds: - a spacial bounding box which is axes-parallel in index coordinates (often discrete indices of pixels), to be accessed by Geometry3D::GetBoundingBox() - a time related bounding box which holds the temporal validity of the considered data object in milliseconds (start and end time), to be accessed by Geometry3D::GetTimeBounds().\n The default for 3D geometries is minus infinity to plus infinity, meaning the object is always displayed independent of displayed time in MITK. - position information in form of a Euclidean transform in respect to world coordinates (i.e. a linear transformation matrix and offset) to convert (discrete or continuous) index coordinates to world coordinates and vice versa,\n to be accessed by Geometry3D::GetIndexToWorldTransform()\n - See also: \ref Section_1 "Introduction to Geometries" + See also: \ref GeometryOverviewPage_Introduction "Introduction to Geometries" - Many other properties (e.g. origin, extent, ...) which can be found in the \ref Geometry3D "class documentation" - VERY IMPORTANT:\n A flag called isImageGeometry, which indicates whether the coordinates are center-based or not!\n - See also: \ref Section_1 "Introduction to Geometries" and \ref Subsection_21 "IMPORTANT: Putting it together for an Image"\n\n + See also: \ref GeometryOverviewPage_Introduction "Introduction to Geometries" and \ref GeometryOverviewPage_Putting_Together "IMPORTANT: Putting it together for an Image"\n\n Every data object which is (sub-)class of BaseData has a Geometry3D, to be more specific, a TimeSlicedGeometry, to be accessed by BaseData::GetTimeSlicedGeometry().\n This is because all data objects are objects in space and time. The data values are often stored in index coordinates, e.g., integer pixel/voxel or time indices.\n The information required to convert these index coordinates into a world coordinate system, with spatiotemporal coordinates in millimeters and milliseconds, is stored in Geometry3D\n class and its sub-classes. TimeSlicedGeometry describes a spatiotemporal geometry consisting of spatial geometries existing at different times, and allocates each geometry at a valid time step a discrete number. It contains a list of Geometry3D instances to be accessed by\n TimeSlicedGeometry::GetGeometry3D(t), with t between 0 and TimeSlicedGeometry::GetTimeSteps().\n To convert between world time in milliseconds and the integer timestep number use TimeSlicedGeometry::MSToTimeStep(), for conversion in the opposite direction\n TimeSlicedGeometry::TimeStepToMS(). Often all Geometry3D instances contained in a TimeSlicedGeometry have the same temporal extent.\n The initialization for this case can be done using TimeSlicedGeometry::InitializeEvenlyTimed(Geometry3D *geometry3D, unsigned int timeSteps). The Geometry3D parameter must have a limited life span set by Geometry3D::SetTimeBounds(). It is used as the first Geometry3D contained in the TimeSlicedGeometry (thus returned by TimeSlicedGeometry:: GetGeometry3D(0)). The next one will start to have a valid time range immediately at the end of validness of the processor. The bounding boxes and spacial transformations are copied.\n The instance of Geometry3D provided to TimeSlicedGeometry::InitializeEvenlyTimed is referenced, not copied! TimeSlicedGeometry is a Geometry3D itself. Its bounding box and transformation is usually the same as the bounding box and transformations of the contained Geometry3D instances.\n Its life span (to be accessed by TimeSlicedGeometry::GetTimeBounds()) is the span from the initial valid time of the first contained Geometry3D to the termination of the last valid time of contained Geometry3Ds. TimeSlicedGeometry can also contain Geometry3D instances that do not have the same Euclidean geometry. In that case, TimeSlicedGeometry::GetEvenlyTimed() has to be false. SlicedGeometry3D is a sub-class of Geometry3D, which describes data objects consisting of slices, e.g., objects of type Image (or SlicedData, which is the super-class of Image). Therefore, Image::GetTimeSlicedGeometry() will contain a list of SlicedGeometry3D instances. There is a special method SlicedData::GetSlicedGeometry(t) which directly returns\n a SlicedGeometry3D to avoid the need of casting. Comparable to TimeSlicedGeometry the class SlicedGeometry3D contains a list of Geometry2D objects describing the slices in the image. Instead of time steps we have spatial steps here from 0 to GetSlices(). SlicedGeometry3D::InitializeEvenlySpaced (Geometry2D *geometry2D, unsigned int slices) initializes a stack of slices with the same thickness, one starting at the position where the previous one ends. Geometry2D provides methods for working with 2D manifolds (i.e., simply spoken, an object that can be described using a 2D coordinate-system) in 3D space.\n For example it allows mapping of a 3D point on the 2D manifold using Geometry2D::Map(). A subclass of Geometry2D called PlaneGeometry, explicitly describes a 2D rectangular plane.\n Another important subclass of Geometry2D is the DisplayGeometry which describes the geometry of the display (the monitor screen). Basically it represents a rectangular view on a 2D world geometry\n The DisplayGeometry converts between screen and world coordinates, processes input events (e.g. mouse click) and provides methods for zooming and panning.\n \image html DisplayGeometry.png
Display Geometry\n\n
Finally there is the AbstractTransformGeometry which describes a 2D manifold in 3D space, defined by a vtkAbstractTransform. It is a abstract superclass for arbitrary user defined geometries\n An example is the ThinPlateSplineCurvedGeometry.\n -\subsection Subsection_21 IMPORTANT: Putting it together for an Image +\subsection GeometryOverviewPage_Putting_Together IMPORTANT: Putting it together for an Image Please read this section accurately if you are working with Images! The definition of the position of the corners of an image is different than the one of other data objects: As mentioned in the previous section, world coordinates of data objects (e.g. surfaces ) usually specify the bottom left back corner of an object. In contrast to that a geometry of an Image is center-based, which means that the world coordinates of a voxel belonging to an image points to the center of that voxel. E.g: \image html PixelCenterBased.png
Center-based voxel\n\n
If the origin of e.g. a surface lies at (15,10,0) in world coordinates, the origin`s world coordinates for an image are internally calculated like the following:
(15-0.5*X-Spacing\n 10-0.5*Y-Spacing\n 0-0.5*Z-Spacing)\n
If the image`s spacing is (x,y,z)=(1,1,3) then the corner coordinates are (14.5,9.5,-1.5). If your geometry describes an image, the member variable isImageGeometry must be changed to true. This variable indicates also if your geometry is center-based or not.\n The change can be done in two ways:\n -# You are sure that your origin is already center-based. Whether because you adjusted it manually or you copied it from another image.\n In that case, you can call the function setImageGeometry(true) or imageGeometryOn() to set the bool variable to true. -# You created a new geometry, did not manually adjust the origin to be center-based and have the bool value isImageGeometry set to false (default).\n In that case, call the function ChangeImageGeometryConsideringOriginOffset(true). It will adjust your origin automatically and set the bool flag to true.\n If you experience displaced contours, figures or other stuff, it is an indicator that you have not considered the origin offset mentioned above.\n\n An image has a TimeSlicedGeometry, which contains one or more SlicedGeometry3D instances (one for each time step), all of which contain one or more instances of (sub-classes of) Geometry2D (usually PlaneGeometry).\n As a reminder: Geometry instances referring to images need a slightly different definition of corners, see Geometry3D::SetImageGeometry. This is usualy automatically called by Image.\n\n -\section Section_3 Connection between MITK, ITK and VTK Geometries +\section GeometryOverviewPage_Connection Connection between MITK, ITK and VTK Geometries \image html ITK_VTK_MITK_Geometries.png \n\n - VTK transformation for rendering - ITK transformation for calculations - Both automatically updated when one is changed\n Attention:Not automatically updated when changed hardcoded. Example: geometry->GetVtkMatrix()->Rotate(....) */ } \ No newline at end of file diff --git a/Documentation/Doxygen/Interaction.dox b/Core/Documentation/Doxygen/Concepts/Interaction.dox similarity index 92% rename from Documentation/Doxygen/Interaction.dox rename to Core/Documentation/Doxygen/Concepts/Interaction.dox index f02cc0eb73..99cf22ec85 100644 --- a/Documentation/Doxygen/Interaction.dox +++ b/Core/Documentation/Doxygen/Concepts/Interaction.dox @@ -1,122 +1,122 @@ /** \page InteractionPage Interaction and Undo/Redo Concepts -\section InteractionIntroduction Interaction in MITK +\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 Statemachines Statemachines to implement Interaction +\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 Statemachine State Machine +\subsection InteractionPage_Statemachine State Machine So a separation of the definition of a sequence in interaction and its implementation is a useful step in the development of an interactive application. To be able to do that, we implemented the concept of state machines with several classes: States, Transitions and Actions define the interaction pattern. The state machine itself adds the handling of events, that are sent to it. \image html statemachine.jpg -\subsubsection ExampleA Example A: +\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. 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 GuardState Guard States +\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. \image html statemachine_guard.jpg -\subsubsection ExampleB Example B: +\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. -\subsection XMLDefinitionStatemachine Definition of a State machine +\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). -The structure is the following (from \ref ExampleA) : +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 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 InteractionEvents for further informations. +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 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. -\subsubsection ReusePattern Reuse of Interaction Patterns +\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 StartupInteraction Loading Statemachines at Runtime +\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 InteractionEvents Events +\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. See mitk::Event, mitk::GlobalInteraction -\subsection GlobalInteraction 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. 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. 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 Interactors Interactors +\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 ExecOperations Executing Operations +\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 UndoController UndoController +\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 references References +\subsection InteractionPage_references References [Bin99] Robert V. Binder. Testing Object-Oriented Systems: Models, Patterns, and Tools. Addison-Wesley, 1999 */ diff --git a/Documentation/Doxygen/Overview.dox b/Core/Documentation/Doxygen/Concepts/Overview.dox similarity index 98% rename from Documentation/Doxygen/Overview.dox rename to Core/Documentation/Doxygen/Concepts/Overview.dox index 8da783ed43..1891b083fb 100644 --- a/Documentation/Doxygen/Overview.dox +++ b/Core/Documentation/Doxygen/Concepts/Overview.dox @@ -1,52 +1,52 @@ /** \page OverviewPage Overview on the Medical Imaging Interaction Toolkit (MITK) Four issues are important for advanced interactive medical imaging software: Today, there are two major open-source toolkits for visualization and image processing: 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. 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. -\section DesignOverview Design Overview +\section OverviewPage_DesignOverview Design Overview 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. ... */ diff --git a/Documentation/Doxygen/Properties.dox b/Core/Documentation/Doxygen/Concepts/Properties.dox similarity index 100% rename from Documentation/Doxygen/Properties.dox rename to Core/Documentation/Doxygen/Concepts/Properties.dox diff --git a/Documentation/Doxygen/Modules/ModuleQVTKRendering.dox b/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox similarity index 94% rename from Documentation/Doxygen/Modules/ModuleQVTKRendering.dox rename to Core/Documentation/Doxygen/Concepts/QVTKRendering.dox index 196408af99..1f1f070925 100644 --- a/Documentation/Doxygen/Modules/ModuleQVTKRendering.dox +++ b/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox @@ -1,107 +1,107 @@ /** -\page Rendering Rendering in MITK by means of the QT-VTK widget +\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. -\section vktRendering 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. More information about the VTK rendering pipeline can be found at http://www.vtk.org and in the several VTK books. -\section mitkRendering MITK Rendering Pipeline +\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. 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 sequence diagramm, 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 programmerGuide User Guide: Changes in programming of rendering related stuff +\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"); -\subsection distinctRenderWindow Setting up a distinct Rendering-Pipeline +\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. */ diff --git a/Documentation/Doxygen/RenderingTests.dox b/Core/Documentation/Doxygen/Concepts/RenderingTests.dox similarity index 93% rename from Documentation/Doxygen/RenderingTests.dox rename to Core/Documentation/Doxygen/Concepts/RenderingTests.dox index 89695ba0ea..2c60491f2a 100644 --- a/Documentation/Doxygen/RenderingTests.dox +++ b/Core/Documentation/Doxygen/Concepts/RenderingTests.dox @@ -1,97 +1,97 @@ namespace mitk{ /** \page RenderingTests Automatic Rendering Tests Available sections: --# \ref WhatIsARenderingTest "What is an automatic rendering test?" --# \ref HowToCreateATest "How to create a rendering test" +-# \ref RenderingTests_WhatIsARenderingTest "What is an automatic rendering test?" +-# \ref RenderingTests_HowToCreateATest "How to create a rendering test" -\section WhatIsARenderingTest What is an automatic 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 HowToCreateATest How to create your own automatic rendering test +\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 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 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 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. 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 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. 2. 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/Documentation/Doxygen/CoordinateTypes.png b/Core/Documentation/Doxygen/Concepts/images/geometryoverview/CoordinateTypes.png similarity index 100% rename from Documentation/Doxygen/CoordinateTypes.png rename to Core/Documentation/Doxygen/Concepts/images/geometryoverview/CoordinateTypes.png diff --git a/Documentation/Doxygen/DisplayGeometry.png b/Core/Documentation/Doxygen/Concepts/images/geometryoverview/DisplayGeometry.png similarity index 100% rename from Documentation/Doxygen/DisplayGeometry.png rename to Core/Documentation/Doxygen/Concepts/images/geometryoverview/DisplayGeometry.png diff --git a/Documentation/Doxygen/ITK_VTK_MITK_Geometries.png b/Core/Documentation/Doxygen/Concepts/images/geometryoverview/ITK_VTK_MITK_Geometries.png similarity index 100% rename from Documentation/Doxygen/ITK_VTK_MITK_Geometries.png rename to Core/Documentation/Doxygen/Concepts/images/geometryoverview/ITK_VTK_MITK_Geometries.png diff --git a/Documentation/Doxygen/PixelCenterBased.png b/Core/Documentation/Doxygen/Concepts/images/geometryoverview/PixelCenterBased.png similarity index 100% rename from Documentation/Doxygen/PixelCenterBased.png rename to Core/Documentation/Doxygen/Concepts/images/geometryoverview/PixelCenterBased.png diff --git a/Documentation/Doxygen/WorldcoordinateSystemCenterBased.png b/Core/Documentation/Doxygen/Concepts/images/geometryoverview/WorldcoordinateSystemCenterBased.png similarity index 100% rename from Documentation/Doxygen/WorldcoordinateSystemCenterBased.png rename to Core/Documentation/Doxygen/Concepts/images/geometryoverview/WorldcoordinateSystemCenterBased.png diff --git a/Documentation/Doxygen/worldcoordinateSystem.png b/Core/Documentation/Doxygen/Concepts/images/geometryoverview/worldcoordinateSystem.png similarity index 100% rename from Documentation/Doxygen/worldcoordinateSystem.png rename to Core/Documentation/Doxygen/Concepts/images/geometryoverview/worldcoordinateSystem.png diff --git a/Documentation/Doxygen/statemachine.eps b/Core/Documentation/Doxygen/Concepts/images/interaction/statemachine.eps similarity index 100% rename from Documentation/Doxygen/statemachine.eps rename to Core/Documentation/Doxygen/Concepts/images/interaction/statemachine.eps diff --git a/Documentation/Doxygen/statemachine.jpg b/Core/Documentation/Doxygen/Concepts/images/interaction/statemachine.jpg similarity index 100% rename from Documentation/Doxygen/statemachine.jpg rename to Core/Documentation/Doxygen/Concepts/images/interaction/statemachine.jpg diff --git a/Documentation/Doxygen/statemachine_guard.eps b/Core/Documentation/Doxygen/Concepts/images/interaction/statemachine_guard.eps similarity index 100% rename from Documentation/Doxygen/statemachine_guard.eps rename to Core/Documentation/Doxygen/Concepts/images/interaction/statemachine_guard.eps diff --git a/Documentation/Doxygen/statemachine_guard.jpg b/Core/Documentation/Doxygen/Concepts/images/interaction/statemachine_guard.jpg similarity index 100% rename from Documentation/Doxygen/statemachine_guard.jpg rename to Core/Documentation/Doxygen/Concepts/images/interaction/statemachine_guard.jpg diff --git a/Documentation/Doxygen/Modules/RenderingOverviewVTK.png b/Core/Documentation/Doxygen/Concepts/images/rendering/RenderingOverviewVTK.png similarity index 100% rename from Documentation/Doxygen/Modules/RenderingOverviewVTK.png rename to Core/Documentation/Doxygen/Concepts/images/rendering/RenderingOverviewVTK.png diff --git a/Documentation/Doxygen/Modules/qVtkRenderingClassOverview.png b/Core/Documentation/Doxygen/Concepts/images/rendering/qVtkRenderingClassOverview.png similarity index 100% rename from Documentation/Doxygen/Modules/qVtkRenderingClassOverview.png rename to Core/Documentation/Doxygen/Concepts/images/rendering/qVtkRenderingClassOverview.png diff --git a/Documentation/Doxygen/Modules/qVtkRenderingSequence.png b/Core/Documentation/Doxygen/Concepts/images/rendering/qVtkRenderingSequence.png similarity index 100% rename from Documentation/Doxygen/Modules/qVtkRenderingSequence.png rename to Core/Documentation/Doxygen/Concepts/images/rendering/qVtkRenderingSequence.png diff --git a/Core/Documentation/Doxygen/Concepts/images/rendering/rendering_vsd_files.tar b/Core/Documentation/Doxygen/Concepts/images/rendering/rendering_vsd_files.tar new file mode 100644 index 0000000000..f7b774c559 Binary files /dev/null and b/Core/Documentation/Doxygen/Concepts/images/rendering/rendering_vsd_files.tar differ diff --git a/Documentation/Doxygen/extension-points/index.dox b/Core/Documentation/Doxygen/extension-points/mitkExtPointsIndex.dox similarity index 100% rename from Documentation/Doxygen/extension-points/index.dox rename to Core/Documentation/Doxygen/extension-points/mitkExtPointsIndex.dox diff --git a/Documentation/Doxygen/ImageMapperdisplayGeometry.png b/Core/Documentation/images/rendering/ImageMapperdisplayGeometry.png similarity index 100% rename from Documentation/Doxygen/ImageMapperdisplayGeometry.png rename to Core/Documentation/images/rendering/ImageMapperdisplayGeometry.png diff --git a/Documentation/Doxygen/cameraPositioning.png b/Core/Documentation/images/rendering/cameraPositioning.png similarity index 100% rename from Documentation/Doxygen/cameraPositioning.png rename to Core/Documentation/images/rendering/cameraPositioning.png diff --git a/Documentation/Doxygen/cameraPositioning3D.png b/Core/Documentation/images/rendering/cameraPositioning3D.png similarity index 100% rename from Documentation/Doxygen/cameraPositioning3D.png rename to Core/Documentation/images/rendering/cameraPositioning3D.png diff --git a/Documentation/Doxygen/imageVtkMapper2Darchitecture.png b/Core/Documentation/images/rendering/imageVtkMapper2Darchitecture.png similarity index 100% rename from Documentation/Doxygen/imageVtkMapper2Darchitecture.png rename to Core/Documentation/images/rendering/imageVtkMapper2Darchitecture.png diff --git a/Documentation/Doxygen/mitkGeometry2DDataVtkMapper3D.png b/Core/Documentation/images/rendering/mitkGeometry2DDataVtkMapper3D.png similarity index 100% rename from Documentation/Doxygen/mitkGeometry2DDataVtkMapper3D.png rename to Core/Documentation/images/rendering/mitkGeometry2DDataVtkMapper3D.png diff --git a/Documentation/Doxygen/mitkGeometry2DDataVtkMapper3D.svg b/Core/Documentation/images/rendering/mitkGeometry2DDataVtkMapper3D.svg similarity index 100% rename from Documentation/Doxygen/mitkGeometry2DDataVtkMapper3D.svg rename to Core/Documentation/images/rendering/mitkGeometry2DDataVtkMapper3D.svg diff --git a/Documentation/Doxygen/scaling.png b/Core/Documentation/images/rendering/scaling.png similarity index 100% rename from Documentation/Doxygen/scaling.png rename to Core/Documentation/images/rendering/scaling.png diff --git a/Documentation/Doxygen/texturedPlane.png b/Core/Documentation/images/rendering/texturedPlane.png similarity index 100% rename from Documentation/Doxygen/texturedPlane.png rename to Core/Documentation/images/rendering/texturedPlane.png diff --git a/Documentation/Doxygen/BuildInstructions.dox b/Documentation/Doxygen/DeveloperManual/BuildInstructions.dox similarity index 93% rename from Documentation/Doxygen/BuildInstructions.dox rename to Documentation/Doxygen/DeveloperManual/BuildInstructions.dox index c08c4275f0..1c503a8c61 100644 --- a/Documentation/Doxygen/BuildInstructions.dox +++ b/Documentation/Doxygen/DeveloperManual/BuildInstructions.dox @@ -1,201 +1,201 @@ /** \page BuildInstructionsPage Build Instructions -\section BIZero Introduction +\section BuildInstructions_Introduction Introduction The MITK build system (which is based on CMake) supports a "superbuild" process, meaning that it will download, configure, and build all required third-party libraries (except Qt) automatically. These instructions will show you how to use the MITK superbuild. \note This page explains explicitly how to build MITK itself. If you want to create your own project based on MITK, the process described below is completely automated. Please see Setup a MITK-based project For more advanced users, the last sections explain how to inject custom build libraries into the superbuild process. -\section BIOne Prerequisites +\section BuildInstructions_Prerequisites Prerequisites You need: -# Git from http://git-scm.com (there are also numerous third-party graphical clients available). We recomment using Git, but see below for a way how to get the current source code without using it. -# CMake (version 2.8.4 or higher) -# Qt 4.x if you plan to develop Qt-based applications (version 4.6 or above is recommended, we cannot guarantee compatibility with lower versions) -\section BIQt A note about Qt +\section BuildInstructions_Qt A note about Qt Nokia provides several binary packages for Qt. You must make sure that the package you download matches your toolchain. On Linux, getting Qt by installing the packages provided by your Linux package manager is the preferred way. On Windows, the Nokia provided binaries are compiled for 32bit architectures. You cannot build your own project for a 64bit machine and use the 32bit Qt libraries. You have two options for a 64bit Qt-based application: -# Download an inofficial 64bit installer, for example here. Note that we cannot offer support for problems with MITK due to the usage of this kind of installers. -# Compile Qt yourself. This is shortly described below. To compile Qt on Windows using Visual Studio, follow the steps below: -# Download the Qt sources and unpack them, e.g. to C:/qt-everywhere-opensource-src-4.7.4 -# Open a Visual Studio command prompt. Make sure to use the appropriate command prompt for either a 32 bit or 64 bit build. Note that Visual Studio Express does not come with 64bit compilers out of the box (the Professional version does). -# Configure Qt by executing the configure.exe command in your Qt source directory. The following configure options will build a Qt compatible with MITK: \verbatim configure.exe -prefix C:\Qt\4.7.4_vc9_x64 -debug-and-release -qt-sql-sqlite -no-multimedia -no-audio-backend -no-phonon -no-phonon-backend -no-declarative -mp -nomake examples -nomake demos -nomake docs \endverbatim -# Build and install the Qt libraries \verbatim nmake nmake install \endverbatim After "nmake install" completed successfully, you may delete your Qt source directory. -\section BITwo Get a source tree +\section BuildInstructions_Get_Source Get a source tree Since MITK is under active development we recommend to use git to get the most recent version. To make sure you get a stable tree, check the MITK dashboard before checking out. If the build tree is not clean, you can specify an older revision for the checkout or get a stable tar ball from www.mitk.org. If you don't want to use Git, you may also download the current source code (or any other older version) as a tar.gz package by clicking on the snapshot link. You can then skip the clone step below. To clone MITK's current git repository do: \code git clone http://git.mitk.org/MITK.git \endcode -\section BIThree Build MITK with CMake +\section BuildInstructions_Build_With_CMake Build MITK with CMake Create a new directory for the superbuild binary tree, change to it and call CMake: In the shell (assuming you current directory is the same as the one where you issued the git clone command): \code mkdir MITK-superbuild cd MITK-superbuild ccmake ../MITK \endcode If you use Windows, then you just start the CMake GUI and enter the location of the source and of the binary tree, choose a suitable generator and configure the project. CMake will present you a couple of options, these are the most important ones: - MITK_USE_BLUEBERRY Build the BlueBerry application framework - MITK_USE_Boost Build MITK code which depends on Boost (this will download Boost 1.45.0) - MITK_USE_Boost_LIBRARIES If you need binary Boost libraries, specify them here. - MITK_USE_OpenCV Build MITK code which depends on OpenCV (this will download and build OpenCV 2.3) - MITK_USE_Python Enables Python wrapping in MITK. This will also configure ITK, VTK, and OpenCV (if enabled) to build Python wrappers. - MITK_USE_QT Build MITK code which depends on Qt - QT_QMAKE_EXECUTABLE The path to the qmake executable of your Qt installation If you are satisfied with the configuration of your MITK superbuild, generate the project files with CMake by pressing "Generate". Linux users usually just enter "make" (optionally supplying the number threads to be used for a parallel build): \code make -j4 \endcode Windows users using Visual Studio can open the generated MITK-superbuild.sln solution file in the MITK-superbuild directory and start the build by building the BUILD_ALL project. -\section BIFour Customize your MITK superbuild +\section BuildInstructions_Customize Customize your MITK superbuild The MITK superbuild configured MITK with all needed external libraries. The build directories of these libraries, and of MITK itself are located inside the MITK-superbuild directory. For example, the directory layout may look like: \code MITK-superbuild |- ITK-build |- VTK-build |- MITK-build \endcode To change the configuration of the MITK build, choose the MITK-build directory as the binary directory in the CMake GUI. After generating the project files, build the MITK project by either issuing "make" in the MITK-build directory (Linux), or by opening MITK-build/MITK.sln and building the project with Visual Studio. You may also change the configuration of any project configured via the superbuild process. Make sure to also build the changed project and also the projects which depend on it. -\section BIFive Running Applications +\section BuildInstructions_Running Running Applications On Linux, just execute the application you want to run. MITK executables are located in MITK-superbuild/MITK-build/bin On Windows, the PATH environment variable must contain the directories containging third-party libraries. The MITK build system generated Windows Batch files in the MITK-build directory which set up a correct environment and opens the appropriate Visual Studio solution file. Use (and maybe modify/enhance) these Batch files to be able to start and debug MITK applications from inside Visual Studio. -\section BISix Documentation +\section BuildInstructions_Documentation Documentation If you have the Doxygen documentation tool installed, you get a new project (Visual Studio) or "make" target named "doc". You can build this to generate the HTML documentation of MITK in the Documentation/Doxygen directory of your MITK-build binary tree or in the MITK_DOXYGEN_OUTPUT_DIR CMake variable (if specified). -\section BISeven Extend MITK on your own (using the application framework BlueBerry) +\section BuildInstructions_Extending Extend MITK on your own (using the application framework BlueBerry) \ref NewPluginPage -\section BIEight Use MITK in your own project (as a toolkit) +\section BuildInstructions_As_Toolkit Use MITK in your own project (as a toolkit) In the MITK-build binary tree the MITKConfig.cmake file is generated. You can include it in your own project with find_package(MITK) On Windows you also need find_package(ITK) find_package(VTK) to get the library dependencies right. After that you can set your include path with include_directories(${QMITK_INCLUDE_DIRS}) and create an application: link_directories(${MITK_LINK_DIRECTORIES}) add_executable(MyApp MyApp.cpp) target_link_libraries(Step1 ${QMITK_LIBRARIES}) \note IMPORTANT: do not include the ITK_USE_FILE in your project when using MITK. There's a conflict in the ITK and MITK tree classes which will be resolved soon. -\section BINine Superbuild Customization +\section BuildInstructions_Advanced_Customization Superbuild Customization You can inject pre-build third-party libraries into the MITK superbuild by setting certain CMake variables before the first configure step. MITK will then use these third-party libraries instead of downloading and building them itself. Note you must take care to configure those libraries with all options MITK requires. The variables listed below are provided for injecting third-party libraries. Their occurrence in the CMake GUI or in ccmake may depend on specific MITK_USE_* options set to ON. You may also use the variable names below without the EXTERNAL_ prefix, for example when providing their values on a command line call to CMake. - EXTERNAL_BOOST_ROOT Set this variable to your custom Boost installation - EXTERNAL_CTK_DIR Set this variable to your CTK binary tree (the directory containing the CTKConfig.cmake file) - EXTERNAL_CableSwig_DIR Set this variable to your CableSwig binary tree for Python wrapping (the directory containing the CableSwigConfig.cmake file) - EXTERNAL_DCMTK_DIR Set this variable to your DCMTK binary tree (the directory containing the DCMTKConfig.cmake file) - EXTERNAL_GDCM_DIR Set this variable to your GDCM binary tree (the directory containing the GDCMConfig.cmake file) - EXTERNAL_ITK_DIR Set this variable to your ITK binary tree (the directory containing the ITKConfig.cmake file) - EXTERNAL_OpenCV_DIR Set this variable to your OpenCV binary tree (the directory containing the OpenCVConfig.cmake file) - EXTERNAL_VTK_DIR Set this variable to your VTK binary tree (the directory containing the VTKConfig.cmake file) To set CMake options before the first configure step is invoked, supply them on the command line, i.e. \code ccmake -DITK_DIR:PATH=/opt/ITK-release ../MITK \endcode See the following link for more information about how to configure third-party libraries: \subpage BuildToolkits "How to build ITK, VTK and QT" */ diff --git a/Documentation/Doxygen/BuildToolkits.dox b/Documentation/Doxygen/DeveloperManual/BuildToolkits.dox similarity index 60% rename from Documentation/Doxygen/BuildToolkits.dox rename to Documentation/Doxygen/DeveloperManual/BuildToolkits.dox index e6f5b73c48..aaa15df22a 100644 --- a/Documentation/Doxygen/BuildToolkits.dox +++ b/Documentation/Doxygen/DeveloperManual/BuildToolkits.dox @@ -1,29 +1,31 @@ /** \page BuildToolkits Build Toolkits -\section buildITK ITK +If you are using the superbuild ITK and VTK will be downloaded and build during the processm by default. Only Qt will have to be build beforehand. You can of course use your own versions of ITK and VTK during the superbuild as described in BuildInstructions_Advanced_Customization . + +\section BuildToolkits_ITK ITK For building ITK please refer to the ITK documentation http://www.itk.org/Wiki/ITK_Getting_Started -\section buildQT QT +\section BuildToolkits_QT QT For detailed build instructions please refer to http://doc.trolltech.com/4.5/installation.html (If you are using a version other than QT 4.5 please change the link accordingly.) -\section buildVTK VTK +\section BuildToolkits_VTK VTK For building VTK please refer to the VTK documentation http://www.vtk.org/Wiki/VTK_Building_VTK Please note, that you have to link VTK against your QT by checking: - \b VTK_USE_GUISUPPORT - \b VTK_USE_QVTK */ diff --git a/Documentation/Doxygen/Development.dox b/Documentation/Doxygen/DeveloperManual/Development.dox similarity index 95% rename from Documentation/Doxygen/Development.dox rename to Documentation/Doxygen/DeveloperManual/Development.dox index 5353354686..caa8d3b710 100644 --- a/Documentation/Doxygen/Development.dox +++ b/Documentation/Doxygen/DeveloperManual/Development.dox @@ -1,32 +1,32 @@ /** \page Development Development with MITK The following items are concerned with the practical use of the MITK library for software development. Some abstract concepts of MITK are described in \ref Concepts \section DevelopmentSetup Setting Up MITK \li \subpage SupportedPlatformsPage \li \subpage BuildInstructionsPage \li \subpage thirdpartylibs \section DevelopmentGettingToKnow Getting To Know MITK \li \subpage DirectoryStructurePage \li \subpage TutorialPage \section DevelopmentWith Developing With MITK \li \subpage DICOMTesting \li \subpage NewPluginPage \li \subpage StatemachineEditor \li \subpage mitkExtPointsIndex \li \subpage KnownProblemsPage \section DevelopmentContributing Contributing To MITK \li \subpage DocumentationGuide -\li \subpage StylesAndNotesPage +\li \subpage StyleGuideAndNotesPage */ diff --git a/Documentation/Doxygen/DirectoryStructure.dox b/Documentation/Doxygen/DeveloperManual/DirectoryStructure.dox similarity index 100% rename from Documentation/Doxygen/DirectoryStructure.dox rename to Documentation/Doxygen/DeveloperManual/DirectoryStructure.dox diff --git a/Documentation/Doxygen/DocumentationGuide.dox b/Documentation/Doxygen/DeveloperManual/DocumentationGuide.dox similarity index 100% rename from Documentation/Doxygen/DocumentationGuide.dox rename to Documentation/Doxygen/DeveloperManual/DocumentationGuide.dox diff --git a/Documentation/Doxygen/KnownProblems.dox b/Documentation/Doxygen/DeveloperManual/KnownProblems.dox similarity index 92% rename from Documentation/Doxygen/KnownProblems.dox rename to Documentation/Doxygen/DeveloperManual/KnownProblems.dox index de4a3d30d0..52da8eddd8 100644 --- a/Documentation/Doxygen/KnownProblems.dox +++ b/Documentation/Doxygen/DeveloperManual/KnownProblems.dox @@ -1,14 +1,14 @@ /** \page KnownProblemsPage Known Problems \li "Installing" MITK via cmake (or using "make install") is not yet supported. \li Sometimes remote X sessions will display black rendering windows. It is not known whether this is a problem within MITK or within the X implementation. \li MITK CHILI plugin has limitations when working with DICOMDIR data sources (bug #1756) -\section deployment Deployment +\section KnownProblemsPage_Deployment Deployment \li CMAKE_BUILD_TYPE has to be set to Debug or Release: For Makefile-based installers (make on Mac and Linux, nmake on Windows ) the CMAKE_BUILD_TYPE variable has to be set to Debug or Release. Otherwise the packages generated by CPack will be incomplete. */ diff --git a/Documentation/Doxygen/NewPlugin.dox b/Documentation/Doxygen/DeveloperManual/NewPlugin.dox old mode 100755 new mode 100644 similarity index 100% rename from Documentation/Doxygen/NewPlugin.dox rename to Documentation/Doxygen/DeveloperManual/NewPlugin.dox diff --git a/Documentation/Doxygen/StyleGuide.dox b/Documentation/Doxygen/DeveloperManual/StyleGuideAndNotes.dox similarity index 89% rename from Documentation/Doxygen/StyleGuide.dox rename to Documentation/Doxygen/DeveloperManual/StyleGuideAndNotes.dox index 544ec62757..a52ca3b7fd 100644 --- a/Documentation/Doxygen/StyleGuide.dox +++ b/Documentation/Doxygen/DeveloperManual/StyleGuideAndNotes.dox @@ -1,493 +1,493 @@ /** -\page StylesAndNotesPage The MITK Style Guide and Technical Notes +\page StyleGuideAndNotesPage The MITK Style Guide and Technical Notes The following document is a description of the accepted coding style for the Medical Imaging Interaction Toolkit (MITK). Developers who wish to contribute code to MITK should read and adhere to the standards described here. Available sections: - \ref NameConventions - \ref Pointer - \ref Namespace - \ref CodeLayoutandIndentation - \ref UseofBraces - \ref IncludeGuards - \ref TechnicalNotes -\section NameConventions Name Conventions +\section StyleGuideAndNotesPage_NameConventions Name Conventions \li Using case change to indicate separate words @code ImageFilter PixelType DataStorage NodePredicateProperty @endcode \li Underscores are not used e.g. Image_Filer, _Node \li Variable names should convey the meaning behind the code @code BoundingBox::Pointer boundingBox = BoundingBox::New(); @endcode \li Names are generally spelled out @code mitk::DataTreeNode* node; @endcode \li Abbreviation are allowable when in common use e.g. ROI for Region of Interest -\subsection NamingClasses Naming Classes +\subsection StyleGuideAndNotesPage_NamingClasses Naming Classes \li Classes are named beginning with a capital letter \li Classes are named according to the following general rule: @code class name = @endcode \li Examples of concetpts \n Accessor: Access and convert between types e.g. NullScalarAccessor \n Container: A container of objects such as points or images e.g. VectorContainer \n Filter: A class that participates in the data processing pipeline e.g. AddImageFilter \n Mapper: Transform data from one form into another e.g. ContourMapper2D \n Reader/Wirter: A class that reads/writes a single data object e.g. VtkSurfaceReader \n -\subsection NamingFiles Naming Files +\subsection StyleGuideAndNotesPage_NamingFiles Naming Files \li MITK classes like @a ExampleClass should be in namespace @a mitk and their corresponding files should be named @a mitkExampleClass.h/.cpp. @code mitkDataStorage @endcode \li Qt specific MITK classes like @a QmitkListView should have the prefix Qmitk in their class names and their corresponding files should be named @a QmitkListView.h/.cpp. @code QmitkDataStorageComboBox @endcode \li Header Files ends with an .h and \li Implementation Files with an .cpp or .txx for a template class -\subsection NamingMethodsandFunctions Naming Methods and Functions +\subsection StyleGuideAndNotesPage_NamingMethodsandFunctions Naming Methods and Functions \li Functions and methods are named beginning with a capital letter \li Referring to class methods in code, an explicit this-> pointer should be used @code mitk::DataStorage::SetOfObjects::ConstPointer all = this->GetAll(); @endcode -\subsection NamingSignalSlots Naming Signal/Slots Methods and Functions +\subsection StyleGuideAndNotesPage_NamingSignalSlots Naming Signal/Slots Methods and Functions \li Slots are named according to the following general rule @code On[variable name who send the signal][signal](); @endcode \li Example @code connect( loadImagePushButton, SIGNAL( clicked(bool ) ), SLOT( OnLoadImagePushButtonClicked( bool ) ) ); void mitk::Image::OnLoadImagePushButtonClicked( bool ) { ... Do something ... } @endcode \li Signals are named according to the following general rule @code Signal[MethodName](); @endcode \li Example @code emit SignalFinishedSegmentation(); @endcode -\subsection NamingClassDataMembers Naming Class Data Members +\subsection StyleGuideAndNotesPage_NamingClassDataMembers Naming Class Data Members \li Class data member are prepended with m_ @code m_Volumes m_OffsetTable m_ImageMask @endcode \li Except of QT class Data Members, those begins in lowercase. @code loadImageButton; closeImageAction; @endcode -\subsection NamingLocalVariables Naming Local Variables +\subsection StyleGuideAndNotesPage_NamingLocalVariables Naming Local Variables \li Local variables begin in lowercase @code offset data slicesIt @endcode -\subsection NamingQtVariables Naming Qt Variables +\subsection StyleGuideAndNotesPage_NamingQtVariables Naming Qt Variables \li GUI variables ends with name of used QT tool. @code QPushButton* loadImagePushButton; QAction* closeImageAction; QCheckBox* hideImageCheckBox; QRadioButton* binaryImageRadioButton; @endcode -\subsection NamingTypedefs Naming Typedefs +\subsection StyleGuideAndNotesPage_NamingTypedefs Naming Typedefs \li Typedef names end in the word Type @code typedef TPixel PixelType; typedef itk::Image< TPixel, VImageDimension > ImageType; typedef std::list ImageListType; @endcode -\section Pointer Pointer +\section StyleGuideAndNotesPage_Pointer Pointer -\subsection DeclarationofPointers Declaration of Pointers +\subsection StyleGuideAndNotesPage_DeclarationofPointers Declaration of Pointers \li Position of * pointers are connected with the declaration type @code int* counter; @endcode \li Analog to references @code int& counter; @endcode -\subsection SmartPointer SmartPointer +\subsection StyleGuideAndNotesPage_SmartPointer SmartPointer \li SmartPointers must be used for classes that have itk::Object as a base class. \li Assignment of a just created instance to a normal pointer results in a crash, since the reference count is decreased immediately to zero and the object is destroyed. @code itk::Object::Pointer object = itk::Object::New(); @endcode \li Static declarations are also forbidden and result into an exception when the scope of the variable is left, because the destructor is called while the reference count is still greater than zero. \li Note that using smart pointers requires using real (normal) pointers when setting input. If you want to return a newly created smart pointer that is not also kept within the class (e.g., if you write a Clone method), you have to return a smart pointer on output (compare itkMacro.h). If the smart pointer is kept within the class, returning a real (normal) pointer is sufficient. \li Testing a SmartPointer against NULL is done with the IsNull() and Is- NotNull() methods. A simple ==NULL issues a warning. -\section Namespace Namespace +\section StyleGuideAndNotesPage_Namespace Namespace \li MITK classes should be in namespace @a mitk @code mitk::Image::Pointer mitk::ImageGenerator::MakeImage() { // already in namespace mitk here! Image::Pointer image = mitk::Image::New(); ImageDecorator::Pointer decorator = mitk::ImageDecorator::New(); d->Decorate( image ); return image; } @endcode \li Constants in MITK for mitk::Operation and mitk::Action are set in namespace, so don't forget to add prefix mitk:: @code switch (actionId) { case mitk::AcMOVESELECTED: ....Do something ... break; default: break; } @endcode -\section CodeLayoutandIndentation Code Layout and Indentation +\section StyleGuideAndNotesPage_CodeLayoutandIndentation Code Layout and Indentation -\subsection GeneralLayout General Layout +\subsection StyleGuideAndNotesPage_GeneralLayout General Layout \li Each line of code should take no more than 81 characters. \li Use lots of whitespace to separate logical blocks of code, intermixed with comments \li DO NOT USE TABS. The standard indention is 2 spaces (see ITK Style Guide). Configure your editor accordingly. \li Declaration of variables should be one declaration per line @code int sliceNumber; char* stringName; ImageType::Pointer image; @endcode -\subsection ClassLayout Class Layout +\subsection StyleGuideAndNotesPage_ClassLayout Class Layout \li Copyright @code /*========================================================================= Program: Medical Imaging & Interaction Toolkit Module: $RCSfile$ Language: C++ Date: $Date$ Version: $Revision$ Copyright (c) German Cancer Research Center, Division of Medical and Biological Informatics. All rights reserved. See MITKCopyright.txt or http://www.mitk.org/copyright.html for details. This software is distributed WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the above copyright notices for more information. =========================================================================*/ @endcode \li Include Guards @code #ifndef __mitkClassName_h #define __mitkClassName_h @endcode \li Includes [A .. Z] @code #include "... .h" @endcode \li Doxygen @code /*! \brief mitkClassName \sa ..... \verbatim Last contributor: $Author$ \endverbatim */ @endcode \li Namespace @code namespace mitk { @endcode \li Class (Template) @code template class ClassName : public ImageBase { @endcode \li Typedefs @code public: ....typedefs.... @endcode \li Methods @code public: ....methods.... protected: ....methods.... private: ....methods.... @endcode \li QT Signals @code signals: Signal...(); @endcode \li QT Slots @code public slots: On...(); protected slots: On...(); @endcode \li Data Member @code private/protected: ....class data members.... }; } #endif @endcode -\section UseofBraces Use of Braces +\section StyleGuideAndNotesPage_UseofBraces Use of Braces \li Used to delimit the scope of an if, for, while, switch. \li Braces are placed on a line by themselves: @code for ( unsigned int i = 0; i < 3; ++i ) { ... do something ... } @endcode or @code if ( condition ) { ... do something ... } else if ( other condition ) { ... do something ... } else { ... do something ... } @endcode \li You can choose to use braces on a line with a code block when the block consists of a single line: @code if ( condition ) { foo = 1; } else if ( condition2 ) { foo = 3; } else { return; } @endcode or @code for ( unsigned int i = 0; i < 3; ++i) { x[i] = 0.0; } @endcode -\section IncludeGuards Include Guards +\section StyleGuideAndNotesPage_IncludeGuards Include Guards \li #inlcude guard is a particular construct used to avoid the problem of double inclusion when dealing with the #include directive. \li Naming convention for #inlcude guards is: ClassName_h \li Following example demonstrates a problem that can arise if #include guards are missing: Here, the file child.cpp has indirectly included two copies of the text in the header file grandfather.h. This causes a compilation error, since the structure type foo is apparently defined twice. @code grandfather.h struct foo { int m Member; }; father.h #include "grandfather.h" child.h #include "grandfather.h" #include "father.h" @endcode -\subsection Useofincludeguards Use of #include guards +\subsection StyleGuideAndNotesPage_Useofincludeguards Use of #include guards \li Here, the first inclusion of grandfather.h causes the macro grandfather h to be defined. Then, when child.cpp includes grandfather.h the second time, the #ifndef test fails, and the preprocessor skips down to the #endif, thus avoiding the second definition of struct foo. The program compiles correctly. @code grandfather.h #ifndef grandfather h #define grandfather h struct foo { int m Member; }; father.h #include "grandfather.h" child.h #include "grandfather.h" #include "father.h" @endcode -\section TechnicalNotes Some Technical Notes +\section StyleGuideAndNotesPage_TechnicalNotes Some Technical Notes \li Use forward declarations in header files wherever possible. Only include those header files in a header file that are really necessary. Include the rest in the implementation file. \li For classes inheriting directly or indirectly from @a itk::LightObject (most of the MITK-classes do so), the class definition should include the mitkClassMacro. Additionally, if the class can be instantiated (normally the case, if the class is not abstract) and has @em only a constructor without parameters, the constructor should be declared protected and the @a itkNewMacro should be used to create a @a New() method for instantiation. Here is an example: @code class ExampleClass : public SuperClassOfTheExampleClass { public: mitkClassMacro(ExampleClass, SuperClassOfTheExampleClass); itkNewMacro(Self); // Self is a typedef to the class name generated by the mitkClassMacro [...] protected: ExampleClass(); virtual ~ExampleClass(); } @endcode \li Set- and Get-methods can be created with the macros @a itkSetObjectMacro(name,type) and @a itkGetObjectMacro(name,type), respectively, if the @a type is derived from @a itk::LightObject or @a itk::Object. There are also macros for other types, e.g., strings, see itkMacro.h. \li When using inner classes of a parent class which is templated, you have to use the keyword @a typename for gcc 3.x and standard compliance. For example, @a TreeChangeListener is an inner class of @a Tree, therefore use: @code class LinkedTree : public Tree { public: typedef typename LinkedTree::TreeChangeListener TreeChangeListener; [...] } @endcode Another example: @code typename std::vector::iterator pos = treeChangeListenerList.begin(); @endcode @a iterator is an inner class of @a vector. \li Constants in MITK for mitk::Operation and mitk::Action are set in namespace, so don't forget to add prefix @a mitk:: @code switch (actionId) { case mitk::AcMOVESELECTED: @endcode Prefixes for the constants are to be used like corresponding others. See file @a Interactions\\mitkBaseInteraction\\mitkInteractionConst.h for further details. \li Often QmitkFunctionality::Activated() and QmitkFunctionality::Deactivated() is the right place to connect and disconnnect event-handlers (e.g., mitk::GlobalStateMachine::AddStateMachine() in Activated() and mitk::GlobalStateMachine::RemoveStateMachine() in Deactivated()). \li The four widgets of the QmitkStdMultiWidget should be initialized in QmitkFunctionality::Activated(), but does @em not need to be restored in QmitkFunctionality::Deactivated(): It is the responsiblity of the subsequently activated functionality to initialize them according to its needs. */ diff --git a/Documentation/Doxygen/SupportedPlatforms.md b/Documentation/Doxygen/DeveloperManual/SupportedPlatforms.md similarity index 100% rename from Documentation/Doxygen/SupportedPlatforms.md rename to Documentation/Doxygen/DeveloperManual/SupportedPlatforms.md diff --git a/Documentation/Doxygen/ThirdPartyLibs.dox b/Documentation/Doxygen/DeveloperManual/ThirdPartyLibs.dox similarity index 100% rename from Documentation/Doxygen/ThirdPartyLibs.dox rename to Documentation/Doxygen/DeveloperManual/ThirdPartyLibs.dox diff --git a/Documentation/Doxygen/Modules.dox b/Documentation/Doxygen/Modules/Modules.dox similarity index 100% rename from Documentation/Doxygen/Modules.dox rename to Documentation/Doxygen/Modules/Modules.dox diff --git a/Documentation/Doxygen/Modules/qt-vtk rendering class overview.vsd b/Documentation/Doxygen/Modules/qt-vtk rendering class overview.vsd deleted file mode 100644 index 93dd70be2f..0000000000 Binary files a/Documentation/Doxygen/Modules/qt-vtk rendering class overview.vsd and /dev/null differ diff --git a/Documentation/Doxygen/Modules/qt-vtk rendering sequence.vsd b/Documentation/Doxygen/Modules/qt-vtk rendering sequence.vsd deleted file mode 100644 index 356431b5ef..0000000000 Binary files a/Documentation/Doxygen/Modules/qt-vtk rendering sequence.vsd and /dev/null differ diff --git a/Documentation/Doxygen/StatemachineEditor/BuildPath.PNG b/Documentation/Doxygen/StatemachineEditor/images/BuildPath.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/BuildPath.PNG rename to Documentation/Doxygen/StatemachineEditor/images/BuildPath.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/CreateJavaProject.PNG b/Documentation/Doxygen/StatemachineEditor/images/CreateJavaProject.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/CreateJavaProject.PNG rename to Documentation/Doxygen/StatemachineEditor/images/CreateJavaProject.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/Import.PNG b/Documentation/Doxygen/StatemachineEditor/images/Import.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/Import.PNG rename to Documentation/Doxygen/StatemachineEditor/images/Import.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/Import2.PNG b/Documentation/Doxygen/StatemachineEditor/images/Import2.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/Import2.PNG rename to Documentation/Doxygen/StatemachineEditor/images/Import2.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/Import3.PNG b/Documentation/Doxygen/StatemachineEditor/images/Import3.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/Import3.PNG rename to Documentation/Doxygen/StatemachineEditor/images/Import3.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/Import4.PNG b/Documentation/Doxygen/StatemachineEditor/images/Import4.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/Import4.PNG rename to Documentation/Doxygen/StatemachineEditor/images/Import4.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/NewStatemachine.PNG b/Documentation/Doxygen/StatemachineEditor/images/NewStatemachine.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/NewStatemachine.PNG rename to Documentation/Doxygen/StatemachineEditor/images/NewStatemachine.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/NewStatemachine1.PNG b/Documentation/Doxygen/StatemachineEditor/images/NewStatemachine1.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/NewStatemachine1.PNG rename to Documentation/Doxygen/StatemachineEditor/images/NewStatemachine1.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/NewStatemachine2.PNG b/Documentation/Doxygen/StatemachineEditor/images/NewStatemachine2.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/NewStatemachine2.PNG rename to Documentation/Doxygen/StatemachineEditor/images/NewStatemachine2.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/NewStatemachine3.PNG b/Documentation/Doxygen/StatemachineEditor/images/NewStatemachine3.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/NewStatemachine3.PNG rename to Documentation/Doxygen/StatemachineEditor/images/NewStatemachine3.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/Runas.png b/Documentation/Doxygen/StatemachineEditor/images/Runas.png similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/Runas.png rename to Documentation/Doxygen/StatemachineEditor/images/Runas.png diff --git a/Documentation/Doxygen/StatemachineEditor/addAction.PNG b/Documentation/Doxygen/StatemachineEditor/images/addAction.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/addAction.PNG rename to Documentation/Doxygen/StatemachineEditor/images/addAction.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/application.PNG b/Documentation/Doxygen/StatemachineEditor/images/application.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/application.PNG rename to Documentation/Doxygen/StatemachineEditor/images/application.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/application1.PNG b/Documentation/Doxygen/StatemachineEditor/images/application1.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/application1.PNG rename to Documentation/Doxygen/StatemachineEditor/images/application1.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/changeEvent.PNG b/Documentation/Doxygen/StatemachineEditor/images/changeEvent.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/changeEvent.PNG rename to Documentation/Doxygen/StatemachineEditor/images/changeEvent.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/openPropertiesView.PNG b/Documentation/Doxygen/StatemachineEditor/images/openPropertiesView.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/openPropertiesView.PNG rename to Documentation/Doxygen/StatemachineEditor/images/openPropertiesView.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/openstatemachinexml.png b/Documentation/Doxygen/StatemachineEditor/images/openstatemachinexml.png similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/openstatemachinexml.png rename to Documentation/Doxygen/StatemachineEditor/images/openstatemachinexml.png diff --git a/Documentation/Doxygen/StatemachineEditor/specifycontainer.png b/Documentation/Doxygen/StatemachineEditor/images/specifycontainer.png similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/specifycontainer.png rename to Documentation/Doxygen/StatemachineEditor/images/specifycontainer.png diff --git a/Documentation/Doxygen/StatemachineEditor/specifycontainer2.png b/Documentation/Doxygen/StatemachineEditor/images/specifycontainer2.png similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/specifycontainer2.png rename to Documentation/Doxygen/StatemachineEditor/images/specifycontainer2.png diff --git a/Documentation/Doxygen/StatemachineEditor/specifycontainer3.png b/Documentation/Doxygen/StatemachineEditor/images/specifycontainer3.png similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/specifycontainer3.png rename to Documentation/Doxygen/StatemachineEditor/images/specifycontainer3.png diff --git a/Documentation/Doxygen/Tutorial/Step06.dox b/Documentation/Doxygen/Tutorial/Step06.dox index 6b3364d25d..55809be313 100644 --- a/Documentation/Doxygen/Tutorial/Step06.dox +++ b/Documentation/Doxygen/Tutorial/Step06.dox @@ -1,112 +1,112 @@ /** \page Step06Page MITK Tutorial - Step 6: Use an interactive region-grower In this step the program is enhanced by the possibility to start a region-grower at interactively added points. We will see how MITK images can be accessed as ITK images. We now load the image file only (mitk/Core/Code/Testing/Data/Pic3D.pic.gz) since the surface will be the result of the region-growing. \image html step6_result.png The source is now split among several files: \li \ref Step6.cpp "Step6.cpp" \li \ref Step6.h "Step6.h" \li \ref Step6RegionGrowing.txx "Step6RegionGrowing.txx" \li \ref Step6RegionGrowing1.cpp "Step6RegionGrowing1.cpp" \li \ref Step6RegionGrowing2.cpp "Step6RegionGrowing2.cpp" \li \ref Step6main.cpp "Step6main.cpp" The class Step6 inherits from QMainWindow and provides methods for setting up the widgets. Step6RegionGrowing.cpp contains a method for performing the region-growing. Step6main.cpp contains main. Like in ITK and VTK class member names start with m_ followed by the proper member name starting with a capital letter (e.g. m_Tree). -Function names start with capital letters. To learn more about style conventions in MITK read \ref StylesAndNotesPage "The MITK Style Guide". +Function names start with capital letters. To learn more about style conventions in MITK read \ref StyleGuideAndNotesPage "The MITK Style Guide". \dontinclude Step6.cpp The widgets are initialized as in the previous steps but with an additional QVBox for a button to start the segmentation: \skipline Create controlsParent \until hlayout->addWidget(m_LineEditThresholdMax) Then a button is created to start the segmentation and its clicked() signal is connected to the method StartRegionGrowing(): \dontinclude Step6.cpp \skipline QPushButton* startButton \skipline connect(startButton \section AccessMTIKImagesAsITKImagesSection Access MITK images as ITK images ITK images are templated whereas mitk::Images are not. To use ITK filters with MITK images, we have to convert From MITK to ITK. To do so, first define an access method, which is templated as an ITK image is: \code template MyAccessMethod(itk::Image* itkImage) { ... } \endcode If you don't understand this template syntax, you should read any C++ text book. Understanding template syntax is crucial to successfully using ITK. To call this templated method with an (untemplated) mitk::Image, you can use the AccessByItk macro from mitkImageAccessByItk.h. This macro checks for the actual image type of the mitk::Image and does any neccessary conversions. Look into "Modules / Adaptor classes" for more information. \code AccessByItk(mitkImage, MyAccessMethod) \endcode \dontinclude Step6RegionGrowing.txx In this step our access method is called RegionGrowing() (defined in \ref Step6RegionGrowing.txx "Step6RegionGrowing.txx"): \skipline template \until } \until } Additionally the access function has to be instantiated for all datatypes and two/three dimensions as some compilers have memory problems without this explicit instantiation, some even need instantiations in separate files for 2D/3D: \n For 2D in \ref Step6RegionGrowing1.cpp "Step6RegionGrowing1.cpp" : \dontinclude Step6RegionGrowing1.cpp \skipline InstantiateAccessFunctionForFixedDimension_1 ... and for 3D in \ref Step6RegionGrowing2.cpp "Step6RegionGrowing2.cpp": \dontinclude Step6RegionGrowing2.cpp \skipline InstantiateAccessFunctionForFixedDimension_1 \dontinclude Step6.cpp The method StartRegionGrowing() finally calls our access method RegionGrowing(): \skipline Step6::StartRegionGrowing \until } \section ConvertingITKMITKSection Converting ITK images to MITK images and vice versa In some cases it is useful to simply convert between ITK and MITK images. The direction ITK to MITK is easy, since mitk::Image can handle most data types. The direction MITK to ITK is more critical, since ITK images have to be instantiated with a fixed pixel type and fixed dimension at compile time. \li \code mitk::Image mitk::ImportItkImage(itk::Image<...>) \endcode \li \code mitk::CastToItkImage(mitkImage, itk::Image<...>) \endcode \section ConnectingMITKToVTKSection Connecting MITK images to VTK Images are not converted or copied: The data array is just accessed via an encapsulating VTK object. \li \code vtkImageData* mitk::Image::GetVtkImageData(int time = 0) \endcode \section SurfacesMITKToVTKSection MITK Surfaces to VTK and vice versa Again: not a conversion, just accessing. \li \code vtkPolyData* mitk::Surface::GetVtkPolyData(int time = 0) \endcode \li \code mitk::Surface::SetVtkPolyData(vtkPolyData*, int time = 0) \endcode \ref Step05Page "[Previous step]" \ref Step07Page "[Next step]" \ref TutorialPage "[Main tutorial page]" */ diff --git a/Documentation/Doxygen/Applications.dox b/Documentation/Doxygen/UserManual/Applications.dox similarity index 95% rename from Documentation/Doxygen/Applications.dox rename to Documentation/Doxygen/UserManual/Applications.dox index 03320b76e8..65f1b1e6c6 100644 --- a/Documentation/Doxygen/Applications.dox +++ b/Documentation/Doxygen/UserManual/Applications.dox @@ -1,30 +1,30 @@ /** \page ApplicationsPage Using MITK and Applications Available sections: - \ref ApplicationsPageUsingMITK - \ref ApplicationsPageApplications - \ref ApplicationsPageApplicationsList \section ApplicationsPageUsingMITK Using MITK Many of the applications created with the use of MITK share common basic functionalities. Due to this, there is one manual which explains the basic usage of MITK. For more information on the use of the advanced features of an application please take a look the \ref ApplicationsPageApplicationsList , whereas if you are interested in a certain view further information can be found in \ref ModuleListPage . -The basic usage information on MITK can be found in \subpage MITKManualMainPage . +The basic usage information on MITK can be found in \subpage MITKUserManualPage . \section ApplicationsPageApplications What are Applications? Applications are executables, which contain a certain configuration of views and perspectives. Usually they are aimed at a selective audience or solving a particular problem. As such they focus on certain capabilities of MITK, while ignoring others. The main reason for this is to supply the users of the application with the power of MITK for solving their tasks, without daunting them with an overwhelming number of menus and options. At the same time, this allows, together with the use of perspectives, the creation of sleek and elegant workflows, which are easily comprehensible. A typical example of this would be an application which contains only views related to the analysis of the human brain (particular question) or one which contains only what is necessary for displaying medical data in the classroom (specific audience). \section ApplicationsPageApplicationsList List of Applications -If you are interested in using a specific application, currently developed by the MITK team you might want to take a look first at the \ref MITKManualMainPage . Further information on any application can be found here: +If you are interested in using a specific application, currently developed by the MITK team you might want to take a look first at the \ref MITKUserManualPage . Further information on any application can be found here:
  • \subpage org_extapplication
  • \subpage org_dti_atlas_application
  • \subpage org_diffusionapplication
*/ \ No newline at end of file diff --git a/Documentation/Doxygen/UserManual/MITKUserManual.dox b/Documentation/Doxygen/UserManual/MITKUserManual.dox index bacf8c1f02..8fd660c38f 100644 --- a/Documentation/Doxygen/UserManual/MITKUserManual.dox +++ b/Documentation/Doxygen/UserManual/MITKUserManual.dox @@ -1,118 +1,118 @@ /** -\page MITKManualMainPage The MITK User Manual +\page MITKUserManualPage The MITK User Manual Welcome to the basic MITK user manual. This document tries to give a concise overview of the basic functions of MITK and be an comprehensible guide on using them. Available sections: - - \ref MITKManualMainPageOverview - - \ref MITKManualMainPageUserInterface - - \ref MITKManualMainPagePerspectives + - \ref MITKUserManualPageOverview + - \ref MITKUserManualPageUserInterface + - \ref MITKUserManualPagePerspectives -\section MITKManualMainPageOverview About MITK +\section MITKUserManualPageOverview About MITK MITK is an open-source framework that was originally developed as a common framework for Ph.D. students in the Division of Medical and Biological Informatics (MBI) at the German Cancer Research Center. MITK aims at supporting the development of leading-edge medical imaging software with a high degree of interaction. MITK re-uses virtually anything from VTK and ITK. Thus, it is not at all a competitor to VTK or ITK, but an extension, which tries to ease the combination of both and to add features not supported by VTK or ITK. Research institutes, medical professionals and companies alike can use MITK as a basic framework for their research and even commercial (thorough code research needed) software due to the BSD-like software license. Research institutes will profit from the high level of integration of ITK and VTK enhanced with data management, advanced visualization and interaction functionality in a single framework that is supported by a wide variety of researchers and developers. You will not have to reinvent the wheel over and over and can concentrate on your work. Medical Professionals will profit from MITK and the MITK applications by using its basic functionalities for research projects. But nonetheless they will be better off, unless they are programmers themselves, to cooperate with a research institute developing with MITK to get the functionalitiy they need. MITK and the MITK applications are not certified medical products and may be used in a research setting only. They must not be used in patient care. -\section MITKManualMainPageUserInterface The User Interface +\section MITKUserManualPageUserInterface The User Interface The layout of the MITK applications is designed to give a clear distinction between the different work areas. The following figure gives an overview of the main sections of the user interface. \image html GUI_Commented.png "The Common MITK Application Graphical User Interface" -The datamanager and the \ref MITKManualMainPagePerspectives have their own help sections. This document explains the use of: - - The \ref MITKManualMainPageMultiWidget - - The \ref MITKManualMainPageMenu - - The \ref MITKManualMainPageLevelWindow - - The \ref MITKManualMainPageMemoryUsage - - The \ref MITKManualMainPageViews +The datamanager and the \ref MITKUserManualPagePerspectives have their own help sections. This document explains the use of: + - The \ref MITKUserManualPageMultiWidget + - The \ref MITKUserManualPageMenu + - The \ref MITKUserManualPageLevelWindow + - The \ref MITKUserManualPageMemoryUsage + - The \ref MITKUserManualPageViews -\section MITKManualMainPageMultiWidget Four Window View +\section MITKUserManualPageMultiWidget Four Window View -\subsection MITKManualMainPageMultiWidgetOverview Overview +\subsection MITKUserManualPageMultiWidgetOverview Overview The four window view is the heart of the MITK image viewing. The standard layout is three 2D windows and one 3D window, with the transversal window in the top left quarter, the sagittal window in the top right quarter, the coronal window in the lower left quarter and the 3D window in the lower right quarter. The different planes form a crosshair that can be seen in the 3D window. Once you select a point within the picture, informations about it are displayed at the bottom of the screen. -\subsection MITKManualMainPageMultiWidgetNavigation Navigation +\subsection MITKUserManualPageMultiWidgetNavigation Navigation Left click in any of the 2D windows centers the crosshair on that point. Pressing the right mouse button and moving the mouse zooms in and out. By scrolling with the mouse wheel you can navigate through the slices of the active window and pressing the mouse wheel while moving the mouse pans the image section. In the 3D window you can rotate the object by pressing the left mouse button and moving the mouse, zoom either with the right mouse button as in 2D or with the mouse wheel, and pan the object by moving the mouse while the mouse wheel is pressed. Placing the cursor within the 3D window and holding the "F" key allows free flight into the 3D view. -\subsection MITKManualMainPageMultiWidgetCustomizingViews Customizing +\subsection MITKUserManualPageMultiWidgetCustomizingViews Customizing By moving the cursor to the upper right corner of any window you can activate the window menu. It consists of three buttons. \image html Crosshair_Modes.png "Crosshair" The crosshair button allows you toggle the crosshair, reset the view and change the behaviour of the planes. Activating either of the rotation modes allows you to rotate the planes visible in a 2D window by moving the mouse cursor close to them and click and dragging once it changes to indicate that rotation can be done. The swivel mode is recommended only for advanced users as the planes can be moved freely by clicking and dragging anywhere within a 2D window. The middle button expands the corresponding window to fullscreen within the four window view. \image html Views_Choices.png "Layout Choices" The right button allows you to choose between many different layouts of the four window view to use the one most suited to your task. -\section MITKManualMainPageMenu Menu +\section MITKUserManualPageMenu Menu -\subsection MITKManualMainPageFile File +\subsection MITKUserManualPageFile File This dialog allows you to save, load and clear entire projects, this includes any nodes in the data manager. -\subsection MITKManualMainPageEdit Edit +\subsection MITKUserManualPageEdit Edit This dialog supports undo and redo operations as well as the image navigator, which gives you sliders to navigate through the data quickly. -\subsection MITKManualMainPageWindow Window +\subsection MITKUserManualPageWindow Window This dialog allows you to open a new window, change between perspectives and reset your current one to default settings. If you want to use an operation of a certain perspective within another perspective the "Show View" menu allows to select a specific function that is opened and can be moved within the working areas according to your wishes. Be aware that not every function works with every perspective in a meaningful way. The Preferences dialog allows you to adjust and save your custom settings. \image html Window_Dropdown.png "Preferences" -\subsection MITKManualMainPageHelp Help +\subsection MITKUserManualPageHelp Help This dialog contains this help, the welcome screen and information about MITK. -\section MITKManualMainPageLevelWindow Levelwindow +\section MITKUserManualPageLevelWindow Levelwindow Once an image is loaded the levelwindow appears to the right hand side of the four window view. With this tool you can adjust the range of grey values displayed and the gradient between them. Moving the lower boundary up results in any pixels having a value lower than that boundary to be displayed as black. Lowering the upper boundary causes all pixels having a value higher than it to be displayed as white. The pixels with a value between the lower and upper boundary are displayed in different shades of grey. This way a smaller levelwindow results in higher contrasts while cutting of the information outside its range whereas a larger levelwindow displays more information at the cost of contrast and detail. You can pick the levelwindow with the mouse to move it up and down, while moving the mouse cursor to the left or right to change its size. Picking one of the boundaries with a left click allows you to change the size symmetrically. Holding CTRL and clicking a boundary adjusts only that value. -\section MITKManualMainPageMemoryUsage System Load Indicator +\section MITKUserManualPageMemoryUsage System Load Indicator The System Load Indicator in the lower right hand corner of the screen gives information about the memory currently required by the MITK application. Keep in mind that image processing is a highly memory intensive task and monitor the indicator to avoid your system freezing while constantly swapping to the hard drive. -\section MITKManualMainPageViews Views +\section MITKUserManualPageViews Views Each solution for a specific problem that is self contained is realized as a single view. Thus you can create a workflow for your problem by combining the capabilities of different views to suit your needs. -One elegant way to do this is by combining views in \ref MITKManualMainPagePerspectives. +One elegant way to do this is by combining views in \ref MITKUserManualPagePerspectives. By pressing and holding the left mouse button on a views tab you can move it around to suit your needs, even out of the application window. -\section MITKManualMainPagePerspectives Perspectives +\section MITKUserManualPagePerspectives Perspectives The different tasks that arise in medical imaging need very different approaches. To acknowledge this circumstance MITK supplies a framework that can be build uppon by very different solutions to those tasks. These solutions are called perspectives, each of them works independently of others although they might be used in sequence to achieve the solution of more difficult problems. It is possible to switch between the perspectives using the "Window"->"Open Perspective" dialog. -See \ref MITKManualMainPageMenu for more information about switching perspectives. +See \ref MITKUserManualPageMenu for more information about switching perspectives. */ diff --git a/Documentation/Doxygen/ModuleList.dox b/Documentation/Doxygen/UserManual/ModuleList.dox similarity index 100% rename from Documentation/Doxygen/ModuleList.dox rename to Documentation/Doxygen/UserManual/ModuleList.dox diff --git a/Documentation/Doxygen/UserManual/Crosshair_Modes.png b/Documentation/Doxygen/UserManual/images/Crosshair_Modes.png similarity index 100% rename from Documentation/Doxygen/UserManual/Crosshair_Modes.png rename to Documentation/Doxygen/UserManual/images/Crosshair_Modes.png diff --git a/Documentation/Doxygen/UserManual/GUI.png b/Documentation/Doxygen/UserManual/images/GUI.png similarity index 100% rename from Documentation/Doxygen/UserManual/GUI.png rename to Documentation/Doxygen/UserManual/images/GUI.png diff --git a/Documentation/Doxygen/UserManual/GUI_Commented.png b/Documentation/Doxygen/UserManual/images/GUI_Commented.png similarity index 100% rename from Documentation/Doxygen/UserManual/GUI_Commented.png rename to Documentation/Doxygen/UserManual/images/GUI_Commented.png diff --git a/Documentation/Doxygen/UserManual/Top_Right_Corner_Menu.png b/Documentation/Doxygen/UserManual/images/Top_Right_Corner_Menu.png similarity index 100% rename from Documentation/Doxygen/UserManual/Top_Right_Corner_Menu.png rename to Documentation/Doxygen/UserManual/images/Top_Right_Corner_Menu.png diff --git a/Documentation/Doxygen/UserManual/Views_Choices.png b/Documentation/Doxygen/UserManual/images/Views_Choices.png similarity index 100% rename from Documentation/Doxygen/UserManual/Views_Choices.png rename to Documentation/Doxygen/UserManual/images/Views_Choices.png diff --git a/Documentation/Doxygen/UserManual/Window_Dropdown.png b/Documentation/Doxygen/UserManual/images/Window_Dropdown.png similarity index 100% rename from Documentation/Doxygen/UserManual/Window_Dropdown.png rename to Documentation/Doxygen/UserManual/images/Window_Dropdown.png diff --git a/Plugins/org.mitk.gui.qt.diffusionimagingapp/documentation/UserManual/QmitkDiffusionImagingAppUserManual.dox b/Plugins/org.mitk.gui.qt.diffusionimagingapp/documentation/UserManual/QmitkDiffusionImagingAppUserManual.dox index 9557567e81..d08667e22f 100644 --- a/Plugins/org.mitk.gui.qt.diffusionimagingapp/documentation/UserManual/QmitkDiffusionImagingAppUserManual.dox +++ b/Plugins/org.mitk.gui.qt.diffusionimagingapp/documentation/UserManual/QmitkDiffusionImagingAppUserManual.dox @@ -1,12 +1,12 @@ /** \bundlemainpage{org_diffusionapplication} Using The Diffusion Imaging Application \section QMitkDiffusionApplicationManualOverview What is the Diffusion Imaging Application The Diffusion Imaging Application contains selected views for the analysis of images of the human brain. These encompass the views developed by the Neuroimaging Group of the Division Medical and Biological Informatics as well as basic image processing views such as segmentation and volumevisualization. \isHtml -For a basic guide to MITK see \ref MITKManualMainPage . +For a basic guide to MITK see \ref MITKUserManualPage . \isHtmlend */ diff --git a/Plugins/org.mitk.gui.qt.dtiatlasapp/documentation/UserManual/QmitkDTIAtlasAppUserManual.dox b/Plugins/org.mitk.gui.qt.dtiatlasapp/documentation/UserManual/QmitkDTIAtlasAppUserManual.dox index 778b310dbe..487a8af86b 100644 --- a/Plugins/org.mitk.gui.qt.dtiatlasapp/documentation/UserManual/QmitkDTIAtlasAppUserManual.dox +++ b/Plugins/org.mitk.gui.qt.dtiatlasapp/documentation/UserManual/QmitkDTIAtlasAppUserManual.dox @@ -1,12 +1,12 @@ /** \bundlemainpage{org_dti_atlas_application} Using The DTI Atlas Application \section QMitkDTIAtlasApplicationManualOverview What is the DTI Atlas Application The DTI Atlas Application is a viewer for MR, diffusion tensor and fibre images and contains no additional functionality. The welcome page allows the selection of which example data to examine. \isHtml -For a basic guide to MITK see \ref MITKManualMainPage . +For a basic guide to MITK see \ref MITKUserManualPage . \isHtmlend */ diff --git a/Plugins/org.mitk.gui.qt.extapplication/documentation/UserManual/QmitkExtapplicationUserManual.dox b/Plugins/org.mitk.gui.qt.extapplication/documentation/UserManual/QmitkExtapplicationUserManual.dox index de3fc8bbee..dc03786879 100644 --- a/Plugins/org.mitk.gui.qt.extapplication/documentation/UserManual/QmitkExtapplicationUserManual.dox +++ b/Plugins/org.mitk.gui.qt.extapplication/documentation/UserManual/QmitkExtapplicationUserManual.dox @@ -1,19 +1,19 @@ /** \bundlemainpage{org_extapplication} Using The Ext Application \section QMitkExtApplicationManualOverview What is the Ext App The MITK Ext Application is used by developers. As such the kind and number of views it contains is highly variable and dependent on the specific build. Typically it contains no special perspectives and whatever views the developer deemed desirable. Be aware, that it may contain views which are work in progress and may behave erratically. If you have been given such an executable by someone, please refer to the appropriate section of the online documentation for up to date usage information on any module. \isHtml \ref ModuleListPage \isHtmlend If you are using a nightly installer, the Ext Application will contain nearly all views available in MITK and as such most likely will seem confusing. Again the list of modules might be a good starting point if you want to have a rough idea of what could be of interest to you. \isHtml -For a basic guide to MITK see \ref MITKManualMainPage . +For a basic guide to MITK see \ref MITKUserManualPage . \isHtmlend */