diff --git a/Core/Documentation/Doxygen/Concepts/Concepts.dox b/Core/Documentation/Doxygen/Concepts/Concepts.dox
index 4caf8cec74..b371c3596e 100644
--- a/Core/Documentation/Doxygen/Concepts/Concepts.dox
+++ b/Core/Documentation/Doxygen/Concepts/Concepts.dox
@@ -1,17 +1,29 @@
 /**
 \page Concepts MITK concepts
 
 The following items describe some issues about MITK on a more abstract level. 
 
-If you want to start using MITK, you also want to see \ref Development
+-# \subpage OverviewPage
+-# Coding Concepts
+ -# General (Todo)
+ -# Coding Style (Todo)
+ -# Using Macros (Todo)
+ -# \subpage MicroServices_Overview
+-# Data Concepts
+ -# Data Storage (Todo)
+ -# \subpage PropertiesPage
+ -# \subpage GeometryOverviewPage
+-# \subpage QVTKRendering
+-# \subpage InteractionPage
+-# \subpage LoggingPage
+-# \subpage ExceptionPage
+-# Testing Concept
+ -# \subpage GeneralTests
+ -# \subpage RenderingTests
+-# Application Concept
+ -# General: MITK Applications (Todo)
+ -# Plug-Ins (Todo)
+ -# Perspective Concept (Todo)
 
-\li \subpage OverviewPage
-\li \subpage QVTKRendering
-\li \subpage InteractionPage
-\li \subpage ExceptionPage
-\li \subpage LoggingPage
-\li \subpage PropertiesPage
-\li \subpage GeometryOverviewPage
-\li \subpage MicroServices_Overview
-\li \subpage RenderingTests
+If you want to start using MITK, you also want to see the chapter \ref Development.
 */
diff --git a/Core/Documentation/Doxygen/Concepts/Overview.dox b/Core/Documentation/Doxygen/Concepts/Overview.dox
index 1891b083fb..8612b907fe 100644
--- a/Core/Documentation/Doxygen/Concepts/Overview.dox
+++ b/Core/Documentation/Doxygen/Concepts/Overview.dox
@@ -1,52 +1,52 @@
 /**
 
-\page OverviewPage Overview on the Medical Imaging Interaction Toolkit (MITK)
+\page OverviewPage Introduction: Overview on the Medical Imaging Interaction Toolkit (MITK)
  
 Four issues are important for advanced interactive medical imaging software:
 <ul>
  <li> the data, not only the original images, but also other data like segmentation results, 
 surfaces, vessel-trees, etc.,
  <li> the algorithms to extract information from the data or to generate new data,
  <li> the visualization of the data, which requires information about the position of the data 
 in space and time and 
  <li> to allow the user to conveniently interact with the data.
 </ul>
 
 Today, there are two major open-source toolkits for visualization and image processing:
 <ul>
  <li> the <a href="http://www.vtk.org">Visualization Toolkit (VTK)</a>, which provides "a wide variety 
 of visualization algorithms including scalar, vector, tensor, texture, and volumetric methods; 
 and advanced modeling techniques such as implicit modelling, polygon reduction, mesh smoothing, 
 cutting, contouring, and Delaunay triangulation. In addition, dozens of imaging algorithms have 
 been directly integrated to allow the user to mix 2D imaging / 3D graphics algorithms and data."
 (from the <a href="http://www.vtk.org">Visualization Toolkit (VTK)</a> ).
  <li> the <a href="http://www.itk.org">Insight Toolkit (ITK)</a>, which provides registration and 
 segmentation algorithms.
 </ul>
 
 ITK provides powerful algorithms, but is not designed for visualization or interaction. VTK has 
 powerful visualization capabilities, but only low-level support for interaction such as picking 
 methods, rotation, movement and scaling of objects. Support for high level interactions with data
 as, for example, the interactive construction and modification of deformable models, and 
 undo-capabilities is outside the scope of VTK. Furthermore, it is designed to create \em one 
 \em kind of view on the data. There is no special assistance to realized multiple, different 
 views of the data (as a multiplanar reconstruction and a 3D rendering). Finally, VTK supports only
 2D and 3D data, not 3D+t data, which are required for some medical applications, and there is 
 currently no convenient possibility to combine VTK with ITK.
 
 The aim of MITK is to use VTK and ITK, allow an easy combination of both and extend them with those 
 features, which are outside the scope of both.
 
 \section OverviewPage_DesignOverview Design Overview
 
 The basic design concept of MITK is model-view-controller (MVC). Although some people think MVC is 
 out-of-date, it is useful in this case (and also we do not really use pure MVC): we have data 
 (\em model), on which we want to have different @em views and we want to interact with the data 
 (\em controller), which should result in a simultaneous and consistent update of all views.
 
 <ul>
  <li> data management classes
  <li>
 </ul> 
 ...
  */
