Medical Imaging Interaction Toolkit
2024.06.00
Medical Imaging Interaction Toolkit
|
In the MITK rendering concept, Mappers are responsible for actually rendering data onto the screen. More...
Classes | |
class | mitk::ImageVtkMapper2D |
Mapper to resample and display 2D slices of a 3D image. More... | |
class | mitk::Mapper |
Base class of all mappers, Vtk as well as OpenGL mappers. More... | |
class | mitk::PlaneGeometryDataMapper2D |
Vtk-based 2D mapper for rendering a crosshair with the plane geometry. More... | |
class | mitk::PlaneGeometryDataVtkMapper3D |
Vtk-based mapper to display a PlaneGeometry in a 3D window. More... | |
class | mitk::PointSetVtkMapper2D |
Vtk-based 2D mapper for PointSet. More... | |
class | mitk::PointSetVtkMapper3D |
Vtk-based mapper for PointSet. More... | |
class | mitk::SurfaceVtkMapper2D |
Vtk-based mapper for cutting 2D slices out of Surfaces. More... | |
class | mitk::SurfaceVtkMapper3D |
Vtk-based mapper for Surfaces. More... | |
class | mitk::VtkMapper |
Base class of all Vtk Mappers in order to display primitives by exploiting Vtk functionality. More... | |
class | mitk::GLMapper |
Base class of all OpenGL-based mappers. More... | |
class | mitk::SplineVtkMapper3D |
Vtk-based mapper for Splines. More... | |
class | mitk::UnstructuredGridVtkMapper3D |
Vtk-based mapper for UnstructuredGrid. More... | |
class | mitk::VolumeMapperVtkSmart3D |
Vtk-based mapper for VolumeData. More... | |
class | mitk::RegEvaluationMapper2D |
Mapper to resample and display 2D slices of registration evaluation visualization. More... | |
class | mitk::LabelSetImageVtkMapper2D |
Mapper to resample and display 2D slices of a 3D labelset image. More... | |
class | mitk::MultiLabelSegmentationVtkMapper3D |
Mapper to resample and display 2D slices of a 3D labelset image. More... | |
class | mitk::DoseImageVtkMapper2D |
Mapper to resample and display 2D slices of a 3D image. More... | |
class | mitk::ContourMapper2D |
OpenGL-based mapper to display a mitk::Contour object in a 2D render window. More... | |
class | mitk::ContourSetMapper2D |
OpenGL-based mapper to display a mitk::Contour object in a 2D render window. More... | |
class | mitk::ContourSetVtkMapper3D |
Vtk-based mapper for mitk::Contour. More... | |
class | mitk::ContourVtkMapper3D |
Vtk-based mapper for mitk::Contour. More... | |
In the MITK rendering concept, Mappers are responsible for actually rendering data onto the screen.
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.
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 Rendering Concept. 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.
More details can be found in the section on Rendering Concept.
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.