diff --git a/Documentation/Doxygen/DeveloperManual/API/DevelopmentAPI.dox b/Documentation/Doxygen/API/DevelopmentAPI.dox similarity index 90% rename from Documentation/Doxygen/DeveloperManual/API/DevelopmentAPI.dox rename to Documentation/Doxygen/API/DevelopmentAPI.dox index 4f1263355b..d5c296f00f 100644 --- a/Documentation/Doxygen/DeveloperManual/API/DevelopmentAPI.dox +++ b/Documentation/Doxygen/API/DevelopmentAPI.dox @@ -1,5 +1,4 @@ /** \page DevelopmentAPI API-Documentation -TODO */ diff --git a/Documentation/Doxygen/DeveloperManual/API/Groups/CMakeLists.txt b/Documentation/Doxygen/API/Groups/CMakeLists.txt similarity index 100% rename from Documentation/Doxygen/DeveloperManual/API/Groups/CMakeLists.txt rename to Documentation/Doxygen/API/Groups/CMakeLists.txt diff --git a/Documentation/Doxygen/DeveloperManual/API/Groups/ModuleAdaptors.dox b/Documentation/Doxygen/API/Groups/ModuleAdaptors.dox similarity index 99% rename from Documentation/Doxygen/DeveloperManual/API/Groups/ModuleAdaptors.dox rename to Documentation/Doxygen/API/Groups/ModuleAdaptors.dox index c00107bc16..87c36285cf 100644 --- a/Documentation/Doxygen/DeveloperManual/API/Groups/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/DeveloperManual/API/Groups/ModuleGeometry.dox b/Documentation/Doxygen/API/Groups/ModuleGeometry.dox similarity index 97% rename from Documentation/Doxygen/DeveloperManual/API/Groups/ModuleGeometry.dox rename to Documentation/Doxygen/API/Groups/ModuleGeometry.dox index 212dd043a4..aa6ca16d8f 100644 --- a/Documentation/Doxygen/DeveloperManual/API/Groups/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/DeveloperManual/API/Groups/ModuleGeometryFig1.png b/Documentation/Doxygen/API/Groups/ModuleGeometryFig1.png similarity index 100% rename from Documentation/Doxygen/DeveloperManual/API/Groups/ModuleGeometryFig1.png rename to Documentation/Doxygen/API/Groups/ModuleGeometryFig1.png diff --git a/Documentation/Doxygen/DeveloperManual/API/Groups/ModuleMicroServices.dox b/Documentation/Doxygen/API/Groups/ModuleMicroServices.dox similarity index 99% rename from Documentation/Doxygen/DeveloperManual/API/Groups/ModuleMicroServices.dox rename to Documentation/Doxygen/API/Groups/ModuleMicroServices.dox index e3e6869d38..0e5d618203 100644 --- a/Documentation/Doxygen/DeveloperManual/API/Groups/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/DeveloperManual/API/Groups/ModuleVisualization.dox b/Documentation/Doxygen/API/Groups/ModuleVisualization.dox similarity index 80% rename from Documentation/Doxygen/DeveloperManual/API/Groups/ModuleVisualization.dox rename to Documentation/Doxygen/API/Groups/ModuleVisualization.dox index b63b43f940..72fb312d85 100644 --- a/Documentation/Doxygen/DeveloperManual/API/Groups/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/DeveloperManual/API/Groups/ModuleVisualizationMapper.dox b/Documentation/Doxygen/API/Groups/ModuleVisualizationMapper.dox similarity index 98% rename from Documentation/Doxygen/DeveloperManual/API/Groups/ModuleVisualizationMapper.dox rename to Documentation/Doxygen/API/Groups/ModuleVisualizationMapper.dox index a7a9dc1a2f..8f6a285c77 100644 --- a/Documentation/Doxygen/DeveloperManual/API/Groups/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/DeveloperManual/API/Groups/ModuleVisualizationNavigationControl.dox b/Documentation/Doxygen/API/Groups/ModuleVisualizationNavigationControl.dox similarity index 87% rename from Documentation/Doxygen/DeveloperManual/API/Groups/ModuleVisualizationNavigationControl.dox rename to Documentation/Doxygen/API/Groups/ModuleVisualizationNavigationControl.dox index 8543bfbee3..5e6a5b828a 100644 --- a/Documentation/Doxygen/DeveloperManual/API/Groups/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/DeveloperManual/API/Groups/ModuleVisualizationRenderer.dox b/Documentation/Doxygen/API/Groups/ModuleVisualizationRenderer.dox similarity index 99% rename from Documentation/Doxygen/DeveloperManual/API/Groups/ModuleVisualizationRenderer.dox rename to Documentation/Doxygen/API/Groups/ModuleVisualizationRenderer.dox index ade1036bad..e1e2428197 100644 --- a/Documentation/Doxygen/DeveloperManual/API/Groups/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/DeveloperManual/API/Groups/Modules.dox b/Documentation/Doxygen/API/Groups/Modules.dox similarity index 100% rename from Documentation/Doxygen/DeveloperManual/API/Groups/Modules.dox rename to Documentation/Doxygen/API/Groups/Modules.dox diff --git a/Documentation/Doxygen/DeveloperManual/API/Groups/RenderingSequence.png b/Documentation/Doxygen/API/Groups/RenderingSequence.png similarity index 100% rename from Documentation/Doxygen/DeveloperManual/API/Groups/RenderingSequence.png rename to Documentation/Doxygen/API/Groups/RenderingSequence.png diff --git a/Documentation/Doxygen/DeveloperManual/API/Groups/RenderingSequence.vsd b/Documentation/Doxygen/API/Groups/RenderingSequence.vsd similarity index 100% rename from Documentation/Doxygen/DeveloperManual/API/Groups/RenderingSequence.vsd rename to Documentation/Doxygen/API/Groups/RenderingSequence.vsd diff --git a/Documentation/Doxygen/DeveloperManual/API/Groups/dialogbarSlicer.png b/Documentation/Doxygen/API/Groups/dialogbarSlicer.png similarity index 100% rename from Documentation/Doxygen/DeveloperManual/API/Groups/dialogbarSlicer.png rename to Documentation/Doxygen/API/Groups/dialogbarSlicer.png diff --git a/Documentation/Doxygen/DeveloperManual/API/Groups/dialogbarStandardViews.png b/Documentation/Doxygen/API/Groups/dialogbarStandardViews.png similarity index 100% rename from Documentation/Doxygen/DeveloperManual/API/Groups/dialogbarStandardViews.png rename to Documentation/Doxygen/API/Groups/dialogbarStandardViews.png diff --git a/Documentation/Doxygen/DeveloperManual/API/Groups/dialogbarStereoOptions.png b/Documentation/Doxygen/API/Groups/dialogbarStereoOptions.png similarity index 100% rename from Documentation/Doxygen/DeveloperManual/API/Groups/dialogbarStereoOptions.png rename to Documentation/Doxygen/API/Groups/dialogbarStereoOptions.png diff --git a/Documentation/Doxygen/DeveloperManual/API/Groups/dialogbarbuttons.png b/Documentation/Doxygen/API/Groups/dialogbarbuttons.png similarity index 100% rename from Documentation/Doxygen/DeveloperManual/API/Groups/dialogbarbuttons.png rename to Documentation/Doxygen/API/Groups/dialogbarbuttons.png diff --git a/Documentation/Doxygen/DeveloperManual/API/Groups/functionalityButtons.png b/Documentation/Doxygen/API/Groups/functionalityButtons.png similarity index 100% rename from Documentation/Doxygen/DeveloperManual/API/Groups/functionalityButtons.png rename to Documentation/Doxygen/API/Groups/functionalityButtons.png diff --git a/Documentation/Doxygen/DeveloperManual/API/Groups/renderwindowOptions.png b/Documentation/Doxygen/API/Groups/renderwindowOptions.png similarity index 100% rename from Documentation/Doxygen/DeveloperManual/API/Groups/renderwindowOptions.png rename to Documentation/Doxygen/API/Groups/renderwindowOptions.png diff --git a/Documentation/Doxygen/DeveloperManual/API/Groups/renderwindows.png b/Documentation/Doxygen/API/Groups/renderwindows.png similarity index 100% rename from Documentation/Doxygen/DeveloperManual/API/Groups/renderwindows.png rename to Documentation/Doxygen/API/Groups/renderwindows.png diff --git a/Documentation/Doxygen/DeveloperManual/API/Groups/undoredobutton.png b/Documentation/Doxygen/API/Groups/undoredobutton.png similarity index 100% rename from Documentation/Doxygen/DeveloperManual/API/Groups/undoredobutton.png rename to Documentation/Doxygen/API/Groups/undoredobutton.png