| NDT.net - March 2002, Vol. 7 No. 03 |
Standard methods for flaw detection in aluminium castings use a radioscopic image of the casting in question. This image will be inspected using special adapted filters. For each casting in the inspection the tool has to be parameterised.
An alternative method attempts to obtain more information about the casting (and the flaws) by using more than one radioscopic image of the object. Each image shows the casting from different angles. The different positions of the casting in the images are used to track a flaw through these images. A flaw should be present in more than one image since it is the projection of a 3D object onto these 2D images. That makes it possible to determine if it is a real defect or a distortion of the image. The great advantage of this method lies in its ability to inspect different objects without a re-parameterisation. A possible disadvantage comes from the need to process a number of images, which could lend to severe speed problems.
The method should be introduced here without going into the details (a more detailed description can be found in [1, 2]). The method consists of two phases. In the first phase we use pattern recognition to process a sequence of X-ray images of the object. We detect the edges in each image of the sequence using a Laplacian of Gaussian filter. After that we segment the closed regions and compute several features of each region. This leads to a classification of the regions into potential flaws and non – flaws. This first phase of the method takes most of the time because of the necessity to provide a pattern recognition on each single image.
Fig 1: Overview
|
In the second phase of the method we track the potential flaws. We try to identify a flaw, which we detected in one image in one of the next images of the sequence. This is possible by using the information on the movement and the rotation of the cast between two images. We will detect a flaw only when it is present in a certain number of subsequent images. With this step we can separate the potential flaws into real defects and false detections.
Figure 1 shows an overview of the phases of the method.
We implemented the method first with MatLab. We tested this first implementation with real and simulated data; the preliminary results are encouraging: We could detect 100% of the flaws in our test data, which consists of 16 sequences of X ray images. Thereby we got no false detection.
Our next step was the implementation of the method as a C++ application, which should run under Windows. We hoped that this would increase the speed of the application. The present paper describes details of the design and the implementation. Section 2 will give some details on the overall structure of the application. Section 2.3 will look into the usage of MMX. Section 3 gives an overview of the results. The summary is in section 4.
We choose an object-oriented approach for the implementation. Our aim was to make the implementation as independent as possible from the exterior environment. Consequently, we had to separate the method from the user interface, so that the user interface (which is usually provided by the manufacturer of the testing machine) could be replaced easily (Document – View – Architecture). The GUI of our implementation gives the user the opportunity to manipulate all parameters of the process.
2.1 Document – View - Architecture
The design of the application was guided by our wish to provide a logical and consistent structure. The method of flaw detection should be independent from a certain GUI. Therefore, we decided to separate method and data from the user interface and the presentation of the data. Naturally, we choose a Document – View – Architecture. The reader will find an overview in [4].
It is the concept of a Document – View – Architecture to separate the data of the application process (that is the Document) from the presentation of the data itself (the one or more Views). The term document in this context may lead to a false direction because one may think only of "documents" in connection to office applications. In the current context "document" means the all of the data, which is processed by the application. In our application these are the images, the results of the pattern recognition processes and so on. The document part of the application also provides a method to save the data and to manipulate them.
A document can be represented to the user via several views. A view could be a diagram that shows the result of an operation. Since the document is strictly separated from the views there are no problems to provide another view without changing anything at the document part of the application (Figure 2).
Fig 2: Document - View - Architecture.
|
The document part consists of the representation of the data in the memory. Also it provides methods to process the data. The user interface is independent. It consists of the view part, which presents the data to the user and the user control which enables the user to control the program parameters via menus, dialogs, etc. Figure 3 gives a course overview of the structure of the application.
Fig 3: Control and presentation
|
For the detection (which is part of the document) we provided an independent thread. That gives us the opportunity to substitute the GUI if necessary. A thread is a kind of a sub-process but in opposition to the Win32 task a thread is not executable as a standalone (so you will not see a single thread in the task manager). Anyhow all threads are independent from each other. An application can consist of several threads.
The advantage of using threads is that actions that do not depend on each other can be handled independently. Threads are executed quasi – parallel i.e. the user gets the impression that they are executed at the same time – actually the operating systems schedules each thread in such a way that every thread is executed in a time slice after each other.
As an additional advantage we can program the method for flaw detection independent from the GUI. But there has to be some kind of communication interface between the parts of the program.
Figure 4 shows the interaction of the two main parts of the program. For means of communication the interface between them consists of two parts: The data section and the parameter section. The GUI writes to the parameter section (in order to change the behaviour of the flaw detection); the detection method only reads the parameters and writes the data (to give the GUI access to the results). The GUI prepares the data and shows them in different views to the user.
Fig 4: Design of the interface
|
2.2 Actual Implementation
Actually, the data section, which is the interface between the parts of the program, consists of two parts. Both are global variables so that both threads have access to the interface.
The application itself is a class that is derived from CApplication (according to the MFC – Microsoft Foundation Classes – model). In the constructor of the class the view part is initialised. As soon as a detection process is triggered by the user a new worker thread is started which contains the real process. The function CApplication::OnIdle() is frequently called by the scheduler of the operating system. It updates the different views, which the GUI shows.
The main goal of the development process was to make the execution fast. Therefore we undertook a profiling on each step of the detection method. This lead us to the lines of code that should be modified to speed up the program. The main problems occurred in the segmentation part (Figure 1). The Region – Growing – Algorithm, which is used, detects regions, which are separated from each other through edges. We took care to re-develop the algorithm since it was both fast and robust. The reader will find a detailed description of the profiling process in [3].
Another possibility to enhance the speed of the image processing is to use MMX. We will describe this in the next section.
2.3 MMX
Modern Intel compatible CPUs have an additional instruction set which is capable to perform fast image processing. The original intention of the MMX instructions (MultiMedia eXtension) was to enhance the graphic performance of PCs. MMX instructions are executed by a special execution unit inside the CPU. Additionally this second ALU is highly parallel in itself. The MMX instruction set is an SIMD instruction set (Single Instruction – Multiple Data), i.e. one instruction can manipulate up to eight numbers. The conventional CPU kernel performs the program control.
The possibility to perform eight independent integer calculations at the same time leads to the estimation of big performance enhancements through MMX. In the past it was difficult to use MMX because no high language compiler was capable to generate MMX instructions in its code. The only possibility to use MMX was to write assembler code for the calculations by yourself. Since assembler code is far more complex than code written in any higher programming language and any change to the program code is far more difficult to perform the usage of MMX meant a non – tolerable effort. So the barrier to use MMX was high. A description of the use of direct – coded MMX instructions in image processing can be found in [5].
Nowadays, Intel corporation provides libraries for different applications of MMX for different higher programming languages. The MMX instructions are hidden inside functions that perform complex operations. Beside the Intel Image Processing Library (TM) (the one we used for the flaw detection) other libraries exist, such as the Intel Signal Processing Library (TM) for one – dimensional signal processing. Each library is a Dynamic Link Library (DLL).
An additional obstacle to use MMX is that Intel changes the instruction set several times when introducing a new processor. Though all CPUs since the PentiumMMX support the MMX instruction set for each processor, new and better instructions were implemented. Either the code has to be adapted for each new processor or the choice of hardware on which the application will run needs to be narrowed.
This problem will be solved with the MMX libraries. The application uses a DLL called ipl.dll. This one checks which processor is actually installed (using a second DLL: Cpuinf32.dll). The correct processor – dependent DLL that actually implements the library functions will then be loaded into the memory. This whole procedure is truly transparent for the developer– as you may say: "under the hood" – so that you have not to care about (Figure 5). Another additional advantage is that you do not have to change anything on your code to make it fit for a new processor – just install the new processor – dependent DLL.
Fig 5: Initialize the MMX library.
|
The Intel Image Processing Library contains functions for filters, convolutions etc. and for the data structures to support the image processing. Images are described through a header to which the image data is associated. The library supports several image formats, as:
Each format supports a one-bit per pixel, eight-bit, sixteen-bit, thirty-two-bit integer value per pixel or a float value per pixel.
Although you have the possibility to use only this pre-defined data structures we developed our application using our own data structures – because the original development and design was done without the Intel Image Processing Library. Therefore, we had to copy the data into the appropriate data structures from the library. Figure 6 shows the steps towards a call to the library in principle.
Fig 6: Call to a MMX - function.
|
So we had to copy the whole image data twice for one call of a library function. Despite this overhead we experienced a great speed-up of the program (see section 3).
You can download the Intel Image Processing Library for free from the web [6]. You will also find detailed documentation there.
In order to measure the speed of the program we used several sequence of X ray images with different numbers of potential flaws. Every sequence consists of ten images, each with a size of 256 x 256 pixels (this means our test images where smaller than normally used.) We measured a processing time of halve a second per image.
From this we calculated the processing time of normal – sized images as to be about 1 second on a Pentium III with 600 MHz. A sequence of 70 images as it is actually used could be processed in about one minute. The faster speed through using MMX is independent from the number of potential flaws. We could attribute this to the fact that MMX is used for image processing, e.g. for the calculation of the gradient of the image in which case the processing time only depends on the size of the images but not on the number of potential flaws. Figure 7 shows the processing time for image sequences of ten images each with a different number of potential flaws.
Fig 7: Computation time dependent on the number of potential flaws.
|
We got the very same result when we looked at the computation time of the detection process only (i.e. the first part of our method). The computation time accelerates linear, the gain in speed when using MMX is approximate the same. Figure 8 shows the computation time for the detection phase for sequences of ten images dependent on the number of potential flaws.
Fig 8: Computation time for phase 1.
|
The computation time for the tracing of the potential flaws through several images, i.e. the second phase of our method, is more or less exponential over the number of potential flaws. In this case we experienced no speed – up when using MMX because MMX is not used for these calculations. Figure 9 shows this for sequences of ten images and a different number of potential flaws.
Fig 9: Computation time for phase 2.
|
In [1, 2] Mery describes a new method for the detection of flaws in aluminium castings. Originally the method was implemented and tested in MatLab. The goal of this project was to transfer the algorithm to the programming language C++. This should lead to:
Since we reached these goals it seems now possible to use this method in an industrial environment to improve the quality management of producing aluminium castings.
The clear structure of the application with its strictly independent parts (the document and the view part) gives the opportunity to adapt the program to different environments. In future it will be possible to easily expand and improve the program.
We consider the speed of the computation as sufficient to meet the requirements of an industrial use. A state-of-the- art PC can process 70 images per minute. To reach this speed we used MMX among other things.
This means that we achieved the goal of the project to show that the method could be used in practice.
| © NDT.net - info@ndt.net | |Top| |