Difference between revisions of "User:Lantiga"

From NAMIC Wiki
Jump to: navigation, search
Line 1: Line 1:
 
== Ideas for Slicer3 ==
 
== Ideas for Slicer3 ==
 +
 +
=== vmtk ===
 +
 +
* figure out an official way to use vmtk within slicer and provide concrete examples and several modules:
 +
** vessel enhancement
 +
** vessel segmentation
 +
** geometric analysis
 +
** meshing for CFD
 +
** visualization of CFD data
 +
* running modules in a localized space is vital: one solution has been implemented in Boston, but a more general approach would have a broader impact (see below)
 +
* output fiducials would be useful (see below) but not vital for vmtk integration, can be circumvented using world points
 +
* multistage modules would be useful (see below) but not essential
 +
* packaging is tricky, but can be postponed for now
 +
* future developments: vmtk through Tcl, or vmtk through Python through Tcl
 +
 +
=== Modules in localized space ===
 +
* the rationale is to give command line modules a chance to run in a space where images are oriented as X Y Z (i.e. fully specified by a vtkImageData) but still have correct information available as to image origin, spacing and up/down, left/right, front/back consistency.
 +
* the solution implemented in Boston consists in computing the transform from the localized space (the XYZ one) to Slicer's RAS for the first image in the CLI. All other CLI arguments (images, surfaces, fiducials and ROIs) are transformed using that transform before being written to command line. Upon completion, Slicer reads the results (which have been generated in localized space) and puts them in the scene as children of the RAStoLocal transform.
 +
* nicer (more general) solution: there should be a localization mechanism by which Slicer3 creates a miniscene relative to a transformable node (image, model, transform, etc) and runs the module using that miniscene. This involves that all inputs, fiducials, ROIs, etc are first transformed to that miniscene root transform node. The outputs would also be reimported as children of the miniscene.
 +
** if the CLI module is MRML-aware, Slicer3 will let the module deal with the mini scene
 +
** if the CLI module is not MRML-aware, Slicer3 will take care of hardening the transforms up to the miniscene's root on the images, surfaces, fiducials, etc, exporting the hardened nodes (which are now direct descendants of the miniscene root), reimporting the results and transferring the mini scene contents to the main scene.
 +
 +
=== Hardening transforms ===
 +
 +
* a user should be able to harden transforms on nodes. In the MRML tree, if a user moves a node and changes its parent (say, from a parent trasform to root), this can have two different meanings:
 +
** the basis changes, the data doesn't (the way it works now): the effect is that the node changes its position and orientation in the 3D window.
 +
** the basis doesn't change, the data does: the effect is now that the position and orientation of the node are unchanged, but the node is now child of a different transform (this is what we'll call hardening)
 +
 +
=== Multistage modules ===
 +
* Go through new ideas for XML modules:
 +
* multistage modules;
 +
* output fiducials with text to be placed in scene: probably either through a vtkMRMLFiducialStorageNode that outputs a vtp file or (easier) through an XML data structure sent to output as a file or on stdout;
 +
 +
=== Python ===
 +
** write some sample modules;
 +
** extend scripted modules to Python?
 +
 +
* DBPs
 +
** vascular (vmtk): segmentation, analysis, meshing, CFD;
 +
** segmentation and registration in PKD (polycystic kidney disease);
 +
** functional renal imaging;
 +
** functional brain imaging;
 +
 +
= Specific themes =
  
 
* Transforms and CLI:  
 
* Transforms and CLI:  

Revision as of 09:08, 5 September 2007

Ideas for Slicer3

vmtk

  • figure out an official way to use vmtk within slicer and provide concrete examples and several modules:
    • vessel enhancement
    • vessel segmentation
    • geometric analysis
    • meshing for CFD
    • visualization of CFD data
  • running modules in a localized space is vital: one solution has been implemented in Boston, but a more general approach would have a broader impact (see below)
  • output fiducials would be useful (see below) but not vital for vmtk integration, can be circumvented using world points
  • multistage modules would be useful (see below) but not essential
  • packaging is tricky, but can be postponed for now
  • future developments: vmtk through Tcl, or vmtk through Python through Tcl

