ITKBOARD: A VISUAL DATAFLOW LANGUAGE FOR

BIOMEDICAL IMAGE PROCESSING

Hoang D. K. Le, Rongxin Li, S

ebastien Ourselin

BioMedIA, Autonomous Systems Laboratory

John M. Potter

Programming Languages & Compilers Group

School of Computer Science & Engineering

University of New South Wales, Sydney

Keywords:

Dataﬂow programming, visual programming languages, image processing software, ITK, ITKBoard.

Abstract:

Experimenters in biomedical image processing rely on software libraries to provide a large number of standard

ﬁltering and image handling algorithms. The Insight Toolkit (ITK) is an open-source library that provides a

complete framework for a range of image processing tasks, and is speciﬁcally aimed at segmentation and

registration tasks for both two and three dimensional images.

This paper describes a visual dataﬂow language, ITKBoard, designed to simplify building, and more signif-

icantly, experimenting with ITK applications. The ease with which image processing experiments can be

interactively modiﬁed and controlled is an important aspect of the design. The experimenter can focus on the

image processing task at hand, rather than worry about the underlying software. ITKBoard incorporates com-

posite and parameterised components, and control constructs, and relies on a novel hybrid dataﬂow model,

combining aspects of both demand and data-driven execution.

1 INTRODUCTION

Segmentation and registration are two common tasks

that are conducted in processing biomedical im-

ages, such as those produced by Computed Tomog-

raphy Imaging (CT scanners) and Magnetic Reso-

nance Imaging (MRI scanners). Segmentation in-

volves identifying and classifying features of interest

within an image, and registration involves the align-

ment of corresponding parts of different images or un-

derlying grids and meshes. A biomedical application

being explored in our BioMedIA laboratory at CSIRO

performs non-invasive modelling of the internal 3D

structure of an artery. Potentially this can be used to

customise the design of a good-ﬁtting stent as used

in angioplasty procedures. Segmentation is used to

identify the arterial region of interest, and registration

used to align the 3D model of the stent.

Researchers working in this area typically exper-

iment with different image ﬁltering algorithms, and

modify parameters of the algorithms in attempting to

achieve good images for diagnostic or other purposes.

Their concern is with the kind of algorithm and the

tuning process involved, in order to achieve accurate

reconstructions from the images. They do not, in gen-

eral, want to be concerned with the development of

the underlying software.

The Insight Toolkit (ITK) is an open-source soft-

ware toolkit for performing registration and segmen-

tation. ITK is based on a demand-driven dataﬂow ar-

chitecture, and is implemented in C++ with a heavy

reliance on C++ templates to achieve efﬁcient generic

components. Only competent C++ developers can

build image processing applications using ITK in the

raw. Although the toolkit does allow Python, Java

or Tcl scripting of ITK components, the level of pro-

gramming expertise and time required is still too high

for convenient experimentation with ITK. In particu-

lar, experimenters working with scripted models, still

have a cognitive mismatch between the image pro-

cessing problems they want to solve, and the task of

writing scripts to run different experiments.

Our aim with ITKBoard is to provide a simpler

platform for biomedical researchers to experiment on,

leveraging the underlying strengths of ITK, but re-

quiring little or no programming knowledge to use.

More speciﬁcally, we aim to overcome some exist-

ing limitations such as a lack of efﬁciency in dataﬂow

D. K. Le H., Li R., Ourselin S. and M. Potter J. (2007).

ITKBOARD: A VISUAL DATAFLOW LANGUAGE FOR BIOMEDICAL IMAGE PROCESSING.

In Proceedings of the Second International Conference on Software and Data Technologies - PL/DPS/KE/WsMUSE, pages 13-21

DOI: 10.5220/0001339800130021

 SciTePress

model construction, difﬁculty in customising ﬁlter’s

properties for running different experiments, and lack

of high-level constructs for controlling execution.

To this end, we have designed a visual dataﬂow

language which provides extra features above and be-

yond ITK. The novel contributions of ITKBoard are:

visual construction of ITK applications, by graphi-

cal manipulation of ﬁltering models as reported else-

where (Le et al., 2005)); a hybrid dataﬂow model,

combining both demand-driven execution for images,

and data-driven execution for ﬁlter parameters; ex-

plicit visual parameterisation of ﬁlters, with graphical

