ScilImage: A Multi-layered Environment for Use and Development of Image Processing Software Richard van Balen
Dennis Koelma Ton K. ten Kate Arnold W.M. Smeulders
Benno Mosterd
Faculty of Mathematics and Computer Science, University of Amsterdam Kruislaan 403, 1098 SJ Amsterdam, The Netherlands tel.: +31 20 525 7516, e-mail:
[email protected]
July 20, 1994 Abstract
This paper presents an integrated system made up of a portable multi-layered interactive environment for software development and use, and a class based infrastructure for image processing. The interactive environment is responsive to di erent type of users, and consists of a library handler, a C interpreter, a command expander, a menu and dialog generator, and a visual programming interface. All interface layers are generated from a command description le. The design considerations of each of the interface layers is discussed. The image infrastructure enforces strict image class separation, and takes care of actions common to all image classes. Through the use of an abstraction mechanism based on function overloading, the infrastructure allows image sub-classing and the de nition of new image classes, which automatically inherit the consistent behavior of the total environment. An overview of the extensive image processing libraries functionality is given, with special attention to bit-mapped binary images and mathematical morphology advancements provided in the system.
1 Introduction In image processing, interactive environments have always played an important role. Generally there are no o the shelf solutions available for image processing problems. Although the theory of image processing has advanced well beyond development based only on trial and error, the amount and variability of data, even within similar images, is so large that visual evaluation of attempted strategies is a practical necessity [1]. The immediate feedback interactive systems provide reduces the time needed to develop new applications. Furthermore, the ability to see the result of processing and to modify code or parameters within seconds brings new insights, such as how sensitive an algorithm is to a small change in the image, or how parameters should be tuned in response to certain shapes found [2]. Obviously, an interactive system is of great importance to image processing design, methodology and development. Unlike word processing, for example, the processing and interpretation of digital images still is in many respects an evolving discipline. In 2D and especially in 3D image processing many issues remain unsolved. The general situation is that there is an ongoing ow of new or renewed 1
algorithms and implementations. As a consequence software environments for image processing are still expanding and evolving [3, 4]. Since dedicated hardware systems are targeted at speeding up stable methodology, using them is in contrast with the state of the art in the eld requiring to quickly add new algorithms [5]. The natural alliance between interactive systems and image processing, combined with the need for
exibility, has led many research institutions to develop their own image processing environment. Today close to a hundred image processing systems are in existence [6] prohibiting the exchange of algorithms between research groups [3, 7]. The need to exchange software and ideas is especially important in the study of new research topics, such as model-based image processing and image understanding, since the complexity of these topics force research centers to cooperate [3]. In a survey covering 72 image processing languages, Preston concluded that the diversity in image processing environments is not justi ed since the image processing applications themselves are not so disparate as to require unique and specialized data types or di erent programming constructions [6]. It is therefore recognized that, if an image processing environment is to meet the requirements of multiple research institutions, the time is felt right to specify a portable and exible environment to allow for ongoing changes in software methodology [3, 5]. In a research context there is often no clear distinction between an image processing user and the developer of the program [8]. Computer scientists typically develop or at least adapt programs and algorithms for their own use. In the process of developing new algorithms they frequently switch between a programming mode and a users mode. As a consequence most image processing systems provide an algorithmic view on image processing. The user is bothered with explicit image type and dimension management, and restrictions on image input and output designation. Furthermore the user is required to know of algorithmic details, such as whether an operation can be performed in place or not. To serve programming and use of an image processing system beyond a research setting it is in our view, therefore, essential to provide a logical and dynamic view on image processing rather than a static and algorithmic one. The various image processing environments range from a collection of routines in software libraries [9], via command [10], menu [11], or visual programming [12] driven systems that are easy to use, to highly specialized but idiosyncratic programming languages [1, 13]. Although the latter group contains variable types and programming constructs, one is often confronted during application development with limitations caused by the specialized nature of the language. The importance of programmability is stressed in [1, 2, 14]. In [15] Graham states that in the design of an image processing system it is all too often the case that little attention is paid to general programmability. We share the opinion that attention to this topic pays dividend, but we stress the importance of adhering to existing programming standards rather than de ning a new one. Di erent forms of environments each provide a suitable interface for one group of users in particular. Di erent type of users, however, have di erent interface needs [16]. Menu based systems, for example, are easy to learn for novices, but they are a nuisance for expert users as they are forced to travel through (multiple) menus to specify an action. A visual programming interface can be so intuitive that even users with no programming experience can create simple, but non-trivial programs. Experienced program developers, however, need complete control and program constructs which are very dicult to express with visual programming. Also the users themselves are not a constant factor since they progress from beginners, to experienced, to possibly experts, and may eventually need special features not presented in the environment, forcing them to program the missing aspects themselves. We therefore conclude that the interface of an interactive environment should be such that it is responsive to di erent types of users. Moreover, if an environment simultaneously provides an interface that accommodates both 2
experienced developers as well as lay end-users the barrier between development and use of a system is resolved.
Requirements
From the observations made above we produced the following list of requirements for a new and
exible environment for image processing.
The environment should combine the advantages of di erent systems, being helpful to beginning users yet providing more power and exibility when the user gains more experience. To also allow non-programmers to construct simple programs a visual programming paradigm should be included. Since no environment for image processing can possibly supply the answer to all the users needs and questions, the environment should not only allow the use of image processing software, but also allow for software development. Ideally further development within or with the environment should take place in a standard programming language. The environment should not be limited to the image processing domain. This would ideally mean that the environment also allows easy integration of di erent application domains. The consequence of the previous requirement is to clearly separate the environment from the image processing algorithms. A exible image processing infrastructure should, therefore, be designed independent of the interactive environment. Both the interactive environment and the image processing infrastructure should be portable for a variety of machines and operating systems.
In this paper we address the computer science aspects of a general purpose interactive environment [17] and a exible infrastructure for image processing [18]. The two combined results in a multi-layered environment which meets the demands of portability, maintainability, and exibility necessary to function as a general vehicle for use and development of image processing software. Section 2 features the interactive environment and a description of each of the interface layers. Section 3 elaborates on the object oriented image infrastructure. In section 4 an overview of the image processing functionality is given and some important aspects of the image libraries are discussed. Section 5 is on related work and use of the system in several projects. In section 6 a discussion and some conclusions on the presented environment are given.
2 SCIL: A Multi-layered Environment ScilImage is the combination of the user front-end environment SCIL [17] and image processing libraries under the name of Image [18]. SCIL (Standard C Interpretive Language), can be tailored to many di erent application domains, and consists of multiple interface layers, which all are active at the same time. Figure 1 shows an overview. Compiled functions are interfaced through the library handler, which is practically invisible to the user. The rst user visible layer consists of a C-interpreter. In the second layer a command expander working on image processing commands known to the system opens the way to ecient interactive (image processing) design, hiding the C-level from the novice and allowing shorthand typing for the experienced user. In the third layer, 3
4 Visual Programming
3
Command Description File
Image
Menu & Dialog Generator
2 Command Expander
1
C Interpreter
0
Library Handler
Function browser Icon connections on worksheet
Interactive operation with menus and dialog boxes Text Windows Command shorthand Default arguments Argument prompting Complete C programs Flow control
User defined or imported
Figure 1: The SCIL interface layers. All layers are generated from the Command Description File. a window management system generates menus and dialogs for command selection, now hiding the command level from the naive user. The layers in the front-end o er di erent levels of user support. Going from the C interpreter, via the Command Expander level, to the Menu and Dialog generator, the system o ers increasingly more user-friendliness but looses on exibility and speed of interaction. At the menu and dialog level, for example, no program ow-control is available. This is reserved for the C interpreter level. There is one more interface layer supporting visual programming to combine user-friendliness with programmability. It is based on a data- ow paradigm, which allows users without any programming experience to built simply structured but non-trivial programs [19]. All interface layers are generated from a Command Description File (CDF) which insulates the interface layers from the application. We discuss the design considerations of each of the interface layers and go over the functionality of each of the layers one by one.
The C interpreter
We have selected a standard programming language as the basis for command speci cation. The advantage is that the command language is well de ned, generally known, and equal to the language used to run actual programs. As a consequence interactively developed programs can also be used in compiled mode. C is the obvious choice as most software and hardware based image processing routines are interfaced through C-callable libraries. The C interpreter ensures general programmability and portability of the developed applications. The use of the interpreter not only shortcuts the traditional edit-compile-debug cycle, but also allows the developed applications to be compiled and executed as stand-alone programs.
4
The Library Handler
Linking of external libraries takes place through the library handler, a separate layer of the environment which is invisible to the user. It provides the ability to add new commands quickly and easily. When adding functions to the environment the user only deals with a command description le, adding one entry for each function to become known to all the layers in the environment. There is no need to make any changes to external libraries. In this way the separation between the environment and application code remains clean and well de ned. In practice, there is one command description le per library. All command description les are concatenated into a single command description le, from which a table with the names, addresses and the number of arguments is compiled, and linked in with the rest of the system. The major advantage of this approach is that software libraries of various engineering elds, such as image processing, data-basing, statistical analysis and graphics, can easily be combined in the system. It also allows for easy software exchange between di erent users, as they can exchange personal libraries by sending the library in compiled form together with its command description le. Rather than tailoring the C-interpreter itself to the image processing domain, the ability to add any software library to the C-interpreter, broadens the usability and scope signi cantly.
Figure 2: Impression of the Macintosh version of ScilImage with several interface layers: A generated menu bar, dialog box, three images, a run-editor containing a C program, a history window, and a worksheet showing C statements and commands.
5
The Command Expander
Where the bene ts of a C interpreter are obvious to program developers, they were found too complex for non-programming users. Non-programming users have diculty or nd it cumbersome to type all C punctuation. To solve the issue, the command expander responsible for transposing (possibly abbreviated) commands into legal C function calls, serves as an extra interface layer on top of the C interpreter in layer 2 of the total environment. At the command expansion level arguments are checked against legal values. When arguments of a command are left unspeci ed the list is completed with default values. Interactive argument prompting is invoked when requested by typing a question mark, when an illegal value is encountered, or when automatic conversion to the correct type fails. An example of the command expander functionality can be seen in g 2. As all other interface layers, the command expander operates on the command description le.
The Command Description File
Per processing function the command description le contains a speci cation of each argument including the type, default and range or legal values, and explanation of the prompted argument. Apart from the standard C types, such as "int", " oat", or "long", some special types are supported, e.g. "odd", "even", "choice", "in le", "out le". A typical function entry in the command description le is given below: FUNC MENU ICON ARGS
uniform Filter uniform.bitmap image image odd odd
in out con con
A B 3 3
1 1
61 61
Input Image Output Image X Filter Size Y Filter Size
#
The "choice" type allows the user to specify a single choice out of a set of legal choices. It plays an important role in the command expander. As a detail, consider that through the use of names with associated aliases it connects symbolic names to constants, particularly useful in image processing development to avoid the introduction of "magic" numbers. In the system, new types can be de ned through function hooks, that is calling a speci ed function if an unknown type is encountered. An example of such a foreign type is the "image" type. If an image type is encountered in the command description le, a hooked function is called, transposing the current images into a legal choice type consisting of the image names (with the image address as alias), which the command expander can handle.
The Menu & Dialog Generator
The Menu & Dialog (M&D) Generator in layer three of the environment dynamically creates at run-time a window and menu based interface from the speci cations in the command description le. Mouse activation automatically shows the available commands in cascading pop up menus. When a command is selected a dialog box is created giving an overview of all the arguments of the function together with their defaults and ranges or legal choices whichever is relevant. Depending on whether a help le can be found for the command at hand also a help button is created. Fig 3 shows an example of a generated dialog box. 6
Figure 3: A dialog box as automatically generated from the Command Description File The M&D generator performs an educated guess, based on the argument type and legal values, to choose the most appropriate graphical attribute to display in the dialog box, such as slider, cycle, sequence of buttons, or editable text eld. In this way additional speci cations in the command description le are not needed, serving simplicity in use, consistency throughout the user interface and dynamical adaptation of the attribute. To illustrate the dynamic adaptation in more detail, consider the subsequent creation of a series of images. When there are only a few images, each image is symbolized by a button with the image name next to it. When some new images are created, the name of the images is placed inside the buttons to save space. Finally, if the number of images exceeds a second limit, say ten, only the current selected image is shown allowing the user to choose another image from a menu, or by cycling through the available images. Since the interface is generated at run-time, the listing and sequence of commands in menus is tailored quickly to personal preferences or customized for a particular application.
The Visual Programming Layer
The SCIL environment also has a visual programming (VP) layer based on a data- ow paradigm. The rationale behind the use of visual programming is discussed in [19, 17]. It is obvious that VP is user-friendly, and visual programs o er a quick insight in the program structure. Especially for image processing they are helpful as the transformation of the image data can be followed and visualized through interacting on the program ow. For an overview of di erent visual programming paradigms and systems the reader is referred to [20, 21, 22]. We have opted, apart from having visual expressions, to also implement a C-icon which can hold any C-statement, allowing a mixture between visual and textual expressions, to circumvent the problem that not every programming issue can easily be expressed in a visual manner. The VP layer consists of two parts; a function browser and a worksheet. The function browser 7
(see gure 4) is similar in structure to the main menu, since both are generated from the command description le, only now the di erent menus and menu items are represented as named class-icons and function icons.
Figure 4: Part of the VP layer: the function browser When a function icon is selected it can be placed into the worksheet. The worksheet (see gure 5) consists of two parts, a workspace in which the visual program is built and a control area with command buttons and edit icons. In the workspace the function icons can be connected by selection of input/output pin pairs. As soon as two pins have been selected, and the pin types match, the connection becomes visible. There can only be one connection to an input pin, but an output pin can be connected to multiple input pins. Through a number of edit icons the user can manipulate the visual program in several ways. We only mention a few of the edit commands here: the user can obtain help information, destroy components, execute selected functions or the complete program, compose a part of a visual program into a single icon, start a separate worksheet to edit a composed icon, or add a C icon to mix C statements into the visual program. When a visual program has been developed and is working correctly it can also be saved as an ordinary C program. This allows the user to execute the program without the visual programming environment.
8
Figure 5: Example of a worksheet
Visual Program Execution
Once the program has been composed it can be executed (in a continuous or step mode) by pressing the start button. Since the program is interpreted execution starts immediately. The order in which the functions are executed is a combination of data and demand driven. If there is a function that has valid data on all input pins then it is executed (data driven). If a function does not have valid data on all input pins its predecessors are executed (demand driven). The function under execution is highlighted so the user can experience the execution. Like all other layers the VP layer operates on the command description le. For the VP layer each function argument in the command description le can be described as being an input, an output, an input-output, or a control parameter. Input and output parameters appear as pins to the left and right of the function icon respectively, while an input-output parameter ows through the icon. Control parameters are parameters that seldomly need be changed. They are not represented as pins. If a function icon has control parameters a small rectangular handle is placed above the icon, which, if selected, allows the user to change the control parameters through a generated dialog box.
3 A Data-types Infrastructure for Image Processing From a software engineering point of view, a number of observations can be made when studying the nature of images and image processing.
Image Classi cation
Although all digital images basically consist of arrays of pixels, there is a natural basis for the division of images into di erent classes. The di erence between grey valued images and binary images is clear. Less obvious is the di erence between a grey valued image and a label image identifying connected components, for grey valued images and label images use the same elds to store the data. Still they 9
are essentially di erent classes of images as they give a di erent semantic to the pixel values stored. As a consequence grey valued and label images have di erent sets of admissible operations. This natural way of classifying images by their admissible operations should be re ected in the design of an image processing system. An image processing system must, therefore, enforce class separation of its data: the digital images. Most existing image processing systems lack strong image class separation. An example of weak class separation is the representation of binary images as bit-planes in a grey value image. This representation not only spoils memory and transport speed, but also prohibits class safety since the content of a binary image can change as a side e ect of an operation on the grey value image. Apart from class safety, another argument for strong class separation is execution eciency. We cite Piper and Rutovitsch [23] that for eciency reasons an image processing system should not impose any data representation on images, but allow images to be represented in the most suitable way for processing.
Object Oriented Infrastructure
Class separation calls for an object oriented approach in image processing systems [24]. Since it is sensible to deal with actions and properties common to all image classes at a generic level, while dealing with more speci c actions in specialized classes, we argue that an object oriented infrastructure should serve as the backbone in a growing and evolving system. To allow the infrastructure to detect whether an action is legal on a speci c image class, a list of admissible actions is known to each of the image classes. Furthermore class safety, consistency, and standardized checks on function arguments, are taken care of by the infrastructure, rather than being the concern of every programmer. The infrastructure provides the possibility to create new image classes. Through an abstraction mechanism new classes automatically inherit the consistent behavior common to all image classes. In this way the evolving nature of an image processing system can be kept consistent with respect to the data-structures. It anticipates to the need of future image classes without having to change the infrastructure. Future image classes include image sequences, time series, and multi-scale images.
Abstraction Through Function Overloading
Although images are strictly separated by class it would be undesirable and uncomfortable to an end-user if an operation would carry a di erent name for each of the image classes. To map a single action name to di erent image class speci c functions, abstraction is handled through function overloading. Function overloading introduces a speci c function formalism, and saves considerable on the number of function names visible to the user. Function overloading also opens the way to action sharing and inheritance, thus allowing image classing and sub-classing to be used as an organizational tool. For example, it is possible to design a set of operations targeted at speci c processing domains such as microscopical images or the domain of radiology images. Sub-classing a new image class from the grey value main class, re ects the specialized nature. It organizes the set of operations such that it helps both the user and the program developer by restricting the number of admissible actions.
3.1 The infrastructure: Services and Behavior
The infrastructure communicates with di erent image classes in an abstract way through a table driven function overload mechanism. By making a limited number of actions obligatory for every 10
image class the infrastructure generalizes common actions. Thus it standardizes overall system behavior, regardless of any present or future image class.
Dynamic and Logical Images
In the system, the user views of an image as a named object capable of holding any image class, and lets the program concern about dimension management, class safety and legality of actions. It implies that the user is not restricted in choosing what logical image is going to be the output image. As a consequence, an image object is omnipotent in the sense that it can change its class and dimension. So an image object must serve as input as well as output to an operation if so desired, even if the image class of the object changes as a result of the operation. The infrastructure automatically takes care of the adjustment of the output image in all situations by overloading the obligatory create image, and destroy image actions, shielding the user from implementational details.
Generic Region of Interest Processing
Especially when dealing with very large images, there is a need to process only an arbitrary part of the image: a Region Of Interest (ROI). ROI processing is considered a concept at the general level, both in the sense that it is independent of any image class, and in the sense that it should apply to the complete range of possible image processing actions. As a consequence, ROI processing belongs at the level of the general infrastructure, rather than at the algorithmic level. Generic handling of ROI processing, requires the possibility to copy a (hyper) rectangular part of an image forming a temporary image on which the operation can be performed. After the operation the data is copied back to the original image. By limiting the pixel access by a bit-mask, arbitrary shapes of ROI's are handled. Through overloading the copy part image, and copy masked part actions the infrastructure deals with ROI's independent of image type. With this approach, the processing algorithm has no concern with ROI's since a ROI in itself is just an image.
Image Class Conversion
In a class based system as described here, there is a need for class conversions. A general solution to the class to class conversion has been achieved by letting every image class store a single row in a common format. Row by row the class speci c data format is converted to a common format and on to the new format. Each image class is expected to overload the convert to common and convert from common actions. Once implemented, these actions are invisible to the end-user who only deals with the abstract function convert image.
Abstraction and Automation of Image Display
In general, the display of an image not only depends on the image class but also on the image processing domain. In radiology or microscopy, for example, visualization takes on an essential role, whereas in a theoretical research environment the requirements are often much simpler, or di erent anyway. However, since function over-ruling is implicit to function overloading, di erent display requirements are solved generically. The infrastructure provides automatic image display. To also enable the display of a ROI, overloading of an action to display an image part is obligatory for every image class.
11
4 The Image Libraries ScilImage o ers an extensive set of image processing operations, separated by image class into di erent libraries. Table 1 shows the presently supported image classes of the standard. Binary 3D Grey integer 3D Label 3D Grey oat 3D Complex 3D Color 3D
Binary 2D Grey integer 2D Label 2D Grey oat 2D Complex 2D Color 2D
Table 1: Image classes presently supported by ScilImage standard All class speci c libraries are based on the image infrastructure. A 'generic' library, containing all user visible function names, serves as an abstract placeholder to reach class speci c functions through function overloading. To interface the image libraries to the SCIL environment an entry for each of the functions in the 'generic' library has been made in the SCIL command description le. The overhead imposed by SCIL or the overloading mechanism is neglectable, as the time needed to parse and call a function is only a fraction of the time needed to execute the image processing operation. In ScilImage, attention has been given to image processing implementations which are tailored to the speci cs of general purpose computers [11]. The obvious advantage of these fast software implementations over specialized hardware is that they can easily be ported to other architectures e.g. to bene t from faster execution, or to be integrated in other systems and to become more widespread in use. At present more than 300 image processing operations are visible to the user. The actual number of di erent functions is much larger since many of these operations are overloaded to work on several image classes. Moreover, it should be emphasized that the number of functions does not say all about the power of a system. Sometimes, the functionality of a dozen operations can be replaced by a single versatile function. An example is the image expression evaluator 'eval', to which we return later. On the other hand, it should also be noted that years of study may lead to just a few statements. For example, studies to nd the theoretical best approximation of the length of straight lines [25], or the curvature of shapes [26], result in a single statement or single operation, but one well founded. The following gives an incomplete overview of the image processing functionality supported in ScilImage.
Filters, including uniform, kuwahara, sigma, percentile, gauss and fuzzy derivatives, convolution with user de ned kernel, various edge-detection lters etc. etc. Where possible the implementations provide lter size independent performance. Fast binary image and mathematical morphology operations, grey value mathematical morphology and threshold morphology, see below. Full Image arithmetics, logical functions, and versatile image expression evaluator, see below Local image processing operations on interactively pointed image patches ("lens"). 12
A number of segmentation and threshold tools, dynamic segmentation and path search operations with cost values, Freeman chain code handling. Geometric manipulations, such as rotate, panning, and alike. Mouse based image interactions. Display: 2D and 3D with programmable LUT, 3D slicing and volume rendering, automatic enhancements, settings, scaling, sizing, positioning, and dithering. Test pattern generation. Disk i/o (TIFF, PICT, TCL-Image, AIM, ICS). Image postscript generation. Image statistics. Graphics overlaid on image. Interactive and automated particle shape and density measurement, selection and analysis. Various threshold and segmentation methods. Fourier analysis, frequency ltering.
Blazing Bit-mapped Binary (BBB) Images
We present a few topics in more detail. Many of the image processing functions are built on the experience with the previous TCL-Image [13] and ScilAim [14] packages. The representation of binary images in these packages, however, was in con ict with the class separation and class safety policy we advocate. In the new binary image processing library, binary images are represented as binary bitmaps, rather than as bit-planes in grey value images [27]. The new representation not only dramatically improves the execution speed, but is also much more ecient regarding memory requirements. It forms an appropriate format for document image processing. In the bit-mapped binary data-structure 32 consecutive binary image pixels t in a single computer word, allowing basic operations to operate on 32 pixels in parallel. Boolean operations, for example, are speeded up by a factor of 50. On common general purpose architectures they are executed well within real time [27]. A methodological advancement through applying logarithmic decomposition of structuring elements in mathematical morphology, results in erosions and dilations of convex structuring elements, which are an order of magnitude faster than the previously best known software implementations [27]. Independent of image content 17 iterations of an erosion on a 512*512 image, for example, complete within 60 ms on a Sun SparcII rated at 28 MIPS. Threshold morphology or fuzzy mathematical morphology was introduced in [28] to make the morphology theory more robust against noise in the image. Rather than requesting that precisely 1 pixel in the structuring element is an object pixel for removal by the erosion, threshold morphology replaces it by a threshold value, t. For t=1 or t=N, threshold morphology is identical to a dilation or an erosion respectively. For all values in between it allows some tolerance in the data (noise) or the model (the shape of the structuring element). Threshold morphology improves the practical application of mathematical morphology. As all other mathematical morphology implementations 13
in the package, threshold morphology uses the BBB-data structures and supports arbitrary shaped structuring elements. Also the grey value morphological operations have been implemented in ScilImage. It has been shown in [29] that erosions and dilations with parabolic shaped structuring functions are the morphological equivalents of the linear Gaussian scale space lter. A practical advantage of parabolic structuring functions is that they are the unique rotational symmetric structuring functions that can be decomposed by x- and y- dimensioning, yielding an acceptable computing performance.
Image Expression Evaluator
In ScilImage, an image expression evaluator is a handy instrument for image generation, quick modi cation, and for developing an ad-hoc feel for the image contents. Providing separate expressions for 'add image', 'multiply image', and so on, would be cumbersome. In ScilImage this is solved through an image expression evaluator named 'eval', which accepts all C expression operators (and more). We illustrate its use by some examples: eval "B = 3 * A + C / 3.5 * (D / 2 + 128)"
Thresholding an image by a certain value can be expressed by introducing some pixel dependent control as: eval "B = (A
