Slicer3:Data Model

From NAMIC Wiki
Revision as of 13:41, 18 December 2006 by Andy (talk | contribs) (Update from Wiki)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Home < Slicer3:Data Model

Status

Feb 13, 2006

Alex has been converting the mrml functionality of Slicer2.6 into a new set of classes that will eventually become libMRML. These are currently being prototyped in the vtkSlicerThree Module in the slicer2 cvs head. They will be migrated to the Slicer3 svn repository in the next couple weeks once there is enough infrastructure there to support building test executables.

Considerations currently being evaluated:

  • library dependencies
    • object structure comes from vtk
    • volume i/o relies on vtk, itk, and vtkITK
    • transforms will also require a mix
  • class hierarchy for mrml (what specializations are done with subclasses versus instance variables)


Goals

See also AHM Programming week project.

Slicer 2.x MRML


Data Represented in MRML in Slicer 2.x

  • Volumes
    • IJK->RAS (VTK->RAS)
    • Scalar Types
    • Multicomponent (RGB, Displacement Vector)
    • Tensor Volumes
    • Label Maps
    • Reference to Lookup Table
  • Models
    • vtkPolyData
      • Named Field Data (scalars, vectors, labels) at points and cells (FreeSurferReaders)
      • Polylines with tensor point data (DTMRI Module)
    • Color, Clipping State, Visibility, Scalar Visibility, LookupTable
  • Transforms
    • Matrix4x4
  • Lookup Tables
    • vtkLookupTable info
  • Fiducials
    • Position, Quaternion
    • Name, Selection State, Type (endoscopic, normal)
    • Glyph Size, Text Size
  • Fiducial Lists
    • Name, Slze, Color, Selection State
  • Colors
    • Name, Label#, Diffuse/Ambient/Specular
  • Model Groups
  • Application State (not to be carried to Slicer3 MRML)
  • Locator (not to be carried to Slicer3 MRML)
  • Module Specific Parameters (not to be carried to Slicer3 MRML)


Operations On MRML Scene

  • Load from File
  • Save to File
  • Traverse Nodes in Tree
  • Insert Node
  • Delete Node
  • Register Tree Observer
  • Update MRML
  • Get Transformations (e.g. IJK to World through transform tree)
  • Data Type Specific Operations
    • Get/Set Node MetaData
    • Get/Set Data (e.g. as vtkImageData)


Desired Additional Functions Required in Slicer 3

  • Deep Copy
  • Serialize/Deserialize
  • Fine-Grained Observers (per node)
  • Camera Nodes (view transforms in coordinate space manager)
  • Access Modes (all through same API, differences in "filename")
    • Mrml File Representation
    • Client/Server
    • Access Data Tree in Core
  • Import/Export Subtrees

Use Cases for Slicer 3

  • Mrml Data Model is accessed via a C++ callable API
  • API is wrapped for inclusion with various types of calling routines
    • ITK ImageReader/ImageWriter wrapping uses filename to select access mode, and can interact with ITK programs originally written to work with files
    • vtkImageReader/vtkImageWriter wraps for use in VTK
    • slicerget/slicerput style interaction to pipe data through unu filters
    • other wrappers possible (matlab, data explorer...)
    • Viewer Programs Observe Data Model and Generate Visualizations

Path-based MRML3 proposal

Mike's proposal for a path-based MRML3 representation, based on extending the Coordinate Space Manager ideas to the entire MRML3 tree.

Notes from Alex, Steve, Xiadong, Dan, Mathieu meeting(01/12/06).

This approach rely on the assumption that any Modules would provide Transforms operations, in particular Concatenation operation.

As of now, only VTK (compare to ITK) provide a Concatenation of Transforms. Proposal was that we create a vtkGenericTransform (subclass of vtkObject) which would contains an itkGenericTransform.

Also Dan/Xiadong showed us there current approach (in another project) on how to deal with a factory of transforms. This is very close to the current ImageIO factory found in ITK. Major difference are:

  • User specify explicitely what Transform they want, instead of the CanRead mechanism.
  • A thin wrapper around the itkTransform had to be written to handle the problem with template


Implementation proposal of MRML to be toolkit independant

The goal is to proposed an implementation of libMRML to be toolkit independent from VTK in particular. Notes are currently gater here libMRML Notes

libMRML and the Slicer Daemon

The goal of the Slicer Daemon project is to allow remote editing of the MRML data model by external programs over a socket.