diff --git a/Core/Code/CppMicroServices/CMake/usCTestScript.cmake b/Core/Code/CppMicroServices/CMake/usCTestScript.cmake index af6ee829a7..7feac62e8e 100644 --- a/Core/Code/CppMicroServices/CMake/usCTestScript.cmake +++ b/Core/Code/CppMicroServices/CMake/usCTestScript.cmake @@ -1,131 +1,131 @@ macro(build_and_test) set(CTEST_SOURCE_DIRECTORY ${US_SOURCE_DIR}) set(CTEST_BINARY_DIRECTORY "${CTEST_DASHBOARD_ROOT}/${CTEST_PROJECT_NAME}_${CTEST_DASHBOARD_NAME}") #if(NOT CTEST_BUILD_NAME) # set(CTEST_BUILD_NAME "${CMAKE_SYSTEM}_${CTEST_COMPILER}_${CTEST_DASHBOARD_NAME}") #endif() ctest_empty_binary_directory(${CTEST_BINARY_DIRECTORY}) ctest_start("Experimental") if(NOT EXISTS "${CTEST_BINARY_DIRECTORY}/CMakeCache.txt") file(WRITE "${CTEST_BINARY_DIRECTORY}/CMakeCache.txt" "${CTEST_INITIAL_CACHE}") endif() ctest_configure(RETURN_VALUE res) if (res) message(FATAL_ERROR "CMake configure error") endif() ctest_build(RETURN_VALUE res) if (res) message(FATAL_ERROR "CMake build error") endif() ctest_test(RETURN_VALUE res PARALLEL_LEVEL ${CTEST_PARALLEL_LEVEL}) if (res) message(FATAL_ERROR "CMake test error") endif() if(WITH_MEMCHECK AND CTEST_MEMORYCHECK_COMMAND) ctest_memcheck() endif() if(WITH_COVERAGE AND CTEST_COVERAGE_COMMAND) ctest_coverage() endif() #ctest_submit() endmacro() -function(create_initial_cache var _shared _threading _sf _c++11 _autoload) +function(create_initial_cache var _shared _threading _sf _cxx11 _autoload) set(_initial_cache " US_BUILD_TESTING:BOOL=ON US_BUILD_SHARED_LIBS:BOOL=${_shared} US_ENABLE_THREADING_SUPPORT:BOOL=${_threading} US_ENABLE_SERVICE_FACTORY_SUPPORT:BOOL=${_sf} - US_USE_C++11:BOOL=${_c++11} + US_USE_C++11:BOOL=${_cxx11} US_ENABLE_AUTOLOADING_SUPPORT:BOOL=${_autoload} ") set(${var} ${_initial_cache} PARENT_SCOPE) if(_shared) set(CTEST_DASHBOARD_NAME "shared") else() set(CTEST_DASHBOARD_NAME "static") endif() if(_threading) set(CTEST_DASHBOARD_NAME "${CTEST_DASHBOARD_NAME}-threading") endif() if(_sf) set(CTEST_DASHBOARD_NAME "${CTEST_DASHBOARD_NAME}-servicefactory") endif() - if(_c++11) + if(_cxx11) set(CTEST_DASHBOARD_NAME "${CTEST_DASHBOARD_NAME}-cxx11") endif() if(_autoload) set(CTEST_DASHBOARD_NAME "${CTEST_DASHBOARD_NAME}-autoloading") endif() set(CTEST_DASHBOARD_NAME ${CTEST_DASHBOARD_NAME} PARENT_SCOPE) endfunction() #========================================================= set(CTEST_PROJECT_NAME CppMicroServices) if(NOT CTEST_PARALLEL_LEVEL) set(CTEST_PARALLEL_LEVEL 1) endif() # SHARED THREADING SERVICE_FACTORY C++11 AUTOLOAD set(config0 0 0 0 0 0 ) set(config1 0 0 0 0 1 ) set(config2 0 0 0 1 0 ) set(config3 0 0 0 1 1 ) set(config4 0 0 1 0 0 ) set(config5 0 0 1 0 1 ) set(config6 0 0 1 1 0 ) set(config7 0 0 1 1 1 ) set(config8 0 1 0 0 0 ) set(config9 0 1 0 0 1 ) set(config10 0 1 0 1 0 ) set(config11 0 1 0 1 1 ) set(config12 0 1 1 0 0 ) set(config13 0 1 1 0 1 ) set(config14 0 1 1 1 0 ) set(config15 0 1 1 1 1 ) set(config16 1 0 0 0 0 ) set(config17 1 0 0 0 1 ) set(config18 1 0 0 1 0 ) set(config19 1 0 0 1 1 ) set(config20 1 0 1 0 0 ) set(config21 1 0 1 0 1 ) set(config22 1 0 1 1 0 ) set(config23 1 0 1 1 1 ) set(config24 1 1 0 0 0 ) set(config25 1 1 0 0 1 ) set(config26 1 1 0 1 0 ) set(config27 1 1 0 1 1 ) set(config28 1 1 1 0 0 ) set(config29 1 1 1 0 1 ) set(config30 1 1 1 1 0 ) set(config31 1 1 1 1 1 ) foreach(i ${US_BUILD_CONFIGURATION}) create_initial_cache(CTEST_INITIAL_CACHE ${config${i}}) message("Testing build configuration: ${CTEST_DASHBOARD_NAME}") build_and_test() endforeach() diff --git a/Core/Documentation/Doxygen/Concepts/Concepts.dox b/Core/Documentation/Doxygen/Concepts/Concepts.dox index 2665de8898..b435bffaa9 100644 --- a/Core/Documentation/Doxygen/Concepts/Concepts.dox +++ b/Core/Documentation/Doxygen/Concepts/Concepts.dox @@ -1,32 +1,29 @@ /** \page Concepts MITK Concepts The following items describe some issues about MITK on a more abstract level. -# \subpage OverviewPage -# \subpage CodingPage "Coding Concepts" -# \ref CodingPageGeneral -# \ref CodingPageStyle -# \ref CodingPageMITKMacros -# \subpage MicroServices_Overview -# Data Concepts -# \subpage DataManagementPage -# \subpage MitkImagePage -# \subpage PropertiesPage -# \subpage GeometryOverviewPage -# \subpage PipelineingConceptPage -# \subpage QVTKRendering -# Interaction -# \subpage DataInteractionPage -# \subpage InteractionPage -# \subpage LoggingPage -# \subpage ExceptionPage --# Testing Concept - -# \subpage GeneralTests - -# \subpage RenderingTests -# \subpage ModularizationPage "Modularization Concept" -# \ref ModularizationPageOverview -# \ref ModularizationPageHowTo If you want to start using MITK, you also want to see the chapter \ref Development. */ diff --git a/Core/Documentation/Doxygen/Concepts/DataInteraction.dox b/Core/Documentation/Doxygen/Concepts/DataInteraction.dox index 46adae02d9..ffe736f286 100644 --- a/Core/Documentation/Doxygen/Concepts/DataInteraction.dox +++ b/Core/Documentation/Doxygen/Concepts/DataInteraction.dox @@ -1,204 +1,204 @@ /** \page DataInteractionPage Interaction Concepts \tableofcontents \section InteractionPage_Introduction Introduction to Interaction in MITK Interaction is a very important task in medical image processing software. Therefore MITK provides a special interaction concept that provides the developer with an easy way to develop and maintain user interaction separately from the algorithms processing the input. This allows e.g. for common interaction schemes to be re-used in different contexts. The core of the interaction concept is based on entities called \b DataInteractors that listen for certain pre-defined events and execute actions when such an event is triggered.\n In the following the different components of the interaction concept are explained. First a a high-level overview about how the different components interact is given, then some parts are explained in more detail. \subsection FurtherReadingInteraction Topics related to interaction - further information: See the \ref DataInteractionTechnicalPage page for a more technical explanation. \n Consult \ref HowToUseDataInteractor for usage information.\n See \ref SectionImplementationDataInteractor for an example on how to implement a new DataInteractor \n for information about how to create new events refer to ImplementNewEventsPage.\n The documentation of the depricated former concept can be found at \ref InteractionPage. \section HandlingSection Event Handling & Window Manager Abstraction The following sequence diagram gives an examplary overview of the process from creating an event until executing an action in the DataInteractor. This diagram assumes the usage of the Qt framework, but also shows that the interaction concept itself is implemented independent of any specific window manager. \image html event_handling.png
  1. a user event is triggered and send to MITK
  2. this layler serves as an adapter from window manager (here Qt) events to MITK internal events (later refered to as InteractionEvents).
  3. once the event is adapted it is send to a Dispatcher, which is linked to a render window, to be handled.
  4. on Dispatcher level all objects are known that can react to incoming events (DataInteractors)
  5. a DataInteractor is offered an event and checks its EventConfig object, which returns if a variant if this event has been defined for this DataInteractor.
  6. if the DataInteractor has a variant for the event, it consults its state machine to check if the input can be handled in the current state
  7. the actions asociated with a state change (transition) are executed and the event is successfully handled.