input/output parameter dependencies between ﬁlters;

visual composition of ﬁlters that can be saved and re-

deployed in other applications; explicit visual control

ﬂow with selection and repetition constructs; and ex-

plicit construction of expressions combining parame-

ters through the visual interface.

The combination of features in ITKBoard is

unique, and designed to suit experimentation in

biomedical image processing. In particular, our hy-

brid dataﬂow model, incorporating both data-driven

and demand-driven computation, is novel. The con-

trol constructs in our language are also interesting,

being tailored speciﬁcally to cope with the underly-

ing ITK execution model, combined with our hybrid

model.

The paper is organised as follows. Section 2 pro-

vides a summary of the software architecture of ITK.

In particular we discuss how the uniformity in the ITK

design allows dataﬂow models to be “wired up”, and

ﬁlters to be executed on demand. The user-based per-

spective of ITKBoard, presented in Section 3, gives

an indication of the ease-of-use that we achieve with

the interactive visual layer that we place on top of

the ITK model. In Section 4 we focus on the hybrid

dataﬂow model that we employ in ITKBoard. Here

we extend the demand-driven dataﬂow model of ITK,

in which image data is cached at ﬁlter outputs, with a

data-driven model for handling ﬁlter parameters. This

adds a uniformity to handling parameters which is

not directly provided in the ITK model. Further de-

tails of the ITKBoard architecture are outlined in Sec-

tion 5: we consider wrapper and plug-in mechanisms

for ITKBoard, composite ﬁlters, a simple way of ex-

pressing combinations of parameters, and explicit vi-

sual control ﬂow constructs for selection and repeti-

tion. In Section 6 we discuss the contribution of our

work, and compare it with other related work, before

a brief conclusion in Section 7 where we also point to

possible future work.

2 ITK: THE INSIGHT TOOLKIT

We provide a brief summary of the features of ITK

which are relevant for the design of ITKBoard. There

is a comprehensive software guide (Ib

nez et al.,

2005) which should be consulted for further informa-

tion.

ITK is based on a simple demand-driven dataﬂow

model (Johnston et al., 2004) for image processing.

In such a model, the key idea is that computation is

described within process elements, or ﬁlters, which

transform input data into output data. Data pro-

cessing pipelines form a directed graph of such ele-

ments in which the output data of one ﬁlter becomes

the input for another. In a demand-driven model,

computation is performed on request for output data.

By caching output data it is possible to avoid re-

computation when there have been no changes to the

inputs. Image processing is computationally inten-

sive, and so redundant computations are best avoided.

ITK has therefore adopted this lazy, memo-ised eval-

uation strategy as its default computational mecha-

nism.

ITK is implemented in C++ and adopts standard-

ised interfaces for the constituent elements of the

dataﬂow model. In particular it provides a generic

interface for process objects (ﬁlters). In ITK images

and geometric meshes are the only types of data trans-

formed by ﬁlters. They are modelled as generic data

objects, which can be specialised for two and three

dimensional image processing. Typically output data

objects for a ﬁlter are cached, and only updated as

necessary.

When inputs are changed, downstream data be-

comes out-of-date. Subsequent requests will cause

re-computation of only those parts of the model which

are out-of-date. As well as tracking the validity of the

cached output images, ITK provides a general event

notiﬁcation mechanism, based on the Observer de-

sign pattern (Gamma et al., 1995) for allowing ar-

bitrary customisation of behaviours that depend on

the state of computation. This mechanism makes it

feasible for us to trap particular events in the stan-

dard ITK execution cycle, and intersperse the stan-

dard behaviours with further updating as required by

our ITKBoard model.

ITK uses data other than the objects (image data)

that are transformed by ﬁlters. This other data is con-

strained to be local to a particular ﬁlter. Such data

is usually used to parameterise the behaviour of the

ﬁlters, or in some cases, provide output information

about a computation which is distinct from the image

transformation typical of most ﬁlters. Such paramet-

ric data are treated as properties of a ﬁlter, and there

ICSOFT 2007 - International Conference on Software and Data Technologies

is a standard convention in ITK for providing access

to them with get and set methods. There is however,

no standard mechanism in ITK to model dependen-

cies between the parameters of different ﬁlters in ITK.

This is one of our contributions with ITKBoard.

To build an ITK application, the basic approach

requires all elements of the model to be instantiated

