medical imaging interaction toolkit

MEDICAL IMAGING INTERACTION TOOLKIT

Ivo WolfMarco Nolden

CTK Workshop Heidelberg, June 29/30, 2009

Examples


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


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 consists of four layers:1. Toolkit Core2. Toolkit UI Core3. Toolkit Modules4. 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



Bundles: Frontends for segmentation, registration, IGT, … Common tasks as surface extraction, measurement, … Results from master and PhD theses

Standard services: Data repository Preferences Logging



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

medical imaging interaction toolkit

Documents