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

From NAMIC Wiki
Jump to: navigation, search
(thoughts about property mapping)
Line 36: Line 36:
 
</div>
 
</div>
 
</div>
 
</div>
 +
 +
==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:
 +
**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!) is not mapped; in MeVisLab, we would need to reference a documentation file (HTML)
 +
**category is similar to genre (or group), but cannot be mapped – maybe as keywords?
 +
**acknowledgments and license are not mapped, either -> maybe add to comment, too?
  
 
==Delivery Mechanism==
 
==Delivery Mechanism==

Revision as of 22:09, 17 June 2013

Home < 2013 Summer Project Week:CLI modules in MeVisLab

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

TBD


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:
    • 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!) is not mapped; in MeVisLab, we would need to reference a documentation file (HTML)
    • category is similar to genre (or group), but cannot be mapped – maybe as keywords?
    • acknowledgments and license are not mapped, either -> maybe add to comment, too?

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 (possibly integrated in the open source community modules repository)

References