Modules in localized space

  • the rationale is to give command line modules a chance to run in a space where images are oriented as X Y Z (i.e. fully specified by a vtkImageData) but still have correct information available as to image origin, spacing and up/down, left/right, front/back consistency.
  • the solution implemented in Boston consists in computing the transform from the localized space (the XYZ one) to Slicer's RAS for the first image in the CLI. All other CLI arguments (images, surfaces, fiducials and ROIs) are transformed using that transform before being written to command line. Upon completion, Slicer reads the results (which have been generated in localized space) and puts them in the scene as children of the RAStoLocal transform.
  • nicer (more general) solution: there should be a localization mechanism by which Slicer3 creates a miniscene relative to a transformable node (image, model, transform, etc) and runs the module using that miniscene. This involves that all inputs, fiducials, ROIs, etc are first transformed to that miniscene root transform node. The outputs would also be reimported as children of the miniscene.
    • if the CLI module is MRML-aware, Slicer3 will let the module deal with the mini scene
    • if the CLI module is not MRML-aware, Slicer3 will take care of hardening the transforms up to the miniscene's root on the images, surfaces, fiducials, etc, exporting the hardened nodes (which are now direct descendants of the miniscene root), reimporting the results and transferring the mini scene contents to the main scene.

Hardening transforms

  • a user should be able to harden transforms on nodes. In the MRML tree, if a user moves a node and changes its parent (say, from a parent trasform to root), this can have two different meanings:
    • the basis changes, the data doesn't (the way it works now): the effect is that the node changes its position and orientation in the 3D window.
    • the basis doesn't change, the data does: the effect is now that the position and orientation of the node are unchanged, but the node is now child of a different transform (this is what we'll call hardening)

Multistage modules

  • Go through new ideas for XML modules:
  • multistage modules;
  • output fiducials with text to be placed in scene: probably either through a vtkMRMLFiducialStorageNode that outputs a vtp file or (easier) through an XML data structure sent to output as a file or on stdout;

Python

    • write some sample modules;
    • extend scripted modules to Python?
  • DBPs
    • vascular (vmtk): segmentation, analysis, meshing, CFD;
    • segmentation and registration in PKD (polycystic kidney disease);
    • functional renal imaging;
    • functional brain imaging;

Specific themes

  • Transforms and CLI:
    • the rationale is to give command line modules a chance not to worry about transforms but still have correct information available as to spacing and up/down, left/right, front/back consistency
    • the image passed to a command line module should be in normalized orientation space, i.e.: real origin, real spacing,
    • reference node specified in XML (either tag of the reference node or tag of child nodes to the reference - the latter allows many references in the same command line). Images in normalized orientation space.
    • the reference transform should be just a rigid transformation bringing the axes to XYZ (by looking at projections, but not necessarily). Therefore, from the node transform, a RASToLocalMatrix should be extracted, containing only the cosines that bring the axes to XYZ.
    • for each XML node, specify what's its reference node. The default is patient space (identity matrix), but in general it could be another node. So the current node matrix should be multiplied by the inverse of the reference node matrix before being written out. Correspondingly, when the command line module has executed, all results have to be multiplied by the corresponding reference node matrix. A reference node could be the node itself, meaning that the node transform wil be multiplied by the inverse of its reference transform.
    • find ways to harden transforms for specific MRML nodes
    • in the end: the writer of a command line module or Python scripted module etc. has to be put in the condition of not knowing anything about transforms, and still deal with legal vtkImageData objects (with their own spacing and right-handedness)
  • Multi-stage CLI:
    • wizard or tabbed interface with content generated one page per command line module, and user control is returned from one page to the next.
    • one XML that puts command line modules together. This way command line modules can be either used alone or in a wizard.
    • change the way CLI are specified: XML files are discovered first, each XML describes how's the module is going to be (executable, shared library, Python class, etc). This saves time for module discovery (at least on OSX), and (as suggested by Raoul) it makes it easy for a developer to know how that CLI is going to behave and to develop against it.
  • Fix vtkITK CMakeLists.txt (generate vtkITKTCL.so separately from vtkITK.so).
  • XML module GUI:
    • give possibility to build a GUI from XML in ScriptedModules (either from Tcl or Python) or even everywhere in Slicer3, even from C++.
  • Python:
    • try wrapping VTK. What happens when Python through Tcl is used and ShallowCopy to a true VTK module is called?
  • Annotation widget
    • do it for command line modules (like: put this string at this point in the scene)