https://www.na-mic.org/w/index.php?action=history&feed=atom&title=Engineering%3ATCON_01_05_2006_SlicerDataModelEngineering:TCON 01 05 2006 SlicerDataModel - Revision history2026-04-06T23:51:13ZRevision history for this page on the wikiMediaWiki 1.33.0https://www.na-mic.org/w/index.php?title=Engineering:TCON_01_05_2006_SlicerDataModel&diff=4111&oldid=prevAndy: Update from Wiki2006-12-18T13:36:06Z<p>Update from Wiki</p>
<p><b>New page</b></p><div>== Attendants ==<br />
<br />
* Bill Lorensen, GE<br />
* Steve Pieper, Isomics<br />
* Alex Yarmarkovich, BWH<br />
* Mike Halle, BWH<br />
* Mathieu Malaterre, Kitware<br />
* Luis Ibanez, Kitware<br />
* Xiaodong Tao, GE<br />
<br />
== Topics ==<br />
<br />
=== Make MRML independent of ITK, VTK or any other toolkit ===<br />
<br />
* MRML API shouldn't use ITK or VTK types.<br />
* Use type descriptors (e.g. strings) plus binary blocks to store/retrieve from the data model.<br />
* Use auxiliary libraries for converting the binary blocks into toolkit specific types.<br />
** MRML-VTK set of factories: to convert binary blocks into VTK classes.<br />
** MRML-ITK set of factories: to convert binary blocks into ITK classes.<br />
** MRML-Generic set of factories: to convert binary blocks into raw data types (e.g. array of chars).<br />
* Use another factory mechanism to handle management of the data blocks (e.g. a factory that manages images and polydata using VTK).<br />
* How to serialize the content of ITK/VTK classes, and deserialize them.<br />
* Maybe register the (ITK/VTK...) factories with the main MRML library.<br />
<br />
=== How to deal with MetaData ===<br />
<br />
* Avoid MetaData that can be recomputed from the data (avoid redundancy).<br />
<br />
=== Wrapping MRML for Tcl and Python ===<br />
<br />
* Bill suggests to write MRML as we wish, and then add vtk wrappers to it. Just like the VTKITK wrappers.<br />
<br />
=== Symbolic Path Mechanism in MRML ===<br />
<br />
* How to implement in this context.<br />
* Issue on how to maintain the symmetry of Reading/Writing external files.<br />
<br />
=== How to represent the Transforms ===<br />
<br />
* Avoid the current limitation of having only linear transforms<br />
* How to deal with composed transforms<br />
** Tradeoff between flexibility / speed / accuracy<br />
** Does MRML needs to know about the details of the transforms ?<br />
* Split a Transform library ? independent of ITK and VTK ?<br />
<br />
=== Avoid Templates ===<br />
<br />
* The basic MRML type is a binary block of data</div>Andy