Difference between revisions of "2013 Summer Project Week:CLI modules in MeVisLab"

From NAMIC Wiki
Jump to: navigation, search
(thoughts about property mapping)
m (Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/")
 
(7 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
<gallery>
 
<gallery>
 
Image:PW-MIT2013.png|[[2013_Summer_Project_Week#Projects|Projects List]]
 
Image:PW-MIT2013.png|[[2013_Summer_Project_Week#Projects|Projects List]]
 +
Image:CLI module list in MeVisLab.png|MeVisLab module search result listing imported CLI modules
 +
Image:CLI in action in MeVisLab.png|CLI module connected with other MeVisLab modules in a network
 +
Image:BRAINSFit in MeVisLab.png|Example of a more complex GUI panel
 +
Image:CLI debug window in MeVisLab.png|The MeVisLab module's context menu allows to debug CLI execution
 
</gallery>
 
</gallery>
  
Line 31: Line 35:
  
 
<h3>Progress</h3>
 
<h3>Progress</h3>
−
TBD
+
Working:
 +
*Import of CLI modules into the MeVisLab module database
 +
*Image inputs (optional and required) and outputs
 +
*Parameters with different types (bool, int, float, enum, point etc.)
 +
*Ranges (min/max) and steps (+/- spinners in GUI)
 +
*Tooltips on parameters, inputs/outputs, the module itself and group boxes
 +
*Working "Show Help" in the module's context menu(!)
 +
*Heuristics for nice GUI layouts ("advanced" tabs etc.)
 +
*CLI execution
 +
**Optional: Automatic running on changed inputs/parameters
 +
**Error reporting (exitcodes, UNIX signals)
 +
**Debugging window (command, stdout, stderr)
 +
*Simple output parameters (readonly values reported back via --returnparameterfile)
  
 +
Not finished yet:
 +
*XMarkerLists as input (for <point multiple=true>)
 +
*Curve output (<measurement>)
 +
*Regions (currently broken in Slicer)
 +
*Coordinate system conversion (missing in Slicer, too)
 +
*respect given fileExtensions
  
 +
Unfinished, difficult:
 +
*Transforms (at least, linear transforms could be converted to Matrix fields)
 
</div>
 
</div>
 
</div>
 
</div>
Line 40: Line 64:
  
 
*The MeVisLab module name will be the basename of the CLI executable, because module names are usually camelcase names without spaces, but the CLI description's title tag will contain spaces.
 
*The MeVisLab module name will be the basename of the CLI executable, because module names are usually camelcase names without spaces, but the CLI description's title tag will contain spaces.
−
*Many properties of the CLI module have no direct correspondence:
+
*Many properties of the CLI module have no direct correspondence, so we need to be creative:
 
**description maps to comment
 
**description maps to comment
 
**contributor roughly maps to author (the latter has a strict structure with comma-separation, though)
 
**contributor roughly maps to author (the latter has a strict structure with comma-separation, though)
 
**title & version are put into the comment for now, too
 
**title & version are put into the comment for now, too
−
**documentation-url (which does not always contain a URL in practice!) is not mapped; in MeVisLab, we would need to reference a documentation file (HTML)
+
**documentation-url (which does not always contain a URL in practice!) cannot be mapped; in MeVisLab, we need to reference a documentation ''file'' -> we now generate HTML files that redirect to the documentation-url
−
**category is similar to genre (or group), but cannot be mapped – maybe as keywords?
+
**category is similar to genre (or group), but cannot be mapped –> split into keywords (''could'' be useful)
 
**acknowledgments and license are not mapped, either -> maybe add to comment, too?
 
**acknowledgments and license are not mapped, either -> maybe add to comment, too?
 +
 +
In Slicer, in order to debug CLI execution, it makes sense to change the preferences to prefer external executables over DLL loading.
  
 
==Delivery Mechanism==
 
==Delivery Mechanism==
Line 57: Line 83:
 
##Extension -- commandline
 
##Extension -- commandline
 
##Extension -- loadable
 
##Extension -- loadable
−
#YES – Other (Please specify) → a MeVisLab module (possibly integrated in the open source [http://mevislabmodules.sourceforge.net/ community modules] repository)
+
#YES – Other (Please specify) → a MeVisLab module (currently on [https://github.com/hmeine/MeVisLab-CLI GitHub as "MeVisLab-CLI"], will be bundled with MeVisLab in the future.
  
 
==References==
 
==References==
−
*http://www.slicer.org/slicerWiki/index.php/Slicer3:Execution_Model_Documentation
+
*https://www.slicer.org/wiki/Slicer3:Execution_Model_Documentation
 
*http://www.commontk.org/index.php/Documentation/Command_Line_Interface
 
*http://www.commontk.org/index.php/Documentation/Command_Line_Interface
 
*http://www.commontk.org/index.php/Documentation/CLI_In_Context
 
*http://www.commontk.org/index.php/Documentation/CLI_In_Context
 +
* Previous effort to catalog XML support http://www.na-mic.org/Wiki/index.php/2011_Winter_Project_Week:SEMXMLSchema
 +
* Slicer code for CLI execution: https://github.com/Slicer/Slicer/blob/master/Base/QTCLI/vtkSlicerCLIModuleLogic.cxx

Latest revision as of 17:11, 10 July 2017

Home < 2013 Summer Project Week:CLI modules in MeVisLab

  • MeVisLab module search result listing imported CLI modules

  • CLI module connected with other MeVisLab modules in a network

  • Example of a more complex GUI panel

  • The MeVisLab module's context menu allows to debug CLI execution

Key Investigators

  • Fraunhofer MEVIS: Hans Meine
  • Steve Pieper, Isomics
  • Jean-Christophe Fillion-Robin, Kitware
  • Jim Miller, GE

Objective

Integrate CLI modules in MeVisLab, much like it was done before with NiftyView and MITK, for instance.

It shall be as convenient as possible to use CLI modules in MeVisLab, i.e. the integration should strive to achieve the possibility to seamlessly connect CLI modules with built-in MeVisLab modules in a network.

Approach, Plan

  • In order to use CTK's convenience classes for accessing CLI modules, we will have to integrate CTK into our MeVisLab ThirdParty repository and our (qmake-based) build system. It could become interesting because of CTK's dependencies, which must be pulled from our ThirdParty repository as well, if the (patched) versions are not close enough (yet).
  • For integration of the generic CTK CLI support to a platform specific tool, the bulk data types parameters (volumes, models, transforms...) need to be mapped to platform-specific GUI elements and data management techniques (probably files to start). This has been started for Slicer and we can review how it could work in MeVisLab.
  • For seamless integration (see objective), it will be necessary not to use standard Qt widgets, but to have widgets with MeVisLab field connectors. Furthermore, image inputs and outputs shall be mapped to corresponding module inputs / outputs in MeVisLab. The question is whether it is easier to use the CTK support for custom widgets, or whether the CLI XML description should be mapped to a module description in MDL (MeVisLab definition language) instead. (MeVisLab does not currently offer dynamic creation of fields, i.e. parameters, inputs or outputs.)

Progress

Working:

  • Import of CLI modules into the MeVisLab module database
  • Image inputs (optional and required) and outputs
  • Parameters with different types (bool, int, float, enum, point etc.)
  • Ranges (min/max) and steps (+/- spinners in GUI)
  • Tooltips on parameters, inputs/outputs, the module itself and group boxes
  • Working "Show Help" in the module's context menu(!)
  • Heuristics for nice GUI layouts ("advanced" tabs etc.)
  • CLI execution
    • Optional: Automatic running on changed inputs/parameters
    • Error reporting (exitcodes, UNIX signals)
    • Debugging window (command, stdout, stderr)
  • Simple output parameters (readonly values reported back via --returnparameterfile)

Not finished yet:

  • XMarkerLists as input (for <point multiple=true>)
  • Curve output (<measurement>)
  • Regions (currently broken in Slicer)
  • Coordinate system conversion (missing in Slicer, too)
  • respect given fileExtensions

Unfinished, difficult:

  • Transforms (at least, linear transforms could be converted to Matrix fields)

Notes, Thoughts, Design Decisions

  • The MeVisLab module name will be the basename of the CLI executable, because module names are usually camelcase names without spaces, but the CLI description's title tag will contain spaces.
  • Many properties of the CLI module have no direct correspondence, so we need to be creative:
    • description maps to comment
    • contributor roughly maps to author (the latter has a strict structure with comma-separation, though)
    • title & version are put into the comment for now, too
    • documentation-url (which does not always contain a URL in practice!) cannot be mapped; in MeVisLab, we need to reference a documentation file -> we now generate HTML files that redirect to the documentation-url
    • category is similar to genre (or group), but cannot be mapped –> split into keywords (could be useful)
    • acknowledgments and license are not mapped, either -> maybe add to comment, too?

In Slicer, in order to debug CLI execution, it makes sense to change the preferences to prefer external executables over DLL loading.

Delivery Mechanism

This work will be delivered to the NA-MIC Kit as a (please select the appropriate options by noting YES against them below)

  1. ITK Module
  2. Slicer Module
    1. Built-in
    2. Extension -- commandline
    3. Extension -- loadable
  3. YES – Other (Please specify) → a MeVisLab module (currently on GitHub as "MeVisLab-CLI", will be bundled with MeVisLab in the future.

References

Retrieved from "https://www.na-mic.org/w/index.php?title=2013_Summer_Project_Week:CLI_modules_in_MeVisLab&oldid=97134"