A visual programming interface for an image processing environment

concept specialization of concept specialization of Data object X object Y object A relatable Y request X request Request B relatable A relation Relation B relation uses concept Figure 5.6: Class diagram de ning the structure of relationships. 5.4. Concepts in the infrastructure 93 concept request purpose specify need for instantiation of data object examples of specializations see data object concept interface methods for identi cation of request visualization of request spatial extent manipulation weight manipulation Table 5.4: Summary of the concept request. B relation Y object 1 Y object 2 A relation 1 A relation 2 X object link Figure 5.7: Example of instantiation of static relations. Then, corner objects and corner requests are able to participate in adjoining relationships, and line objects and line requests are able to participate in both adjoining and perpendicular relationships. The interface of each relatable-object concept includes a method to supply the data necessary to establish the relationship. For example, a constituent-relatable-object has a method to supply the caller with a reference to its parent/child and a temporal-relatableobject has a method to supply the time of construction. The interface of a relatable-object also includes a method to respond to changes in the relationship. Removal of the related data object leads to removal of the object or adjustment of its certainty factor. 94 Chapter 5. A blackboard infrastructure for object-based image interpretation concept relationships purpose record relationships between data objects record relationships between requests examples of specializations spatial relationships perceptual relationships endorsement relationships logical (constituent) relationships temporal relationships interface methods for supply of data necessary to establish relationship update of changes in relationship navigation to related objects Table 5.5: Summary of the concept relationships. Relations come in two avors: static and volatile. Static relationships are computed once for each possible pair in the set of objects under consideration by the algorithm. The computed relations are then stored by instantiation of a relation object between two related objects, see gure 5.7. When relations between objects are inspected it su ces to follow the links to know which objects are related. An example of a typical static relationship is a constituent relation, used to construct a hierarchy of requests (a model) or data objects. Static relationships have facilities to re-act to changes in the relationship, their lifetime need not span the entire interpretation process. Volatile relationships are not stored but computed as necessary. The relatable-object concept is used to determine whether the relationship exists but no relation object is instantiated to keep track of computed relations. Volatile relationships thus have to be recomputed whenever the set of objects under consideration changes. An example of a typical volatile relationship is a temporal relation. Computing a temporal relation is simple and computationally fast so it is not really necessary to store such relations. The choice between a static or volatile relation is made by the user. The decision depends upon the type of use of the relation, its lifetime in the application, the complexity of computing the relationship, memory requirements, and computing power. Some types of relationships, e.g. spatial, may be used both in a static and volatile way in a single application: The use of one does not exclude the use of the other. 5.4.4 Models Object graphs are used to construct a symbolic model of the world. The nodes in an object graph consist of requests and arcs consist of relationships. A model of a parallelogram is given in gure 5.8. Each node of an object graph may consist of another object graph to create a hierarchical 5.4. Concepts in the infrastructure 95 cu rv ili ne ar s eg m en ts L ev el 3 co m po si te o bj ec ts L ev el 4 KS parallelogram detector constituent relation adjoining relation parallel relation parallelogram request line segment request Figure 5.8: Example of an object graph with a hierarchical structure. 96 Chapter 5. A blackboard infrastructure for object-based image interpretation structure. Knowledge about the hierarchical structure of an object graph resides either in knowledge sources or in requests. Putting the knowledge in requests is done by de ning the concept of a composite request, a specialization of the request concept. The interface of the composite request has methods to retrieve the constituent parts of a composite request. Complex geometrical models of symbolic objects are more easily de ned within a single request concept. In case the symbolic object has a clear hierarchical structure the object graph is a useful tool to re ect that structure. 5.4.5 Knowledge sources A knowledge source has two versions: an active one and a passive one. The passive version of a knowledge source operates in a data driven way. It has one or more data objects and relationships as input. The output consists of new data objects and/or relationships, typically of a higher level of abstraction. For example, the line grouper in gure 5.5 has a series of line segments as input and parallelograms as output. In addition, the line grouper may store the computed aligned and adjoining relationships on the blackboard. The active version of a knowledge source operates in a demand driven way and has a request as input. The active version aims at nding the best matching instantiation of a data object of the requested type by examining data on lower levels of the blackboard. In case the necessary data to ful ll the request are not available the knowledge source posts requests for objects at a lower level of abstraction. For example, if the line grouper in gure 5.5 nds a request for a parallelogram on level 4 of the blackboard and no line segments are present on level 3 it posts a request for line segments on level 3. Each knowledge source has a source and destination level, indicated by the meaning (textual description) of a level. The source level is used to group the knowledge sources into classes that operate on the same level of the blackboard, i.e. the same level of abstraction, the same stage in the image interpretation process, or on the same type of data objects. The same holds for the destination level. For example, image processing operations have either sensory data or point feature spaces on their source level. They produce point feature spaces or feature values on their destination level. The applicability of a knowledge source in a speci c situation is determined by the trigger and test methods of the knowledge source concept. The methods use the presence and properties of data objects, requests, and relationships to indicate whether the execution of a knowledge source is appropriate. The execution of a knowledge source is initiated by the strategy guiding the image interpretation process. We now elaborate on the di erence between a knowledge source and a strategy for a better understanding of both concepts and to be able to make a well founded choice in the implementation of an application. The di erence between a knowledge source and a strategy is determined by the amount of knowledge an algorithm uses on the type of data objects involved. If the interface of the abstract data object concept su ces in the expression of the algorithm it is implemented as a strategy. If the algorithm uses the interface of a 5.4. Concepts in the infrastructure 97 concept knowledge source purpose compute data objects and relationships examples of specializations feature detection feature value extraction geometrical reasoning graph matching con ict resolution interface methods for identi cation of knowledge source source and destination level manipulation trigger and test functions weight manipulation execution of the knowledge source Table 5.6: Summary of the concept knowledge source. specialization of the data object concept it is implemented as a knowledge source. As an example, we show how logical sensors (Henderson & Shilcrat, 1984) and sensor modules (Weller, Groen, & Hertzberger, 1990) would be implemented in our infrastructure. The idea of logical sensors and sensor modules is that sensors can be de ned abstractly in terms of computational processes operating on the output of other sensors. Each sensor has several techniques to compute the output and internally selects the component providing the best result. Each component of a sensor operates on a speci c type of data object and therefore is a knowledge source in our infrastructure. The behaviour of sensors aimed at selection of the most appropriate component is expressed independent of the type of data object and therefore a strategy. The di erence between a knowledge source and a strategy is not determined by the complexity of the algorithm. A knowledge source is allowed to use an arbitrary amount of domain knowledge in its operation. This knowledge does not have to be present on the blackboard. 5.4.6 Controller The strategy guiding the image interpretation process is developed by the user and implemented as a specialization of the blackboard controller. The blackboard controller determines the order in which the knowledge sources are executed. The controller uses several sources of information to determine the order of execution: the (implicit) strategy, the meaning of the levels of the blackboard, the data objects, requests, and relationships present on the blackboard, the occurrence of blackboard events, and the knowledge sources present. Blackboard events are generated by the level concept and send to the controller to indicate changes. Changes include addition and removal of objects (data objects or requests). 98 Chapter 5. A blackboard infrastructure for object-based image interpretation concept controller purpose guiding the image interpretation 