as objects from the C++ classes provided by ITK. The

toolkit does encourage a particular idiomatic style of

programming for creating ﬁlter instances and con-

structing ﬁlter pipelines by hard-wiring the input-

output connections. Nevertheless, programming in

any form in C++ is not for the faint-hearted.

Consequently, to escape from the complexities of

C++, there is a wrapper mechanism which allows ITK

ﬁlters to be accessed from simpler, interpreted lan-

guages. Currently those supported are Java, Python

and Tcl. Image processing applications can be writ-

ten in any of these languages, using standard ITK ﬁl-

ters as the primitive components. However, even with

such high-level languages, the text-based program-

ming task still slows down the experimenter who sim-

ply wants to investigate the effect of different image

processing algorithms on a given image set.

3 A USER’S PERSPECTIVE OF

ITKBOARD

ITKBoard is a system that implements a visual

dataﬂow language, providing a simple means of inter-

actively building a dataﬂow model for two- and three-

dimensional image processing tasks. Unlike the un-

derlying ITK system, outlined in Section 2, ITKBoard

requires no knowledge of programming. It provides

a much less intimidating approach to the image pro-

cessing tasks that ITK is designed to support. To ex-

ecute an image processing task simply involves click-

ing on any image viewer element in the model. By

offering a single user interface for both model con-

struction and execution, ITKBoard encourages exper-

imenters to try out different ﬁltering algorithms and

different parameter settings.

We summarise the key features that are evident

from the screenshot displayed in Figure 1. This shows

a small example of an image processing task to illus-

trate the key concepts behind our design of ITKBoard.

The simplicity and ease-of-use of the interface and the

intuitive nature of the way in which tasks are mod-

elled should be evident from the ﬁgure. The panel

on the left shows the palette of available elements,

which are typically wrapped versions of ITK process

objects. This provides the interface with the library of

components that ITK provides—no other exposure of

ITK functionality is required in ITKBoard.

The main panel displays a complete ﬁltering ap-

plication mid-way through execution, as suggested by

the execution progress bar. To construct such an ap-

plication, the user selects elements from the left panel,

placing them in the application panel, and connecting

outputs to inputs as required. We visually distinguish

between image data, the thick dataﬂow edges, and

parametric data, the thin edges. Image inputs are pro-

vided on the left of ﬁlter elements, and outputs on the

right. Parameter inputs are via pins at the top of ﬁlters,

outputs at the bottom. ITKBoard uses colour coding

of image dataﬂows to indicate when image data is up-

to-date. In the colour version of Figure 1, red image

dataﬂows indicate that the data is out-of-date, yellow

ﬂows indicate that data is being updated, and green

ones indicate up-to-date data.

Viewer elements act as probes, and provide the

mechanism for execution. The user may request any

particular view to be updated. This demand is propa-

gated upstream, just as in ITK, until the cached image

data is found to be up-to-date. Viewers cache their im-

age data. This allows experimenters to attach multiple

viewers to a given ﬁlter output, and update them inde-

pendently. This is an easy-to-use device for simulta-

neously observing images produced before and after

changes to the upstream model which is particularly

helpful for experimenting with ﬁltering models. Fig-

ure 2 illustrates the display for a viewer, in this case

one that compares two-dimensional cross sections of

three-dimensional images.

Parameters of a ﬁlter are interactively accessible

via property tables, which can be displayed by click-

ing on the ﬁlter icon. Input parameters can be set in

one of three ways: at initialisation, with some default

value, by explicit user interaction, or by being con-

ﬁgured as being dependent on some other parameter

value. For example, in Figure 1, inputs of the Bi-

nary Threshold depend on output parameters of the

upstream Statistics ﬁlter. We will discuss how param-

eter data propagation works in Section 4.

Our example illustrates a simple if-then-else con-

trol construct. To update its output image, it chooses

between its two image data inputs, according to the

current value of its selection condition, which is sim-

ply some expression computed from its parameters.

One key design consideration is apparent here: in

order to prevent image update requests being propa-

gated upstream via all inputs, the condition is eval-

uated based on current parameter settings. Other-

wise, propagating the request on all inputs would

typically involve expensive image processing com-

putations, many of which may simply be discarded.

This will be discussed further in the following sec-

ITKBOARD: A VISUAL DATAFLOW LANGUAGE FOR BIOMEDICAL IMAGE PROCESSING

