User:Lantiga

Ideas for Slicer3

• 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)