Difference between revisions of "2013 Summer Project Week:CLI modules in MeVisLab"
From NAMIC Wiki
Hans.meine (talk | contribs) (Add some thoughts on whether to use the CTK XSLT or not.) |
|||
| Line 13: | Line 13: | ||
<h3>Objective</h3> | <h3>Objective</h3> | ||
| − | Integrate CLI modules in MeVisLab, much like it [http://www.commontk.org/index.php/Documentation/CLI_In_Context was done before with NiftyView and MITK], for instance. | + | <p>Integrate CLI modules in MeVisLab, much like it [http://www.commontk.org/index.php/Documentation/CLI_In_Context was done before with NiftyView and MITK], for instance.</p> |
| + | 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. | ||
</div> | </div> | ||
| Line 22: | Line 23: | ||
* 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). | * 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 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.) | ||
</div> | </div> | ||
Revision as of 19:57, 8 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
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
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)
- ITK Module
- Slicer Module
- Built-in
- Extension -- commandline
- Extension -- loadable
- YES – Other (Please specify) → a MeVisLab module (possibly integrated in the open source community modules repository)