A software environment for image interpretation

I-see: An AI tool for image understanding

A software package to support advanced research in the field of image processing and image analysis must have sufficiently powerful features, especially if it is to be used in a variety of application domains. In this contribution, we present the concepts of the LUCI image processing package, which has been developed in order to meet requirements that have been formulated as a result of previous experiences in our research group. These include support for multi-dimensional images and programming constructs to perform operations on those pixels that are contained in areas of arbitrary shape. In addition, we briefly present support tools for managing this software and its documentation.

LUCI, a portable software package for different fields of image processing research

In this paper, we will review some visual inspection problems that were presented to our laboratory by a consortium of Belgian industrial companies. These problems were selected to serve as a test vehicle for a software package, called LILY (Leuven Image processing Library), that was developed for the consortium by our laboratory. Therefore, this paper consists of several parts : first, an overview of the LILY software package will be given; then, three case studies carried out with the package will be detailed. The case studies are very different in nature, so that a variety of algorithms will be dealt with. The first case study is about defect inspection in unexposed radiographic film. In this case, image data is presented as a continuous stream of lines of pixels. In the study, convolution techniques, curve fitting methods and Fourier analysis were applied. The second case studv treats the inspection of textured textiles and is thus essentially a texture inspection problem. Here, we will introduce a novel approach, whereby self-adaptive convolution filters are constructed from test samples. Both the size and the coefficients of the convolution mask are deternuned from the texture that is to be inspected. A last case study deals with defect detection in solder joints. Here, we will show how a well adapted illumination can simplify the inspection to a great extent.

