Engineering:TCON 01 05 2006 SlicerDataModel

Attendants

• Bill Lorensen, GE
• Steve Pieper, Isomics
• Alex Yarmarkovich, BWH
• Mike Halle, BWH
• Mathieu Malaterre, Kitware
• Luis Ibanez, Kitware
• Xiaodong Tao, GE

Topics

Make MRML independent of ITK, VTK or any other toolkit

• MRML API shouldn't use ITK or VTK types.
• Use type descriptors (e.g. strings) plus binary blocks to store/retrieve from the data model.
• Use auxiliary libraries for converting the binary blocks into toolkit specific types.
  • MRML-VTK set of factories: to convert binary blocks into VTK classes.
  • MRML-ITK set of factories: to convert binary blocks into ITK classes.
  • MRML-Generic set of factories: to convert binary blocks into raw data types (e.g. array of chars).
• Use another factory mechanism to handle management of the data blocks (e.g. a factory that manages images and polydata using VTK).
• How to serialize the content of ITK/VTK classes, and deserialize them.
• Maybe register the (ITK/VTK...) factories with the main MRML library.

How to deal with MetaData

• Avoid MetaData that can be recomputed from the data (avoid redundancy).

Wrapping MRML for Tcl and Python

• Bill suggests to write MRML as we wish, and then add vtk wrappers to it. Just like the VTKITK wrappers.

Symbolic Path Mechanism in MRML

• How to implement in this context.
• Issue on how to maintain the symmetry of Reading/Writing external files.

How to represent the Transforms

• Avoid the current limitation of having only linear transforms
• How to deal with composed transforms
  • Tradeoff between flexibility / speed / accuracy
  • Does MRML needs to know about the details of the transforms ?
• Split a Transform library ? independent of ITK and VTK ?

Avoid Templates

• The basic MRML type is a binary block of data