Entrevistas aplicada

This chapter concludes after an analysis of the possible peak perfor- mance of multimedia instructions in Section3.4and of the implemen- tation of typical low-level signal processing algorithms on SIMD multi- media architectures in Section3.5with some results from benchmarks computed with the image processing software heurisko on various PC platforms. The benchmarks are also available on the CD.

3.6 Conclusions and outlook 51

Table 3.6: Performance of image processing operations optimized with MMX in- structions. The performance is given in MPixels/s for both MMX disabled (-MMX) and MMX enabled (+MMX). All image sizes are 512×512

Operation Pentium 166 MHz Pentium II 266 MHz

-MMX +MMX -MMX +MMX Addition/Multiplication C = f(A,B): Addition, 8-bit 11.0 49.3 77.5 143 Addition, 16-bit 7.4 23.4 24.3 32.4 Multiplication, 8-bit 6.0 38.8 65.4 121 Multiplication, 16-bit 5.5 23.3 23.7 32.5 Accumulation A = A+B: 8-bit to 16-bit 9.8 29.9 49.5 78.7 8-bit to 32-bit 9.6 16.7 16.7 26.3 16-bit to 32-bit 8.4 14.0 16.2 22.3 Convolution: with 1/4[1 2 1] 2.4 22.7 8.4 42.6 with 1/16[1 2 1, 2 4 2, 1 2 1] 1.1 10.4 2.8 18.9 Laplace 1.3 10.4 5.0 28.6 Sobel 1.4 10.4 4.4 26.7 with 1/16[1 4 6 4 1] 1.4 15.8 4.6 29.4 with 5×5 mask 0.3 4.1 1.0 7.8

Erosion and Dilation:

with 3_×3 mask 1.5 10.7 4.1 23.6

with 5×5 mask 0.6 4.3 1.9 9.3

From Table3.6can be seen that up to 400 MOPS can be reached with modern standard processors. Thus, more complex real-time image pro- cessing (10 MPixels/s) with up to 40 operations per pixel—for example a convolution with a 5×5 mask—is possible.

In this chapter, modern multimedia architectures were discussed. The analysis showed clearly that low-level signal processing algorithms are accelerated well beyond the usual steady increase in computing power. This development was not initiated by the signal processing or computer vision community but by a new mainstream multime- dia trend. However, as sophisticated algorithms are also required for sound processing and video compression, the architectures proved to be very suitable for all kinds of low-level signal and image process- ing algorithms. The continuous development of multimedia architec- tures indicates that further significant progress can be expected in this

52 3 Multimedia Architectures field, which will accelerate the computing power for signal processing faster than for general purpose number crunching. It can thus also be expected that some weaknesses of the current architectures (such as missing support of lookup table operations) will be removed and that more efficient handling of alignment problems and non-SIMD instruc- tion types will be incorporated into future architectures.

3.7 References

[1] Borland International Inc., (1991). Turbo Assembler Quick Reference Guide.

[2] Intel, (1996). Intel Architecture MMXT M _{Technology, Developer’s Manual.} Intel order No. 243010.

[3] Texas Instruments, (1988). Graphics operations. In TMS34010 User’s Guide. Houston: Texas Instruments.

[4] Motorola Inc., (1991). Graphics unit implementation. In MC88110 Second Generation RISC Microprocessor User’s Manual.

[5] Mou, A. Z. J., Rice, D. S., and Ding, W., (1996). VIS-based native video processing on UltraSPARC. In Proc. Int. Conf. on Image Proc. ICIP’96, Vol. II, pp. 153–156.

[6] Sun Microelectronics, (1995). Visual instruction set user’s guide. [7] Intel, (1996). Intel Architecture MMXT M _{Technology, Programmer’s Ref-}

erence Manual. Intel Order No. 243007-001.

[8] Intel, (1996). Intel MMXT M _{Technology Overview. Intel order No. 243081-} 001.

[9] AMD, (1996). AMD K-6 Processor Multimedia Extensions (MMX). AMD publication No. 20726.

