diff --git a/Documentation/Doxygen/Concepts.dox b/Documentation/Doxygen/Concepts.dox index fa551a35df..1097534deb 100644 --- a/Documentation/Doxygen/Concepts.dox +++ b/Documentation/Doxygen/Concepts.dox @@ -1,11 +1,12 @@ /** \page Concepts MITK concepts The following items describe some issues about MITK on a more abstract level. If you want to start using MITK, you also want to see \ref Development -\li \ref OverviewPage -\li \ref InteractionPage -\li \ref Rendering +\li \subpage OverviewPage +\li \subpage InteractionPage +\li \subpage Rendering +\li \subpage PropertiesPage */ diff --git a/Documentation/Doxygen/Development.dox b/Documentation/Doxygen/Development.dox index 405ec44af9..5aa2dbf440 100644 --- a/Documentation/Doxygen/Development.dox +++ b/Documentation/Doxygen/Development.dox @@ -1,15 +1,16 @@ /** \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 -\li \ref DirectoryStructurePage -\li \ref BuildInstructionsPage -\li \ref TutorialPage -\li \ref StylesAndNotesPage -\li \ref NewPluginPage \endQT4 -\li \ref KnownProblemsPage +\li \subpage DirectoryStructurePage +\li \subpage BuildInstructionsPage +\li \subpage TutorialPage +\li \subpage StylesAndNotesPage +\li \subpage NewPluginPage \endQT4 +\li \subpage KnownProblemsPage +\li \subpage thirdpartylibs */ diff --git a/Documentation/Doxygen/ModuleList.dox b/Documentation/Doxygen/ModuleList.dox new file mode 100644 index 0000000000..783e3d3e87 --- /dev/null +++ b/Documentation/Doxygen/ModuleList.dox @@ -0,0 +1,40 @@ +/** +\page ModuleListPage MITK Modules + +\section ModuleListPageOverview Overview + +The modules 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 modules as needed. + +The distinction between developer and end user use is for convenience only and mainly distinguishes which group a module is primarily aimed at. + +\section ModuleListPageEndUserModuleList List of Modules for End User Use + + \li \subpage org.basicimageprocessing + \li \subpage org.colourimageprocessing + \li \subpage org.datamanager + \li \subpage org.diffusion + \li \subpage IGTGeneralModulePage + \li \subpage org.imagecropper + \li \subpage org.imagenavigator + \li \subpage org.imagestatistics + \li \subpage org.isosurface + \li \subpage org.measure + \li \subpage org.moviemaker + \li \subpage org.pointsetinteraction + \li \subpage RegistrationModuleOverviewPage + \li \subpage org.segment + \li \subpage org.simplemeasurement + \li \subpage org.volvis + +\section ModuleListPageDevModuleList List of Modules for Developer Use and Examples + + \li \subpage org.mitk.gui.qt.navigationdataplayer + \li \subpage org.regiongrowing + \li \subpage org.simpleexample + \li \subpage org.surfacematerialeditor + \li \subpage org.mitk.gui.qt.toftutorial + \li \subpage org.videoplayer + \li \subpage org.viewinitialitzation + + +*/ \ No newline at end of file diff --git a/Documentation/Doxygen/Modules.dox b/Documentation/Doxygen/Modules.dox index c25155d7e2..4776c93d90 100644 --- a/Documentation/Doxygen/Modules.dox +++ b/Documentation/Doxygen/Modules.dox @@ -1,128 +1,115 @@ /** \defgroup Data Data Classes \ingroup DataManagement \brief This subcategory includes the data classes, e.g., for images (mitk::Image), surfaces (mitk::Surface), vessel-trees (mitk::VesselTreeData), etc. Data access classes are only included, if there is no equivalent in itk (see \ref ProcessAndAdaptorClasses "Process and Adaptor Classes" below). */ /** \defgroup IO IO Classes \ingroup DataManagement \brief This subcategory includes the IO classes to read or write data objects. */ /** \defgroup DataStorage Data Storage Classes \ingroup DataManagement \brief This subcategory includes the classes to store and retrieve objects from the mitk::DataStorage */ /** \defgroup ProcessAdaptor Process and Adaptor Classes \anchor ProcessAndAdaptorClasses \brief This category includes process (algorithm) classes developed specifically for mitk and (mainly) adaptor classes for the integration of algorithms from other toolkits (currently vtk, itk). The itk adaptor classes are also useful for data access to mitk data objects. */ /** \defgroup Process Process Classes \ingroup ProcessAdaptor \brief This subcategory includes process (algorithm) classes developed specifically for mitk. */ /** \defgroup InteractionUndo Interaction and Undo Classes \brief This category includes classes that support the developer to create software that allows the user to interact with the data. This includes complex interactions that have multiple states (e.g., moving a handle of an active contour vs changing its local elasicity) and a concept to realize an undo/redo-mechanism. A detailed description of the rationale for these classes can be found in \ref InteractionPage. */ /** \defgroup Interaction Interaction Classes \ingroup InteractionUndo \brief This subcategory includes interaction classes (subclasses of mitk::StateMachine) that change the data according to the input of the user. For undo-support, the change is done by sending an OperationEvent to the respective data object, which changes itself accordingly. A detailed description of the rationale for these classes can be found in \ref InteractionPage. */ /** \defgroup Undo Undo Classes \ingroup InteractionUndo \brief This subcategory includes the undo/redo-specific classes. For undo-support, the change is done by sending an OperationEvent to the respective data object, which changes itself accordingly. A detailed description of the rationale for these classes can be found in \ref InteractionPage. */ /** \defgroup ToolManagerEtAl Classes related to the Segmentation bundle \brief A couple of classes related to the Segmentation bundle. See also \ref QmitkSegmentationTechnicalPage */ /** \defgroup Registration Registration \brief A couple of classes related to registration. */ /** \defgroup RigidRegistration Classes related to rigid registration \ingroup Registration \brief A couple of classes related to rigid registration. */ /** \defgroup PointBasedRegistration Classes related to point based registration \ingroup Registration \brief A couple of classes related to point based registration. */ /** \defgroup MITKPlugins MITK Plugins \brief This group includes all MITK Plugins */ - -/** - \page MITKProperties MITK Properties - - Very general information on MITK properties and an overview of some which are not specific to a certain module can be found in \ref PropertiesPage . - - For more specific information on a properties introduced by a certain module consults the appropriate module page. - - See also: - - \subpage PropertiesPage - -*/ diff --git a/Documentation/Doxygen/Modules/ModuleAdaptors.dox b/Documentation/Doxygen/Modules/ModuleAdaptors.dox index b720121389..c00107bc16 100644 --- a/Documentation/Doxygen/Modules/ModuleAdaptors.dox +++ b/Documentation/Doxygen/Modules/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 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 Limitations. +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 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 (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 Limitations Limitations +\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/NewPlugin.dox b/Documentation/Doxygen/NewPlugin.dox index 29cb922719..e0427d610d 100755 --- a/Documentation/Doxygen/NewPlugin.dox +++ b/Documentation/Doxygen/NewPlugin.dox @@ -1,95 +1,95 @@ /** \page NewPluginPage How to create a new MITK Plug-in The MITK Plugin Generator is a command line tool to simplify the process of creating your own MITK project (optional) and plug-ins. It can either be downloaded here or used from an existing MITK build. The Plugin Generator takes the following command line arguments: \verbatim ./MITKPluginGenerator -h A CTK plug-in generator for MITK -h, --help Show this help text -o, --out-dir Output directory (default: /tmp) -l, --license Path to a file containing license information (default: :/MITKLicense.txt) -v, --vendor The vendor of the generated code (default: DKFZ, Medical and Biological Informatics) -q, --quiet Do not print additional information -y, --confirm-all Answer all questions with 'yes' Plug-in View options -vc, --view-class The View's' class name -vn, --view-name The View's human readable name Plug-in options -ps, --plugin-symbolic-name The plugin's symbolic name -pn, --plugin-name The plug-in's human readable name Project options --project-copyright Path to a file containing copyright information (default: :/MITKCopyright.txt) --project-name The project name --project-app-name The application name \endverbatim If a project name is provided via the --project-name argument, the new plug-in will be generated as part of a new project. \section NewPluginOnly Creating a new MITK plug-in Here is an example call to the Plugin Generator, creating one plug-in with the symbolic name com.mycompany.myplugin and a View named My View: \verbatim ./MITKPluginGenerator --plugin-symbolic-name org.mycompany.myplugin --view-name "My View" \endverbatim If you did not already specify the final location of the plug-in via the --out-dir argument, move the directory (in our example /tmp/org.mycompany.myplugin) to your existing project. Do not forget to add the plug-in in your project's build system (usually in the file <your-project>/Plugins/Plugins.cmake). \section NewPluginWithProject Creating a new MITK project \subsection NewPluginProjectPrerequisites Prerequisites You need: -# Git from http://git-scm.com (there are also numerous third-party graphical clients available) -# CMake (version 2.8.4 or higher) -# Qt 4.x if you plan to develop Qt-based applications (version 4.5 or above is recommended, we cannot guarantee compatibility with lower versions) Here is an example call to the Plugin Generator, creating the same plug-in as above but integrated in a new project: \verbatim ./MITKPluginGenerator --plugin-symbolic-name org.mycompany.myplugin --view-name "My View" --project-name "MyProject" --project-app-name "MyApp" \endverbatim The generated project is completely self-contained and can be configured via CMake immediately. When building the generated project, it will first download all required dependencies (like MITK itself). For an explanation of the project's build directory layout, see SetupAMITKBasedProject. -\section Limitations +\section NewPluginLimitations The Plugin Generator supports only a very limited set of possible configuration options. For more customizations of your project or plug-in, you must familiarize yourself with CMake and the generated build system. Further, the generator is not able to modify existing projects, it can only create new ones. -\section BuildSystem Build system for plug-ins +\section NewPluginBuildSystem Build system for plug-ins Just put new files in your plug-in's \c src or \c src/internal directory and edit the \c files.cmake file there. If you have any fancy stuff like external libraries and include directories you should have a look at the CMake manual and general MITK build system documentation. -\section Troubleshooting Troubleshooting +\section NewPluginTroubleshooting Troubleshooting \par I get "Could not find library" messages and similar stuff when I try to start my project's executable. This is mostly due to wrong environment settings. On Windows, make sure that you use the supplied batch files to start Visual Studio or your project's executable. If you still get errors, double check the value of the PATH variable in your batch files (it must contain MITK's binary directory and paths to the ITK, VTK and Qt libraries. \par On Linux, set your LD_LIBRARY_PATH variable accordingly. */ diff --git a/Documentation/Doxygen/Properties.dox b/Documentation/Doxygen/Properties.dox index 8c3fc516fd..1ce4727bec 100644 --- a/Documentation/Doxygen/Properties.dox +++ b/Documentation/Doxygen/Properties.dox @@ -1,218 +1,219 @@ /** \page PropertiesPage The MITK Property Concept \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(node->GetProperty("color")); node->SetProperty( "IsTensorVolume", mitk::BoolProperty::New( true ) ); \endcode \section ListOfIndependentProperty A List Of Module Independent Properties \subsection FileManagement File Management
  • path - The physical path the file was loaded from
  • name - The node name in the datamanager
  • selected - Whether the node is selected in the datamanager
\subsection GenericRenderingProperty Generic Rendering Properties
  • color - Color the surface, grey value image, whatever should be rendered in (default is usually white). There is a special mitk::ColorProperty and you can use the Getter/Setter methods to access it. The color is defined with three values (RGB) in the range between 0.0 and 1.0. \remark If you are inside a mapper you can use the following code to access the color: \code float rgb[3]={1.0f, 1.0f, 1.0f}; GetColor( rgb, BaseRenderer ); \endcode (The BaseRenderer is usually known inside a mapper). \warning This property will not effect images if you set the property "use color" to false. In that case a user-defined lookuptable will be used.
  • in plane resample extent by geometry - Toggles: Resampling grid corresponds to the current world geometry. This means that the spacing of the output 2D image depends on the currently selected world geometry, and *not* on the image itself.
  • Resampling grid corresponds to the input geometry. This means that the spacing of the output 2D image is directly derived from the associated input image, regardless of the currently selected world geometry.
  • layer - Controls which image is considered "on top" of another. In the case that two should inhabit the same space, the higher layer occludes lower layer. So far it works for images and pointsets. The layer property applies only for similar datatypes. Pointsets are always rendered in front of images and the layer will not have any effect.
  • levelwindow - In general, grayscale images contain values between 0 and 255. Therefore, the default window boundaries are set respectively. For displaying the image within a certain range, ie. 50 - 200, this property can be used to adjust the minimum and maximum boundary.
  • LookupTable - This property contains a user defined lookuptable, which can be used to map scalar values to color values. Example: If an image contains a value of 128, in the resulting image the passed lookuptable could map this value to red (255, 0, 0). \warning This property will not effect images if you set the property "use color" to true. In that case color properties and a default lookuptable are used. Example for setting up a lookuptable in MITK: \code #include #include #include #include [...] vtkSmartPointer vtkLUT = vtkSmartPointer::New(); vtkLUT->SetRange(100,200); //define your table here vtkLUT->Build(); //pass the table to MITK mitk::LookupTable::Pointer mitkLookupTable = mitk::LookupTable::New(); mitkLookupTable->SetVtkLookupTable(vtkLUT); mitk::LookupTableProperty::Pointer LookupTableProp = mitk::LookupTableProperty::New( mitkLookupTable ); result->SetProperty( "LookupTable", LookupTableProp ); result->SetBoolProperty("use color", false); result->Update(); \endcode
  • opacity - Alpha (or transparency) value of the node/image/surface etc.. The range of the opacity is between 0.0 and 1.0. \remark If you are inside a mapper you can use the following code to access the opacity: \code float opacity=1.0f; GetOpacity( opacity, BaseRenderer ); \endcode (The BaseRenderer is usually known inside a mapper).
  • reslice interpolation - This property takes effect in swivel mode or crosshair rotaiton only. The interpolation modes "Nearest", "Linear", and "Cubic" are available and effect the pixel outcome along the rotated plane.
  • texture interpolation - This property toggles interpolation of the texture. If enabled, edges between image pixels are blurred. If disabled, edges remain sharp.
  • use color - This property toggles the use of a user-defined lookuptable for the rendering. True: use the LUT; False: use the color propery. Example for setting up a lookuptable in MITK: \code #include #include #include #include [...] vtkSmartPointer vtkLUT = vtkSmartPointer::New(); vtkLUT->SetRange(100,200); //define your table here vtkLUT->Build(); //pass the table to MITK mitk::LookupTable::Pointer mitkLookupTable = mitk::LookupTable::New(); mitkLookupTable->SetVtkLookupTable(vtkLUT); mitk::LookupTableProperty::Pointer LookupTableProp = mitk::LookupTableProperty::New( mitkLookupTable ); result->SetProperty( "LookupTable", LookupTableProp ); result->SetBoolProperty("use color", false); result->Update(); \endcode
  • visible - toggle node/image/surface being rendered at all
\subsection SurfaceRenderingProperties Surface Rendering Properties
  • back color - in 2D, color of the normals outside the surface
  • back normal lenth (px) - in 2D, length of the normals in pixels (When decreasing it the color using the front color is shorter?)
  • color mode - (From VTK) Control how the scalar data is mapped to colors. By default (ColorModeToDefault), unsigned char scalars are treated as colors, and NOT mapped through the lookup table, while everything else is. Setting ColorModeToMapScalars means that all scalar data will be mapped through the lookup table.
  • draw normals 2d - in 2D, toggles the presence of normals
  • front color - in 2D, color of the normals inside the surface
  • front normal lenth (px) - in 2D, length of the normals in pixels (When decreasing it the color using the back color is shorter?)
  • invert normals - in 2D, switch front/back normals
  • line width - in 2D, controls the thickness of the line where the surface intersects the plane (and normals)
  • material.ambientCoefficient - in 3D ambient lighting
  • material.diffuseCoefficient - in 3D scattering of light
  • material.interpolation - Choose which interpolation algorithm to use for surface construction
  • material.representation - Choose the representation to draw the mesh in (Surface, Wireframe, Point Cloud)
  • material.specularCoefficient - in-/decrease non-scattered reflection
  • material.specularPower - control percentage of non-scattered reflection
  • material.wireframeLineWidth - width of the wires if wireframe representation is
  • scalar mode - (From VTK) Control how the filter works with scalar point data and cell attribute data. By default (ScalarModeToDefault), the filter will use point data, and if no point data is available, then cell data is used. Alternatively you can explicitly set the filter to use point data (ScalarModeToUsePointData) or cell data (ScalarModeToUseCellData). You can also choose to get the scalars from an array in point field data (ScalarModeToUsePointFieldData) or cell field data (ScalarModeToUseCellFieldData). If scalars are coming from a field data array, you must call SelectColorArray before you call GetColors. When ScalarMode is set to use Field Data (ScalarModeToFieldData), you must call SelectColorArray to choose the field data array to be used to color cells. In this mode, if the poly data has triangle strips, the field data is treated as the celldata for each mini-cell formed by a triangle in the strip rather than the entire strip.
  • scalar visibility - (From VTK) Turn on/off flag to control whether scalar data is used to color objects.
  • selected - whether the node is selected
  • shader - which shader to use for surface rendering, currently the options are "fixed" and "mitkShaderLightning"
\subsection VolumeRenderingProperties Volume Rendering Properties
  • TransferFunction - contains transfer function for use in coloring image
  • volumerendering - Should the volume be rendered or not
  • volumerendering configuration - Choice between Composite und MIP
  • volumerendering.cpu.ambient - ambient lighting
  • volumerendering.cpu.diffuse - in-/decrease light dispersion
  • volumerendering.cpu.specular - in-/decrease non-scattered reflection
  • volumerendering.cpu.specular.power - control percentage of non-scattered reflection
  • volumerendering.gpu.ambient - same as cpu with gpu
  • volumerendering.gpu.diffuse - same as cpu with gpu
  • volumerendering.gpu.reducesliceartifacts - Reduce slice artifacts
  • volumerendering.gpu.specular - same as cpu with gpu
  • volumerendering.gpu.specular.power - same as cpu with gpu
  • volumerendering.gpu.usetexturecompression - use texture compression
  • volumerendering.ray.ambient - same as cpu with ray
  • volumerendering.ray.diffuse - same as cpu with ray
  • volumerendering.ray.specular - same as cpu with ray
  • volumerendering.ray.specular.power - same as cpu with ray
  • volumerendering.usegpu - Whether to use the GPU for rendering or not
  • volumerendering.uselod - Whether to use the Level Of Detail mechanism or not
  • volumerendering.usemip - Whether to utilize maximum intensity projection
  • volumerendering.useray - Whether to use raycasting or not
\remark Uselod can be active with usegpu, usemip, useray, but any of the latter can not be used with another one of them. \subsection PointSetProperties Point Set Properties
  • close contour - Toggles whether the first and the last point of a contour (connecting pieces between following points of a pointset) are connected.
  • contourcolor - Determines the color of the contour (connecting pieces between following points of a pointset). Visible only if "show contour" is active.
  • contoursize - Represents the diameter of the contour (which is kind of a tube between the following points of a pointset). Visible only if "show contour" is active.
  • distance decimal digits - Sets the number of decimal places for the euclidean point to point distance which can be displayed by activating "show distances".
  • point 2D size - The positions of points in the 2D view are represented by crosses. "point 2D size" determines the size of this crosses.
  • point line width - The positions of points in the 2D view are represented by crosses. "point line width" determines the thickness of this crosses.
  • pointsize - The positions of points in the 3D view are represented by spheres. "pointsize" determines the diameter (size) of this spheres.
  • selectedcolor - Sets the color for selected points from a pointset.
  • show angles - If "show contour" is active the angles between two contour parts can be shown.
  • show contour - Connects following points of a pointset by drawing connecting pieces between this points.
  • show distance lines - Shows all angles and lines of the contour (in 2D views) even if they are not on the view's current slice.
  • show distances - Draws lines between following points (in 2D views) and displays the euclidean distance between this points.
  • show points - Toggles if the points are visible or not in the view.
  • updateDataOnRender - If "true" the pointset is updated before rendering. If the pointset is part of a filter pipeline this also causes an update to the pipeline which sometimes may be not desired so it can be switched of by setting it to false.
+Information on properties not in this list can be found in the appropriate module. */ diff --git a/Documentation/Doxygen/Tutorial/Tutorial.dox b/Documentation/Doxygen/Tutorial/Tutorial.dox index 22e1981483..224705cbaa 100644 --- a/Documentation/Doxygen/Tutorial/Tutorial.dox +++ b/Documentation/Doxygen/Tutorial/Tutorial.dox @@ -1,34 +1,34 @@ /** \page TutorialPage The MITK Tutorial This tutorial gives an introduction to MITK. We will start with the first steps of just compiling what you get after downloading MITK, continue to show how to display and do basic interaction with images, and finally show how to build an application module (functionality). The source code of the examples can be found in mitk/QApplications/Tutorial/ \n Two data files are used to execute the example code. They are located in mitk/Core/Code/Testing/Data/ \li Pic3D.pic.gz \n This file contains an image. \li lungs.vtk \n This file contains a surface. \section TutorialSection Tutorial chapters -\li \ref Step00Page "Step 0: Getting started" -\li \ref Step01Page "Step 1: Displaying an image" -\li \ref Step02Page "Step 2: Load one or more data sets" -\li \ref Step03Page "Step 3: Create 3D view" -\li \ref Step04Page "Step 4: Use several views to explore data" -\li \ref Step05Page "Step 5: Interactively add points" -\li \ref Step06Page "Step 6: Use an interactive region-grower" -\li \ref Step07Page "Step 7: Convert result of region growing into a surface" -\li \ref Step08Page "Step 8: Use QmitkStdMultiWidget as widget" -\li \ref Step09Page "Step 9: A functionality" -\li \ref Step10Page "Step 10: A new Interaction" +\li \subpage Step00Page "Step 0: Getting started" +\li \subpage Step01Page "Step 1: Displaying an image" +\li \subpage Step02Page "Step 2: Load one or more data sets" +\li \subpage Step03Page "Step 3: Create 3D view" +\li \subpage Step04Page "Step 4: Use several views to explore data" +\li \subpage Step05Page "Step 5: Interactively add points" +\li \subpage Step06Page "Step 6: Use an interactive region-grower" +\li \subpage Step07Page "Step 7: Convert result of region growing into a surface" +\li \subpage Step08Page "Step 8: Use QmitkStdMultiWidget as widget" +\li \subpage Step09Page "Step 9: A functionality" +\li \subpage Step10Page "Step 10: A new Interaction" Enjoy MITK! */ diff --git a/Modules/Bundles/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkDiffusionImagingUserManual.dox b/Modules/Bundles/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkDiffusionImagingUserManual.dox index 7199f9da63..86f2d20a55 100644 --- a/Modules/Bundles/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkDiffusionImagingUserManual.dox +++ b/Modules/Bundles/org.mitk.gui.qt.diffusionimaging/documentation/UserManual/QmitkDiffusionImagingUserManual.dox @@ -1,100 +1,104 @@ /** \bundlemainpage{org.diffusion} MITK Diffusion Imaging (MITK-DI) This module provides means to diffusion weighted image reconstruction, visualization and quantification. Diffusion tensors as well as different q-ball reconstruction schemes are supported. Q-ball imaging aims at recovering more detailed information about the orientations of fibers from diffusion MRI measurements and, in particular, to resolve the orientations of crossing fibers. Available sections: - \ref QmitkDiffusionImagingUserManualIssues - \ref QmitkDiffusionImagingUserManualTensorReconstruction - \ref QmitkDiffusionImagingUserManualQBallReconstruction - \ref QmitkDiffusionImagingUserManualDicomImport - \ref QmitkDiffusionImagingUserManualQuantification - \ref QmitkDiffusionImagingUserManualVisualizationSettings - \ref QmitkDiffusionImagingUserManualReferences + - \ref QmitkDiffusionImagingUserManualTechnicalDetail \image html overview.png The MITK Diffusion Imaging Module \section QmitkDiffusionImagingUserManualIssues Known Issues \li Dicom Import: The dicom import has so far only been implemented for Siemens dicom images. MITK-DI is capable of reading the nrrd format, which is documented elsewhere [1, 2]. These files can be created by combining the raw image data with a corresponding textual header file. The file extension should be changed from *.nrrd to *.dwi or from *.nhdr to *.hdwi respectively in order to let MITK-DI recognize the diffusion related header information provided in the files. \section QmitkDiffusionImagingUserManualTensorReconstruction Tensor Reconstruction The tensor reconstruction view allows ITK based tensor reconstruction [3]. \image html tensor1.png ITK tensor reconstruction The advanced settings for ITK reconstruction let you configure the number of threads to be used and a manual threshold on the non-diffusion weighted image. All voxels below this threshold will not be reconstructed and left blank. \image html tensor2.png Advanced settings for ITK tensor reconstruction A few seconds (depending on the image size) after the reconstruction button is hit, a colored image should appear in the main window. \image html tensor4.png Tensor image after reconstruction \section QmitkDiffusionImagingUserManualQBallReconstruction Q-Ball Reconstruction The q-ball reonstruction bundle implements a variety of reconstruction methods. The different reconstruction methods are described in the following: \li Numerical: The original, numerical q-ball reconstruction presented by Tuch et al. [5] \li Standard (SH): Descoteaux's reconstruction based on spherical harmonic basis functions [6] \li Solid Angle (SH): Aganj's reconstruction with solid angle consideration [7] \li ADC-profile only: The ADC-profile reconstructed with spherical harmonic basis functions \li Raw signal only: The raw signal reconstructed with spherical harmonic basis functions \image html qballs1.png The q-ball resonstruction view B0 threshold works the same as in tensor reconstruction. The maximum l-level configures the size of the spherical harmonics basis. Larger l-values (e.g. l=8) allow higher levels of detail, lower levels are more stable against noise (e.g. l=4). Lambda is a regularisation parameter. Set it to 0 for no regularisation. lambda = 0.006 has proven to be a stable choice under various settings. \image html qballs2.png Advanced q-ball reconstruction settings This is how a q-ball image should initially look after reconstruction. Standard q-balls feature a relatively low GFA and thus appear rather dark. Adjust the level-window to solve this. \image html qballs3.png q-ball image after reconstruction \section QmitkDiffusionImagingUserManualDicomImport Dicom Import The dicom import does not cover all hardware manufacturers but only Siemens dicom images. MITK-DI is also capable of reading the nrrd format, which is documented elsewhere [1, 2]. These files can be created by combining the raw image data with a corresponding textual header file. The file extension should be changed from *.nrrd to *.dwi or from *.nhdr to *.hdwi respectively in order to let MITK-DI recognize the diffusion related header information provided in the files. In case your dicom images are readable by MITK-DI, select one or more input dicom folders and click import. Each input folder must only contain DICOM-images that can be combined into one vector-valued 3D output volume. Different patients must be loaded from different input-folders. The folders must not contain other acquisitions (e.g. T1,T2,localizer). In case many imports are performed at once, it is recommended to set the the optional output folder argument. This prevents the images from being kept in memory. \image html dicom1.png Dicom import The option "Average duplicate gradients" accumulates the information that was acquired with multiple repetitions for one gradient. Vectors do not have to be precisely equal in order to be merged, if a "blur radius" > 0 is configured. \section QmitkDiffusionImagingUserManualQuantification Quantification The quantification view allows the derivation of different scalar anisotropy measures for the reconstructed tensors (Fractional Anisotropy, Relative Anisotropy, Axial Diffusivity, Radial Diffusivity) or q-balls (Generalized Fractional Anisotropy). \image html quantification.png Anisotropy quantification \section QmitkDiffusionImagingUserManualVisualizationSettings ODF Visualization Setting In this small view, the visualization of ODFs and diffusion images can be configured. Depending on the selected image in the data storage, different options are shown here. For tensor or q-ball images, the visibility of glyphs in the different render windows (T)ransversal, (S)agittal, and (C)oronal can be configured here. The maximal number of glyphs to display can also be configured here for. This is usefull to keep the system response time during rendering feasible. The other options configure normalization and scaling of the glyphs. In diffusion images, a slider lets you choose the desired image channel from the vector of images (each gradient direction one image) for rendering. Furthermore reinit can be performed and texture interpolation toggled. This is how a visualization with activated glyphs should look like: \image html visualization3.png Q-ball image with ODF glyph visibility toggled ON \section QmitkDiffusionImagingUserManualReferences References 1. http://teem.sourceforge.net/nrrd/format.html 2. http://www.cmake.org/Wiki/Getting_Started_with_the_NRRD_Format 3. C.F.Westin, S.E.Maier, H.Mamata, A.Nabavi, F.A.Jolesz, R.Kikinis, "Processing and visualization for Diffusion tensor MRI", Medical image Analysis, 2002, pp 93-108 5. Tuch, D.S., 2004. Q-ball imaging. Magn Reson Med 52, 1358-1372. 6. Descoteaux, M., Angelino, E., Fitzgibbons, S., Deriche, R., 2007. Regularized, fast, and robust analytical Q-ball imaging. Magn Reson Med 58, 497-510. 7. Aganj, I., Lenglet, C., Sapiro, G., 2009. ODF reconstruction in q-ball imaging with solid angle consideration. Proceedings of the Sixth IEEE International Symposium on Biomedical Imaging Boston, MA. 8. Goh, A., Lenglet, C., Thompson, P.M., Vidal, R., 2009. Estimating Orientation Distribution Functions with Probability Density Constraints and Spatial Regularity. Med Image Comput Comput Assist Interv Int Conf Med Image Comput Comput Assist Interv LNCS 5761, 877 ff. +\section QmitkDiffusionImagingUserManualTechnicalDetail Technical Information for Developers + +The diffusion imaging module uses additional properties beside the ones in use in other modules, for further information see \subpage DiffusionImagingPropertiesPage . */ diff --git a/Modules/Bundles/org.mitk.gui.qt.segmentation/documentation/UserManual/org_mitk_gui_qt_segmentation.dox b/Modules/Bundles/org.mitk.gui.qt.segmentation/documentation/UserManual/org_mitk_gui_qt_segmentation.dox index 82f5f4536c..d23f4b22a3 100644 --- a/Modules/Bundles/org.mitk.gui.qt.segmentation/documentation/UserManual/org_mitk_gui_qt_segmentation.dox +++ b/Modules/Bundles/org.mitk.gui.qt.segmentation/documentation/UserManual/org_mitk_gui_qt_segmentation.dox @@ -1,263 +1,268 @@ /** \bundlemainpage{org.segment} The Segmentation Module \image html segmentation.png "Icon of the Module" Some of the below described features are not available in the open-source part of the MITK-3M3-Application. Available sections: - \ref org_mitk_gui_qt_segmentationUserManualOverview - \ref org_mitk_gui_qt_segmentationUserManualTechnical - \ref org_mitk_gui_qt_segmentationUserManualImageSelection - \ref org_mitk_gui_qt_segmentationUserManualManualKringeling - \ref org_mitk_gui_qt_segmentationUserManualManualKringeling1 - \ref org_mitk_gui_qt_segmentationUserManualManualKringeling2 - \ref org_mitk_gui_qt_segmentationUserManualManualKringeling3 - \ref org_mitk_gui_qt_segmentationUserManualManualKringeling4 - \ref org_mitk_gui_qt_segmentationUserManualManualKringeling5 - \ref org_mitk_gui_qt_segmentationUserManualOrganSegmentation - \ref org_mitk_gui_qt_segmentationUserManualOrganSegmentation1 - \ref org_mitk_gui_qt_segmentationUserManualOrganSegmentation2 - \ref org_mitk_gui_qt_segmentationUserManualOrganSegmentation99 - \ref org_mitk_gui_qt_segmentationUserManualLesionSegmentation - \ref org_mitk_gui_qt_segmentationUserManualPostprocessing - \ref org_mitk_gui_qt_segmentationUserManualSurfaceMasking + - \ref org_mitk_gui_qt_segmentationUserManualTechnicalDetail \section org_mitk_gui_qt_segmentationUserManualOverview Overview The Segmentation perspective allows you to create segmentations of anatomical and pathological structures in medical images of the human body. The perspective groups a number of tools for
  • (semi-)automatic segmentation of organs on CT or MR image volumes
  • semi-automatic segmentation of lesions such as enlarged lymph nodes or tumors
  • manual segmentation of any strucutures you might want to delineate
\image html org_mitk_gui_qt_segmentationIMGapplication.png Segmentation perspective consisting of the Data Manager view and the Segmentation view If you wonder what segmentations are good for, we shortly revisit the concept of a segmentation here. A CT or MR image is made up of volume of physical measurements (volume elements are called voxels). In CT images, for example, the gray value of each voxel corresponds to the mass absorbtion coefficient for X-rays in this voxel, which is similar in many %parts of the human body. The gray value does not contain any further information, so the computer does not know whether a given voxel is part of the body or the background, nor can it tell a brain from a liver. However, the distinction between a foreground and a background structure is required when
  • you want to know the volume of a given organ (the computer needs to know which %parts of the image belong to this organ)
  • you want to create 3D polygon visualizations (the computer needs to know the surfaces of structures that should be drawn)
  • as a necessary pre-processing step for therapy planning, therapy support, and therapy monitoring
Creating this distinction between foreground and background is called segmentation. The Segmentation perspective of MITKApp uses a voxel based approach to segmentation, i.e. each voxel of an image must be completely assigned to either foreground or background. This is in contrast to some other applications which might use an approach based on contours, where the border of a structure might cut a voxel into two %parts. The remainder of this document will summarize the features of the Segmentation perspective and how they are used. \section org_mitk_gui_qt_segmentationUserManualTechnical Technical issues The Segmentation perspective makes a number of assumptions. To know what this module can be used for, it will help you to know that:
  • Images must be 2D, 3D, or 3D+t
  • Images must be single-values, i.e. CT, MRI or "normal" ultrasound. Images from color doppler or photographic (RGB) images are not supported
  • Segmentations are handled as binary images of the same extent as the original image
\section org_mitk_gui_qt_segmentationUserManualImageSelection Image selection The Segmentation perspective makes use of the Data Manager view to give you an overview of all images and segmentations. \image html org_mitk_gui_qt_segmentationIMGselection.png Data Manager is used for selection of the current segmentation. The reference image is selected in the drop down box of the control area. To select the reference image (e.g. the original CT/MR image) use the drop down box in the control area of the Segmentation view. The segmentation image that has been selected in the Data Manager is displayed below the drop down box. If no segmentation image exists or none is selected create a new segmentation image by using the "New segmentation" button. Some items of the graphical user interface might be disabled when no image is selected. In any case the application will give you hints if a selection is needed. \section org_mitk_gui_qt_segmentationUserManualManualKringeling Manual contouring With manual contouring you define which voxels are part of the segmentation and which are not. This allows you to create segmentations of any structeres that you may find in an image, even if they are not part of the human body. You might also use manual contouring to correct segmentations that result from sub-optimal automatic methods. The drawback of manual contouring is that you might need to define contours on many 2D slices. However, this is moderated by the interpolation feature, which will make suggestions for a segmentation. \subsection org_mitk_gui_qt_segmentationUserManualManualKringeling1 Creating new segmentations Unless you want to edit existing segmentations, you have to create a new, empty segmentation before you can edit it. To do so, click the "New manual segmentation" button. Input fields will appear where you can choose a name for the new segmentation and a color for its display. Click the checkmark button to confirm or the X button to cancel the new segmentation. Notice that the input field suggests names once you %start typing and that it also suggests colors for known organ names. If you use names that are not yet known to the application, it will automatically remember these and consider them the next time you create a new segmentation. Once you created a new segmentation, you can notice a new item with the "binary mask" icon in the Data Manager tree view. This item is automatically selected for you, so that you can %start editing the new segmentation right away. \subsection org_mitk_gui_qt_segmentationUserManualManualKringeling2 Selecting segmentations for editing As you might want to have segmentations of multiple structures in a single patient image, the application needs to know which of them to use for editing. You select a segmenation by clicking it in the tree view of Data Manager. Note that usually segmentations are displayed as sub-items of "their" patient image. In the rare case where you need to edit a segmentation that is not displayed as a a sub-item, you can click both the original image AND the segmentation while holding down CTRL on the keyboard. When a selection is made, the Segmentation view will hide all but the selected segmentation and the corresponding original image. When there are multiple segmentations, the unselected ones will remain in Data Manager, you can make them visible at any time by selecting them. If you want to see all segmenations at the same time, just clear the selection by clicking outside all the tree items in Data Manager. \subsection org_mitk_gui_qt_segmentationUserManualManualKringeling3 Selecting editing tools If you are familiar with MITKApp, you know that clicking and moving the mouse in any of the 2D render windows will move around the crosshair that defines what part of the image is displayed. This behavior is disabled while any of the manual segmentation tools are active -- otherwise you might have a hard time concentrating on the contour you are drawing. To %start using one of the editing tools, click its button the the displayed toolbox. The selected editing tool will be active and its corresponding button will stay pressed until you click the button again. Selecting a different tool also deactivates the previous one. If you have to delineate a lot of images, you should try using shortcuts to switch tools. Just hit the first letter of each tool to activate it (A for Add, S for Subtract, etc.). \subsection org_mitk_gui_qt_segmentationUserManualManualKringeling4 Using editing tools All of the editing tools work by the same principle: you press the mouse (left button) anywhere in a 2D window (any of the orientations transversal, sagittal, or frontal), move the mouse while holding the mouse button and release to finish the editing action. All tools work on the original slices of the patient image, i.e. with some rotated/tilted MR image volumes you need to perform a "reinit" option in Data Manger before you are able to use editing tools. Multi-step undo and redo is fully supported by all editing tools. Use the application-wide undo button in the toolbar to revert erroneous %actions. \image html org_mitk_gui_qt_segmentationIMGiconAddSubtract.png Add and Subtract tools Use the left mouse button to draw a closed contour. When releasing the mouse button, the contour will be added (Add tool) to or removed from (Subtract tool) the current segmentation. Hold down the CTRL key to invert the operation (this will switch tools temporarily to allow you quick corrections). \image html org_mitk_gui_qt_segmentationIMGiconPaintWipe.png Paint and Wipe tools Use the slider below the toolbox to change the radius of these round paintbrush tools. Move the mouse in any 2D window and press the left button to draw or erase pixels. As the Add/Subtract tools, holding CTRL while drawing will invert the current tool's behavior. \image html org_mitk_gui_qt_segmentationIMGiconRegionGrowing.png Region Growing tool Click at one point in a 2D slice widget to add an image region by the region growing tool to the segmentation. Moving up the cursor while holding the left mouse button widens the range for the included grey values, moving it down narrows it. When working on an image with a high range of grey values, the selection range can be influenced more strongly by moving the cursor at higher velocity. Region Growing selects all pixels around the mouse cursor that have a similar gray value as the pixel below the mouse cursor. This enables you to quickly create segmentations of structures that have a good contrast to surrounding tissue, e.g. the lungs. The tool will select more or less pixels (corresponding to a changing gray value interval width) when you move the mouse up or down while holding down the left mouse button. A common issue with region growing is so called "leakage", which happens when the structure of interest is connected to other pixels of similar gray values through a narrow "bridge" at the border of the structure. The Region Growing tool comes with "leakage detection/removal" feature. If leakage happens, you can left-click into the leakage region and the tool will try to automatically remove this region (see illustration below). \image html org_mitk_gui_qt_segmentationIMGleakage.png Leakage correction feature of the Region Growing tool \image html org_mitk_gui_qt_segmentationIMGiconCorrection.png Correction tool You do not have to draw a closed contour to use the Correction tool and do not need to switch between the Add and Substract tool to perform small corrective changes. The following figure shows the usage of this tool:
  • if the user draws a line which %starts and ends outside the segmenation a part of it is cut off (left image)
  • if the line is drawn fully inside the segmentation the marked region is added to the segmentation (right image)
\image html org_mitk_gui_qt_segmentationIMGcorrectionActions.png %actions of the Correction tool illustrated \image html org_mitk_gui_qt_segmentationIMGiconFill.png Fill tool Left-click inside a segmentation with holes to completely fill all holes. \image html org_mitk_gui_qt_segmentationIMGiconErase.png Erase tool This tool removes a connected part of pixels that form a segmentation. You may use it to remove so called islands (see picture) or to clear a whole slice at once (hold CTRL while clicking). \subsection org_mitk_gui_qt_segmentationUserManualManualKringeling5 Interpolation Creating segmentations for modern CT volumes is very time-consuming, because strucutres of interest can easily cover a range of 50 or more slices. The Segmentation view offers a helpful feature for these cases: "Interpolation" creates suggestions for a segmentation whenever you have a slice that
  • has got neighboring slices with segmentations (these do not need to be direct neighbors but could also be a couple of slices away) AND
  • is completely clear of a manual segmentation -- i.e. there will be no suggestion if there is even only a single pixel of segmentation in the current slice.
Interpolated suggestions are displayed in a different way than manual segmentations are, until you "accept" them as part of the segmentation. To accept single slices, click the "Accept" button below the toolbox. If you have segmented a whole organ in a every-x-slices way, you may also review the interpolations and then accept all of them at once by clicking "... all slices". \section org_mitk_gui_qt_segmentationUserManualOrganSegmentation Organ segmentation The manual contouring described above is a fallback option that will work for any kind of images and structures of interest. However, manual contouring is very time-consuming and tedious. This is why a major part of image analysis research is working towards automatic segmentation methods. The Segmentation view comprises a number of easy-to-use tools for segmentation of CT images (Liver) and MR image (left ventricle and wall, left and right lung). \subsection org_mitk_gui_qt_segmentationUserManualOrganSegmentation1 Liver on CT images On CT image volumes, preferrably with contrast agent in the portal venous phase, the Liver tool will fully automatically analyze and segment the image. All you have to do is to load and select the image, then click the "Liver" button. During the process, which takes a minute or two, you will get visual progress feedback by means of a contour that moves closer and closer to the real liver boundaries. \subsection org_mitk_gui_qt_segmentationUserManualOrganSegmentation2 Heart, lung, and hippocampus on MRI While liver segmentation is performed fully automatic, the following tools for segmentation of the heart, the lungs, and the hippocampus need a minimum amount of guidance. Click one of the buttons on the "Organ segmentation" page to add an average %model of the respective organ to the image. This %model can be dragged to the right position by using the left mouse button while holding down the CTRL key. You can also use CTRL+middle mouse button to rotate or CTRL+right mouse button to scale the %model. Before starting the automatic segmentation process by clicking the "Start segmentation" button, try placing the %model closely to the organ in the MR image (in most cases, you do not need to rotate or scale the %model). During the segmentation process, a green contour that moves closer and closer to the real liver boundaries will provide you visual feedback of the segmentation progress. The algorithms used for segmentation of the heart and lung are method which need training by a number of example images. They will not work well with other kind of images, so here is a list of the image types that were used for training:
  • Hippocampus segmentation: T1-weighted MR images, 1.5 Tesla scanner (Magnetom Vision, Siemens Medical Solutions), 1.0 mm isotropic resolution
  • Heart: Left ventricle inner segmentation (LV Model): MRI; velocity encoded cine (VEC-cine) MRI sequence; trained on systole and diastole
  • Heart: Left ventricular wall segmentation (LV Inner Wall, LV Outer Wall): 4D MRI; short axis 12 slice spin lock sequence(SA_12_sl); trained on whole heart cycle
  • Lung segmentation: 3D and 4D MRI; works best on FLASH3D and TWIST4D sequences
\subsection org_mitk_gui_qt_segmentationUserManualOrganSegmentation99 Other organs As mentioned in the Heart/Lung section, most of the underlying methods are based on "training". The basic algorithm is versatile and can be applied on all kinds of segmentation problems where the structure of interest is topologically like a sphere (and not like a torus etc.). If you are interested in other organs than offered by the current version of the Segmentation view, please contact our research team. \section org_mitk_gui_qt_segmentationUserManualLesionSegmentation Lesion segmentation Lesion segmentation is a little different from organ segmentation, because lesions are not part of the healthy body, sometimes having a diffuse border, and oftenly they are found if varying places all over the body. The tools in this section offer efficient ways to create 3D segmentations of such lesions. The Segmentation view currently offers supoprt for enlarged lymph nodes. To segment an enlarged lymph node, find a more or less central slice of it, activate the "Lymph Node" tool and draw a rough contour on the inside of the lymph node. When releaseing the mouse button, a segmentation algorithm is started in a background task. The result will become visible after a couple of seconds, but you do not have to wait for it. If you need to segment several lymph nodes, you can continue to inspect the image right after closing the drawn contour. If the lymph node segmentation is not to your content, you can select the "Lymph Node Correction" tool and drag %parts of the lymph node surface towards the right position (works in 3D, not slice-by-slice). This kind of correction helps in many cases. If nothing else helps, you can still use the pure manual tools as a fallback. \section org_mitk_gui_qt_segmentationUserManualPostprocessing Things you can do with segmentations As mentioned in the introduction, segmentations are never an end in themselves. Consequently, the Segmentation view adds a couple of "post-processing" %actions to Data Manager. These %actions are accessible through the context-menu of segmentations in Data Manager's list view \image html org_mitk_gui_qt_segmentationIMGDataManagerContextMenu.png Context menu items for segmentations
  • Create polygon %model applies the marching cubes algorithms to the segmentation. This polygon %model can be used for visualization in 3D or other things such as stereolithography (3D printing).
  • Create smooted polygon %model uses smoothing in addition to the marching cubes algorithms, which creates models that do not follow the exact outlines of the segmentation, but look smoother.
  • Statistics goes through all the voxels in the patient image that are part of the segmentation and calculates some statistical measures (minumum, maximum, median, histogram, etc.). Note that the statistics are ALWAYS calculated for the parent element of the segmentation as shown in Data Manager.
  • Autocrop can save memory. Manual segmentations have the same extent as the patient image, even if the segmentation comprises only a small sub-volume. This invisible and meaningless margin is removed by autocropping.
\section org_mitk_gui_qt_segmentationUserManualSurfaceMasking Surface Masking You can use the surface masking tool to create binary images from a surface which is used used as a mask on an image. This tast is demonstrated below: \image html segmentationFromSurfaceBefore.png Load an image and a surface. Select the image and the surface in the corresponding drop-down boyes (both is selected automatically if there is just one image and one surface) \image html segmentationFromSurfaceAfter.png After clicking "Create segmentation from surface" the newly created binary image is inserted in the DataManager and can be used for further processing +\section org_mitk_gui_qt_segmentationUserManualTechnicalDetail Technical Information for Developers + +For technical specifications see \subpage QmitkSegmentationTechnicalPage and for information on the extensions of the tools system \subpage toolextensions . + */ diff --git a/Modules/IGT/Documentation/doxygen/IGTModule.dox b/Modules/IGT/Documentation/doxygen/IGTModule.dox new file mode 100644 index 0000000000..428a0d7deb --- /dev/null +++ b/Modules/IGT/Documentation/doxygen/IGTModule.dox @@ -0,0 +1,15 @@ +/** +\page IGTGeneralModulePage The IGT Modules + +\section IGTGeneralModulePageOverview Overview + +These modules for image guided therapy contain functionalities for the tracking for instruments and the subsequent rendering of these instruments within MITK. + +\section IGTGeneralModulePageModuleList List of IGT Modules + + \li \subpage org.mitk.gui.qt.igtnavigationtoolmanager + \li \subpage org.toolpairnavigation + \li \subpage org.mitk.gui.qt.igttrackingtoolbox + \li \subpage org.igttutorial + +*/ \ No newline at end of file diff --git a/Modules/RigidRegistration/Documentation/doxygen/RegistrationModuleOverview.dox b/Modules/RigidRegistration/Documentation/doxygen/RegistrationModuleOverview.dox new file mode 100644 index 0000000000..dc5d5cd041 --- /dev/null +++ b/Modules/RigidRegistration/Documentation/doxygen/RegistrationModuleOverview.dox @@ -0,0 +1,14 @@ +/** +\page RegistrationModuleOverviewPage The Registration Modules + +\section RegistrationModuleOverviewPageOverview Overview + +MITK provides several modules for the registration of images. + +\section RegistrationModuleOverviewPageList List of Modules + + \li \subpage org.deform.registration + \li \subpage org.pointbased.reg + \li \subpage org.rigid.regis + +*/ \ No newline at end of file