Figure 1: Screenshot of ITKBoard.

tions. The bottom panel of Figure 1 simply displays

a trace of underlying conﬁguration actions for debug-

ging purposes during development of ITKBoard.

Figure 2: Comparing images with a Viewer.

4 THE HYBRID DATAFLOW

MODEL

In ITK there is a clear distinction between image data

which participates in demand-driven dataﬂow compu-

tations, and parametric data used to conﬁgure ﬁlters.

Image data is large and must be managed with care,

whereas parameters are usually simple scalars or vec-

tors that consume negligible memory. Sometimes in

image processing tasks, parameters do need to be log-

ically shared between different ﬁlters. With ITK, any

such sharing must be conﬁgured explicitly by the user

when they set the parameters for individual ﬁlters. For

ITKBoard we introduced a design requirement that

sharing of such data between ﬁlters must be made ex-

plicit in the model that a user builds.

A couple of design alternatives presented them-

selves to us. First, instead of treating parameters as

local to individual ﬁlters, we could simply take them

to be global variables for the whole model. This

solution is certainly implementable, but requires a

global namespace for the parameters, and binding of

the global parameter names to the local names used

within each of the individual ﬁlters. On the down-

side, this approach requires the user to invent a global

name and keep track of its local variants, in order to

understand what parameters are shared where. With

the ability to form composite models, we must also

deal with the added complexity of nested namespaces.

Furthermore, we want parameters of some ﬁlters to be

able to determine those of other ﬁlters. This would re-

quire the user to distinguish between those parameters

which had to be set externally by the user, and those

which would be the responsibility of a ﬁlter to set.

Instead of using global variables for handling

ICSOFT 2007 - International Conference on Software and Data Technologies

parametric data, we have opted for a dataﬂow solu-

tion. In our ITKBoard model, we deem this appropri-

ate because we are already using a dataﬂow model

for image data, and because it avoids some of the

problems mentioned above in treating parameters as

global variables. First, with a visual dataﬂow lan-

guage, there is no need to provide global names for

the dataﬂow parameters; second, the dataﬂow connec-

tions make apparent any dependencies between pa-

rameters, and who is responsible for setting the data

values, by distinguishing between input and output

parameters—more on this soon; third, with a com-

posite model, it is a relatively simple matter to choose

which internal parameters to expose at the composite

level, with external inputs mapping to internal inputs,

and internal outputs mapping to external outputs.

Perhaps the most interesting design choice in ITK-

Board has been to opt for a data-driven propagation

scheme for data parameters. Given that ITK already

supports a demand-driven model of computation for

image data, why not instead just go with the ﬂow,

and make the update of parameters demand-driven as

well? There are three main reasons for making pa-

rameter updates data-driven.

The ﬁrst reason is implementation biased—it is

simpler to extend ITK with a data-driven propagation

scheme for parameter updates. Whenever a parameter

is updated, we simply ensure that any downstream de-

pendants are immediately notiﬁed of the change, and

correspondingly updated. This mechanism works for

output parameters of a ﬁlter as well. Normally when

an ITK ﬁlter completes its (demand-driven) compu-

tation of its output image, the downstream ﬁlters are

notiﬁed of completion, so they may proceed with any

pending computation. In ITKBoard, our implemen-

tation simply catches this notiﬁcation event, and up-

dates downstream parameters with the new output pa-

rameter values which can be gotten from the underly-

ing ITK ﬁlter, before proceeding with the interrupted

demand-driven computation downstream. If, alterna-

tively, we implemented demand-driven parameter up-

date, we would have to track when output parame-

ters are out-of-date, and this would presumably be

delegated to the ITK mechanism which is based on

checking whether the output images are out-of-date;

whatever the implementation trick used, the demand-

driven approach implies that requests for parame-

ter updates will trigger (potentially expensive) image

processing computations. With the data-driven ap-

proach, (cheap) parameter updates are propagated im-

mediately, and never trigger image processing with-

out a separate request for an up-to-date image.

The second reason for adopting the data-driven

scheme for parameter propagation is more user fo-

cused. Our scheme implies that all image process-

ing computations are driven by requests for up-to-date

images, and nothing else. These requests are propa-

gated upstream, and the state of computation is solely

determined by the current validity of image data and