[10] AMD, (1998). 3DNow! Technology Manual. AMD Publication No. 21928. [11] AMD, (1998). AMD-K6-2 Processor Code Optimization. AMD Publication

No. 21924.

[12] Motorola Inc., (1998). AltiVec technology programming environments manual.

[13] Rubin, P., Rose, B., and McCallig, M., (1996). Motion video instruction extensions for alpha. Digital equipment.

[14] Jähne, B., (1997). Digital Image Processing—Concepts, Algorithms, and Scientific Applications, 4th edition. New York: Springer.

4 Customizable Medical Image

Processing Systems

Athanasios M. Demiris,Carlos E. Cárdenas S., and

Hans Peter Meinzer

Abteilung Medizinische und Biologische Informatik

Deutsches Krebsforschungszentrum Heidelberg (DKFZ), Germany 4.1 Introduction . . . 53

4.1.1 Developing specialized components for a host system 53 4.1.2 Requirements . . . 56 4.2 State of the art . . . 57 4.3 Identifying development phases . . . 58 4.4 Components of the architecture . . . 60 4.4.1 Repository . . . 60 4.4.2 Statistical image analysis component. . . 63 4.4.3 Optimal parameter value estimation component . . . 64 4.4.4 Creation of graphical user interfaces . . . 66 4.5 Implementation of the architecture . . . 70 4.5.1 Implementation techniques . . . 70 4.5.2 A sample use of the architecture . . . 71 4.6 Conclusions . . . 74 4.7 Future work . . . 74 4.8 References . . . 75

4.1 Introduction

4.1.1 Developing specialized components for a host system The image processing functionality needed in a specific domain, for ex- ample, radiology, consists of an invariant and a variable part. All image processing functionality that aims at interpretation or manipulation of the semantics of the image make up the variant part of the system. This part changes for every new application in the domain. It is obvious that a radiology department will need a different set of image processing

53

Handbook of Computer Vision and Applications Copyright © 1999 by Academic Press

Volume 3 All rights of reproduction in any form reserved.

54 4 Customizable Medical Image Processing Systems tools for the analysis of magnetic resonance1_{(MR)-mammograms than}

for the volumetric calculations in computer tomography (CT) images of the upper abdominal area. In these examples the end users are clinical radiologists. Their requirements are expressed in terms of the clinical cases they want to treat and that is exactly the way in which the software solution offered to them should be addressed and organized by the de- velopers. This obvious observation calls out for specialized modules of a system that target each different problem in an application do- main even if there are functional overlaps among them. The fact that a region-growing algorithm probably would be used in parts of more than one case does not justify collecting all possible functions, integrating them into one monolithic system, and installing it in the site of an end user. This attempt to a priori cover all possible scenarios by structur- ing the end-user system in terms of image processing functionality in- creases the work load and decreases the acceptability. Such solutions cannot be integrated into everyday clinical routine. Creating special- ized components addressing specific problems instead of all-purpose systems enforces user-centered design and developments as well as encapsulation of overcomplicated functionality, which is feasible only when a concrete and restricted application domain is addressed.

The invariant part of domain-oriented image processing systems deals with the image handling. Image handling means image retrieval, display, contents-preserving functionality like gray-level manipulations, zooming and similar visual information enhancements, storage and transfer. Although the core of each application should vary for each case this part should be uniform and used in an intuitive way. A de- tailed analysis of the work situation should be carried out and the re- sulting system should contain a domain specific visual vocabulary, that is, domain specific elements, terms, interactions etc. as shown by Gul- liksen and Sandblad in [1]. If this visual vocabulary is formalized ap- propriately as shown in Section4.4.4, other systems may adapt to it— thus resulting in a uniform look-and-feel for all applications of image processing in a specific domain or at least in one end-user site.

