Abstract:
A method and apparatus for digital video capturing and compression supports multi-viewpoint interactive video applications. Multiple (typically hundreds of) video cameras centripetally placed in a three dimensional space acquire real-time visual pictures of the same 3D scene from multiple viewpoints at the rate of 20-30 frames per second (fps). Parallel Multi-Viewpoint Video Capturing and Compression (PMVCC) supports the operation of the apparatus. In an exemplary realization, a Multi-DSP Array (MDA) architecture uses hundreds of high-performance digital signal processors (DSPs) working in parallel to obtain a sustained computation power of hundreds of GIPS (Giga Instructions Per Second).

Description:
CROSS REFERENCE TO RELATED APPLICATIONS  
       [0001]    This application claims the benefit of U.S. Provisional Application No. 60,191,754 filed Mar. 24, 2000, the disclosure of which is herein incorporated by reference in its entirety.  
         [0002]    This application is related to the copending application by Yonghui Ao, filed on the same date as the present application, entitled “METHOD AND SYSTEM FOR SUBJECT VIDEO STREAMING”. This related application will be hereinafter referred to as the Subject Video Streaming application. 
     
    
     
       BACKGROUND OF THE INVENTION  
         [0003]    1. Field of the Invention  
           [0004]    The invention relates in general to the field of digital video capturing and compression, and particularly to real-time multi-viewpoint video capturing and compression. The data output by this apparatus can be used to serve a plurality of simultaneous viewers with different interests in the same 3D scene or object. Therefore, this technology can be used for such interactive video applications as E-commerce, electronic catalog, digital museum, interactive entertainment, and the like.  
           [0005]    2. Description of the Related Art  
           [0006]    The need for and the technological development of multi-viewpoint image or video capturing technologies have been around for many years. The history can be traced even back to the 19th Century when people attempted to take simultaneous photos of a running horse from different angles. When combined with modern electronics and digital technologies, however, new challenges arise.  
           [0007]    Consider a typical digital video camera that takes color images of 512×512 pixels in size at a refresh rate of 30 frames per second (fps). Consider further a set of, for example, 200 or more such cameras working synchronously, producing over 200 concurrent digital video streams. This amounts to a raw data rate of about 20 Gbit/s. If the standard MPEG-2 scheme is used for video compression, a total of more than 200 MPEG-2 threads must be handled simultaneously. This would demand the computational power of hundreds of Giga-instructions per second, or GIPS (i.e., units of 10 9  instructions per second). Such a raw data rate and such a level of computation power are far beyond the capability of any single or multiple digital signal processors existing today at a commercially feasible cost. Take, for example, the Texas Instruments (TI) C8x processors. Even the powerful multiple DSP like TI C8x (5 DSP cores in a chip with 2000 MIPS power at the cost of US $1,000/ea) cannot handle one channel of MPEG-2 processing. If two C80xs or eight C6xs are used to serve one camera, the total cost is too high, considering that 200 or more cameras must be served, and the system will be too large to be practically implemented. Even though the processing power of seven C6x DSPs is sufficient to handle one MPEG2 compression and decompression, it takes ⅔ (22.4 ms) of the processing time to transmit a frame of raw data (640×480 color) to co-processors for parallel computing. It is impractical to do so for a 30 fps (33.33 ms/frame) real time video application, and thus represents a system bottleneck.  
           [0008]    The technical challenge for such a system includes (1) handling massive video capturing and compression tasks, (2) handling a huge amount of raw data traffic from multiple video cameras to multiple image processors, and (3) producing a compressed code stream significantly smaller than the traffic of 200 MPEG-2 code streams.  
           [0009]    Conventional multi-viewpoint image and video capturing/coding techniques follow a model-based approach. The basic idea behind these techniques is that, by utilizing the visual information acquired from a plurality of cameras, a 3-D model can be established. The transmission of the data relating to the 3D model, as opposed to transmitting the data relating to the actual object or scene, is a manageable amount. A typical procedure in the model-based approach includes the steps of (1) acquiring multi-viewpoint raw video data; (2) analyzing the raw video data to establish a 3-D shape description of the scene or of the objects in the scene; (3) encoding the 3-D model and associated descriptions (e.g., texture) into a compact form.  
           [0010]    Some 3D camera products have been commercialized. These cameras detect the depth information relating to the object being shot via an active-radar-like process, and return 3-D shape information about the object. Since they can record the visible surface from only one viewpoint, several such cameras are needed from different viewpoints to establish a complete description. A multi-viewpoint variation of these 3-D cameras is 3-D scanner. In general, a 3-D scanner is not suitable for capturing dynamic events, in which the visual world is in motion even while the image capturing is taking place.  
           [0011]    The 3D Dome Project (see A Multi-Camera Method for 3D Digitization of Dynamic, Real-World Events, P. Rander doctoral dissertation, tech. report CMU-RI-TR-98-12, Robotics Institute, Carnegie Mellon University, May, 1998. referred to hereinafter as the dome project article) of the Robotics Institute of Carnegie Mellon University is perhaps the first integration of synchronized cameras at multiple viewpoints. It is a typical model-based method, where the 3D shape and appearance over time need to be estimated. In particular, the 3D digitization method in the dome project article decomposes the 3D shape recovery task into the estimation of a visible structure in each video frame followed by the integration of the visible structure into a complete 3D model. Then, this estimated 3D structure is used to guide the color and texture digitization in the original video images. The 3D dome itself consists of a synchronized collection of 51 calibrated video cameras mounted on a geodesic dome 5 m in diameter. This 3D Dome design has an inherent difficulty in performing integrated, on the fly, real-time capturing and coding due to the large amount of data and the complexity of the model computation task.  
           [0012]    In another work (see “Acquiring 3D Models of Non-Rigid Moving Objects From Time and Viewpoint Varying Image Sequences: A Step Toward Left Ventricle Recovery”, Y. Sato, M. Moriyama, M. Hanayama, H. Naito, and S. Tamura, IEEE Transactions on Pattern Analysis and Machine Intelligence, Vol. 19, No. 3, March 1997.), Y. Sato et al described a method for the accurate recovery of time-varying 3D shapes with a known cycle from images with different viewpoints as well as times. This is also a model-based approach, aiming at the recovery of the left ventricular shapes.  
           [0013]    U.S. Pat. No. 5,850,352 (issued Dec. 15, 1998, to Moezzi et al.) describes an immersion video system. This is also a model-based approach. It includes a “hypermosaicing” process to generate, from multiple video views of a scene, a three-dimensional video mosaic. In this process, a knowledge database is involved which contains information about the scene such as scene geometry, shapes and behaviors of objects in the scene, and internal/external camera calibration models. For video capturing, multiple video cameras are used, each at a different spatial location to produce multiple two-dimensional video images of the scene. Due to the high complexity of the  3 -dimensional scene model computation, this method is unlikely to be capable of producing a real-time code stream construction integrated with the capturing task.  
           [0014]    U.S. Pat. No. 5,617,334 (issued Apr. 1, 1997 to Tseng et al.) describes a method for multi-viewpoint digital video coding and decoding. This method describes a hybrid model-based and MPEG-like compression scheme. The encoder comprises a depth estimator which combines the information from a few video channels to form a depth map of the scene or of the object. The depth map itself is to be encoded and sent to the decoder. The encoded information also includes MPEG-2 coded prediction errors. This method deals with the case in which there is only 1 primary viewpoint and a few (four in the description) dependent viewpoints, and does not provide a solution for situations with a massive number (hundreds) of viewpoints. Besides, since the processing speed is not a main concern in that work, no parallel and distributed processing scheme is described.  
           [0015]    There are several drawbacks to the model-based approach. First, extracting a 3D model from multi-viewpoint images is not guaranteed always to be successful and accurate, and is normally very time-consuming. It is not suitable for large-scale, real-time, processing. Second, displaying a recovered 3D model with the associated texture mapped on it will not always reconstruct the original object precisely. In particular, the visual differences between the picture taken directly from the camera and the picture rendered from the graphics model will often be great.  
         SUMMARY OF THE INVENTION  
         [0016]    One of the objects of this invention is to provide a method and system in no 3D model needs to be extracted. According to the invention, the pictures taken will be compressed without attempting to understand the geometry structure of the object. With the observation that pictures taken from two close viewpoints will be similar for most of the cases, this spatial redundancy will be exploited in the inventive video compression algorithm. This will eliminate both the uncertainty of 3D model extraction and the visual errors of rendering the images from a graphics model.  
           [0017]    In an apparatus employing the inventive method according to an embodiment of the invention, the apparatus includes a shell structure placed on a preferably flat platform, which isolates the space underneath the shell from the outside world. This shell can be constituted using such 3-D geometric shapes as sphere, dome, polyhedral, or cubic, and has a dome structure (hemisphere) in a specific embodiment. The platform can, but need not necessarily, be made rotatable by connecting it with a motor. The space underneath the hemisphere and above the platform is the visual world to be processed by this apparatus.  
           [0018]    Such an apparatus with integrated real-time digital video capturing and compression capability is referred to herein, for the sake of linguistic convenience, as an Integrated Digital Dome (IDD). The invention further relates to a method of parallel multi-viewpoint video capturing and compression (PMVCC) to support the operation of such an IDD. In an exemplary embodiment of PMVCC according to the invention, a Multi-DSP Array (MDA) architecture is employed, with hundreds of high-performance DSPs working in parallel to obtain a rate of computation of 300 GIPS at a commercially feasible cost. By means of MDA, the real time video data are compressed on the fly by the IDD. Multi-viewpoint compressed data are sent to a host system (a video server or a personal computer) in a proprietary format for future processing. Such processing is described in the Subject Video Streaming application.  
           [0019]    The PMVCC algorithm according to the invention provides for parallelism. In this algorithm, only about 15% of the viewpoints are to be dealt with by full MPEG2 compression, and the images of other viewpoints are coded in a highly compact form by utilizing the spatial similarity of these images with the base images.  
           [0020]    Other objects, advantages, and aspects of the invention will become apparent from the discussion below, taken in accordance with the included drawings. 
       
    
    
     BRIEF DESCRIPTION OF DRAWINGS  
       [0021]    [0021]FIG. 1 shows, in highly simplified form, a three layer structure relating to an embodiment of the invention.  
         [0022]    [0022]FIG. 2 graphically illustrates the determination of the location and number of viewpoints on the dome.  
         [0023]    [0023]FIG. 3 graphically illustrates a particular step in the determination of the location and number of viewpoints on the cover.  
         [0024]    [0024]FIG. 4 is an explanatory figure relating to the hardware calibration process.  
         [0025]    [0025]FIG. 5 is an explanatory figure illustrating the determination of a coordinate system.  
         [0026]    [0026]FIG. 6. graphically illustrates the calibration of the software.  
         [0027]    [0027]FIG. 7. shows different types of processing groups.  
         [0028]    [0028]FIG. 8 illustrates the logic relationships and physical positions among cameras and processors in a processing group.  
         [0029]    [0029]FIG. 9 is a simplified block diagram of the processing group shown in FIG. 8.  
         [0030]    [0030]FIG. 10 is a highly simplified schematic showing the logical interrelationships between components of an entire capture and compression system.  
         [0031]    [0031]FIG. 11 illustrates the syntactic structure of a coded bitstream.  
         [0032]    [0032]FIG. 12 illustrates coding task decomposition.  
         [0033]    [0033]FIG. 13 shows the modular design and data flow in a C-processor according to an embodiment of the invention.  
         [0034]    [0034]FIG. 14 shows the modular design and data flow in an S-processor according to an embodiment of the invention.  
         [0035]    [0035]FIG. 15 is a logic diagram relating to rotation and translation prediction.  
         [0036]    [0036]FIG. 16 shows, in high level natural language pseudocode, an I-frame coding algorithm according to an embodiment of the invention.  
         [0037]    [0037]FIG. 17 shows, in high level natural language pseudocode, a P-frame coding algorithm according to an embodiment of the invention.  
         [0038]    [0038]FIG. 18 illustrates a task pipeline structure for a program group in accordance with an embodiment of the invention.  
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0039]    Constructional Design of the Apparatus  
         [0040]    A description will now be provided for the sake of conveying a complete understanding of how best to practice and implement the invention. It will be appreciated, however, that the discussion will include numerous specificities which are not strictly necessary to the invention and may be varied or omitted. Some detail is omitted as necessary to avoid obscuring the invention. The scope and reach of the invention should be understood in conjunction with the appended claims.  
         [0041]    An apparatus according to the invention can be constituted in various shapes, and the method according to the invention does not favor any particular one of the shapes. From a practical point of view, many applications prefer an isotropic design such that the optical center from different viewpoints coincides at a common point, and that the picture-taking process at different viewpoints possesses the same focal length. Such a preference suggests a cover-like structure where the surface of the viewpoints forms a hemisphere or similar shape. Without loss of generality, the description herein will be based on such a dome-like structure throughout the rest of this document. It will be understood, however, that “dome” is used for linguistic convenience only and should be viewed as a term meaning any appropriate shape. The terms “cover” or “container” may also be used, and it will be understood that these terms are meant to have a meaning identical to that of “dome” as described above.  
         [0042]    The size of the cover is flexible. Typical embodiments include desktop dimensions with volumes large enough to contain objects like toys, tools, electronics, etc.; room dimensions capable of containing larger objects such as vehicles, furniture, animals, or human models; stadium dimensions capable of hosting mass gathering such as sports or entertainment activities.  
         [0043]    In a particular embodiment, the cover is defined to have three functional layers: an inner layer (In), an intermediate layer (Im), and an exterior layer (Ex).  
         [0044]    The function of the In-layer is to provide the background and illumination for the visual world. The illumination design and material used for the In-layer are not specified in this invention, but should fulfill the requirement that the peeking is one-way available only from outside to inside of the cover. In other words, the outside world is invisible for a viewer inside the cover, but the outside viewer is able to peek and view the scene inside.  
         [0045]    The Im-layer contains a plurality of video sensors for capturing the digital video data. In an embodiment, more than 200 CCD cameras are placed centripetally on the Im-layer. Their locations are determined following a certain mosaic structure. These video cameras acquire real-time visual pictures from multiple viewpoints at the rate of 20-30 fps. The captured digital video data are real-time compressed by a plurality of digital signal processors through a method as described below.  
         [0046]    The Ex-layer provides the physical frame and wiring for inter-connection between the cover and other equipment. A subsystem module is included in the Ex-layer that transmits the captured video data to mass storage equipments or computing processors for further processing.  
         [0047]    [0047]FIG. 1 illustrates the three-layer structure of the IDD. In an embodiment, the diameter of the cover is around three meters.  
         [0048]    Determining Viewpoints  
         [0049]    A plurality of CCD cameras is placed in the Im-layer, with the camera head pointing towards inside of the IDD. Each camera represents a viewpoint of observation.  
         [0050]    The invention has no favored preference on the numbers and locations of the viewpoints on the cover. The invented method applies equally to various choices of camera number and viewpoint location. A typical configuration is latitude-longitude system with two sets of perpendicular geodesic lines and each viewpoint being defined at every cross point of the geodesic lines. In an embodiment, the location and number of viewpoints on the cover is determined as follows:  
         [0051]    Step 1. Divide the surface of cover into four equal parts (FIG. 2).  
         [0052]    1. Locate the North Pole of the cover.  
         [0053]    2. Dividing the equator into four equal segments. The four dividing points are denoted as D 0 , D 1 , D 2 , and D 3 .  
         [0054]    3. From each of the four dividing points, draw a shortest arc connecting to north pole. These four arcs divide the surface of cover into four equal parts (quarters).  
         [0055]    Step 2. For each quarter (without loss of generality, we consider the quarter of D 0 -D 1 ), do the following (FIG. 3):  
         [0056]    1. Define S to be a set of sphere triangles. Initialize S to contain the sphere triangle defined by vertices D 0 , D 1 , and the North Pole.  
         [0057]    2. For every sphere triangle in S do  
         [0058]    3. Find the middle point on every arc connecting a pair of vertices.  
         [0059]    4. Connect all these middle points using the shortest arc.  
         [0060]    5. Turn all middle points into new vertices. Delete all sphere triangles in S, and then fill S with all new sphere triangles.  
         [0061]    6. Repeat 2 and 3.  
         [0062]    In practice, Step 2.4 can be repeated an arbitrary number of times. After each repeat, each vertex on the cover represents a viewpoint. Therefore, the number of repititions determines the density of viewpoints. In an embodiment we require the Step 2.4 be repeated at least two times. Therefore, in that embodiment, the number of viewpoints on the cover is at least 146.  
         [0063]    Camera Calibration  
         [0064]    At each viewpoint there is a digital video camera (e.g., CCD or CMOS camera) pointing towards the inside of the cover. For every camera there are two operation modes: recording mode and calibration mode. The camera parameters are fixed during the recording mode but are adjustable during the calibration mode.  
         [0065]    There are two basic methods for camera calibration: hardware calibration and software calibration. The hardware calibration process assures that the optical center of all cameras coincidences with the same Center of Interest (without loss of generality let it be the center of the cover), as shown in FIG. 4. This process can be done manually or automatically, individually for every camera. The hardware calibration process also assures that all cameras have the same focal length which is adjusted such that the Center of Interest has the sharpest image on the image plane.  
         [0066]    The hardware calibration process further determines the X-Y coordinate system on the 2-D image plane (FIG. 5). In an embodiment the Center of Interest is coincident with the center of the cover. In this circumstance the image plane is coincident with the tangential plane of the cover at the viewpoint. The Y (vertical) axis is the projection of the line of longitude that passes this viewpoint onto the image plane, with the North being the positive direction. The X-axis is perpendicular to Y-axis on the image plane with East being the positive.  
         [0067]    In software calibration (FIG. 6), the basic idea is not to physically adjust the camera parameters to the standard values, but to record the difference between the camera parameter values before calibration and the standard values. These difference values are then compensated during the video coding process. In a preferred embodiment, we let the captured frame size be slightly larger than the encoding and display frame size ( 610 ), so that there is a margin in both the horizontal and vertical directions, respectively. For example, one may use a camera with 500×500 pixels resolution and define a 384×256 area in the center to be the actual frame to be encoded and displayed. When a cover is produced, the initial mechanical work on mounting the cameras at the viewpoints should meet such a precision that the maximum displacement of the optical center from the image of center of interest should not exceed the size of margin ( 620 ). The displacements in the vertical and horizontal directions are recorded during software calibration and are used in the encoding process.  
         [0068]    The software calibration further measures the angular difference between the Y-axis on the image plane and the standard Y direction which is the image plane projection of the longitude that passes the viewpoint ( 630 ).  
         [0069]    Video Capturing  
         [0070]    A central clock is used to control the synchronous picture taking from all viewpoints. The recording mode includes single-shot recording and continuous recording. In single-shot recording, only one image is taken simultaneously at each viewpoint. In continuous recording, a sequence of pictures is taken synchronously at each viewpoint. In continuous mode, the rate of the central clock determines the frame rate of the video.  
         [0071]    Captured digital video signal can be either in R-G-B format or Y-U-V format. In the former case, an extra step is needed to convert it into Y-U-V format, which is a standard process. U and V data are further down-sampled by a standard 4:1:1 or 4:2:0 format depending on the application, and are transferred to a plurality of digital signal processors (DSP) for coding.  
         [0072]    Processing Groups (PG)  
         [0073]    Video coding is performed using the processing group (PG) as a unit. The assignment of each viewpoint to an appropriate processing group and the number of viewpoints in a processing group are entirely up to the designer and can be flexible. In a preferred embodiment four types of PG are developed (FIG. 7):  
         [0074]    PG-5. This PG type has 5 cameras: a generally central camera (referred to generically as “control camera” or “C-camera”) and 4 surrounding cameras (S-cameras). This PG type is used at the North Pole viewpoint.  
         [0075]    PG-4. In this type of PG there are one C-camera and three S-cameras. This type of PG is used at viewpoints D 0 , D 1 , D 2 , and D 3 .  
         [0076]    PG-7. This type of PG contains a C-camera and six S-cameras.  
         [0077]    Irregular PG. This type of PG contains a C-camera and none or up to three S-cameras.  
         [0078]    This invention does not specify a scheme of using these PGs. However, it can been seen that with these four types of PG all the viewpoints on the cover can be exactly covered (no overlap or missing). The following description relates to the PG-7, but the same principle may be applied to any of the other types of PGs.  
         [0079]    The PG-7 in Detail  
         [0080]    Associated with every viewpoint there is a DSP processor. FIG. 8 illustrates the logic relationships and physical positions among the seven video cameras and DSP processors in a PG-7 group. The C-processor serves as a group master to control the whole compression process of the PG, including sub-task pipeline synchronization, bus control, data collection, and data distribution. It also undertakes 25% of coding sub-tasks. The S-processors are co-processors each of which takes 12.5% of coding sub-tasks.  
         [0081]    [0081]FIG. 9 is the block diagram of a processing group PG-7 corresponding to FIG. 8. A bus controller ( 980 ) is added to improve bus-driving ability and synchronization with other PGs. Raw digital data (in Y-U-V format) from the C-camera is distributed to all seven DSP processors for coding ( 910 ). In contrast, raw digital data from each S-camera is sent to the corresponding S-DSP processor only ( 920 ). During the coding process, mutual data exchange is required among the processors ( 930 ). Encoded data are placed on the sub-system data bus ( 940 ) to be sent to the host system.  
         [0082]    [0082]FIG. 10 is a logic diagram of the entire PMVCC system organization. All the processing groups are connected with a system data bus and a system control bus that connect to the PCI Interface Card for outputting compressed video data to a host computer.  
         [0083]    [0083]FIG. 11 illustrates the syntactic structure of the coded bitstream produced by the cover. At the top level of syntax ( 1110 ), the bitstream contains a file header followed by code streams of all PGs. There is no particular preference for the order of PGs, but in an embodiment we put the North PG first, and then the PGs at viewpoints D 0 , D 1 , D 2 , and D 3 . The file header contains generic information such as the frame size, frame rate, and so on. A PG code stream comprises the PG header and the PG data body ( 1120 ). The PG header ( 1130 ) specifies the type of PG (whether it is PG-3, PG-4, PG-7, or other types), the C-Camera ID, and coding parameters such as the color format being used, what kind of coding scheme is used for this PG, and so on. Note that different PGs of the same cover may be coded using different schemes, e.g., one using DCT coding and another using sub-band coding. It will be appreciated that in there is no regulation on how to assign the C-camera ID.  
         [0084]    Each PG code stream contains a sequence of GOPs (group of pictures) ( 1140 ), similar to the MPEG family. A GOP contains a leading I-frame (independent frame) followed by a sequence of P-frames (predicted frame) or B-frames (bi-directional frame) ( 1150 ). In the rest of this document an embodiment with only I and P frames is described but the principle completely covers the situation with B frame. Both I and P frames possess the same bitstream structure, that is, a C-Camera code stream followed by up to six S-camera code streams ( 1160 ). Again, no restriction is required on the order of those S-camera code streams, and any convention may be employed.  
         [0085]    [0085]FIG. 12 illustrates the coding task decomposition in this PMVCC method. The entire video frame is divided into eight equal-sized tiles ( 1210 ). Each S-processor is responsible for the coding of one tile, and the C-processor deals with two tiles. There is no restriction on which tile is assigned to which processor. When coding an I-frame, only the exact tile is to be fed to a processor ( 1220 ). However, when coding a P-frame, the tile and a portion of the surrounding margin are to be transmitted to a processor in order to perform motion estimation. The size of the margin is determined by the size of the search window in a motion estimation algorithm (see below for details).  
         [0086]    C-Processor  
         [0087]    [0087]FIG. 13 shows the algorithm modular design and data flow in a C-processor. The C-processor receives raw data input from the C-camera only. In the case of I-frame coding, the exact two tiles chosen out of eight tiles from the entire video frame are input to a frame buffer ( 1310 ). In the case of P-frame coding, the two tiles chosen plus margins ( 1230 ) required for motion estimation are input to the frame buffer ( 1310 ). If the current frame is to be encoded as an I-frame, a suitable I-frame encoding scheme is called ( 1320 ). Here, “suitable I-frame coding scheme” refers to a standard JPEG-like coding scheme as used in the MPEG family for independent frame coding, or can be any proprietary coder that encodes a still image frame. The encoded I-frame data is put on the subsystem bus ( 1330 ) for output to the host system. Then a suitable I-frame decoder (an inverse process of the encoding) decodes the compressed data ( 1340 ). The decompressed data is sent to a frame buffer ( 1350 ) as a reference for coding a new P-frame. This frame buffer also receives decompressed data ( 1360 ) of other tiles from those S-processors in the same PG, to form a complete reconstructed frame. The decompressed data is also put on the subsystem bus ( 1370 ) for exchange with the S-processors within the same PG.  
         [0088]    If the current frame is to be coded as a P-frame, the two tiles plus margins are fed to a suitable P-frame encoding scheme ( 1380 ). Here, a “suitable P-frame encoding scheme” refers to a standard MPEG-like P-frame coding scheme but without the feedback loop, or can be any proprietary P-frame coding routine without the feedback loop. The encoded P-frame data is put on the subsystem bus ( 1330 ) for output to the host system. Then a suitable P-frame decoder (an inverse process of the encoding) decodes the compressed data ( 1390 ). The decompressed data is sent to a frame buffer ( 1350 ) as a reference for coding the next P-frame. This frame buffer ( 1350 ) also receives decompressed data of other tiles from those S-processors in the same PG, to form a complete reconstructed frame. The decompressed data is also put on the subsystem bus ( 1370 ) for exchange with other processors within the same PG.  
         [0089]    S-Processor  
         [0090]    [0090]FIG. 14 shows the algorithmic modules and data flow in an S-processor. The S-processor receives raw data input from both its corresponding S-camera and the C-camera in the same PG. The description for modules  1410 ,  1411 ,  1412 ,  1413 ,  1414 , and  1415  is the same as in the C-processor, except that only one tile instead of two is processed in this case.  
         [0091]    The S-processor receives raw data from the S-camera at the same time instant that the C-camera raw data comes in. While the C-camera input is being processed, the S-camera data is buffered in a full size buffer ( 1420 ). Right when the reconstructed C-camera data is ready at  1415 , a rotation and translation predictor ( 1440 ) is applied so as to form a prediction for the S-camera data in  1420 . This prediction is done by rotating and translating the C-camera data according to the relationship between the S-camera image and the C-camera image as described by the camera parameters ( 1450 ). Essentially, the camera parameters include the viewpoint location of the S-camera, the X-Y coordinate system on the image plane, and in the case of software calibration, the displacement information. This set of information is acquired during camera calibration and is pre-loaded into the S-processor. The predicted S-camera image is compared with the actual S-camera image through a pixel-to-pixel difference ( 1460 ). The differences are finally encoded by a residual coding scheme ( 1470 ) to form a final code for S-camera image, which is placed on the subsystem bus for output to the host system. The residual coding scheme can be any type of still-image coding scheme, such as JPEG or sub-band coding.  
         [0092]    [0092]FIG. 15 illustrates a logic diagram of rotation and translation prediction used in ( 1440 ). It contains two steps. First, a linear transform matrix M is determined that brings the C-camera coordinate system to the S-camera coordinate system. If software camera calibration is used, then this matrix M should also consider the influence of the displacements of the two coordinate systems from their respective standard coordinates on the transform. The second step is to apply the matrix M to the reconstructed C-camera image to make a prediction for the S-camera image. The related mathematics is quite standard and the detail is omitted here so as not to obscure the invention.  
         [0093]    PMVCC I-Frame Coding Algorithm  
         [0094]    A complete description of an I-frame coding algorithm in PMVCC is given in FIG. 16. In this algorithm, seven DSP processors (one C-processor and six S-processors) work in parallel, producing a much faster encoding power than MPEG-like coding schemes. In this algorithm, “suitable still-image coding scheme” can be a standard JPEG-like coding scheme or any proprietary still-image coding scheme.  
         [0095]    PMVCC P-Frame Coding Algorithm  
         [0096]    [0096]FIG. 17 gives the P-frame coding algorithm in PMVCC. This is also a parallel encoding scheme among seven DSP processors. The process is similar to the PMVCC I-frame coding algorithm, except that at Step 1.2 an MPEG-like P-frame coding scheme is used instead of a JPEG-like scheme. It should be noted that, when the raw data from C-processor is split and sent to the seven processors, the relevant margins for motion estimation (refer to FIG. 12) are also sent.  
         [0097]    Task Pipeline  
         [0098]    The two PMVCC parallel algorithms (I-frame and P-frame) can be effectively pipelined. FIG. 18 illustrates an exemplary task pipeline structure of PG-7. It is a true MIMD array processor architecture. The basic specification of the pipeline is also listed in the figure.  
         [0099]    It will be apparent to those skilled in the art that various modifications can be made to this PMVCC algorithm and the related architecture of the instant invention without departing from the scope or spirit of the invention, and it is intended that the present invention cover modifications and variations of the PMVCC algorithm and related architecture provided they come in the scope of the appended claims and their equivalents. Furthermore, it will be appreciated that the many specificities provided herein are for the sake of explanation only, and not intended to limit the scope and reach of the invention.