the current thread of incomplete requests. In partic-

ular, a dependency of an input parameter on an up-

stream ﬁlter’s output parameter will not trigger com-

putation for the upstream ﬁlter, even if that ﬁlter is not

up-to-date.

The third reason for not applying the demand-

driven scheme to parametric data is to allow a richer

class of models, while still avoiding recursion caused

by cycles between image data and parameter depen-

dencies. In a standard demand-driven model, down-

stream output parameters cannot connect to upstream

ﬁlters without causing a feedback loop. By separat-

ing the image demands from the data-driven param-

eter updating mechanism, ITKBoard can handle such

dependencies. So, ITKBoard allows cyclic dependen-

cies that involve at least one image and one parame-

ter data dependency. ITKBoard does not allow cy-

cles of image dataﬂow, or of parameter dataﬂow; only

mixed cycles are allowed. ITKBoard provides built-in

support for iterative ﬁlters, so image feedback is not

needed for expressing repetitive processing.

Because the user interface gives visual cues about

which data is not up-to-date, and where parameter de-

pendencies lie, it is a simple matter for a user to ex-

plicitly request that an output parameter for a partic-

ular ﬁlter be brought up-to-date by requesting an up-

dated view of the output image for that ﬁlter. The

rationale for this is to give the user better control over

which parts of the model are actually re-computed

after changes are made, thereby avoiding potentially

expensive but unnecessary image processing. For

biomedical experimenters, we decided this ﬁner gran-

ularity of control over where image processing occurs

was a worthwhile feature.

Input parameters can be set in a number of ways.

Unconnected parameters have a default value. Input

parameter pins are positioned along the top of the ﬁl-

ter icon, and outputs at the bottom. Connections can

be made from either input or output pins to other in-

put pins. When a connection is made between two

input parameters, the downstream input parameter is

overridden by the value of the upstream input. For all

parameter connections, whenever the upstream value

is updated, the connected downstream value is corre-

spondingly updated. Users may directly override the

current value of an input parameter associated with a

ﬁlter; in this case, any downstream dependants will

be updated, but upstream parameters will retain their

old value—again, this gives experimenters some ex-

ITKBOARD: A VISUAL DATAFLOW LANGUAGE FOR BIOMEDICAL IMAGE PROCESSING

tra ﬂexibility. They have the opportunity to test lo-

cal parameter changes in a model, without restructur-

ing the dependencies in the model. This is similar to

the way some program debuggers allow the values of

variables to be set externally. Note that the value of

a user-modiﬁed input parameter will be retained un-

til there is some other upstream variation causing the

parameter to be modiﬁed via some inward parameter

dataﬂow, if such a connection exists.

Our design choice in opting for a hybrid dataﬂow

model does have an impact on the behaviour of con-

trol constructs as described later in Section 5.

5 MORE DETAILS OF ITKBOARD

We detail some of the more useful features of ITK-

Board: auto-wrappers for ITK ﬁlters and a plug-

in mechanism, ITKBoard’s take on composite ﬁl-

ters, support for expressing parameter-based compu-

tations, and ﬁnally control constructs.

5.1 Wrappers and Plug-ins for

ITKBoard

The main goal of ITKBoard has been to present an

easy-to-use interface for experimenters who want to

use ITK without worrying about programming de-

tails. To this end it is critical that ITKBoard can eas-

ily access all of the ITK infrastructure and that new

pre-compiled components can be easily added to ITK-

Board.

The ﬁrst mechanism is an auto-wrapper for ITK

ﬁlters so that ITKBoard is easily able to leverage all

of the ﬁltering functionality provided by ITK, or by

any other C++ code implementing similar interfaces.

Our auto-wrapper parses the C++ code for a ﬁlter,

and generates C++ code that wraps the ﬁlter so that it

can be used within ITKBoard. In particular, the auto-

wrapping process is able to extract input and output

parameters for an ITK ﬁlter, assuming the convention

that input parameters are those deﬁned with get and

set methods (or macros), and output parameters those

just with get methods. The auto-wrapper allows a user

to intervene to adapt the auto-wrapper’s translation as

required.

The second mechanism provides support for plug-

ins. This allows us to include newly developed ﬁl-

ters into the ITKBoard system without recompiling

the source code for the system. This is important for

effective sharing and distribution of extensions. We