Some Visual Inspection Problems in the Belgian Industry (Invited).

In this paper we will present LILY, a software package for image processing. LILY stands for Leuven Image processing LibrarY and has been developed with funding from a large number of Belgian industrial companies who are all interested in visual inspection problems. Therefore, the algorithms in the package are mainly concerned with this application field, although also other algorithms are incorporated. All procedures have been written in Pascal and Fortran on a VAX running VMS, with current work being done to convert the package to the C-language. Along with the programmed algorithms come a large number of support functions and procedures to facilitate the development of image processing programs. The package thus presents itself to the user as a large toolbox from which the appropriate tools must be taken to accomplish a certain task. The available procedures fall in one of the following categories: segmentation, coding, filtering, feature extraction, classification, texture analysis, relaxation, and pyramidal structures. In the first part of the paper, an overview will be given of the algorithms that are present in all these different classes. Syntactical conventions, documentation, maintenance and development tools will be discussed also. The second part of the paper is devoted to some specific problems that have been solved as a testcase for the algorithms. First Laws' procedure for texture segmentation is implemented and applied to the detection of defects in textiles. The procedure involves filtering the image with one or more suitably chosen masks, squaring the obtained values, computing the energy as a texture feature and classifying the resulting values. Each of these steps corresponds more or less to a different module of the package. A second industrial problem of defect inspection in unexposed radiographic film has been approached using three alternative techniques: one dimensional convolution filtering, Fourier domain filtering and polynomial regression.

Lily: A Software Package for Image Processing

Handle everyday research tasks with reliable, citation-backed results

Your personal Research Agent to handle research tasks with citation-backed results

Popular Tasks used by Researchers

How can I help with your research?

Meet SciSpace

Get more enhanced response by uploading the PDFs you want me to reference.

No relevant PDFs in your library

SciSpace is the AI research assistant for academics. Run systematic literature reviews on 280M+ papers, and write papers with cited sources. Trusted by 1M+ students, PhDs & researchers.

SciSpace | AI for Research

Analyze PDFs

Code & Manuscripts

Funding & Grants

Literature & Patents

Medical & Clinical Data

Systematic Review

Visualize & Present

Web & Data

Build a Google Scholar-like website for your research.

Build a website

Create charts and images for your research

Create a Chart

Write a paper for submission to a journal

Draft a manuscript

Patent Search

Design eye-catching scientific posters in minutes.

Scientific Poster Generation

Systematic Literature Review

One task is running at the moment. Your messages will be shown right after.

Drag and drop or click here to browse

Loved by <highlight>1 million+</highlight> researchers

Extract a list of specific topics and their sources from unstructured text

Topics

Compare and analyze relevant papers that matches with your search

Papers

Get insights from PDFs and bookmarked papers from your library

My library

Recent searches

Try searching for:

Catch AI-generated content in scholarly and non-scholarly content

{ai} Detector

Ai Writer

Get PDF Summaries, highlighted text explanations 

Chat with PDF

Effortlessly create in-text citations and bibliographies in APA and 2,500 other formats

Citation generator

Get explanations, summaries, and answers on academic papers

Ease up your research workflow with {scispace}'s cohort of exciting AI tools

Elevate your academic writing skills and convey your ideas the way you want

Paraphraser

Explore our range of reading and writing tools

Your file is being prepared and should be ready in a few minutes. If it's a large file, it might take a bit longer. You can close this window, and we'll email you the file when it's done.

You have reached a maximum limit of <strong>{limit}</strong> columns in the table. Remove at least <strong>1</strong> column to add or create another one.

Rudi Bartels

Author Tools

Chat about Author

Papers

Lily: A Software Package for Image Processing

Some Visual Inspection Problems in the Belgian Industry (Invited).