MedINRIA 2.0 - Platform architecture overviewOlivier ClatzJulien Wintz

CTK Workshop Heidelberg, June 29/30, 2009

Context

Multiple software MedINRIA CardioViz3D YAV++

Multiple operating systems Linux MacOSX Windows

Multiple data to deal with Scalar, vector, tensor images Static or dynamic images Static or dynamic meshes

Diverse algorithms image processing visualization FEM models

Different users Clinicians Research scientists

Many contributors Internal External

CTK Workshop Heidelberg, June 29/30, 2009

Problem

Non compatible codes - constrained architectures

Integration policy - compilation and dependencies

Code maintenance

Hard to get familiar with concepts for newcomers

Divergence of philosophy

CTK Workshop Heidelberg, June 29/30, 2009

A modular architecture

No prior knowledge of its functionalities Low level behavior furnished by plugins High level behavior furnished by scripts

CTK Workshop Heidelberg, June 29/30, 2009

A modular architecture

CTK Workshop Heidelberg, June 29/30, 2009

Kernel

CTK Workshop Heidelberg, June 29/30, 2009

Kernel

Organized into layers (dtkCore, dtkScript, dtkSql, dtkGui …) Qt based (only)

Cross platform library handling Cross platform introspection Graphical user interface

Built using cmake

A set of software components developed and maintained at INRIA for

scientific software development

CTK Workshop Heidelberg, June 29/30, 2009

Kernel – core layer

Provides hierarchies of virtual data classes Provides hierarchies of virtual processing classes Provides hierarchies of virtual visualization classes Provides factories to manage them all Provides a plugin abstract interface Provides a plugin manager

CTK Workshop Heidelberg, June 29/30, 2009

Kernel – script layer

An abstract interpretation engine

Embeds interpreters through specializations

CTK Workshop Heidelberg, June 29/30, 2009

Plugin

CTK Workshop Heidelberg, June 29/30, 2009

Plugin

Technically speaking: A dynamic library Built independently Relying on a common basis

than the target application

Conceptually speaking: A container of concrete concept types Specializing abstract concept types Registers these types to a factory An optional user interface An optional glue to external libraries

Should be as atomic as possibleto provide the highest modularity

level possibleDefine low level behavior

CTK Workshop Heidelberg, June 29/30, 2009

Script

CTK Workshop Heidelberg, June 29/30, 2009

Script

Manipulate wrapped layers

No matter the language

Manipulate plugins, external libraries wrappers and the application to define a

high level workflow

CTK Workshop Heidelberg, June 29/30, 2009

Platform

CTK Workshop Heidelberg, June 29/30, 2009

Platform

Domain specific use of dtk’s layers Manipulate abstract concepts: data, processing and visualization Plugin manager (dtkCore) Script interpreter (dtkScript, dtkGui)

Domain specific specialization of dtk’s layers User interface (medGui – dtkGui - QtGui) Database (medSql – dtkSql – QtSql)

Browsing area Viewer area Workspace area

CTK Workshop Heidelberg, June 29/30, 2009

Platform – Operating systems

CTK Workshop Heidelberg, June 29/30, 2009

Dependencies & licensing

CTK Workshop Heidelberg, June 29/30, 2009

Examples

Tensor visualization ITK based plugins (data) VTK based plugins (visualization) Static user interface (from plugin) Dynamic user interface (from script)

CTK Workshop Heidelberg, June 29/30, 2009

Examples

Tensor visualization ITK based plugins (data) VTK based plugins (visualization) Static user interface (from plugin) Dynamic user interface (from script)

Design

CTK Workshop Heidelberg, June 29/30, 2009

Examples

Tensor visualization ITK based plugins (data) VTK based plugins (visualization) Static user interface (from plugin) Dynamic user interface (from script)

Usage scenario - plugins

CTK Workshop Heidelberg, June 29/30, 2009

Examples

Tensor visualization ITK based plugins (data) VTK based plugins (visualization) Static user interface (from plugin) Dynamic user interface (from script)

Usage scenario - script

CTK Workshop Heidelberg, June 29/30, 2009

Examples

CTK Workshop Heidelberg, June 29/30, 2009

Roadmap

Next months First LGPL software release

Image visualization for clinical usage Limited computational capacities Access to existing wrapped libraries through script

Tutorials for scripts & plugins development Documentation Website

Next year Advanced image processing and visualization Visual programming Advanced user interface elements

CTK Workshop Heidelberg, June 29/30, 2009

What's most important for a common platform / toolkit?

Unified development process +++ Open-source community +++ Powerful end-user application +++ Extensible end-user application ++

+ Heterogeneous plugins +++ Scripting support +++ Rapid prototyping ++

General extension concept ++ Workflow modeling ++ Multiple consistent views ++ Scene graphs + Pipeline concept + Visual programming +

CTK Workshop Heidelberg, June 29/30, 2009

How could a collaboration look like?

Possible ways of collaboration: “Common Toolkit”, composed from existing toolkits “Common Toolkit”, implemented from scratch Funding sources ?