rely on a shared library format (.so or .dll) to achieve

this. Every shared library can provide a collection of

ﬁlters, and must provide a creation routine for instan-

tiating the ﬁlters implemented by the library.

Details of both the auto-wrapper and plug-in

mechanisms for ITKBoard have been presented else-

where (Le et al., 2005).

5.2 Composite Filters

Although ITK itself can support the construction of

composite ﬁlters made up of other ﬁlters, we pro-

vide a separate mechanism in ITKBoard. The rea-

son for doing this is that we wish to distinguish

between primitive ﬁlters (typically ITK ﬁlters), and

those which can be composed of sub-ﬁlters.

So we simply provide an ITKBoard implementa-

tion of the Composite design pattern (Gamma et al.,

1995). The Component interface is the standard ITK-

Board abstraction for representing a ﬁlter. Leaf com-

ponents are ITK ﬁlters with their standard ITKBoard

wrapper. What perhaps is interesting here, is that the

composite structure is not hard-coded, as it is in ITK.

The deﬁnition of the composite is simply an XML-

based description of the structure of the composite ﬁl-

ter which describes the individual components of the

composite, together with their data dependencies (the

“wiring”). When a composite ﬁlter is instantiated by

the user, the actual internal structure of the composite

is dynamically conﬁgured by interpreting the XML

description.

Figure 3: A Composite Filter: collapsed form.

Figure 4: A Composite Filter: expanded form.

At the user interface level, composites can either

be collapsed, appearing as a single ﬁlter icon, or ex-

panded, showing the internal structure of the compos-

ite. For example Figure 3 displays a composite ﬁl-

ter in collapsed form, which can be used just like any

other ﬁlter. The expanded form of the same composite

ﬁlter, Figure 4 shows both the internal data dependen-

cies and the distribution of parameters amongst the

internal components.

ICSOFT 2007 - International Conference on Software and Data Technologies

5.3 Parameter Expressions

Most ﬁlter parameters are simple scalar or vector val-

ues used to customise ﬁlters, such as the threshold

level for a simple ﬁlter. In some cases we may wish

to combine parameters in simple ways. To that end

we deﬁne a simple expression interpreter for deﬁning

arithmetic and comparison operations on data values.

These expressions can be entered into the property ta-

bles that deﬁne the parameters for a component. Al-

though a more elaborate mechanism could be built

in, we think that a simple expression interpreter is

likely to sufﬁce for most kinds of applications; any-

thing more complex can easily be implemented

5.4 Control Constructs

Structured control ﬂow has three aspects: sequenc-

ing, choice and repetition.The dataﬂow model natu-

rally supports sequencing of computations through its

directed graph of data dependencies. Given that ﬁl-

ters may have multiple inputs, it is apparent that we

can encode choice and repetition within the imple-

mentation of a ﬁlter. In fact, some of the standard

ITK components have optimising ﬁlters which may

already implement repeated ﬁltering behaviour until

some criterion is met. However, our goal with ITK-

Board is to provide a visual language to allow users

to specify selective and repetitive behaviour.

Selection. Conditional selection of inputs is

achieved with the If-*-Else construct, as depicted in

Figure 5. Each image data input is guarded by a

Figure 5: Conditional construct.

boolean expression. The ﬁrst of these to be true,

starting from the top, is selected for input. Given in-

puts In

for i = 0. . . n, with boolean guards Cond

for

i = 0. . . n− 1, we can deﬁne the output Out by:

Out = In

, ifCond

= . . .

= In

n−1

, ifCond

n−1

= In

, otherwise

The guard expressions are deﬁned in terms of the

input parameters, as properties of the If-*-Else con-

struct. With the data-driven policy for parameters, it

is clear that the guards do not directly depend on the

input image data. So, with demand-driven computa-

tion, we ﬁnd that each request for output is propagated

to just one input, at most. In other words, the selection

of the input dataﬂow In

only depends on i, which, in

turn only depends on the input parameters.

This deterministic behaviour for conditional input

selection, which may seem somewhat unorthodox on

ﬁrst sight, is in fact, one of the main reasons for opting

for the hybrid dataﬂow model, as already discussed in

Section 4. If instead, we had opted for a demand-

driven model for input parameters, then this condi-

tional expression could generate multiple upstream

requests until a true condition was found. In Figure 1,

for example, the parameters for the conditional block