\section EventPage Events Events can describe any sort of user input, such as key strokes, mouse clicks or touch gestures. These events are mapped from an UI framework like Qt to an MITK internal representation and send to the Dispatcher which in turn deals with further processing of the event. These events are not limited to classical input devices but can be extened at will, by introducing new classes which e.g. describe -events from tracking devices, etc. Refer to \ref ImplementNewEventsPage to see how new events and thereby input devices can be integrated. -For an overview of available Events see mitk::InteractionEvent, for on overview of parameters see the \ref DataInteractionTechnicalPage. +events from tracking devices, etc. Refer to \subpage ImplementNewEventsPage to see how new events and thereby input devices can be integrated. +For an overview of available Events see mitk::InteractionEvent, for on overview of parameters see the \subpage DataInteractionTechnicalPage. \section EventHandlerSection EventHandler Is the term describing objects in general that can handle events. These objects can be devided into two groups, namely DataInteractors and EventObserver. Their difference is that DataInteractors are linked with a DataNode which they manipulate, whereas EventObserver do not have a DataNode and therefore are not supposed to manipulate any data. \dot digraph linker_deps { node [shape=record, fontname=Helvetica, fontsize=10]; a [ label="EventHandler" ]; d [ label="{StateMachine|HandleEvent()}" ]; b [ label="{DataInteractor|HandleEvent()}" ]; c [ label="{EventObserver|Notify()}" ]; a -> d; d -> b; d -> c; } \enddot \subsection DataInteractorsSection DataInteractors DataInteractors are specialized EventHandler which handle events for one spefific DataNode. They are implemented following a concept called state machines (see e.g. Wikipedia ). \subsubsection StateMachinesSection StateMachines A specific events action is usually desired to dependent on the content of the data object the state of the interaction. For example if the when adding a line by clicking with the mouse, the first to clicks are supposed to add a point. But the second click should additionally finish the interaction and a subsequent third click should be ignored. State machines provide a great way to model such interaction in which the same user interaction can trigger different actions depending on the current state. Therefore DataInteractors work with so called state machine patterns. The basic idea here is that each interaction can be described by states and transitions which in turn trigger actions. These patterns define a workflow and different patterns can be applied to the same DataInteractor and cause this DataInteractor to perform different user interactions. This principle is best described by an example. Imagine a DataInteractor with the functionality (1) to add Points at a given mouse position and connect them by a line and (2) check if two points are on the same position. Using this DataInteractor, different StateMachine patterns/descriptions can be given which each cause the DataInteractor to perform different interaction schemes. State machine pattern 1: We want the user to draw a line. A simple state machine could express this by three states like this: \dot digraph linker_deps { node [shape=circle, fontname=Helvetica, fontsize=10]; a [ label="NoPoints" ]; b [ label="OnePoint" ]; c [ label="TwoPoints" ]; a -> b [label="MousePress/AddPoint",fontname=Helvetica, fontsize=10]; b -> c [label="MousePress/AddPoint",fontname=Helvetica, fontsize=10]; { rank=same; a b c } } \enddot With each MousePress event the AddPoint function is called and adds a point at the mouse position, unless two points already exist. State machine pattern 2: The same DataInteractor can also operate after the following state machine, which models the interaction to input a closed contour. The DataInteractor can detect an AddPoint event on an already existing point and will trigger a PointsMatch event. \dot digraph { node [shape=circle, fontname=Helvetica, fontsize=10]; a [ label="StartState" ]; b [ label="ClosedContour"]; a -> a [label="MousePress/AddPoint",fontname=Helvetica, fontsize=10]; a -> b [label="PointsMatch/AddPoint",fontname=Helvetica, fontsize=10]; } \enddot In this way state machines provide both, a nice and structured way to represent interaction tasks and description of the interaction which is separated from the code. One DataInteractor can be re-used for different tasks by simply exchanging the state machine pattern. These patterns are described in XML files. \subsubsection DefinitionStateMachine Definition of a State Machine The definition is made up out of three components. Each state machine needs exactly one designated start state into which the state machine is set in the beginning. An example of a state machine describing the interaction of example 2 looks like this: \code \endcode Example 1: State machine pattern, that describes adding points to a contour until the PointsMatch event is triggered. For a more detailed desciption of state machine patterns see here. \subsection EventObserverSection EventObserver EventObserver are objects which will receive all user input and are intented for observation only, they should never modify any DataNodes. For EventObserver it is optional to use the state machine functionality, the default is without. How to use the state machine functionality is described in the documentation of mitk::EventObserver::Notify. \subsection ConfigurationSection Configuration In a lot of cases it is preferable to implement interactions independent of a specific event (e.g. left click with mouse), such that is it possible to easily change this. This is achieved through configuration of EventHandlers. This allows to change the behavior at runtime. The EventHandler provides an interface to easily modify the user input that triggers an action by loading a different configuration, this allows to implement user-specific behavior of the software on an abstract level and to switch in at runtime. This is achieved through XML files describing a configuration. These files can be loaded by the EventHandler and will lead to an internal mapping from specific user input to an absract description of the event given in the config file. In order to do this we distinguish between a spefic event and an event variant. A specific event is described by its event class, which determines the category of an event, e.g. the class MousePressEvent, and its parameter which make this event unique, e.g. LeftMouseButton pressed and no modifier keys pressed. The event variant is a name that is assigned to a spefific event, and to which an EventHandler listens. To illustrate this, an example is given here for two different configuration files. We assume an EventHandler that listens to the event variant 'AddPoint', two possible config files could then look like this: \code \endcode Example 2: Event description of a left click with the mouse and \code \endcode Example 3: Event description of a left click with the mouse while pressing the shift-key If the EventHandler is loaded with the first configuration the event variant 'MousePress' is triggered when the user performs a mouse click, while when the second configuration is loaded 'MousePress' is triggered when the user performs a right click while pressing the shift button. In this way all objects derived by EventHandler can be configured. For a detailed description about how to create the XML file see \ref ConfigurationTechnical . \section DispatcherSection Dispatcher This unit receives all events and distributes them to the DataInteractors. This is done by ordering the DataInteractors according to the layer of their DataNode in descending order. Then the event is offered to the first DataInteractor, which in turn checks if it can handle the event. This is done for each DataInteractor until the first processes the event, after this the other DataInteractors are skipped and all EventObservers are notified. */ diff --git a/Documentation/Doxygen/Modules/CMakeLists.txt b/Documentation/Doxygen/API/Groups/CMakeLists.txt similarity index 100% rename from Documentation/Doxygen/Modules/CMakeLists.txt rename to Documentation/Doxygen/API/Groups/CMakeLists.txt diff --git a/Documentation/Doxygen/Modules/ModuleAdaptors.dox b/Documentation/Doxygen/API/Groups/ModuleAdaptors.dox similarity index 99% rename from Documentation/Doxygen/Modules/ModuleAdaptors.dox rename to Documentation/Doxygen/API/Groups/ModuleAdaptors.dox index c00107bc16..87c36285cf 100644 --- a/Documentation/Doxygen/Modules/ModuleAdaptors.dox +++ b/Documentation/Doxygen/API/Groups/ModuleAdaptors.dox @@ -1,142 +1,142 @@ namespace mitk { /** \defgroup Adaptor Adaptor Classes \ingroup ProcessAdaptor -\brief This subcategory includes adaptor classes for the integration of algorithms from +\brief This subcategory includes adaptor classes for the integration of algorithms from other toolkits, especially ITK. The task of most of the classes in this category is to deal with the conversion between the (templated) itk::Image and the (not-templated) mitk::Image. Methods for conversion are provided for both directions: \li \ref MitkToItk \li \ref ItkToMitk Care has to be taken regarding the involved coordinate systems, see \ref ItkToMitkCoordinateSystems. For limitations on ITK-type conversion see the section \ref ModuleAdaptorLimitations. VTK-based access to MITK images is straightforward: simply ask your mitk::Image for a -\a vtkImageData by calling Image:GetVtkImageData. Similarily, to get a \a vtkPolyData +\a vtkImageData by calling Image:GetVtkImageData. Similarily, to get a \a vtkPolyData from the MITK class for storing surfaces, mitk::Surface, call Surface::GetVtkPolyData. \section MitkToItk MITK to ITK adaptors Pixel type and dimension of MITK images can be specified at run time whereas ITK images are templated over the pixel type and the dimension, thus in ITK both need to be specified at compile time. There two different situations, which are covered in the following sub-sections: \li Either you know the pixel type/dimension the ITK image should have at compile time for some reason (e.g., you always create MITK images of a specific pixel type/dimension) \li or the pixel type/dimension of an MITK image is really unkown and the ITK image should have the same (unkown) type. \subsection MitkToFixedItk Converting MITK images to ITK images with known type If you know the type (pixel type and dimension) of the MITK image you have two options: \li mitk::ImageToItk: is a process class that takes an mitk::Image as input and produces an itk::Image of the given type \a TOutputImage as output (to be accessed using \a GetOutput()). In case the MITK image does not have the same type as \a TOutputImage an exception will be thrown. \li mitk::CastToItkImage: this function has two parameters, the mitk::Image (input) and a smartpointer to an itk::Image (output, does not need to be initialized). In case the - MITK image does not have the same type as the ITK image it will be casted + MITK image does not have the same type as the ITK image it will be casted (if possible; done via itk::CastImageFilter). Thus, mitk::CastToItkImage is the more powerful variant: here it is sufficient that you know what you want to have (the ITK data type), to which the MITK image will be casted, if needed. \subsection MitkToUnkownItk Accessing an MITK image as an ITK image (type unkown) If you do not know the pixel type/dimension of an MITK image in advance and the ITK image should have the same (unkown) type, e.g., to run a filter on the MITK image data, we cannot really convert to one ITK image. This is simply, because we cannot instantiate an itk::Image object with unkown pixel type/dimension. Nevertheless, MITK provides a way to access an MITK image as if it was an ITK image of unkown type. 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, we need to refer you to an 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 (or one of its variants) from mitkImageAccessByItk.h. This macro checks for the actual image type of the mitk::Image and does any neccessary conversions. This works for all configured pixel types (default is char, unsigned char, short, unsigned short, int, unsigned int, float, and double) and dimensions (default is 2 and 3). You can change the considered default pixel types and dimensions by modifying the CMake variables MITK_ACCESSBYITK_*. \code AccessByItk(mitkImage, MyAccessMethod) \endcode An example is given in \ref Step6Page. The AccessBy... macros create quite a lot of code: the user defined access method has to be compiled for all considered pixel types \em times the supported dimensions (default is 2 and 3). Therefore, depending on the complexity of the access method, some compilers may run into problems with memory. One workaround is to use explicit instantiation and distribute it on multiple files. The macro #InstantiateAccessFunction and its variants are for this purpose. An example is again given in \ref Step6Page. Another workaround is to reduce the created code by fixing either the type (#AccessFixedTypeByItk) or dimension (#AccessFixedDimensionByItk). There is one variant of AccessByItk... for passing additional parameters to the access-function, called #AccessFixedTypeByItk_n. \link mitkImage.h \endlink \link mitkImageCast.h \endlink \link mitkImageToItk.h \endlink \link mitkITKImageImport.h \endlink \section ItkToMitk ITK to MITK adaptors Converting ITK images to MITK is easier than the other way round. Basically, you have three options: \li mitk::ITKImageImport: is a process class that takes an itk::Image of the given type \a TOutputImage as input and produces an mitk::Image as output (to be accessed using \a GetOutput()). The image data contained in the itk::Image is referenced, not copied. \li mitk::ImportItkImage: this function takes the itk::Image as input and returns an mitk::Image. Internally, it uses the class just described. So again, the image data contained in the itk::Image is referenced, not copied. \li mitk::CastToMitkImage: this function has two parameters, the itk::Image (input) and a smartpointer to an mitk::Image (output, does not need to be initialized). In contrast to the other described methods, this function copies the image data! \section ItkToMitkCoordinateSystems ITK image vs MITK coordinate systems Converting coordinates from the ITK physical coordinate system (which does not support rotated images) to the MITK world coordinate system should be performed via the Geometry3D of the Image, see mitk::Geometry3D::WorldToItkPhysicalPoint. \section ModuleAdaptorLimitations Limitations The \ref MitkToItk for unspecified types have to do type multiplexing at compile time. This is done for a limited number of pixel types and dimensions, defined during the CMake configuration process. Especially, color image types are not multiplexed. This is because many algorithms do not support color images (e.g. with data type itk::RGBPixel) because they do not have a scalar data type. If your algorithm do support color and you want to multiplex over all scalar as well as the color data type, try the following: \code try { AccessFixedPixelTypeByItk(myMitkImageThatMaybeColor, // The MITK image which may be a color image myAlgorithmFunction, // The template method being able to handle color MITK_ACCESSBYITK_PIXEL_TYPES_SEQ // The default pixel type sequence (itk::RGBPixel) // The additional type sequence ) } catch(const mitk::AccessByItkException& e) { // add error handling here } \endcode */ } diff --git a/Documentation/Doxygen/Modules/ModuleGeometry.dox b/Documentation/Doxygen/API/Groups/ModuleGeometry.dox similarity index 97% rename from Documentation/Doxygen/Modules/ModuleGeometry.dox rename to Documentation/Doxygen/API/Groups/ModuleGeometry.dox index 212dd043a4..aa6ca16d8f 100644 --- a/Documentation/Doxygen/Modules/ModuleGeometry.dox +++ b/Documentation/Doxygen/API/Groups/ModuleGeometry.dox @@ -1,47 +1,47 @@ namespace mitk { /** \defgroup Geometry Geometry Classes \ingroup DataManagement -\brief This subcategory includes the geometry classes, which describe the geometry of the +\brief This subcategory includes the geometry classes, which describe the geometry of the data in space and time. The Geometry3D class holds (see figure) \li a bounding box which is axes-parallel in intrinsic coordinates (often integer indices of pixels), to be accessed by Geometry3D::GetBoundingBox() \li a transform to convert intrinsic coordinates into a world-coordinate system with coordinates in millimeters and milliseconds (floating point values), to be accessed by Geometry3D::GetIndexToWorldTransform() \li a life span, i.e. a bounding box in time in ms (with start and end time), to be accessed by Geometry3D::GetTimeBounds(). The default is minus infinity to plus infinity. \image html ModuleGeometryFig1.png "Geometry: Bounding box and transform" Geometry3D and its sub-classes allow converting between intrinsic coordinates (called index or unit coordinates) and word-coordinates (called world or mm coordinates), e.g. Geometry3D::WorldToIndex. Every data object (sub-)class of BaseData has a Geometry3D, to be more specific, a TimeSlicedGeometry, to be accessed by BaseData::Get TimeSlicedGeometry(). This is because data objects are objects in space and time. The data values are often stored in intrinsic coordinates, e.g., integer pixel/voxel or time indices. The information required to convert these intrinsic coordinates into a physical world coordinate system, with coordinates in millimeters and milliseconds, is stored in Geometry3D class and its sub-classes. -TimeSlicedGeometry describes a geometry consisting of several geometries which exist at different times. It contains a list of Geometry3D instances to be accessed by TimeSlicedGeometry::GetGeometry3D(t), with t between 0 and TimeSlicedGeometry::GetTimeSteps().To convert between world-time in milliseconds and the integer timestep-number use mitk:TimeSlicedGeometry:: MSToTimeStep, for conversion in the opposite direction mitk:TimeSlicedGeometry:: TimeStepToMS. +TimeSlicedGeometry describes a geometry consisting of several geometries which exist at different times. It contains a list of Geometry3D instances to be accessed by TimeSlicedGeometry::GetGeometry3D(t), with t between 0 and TimeSlicedGeometry::GetTimeSteps().To convert between world-time in milliseconds and the integer timestep-number use mitk:TimeSlicedGeometry:: MSToTimeStep, for conversion in the opposite direction mitk:TimeSlicedGeometry:: TimeStepToMS. Often all Geometry3D instances contained in a TimeSlicedGeometry have the same duration of life. 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 live immediately at the end of life of the first. The bounding boxes and transformations are copied. 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. Its life span (to be accessed by TimeSlicedGeometry::GetTimeBounds()) is the span from the beginning of the first contained Geometry3D to the end of the last contained Geometry3D. +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. Its life span (to be accessed by TimeSlicedGeometry::GetTimeBounds()) is the span from the beginning of the first contained Geometry3D to the end of the last contained Geometry3D. TimeSlicedGeometry can also contain Geometry3D instances that do not have the same bounding box and transformation. In this case, TimeSlicedGeometry::GetEvenlyTimed() has to be \a false. SlicedGeometry3D is a sub-class of Geometry3D, which descibes data objects consisting of slices, e.g., objects of type Image (or SlicedData, which is the super-class of Image). Therefore, Image::Get TimeSlicedGeometry() will contain a list of SlicedGeometry3D instances. There is a special method SlicedData::GetSlicedGeometry(t) which directly returns a SlicedGeometry3D to avoid the need of casting. Geometry instances referring to images need a slightly different definition of corners, see Geometry3D::SetImageGeometry. This is usualy automatically called by Image. -Comparable to TimeSlicedGeometry the class SlicedGeometry3D contains a list of Geometry2D objects describing the slices in the data object. 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. +Comparable to TimeSlicedGeometry the class SlicedGeometry3D contains a list of Geometry2D objects describing the slices in the data object. 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. For example it allows mapping a 3D point on the 2D manifold using Geometry2D::Map. The most important sub-class is PlaneGeometry2D, which describes a planar rectangle. \section ExampleForImage Putting it together for Image Image has a 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 PlaneGeometry2D). \deprecated For ITK rev. 3.8 and earlier: Converting coordinates from the ITK physical coordinate system (which did not support rotated images for ITK v3.8 and earlier) to the MITK world coordinate system should be performed via the Geometry3D of the Image, see Geometry3D::WorldToItkPhysicalPoint. As a reminder: Geometry instances referring to images need a slightly different definition of corners, see Geometry3D::SetImageGeometry. This is usualy automatically called by Image. */ //\f$-\infty\f$ to \f$+\infty\f$. } diff --git a/Documentation/Doxygen/Modules/ModuleGeometryFig1.png b/Documentation/Doxygen/API/Groups/ModuleGeometryFig1.png similarity index 100% rename from Documentation/Doxygen/Modules/ModuleGeometryFig1.png rename to Documentation/Doxygen/API/Groups/ModuleGeometryFig1.png diff --git a/Documentation/Doxygen/Modules/ModuleMicroServices.dox b/Documentation/Doxygen/API/Groups/ModuleMicroServices.dox similarity index 99% rename from Documentation/Doxygen/Modules/ModuleMicroServices.dox rename to Documentation/Doxygen/API/Groups/ModuleMicroServices.dox index e3e6869d38..0e5d618203 100644 --- a/Documentation/Doxygen/Modules/ModuleMicroServices.dox +++ b/Documentation/Doxygen/API/Groups/ModuleMicroServices.dox @@ -1,30 +1,29 @@ /** \addtogroup MicroServices \ingroup Core */ /** \addtogroup MicroServicesUtils \ingroup Core */ /** \defgroup MicroServices_Interfaces Micro Services Interfaces \ingroup Core \brief Classes (interfaces) in this category are explicitely designed for usage with the MITK Micro Services. All classes in this category are structs with no non-static members and only pure virtual functions (except for an inlined virtual destructor). Such a class will be called a \e interface. These interfaces are meant to be implemented by MITK module developers to enhance or overwrite certain aspects of the MITK toolkit. All implementations must be registered in the implementing module's \e activator (see mitk::ModuleActivator) using the module's mitk::ModuleContext instance. */ - diff --git a/Documentation/Doxygen/Modules/ModuleVisualization.dox b/Documentation/Doxygen/API/Groups/ModuleVisualization.dox similarity index 80% rename from Documentation/Doxygen/Modules/ModuleVisualization.dox rename to Documentation/Doxygen/API/Groups/ModuleVisualization.dox index b63b43f940..72fb312d85 100644 --- a/Documentation/Doxygen/Modules/ModuleVisualization.dox +++ b/Documentation/Doxygen/API/Groups/ModuleVisualization.dox @@ -1,45 +1,45 @@ /** \defgroup Visualization Visualization and Visualization Organization Classes \ingroup Core -\brief This category includes renderwindows (currently one for OpenGL), renderers (currently only one, +\brief This category includes renderwindows (currently one for OpenGL), renderers (currently only one, for OpenGL-based renderwindows), mappers and classes for navigating in the data. \section overviewVisualization Rationale and overview -Mappers visualize data objects of a specific classes by creating rendering primitives that -interface to the graphics library (e.g., OpenGL, vtk). -Renderers organize the rendering process. A Renderer contains a reference to a (sub-) data tree +Mappers visualize data objects of a specific classes by creating rendering primitives that +interface to the graphics library (e.g., OpenGL, vtk). +Renderers organize the rendering process. A Renderer contains a reference to a (sub-) data tree and asks the mappers of the data objects to render the data into the renderwindow it is associated to. -More details can be found in the section on \ref Rendering. +More details can be found in the section on \ref Rendering. -\subsection inthisgroupVisualization What belongs into this group +\subsection inthisgroupVisualization What belongs into this group \section implementVisualization Practical issues -\section futureVisualization Plans for the future +\section futureVisualization Plans for the future - Abort mechanism - level-of-detail rendering mechanism - allow multiple renderers per renderwindow -- modified detection mechanism: +- modified detection mechanism: - allow to detect whether a modification of data/property/dislaygeometry /camera requires to re-render. E.g., mark whether a property effects the rendering. - analyze which type of modification requires which kind of action, e.g.: - if the displaygeometry or the color has changed, we do not need to - resample an image, but we do need to redraw. The first step is to + if the displaygeometry or the color has changed, we do not need to + resample an image, but we do need to redraw. The first step is to analyze which types of modifications (e.g., displaygeometry changed, properties changed; can we group these?) and actions exist. -- improved design of navigation controllers, probably more focused on +- improved design of navigation controllers, probably more focused on steppers (then on BaseController). Have in mind: - rotatable slices - - dependent views: e.g., sequence of renderers showing series of - consecutive slices (maybe realized as master stepper and + - dependent views: e.g., sequence of renderers showing series of + consecutive slices (maybe realized as master stepper and dependent offset steppers) - consider time vs. slice stepping - use stepper mechanism for additional purposes, e.g., for animating transfer functions */ diff --git a/Documentation/Doxygen/Modules/ModuleVisualizationMapper.dox b/Documentation/Doxygen/API/Groups/ModuleVisualizationMapper.dox similarity index 98% rename from Documentation/Doxygen/Modules/ModuleVisualizationMapper.dox rename to Documentation/Doxygen/API/Groups/ModuleVisualizationMapper.dox index a7a9dc1a2f..8f6a285c77 100644 --- a/Documentation/Doxygen/Modules/ModuleVisualizationMapper.dox +++ b/Documentation/Doxygen/API/Groups/ModuleVisualizationMapper.dox @@ -1,25 +1,25 @@ /** \defgroup Mapper Mapper Classes \ingroup Visualization \brief In the MITK rendering concept, Mappers are responsible for actually rendering data onto the screen. \section overviewVisualizationMapper Overview Mappers differ in the type of data they are capable of rendering (e.g. volume data, polygonal data) and the mode of how data is rendered (e.g. 2D or 3D). For example, the ImageMapperGL2D renders volume data in a 2D view, i.e. it extracts a slice of the volume (as determined by the Geometry of the associated Renderer) and displays it as a 2D plane. All Mapper classes are arranged in a class hierarchy according to these criterions. \section integrationVisualizationMapper Integration into the rendering process Mapper objects are owned by the DataNode which contains the data they have to render. An overview over this composition is given in the section \ref Renderer. Each DataNode can have (and usually has) multiple Mappers attached, each responsible for different modes of rendering. In most cases this would be one 2D Mapper and one 3D Mapper, but other Mappers are possible, too. -Which Mapper of a DataNode to use is determined by an ID; the Renderer of a 2D window would for example ask the DataNode to return an appropriate 2D Mapper. +Which Mapper of a DataNode to use is determined by an ID; the Renderer of a 2D window would for example ask the DataNode to return an appropriate 2D Mapper. More details can be found in the section on \ref Rendering. \section todoVisualizationMapper Future plans The need to Update() a Mapper can be justified by property changes in the associated data items. However, property changes are not uniformly taken into account when deciding on whether to execute Update() or not. The changes are data specific and difficult to generalize. As an effect, many Update() calls are not really necessary and might slow down the rendering process significantly. One solution to this problem might be a mechanism which allows Mappers to register themselves to relevant data properties, so as to be notified whenever a change occurs. If no modification did occur since the last Update(), and the data itself has remained unchanged, no re-initialization (of the rendering pipeline for example) needs to be performed. */ diff --git a/Documentation/Doxygen/Modules/ModuleVisualizationNavigationControl.dox b/Documentation/Doxygen/API/Groups/ModuleVisualizationNavigationControl.dox similarity index 87% rename from Documentation/Doxygen/Modules/ModuleVisualizationNavigationControl.dox rename to Documentation/Doxygen/API/Groups/ModuleVisualizationNavigationControl.dox index 8543bfbee3..5e6a5b828a 100644 --- a/Documentation/Doxygen/Modules/ModuleVisualizationNavigationControl.dox +++ b/Documentation/Doxygen/API/Groups/ModuleVisualizationNavigationControl.dox @@ -1,15 +1,15 @@ /** \defgroup NavigationControl Navigation Control Classes \ingroup Visualization -\brief The classes in this category tell the render (subclass of mitk::BaseRenderer) which +\brief The classes in this category tell the render (subclass of mitk::BaseRenderer) which slice (subclass mitk::SliceNavigationController) or from which direction (subclass mitk::CameraController) it has to render. -Contains two Stepper for stepping through the slices or through different camera views (e.g., +Contains two Stepper for stepping through the slices or through different camera views (e.g., for the creation of a movie around the data), respectively, and through time, if there is 3D+t data. */ \ No newline at end of file diff --git a/Documentation/Doxygen/Modules/ModuleVisualizationRenderer.dox b/Documentation/Doxygen/API/Groups/ModuleVisualizationRenderer.dox similarity index 99% rename from Documentation/Doxygen/Modules/ModuleVisualizationRenderer.dox rename to Documentation/Doxygen/API/Groups/ModuleVisualizationRenderer.dox index ade1036bad..e1e2428197 100644 --- a/Documentation/Doxygen/Modules/ModuleVisualizationRenderer.dox +++ b/Documentation/Doxygen/API/Groups/ModuleVisualizationRenderer.dox @@ -1,42 +1,42 @@ /** \defgroup Renderer Renderer and RenderWindow Classes \ingroup Visualization \brief The MITK rendering model resembles the mechisms found in VTK. This section describes the core components for coordinating rendering processes and render windows. \section overviewVisualizationRenderer Overview To visualize a dataset it needs to be stored in the DataTree. Depending on the application, the whole DataTree may be displayed, or merely parts of it. The rendering of individual data items (e.g. volumes or polygon models) is conducted by specific Mappers: each kind of visualizable data has its own corresponding Mapper implementation (see \ref Mapper). MITK is designed to intrinsically provide different views on data. For example, a volume dataset is volume rendered in a 3D view, and displayed slice-wise in a 2D view. A polygon model would be displayed as a contour in 2D (i.e., the intersection of the 3D model and the respective 2D plane). This principle applies to all kinds of data, thereby ensuring a consistent visual representation regardless of the view type. It is realized by providing Mappers for each combination of data type and view type. Every item of the DataTree is associated with a list of Mappers, each capable of rendering the data item in a specific view. RenderWindows represent the rendering target: an area of the user interface into which data is rendered. The actual rendering process is controlled by Renderers, specifically by mitkVtkPropRenderer, which is a concrete implementation BaseRenderer and iterates over the elements of the DataTree to render each using the associated Mapper. Eeach data item of the DataTree has Geometry objects attached to it which describe the geometry of the data (e.g. its bounding box, location, or spatial conversion hints). \section vtkVisualizationRenderer Encapsulating VTK Rendering Mechanisms As a framework, MITK aims at making use of the visualization capabilities of VTK as much as possible. For the application developer building on top of MITK, the way of how to utilize specific VTK features should be straightforward and familiar. Therefore, most of the MITK rendering components closely resemble or integrate corresponding VTK components. Just like VTK, MITK defines Renderers and Mappers. These classes do not derive from their VTK counterparts, but integrate them and have similar scopes of responsibility. While the VTK rendering mechanism is mainly focused on establishing a pipeline of rendering components (data, filters, mappers, and renderers), MITK has a central DataTree and provides convenient ways of rendering different items of the tree according to their type. Internally, the VTK rendering pipeline is used, though it is more hidden from the application developer who merely makes use of existing rendering capabilities. As of MITK 0.8, the class vtkMitkRenderProp (a derivation of vtkProp) represents the single prop object in the VTK rendering pipeline responsible for coordinating the rendering of all objects in MITK's DataTree. The advantage of this approach is that all rendering management is done in the usual VTK rendering pipeline style, while the control of how data is actually rendered is entirely on MITK side. For example, MITK Mapper classes may either use VTK classes for rendering (actors, properties, ...), or do their rendering entirely in OpenGL where appropriate (e.g. in 2D Mapper classes). For further details refer to the page \ref Rendering. \section renderingManagerVisualizationRenderer Controlling it All: RenderingManager On a higher level, all rendering in MITK is managed and supervised by the RenderingManager. Its main task is to provide a central instance where any part of the application can request a repaint of a particular RenderWindow. Thereby, requests can be issued from multiple independent subroutines at one time, and only result in one repainting call, rather than induce many unnecessary rendering passes. Another task is the supervision of ongoing rendering activities. For large datasets, high quality rendering might become very slow and thus impede smooth user interactions. To alleviate this, level-of-detail rendering and abort-mechanisms are introduced and controlled by the RenderingManager to achieve interactive frame rate and response times. Note that these features are not yet available but currently under development. The rendering process could be further simplified by making the DataTree automatically detect data changes that require the data to be re-drawn. The fundamentals for such a mechanism already exist but still for many modifications a repainting request has to be issued by the entity causing it. \section implementationManagerVisualizationRenderer Platform-Specific Implementation -MITK tries to integrate seamlessly into the normal VTK rendering pipeline. The whole MITK data(tree) is capsuled into one customized vtkProp, the so-called vtkMitkRenderProp which is then integrated into VTK pipeline. +MITK tries to integrate seamlessly into the normal VTK rendering pipeline. The whole MITK data(tree) is capsuled into one customized vtkProp, the so-called vtkMitkRenderProp which is then integrated into VTK pipeline. The VTK integration into GUI systems, like e.g. QT, is therefore equal to normal VTK usage. As an example, the MITK MainApp requires the QT-VTK widget (provided by VTK) for integration of renderWindows into GUI. Further information on this can be found in section "Related Pages" "Rendering in MITK by means of the QT-VTK widget". */ \ No newline at end of file diff --git a/Documentation/Doxygen/Modules/Modules.dox b/Documentation/Doxygen/API/Groups/Modules.dox similarity index 100% rename from Documentation/Doxygen/Modules/Modules.dox rename to Documentation/Doxygen/API/Groups/Modules.dox diff --git a/Documentation/Doxygen/Modules/RenderingSequence.png b/Documentation/Doxygen/API/Groups/RenderingSequence.png similarity index 100% rename from Documentation/Doxygen/Modules/RenderingSequence.png rename to Documentation/Doxygen/API/Groups/RenderingSequence.png diff --git a/Documentation/Doxygen/Modules/RenderingSequence.vsd b/Documentation/Doxygen/API/Groups/RenderingSequence.vsd similarity index 100% rename from Documentation/Doxygen/Modules/RenderingSequence.vsd rename to Documentation/Doxygen/API/Groups/RenderingSequence.vsd diff --git a/Documentation/Doxygen/Modules/dialogbarSlicer.png b/Documentation/Doxygen/API/Groups/dialogbarSlicer.png similarity index 100% rename from Documentation/Doxygen/Modules/dialogbarSlicer.png rename to Documentation/Doxygen/API/Groups/dialogbarSlicer.png diff --git a/Documentation/Doxygen/Modules/dialogbarStandardViews.png b/Documentation/Doxygen/API/Groups/dialogbarStandardViews.png similarity index 100% rename from Documentation/Doxygen/Modules/dialogbarStandardViews.png rename to Documentation/Doxygen/API/Groups/dialogbarStandardViews.png diff --git a/Documentation/Doxygen/Modules/dialogbarStereoOptions.png b/Documentation/Doxygen/API/Groups/dialogbarStereoOptions.png similarity index 100% rename from Documentation/Doxygen/Modules/dialogbarStereoOptions.png rename to Documentation/Doxygen/API/Groups/dialogbarStereoOptions.png diff --git a/Documentation/Doxygen/Modules/dialogbarbuttons.png b/Documentation/Doxygen/API/Groups/dialogbarbuttons.png similarity index 100% rename from Documentation/Doxygen/Modules/dialogbarbuttons.png rename to Documentation/Doxygen/API/Groups/dialogbarbuttons.png diff --git a/Documentation/Doxygen/Modules/functionalityButtons.png b/Documentation/Doxygen/API/Groups/functionalityButtons.png similarity index 100% rename from Documentation/Doxygen/Modules/functionalityButtons.png rename to Documentation/Doxygen/API/Groups/functionalityButtons.png diff --git a/Documentation/Doxygen/Modules/renderwindowOptions.png b/Documentation/Doxygen/API/Groups/renderwindowOptions.png similarity index 100% rename from Documentation/Doxygen/Modules/renderwindowOptions.png rename to Documentation/Doxygen/API/Groups/renderwindowOptions.png diff --git a/Documentation/Doxygen/Modules/renderwindows.png b/Documentation/Doxygen/API/Groups/renderwindows.png similarity index 100% rename from Documentation/Doxygen/Modules/renderwindows.png rename to Documentation/Doxygen/API/Groups/renderwindows.png diff --git a/Documentation/Doxygen/Modules/undoredobutton.png b/Documentation/Doxygen/API/Groups/undoredobutton.png similarity index 100% rename from Documentation/Doxygen/Modules/undoredobutton.png rename to Documentation/Doxygen/API/Groups/undoredobutton.png diff --git a/Documentation/Doxygen/BlueBerry/BlueBerryExampleLauncherDialog.png b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExampleLauncherDialog.png similarity index 100% rename from Documentation/Doxygen/BlueBerry/BlueBerryExampleLauncherDialog.png rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExampleLauncherDialog.png diff --git a/Documentation/Doxygen/BlueBerry/BlueBerryExamples.dox b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExamples.dox similarity index 100% rename from Documentation/Doxygen/BlueBerry/BlueBerryExamples.dox rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExamples.dox diff --git a/Documentation/Doxygen/BlueBerry/BlueBerryExtensionPointsIntro.dox b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExtensionPointsIntro.dox similarity index 100% rename from Documentation/Doxygen/BlueBerry/BlueBerryExtensionPointsIntro.dox rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryExtensionPointsIntro.dox diff --git a/Documentation/Doxygen/BlueBerry/BlueBerryIntro.dox b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryIntro.dox similarity index 100% rename from Documentation/Doxygen/BlueBerry/BlueBerryIntro.dox rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerryIntro.dox diff --git a/Documentation/Doxygen/BlueBerry/BlueBerrySelectionServiceIntro.dox b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerrySelectionServiceIntro.dox similarity index 100% rename from Documentation/Doxygen/BlueBerry/BlueBerrySelectionServiceIntro.dox rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/BlueBerrySelectionServiceIntro.dox diff --git a/Documentation/Doxygen/BlueBerry/ExtensionPointEx.png b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/ExtensionPointEx.png similarity index 100% rename from Documentation/Doxygen/BlueBerry/ExtensionPointEx.png rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/ExtensionPointEx.png diff --git a/Documentation/Doxygen/BlueBerry/ExtensionPoints.png b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/ExtensionPoints.png similarity index 100% rename from Documentation/Doxygen/BlueBerry/ExtensionPoints.png rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/ExtensionPoints.png diff --git a/Documentation/Doxygen/BlueBerry/MitkSelectionService.png b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/MitkSelectionService.png similarity index 100% rename from Documentation/Doxygen/BlueBerry/MitkSelectionService.png rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/MitkSelectionService.png diff --git a/Documentation/Doxygen/BlueBerry/SelectionServiceDiagram.png b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/SelectionServiceDiagram.png similarity index 100% rename from Documentation/Doxygen/BlueBerry/SelectionServiceDiagram.png rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/SelectionServiceDiagram.png diff --git a/Documentation/Doxygen/BlueBerry/SelectionServiceDiagram.xcf b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/SelectionServiceDiagram.xcf similarity index 100% rename from Documentation/Doxygen/BlueBerry/SelectionServiceDiagram.xcf rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/SelectionServiceDiagram.xcf diff --git a/Documentation/Doxygen/BlueBerry/application-window.jpg b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/application-window.jpg similarity index 100% rename from Documentation/Doxygen/BlueBerry/application-window.jpg rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/application-window.jpg diff --git a/Documentation/Doxygen/BlueBerry/workbench-class-diagram.jpg b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-class-diagram.jpg similarity index 100% rename from Documentation/Doxygen/BlueBerry/workbench-class-diagram.jpg rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-class-diagram.jpg diff --git a/Documentation/Doxygen/BlueBerry/workbench-page.jpg b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-page.jpg similarity index 100% rename from Documentation/Doxygen/BlueBerry/workbench-page.jpg rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-page.jpg diff --git a/Documentation/Doxygen/BlueBerry/workbench-window-editor-area.png b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window-editor-area.png similarity index 100% rename from Documentation/Doxygen/BlueBerry/workbench-window-editor-area.png rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window-editor-area.png diff --git a/Documentation/Doxygen/BlueBerry/workbench-window-editor-area.xcf b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window-editor-area.xcf similarity index 100% rename from Documentation/Doxygen/BlueBerry/workbench-window-editor-area.xcf rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window-editor-area.xcf diff --git a/Documentation/Doxygen/BlueBerry/workbench-window-perspective.png b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window-perspective.png similarity index 100% rename from Documentation/Doxygen/BlueBerry/workbench-window-perspective.png rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window-perspective.png diff --git a/Documentation/Doxygen/BlueBerry/workbench-window-perspective.xcf b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window-perspective.xcf similarity index 100% rename from Documentation/Doxygen/BlueBerry/workbench-window-perspective.xcf rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window-perspective.xcf diff --git a/Documentation/Doxygen/BlueBerry/workbench-window-views.png b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window-views.png similarity index 100% rename from Documentation/Doxygen/BlueBerry/workbench-window-views.png rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window-views.png diff --git a/Documentation/Doxygen/BlueBerry/workbench-window-views.xcf b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window-views.xcf similarity index 100% rename from Documentation/Doxygen/BlueBerry/workbench-window-views.xcf rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window-views.xcf diff --git a/Documentation/Doxygen/BlueBerry/workbench-window.jpg b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window.jpg similarity index 100% rename from Documentation/Doxygen/BlueBerry/workbench-window.jpg rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench-window.jpg diff --git a/Documentation/Doxygen/BlueBerry/workbench.jpg b/Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench.jpg similarity index 100% rename from Documentation/Doxygen/BlueBerry/workbench.jpg rename to Documentation/Doxygen/DeveloperManual/Application/BlueBerry/workbench.jpg diff --git a/Documentation/Doxygen/DeveloperManual/Deployment.dox b/Documentation/Doxygen/DeveloperManual/Application/Deployment.dox similarity index 98% rename from Documentation/Doxygen/DeveloperManual/Deployment.dox rename to Documentation/Doxygen/DeveloperManual/Application/Deployment.dox index ea81e022c7..71408502a3 100644 --- a/Documentation/Doxygen/DeveloperManual/Deployment.dox +++ b/Documentation/Doxygen/DeveloperManual/Application/Deployment.dox @@ -1,46 +1,46 @@ /** -\page DeploymentPage Deployment +\page DeploymentPage Deploying MITK \section DeploymentPageIntroduction Introduction
  • easily create portable or installable versions of your MITK-based applications.
  • created packages include all MITK and 3rd party libraries necessary for running the application on other systems
  • distribute your binary application to other people without giving them your source code or putting them in the need for setting up a development environment themselves, eg for evaluation of your tool.
\note This does not install the MITK headers (like an SDK). If you want to develop applications based on MITK you still have to compile MITK yourself. \section DeploymentPagePlatform Platform specific notes \subsection DeploymentPagePlatformLinux Linux You can create a tarball (.tar.gz) of your MITK application which includes all necessary non-system libraries by following these steps:
  • Set the %CMake Variable CMAKE_BUILD_TYPE to either "Debug" or "Release". Any other type (or leaving the variable empty) will not work.
  • If you are using third-pary libraries not shipped with MITK, you might need to add the paths to the third-party libs to your LD_LIBRARY_PATH environment variable (not necessary if you use RPATH in your shared libraries).
  • Type "make package" in your build-tree. This will create a tarball in your build-tree directory.
\note Libraries in system locations (/lib/, /lib32/, /lib64/, /usr/lib/, /usr/lib32/,/usr/lib64/, and /usr/X11R6/) will not be included in the tarball. If you want to distribute Qt (for example), you have to do a custom Qt installation outside of these directories. \subsection DeploymentPagePlatformWindows Windows You can create a Zip file (.zip) or an NSIS installer (needs an installation of NSIS) for Windows platforms. Only "Release" builds are supported during packaging, the results of trying to package "Debug" builds are undefined. \note Building installers based on MinGW is not supported.
  • In Visual Studio, build the "PACKAGE" project, this will create a .zip file and a .exe NSIS installer (if NSIS is installed).
On some systems, it might still be necessary to install the Microsoft Visual C++ Redistributable Package to start the installed application successfully. \subsection DeploymentPagePlatformMacOS MacOS You can create a drag'n drop disk image (.dmg) file for MacOS. The procedure is pretty much the same as for Linux. \note On MacOS, libraries in system locations as pointed out in the Linux section \b and libraries located in /System/Library will not be copied. If you want to distribute any libraries from these locations, you have to install them somewhere else prior to configuring your MITK build. */ \ No newline at end of file diff --git a/Documentation/Doxygen/DeveloperManual/Application/DevelopmentApplication.dox b/Documentation/Doxygen/DeveloperManual/Application/DevelopmentApplication.dox new file mode 100644 index 0000000000..1bcb321658 --- /dev/null +++ b/Documentation/Doxygen/DeveloperManual/Application/DevelopmentApplication.dox @@ -0,0 +1,16 @@ +/** + +\page DevelopmentApplication Developing with the MITK Application Framework + +MITK offers a powerful application featuring a plugin system and many predefined plugins. You can configure this application to offer a set of functionality to the user and easily create an installer. +Working with the application, you will have to learn about extension points and the Blueberry framework itself. If you are new to the matter, please also consult \ref Architecture and \ref FirstSteps. + +
    +
  • \subpage BlueBerryIntro
    • +
  • \subpage BlueBerryExamples
    • +
  • \subpage mitkExtPointsIndex
    • +
  • \subpage DeploymentPage
    • +
+ + +*/ diff --git a/Core/Documentation/Doxygen/extension-points/mitkExtPointsIndex.dox b/Documentation/Doxygen/DeveloperManual/Application/ExtensionPointReference.dox similarity index 100% rename from Core/Documentation/Doxygen/extension-points/mitkExtPointsIndex.dox rename to Documentation/Doxygen/DeveloperManual/Application/ExtensionPointReference.dox diff --git a/Documentation/Doxygen/DeveloperManual/DeveloperManualPortal.dox b/Documentation/Doxygen/DeveloperManual/DeveloperManualPortal.dox new file mode 100644 index 0000000000..ec44916cba --- /dev/null +++ b/Documentation/Doxygen/DeveloperManual/DeveloperManualPortal.dox @@ -0,0 +1,33 @@ +/** +\page DeveloperManualPortal MITK: Developer Manual + +Development with MITK can happen under several disctinct conditions. Depending on whether you are using the Toolkit or the entire application, different sections may apply to you. In case you are unsure about what you need, please refer to \link Architecture The Architecture of MITK text\endlink. An extensive Introduction to MITK is available under \link StartingDevelopment Starting your MITK Development\endlink. + +Depending on whether you are working with the \link DevelopmentToolkit Toolkit\endlink or the \link DevelopmentApplication Application\endlink, you can refer to their respective pages. Generated API-Documentation can be found \link DevelopmentAPI here\endlink. + +\section DeveloperManualStarting Starting your MITK Development + +
    +
  • \subpage StartingDevelopment
    • +
      +
    • \ref Architecture
      • +
    • \ref SettingUpMITK
      • +
    • \ref GettingToKnowMITK
      • +
    • \ref FirstSteps
      • +
    • \ref AboutTestingPage
      • +
    +
  • \subpage DevelopmentToolkit
    • +
      +
    • \ref Concepts
      • +
    • \ref MITKModuleManualsListPage
      • +
    +
  • \subpage DevelopmentApplication
    • +
      +
    • \ref mitkExtPointsIndex
      • +
    • \ref DeploymentPage
      • +
    • \ref BlueBerryExamples
      • +
    • \ref BlueBerryIntro
      • +
    +
+ +*/ diff --git a/Documentation/Doxygen/DeveloperManual/Development.dox b/Documentation/Doxygen/DeveloperManual/Development.dox deleted file mode 100644 index 5e1997f33c..0000000000 --- a/Documentation/Doxygen/DeveloperManual/Development.dox +++ /dev/null @@ -1,50 +0,0 @@ -/** -\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 -\li \ref HowToNewProject - -\section DevelopmentGettingToKnow Getting To Know MITK - -\li \subpage DirectoryStructurePage -\li \subpage TutorialPage - -\section DevelopmentWith Developing With MITK - -\li \subpage CMAKE_FAQ -\li \subpage DICOMTesting -\li \subpage NewPluginPage -\li \subpage StatemachineEditor -\li \subpage mitkExtPointsIndex -\li \subpage DeploymentPage -\li \subpage KnownProblemsPage - -\section DevelopmentContributing Contributing To MITK - -\li \subpage DocumentationGuide -\li \subpage StyleGuideAndNotesPage - -\section DevelopmentGettingToKnowBlueberry Getting To Know BlueBerry - -\li \subpage BlueBerryExamples - -\section DevelopmentFurtherInfo Further Information - -This section lists some ressources you might want to look at if you could not find what you need in -the \ref Development or \ref Concepts sections. - -We hold regular internal seminars which may or may not have something to do with MITK directly. The slides can be found -here. - -If you have some problems with MITK you might want to take a look at the FAQ. - -If the above does not prove sufficient you can contact the Mailinglist. -*/ diff --git a/Documentation/Doxygen/DeveloperManual/Starting/AboutTesting/AboutTestingPage.dox b/Documentation/Doxygen/DeveloperManual/Starting/AboutTesting/AboutTestingPage.dox new file mode 100644 index 0000000000..a0231fc98d --- /dev/null +++ b/Documentation/Doxygen/DeveloperManual/Starting/AboutTesting/AboutTestingPage.dox @@ -0,0 +1,9 @@ +/** +\page AboutTestingPage Testing + +TODO +\subpage GeneralTests +\subpage RenderingTests +\subpage DICOMTesting + +*/ diff --git a/Core/Documentation/Doxygen/Concepts/Overview.dox b/Documentation/Doxygen/DeveloperManual/Starting/Architecture.dox similarity index 96% rename from Core/Documentation/Doxygen/Concepts/Overview.dox rename to Documentation/Doxygen/DeveloperManual/Starting/Architecture.dox index f5def8bb90..c1553fe018 100644 --- a/Core/Documentation/Doxygen/Concepts/Overview.dox +++ b/Documentation/Doxygen/DeveloperManual/Starting/Architecture.dox @@ -1,47 +1,47 @@ /** -\page OverviewPage Introduction: Overview on the Medical Imaging Interaction Toolkit (MITK) +\page Architecture The Architecture of MITK MITK is an open source software toolkit for medical image processing, subsequent data analysis and integration of medical hardware. It is designed with the aim of providing a modular and heavily reusable code base to enable rapid development of new features. Following this design philosophy MITK includes many different specialized modules e.g. the Segmentation Module. This document is aimed at giving an overview of the general structure of MITK. Furthermore it will give an introduction into the coding and design concepts behind this toolkit. \section OverviewPage_DesignOverview Design Overview MITK is designed to be used as a pure software library or as a complete application framework. Thus, a user of MITK can decide if he simply wants to add a new plug-in to the existing application framework or if he needs to implement his own application and wants to use MITK as a software library. Depending on the type of use MITK uses different software libraries, which is shown in the next figure for overview. \image html MitkOverview.png "Overview of MITK" Like shown above, MITK uses the following libraries. These are the main libraries MITK is based on. For further functionality you can optionally include others, a list can be found \ref thirdpartylibs "here" . Based on these libraries, MITK includes the following features:
  • High level interactions with data.
  • Specialized medical imaging algorithms (e.g. segmentation)
  • Support of 3D + t data.
  • Complete application framework, expandable by plug-ins
  • Standard tools for medical imaging as default plug-ins (e.g. measurement, segmentation)
  • Many specialized module for different topics on medical imaging (e.g. diffusion imaging, image guided therapy, live image/ultrasound data processing)
*/ diff --git a/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/FirstSteps.dox b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/FirstSteps.dox new file mode 100644 index 0000000000..72d5728de0 --- /dev/null +++ b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/FirstSteps.dox @@ -0,0 +1,13 @@ +/** +\page FirstSteps First steps in Development + +TODO + +
    +
  • \subpage NewPluginPage
    • +
  • \subpage NewModulePage
    • +
  • \subpage CMAKE_FAQ
    • +
  • \subpage StatemachineEditor
    • +
+ +*/ diff --git a/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/NewModule.dox b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/NewModule.dox new file mode 100644 index 0000000000..ac64bbafbe --- /dev/null +++ b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/NewModule.dox @@ -0,0 +1,4 @@ +/** +\page NewModulePage How to create a new MITK Module + +*/ diff --git a/Documentation/Doxygen/DeveloperManual/NewPlugin.dox b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/NewPlugin.dox similarity index 100% rename from Documentation/Doxygen/DeveloperManual/NewPlugin.dox rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/NewPlugin.dox diff --git a/Documentation/Doxygen/StatemachineEditor/StatemachineEditor.dox b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/StatemachineEditor.dox similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/StatemachineEditor.dox rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/StatemachineEditor.dox diff --git a/Documentation/Doxygen/StatemachineEditor/images/BuildPath.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/BuildPath.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/BuildPath.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/BuildPath.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/CreateJavaProject.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/CreateJavaProject.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/CreateJavaProject.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/CreateJavaProject.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/Import.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/Import.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/Import.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/Import.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/Import2.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/Import2.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/Import2.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/Import2.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/Import3.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/Import3.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/Import3.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/Import3.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/Import4.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/Import4.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/Import4.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/Import4.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/NewStatemachine.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/NewStatemachine.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/NewStatemachine.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/NewStatemachine.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/NewStatemachine1.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/NewStatemachine1.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/NewStatemachine1.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/NewStatemachine1.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/NewStatemachine2.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/NewStatemachine2.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/NewStatemachine2.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/NewStatemachine2.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/NewStatemachine3.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/NewStatemachine3.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/NewStatemachine3.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/NewStatemachine3.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/Runas.png b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/Runas.png similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/Runas.png rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/Runas.png diff --git a/Documentation/Doxygen/StatemachineEditor/images/addAction.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/addAction.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/addAction.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/addAction.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/application.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/application.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/application.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/application.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/application1.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/application1.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/application1.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/application1.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/changeEvent.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/changeEvent.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/changeEvent.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/changeEvent.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/openPropertiesView.PNG b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/openPropertiesView.PNG similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/openPropertiesView.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/openPropertiesView.PNG diff --git a/Documentation/Doxygen/StatemachineEditor/images/openstatemachinexml.png b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/openstatemachinexml.png similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/openstatemachinexml.png rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/openstatemachinexml.png diff --git a/Documentation/Doxygen/StatemachineEditor/images/specifycontainer.png b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/specifycontainer.png similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/specifycontainer.png rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/specifycontainer.png diff --git a/Documentation/Doxygen/StatemachineEditor/images/specifycontainer2.png b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/specifycontainer2.png similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/specifycontainer2.png rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/specifycontainer2.png diff --git a/Documentation/Doxygen/StatemachineEditor/images/specifycontainer3.png b/Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/specifycontainer3.png similarity index 100% rename from Documentation/Doxygen/StatemachineEditor/images/specifycontainer3.png rename to Documentation/Doxygen/DeveloperManual/Starting/FirstSteps/StatemachineEditor/images/specifycontainer3.png diff --git a/Documentation/Doxygen/DeveloperManual/CMakeFAQ.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/CMakeFAQ.dox similarity index 98% rename from Documentation/Doxygen/DeveloperManual/CMakeFAQ.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/CMakeFAQ.dox index 2486bfc14e..a0495ae8a6 100644 --- a/Documentation/Doxygen/DeveloperManual/CMakeFAQ.dox +++ b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/CMakeFAQ.dox @@ -1,38 +1,38 @@ /** -\page CMAKE_FAQ %CMake FAQ +\page CMAKE_FAQ CMake FAQ \section CMAKE_FAQ_General A general comment MITK uses %CMake for configuration. If you want to develop either using MITK as a toolkit or by extending the capabilities of the applications provided by us we recommend using %CMake for your own prject as well. While it might be possible to use MITK in conjunction with other options, such as QMake or setting up your own project manually it will invariably use a lot of work and probably hacks as well. As we have no experience in this we will not be able to help you, so be prepared to have to do a lot of tweaking on your own. This guide does not try to give a general introduction to Cmake, instead it tries to answer some basic questions that might arise for those new to %CMake, to help you get started on MITK. For a more comprehensive introduction on %CMake see here. We will assume in this guide, that the path to your source is /MITK/. \section CMAKE_FAQ_Question Basic Questions \subsection CMAKE_FAQ_Question_WhereGetIt Where do I get CMake and what version do I need? See \ref BuildInstructions_Prerequisites. \subsection CMAKE_FAQ_Question_NewPluginNothing I coded a new plugin for the Workbench and nothing happened. Why? The correct way to create a new plugin is described in \ref NewPluginOnly. Do note that you need to move the source to the MITK/Plugins directory and you will have to add the plugin to the config file (most likely MITK/Plugins/Plugins.cmake). After that see \ref CMAKE_FAQ_Question_HowDoIActivatePlugin. \subsection CMAKE_FAQ_Question_HowDoIActivatePlugin I want to use a plugin, how do I activate it?
  1. Start %CMake
  2. Configure
  3. Set the variable MITK_BUILD_ to TRUE
  4. Configure again
  5. Generate
  6. Start a build using your development environment
\subsection CMAKE_FAQ_Question_HowDoIActivateModule I want to use a module, how do I activate it? Modules are build automatically if a plugin that requires them is activated. See \ref CMAKE_FAQ_Question_HowDoIActivatePlugin. \subsection CMAKE_FAQ_Question_HowOwnToolkits MITK always downloads the toolkits, but I want to use my own. This is covered in \ref HowToNewProjectCustomizingMITKConfigure. \subsection CMAKE_FAQ_Question_HowOwnProjectMITK I want to use an MITK plugin in my own project but I can not find it. See \ref HowToNewProjectAddingMITKFunctionality. */ \ No newline at end of file diff --git a/Core/Documentation/Doxygen/Concepts/CodingGeneral.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Coding.dox similarity index 100% rename from Core/Documentation/Doxygen/Concepts/CodingGeneral.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Coding.dox diff --git a/Documentation/Doxygen/DeveloperManual/DirectoryStructure.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/DirectoryStructure.dox similarity index 100% rename from Documentation/Doxygen/DeveloperManual/DirectoryStructure.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/DirectoryStructure.dox diff --git a/Documentation/Doxygen/DeveloperManual/DocumentationExample.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/DocumentationExample.dox similarity index 100% rename from Documentation/Doxygen/DeveloperManual/DocumentationExample.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/DocumentationExample.dox diff --git a/Documentation/Doxygen/DeveloperManual/DocumentationGuide.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/DocumentationGuide.dox similarity index 100% rename from Documentation/Doxygen/DeveloperManual/DocumentationGuide.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/DocumentationGuide.dox diff --git a/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/GettingToKnowMITK.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/GettingToKnowMITK.dox new file mode 100644 index 0000000000..e418a0b301 --- /dev/null +++ b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/GettingToKnowMITK.dox @@ -0,0 +1,14 @@ +/** +\page GettingToKnowMITK Getting to know MITK + +TODO +
    +
  • \subpage DirectoryStructurePage
    • +
  • \subpage TutorialPage
    • +
  • \subpage CMAKE_FAQ
    • +
  • \subpage StyleGuideAndNotesPage
    • +
  • \subpage DocumentationGuide
    • +
  • \subpage CodingPage
    • +
  • \subpage KnownProblemsPage
    • +
+*/ diff --git a/Documentation/Doxygen/DeveloperManual/KnownProblems.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/KnownProblems.dox similarity index 100% rename from Documentation/Doxygen/DeveloperManual/KnownProblems.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/KnownProblems.dox diff --git a/Documentation/Doxygen/DeveloperManual/StyleGuideAndNotes.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/StyleGuideAndNotes.dox similarity index 100% rename from Documentation/Doxygen/DeveloperManual/StyleGuideAndNotes.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/StyleGuideAndNotes.dox diff --git a/Documentation/Doxygen/Tutorial/CMakeLists.txt b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/CMakeLists.txt similarity index 100% rename from Documentation/Doxygen/Tutorial/CMakeLists.txt rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/CMakeLists.txt diff --git a/Documentation/Doxygen/Tutorial/Step00.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step00.dox similarity index 100% rename from Documentation/Doxygen/Tutorial/Step00.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step00.dox diff --git a/Documentation/Doxygen/Tutorial/Step01.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step01.dox similarity index 100% rename from Documentation/Doxygen/Tutorial/Step01.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step01.dox diff --git a/Documentation/Doxygen/Tutorial/Step02.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step02.dox similarity index 100% rename from Documentation/Doxygen/Tutorial/Step02.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step02.dox diff --git a/Documentation/Doxygen/Tutorial/Step03.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step03.dox similarity index 100% rename from Documentation/Doxygen/Tutorial/Step03.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step03.dox diff --git a/Documentation/Doxygen/Tutorial/Step04.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step04.dox similarity index 100% rename from Documentation/Doxygen/Tutorial/Step04.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step04.dox diff --git a/Documentation/Doxygen/Tutorial/Step05.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step05.dox similarity index 100% rename from Documentation/Doxygen/Tutorial/Step05.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step05.dox diff --git a/Documentation/Doxygen/Tutorial/Step06.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step06.dox similarity index 100% rename from Documentation/Doxygen/Tutorial/Step06.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step06.dox diff --git a/Documentation/Doxygen/Tutorial/Step07.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step07.dox similarity index 100% rename from Documentation/Doxygen/Tutorial/Step07.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step07.dox diff --git a/Documentation/Doxygen/Tutorial/Step08.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step08.dox similarity index 100% rename from Documentation/Doxygen/Tutorial/Step08.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step08.dox diff --git a/Documentation/Doxygen/Tutorial/Step09.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step09.dox similarity index 100% rename from Documentation/Doxygen/Tutorial/Step09.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step09.dox diff --git a/Documentation/Doxygen/Tutorial/Step10.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step10.dox similarity index 100% rename from Documentation/Doxygen/Tutorial/Step10.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Step10.dox diff --git a/Documentation/Doxygen/Tutorial/Tutorial.dox b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Tutorial.dox similarity index 100% rename from Documentation/Doxygen/Tutorial/Tutorial.dox rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/Tutorial.dox diff --git a/Documentation/Doxygen/Tutorial/configureCMake.PNG b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/configureCMake.PNG similarity index 100% rename from Documentation/Doxygen/Tutorial/configureCMake.PNG rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/configureCMake.PNG diff --git a/Documentation/Doxygen/Tutorial/configureVisualStudioProperties.png b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/configureVisualStudioProperties.png similarity index 100% rename from Documentation/Doxygen/Tutorial/configureVisualStudioProperties.png rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/configureVisualStudioProperties.png diff --git a/Documentation/Doxygen/Tutorial/step10_result.png b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step10_result.png similarity index 100% rename from Documentation/Doxygen/Tutorial/step10_result.png rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step10_result.png diff --git a/Documentation/Doxygen/Tutorial/step1_result.png b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step1_result.png similarity index 100% rename from Documentation/Doxygen/Tutorial/step1_result.png rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step1_result.png diff --git a/Documentation/Doxygen/Tutorial/step2_result.png b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step2_result.png similarity index 100% rename from Documentation/Doxygen/Tutorial/step2_result.png rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step2_result.png diff --git a/Documentation/Doxygen/Tutorial/step3a_result.png b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step3a_result.png similarity index 100% rename from Documentation/Doxygen/Tutorial/step3a_result.png rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step3a_result.png diff --git a/Documentation/Doxygen/Tutorial/step3b_result.png b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step3b_result.png similarity index 100% rename from Documentation/Doxygen/Tutorial/step3b_result.png rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step3b_result.png diff --git a/Documentation/Doxygen/Tutorial/step4a_result.png b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step4a_result.png similarity index 100% rename from Documentation/Doxygen/Tutorial/step4a_result.png rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step4a_result.png diff --git a/Documentation/Doxygen/Tutorial/step4b_result.png b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step4b_result.png similarity index 100% rename from Documentation/Doxygen/Tutorial/step4b_result.png rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step4b_result.png diff --git a/Documentation/Doxygen/Tutorial/step5_result.png b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step5_result.png similarity index 100% rename from Documentation/Doxygen/Tutorial/step5_result.png rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step5_result.png diff --git a/Documentation/Doxygen/Tutorial/step6_result.png b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step6_result.png similarity index 100% rename from Documentation/Doxygen/Tutorial/step6_result.png rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step6_result.png diff --git a/Documentation/Doxygen/Tutorial/step8_result.png b/Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step8_result.png similarity index 100% rename from Documentation/Doxygen/Tutorial/step8_result.png rename to Documentation/Doxygen/DeveloperManual/Starting/GettingToKnow/Tutorial/step8_result.png diff --git a/Documentation/Doxygen/DeveloperManual/BuildInstructions.dox b/Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/BuildInstructions.dox similarity index 100% rename from Documentation/Doxygen/DeveloperManual/BuildInstructions.dox rename to Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/BuildInstructions.dox diff --git a/Documentation/Doxygen/DeveloperManual/BuildToolkits.dox b/Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/BuildToolkits.dox similarity index 100% rename from Documentation/Doxygen/DeveloperManual/BuildToolkits.dox rename to Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/BuildToolkits.dox diff --git a/Documentation/Doxygen/DeveloperManual/HowToNewProject-MyProjectLayout.png b/Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/HowToNewProject-MyProjectLayout.png similarity index 100% rename from Documentation/Doxygen/DeveloperManual/HowToNewProject-MyProjectLayout.png rename to Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/HowToNewProject-MyProjectLayout.png diff --git a/Documentation/Doxygen/DeveloperManual/HowToNewProject.dox b/Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox similarity index 99% rename from Documentation/Doxygen/DeveloperManual/HowToNewProject.dox rename to Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox index d961d9c9e4..f9b4cdeaa7 100644 --- a/Documentation/Doxygen/DeveloperManual/HowToNewProject.dox +++ b/Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/HowToNewProject.dox @@ -1,161 +1,161 @@ /** \page HowToNewProject Creating a new MITK project This page is intended to give a comprehensive guide to setting up your own MITK based project. It will use the application framework provided by MITK and is probably the preferred way for most users. The first part of this document is a tutorial aimed at newcomers to MITK and possibly %CMake and tries to give as much help as possible on setting up your own project. If you are looking for more technical information about customizing MITK, the structure of the superbuild or packaging you might want to read the \ref HowToNewProjectAdvancedInformation. If you have set up your MITK project already and want to start developing you could take a look at \ref TutorialPage. \section HowToNewProjectGettingStarted Getting Started To bootstrap your project MITK offers two convenient options:
  1. Use the MITK Plugin Generator, a command line tool used to generate a customized MITK project and/or MITK plug-ins (available for download here).
  2. Use the MITK project template as an example project.
Both options will provide you with a project which contains a "superbuild" mechanism to automatically download, configure, and build MITK as a dependency of your own project. The MITK Plugin Generator generates code using the supplied command line arguments, whereas the MITK project template needs immediate modifications to customize it to your naming schemes. However, the project template will potentially contain more code demonstrating features of MITK. \note Using the MITK Plugin Generator is recommended for beginners. \section HowToNewProjectPrerequisites Prerequisites What ever option you choose, a MITK-based project needs essentially the same prerequisites as MITK itself. Please see \ref BuildInstructions_Prerequisites for details. \note If you use one of the two options above you will \b not \b need to build MITK yourself. This will be done automatically. \section HowToNewProjectCreatingSourceDir Preparing your source directory In order to start developing with MITK, you first have to set up the source directory for your project. \subsection HowToNewProjectSourceUsingGenerator Using the MITK Plugin Generator The usage of the Plugin Generator for creating a new project is described in \ref NewPluginWithProject, please have a look there. \subsection HowToNewProjectSourceUsingTemplate Using the MITK Project Template Download the project as a tarball or zipball and extract it to your desired source directory. \note This is a \b template \b. You must modify it such that it fits the needs of your particular project. Especially you should do a global search and replace for the string "awesome" to rename the template application and plug-in. You may want to rename some files too. \section HowToNewProjectGeneratingCMake Generating your binary with CMake After you have set up your source directory you can proceed to generate your binary directory using %CMake. Depending on your operating system and preferences you might want to use "cmake-gui" or "ccmake" (shell). This document assumes you are using cmake-gui.
  1. Start "cmake-gui" and enter your source (e.g. "D:\AwesomeProject") and binary directory (e.g. "D:\AwesomeProject-superbuild").
  2. Upon first pressing "Configure" you will be prompted to select your generator. This determines what project files will be generated by %CMake. Set this to the development tool you are intending to use (e.g. "Visual Studio 2010 64Bit" or "linux makefiles".
  3. Press "Configure" until no new variables appear and then "Generate". Now all project files have been generated into your binary directory.
  4. Double-check that the right Qt version is used.
Now you are ready to compile your code. Depending on your choice of tool this will be done differently, we cover two possibilities here. \subsection HowToNewProjectCompilingLinuxMakefiles Compiling using linux makefiles
  1. In the shell, switch to your binary directory.
  2. type "make" and hit enter
\subsection HowToNewProjectCompilingVisualStudio Compiling using visual studio We assume your application is called "AwesomeApp" and your project "AwesomeProject" and your binary directory is "D:\AwesomeProject-superbuild\". Replace names and paths accordingly.
  1. Close %CMake and open "D:\AwesomeProject-superbuild\AwesomeProject-superbuild.sln" . Your Visual Studio should appear and by pressing F7 you start the compilation. This will clone the MITK source code, build it, and then start building your own project.
  2. After the superbuild compilation has finished, close the solution file and start the batch file "D:\AwesomeProject-superbuild\AwesomeProject-build\StartVS_debug.bat" (or _release.bat if you built in Release mode) which opens the "D:\AwesomeProject-superbuild\AweseomeProject-build\AwesomeProject.sln" solution.
  3. Set the "AwesomeApp" project as start-up project (right click > "Set as StartUp Project") and press "F5" to start your MITK AwesomeApp.
\note Just opening AwesomeProject.sln from your explorer by double-cliking won`t allow you to start or debug your application because the required environment variables would be missing. Use the supplied batch files or set your PATH variable accordingly. \section HowToNewProjectAddingMITKFunctionality I want to use some MITK plugin but it is not available Due to the sheer number of MITK plugins not every plugin is activated by default. To activate a specific plugin (again replace paths as needed):
  1. Start "cmake-gui" and set the binary directory to "D:\AwesomeProject-superbuild\MITK-superbuild\MITK-build\", the source will adjust automatically and you will see new settings appear.
  2. Navigate to the plugin you want to use (e.g. "MITK_BUILD_org.mitk.gui.qt.segmentation") and tick the checkbox behind it
  3. Press "Configure" until no new variables appear and then "Generate".
  4. Build MITK using your development tool (as in \ref HowToNewProjectCompilingLinuxMakefiles or \ref HowToNewProjectCompilingVisualStudio only in the "D:\AwesomeProject-superbuild\MITK-superbuild\MITK-build\" directory )
  5. Start "cmake-gui" and set the binary directory to "D:\AwesomeProject-superbuild\AwesomeProject-build\", the source will adjust automatically and you will see new settings appear.
  6. Press "Configure" until no new variables appear and then "Generate".
  7. Build your project
  8. Start your application
\note If you want to use an application provided by MITK (e.g. MITK Workbench) you have to tick the appropriate checkbox as well (in this case MITK_BUILD_APP_mitkWorkbench ) and build MITK. Do note, that this application will be located in the bin directory of the "D:\AwesomeProject-superbuild\MITK-superbuild\MITK-build\" folder. -\section HowToNewProjectAdvancedInformation Information for avanced users +\section HowToNewProjectAdvancedInformation Information for advanced users \subsection HowToNewProjectCustomizingMITK Customizing MITK The %CMake scripts from the Plugin Generator of the project template provide some handy options which allow you to customize the MITK build used in your project. You can either inject an already build MITK to be used by your project or configure some MITK options directly in your project's superbuild configuration if MITK is going to be build inside your project. \subsubsection HowToNewProjectCustomizingMITKInjectMITK Inject a MITK build By setting the \b EXTERNAL_MITK_DIR \b variable in your project's superbuild %CMake configuration to a MITK build directory (containing the MITKConfig.cmake) you can skip the MITK build process. If MITK is the only external project in your project, you might want to disable the superbuild of your project completely (set _USE_SUPERBUILD to OFF or edit your CMakeLists.txt file to set it to OFF by default) and set the \b MITK_DIR \b %CMake variable to your MITK build directory. \subsubsection HowToNewProjectCustomizingMITKConfigure Configure the MITK superbuild If MITK is being build inside your project's superbuild process, you can enable the use of certain third-party libraries inside of MITK. The following variables control the MITK configuration:
  • \b MITK_USE_BLUEBERRY Enable the use of the BlueBerry application framework
  • \b MITK_USE_Boost Download and use Boost in MITK
  • \b MITK_USE_CTK Download, compile, and use CTK in MITK
  • \b MITK_USE_DCMTK Download, compile, and use DCMTK in MITK
  • \b MITK_USE_OpenCV Download, compile, and use OpenCV in MITK
  • \b MITK_USE_Python Download and compile 1CableSwig and enable Python wrapping in ITK, VTK, OpenCV, and MITK
  • \b MITK_USE_QT Use the Qt framework in MITK
You can also inject already build third-party libraries from inside your project's superbuild in the MITK superbuild by using any of the following %CMake variables:
  • \b MITK_CTK_DIR Reuse a CTK build directory in MITK.
  • \b MITK_CableSwig_DIR Reuse a 1CableSwig build directory in MITK.
  • \b MITK_DCMTK_DIR Reuse a DCMKT build directory in MITK.
  • \b MITK_GDCM_DIR Reuse a GDCM build directory in MITK.
  • \b MITK_ITK_DIR Reuse a ITK build directory in MITK.
  • \b MITK_OpenCV_DIR Reuse a OpenCV build directory in MITK.
  • \b MITK_VTK_DIR Reuse a VTK build directory in MITK.
If the corresponding \b MITK_USE_ \b option is set to on, the MITK superbuild will use the provided build directory instead of building the project itself. You can also control the source code location for MITK in your project's superbuild configuration by using the following %CMake variables:
  • \b MITK_SOURCE_DIR The path to the MITK source directory. If the value for this variable is non-empty, the variables below are ignored.
  • \b MITK_GIT_REPOSITORY The Git repository containing the MITK source code.
  • \b MITK_GIT_TAG The hash id, tag or branch name used for a checkout from MITK_GIT_REPOSITORY.
\subsubsection HowToNewProjectProjectStructure Project Structure If you are using the superbuild feature of the generated project (the default), you might want to familiarise yourself with the layout of your build tree. The top-level build directory which you specified in %CMake when configuring your project will contain all the required dependencies. Suppose we call our project MyProject and the build directory is "C:\MyProject-superbuild". Then the layout looks something like this: MyProjectLayout.png The top-level directory contains the source code and the build directories from the dependencies of your project. In the current case, the only dependency of MyProject is MITK, which in turn has downloaded and built its own dependencies (CTK, DCMTK, ITK, etc.). The "real" build tree for your project is located in MyProject-superbuild/MyProject-build, so point the %CMake-GUI to this build directory if you want to change the set of enabled plug-ins for example. Further, you should open the MyProject.sln solution file (for Visual Studio) or execute "make" in the MyProject-superbuild/MyProject-build/ directory. Only for the very first time or if you want to update and newly build the project's dependencies should you use the project files in the MyProject-superbuild directory directly. The same applies for the MyProject-superbuild/MITK-superbuild directory. This directory contains the MITK superbuild, nested inside your project's superbuild. If you want to change %CMake options for MITK, use the MyProject-superbuild/MITK-superbuild/MITK-build build directory. \image html HowToNewProject-MyProjectLayout.png "Layout of MyProject" \subsubsection HowToNewProjectPackaging Packaging The project template and the generated projects by the Plugin Generator come with full packaging support. You can create deployable packages of your project for all supported operating systems my building the PACKAGE target. On Linux, this will create a tarball, on MacOS a .dmg file, and on Windows a zipball and an NSIS installer (if NSIS is installed and found). You can read more about deployment \ref DeploymentPage "here". */ \ No newline at end of file diff --git a/Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/SettingUpMITK.dox b/Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/SettingUpMITK.dox new file mode 100644 index 0000000000..5b67763c66 --- /dev/null +++ b/Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/SettingUpMITK.dox @@ -0,0 +1,14 @@ +/** +\page SettingUpMITK Setting Up Mitk + +TODO + +
    +
  • \subpage SupportedPlatformsPage
    • +
  • \subpage BuildInstructionsPage
    • +
  • \subpage thirdpartylibs
    • +
  • \subpage HowToNewProject
    • +
  • \subpage Testing
    • +
+ +*/ diff --git a/Documentation/Doxygen/DeveloperManual/SupportedPlatforms.md b/Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/SupportedPlatforms.md similarity index 100% rename from Documentation/Doxygen/DeveloperManual/SupportedPlatforms.md rename to Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/SupportedPlatforms.md diff --git a/Documentation/Doxygen/DeveloperManual/ThirdPartyLibs.dox b/Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/ThirdPartyLibs.dox similarity index 100% rename from Documentation/Doxygen/DeveloperManual/ThirdPartyLibs.dox rename to Documentation/Doxygen/DeveloperManual/Starting/SettingUpMITK/ThirdPartyLibs.dox diff --git a/Documentation/Doxygen/DeveloperManual/Starting/Starting.dox b/Documentation/Doxygen/DeveloperManual/Starting/Starting.dox new file mode 100644 index 0000000000..fa78a1bb8d --- /dev/null +++ b/Documentation/Doxygen/DeveloperManual/Starting/Starting.dox @@ -0,0 +1,37 @@ +/** + +\page StartingDevelopment Starting your MITK Development + +This Introduction will acquaint you with the most important workflows to get you started with your MITK Development. + +
    +
  • \subpage Architecture
    • +
  • \subpage SettingUpMITK
    • +
      +
    • \ref SupportedPlatformsPage
      • +
    • \ref BuildInstructionsPage
      • +
    • \ref thirdpartylibs
      • +
    • \ref HowToNewProject
      • +
    +
  • \subpage GettingToKnowMITK
    • +
      +
    • \ref DirectoryStructurePage
      • +
    • \ref TutorialPage
      • +
    • \ref CMAKE_FAQ
      • +
    • \ref StyleGuideAndNotesPage
      • +
    • \ref DocumentationGuide
      • +
    • \ref CodingPage
      • +
    • \ref KnownProblemsPage
      • +
    +
  • \subpage FirstSteps
    • +
      +
    • \ref NewPluginPage
      • +
    • \ref NewModulePage
      • +
    • \ref StatemachineEditor
      • +
    +
  • \subpage AboutTestingPage
    • +
+ + + +*/ diff --git a/Documentation/Doxygen/DeveloperManual/Toolkit/DevelopmentToolkit.dox b/Documentation/Doxygen/DeveloperManual/Toolkit/DevelopmentToolkit.dox new file mode 100644 index 0000000000..ae77b729ea --- /dev/null +++ b/Documentation/Doxygen/DeveloperManual/Toolkit/DevelopmentToolkit.dox @@ -0,0 +1,13 @@ +/** + +\page DevelopmentToolkit Developing with the MITK Toolkit + +Todo + +
    +
  • \subpage Concepts
    • +
  • \subpage MITKModuleManualsListPage
    • +
+ + +*/ diff --git a/Documentation/Doxygen/UserManual/MITKModuleManualsList.dox b/Documentation/Doxygen/DeveloperManual/Toolkit/ModuleManuals/MITKModuleManualsList.dox similarity index 93% rename from Documentation/Doxygen/UserManual/MITKModuleManualsList.dox rename to Documentation/Doxygen/DeveloperManual/Toolkit/ModuleManuals/MITKModuleManualsList.dox index 1cd4e1e54e..6dfede77e3 100644 --- a/Documentation/Doxygen/UserManual/MITKModuleManualsList.dox +++ b/Documentation/Doxygen/DeveloperManual/Toolkit/ModuleManuals/MITKModuleManualsList.dox @@ -1,20 +1,21 @@ /** \page MITKModuleManualsListPage MITK Module Manuals \section MITKModuleManualsListPageOverview Overview The modules are shared libraries that provide functionality that can be used by developers. \section MITKModuleManualsListPageModuleManualList List of Module Manuals \li \subpage IGTGeneralModulePage \li \subpage MitkOpenCL_Overview \li \subpage SimulationManualPage + \li \subpage GeneratingDeviceModulesPage \section MITKModuleManualsListPageAdditionalInformation Additional Information on Certain Modules \li \ref PlanarPropertiesPage \li \subpage DiffusionImagingPropertiesPage \li \subpage ConnectomicsRenderingPropertiesPage */ diff --git a/Core/Documentation/Doxygen/Concepts/images/introduction/MitkOverview.png b/Documentation/Doxygen/DeveloperManual/images/MitkOverview.png similarity index 100% rename from Core/Documentation/Doxygen/Concepts/images/introduction/MitkOverview.png rename to Documentation/Doxygen/DeveloperManual/images/MitkOverview.png diff --git a/Documentation/Doxygen/MainPage.dox.in b/Documentation/Doxygen/MainPage.dox.in index 05d7565451..ed93fcfd62 100644 --- a/Documentation/Doxygen/MainPage.dox.in +++ b/Documentation/Doxygen/MainPage.dox.in @@ -1,57 +1,17 @@ /** -\mainpage Medical Imaging Interaction Toolkit +\mainpage Medical Imaging Interaction Toolkit - Documentation Portal \image html mitkLogo.jpg -\section intro Introduction +This page acts as a portal to the three different parts of the MITK-Documentation. -Welcome to the Medical Imaging Interaction Toolkit (MITK). -Currently under active development, MITK aims at supporting the -development of leading-edge medical imaging software -with a high degree of interaction. It combines VTK, -ITK and the pic-based-libraries of the -Div. Medical and Biological Informatics -of the DKFZ and adds those features that are most important -for developing interactive medical imaging software covered neither by VTK nor ITK, i.e: -\li multiple, consistent views on the same data. For example, when you have three orthogonal -2D-views and a 3D view and data consisting of a green surface, the surface will be visible and green -in all views (as contour lines in 2D, as a surface in 3D), and when you move the surface, it will -move in all views. When you try to implement this with basic VTK, you will need to coordinate the -position/orientation/color/... of all the views somewhere in your program - exactly this can MITK -do for you. -\li interactions that create and/or modify data (not only actors as in basic VTK) -\li complex interactions with multiple states, e.g., for interaction with active contours -\li undo/redo of interactions -\li organization of data objects in a tree at run-time, e.g., to represent logical dependencies (e.g., -a heart cavity is a part of the heart) or to control the rendering process -\li additional properties of arbitrary type can be assigned to data objects contained in the data tree -\li visualization and interaction with 3D+t data (basic VTK can handle only 3D data and ITK is not -for visualization and interaction) -\li although MITK is mainly a toolkit and not an application, it offers some support on the -application-level, e.g, for structured combination of modules (so-called functionalities), e.g., for -combining and switching between one functionality for segmentation and another for registration. +If this is your first time around here and you are interested in learning more about MITK, please read \subpage Overview -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 the features outlined above. +If you are a MITK end-user, please refer to the \subpage UserManualPortal -\section FurtherReading Further Reading +If you are a developer looking for a developer's guide, please see \subpage DeveloperManualPortal -\subpage ShortIntroductionToMITK - -\ref Concepts - -\ref Development - -\ref HowToNewProject "A comprehensive newcomers guide to setting up your own MITK project" - -@MITK_XP_LINK@ - -@BLUEBERRY_DOXYGEN_LINK@ - -\ref thirdpartylibs - - */ diff --git a/Documentation/Doxygen/Modules/ModuleGeometryFigures.zip b/Documentation/Doxygen/Modules/ModuleGeometryFigures.zip deleted file mode 100644 index 434c701fb9..0000000000 Binary files a/Documentation/Doxygen/Modules/ModuleGeometryFigures.zip and /dev/null differ diff --git a/Documentation/Doxygen/DeveloperManual/ShortIntroductionToMITK.dox b/Documentation/Doxygen/Overview/Overview.dox similarity index 96% rename from Documentation/Doxygen/DeveloperManual/ShortIntroductionToMITK.dox rename to Documentation/Doxygen/Overview/Overview.dox index 9b03af2ba5..565f32e6f2 100644 --- a/Documentation/Doxygen/DeveloperManual/ShortIntroductionToMITK.dox +++ b/Documentation/Doxygen/Overview/Overview.dox @@ -1,29 +1,29 @@ /** -\page ShortIntroductionToMITK A short introduction to MITK +\page Overview MITK: An Overview The Medical Imaging Interaction Toolkit (MITK) can be used in several different ways. If you are a new user to MITK the first question is in what manner you intend to use it. The following options are simplified and condensed versions of the most common usage scenarios. \tableofcontents \section ShortIntroductionToMITKAsToolkit I want to develop my own software framework, but use some of MITK's data structures and algorithms You will use MITK as a toolkit and probably benefit most from the \ref BuildInstructionsPage and MITK API Documentation. \section ShortIntroductionToMITKAsFramework I want to use the MITK and BlueBerry software framework to develop my own software Here you have again two options. \subsection ShortIntroductionToMITKAsFrameworkExtendingWorkbench I want use the MITK Workbench and extend its capabilities You are using MITK as software framework and writing your own modules and plugins for MITK. You want to read the \ref BuildInstructionsPage and further on \ref Development. Also you might want to take a look at our \ref CMAKE_FAQ. \subsection ShortIntroductionToMITKAsFrameworkExternalProject I want to create my own application based on MITK but with major customizations and changes This is probably the most common way to use MITK. You are using MITK as software framework and building your own project and application using MITK. You want to read \ref HowToNewProject and the general information in \ref Development. Also you might want to take a look at our \ref CMAKE_FAQ. \section ShortIntroductionToMITKAsFrameworkEndUser I want to use the MITK Workbench to do image processing You are using MITK and the MITK Workbench as an end user and will find user manuals in \ref MITKUserManualPage and \ref PluginListPage. */ \ No newline at end of file diff --git a/Documentation/Doxygen/UserManual/Applications.dox b/Documentation/Doxygen/UserManual/Applications.dox index 2a6b7db404..7620fc8046 100644 --- a/Documentation/Doxygen/UserManual/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 PluginListPage . -The basic usage information on MITK can be found in \subpage MITKUserManualPage . +The basic usage information on MITK can be found in \ref 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 MITKUserManualPage . Further information on any application can be found here:
  • \subpage org_mitkworkbench
  • \subpage org_dti_atlas_application
  • \subpage org_mitk_gui_qt_diffusionimagingapp
*/ \ No newline at end of file diff --git a/Documentation/Doxygen/UserManual/MITKPluginManualsList.dox b/Documentation/Doxygen/UserManual/MITKPluginManualsList.dox index 26c53b8a28..7c28abd755 100644 --- a/Documentation/Doxygen/UserManual/MITKPluginManualsList.dox +++ b/Documentation/Doxygen/UserManual/MITKPluginManualsList.dox @@ -1,37 +1,39 @@ /** \page PluginListPage MITK Plugin Manuals \section PluginListPageOverview Overview The plugins and bundles provide much of the extended functionality of MITK. Each encapsulates a solution to a problem and associated features. This way one can easily assemble the necessary capabilites for a workflow without adding a lot of bloat, by combining plugins as needed. The distinction between developer and end user use is for convenience only and mainly distinguishes which group a plugin is primarily aimed at. \section PluginListPageEndUserPluginList List of Plugins for End User Use \li \subpage org_mitk_views_basicimageprocessing \li \subpage org_mitk_views_datamanager \li \subpage org_mitk_gui_qt_diffusionimaging \li \subpage org_mitk_views_imagecropper \li \subpage org_mitk_views_imagenavigator \li \subpage org_mitk_gui_qt_measurementtoolbox \li \subpage org_mitk_views_moviemaker \li \subpage org_mitk_views_meshdecimation \li \subpage org_mitk_views_pointsetinteraction \li \subpage org_mitk_gui_qt_registration \li \subpage org_mitk_views_segmentation \li \subpage org_mitk_views_volumevisualization \li \subpage org_mitk_gui_qt_dicom \li \subpage org_mitk_gui_qt_ultrasound + \li \subpage org_mitk_views_fiberfoxview \section PluginListPageDevPluginList List of Plugins for Developer Use and Examples \li \subpage org_surfacematerialeditor \li \subpage org_toftutorial \li \subpage org_mitk_gui_qt_examples \li \subpage org_mitkexamplesopencv \li \ref org_mitk_gui_qt_igtexample \li \ref org_mitk_gui_qt_igttracking + \li \subpage org_mitk_gui_InteractionTests */ diff --git a/Documentation/Doxygen/UserManual/UserManualPortal.dox b/Documentation/Doxygen/UserManual/UserManualPortal.dox new file mode 100644 index 0000000000..83d3a73e5b --- /dev/null +++ b/Documentation/Doxygen/UserManual/UserManualPortal.dox @@ -0,0 +1,9 @@ +/** +\page UserManualPortal MITK: User Manual + +
    +
  • \subpage ApplicationsPage
    • +
  • \subpage MITKUserManualPage
    • +
  • \subpage PluginListPage
    • +
+*/ \ No newline at end of file diff --git a/Documentation/MITKDoxygenLayout.xml b/Documentation/MITKDoxygenLayout.xml index 19afb000f9..78f4ebf655 100644 --- a/Documentation/MITKDoxygenLayout.xml +++ b/Documentation/MITKDoxygenLayout.xml @@ -1,188 +1,195 @@ - + - - - - + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - diff --git a/Documentation/Doxygen/ExampleCode/DocumentationExample.h b/Examples/DocumentationExample.h similarity index 100% rename from Documentation/Doxygen/ExampleCode/DocumentationExample.h rename to Examples/DocumentationExample.h