230 likes | 432 Views
Medical Imaging Interaction Toolkit. Ivo Wolf Marco Nolden. Examples. Examples. Examples. Examples. Examples. Examples. Medical Imaging Interaction Toolkit (MITK). Open-source C++ toolkit based on ITK/VTK Coordination of visualizations and interactions
E N D
Medical Imaging Interaction Toolkit Ivo Wolf Marco Nolden
Medical Imaging Interaction Toolkit (MITK) • Open-source C++ toolkit based on ITK/VTK • Coordination of visualizations and interactions • Combine modules developed independently from each other Application / PACS Viewer Plugin MITK module layers: building blocks; OSGi bundles GUI-toolkit (Qt, FLTK, …) MITK: coordinationinteractivity ITK: algorithms segmentation registration VTK: visualization
MITK: Ways of usage MITK can be used in different ways: You can … • … start a new applications from scratch usage as a pure TK • … extend the “MITK-Main Application”: • write additional modules • plug modules into existing modules usage as extensible application • … use the existing “MITK-Main Application” • segmentation • registration usage as an end-user product
MITK: Modularization MITK‘s modular design consistsoffourlayers: • Toolkit Core • Toolkit UI Core • Toolkit Modules • Application Layer
1. Toolkit Core Toolkit Core: classes required by (nearly) all applications • GUI independent part: • Data management • View synchronization • Coordinate system definition and conversion • Interaction repository->Add(image); repository->Add(surface); repository->Add(points); renderer1->SetData(repository);renderer2->SetData(repository);
2. Toolkit UI Core Toolkit UI Core: GUI specific core classes • Currently implemented for Qt3 and Qt4 (partly for FLTK, wxWidgets): • renderwindow • multi-widget • scene manager
3. Toolkit Modules Toolkit Modules: optional toolkit-level extensions • Core extensions: more data classes, mappers, filters, etc. • Core UI extensions: widgets • OSGi components (openCherry) • Functional modules: • Image guided therapy • Unified tracker interface: Aurora, Polaris, MicronTracker, daVinci • Synchronization of tracking devices • Tracking data pipeline • … • Segmentation tools
4. Application Layer Application Layer: Extensible “MITK-Main Application” • Based on an OSGi framework (openCherry, developed at DKFZ) • General extension concept • Plugins can hook into other plugins • MITK-Main Application • Minimal core application • All extensions implemented as OSGi bundles (plugins) and services
4. Application Layer • Bundles: • Frontends for segmentation, registration, IGT, … • Common tasks as surface extraction, measurement, … • Results from master and PhD theses • Standard services: • Data repository • Preferences • Logging
4. Application Layer • Why OSGi: • Established standard for component software • Loose coupling of components (SOA) • Easier exchange of binary modules through standardized metadata • Vendor independent • Successfully used for large software projects (e.g. Eclipse, Websphere, …)
Focus of development • Support the sustainable development of usable interactive applications • View synchronization • Modularization • Reusability • Recently: image guided therapy
Roadmap • Scripting • GPGPU programming • Workflow modelling • Fully specified core (prerequisite for CE/FDA approved software) • Further modularization • Fast turnaround development
Dreams • Plugin repository • Thin client architecture
Open-source status and activities • Source code availability:Source packages, Windows Installer, Read-only Subversion repository • BSD Style License • Public bug tracker • Public build and testing results (dashboard: CDash) • Contributions: some application modules, bug fix patches • Community: mailing list, ~15 posts / week • ...
What's most important for a common platform / toolkit? General: • High level of modularization • Unified development process (incl. testing, dashboard, ...) • Continuous integration as open-source policy • Extensible end-user application • General extension concept: allow extensions of extensions • Integration into existing systems (application hosting) • Easy start Content: • Consistent multiple views and interaction (2D, 3D) on arbitrary data (images, surfaces, points, vessels, etc.) • Pipeline concept as in ITK/VTK • Workflow modeling • Support for image guided therapy
How could a collaboration look like? Possible ways of collaboration (from loose to tight): • Regular workshops • Defined interfaces as in DICOM • Bridges between existing toolkits on different levels: • Data level: file-based exchange, inter-process communication, ... • Code level: adapter classes, common base classes, ... • “Common Toolkit”, composed from existing toolkits • “Common Toolkit”, implemented from scratch
How could a collaboration look like? Possible ways of collaboration (from loose to tight): • Regular workshops • Defined interfaces as in DICOM • Bridges between existing toolkits on different levels: • Data level: file-based exchange, inter-process communication, ... • Code level: adapter classes, common base classes, ... • “Common Toolkit”, composed from existing toolkits • “Common Toolkit”, implemented from scratch Sure! necessary first step vision