diff --git a/Core/Documentation/Doxygen/Concepts/Properties.dox b/Core/Documentation/Doxygen/Concepts/Properties.dox
index 1a9cb7236d..e0cba92da5 100644
--- a/Core/Documentation/Doxygen/Concepts/Properties.dox
+++ b/Core/Documentation/Doxygen/Concepts/Properties.dox
@@ -1,226 +1,226 @@
 /**
-\page PropertiesPage The MITK Property Concept
+\page PropertiesPage Properties
 
 \section PropertyConcept The Concept Behind MITK Properties
 
 Properties belong to a datanode and contain information relevant to the handling of the node by MITK. They provide a place to store additional information which is not part of the actual data, and as such have no reason to be contained within the data/file itself, but might be needed for such things as rendering (e.g. transfer functions) or interaction (e.g. the name of the node).
 
 Propteries can be read an set:
 
 \code
 mitk::ColorProperty::Pointer colorProperty = dynamic_cast<mitk::ColorProperty*>(node->GetProperty("color"));
 
 node->SetProperty( "IsTensorVolume", mitk::BoolProperty::New( true ) );
 \endcode
 
 \section ListOfIndependentProperty A List Of Module Independent Properties
 
 \subsection FileManagement File Management
 <ul>
   <li> path - The physical path the file was loaded from
   <li> name - The node name in the datamanager
   <li> selected - Whether the node is selected in the datamanager
 </ul>
 
 \subsection GenericRenderingProperty Generic Rendering Properties
 <ul>
   <li> color - Color the surface, grey value image, whatever should be rendered in (default is usually white). There is a special mitk::ColorProperty and you can use the Getter/Setter methods to access it. The color is defined with three values (RGB) in the range between 0.0 and 1.0. 
 \remark If you are inside a mapper you can use the following code to access 
 the color:
 \code
 float rgb[3]={1.0f, 1.0f, 1.0f};
 GetColor( rgb, BaseRenderer );
 \endcode
 (The BaseRenderer is usually known inside a mapper).
 
 \warning
 This property will not effect images if you set the property "use color" 
 to false. In that case a user-defined lookuptable will be used.
 
   <li> in plane resample extent by geometry - Toggles:
 Resampling grid corresponds to the current world geometry. This
 means that the spacing of the output 2D image depends on the
 currently selected world geometry, and *not* on the image itself.
   <li> Resampling grid corresponds to the input geometry. This means that
 the spacing of the output 2D image is directly derived from the
 associated input image, regardless of the currently selected world
 geometry.
   <li> layer - Controls which image is considered "on top" of another. In the case 
 that two should inhabit the same space, the higher layer occludes lower layer.
 So far it works for images and pointsets. The layer property applies only for similar datatypes. Pointsets are always rendered in front of images and the layer will not have any effect.
   <li> levelwindow - In general, grayscale images contain values between 0 and 255. Therefore, the default window boundaries are set respectively. For displaying the image within a certain range, ie. 50 - 200, this property can be used to adjust the minimum and maximum boundary.
   <li> LookupTable - This property contains a user defined lookuptable, which can be used to map scalar values to color values. Example: If an image contains a value of 128, in the resulting image the passed lookuptable could map this value to red (255, 0, 0).
 
   \warning
 This property will not effect images if you set the property "use color" 
 to true. In that case color properties and a default lookuptable are used.
 
 Example for setting up a lookuptable in MITK:
 \code
 #include <vtkSmartPointer.h>
 #include <vtkLookupTable.h>
 #include <mitkLookupTable.h>
 #include <mitkLookupTableProperty.h>
 
 [...]
 
 vtkSmartPointer<vtkLookupTable> vtkLUT = vtkSmartPointer<vtkLookupTable>::New();
 vtkLUT->SetRange(100,200); //define your table here
 vtkLUT->Build();
 
 //pass the table to MITK
 mitk::LookupTable::Pointer mitkLookupTable = mitk::LookupTable::New();
 mitkLookupTable->SetVtkLookupTable(vtkLUT);
 mitk::LookupTableProperty::Pointer LookupTableProp = mitk::LookupTableProperty::New( mitkLookupTable );
 
 result->SetProperty( "LookupTable", LookupTableProp );
 result->SetBoolProperty("use color", false);
 result->Update();
 \endcode
   <li> opacity - Alpha (or transparency) value of the node/image/surface etc.. The
 range of the opacity is between 0.0 and 1.0. 
 
 \remark 
 If you are inside a mapper you can use the following code to access 
 the opacity:
 \code
 float opacity=1.0f;
 GetOpacity( opacity, BaseRenderer );
 \endcode
 (The BaseRenderer is usually known inside a mapper).
 
 
   <li> reslice interpolation - This property takes effect in swivel mode or crosshair rotaiton  only. The interpolation modes "Nearest", "Linear", and "Cubic" are available and  effect the pixel outcome along the rotated plane.
   <li> texture interpolation - This property toggles interpolation of the texture. If enabled, edges between image pixels are blurred. If disabled, edges remain sharp.
   <li> use color - This property toggles the use of a user-defined lookuptable 
 for the rendering. True: use the LUT; False: use the color propery.
 Example for setting up a lookuptable in MITK:
 \code
 #include <vtkSmartPointer.h>
 #include <vtkLookupTable.h>
 #include <mitkLookupTable.h>
 #include <mitkLookupTableProperty.h>
 
 [...]
 
 vtkSmartPointer<vtkLookupTable> vtkLUT = vtkSmartPointer<vtkLookupTable>::New();
 vtkLUT->SetRange(100,200); //define your table here
 vtkLUT->Build();
 
 //pass the table to MITK
 mitk::LookupTable::Pointer mitkLookupTable = mitk::LookupTable::New();
 mitkLookupTable->SetVtkLookupTable(vtkLUT);
 mitk::LookupTableProperty::Pointer LookupTableProp = mitk::LookupTableProperty::New( mitkLookupTable );
 
 result->SetProperty( "LookupTable", LookupTableProp );
 result->SetBoolProperty("use color", false);
 result->Update();
 \endcode
   <li> visible - toggle node/image/surface being rendered at all
 </ul>
   
 \subsection SurfaceRenderingProperties Surface Rendering Properties
 
 <ul>
   <li> back color - in 2D, color of the normals outside the surface
   <li> back normal lenth (px) - in 2D, length of the normals in pixels 
 (When decreasing it the color using the front color is shorter?)
   <li> color mode -  (From VTK) Control how the scalar data is mapped to colors. By default (ColorModeToDefault), unsigned char scalars are treated as colors, and NOT mapped through the lookup table, while everything else is. Setting ColorModeToMapScalars means that all scalar data will be mapped through the lookup table.
   <li> draw normals 2d -  in 2D, toggles the presence of normals
   <li> front color - in 2D, color of the normals inside the surface
   <li> front normal lenth (px) - in 2D, length of the normals in pixels 
 (When decreasing it the color using the back color is shorter?)
   <li> invert normals - in 2D, switch front/back normals
   <li> line width - in 2D, controls the thickness of the line where the surface
 intersects the plane (and normals)
   <li> material.ambientCoefficient - in 3D ambient lighting
   <li> material.diffuseCoefficient - in 3D scattering of light
   <li> material.interpolation - Choose which interpolation algorithm to use for
 surface construction
   <li> material.representation - Choose the representation to draw the mesh in
 (Surface, Wireframe, Point Cloud)
   <li> material.specularCoefficient - in-/decrease non-scattered reflection
   <li> material.specularPower - control percentage of non-scattered reflection 
   <li> material.wireframeLineWidth - width of the wires if wireframe representation is
   <li> scalar mode - (From VTK) Control how the filter works with scalar point data and cell attribute data. By default (ScalarModeToDefault), the filter will use point data, and if no point data is available, then cell data is used. Alternatively you can explicitly set the filter to use point data (ScalarModeToUsePointData) or cell data (ScalarModeToUseCellData). You can also choose to get the scalars from an array in point field data (ScalarModeToUsePointFieldData) or cell field data (ScalarModeToUseCellFieldData). If scalars are coming from a field data array, you must call SelectColorArray before you call GetColors. When ScalarMode is set to use Field Data (ScalarModeToFieldData), you must call SelectColorArray to choose the field data array to be used to color cells. In this mode, if the poly data has triangle strips, the field data is treated as the celldata for each mini-cell formed by a triangle in the strip rather than the entire strip. 
   <li> scalar visibility - (From VTK) Turn on/off flag to control whether scalar data is used to color objects. 
   <li> selected - whether the node is selected
   <li> shader - which shader to use for surface rendering, currently the options are
 "fixed" and "mitkShaderLightning"
 </ul>
 
 \subsection VolumeRenderingProperties Volume Rendering Properties
 
 <ul>
   <li> TransferFunction - contains transfer function for use in coloring image
   <li> volumerendering -  Should the volume be rendered or not
   <li> volumerendering configuration - Choice between Composite und MIP
   <li> volumerendering.cpu.ambient - ambient lighting
   <li> volumerendering.cpu.diffuse - in-/decrease light dispersion
   <li> volumerendering.cpu.specular - in-/decrease non-scattered reflection
   <li> volumerendering.cpu.specular.power - control percentage of non-scattered
 reflection 
   <li> volumerendering.gpu.ambient - same as cpu with gpu
   <li> volumerendering.gpu.diffuse - same as cpu with gpu
   <li> volumerendering.gpu.reducesliceartifacts - Reduce slice artifacts
   <li> volumerendering.gpu.specular - same as cpu with gpu
   <li> volumerendering.gpu.specular.power - same as cpu with gpu
   <li> volumerendering.gpu.usetexturecompression - use texture compression
   <li> volumerendering.ray.ambient - same as cpu with ray
   <li> volumerendering.ray.diffuse - same as cpu with ray
   <li> volumerendering.ray.specular - same as cpu with ray
   <li> volumerendering.ray.specular.power - same as cpu with ray
   <li> volumerendering.usegpu -  Whether to use the GPU for rendering or not
   <li> volumerendering.uselod -  Whether to use the Level Of Detail mechanism or not
   <li> volumerendering.usemip -  Whether to utilize maximum intensity projection
   <li> volumerendering.useray - Whether to use raycasting or not
 </ul>
   
 \remark
 Uselod can be active with usegpu, usemip, useray, but any of the latter can not
 be used with another one of them.
 
 
 \subsection PointSetProperties Point Set Properties
 
 <ul>
   <li> close contour - Toggles whether the first and the last point of a contour
 (connecting pieces between following points of a pointset) are connected.
   <li> contourcolor - Determines the color of the contour (connecting pieces between
 following points of a pointset). Visible only if "show contour" is active.
   <li> contoursize - Represents the diameter of the contour (which is kind of a tube
 between the following points of a pointset). Visible only if "show contour" is
 active.
   <li> distance decimal digits - Sets the number of decimal places for the euclidean
 point to point distance which can be displayed by activating "show distances". 
   <li> point 2D size - The positions of points in the 2D view are represented by
 crosses. "point 2D size" determines the size of this crosses.
   <li> point line width - The positions of points in the 2D view are represented by
 crosses. "point line width" determines the thickness of this crosses. 
   <li> pointsize - The positions of points in the 3D view are represented by spheres.
 "pointsize" determines the diameter (size) of this spheres.
   <li> selectedcolor - Sets the color for selected points from a pointset.
   <li> show angles - If "show contour" is active the angles between two contour parts
 can be shown.
   <li> show contour - Connects following points of a pointset by drawing connecting
 pieces between this points.
   <li> show distance lines - Shows all angles and lines of the contour (in 2D views)
 even if they are not on the view's current slice.
   <li> show distances - Draws lines between following points (in 2D views) and
 displays the euclidean distance between this points.
   <li> show points - Toggles if the points are visible or not in the view.
   <li> updateDataOnRender - If "true" the pointset is updated before rendering. If the
 pointset is part of a filter pipeline this also causes an update to the
 pipeline which sometimes may be not desired so it can be switched of by setting
 it to false.
 </ul>
 
 Information on properties not in this list can be found in the appropriate module.
 
 \subsection PropertiesPageSeeAlso See Also
 
 <ul>
  <li> \subpage PlanarPropertiesPage
  <li> \subpage SegmentationPropertiesPage
 </ul>
 */