The invariant part of an image processing application may be used as a framework to host components addressing specialized issues. Thus a viewing station in a radiological department may be extended to in- clude modules for the analysis of CT image-series of the liver, or digital mammography etc. Then the main task of the image processing spe- cialist would be to extend an existing host system by a new module in a system-conforming way to address a new application. This gives software development for image processing applications a new dimen- sion, which can be accomplished with the existing software technology. However, an infrastructure for this kind of development is needed.

4.1 Introduction 55 There are two central aspects in this domain-specific kind of soft- ware development that are not supported by conventional software en- gineering environments. First of all there are no systems that can adapt their outcome to conform with one or more given host systems. This is a task that has to be taken care of by a developer, thus leading to delays because of the time needed to become acquainted with the host system and the target characteristics, as well as the permanent limita- tions in the development of a solution. The second aspect is that the software components created or used for the assembly of the new ap- plication module can only be viewed, in such an environment, as yet an- other piece of software with no specific characteristics. The description of an image processing component as such contains many more char- acteristics than a generalized software component, which contributes numerous advantages, among them the easier retrieval of the correct component to use.

The latter is a more general problem of software development. Code

reuse is supported by current programming paradigms, for example,

object-orientation, but the problem that remains to be treated is the acquisition of the appropriate code to be reused. The same problem arises on higher abstraction levels as well, especially when trying to locate the appropriate set of software parts to reuse. This is a problem that can only be efficiently tackled in domain specific environments.

Since the generalized software development tools fail to success- fully support the development of image processing components there is a need for dedicated solutions. The creation of new development en- vironments for each branch is for a number of reasons not the optimal solution. The most important reason is that all developers have se- lected their preferred tools and put them together into a development environment. Introducing a new solution that can handle at least the same problems in a more domain-oriented way will definitely cause a steep learning curve and require many releases and person-years be- fore it can be used in an efficient way. The person-years required will certainly include interdisciplinary knowledge ranging from compiler theory to advanced image processing and further to radiology or any other application domain.

We will introduce an alternative approach for the development of components for image processing systems by presenting an informa- tion architecture that can be used to extend existing development en- vironments with domain specific parts. This information architecture (or recently more often referred to as infotecture) will itself be imple- mented as a series of components that can be added to any existing development system that follows the object-oriented paradigm.

The overall scenario for the application of object-oriented software engineering in computer vision applications is shown in Chapter5. We use the concepts presented there to create components for imaging

56 4 Customizable Medical Image Processing Systems applications especially in the medical imaging domain. Components in our context can be thought of as software building blocks containing an algorithmic body along with a graphical user interface description and suggested parameter values for operation in a specific data context, for example, medical data. The algorithmic body can be created in any programming language. In Chapter6, a generic solution for the creation of algorithms by means of parameterized types is presented. The use of such techniques enhance reuse not only at the component level, but also at the level of algorithmics in a specific programming environment (higher granularity reuse).

4.1.2 Requirements

An architecture for the support of image processing development should comply with a series of requirements. The need for a domain- oriented character of such an architecture has been emphasized in the previous section and is definitely one of the obvious requirements. Another quite obvious prerequisite is the reduction of “noise” during development, speaking in terms of information theory, that is, all activ- ities not directly associated to the problem under consideration. This leads to a reduced cognitive load for the developer and should also lead to productivity enhancement. Many developers are very produc- tive with a development tool after a long period of working with it. The learning curve for such systems is very steep. This is a reason for rejec- tion of such a system. For the architecture presented here we declared minimal learning effort as one of the basic claims.

The solution to be developed should be considered as added-value software engineering for image processing and should coexist with ex- isting development environments instead of replacing them. Because we decided to use innovative software engineering techniques this as- pect can only be adhered to in part. Development systems that are not based or do not support such techniques cannot be supported by such an architecture.

As the major improvements of any development tool can only be carried out after the first release we proclaim the extensibility of the architecture itself as a major goal. The list of requirements for the ar- chitecture that should support the development of customizable image processing systems can be summarized as follows:

• inclusion of domain-oriented aspects;

• reduction of the cognitive load for the developers;

• optimal learning curve;

• coexistence with other development utilities;

• innovative software engineering concepts; and