are only dependent on the input parameters of the pre-

ceding Connected Threshold ﬁlter. So, while those

parameters remain unaltered, the If-*-Else will always

select the same input when the right-most viewer is

updated—the selection does not depend on the input

image data. If we want downstream choices to de-

pend on upstream images, then we must make it ex-

plicit in the model, by arranging for some ﬁlter to pro-

cess the upstream image, generating output parame-

ters which can then be used as inputs to an If-*-Else.

When such a dependency is modelled, the actual be-

haviour for the conditional selection can depend on

where the user makes update requests. If the user

guides the computation downstream, by ensuring that

all upstream image data is up-to-date, then any con-

ditional selections made downstream will be up-to-

date. However, if the user only requests updates from

the downstream side, it is possible that, even with re-

peated requests, that some of the upstream data re-

mains out-of-date.

Although it may seem undesirable to allow differ-

ent results to be computed, depending on the order of

update requests, we claim this to be a beneﬁt of our

hybrid model. As mentioned in Section 4, the user is

always given visual cues to indicate which image data

is not up-to-date. This gives the experimenter control

over which parts of the model are brought up-to-date,

and which parts may be ignored while attention is fo-

cused on another part of the model.

Repetition. In some dataﬂow languages that fo-

cus on stream-based dataﬂow, iteration is often pre-

sented in terms of a feedback loop with a delay ele-

ment. Although our implementation is indeed based

on this idea, we have chosen to keep this as imple-

mentation detail which need not be exposed to the

user. Instead we provide a simple way of wrapping an

existing ﬁlter in a loop construct, with explicit loop

control managed as a property of the loop construct.

In Figure 6 we illustrate the manner in which a

while loop can be expressed. Observe how the ini-

ITKBOARD: A VISUAL DATAFLOW LANGUAGE FOR BIOMEDICAL IMAGE PROCESSING

Figure 6: While Loop construct.

tial, test and update expressions are written in terms

of properties of the loop construct. Although logically

redundant, we also provide a counting for loop.

6 RELATED WORK

A recent survey (Johnston et al., 2004) provides a

good account of dataﬂow programming, including

dataﬂow visual programming languages (DFVPLs).

The current state of play for DFVPLs with iteration

constructs is reviewed by (M. Mosconi, 2000).

Prograph (Cox et al., 1989) is a general purpose

DFVPL that uses iconic symbols to represent actions

to be taken on data. Its general-purpose features are

not ideal for supporting computationally intensive do-

mains such as signal processing and image analy-

sis. However, control ﬂow in Prograph is implicitly

deﬁned, forcing users to implement their own con-

trol constructs rather than directly use available con-

structs.

The Laboratory Virtual Instrumentation Engineer-

ing Workbench(LabVIEW) (LabVIEW, ) is a plat-

form and development environment for a VPL from

National Instruments. LabVIEW aims to provide de-

sign tests, measurement and control systems for re-

search and industry. It is not geared towards experi-

mental image processing like ITKBoard is. Two itera-

tive forms are supported in LabVIEW namely the for-

loop and the while-loop, with a square-shaped block

to represent the loop’s body.

Cantata (Young et al., 1995) is a language orig-

inally designed for image processing within the

Khoros system (Konstantinides and Rasure, 1994),

a visual programming environment for image pro-

cessing. It is also useful for signal processing and

control systems. In Cantata, icons (called glyphs)

represent programs in Khoros system. Unlike ITK-

Board, Cantata provides a coarse-grained computa-

tion model more suited to distributed computation,

where each glyph corresponds to an entire process

rather than to a process component. There are two

iterative forms provided in Cantata namely the count-

loop and the while-loop, similar to our approach.

VisiQuest (VisiQuest, ) is a commercial scientiﬁc

data and image analysis application that builds on the

foundation laid by Khoros and Cantata.

VIPERS (Bernini and Mosconi, 1994) is a

DFVPL based on the standard scripting language Tcl,

which is used to deﬁne the elementary functional

blocks (the nodes of the data-ﬂow graph) which are

similar to Khoros programs in Cantata. Interest-

ingly, each block corresponds to a Tcl command so

VIPERS is less coarse-grained than Cantata. VIPERS

programs are graphs that have data tokens travelling

along arcs between nodes (modules) which transform

the data tokens themselves. VIPERS has some ba-