diff --git a/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox b/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox
index 1f1f070925..4529f5c291 100644
--- a/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox
+++ b/Core/Documentation/Doxygen/Concepts/QVTKRendering.dox
@@ -1,107 +1,107 @@
 /**
 
-\page QVTKRendering Rendering in MITK by means of the QT-VTK widget
+\page QVTKRendering Rendering Concept
 
-\brief This page describes the MITK rendering mechanism switching to the QTVTK widget. MITK releases with version > 0.8 use this new rendering pipeline. Several changes in contrast to the established old rendering pipeline are explained in the following.
+\brief <B> Rendering in MITK by means of the QT-VTK widget. </B> This page describes the MITK rendering mechanism switching to the QTVTK widget. MITK releases with version > 0.8 use this new rendering pipeline. Several changes in contrast to the established old rendering pipeline are explained in the following.
 
 
 
 
 \section QVTKRendering_Pipeline_VTK VTK Rendering Pipeline
 
 \image html RenderingOverviewVTK.png "Rendering in VTK"
 
 \li In VTK, the vtkRenderWindow coordinates the rendering process. Several vtkRenderers may be associated to one vtkRenderWindow. 
 \li All visible objects, which can exist in a rendered scene (2D and 3D scene), inherit from vtkProp.
 \li A vtkPropAssembly is an assembly of several vtkProps, which appears like one single vtkProp.
 \li MITK uses a new interface class, the "vtkMitkRenderProp", which is inherited from vtkProp. Similar to a vtkPropAssembly, all MITK rendering stuff is performed via this interface class.
 \li Thus, the MITK rendering process is completely integrated into the VTK rendering pipeline. From VTK point of view, MITK renders like a custom vtkProp object.
 
 More information about the VTK rendering pipeline can be found at http://www.vtk.org and in the several VTK books.
 
 
 
 \section QVTKRendering_Pipeline_MITK MITK Rendering Pipeline
 
 In contrast to the former MITK rendering pipeline, the new process is tightly connected to VTK, which makes it straight forward and simple.
 In consequence, several MITK classes have been dropped out:
 
 \li Qmitk::SelectableGLWidget and all inheritors
 \li mitk::RenderWindow
 \li mitk::VtkRenderWindow and all inheritors 
 \li mitk::OpenGLRenderer
 \li mitk::SimpleTextRendering
 
 Instead, we use the above mentioned "vtkMitkRenderProp" in conjunction with a new mitk::VtkPropRenderer for integration into the VTK pipeline. Also, the QmitkRenderWindow does not inherit
 from mitk::RenderWindow, but from the QVTKWidget, which is provided by VTK.
 
 The main classes of the MITK rendering process can be illustrated like this:
 
 \image html qVtkRenderingClassOverview.png "Rendering in MITK"
 
 A render request to the vtkRenderWindow does not only update the VTK pipeline, but also the MITK pipeline. However, the mitk::RenderingManager still coordinates the rendering update behaviour.
 Update requests should be sent to the RenderingManager, which then, if needed, will request an update of the overall vtkRenderWindow. The vtkRenderWindow then starts to call the Render() function
 of all vtkRenderers, which are associated to the vtkRenderWindow. Currently, MITK uses specific vtkRenderers (outside the standard MITK rendering pipeline) for purposes, like displaying a gradient 
 background (mitk::GradientBackground), displaying video sources (QmitkVideoBackround and mitk::VideoSource), or displaying a (department) logo (mitk::ManufacturerLogo), etc. Despite these specific
 renderers, a kind of "SceneRenderer" is member of each QmitkRenderWindow. This vtkRenderer is associated with the custom vtkMitkRenderProp and is responsible for the MITK rendering.
 
 A sequence diagramm, which illustrates the actions after calling the Render() function of the MITK-Scene vtkRenderer is shown below:
 
 \image html qVtkRenderingSequence.png "Sequence overview MITK scene rendering"
 
 
 
 
 \section QVTKRendering_programmerGuide User Guide: Changes in programming of rendering related stuff
 
 \li Within a functionality the vtkRenderWindow can be accessed like this: vtkRenderWindow* vtkRenWin    = m_MultiWidget->mitkWidget4->GetRenderWindow();
 \li Within a functionality the mitkBaseRenderer can be accessed like this: mitk::BaseRenderer* renderer  = mitk::BaseRenderer::GetInstance(m_MultiWidget->mitkWidget4->GetRenderWindow());
 \li An update request of the overall QmitkStdMultiWidget can be performed with: m_MultiWidget->RequestUpdate();
 \li An update of the overall QmitkStdMultiWidget can be forced with: m_MultiWidget->ForceImmediateUpdate();
 \li A single QmitkRenderWindow update request can be done like this: mitk::RenderingManager::GetInstance()->RequestUpdate(m_MultiWidget->mitkWidget4->GetRenderWindow());
 \li A single QmitkRenderWindow update can be forced like this: mitk::RenderingManager::GetInstance()->ForceImmediateUpdate(m_MultiWidget->mitkWidget4->GetRenderWindow());
 \li Getting a BaseRenderer by the widget name can be done like this: mitk::BaseRenderer::GetByName("mitkWidget1"); 
 
 
 \subsection QVTKRendering_distinctRenderWindow Setting up a distinct Rendering-Pipeline
 
 It is sometimes desired to have one (or more) QmitkRenderWindows that are managed totally independent of the 'usual' renderwindows defined by the QmitkStdMultiWidget.
 This may include the data that is rendered as well as possible interactions. In order to achieve this, a set of objects is needed:
 
 \li mitk::RenderingManager   -> Manages the rendering
 \li mitk::DataStorage        -> Manages the data that is rendered
 \li mitk::GlobalInteraction  -> Manages all interaction
 \li QmitkRenderWindow        -> Actually visualizes the data
 
 The actual setup, respectively the connection, of these classes is rather simple:
 
 \code
 // create a new instance of mitk::RenderingManager
 mitk::RenderingManager::Pointer renderingManager = mitk::RenderingManager::New();
 
 // create new instances of DataStorage and GlobalInteraction
 mitk::DataStorage::Pointer dataStorage = mitk::DataStorage::New();
 mitk::GlobalInteraction::Pointer globalInteraction = mitk::GlobalInteraction::New();
 
 // add both to the RenderingManager
 renderingManager->SetDataStorage( dataStorage );
 renderingManager->SetGlobalInteraction( globalInteraction );
 
 // now create a new QmitkRenderWindow with this renderingManager as parameter
 QmitkRenderWindow* renderWindow = new QmitkRenderWindow( parent, "name", renderer, renderingManager );
 
 \endcode
 
 That is basically all you need to setup your own rendering pipeline.
 Obviously you have to add all data you want to render to your new DataStorage. If you want to interact with this renderwindow, you will also have
 to add additional Interactors/Listeners.
 
 Note:
 
 \li Dynamic casts of a mitk::BaseRenderer class to an OpenGLRenderer (or now, to an VtkPropRenderer) should be avoided. The "MITK Scene" vtkRenderer and the vtkRenderWindow as well, are
 therefore now included in the mitk::BaseRenderer.
 
 
 
 
 */
diff --git a/Core/Documentation/Doxygen/Concepts/TestsGeneral.dox b/Core/Documentation/Doxygen/Concepts/TestsGeneral.dox
new file mode 100644
index 0000000000..554920d4f2
--- /dev/null
+++ b/Core/Documentation/Doxygen/Concepts/TestsGeneral.dox
@@ -0,0 +1,4 @@
+/**
+\page GeneralTests General: Tests in MITK
+TODO
+*/