**2.2.3 Three-sensor device**

This architecture acquires colour information using a beam splitter to separate incoming light into three optical paths. Each path has its own red, green or blue colour filter having different spectral transmittances and sensors for sampling the filtered light. Because the camera colour image is obtained by registering the signals from three sensors. The mechanical and optical alignment is necessary to maintain correspondence among the images obtained from the different channels. Besides the difficulties of maintaining image registration, the high cost of the sensor and the use of a beam splitter make the threesensor architecture available only for some professional digital cameras (Lukac & Plataniotis, 2007).

#### **2.3 Real-time imaging systems**

Real-time systems are those systems in which there is urgency to the processing involved. This urgency is formally represented by a deadline. Because this definition is very broad, the case can be made that every system is real-time. Therefore, the definition is usually specialized. A "firm" real-time system might involve a video display system, for example, one that superimposes commercial logos. Here, a few missed deadlines might result in some tolerable flickering, but too many missed deadlines would produce an unacceptable broadcast quality. Finally, a "soft" real-time system might involve the digital processing of photographic images. Here, only quality of performance is at issue. One of the most common misunderstandings of real-time systems is that their design simply involves improving the performance of the underlying computer hardware or image processing algorithm. While this is probably the case for the mentioned display orphotographic processing systems, this is not necessarily true for the target tracking system.

Here, guaranteeing that image processing deadlines are never missed is more important than the average time to process and render one frame. The reason that one cannot make performance guarantees or even reliably measure performance in most real-time systems is that the accompanying scheduling analysis problems are almost always computationally complex. Therefore, in order to make performance guarantees, it is imperative that the bounded processing times be known for all functionality. This procedure involves the guarantee of deadline satisfaction through the analysis of various aspects of code execution and operating systems interaction at the time the system is designed, not after the fact when trial-and-error is the only technique available. This process is called a schedulability analysis. The first step in performing any kind of schedulability analysis is to determine, measure or otherwise estimate the execution of specific code units using logic analyzers, the systemclock, instruction counting, simulations or algorithmic analysis. During software development, careful tracking of central processing unit utilization is needed to focus on those code units that are slow or that have response times that are inadequate. Unfortunately, cache and direct memory access, which are intended to improve average real-time performance, destroy determinism and thus make prediction of deadlines troublesome, if not impossible. But, schedulability analysis is usually the subject of traditional texts on real-time systems engineering (Lukac & Plataniotis, 2007).
