Projects/Slicer3/2007 Project Week MRML Scenes for the Execution Model including Transforms

From NAMIC Wiki
Revision as of 16:56, 6 July 2007 by Millerjv (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Home < Projects < Slicer3 < 2007 Project Week MRML Scenes for the Execution Model including Transforms

XML Module Description


<node descendents="true"></node>

<transform type="linear"></transform>

Example Command Lines

[Command line plugin]    ./SomePluginTakingAScene --scene /path/to/scene/file.mrml
[Shared object plugin]   slicer:13B0835A --scene slicer:04E346F0
[Command line plugin]    ./SomePluginTakingANode --node /path/to/scene/file.mrml#"Some node id"
[Shared object plugin]   slicer:13B0835A --node slicer:04E346F0#Some node id
[Command line plugin]    ./SomePluginTakingATransform --transform /path/to/scene/file.mrml#"Some transform node id"
[Shared object plugin]   slicer:13B0835A --transform slicer:04E346F0#Some transform node id

Key Investigators

  • GE Research: Jim Miller
  • Kitware: Brad Davis
  • BWH: Nicole Aucoin
  • Isomics: Alex Yarmarkovich, Steve Pieper


Pass MRML scenes and nodes to Slicer plugins.

Approach, Plan

Support several paths

  1. Pass nodes in scene wrapper files
  2. Pass nodes directly from MRML tree in memory
  3. Pass scenes in files
  4. Pass scenes from MRML tree in memory


Scene wrapper file approach for transform types is under development as a test case.

Several discussions between Jim, Alex, Brad, and Steve on MRML design and MRML storage. Will investigate collecting all input and output nodes into a single scene that is sent back and forth to the command line module. Key issue is managing MRML node ids: node id in Slicer active scene -> node id in small scene file sent to module -> node id in the module. May need modifications to AddNode() and Copy() methods in MRML.


Back at the ranch, and with a few quiet days for programming, we were able to modify the execution model to communicate transforms via MRML files, complete with ID remapping. The infrastructure established will be utilized for other node types, including hierarchical nodes.

This infrastructure also opens the door for a new type of module in the execution model, one that can communicate directly with the MRML tree in memory.


Additional Information

Strawman Plan

  • MRML
    • virtual method on each node GetReferencedNodes() returns a list of nodes (e.g. model node returns display node, storage node, transform node)
      Is this a list of nodes or list of node ids?
      Referenced nodes are managed in an ad hoc manner. We could have a map of reference ids. Key would be a string for the name of the reference, for instance "TransformNodeID". Value would be a string for the id. This would allow the GetReferencedNodes() method to be written abstractly on the container of reference ids rather than having to be implemented in node that adds a reference id to the hierarchy.
    • [Steve]: yes, a list of ids.
    • [Steve]: I like the container idea - each node needs to have a custom set of referenced nodes, but keeping them in a standard container type might also allow us to handle the observer/event management more consistently.
    • method in MRMLScene GetSubscene(nodeList) returns list all the nodes referenced by all the nodes in the list (recursively searches)
  • CommandLineModule
    • need a way in XML to say that a module is 'mrml aware' -- call them mrmlCLIs
    • when nodes are selected as args to a mrmlCLI
      • need to create a subscene containing all the selected nodes and referenced nodes (use GetSubscene)
      • need to pass mrml ids for arguments rather than filenames
      • need to write the subscene to temp space, along with any volumes or models that aren't saved (needs to use the storage nodes) and pass that as argument to mrmlCLI
    • needs to import the resulting mrml scene written by mrmlCLI back into Slicer3's scene

Example Scenario

  1. User reads grayscale
  2. Creates labelmap with Editor or Segmenter (label volume is not yeat saved)
  3. User enters ModelMaker and selects label map as input and hits Apply
    1. a temp mrml scene is created with
      1. label map volume node
      2. volume display node (ref'd by volume)
      3. color node (ref'd by display)
      4. possibly a transform node (ref'd by volume)
      5. possibly more transform nodes (ref'd by transform nodes)
      6. volume storage node (created by CommandLineModule to point to temp storage of label map)
    2. model maker is invoked with arguments for:
      1. the temp mrml scene
      2. id of the input volume
      3. parameters
    3. model maker
      1. reads mrml scene
      2. pulls out needed info (e.g. label names for each model it makes)
      3. builds the models
      4. puts output into mrml scene that it saves out
    4. CommandLineModule
      1. imports mrml scene file in to current slicer scene

Other Issues

  • Model maker may use mrml scene hierarchy nodes to group the output together so all models from a given build can be deleted as a group.
  • We will want to find a way to tell Slicer that the newly created models should have the same transform ID as the source volume (this is complicated because the current scene import will try to give each node a unique ID, so it may not be possible for the scene written by the mrmlCLI to point to nodes in the Slicer3 mrml scene).

Brad's Notes For EMSegment Use Cases

  • The new EMSegment command line utility uses the "pass scene by file" method with the --mrmlSceneFileName flag. Within this program
    • a MRML scene is created
    • appropriate EMSegment node types are registered with the scene
    • the scene is read
    • some scene data may be overridden by command line arguments (e.g., which image do you want to segment)
    • by default the first EMSegment parameter node is used for segmentation parameters (can override by passing name of node to command line)
    • processing occurs via the vtkEMSegmentLogic (vtkSlicerModuleLogic) class just like in the internal module
    • the results (labelmap) are written to disk
  • The ideal use case for an external module, running within slicer, is
    • Slicer3 passes:
      • the EMSegment parameter node and all referenced (recursively) nodes
      • the input images
    • The module returns:
      • the segmentation results