sic representations to allow node connections, ports

to link blocks into a network. However, the use of en-

abling signals in each block introduces a new boolean

data-ﬂow channel on top of the main input-output

data-ﬂow. VIPERS relies on enabling signals to sup-

port language control constructs. See (M. Mosconi,

2000) for examples and screen-shots.

MeVisLab (Rexilius et al., 2005) is a development

environment for medical image processing and visu-

alisation. MeVisLab provides for integration and test-

ing of new algorithms and the development of appli-

cation prototypes that can be used in clinical environ-

ments. Recently, ITK algorithms have been integrated

into MeVisLab as an ”add-on” module. However,

in ITKBoard, ITK provides the core image process-

ing functionality; with its extensive user base, ITK

library code reliable and well validated. Moreover,

ITKBoard provides a full DFVPL with extra expres-

siveness in comparison to MeVisLab.

ICSOFT 2007 - International Conference on Software and Data Technologies

7 CONCLUSION

We have presented ITKBoard, a rich and expressive

visual dataﬂow language tailored towards biomedi-

cal image processing experimentation. By building

on top of ITK, we have been able to leverage the

strengths of ITK’s architecture and libraries. At the

same time, we provide an interactive development en-

vironment in which experimenters can develop new

image processing applications with little or no con-

cern for programming issues. Furthermore, in one and

the same environment, they can interactively execute

all or part of their model, and investigate the effect

of changing model structure and parameterisation in

a visually intuitive manner.

The hybrid dataﬂow model appears to be unique

amongst dataﬂow languages, and matches well with

the division of data into two kinds in the underly-

ing ITK framework, and with the experimental image

processing that ITKBoard has been designed to sup-

port. Currently we have a complete working imple-

mentation of the features of ITKBoard as discussed

in this paper. Further work is needed to develop ITK-

Board to support streaming of image data and multi-

threaded computation that ITK already goes some

way to supporting.

REFERENCES

Bernini, M. and Mosconi, M. (1994). Vipers: a data ﬂow

visual programming environment based on the tcl lan-

guage. In AVI ’94: Proceedings of the workshop

on Advanced visual interfaces, pages 243–245, New

York, NY, USA. ACM Press.

Cox, P. T., Giles, F. R., and Pietrzykowski, T. (1989). Pro-

graph: A step towards liberating programming from

textual conditioning. In Proceedings of the IEEE

Workshop on Visual LanguagesVL’89, pages 150–

156, Rome, Italy.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.

(1995). Design Patterns: Elements of Reusable

Object-Oriented Software. Addison-Wesley Profes-

sional Computing Series, MA,USA.

nez, L., Schroeder, W., Ng, L., Cates, J., and the In-

sight Software Consortium (2005). The ITK Software

Guide, 2nd edition. http://www.itk.org.

Johnston, W. M., Hanna, J. R. P., and Millar, R. (2004).

Advances in dataﬂow programming languages. ACM

Computing Surveys, 36(1):1–34.

Konstantinides, K. and Rasure, J. R. (1994). The Khoros

software development environment for image and sig-

nal processing. IEEE Transactions on Image Process-

ing, 3(3):243–252.

LabVIEW. National Instruments Corporation. LabVIEW.

User Manual, 2003.

Le, H. D. K., Li, R., and Ourselin, S. (2005). Towards

a visual programming environment based on itk for

medical image analysis. In Digital Image Computing:

Techniques and Applications (DICTA’05), page 80.

IEEE Computer Society.

M. Mosconi, M. P. (2000). Iteration constructs in data-ﬂow

visual programming languages. Computer Langages,

22:67–104.

Rexilius, J., Spindler, W., Jomier, J., Link, F., and Peitgen,

H. (2005). Efﬁcient algorithm evaluation and rapid

prototyping of clinical applications using itk. In Pro-

ceedings of RSNA2005, Chicago.

VisiQuest. Accomplish complex image and data analysis

tasks with an advanced, VisiQuest Visual Proramming

Guide,2006.

Young, M., Argiro, D., and Kubica, S. (1995). Cantata: vi-

sual programming environment for the khoros system.

SIGGRAPH Computer Graphics, 29(2):22–24.

ITKBOARD: A VISUAL DATAFLOW LANGUAGE FOR BIOMEDICAL IMAGE PROCESSING