Andy: Update from Wiki

2006-12-18T13:36:00Z

Update from Wiki

New page

[[Image:f62dc379710c4e82a20236f2d718274d.png]]

<br />

== Current Implementation ==

[[Image:5d647cc5c34fa3d103191c05392096e3.png]]

== Proposed Implementation ==

* The MRML lib should minimize its functionalities to the bare minimum expected from an IO library. No complex operation like transformation of volume should be expected from such a library. Thus the MRML lib should be seen as a lib on top of the MRML-XML file description: manipulating only filename, string and information about volumes.
* There is no notion of vtkPolyData or itk::Mesh, everything is delegated to specialization of mrml.
* For instance instanciating a mrlm::StorageNode will instanciate, using the Factory, a vtk type one or an itk one.
* Once instanciated, the only way to go from itk structure to vtk structure will be to used the third party ITK2VTK code.

=== Pros ===

* Clear separation
* No duplication, mrml will not have an internal representation of let say mrml::Image or mrml::Model
* ITK+MRML does not need -and should not- require VTK (in particular the flipping)

[[Image:fc521a60cf35f329e7888016bddd6011.png]]

=== Cons ===

* mrml by itself will not be very useful, only specialized one will.

== VTK MRML ==

A Module that knows how to read FreeSurfer file should declare that and the ImageIO factory for vtk should know at run time which class to instanciate to read the file.

=== Test case ===

imageData = scene.GetNthNodeByClass(0, "Volume").GetImageData();
vtkGaussianBlur gb;
gb.SetInput( imageData );
gb.Update();
scene.GetNthNodeByClass(0, "Volume").SetImageData (gb.GetOutput()); // reusing same id

so basically the scene has the image data accessible and modifiable without going to disk.

[[Image:d2512cf671445de9e451ae60aa0a6a3f.png]]

At mrml level, it manipulates mrml::StorageNode class, but from vtk-mrml we have access to the full vtkStorageNode class.

== ITK MRML ==

<br />

== Examples ==

<br /> $ xmllint --format volScene3.xml

<?xml version="1.0"?>
<MRML>
<Volume Name="head1" Description="somebodys1" ID="vol1" StorageNodeID="storage1" DisplayNodeID="display1" TransformNodeID="xform1"/>
<Volume Name="head2" Description="somebodys2" ID="vol2" StorageNodeID="storage2" DisplayNodeID="display1" TransformNodeID="xform2"/>
<VolumeArchetypeStorage FileArchetype="TestData/fixed.nrrd" ID="storage1"/>
<VolumeArchetypeStorage FileArchetype="TestData/moving.nrrd" ID="storage2"/>
<VolumeDisplay Name="disp1" ID="display1" Level="128" Window="100"/>
<LinearTransform Name="matXform1" ID="xform1" MatrixTransformToParent="1 0 0 0 0 1 0 0 0 0 1 0 10 20 30 1"/>
<LinearTransform Name="matXform2" ID="xform2" MatrixTransformToParent="1 0 0 0 0 1 0 0 0 0 1 0 10 20 30 1"/>
</MRML>

<br />

== Current Issues ==

=== RAS IJK Space ===

Volumes are VTK-like. ie. vtkMRMLVolumeNode need a whole extra fonctunalities to handle conversion in between RAS space to IJK space.

But on the other hand Model have an implicit representation are are assumed to be vtkPolyData expressed in mm units in IJK space (VTK).

Problems:

# How do I link a vtkPolyData to an itk::Mesh
# Connection in between VTK/Flip then pass to ITK then connected to ITK-VTK...

=== Transforms ===

mrml::Transforms are limited by the current VTK implementation. Thus cannot express the full range of itk::Transform (non-linear ones). There should be a way to encapsulate itk::Transform functionality into a subclass of vtkGeneralTranform to achieve this goal. Problem with vtkTransform, cannot support ITK's transforms : the non linear one, those deriving from itk::KernelTransform (BSpline, ThinPlate...).

User:Mathieu/MRML - Revision history

Andy: Update from Wiki