Documentation/Whitepaper: Difference between revisions
(Created page with ' ''This is open for discussion! The purpose of this whitepaper is to provide a general framework for the development of CTK. It gives an overview of * Goals * Development stra…') |
No edit summary |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
''This document describes thoughts as of approximately 2009. A restatement of our plans is presented in the [[CTK-Roadmap|CTK Roadmap Document]]'' | |||
''This is open for discussion! | = Overview = | ||
''This is open for discussion!'' | |||
The purpose of this whitepaper is to provide a general framework for the development of CTK. It gives an overview of | The purpose of this whitepaper is to provide a general framework for the development of CTK. It gives an overview of | ||
| Line 11: | Line 14: | ||
* Implementation roadmap | * Implementation roadmap | ||
= Goals = | |||
(to be discussed) | (to be discussed) | ||
| Line 22: | Line 25: | ||
* integrate and adapt successful solutions | * integrate and adapt successful solutions | ||
= Development strategy = | |||
(to be discussed) | (to be discussed) | ||
| Line 34: | Line 37: | ||
The CommonTK effort faces these challenges by defining a development strategy. | The CommonTK effort faces these challenges by defining a development strategy. | ||
== Modular design with small core and loose coupling == | |||
The CommonTK will be highly modular and very loose coupling between the modules whenever possible. This will make it possible to use only small parts of it within existing developments or complement CTK code with proprietary code. | The CommonTK will be highly modular and very loose coupling between the modules whenever possible. This will make it possible to use only small parts of it within existing developments or complement CTK code with proprietary code. | ||
== Use parts of CTK within the developments of the CTK founders soon == | |||
To demonstrate (and verify) the possibility to integrate CTK code and their commitment to CTK, the founders should use parts of CTK within their software and toolkit developments soon. | To demonstrate (and verify) the possibility to integrate CTK code and their commitment to CTK, the founders should use parts of CTK within their software and toolkit developments soon. | ||
In case that some functionality of an existing toolkit of a founder (e.g. the logging mechanism of toolkit Y) is provided to the CommonTK, it should be use from the CTK from then on (i.e., toolkit Y should use the logging mechanism from CTK and remove its own - which will be (almost) identical to CTKs). | In case that some functionality of an existing toolkit of a founder (e.g. the logging mechanism of toolkit Y) is provided to the CommonTK, it should be use from the CTK from then on (i.e., toolkit Y should use the logging mechanism from CTK and remove its own - which will be (almost) identical to CTKs). | ||
== Interface design / review /decision process == | |||
Open question: how can we effectively agree on interfaces without getting into a cumbersome process of reviewing everything by everyone? | Open question: how can we effectively agree on interfaces without getting into a cumbersome process of reviewing everything by everyone? | ||
= Design = | |||
(based on [ | (based on [[Documentation/Architecture]] and workshop results) | ||
== BSD style license == | |||
The Common Toolkit shall have a BSD-style license to put no restrictions on the user and allow commercial use. Therefore contributed and used libraries must have a compatible license. | The Common Toolkit shall have a BSD-style license to put no restrictions on the user and allow commercial use. Therefore contributed and used libraries must have a compatible license. | ||
== C++ == | |||
The main language of the Common Toolkit will be C++. | The main language of the Common Toolkit will be C++. | ||
== Qt == | |||
Since all of the main contributors to the Common Toolkit already use Qt or plan to use Qt it was agreed on using it as a GUI Toolkit and also for non-GUI tasks like cross-platform database access. | Since all of the main contributors to the Common Toolkit already use Qt or plan to use Qt it was agreed on using it as a GUI Toolkit and also for non-GUI tasks like cross-platform database access. | ||
== CMake == | |||
CMake will be used as build automation tool. | CMake will be used as build automation tool. | ||
| Line 68: | Line 71: | ||
Possibly the package system can be implemented with CMake. | Possibly the package system can be implemented with CMake. | ||
= Toolkit parts = | |||
== Common data structures == | |||
The Common Toolkit will provide some basic data structures to allow interface design and data exchange between modules. | The Common Toolkit will provide some basic data structures to allow interface design and data exchange between modules. | ||
One goal will be to use a common scene representation (see [wiki:ctkScene]). | One goal will be to use a common scene representation (see [wiki:ctkScene]). | ||
| Line 87: | Line 90: | ||
* Data repository (like MRML, mitk::!DataStorage) | * Data repository (like MRML, mitk::!DataStorage) | ||
== Logging == | |||
A central logging interface should be defined in the core and used throughout the toolkit. | A central logging interface should be defined in the core and used throughout the toolkit. | ||
== DICOM database support == | |||
The DICOM support part of the Common Toolkit will cover different aspects: | The DICOM support part of the Common Toolkit will cover different aspects: | ||
=== WG23 implementation === | |||
The Common Toolkit will provide a C++ reference implementation of a WG23 plugin. | The Common Toolkit will provide a C++ reference implementation of a WG23 plugin. | ||
=== Broad DICOM support === | |||
The Common Toolkit will support more DICOM datatypes like surfaces, segmentations etc. | The Common Toolkit will support more DICOM datatypes like surfaces, segmentations etc. | ||
=== DICOM GUI === | |||
GUI components like patient/study browser | GUI components like patient/study browser | ||
== Plugin support == | |||
The Common Toolkit should support different kinds of plugins to extend applications without recompile. | The Common Toolkit should support different kinds of plugins to extend applications without recompile. | ||
* IO adapters (shared object, dll): Support for special file formats could be provided by IO adapters | |||
* algorithms / filter (shared object, dll): Support for adding algorithms and filters | |||
* command line plugins: Some generic command line interface to allow all kinds of plugins | |||
* GUI modules: Complete GUI (Qt) modules which perform some end-user task and can be integrated as modules in the application | |||
== Scripting engines == | |||
The Common Toolkit should support application scripting. The scripting language and the wrapping mechanism are still to be defined. Things to evaluate: Qt Script for Applications (ECMA Script), Python (!PyQt, !PythonQt) | The Common Toolkit should support application scripting. The scripting language and the wrapping mechanism are still to be defined. Things to evaluate: Qt Script for Applications (ECMA Script), Python (!PyQt, !PythonQt) | ||
== XML files to exchange scene graphs and pipelines == | |||
To exchange scene descriptions, scene graphs and pipelines a XML file format has to defined. | To exchange scene descriptions, scene graphs and pipelines a XML file format has to defined. | ||
== GUIs == | |||
The Common Toolkit will contain packages that provide widgets. GUIs should be skinnable. | The Common Toolkit will contain packages that provide widgets. GUIs should be skinnable. | ||
| Line 123: | Line 126: | ||
A Qt-based GUI will ''not'' be mandatory for applications based on CTK. Support for other GUI toolkits might be added in a later phase. | A Qt-based GUI will ''not'' be mandatory for applications based on CTK. Support for other GUI toolkits might be added in a later phase. | ||
== Integrated Development Environments (IDEs) == | |||
The scope of CTK will include IDEs (e.g. a visual programming environment) and tools for IDEs. Usage of these will not be required for using other CTK modules. | The scope of CTK will include IDEs (e.g. a visual programming environment) and tools for IDEs. Usage of these will not be required for using other CTK modules. | ||
= Technical infrastructure = | |||
== Wiki / repository / testing / cdash? == | |||
Who will be responsible for / who will pay for maintaining the basic development infrastructure? | Who will be responsible for / who will pay for maintaining the basic development infrastructure? | ||
== Package system == | |||
Is CMake as-it-is the adequate solution for this? Maybe some moderate extensions will be necessary, e.g. more than one level of grouping in the GUI. | Is CMake as-it-is the adequate solution for this? Maybe some moderate extensions will be necessary, e.g. more than one level of grouping in the GUI. | ||
= Implementation Roadmap = | |||
'''To be defined''': modules and packages to be started in the next 6 months. | '''To be defined''': modules and packages to be started in the next 6 months. | ||
Latest revision as of 11:30, 17 November 2011
Home < Documentation < WhitepaperThis document describes thoughts as of approximately 2009. A restatement of our plans is presented in the CTK Roadmap Document
Overview
This is open for discussion!
The purpose of this whitepaper is to provide a general framework for the development of CTK. It gives an overview of
- Goals
- Development strategy
- Design
- Toolkit parts
- Technical infrastructure
- Implementation roadmap
Goals
(to be discussed)
The goals of the CommonTK are to:
- provide a unified set of basic features for use in medical imaging
- facilitate the exchange and combination of developments
- avoid duplicate developments
- continuously extend to new tasks within the scope of the toolkit (medical imaging) without growing source-code-wise for existing tasks
- integrate and adapt successful solutions
Development strategy
(to be discussed)
The development of the CommonTK has to face several challenges:
- Several large development efforts already exist.
- Research and development in medical imaging can have different foci and therefore pose different requirements on a toolkit.
- The participants in the common effort have to agree on design issues.
- When using the CommonTK, changes within existing code will be inevitable, which is not attractive for developers.
The CommonTK effort faces these challenges by defining a development strategy.
Modular design with small core and loose coupling
The CommonTK will be highly modular and very loose coupling between the modules whenever possible. This will make it possible to use only small parts of it within existing developments or complement CTK code with proprietary code.
Use parts of CTK within the developments of the CTK founders soon
To demonstrate (and verify) the possibility to integrate CTK code and their commitment to CTK, the founders should use parts of CTK within their software and toolkit developments soon.
In case that some functionality of an existing toolkit of a founder (e.g. the logging mechanism of toolkit Y) is provided to the CommonTK, it should be use from the CTK from then on (i.e., toolkit Y should use the logging mechanism from CTK and remove its own - which will be (almost) identical to CTKs).
Interface design / review /decision process
Open question: how can we effectively agree on interfaces without getting into a cumbersome process of reviewing everything by everyone?
Design
(based on Documentation/Architecture and workshop results)
BSD style license
The Common Toolkit shall have a BSD-style license to put no restrictions on the user and allow commercial use. Therefore contributed and used libraries must have a compatible license.
C++
The main language of the Common Toolkit will be C++.
Qt
Since all of the main contributors to the Common Toolkit already use Qt or plan to use Qt it was agreed on using it as a GUI Toolkit and also for non-GUI tasks like cross-platform database access.
CMake
CMake will be used as build automation tool.
Proposal: Package system
CTK should be organized in packages, like in a Linux distribution package system. This would make it possible to check out only parts of the source code: faster checkout, less code, proabably resulting in higher acceptance of the toolkit.
The packages should have well defined dependencies. The process of getting source code for the packages that are needed could be automated.
Possibly the package system can be implemented with CMake.
Toolkit parts
Common data structures
The Common Toolkit will provide some basic data structures to allow interface design and data exchange between modules. One goal will be to use a common scene representation (see [wiki:ctkScene]).
Comments: (to be discussed)
The data structures have to be carefully designed to allow integration with existing toolkits. Duplication of memory should be avoided.
It may even be possible to refrain from defining actual data classes (as a class for storing images like vtkImageData) for the DICOM-IO part: The IO module could stream the data to adaptor classes that create the actual data objects. These adaptor classes can be written by the CTK users.
In a later step CTK might define its own data classes using the same mechanism. Possible types for that could be:
- Image
- Surface
- Scene or scene graph
- Pipeline
- Data repository (like MRML, mitk::!DataStorage)
Logging
A central logging interface should be defined in the core and used throughout the toolkit.
DICOM database support
The DICOM support part of the Common Toolkit will cover different aspects:
WG23 implementation
The Common Toolkit will provide a C++ reference implementation of a WG23 plugin.
Broad DICOM support
The Common Toolkit will support more DICOM datatypes like surfaces, segmentations etc.
DICOM GUI
GUI components like patient/study browser
Plugin support
The Common Toolkit should support different kinds of plugins to extend applications without recompile.
- IO adapters (shared object, dll): Support for special file formats could be provided by IO adapters
- algorithms / filter (shared object, dll): Support for adding algorithms and filters
- command line plugins: Some generic command line interface to allow all kinds of plugins
- GUI modules: Complete GUI (Qt) modules which perform some end-user task and can be integrated as modules in the application
Scripting engines
The Common Toolkit should support application scripting. The scripting language and the wrapping mechanism are still to be defined. Things to evaluate: Qt Script for Applications (ECMA Script), Python (!PyQt, !PythonQt)
XML files to exchange scene graphs and pipelines
To exchange scene descriptions, scene graphs and pipelines a XML file format has to defined.
GUIs
The Common Toolkit will contain packages that provide widgets. GUIs should be skinnable.
The focus will be on Qt-based widgets (see WidgetPlans).
A Qt-based GUI will not be mandatory for applications based on CTK. Support for other GUI toolkits might be added in a later phase.
Integrated Development Environments (IDEs)
The scope of CTK will include IDEs (e.g. a visual programming environment) and tools for IDEs. Usage of these will not be required for using other CTK modules.
Technical infrastructure
Wiki / repository / testing / cdash?
Who will be responsible for / who will pay for maintaining the basic development infrastructure?
Package system
Is CMake as-it-is the adequate solution for this? Maybe some moderate extensions will be necessary, e.g. more than one level of grouping in the GUI.
Implementation Roadmap
To be defined: modules and packages to be started in the next 6 months.
