Post on 21-Mar-2016
description
MEDICAL IMAGING INTERACTION TOOLKIT
Ivo WolfMarco Nolden
CTK Workshop Heidelberg, June 29/30, 2009
Examples
CTK Workshop Heidelberg, June 29/30, 2009
Examples
CTK Workshop Heidelberg, June 29/30, 2009
Examples
CTK Workshop Heidelberg, June 29/30, 2009
Examples
CTK Workshop Heidelberg, June 29/30, 2009
Examples
CTK Workshop Heidelberg, June 29/30, 2009
Examples
CTK Workshop Heidelberg, June 29/30, 2009
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
GUI-toolkit
(Qt, FLTK, …)
MITK:coordinationinteractivity
ITK:algorithms
segmentationregistration
VTK:visualization
Application / PACS Viewer Plugin
MITK module layers: building blocks; OSGi bundles
CTK Workshop Heidelberg, June 29/30, 2009
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
CTK Workshop Heidelberg, June 29/30, 2009
MITK: Modularization
MITK‘s modular design consists of four layers:1. Toolkit Core2. Toolkit UI Core3. Toolkit Modules4. Application Layer
CTK Workshop Heidelberg, June 29/30, 2009
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);
CTK Workshop Heidelberg, June 29/30, 2009
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
CTK Workshop Heidelberg, June 29/30, 2009
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
CTK Workshop Heidelberg, June 29/30, 2009
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
CTK Workshop Heidelberg, June 29/30, 2009
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
CTK Workshop Heidelberg, June 29/30, 2009
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, …)
CTK Workshop Heidelberg, June 29/30, 2009
Focus of development
Support the sustainable development of usable interactive applications
View synchronization Modularization Reusability Recently: image guided therapy
CTK Workshop Heidelberg, June 29/30, 2009
Roadmap
Scripting GPGPU programming Workflow modelling
Fully specified core (prerequisite for CE/FDA approved software) Further modularization Fast turnaround development
CTK Workshop Heidelberg, June 29/30, 2009
Dreams
Plugin repository Thin client architecture
CTK Workshop Heidelberg, June 29/30, 2009
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 ...
CTK Workshop Heidelberg, June 29/30, 2009
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
CTK Workshop Heidelberg, June 29/30, 2009
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
CTK Workshop Heidelberg, June 29/30, 2009
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