Table-based color conversion to different RGB16 formats

Image data in an initial color format (e.g., subsampled YUV9 data) is color converted to a selected RGB16 color format by executing compiled computer program code. The same compiled computer program code can be used to convert the image data in the initial color format into image data in any of two or more different RGB16 formats. In a preferred embodiment, lookup tables (configurable during run-time processing) are used to make the color conversion processing more efficient. The selected RGB16 color format can be changed during run-time processing, in which case certain lookup tables are reinitialized for the newly selected RGB16 format.

BACKGROUND OF THE INVENTION 
1. Field of the Invention 
The present invention relates to computer-based image processing, and, in 
particular, to converting image data from one color format to another 
color format. 
2. Description of the Related Art 
Many computer-based video processing systems encode video data to reduce 
the number of bits used to represent sequences of video images for more 
efficient storage and/or transmission. It has been found that converting 
the video data to a three-component YUV color format can improve the 
degree of compression attainable for a given sequence of video images. 
Nevertheless, most computer display subsystems rely on image data being in 
a three-component RGB color format. An integrated computer system that 
decodes encoded YUV image data for display on an RGB-based display 
subsystem typically converts the decoded YUV image data to displayable RGB 
image data. 
The present invention is directed to an efficient procedure for converting 
image data from an initial color format, such as a YUV format, into image 
data in an RGB color format. 
Further objects and advantages of this invention will become apparent from 
the detailed description of a preferred embodiment which follows. 
SUMMARY OF THE INVENTION 
The present invention is directed to the color conversion of image data. 
According to a preferred embodiment, image data is provided in an initial 
color format. Compiled computer program code is executed to convert the 
image data in the initial color format into image data in one of two or 
more different RGB16 formats, wherein the same compiled computer program 
code can be used to convert the image data in the initial color format 
into image data in any of the two or more different RGB16 formats.

DESCRIPTION OF THE PREFERRED EMBODIMENT(S) 
The present invention is directed to an efficient method for converting 
image data from an initial color format (e.g., subsampled YUV9 data) into 
a selected RGB16 color format. In a preferred embodiment, the color 
conversion is implemented by executing compiled computer program code that 
accesses lookup tables. The lookup tables, which are configurable during 
run-time processing, are designed for the selected RGB16 color format. The 
same compiled computer program code can be executed for any of the 
different supported RGB16 color formats with only certain of the lookup 
tables being reinitialized when the selection of color format is changed 
during run-time processing. 
System Hardware Architectures 
Referring now to FIG. 1, there is shown a block diagram of computer system 
100 for encoding video signals, according to a preferred embodiment of the 
present invention. Analog-to-digital (A/D) converter 102 of encoding 
system 100 receives analog video signals from a video source. The video 
source may be any suitable source of analog video signals such as a video 
camera or VCR for generating local analog video signals or a video cable 
or antenna for receiving analog video signals from a remote source. A/D 
converter 102 separates the analog video signal into constituent 
components and digitizes the analog components into digital video 
component data (e.g., in one embodiment, 24-bit RGB component data). 
Capture processor 104 captures the digital 3-component video data received 
from converter 102. Capturing may include one or more of color conversion 
(e.g., RGB to YUV), scaling, and subsampling. Each captured video frame is 
represented by a set of three two-dimensional component planes, one for 
each component of the digital video data. In one embodiment, capture 
processor 104 captures video data in a YUV9 (i.e., YUV 4:1:1) format, in 
which every (4.times.4) block of pixels of the Y-component plane 
corresponds to a single pixel in the U-component plane and a single pixel 
in the V-component plane. Capture processor 104 selectively stores the 
captured data to memory device 112 and/or mass storage device 120 via 
system bus 114. Those skilled in the art will understand that, for 
real-time encoding, the captured data are preferably stored to memory 
device 112, while for non-real-time encoding, the captured data are 
preferably stored to mass storage device 120. For non-real-time encoding, 
the captured data will subsequently be retrieved from mass storage device 
120 and stored in memory device 112 for encode processing by host 
processor 116. 
During encoding, host processor 116 reads the captured bitmaps from memory 
device 112 via high-speed memory interface 110 and generates an encoded 
video bitstream that represents the captured video data. Depending upon 
the particular encoding scheme implemented, host processor 116 applies a 
sequence of compression steps to reduce the amount of data used to 
represent the information in the video images. The resulting encoded video 
bitstream is then stored to memory device 112 via memory interface 110. 
Host processor 116 may copy the encoded video bitstream to mass storage 
device 120 for future playback and/or transmit the encoded video bitstream 
to transmitter 118 for real-time transmission to a remote receiver (not 
shown in FIG. 1). 
Referring now to FIG. 2, there is shown a block diagram of computer system 
200 for decoding the encoded video bitstream generated by encoding system 
100 of FIG. 1, according to a preferred embodiment of the present 
invention. The encoded video bitstream is either read from mass storage 
device 212 of decoding system 200 or received by receiver 210 from a 
remote transmitter, such as transmitter 118 of FIG. 1. The encoded video 
bitstream is stored to memory device 214 via system bus 206. 
Host processor 208 accesses the encoded video bitstream stored in memory 
device 214 via high-speed memory interface 216 and decodes the encoded 
video bitstream for display. Decoding the encoded video bitstream involves 
undoing the compression processing implemented by encoding system 100 of 
FIG. 1. Host processor 208 stores the resulting decoded video data to 
memory device 214 via memory interface 216 from where the decoded video 
data are transmitted to display processor 202 via system bus 206. 
Alternatively, host processor 208 transmits the decoded video data 
directly to display processor 202 via system bus 206. Display processor 
202 processes the decoded video data for display on monitor 204. The 
processing of display processor 202 includes digital-to-analog conversion 
of the decoded video data. After being decoded by host processor 208 but 
before being D/A converted by display processor 202, the decoded video 
data may be upsampled (e.g., from YUV9 to YUV24), scaled, and/or color 
converted (e.g., from YUV24 to RGB16). Depending upon the particular 
embodiment, each of these processing steps may be implemented by either 
host processor 208 or display processor 202. In a preferred embodiment, 
the video data is converted from subsampled YUV9 data directly to an RGB16 
color format, as described in the next section of this specification. The 
video data may be further processed in the RGB16 color format (e.g., 
combined with graphics or other video data and/or further converted to a 
color lookup table (CLUT) format) before being converted to the RGB24 
color format for display. 
Referring again to FIG. 1, encoding system 100 is preferably a 
microprocessor-based personal computer (PC) system with a special purpose 
video-processing plug-in board. In particular, A/D converter 102 may be 
any suitable means for decoding and digitizing analog video signals. 
Capture processor 104 may be any suitable processor for capturing digital 
video component data as subsampled frames. In a preferred embodiment, A/D 
converter 102 and capture processor 104 are contained in a single plug-in 
board capable of being added to a microprocessor-based PC system. 
Host processor 116 may be any suitable means for controlling the operations 
of the special-purpose video processing board and for performing video 
encoding. Host processor 116 is preferably a general-purpose 
microprocessor manufactured by Intel Corporation, such as an i486.TM., 
Pentium.RTM., or Pentium.RTM. Pro processor. System bus 114 may be any 
suitable digital signal transfer device and is preferably a peripheral 
component interconnect (PCI) bus. Memory device 112 may be any suitable 
computer memory device and is preferably one or more dynamic random access 
memory (DRAM) devices. High-speed memory interface 110 may be any suitable 
means for interfacing between memory device 112 and host processor 116. 
Mass storage device 120 may be any suitable means for storing digital data 
and is preferably a computer hard drive. Transmitter 118 may be any 
suitable means for transmitting digital data to a remote receiver. Those 
skilled in the art will understand that the encoded video bitstream may be 
transmitted using any suitable means of transmission such as telephone 
line, RF antenna, local area network, or wide area network. 
Referring again to FIG. 2, decoding system 200 is preferably a 
microprocessor-based PC system similar to the basic PC system of encoding 
system 100. In particular, host processor 208 may be any suitable means 
for decoding an encoded video bitstream and is preferably a general 
purpose microprocessor manufactured by Intel Corporation, such as an 
i486.TM., Pentium.RTM., or Pentium.RTM. Pro processor. System bus 206 may 
be any suitable digital data transfer device and is preferably a PCI bus. 
Mass storage device 212 may be any suitable means for storing digital data 
and is preferably a CD-ROM device or a hard drive. Receiver 210 may be any 
suitable means for receiving the digital data transmitted by transmitter 
118 of encoding system 100. Display processor 202 and monitor 204 may be 
any suitable devices for processing and displaying video images (including 
the conversion of digital video data to analog video signals) and are 
preferably parts of a PC-based display system having a PCI graphics board 
and a 24-bit RGB monitor. 
In a preferred embodiment, encoding system 100 of FIG. 1 and decoding 
system 200 of FIG. 2 are two distinct computer systems. In an alternative 
preferred embodiment of the present invention, a single computer system 
comprising all of the different components of systems 100 and 200 may be 
used to encode and decode video images. Those skilled in the art will 
understand that such a combined system may be used to display decoded 
video images in real-time to monitor the capture and encoding of video 
stream. 
In alternative embodiments of present invention, the video encode 
processing of an encoding system and/or the video decode processing of a 
decoding system may be assisted by a pixel processor or other suitable 
component(s) to off-load processing from the host processor by performing 
computationally intensive operations. 
Color Conversion 
In a preferred embodiment of the present invention, host processor 208 of 
decoding system 200 of FIG. 1 generates (as part of the video decoding 
process) image data in a subsampled YUV9 color format and converts that 
image data to a specified RGB16 color format. Those skilled in the art 
understand that there are several different standard RGB16 color formats. 
Standard RGB16 formats include RGB555, RGB565, RGB664, and RGB655 formats. 
The present invention also supports other (possibly non-standard) RGB16 
color formats, including RGB556, RGB646, and RGB466 formats. 
In general, the nomenclature "RGBxyz" refers to a color format in which 
each pixel is represented by a computer data word (i.e., two 8-bit bytes 
of data) consisting of x bits of red component (R), y bits of green 
component (G), and z bits of blue component (B). For example, each pixel 
of image data in the RGB565 color format may be represented by the 
following two-byte word pattern: 
EQU RGB565=(r1 r2 r3 r4 r5 g1 g2 g3 g4 g5 g6 b1 b2 b3 b4 b5) (1) 
where the 5 R-component bits appear as the most significant bits (MSBs) of 
the upper byte of the 16-bit word, the 6 G-component bits are split evenly 
between the least significant bits (LSBs) of the upper byte and the MSBs 
of the lower byte, and the 5 B-component bits appear as the LSBs of the 
lower byte. 
This is different, for example, from the two-byte word pattern for image 
data in the RGB664 color format, which may be represented as follows: 
EQU RGB664=(r1 r2 r3 r4 r5 r6 g1 g2 g3 g4 g5 g6 b1 b2 b3 b4) (2) 
and both are different from the two-byte word pattern for image data in the 
RGB555 format, which may be represented as follows: 
EQU RGB555=(.alpha.r1 r2 r3 r4 r5 g1 g2 g3 g4 g5 b1 b2 b3 b4 b5)(3) 
The RGB555 format has an extra bit (.alpha. in Equation (3)) that may be 
left unused or used, for example, as an alpha-channel transparency bit for 
applications such as chromakeying. 
In general, the conversion of image data from YUV color space to RGB color 
space may be represented by the following matrix Equation (4): 
##EQU1## 
where: 
##EQU2## 
Since b and i have negligible impact to the calculation, they can be 
treated as zero. This YUV-to-RGB color transformation can then be 
approximated by Equations (6)-(8) as follows: 
EQU R=j*(Y+k*V) (6) 
EQU G=j*(Y+l*U+m*V) (7) 
EQU B=j*(Y+n*U) (8) 
where: 
EQU j=a=d=g=1.164 (9) 
EQU k=c/j=1.371 (10) 
EQU l=e/j=-0.336 (11) 
EQU m=f/j=-0.698 (12) 
EQU n=h/j=1.733 (13) 
According to a preferred embodiment, an intermediate contribution from the 
V component to the R component is labeled "RV" and corresponds to the 
product of k and V in Equation (6). Similarly, an intermediate 
contribution from the U component to the G component is labeled "GU", and 
corresponds to the product of l and U in Equation (7), an intermediate 
contribution from the V component to the G component is labeled "GV" and 
corresponds to the product of m and V in Equation (7); and an intermediate 
contribution from the U component to the B component is labeled "BU" and 
corresponds to the product of n and U in Equation (8). 
In a preferred embodiment of the present invention, the intermediate 
contributions RV, GU, GV, and BU are generated using lookup tables 
(labeled Table.sub.-- kV, Table.sub.-- lU, Table.sub.-- mV, and 
Table.sub.-- nU, respectively) that map the U or V component to the 
appropriate product. That is, for example, accessing Table-kV using the V 
component as a table index yields a table entry RV corresponding to the 
product of k and V. The four intermediate contributions RV, GU, GV, and BU 
may be represented by Equations (14)-(17) as follows: 
EQU RV=Table.sub.-- kVV! (14) 
EQU GU=Table.sub.--lUU! (15) 
EQU GV=Table.sub.-- mVV! (16) 
EQU BU=Table.sub.-- nUU! (17) 
Those skilled in the art will understand that these table lookups are used 
to increase the speed of processing over other procedures that perform the 
relatively slow multiplications during run-time processing. 
These intermediate contributions RV, GU, GV, and BU are then used to 
generate indices for a second stage of lookup tables that map to the final 
R, G, and B components. These table lookups may be represented as 
Equations (18)-(20) as follows: 
EQU R=RtableY+RV+d.sub.r ! (18) 
EQU G=GtableY+GU+GV+d.sub.g ! (19) 
EQU B=BtableY+BU+d.sub.b ! (20) 
where Y is the pixel Y component; d.sub.r, d.sub.g, and d.sub.b are dither 
contributions; and Rtable, Gtable, and Btable are lookup tables that map 
from the indices shown in brackets in Equations (18)-(20) to the R, G, and 
B components, respectively. The lookup tables Rtable, Gtable, and Btable 
map each index to the product of j and the index as shown in Equations 
(6)-(8), respectively. Those skilled in the art will understand that 
dither contributions are used to decrease contouring in the decoded 
images. 
In order to generate RGB16 data in the appropriate format, the lookup 
tables Rtable, Gtable, and Btable are designed such that their table 
entries are appropriately spaced for efficient combination into the 
appropriate two-byte word format of the selected RGB16 color format. For 
example, when RGB664 is the selected RGB16 color format, the lookup tables 
return 8-bit byte data for the RGB664 components R.sub.664, G.sub.664, and 
B.sub.664 according to the following bit patterns: 
EQU R.sub.664 =Rtable.sub.-- 664Index!=(r1 r2 r3 r4 r5 r6 0 0)(21) 
EQU G.sub.664 =Gtable.sub.-- 664Index!=(0 0 g1 g2 g3 g4 g5 g6)(22) 
EQU B.sub.664 =Btable.sub.-- 664Index!=(0 0 0 0 b1 b2 b3 b4) (23) 
In order to combine these components into the two-byte word format for the 
RGB664 format of Equation (2), the RGB components may be manipulated by 
executing compiled computer program code corresponding to the following 
pseudocode: 
______________________________________ 
Store G component into lower byte of empty two-byte 
// Step (a) 
register. 
Shift two-byte register four bits left. 
// Step (b) 
OR R component into upper byte of two-byte register. 
// Step (c) 
OR B component into lower byte of two-byte register. 
// Step (d) 
______________________________________ 
For RGB664 data, the status of the two-byte register after each of steps 
(a) through (d) is shown as follows: 
__________________________________________________________________________ 
Step (a): 
( 0 0 0 0 0 0 0 0 0 0 g1 
g2 
g3 
g4 
g5 
g6 
) 
Step (b): 
( 0 0 0 0 0 0 g1 
g2 
g3 
g4 
g5 
g6 
0 0 0 0 ) 
Step (c): 
( r1 
r2 
r3 
r4 
r5 
r6 
g1 
g2 
g3 
g4 
g5 
g6 
0 0 0 0 ) 
Step (d): 
( r1 
r2 
r3 
r4 
r5 
r6 
g1 
g2 
g3 
g4 
g5 
g6 
b1 
b2 
b3 
b4 
) 
__________________________________________________________________________ 
When RGB565 is the selected RGB16 color format, a different set of lookup 
tables is preferably used which return 8-bit byte data for the RGB565 
components R.sub.565, G.sub.565, and B.sub.565 according to the following 
bit patterns: 
EQU R.sub.565 =Rtable.sub.-- 565Index!=(r1 r2 r3 r4 r5 0 0 0) (24) 
EQU G.sub.565 =Gtable.sub.-- 565Index!=(0 g1 g2 g3 g4 g5 g60) (25) 
EQU B.sub.565 =Btable.sub.-- 565Index!=(0 0 0 b1 b2 b3 b4 b5) (26) 
In order to combine these components into the two-byte word format for the 
RGB565 format of Equation (1), the RGB components may be manipulated by 
executing the exact same compiled computer program code as described 
earlier in steps (a) through (d) for the RGB664 case. For RGB565 data, the 
status of the two-byte register after each of steps (a) through (d) is 
shown as follows: 
__________________________________________________________________________ 
Step (a): 
( 0 0 0 0 0 0 0 0 0 g1 
g2 
g3 
g4 
g5 
g6 
0 ) 
Step (b): 
( 0 0 0 0 0 g1 
g2 
g3 
g4 
g5 
g6 
0 0 0 0 0 ) 
Step (c): 
( r1 
r2 
r3 
r4 
r5 
g1 
g2 
g3 
g4 
g5 
g6 
0 0 0 0 0 ) 
Step (d): 
( r1 
r2 
r3 
r4 
r5 
g1 
g2 
g3 
g4 
g5 
g6 
b1 
b2 
b3 
b4 
b5 
) 
__________________________________________________________________________ 
When RGB555 is the selected RGB16 color format, yet another set of lookup 
tables is preferably used which return 8-bit byte data for the RGB555 
components R.sub.555, G.sub.555, and B.sub.555 according to the following 
bit patterns: 
EQU R.sub.555 =Rtable.sub.-- 555Index!=(0 r1 r2 r3 r4 r5 0 0) (27) 
EQU G.sub.555 =Gtable.sub.-- 555Index!=(0 0 g1 g2 g3 g4 g5 0) (28) 
EQU B.sub.555 =Btable.sub.-- 555Index!=(0 0 0 b1 b2 b3 b4 b5) (29) 
As with the RGB565 case, in order to combine these components into the 
two-byte word format for the RGB555 format of Equation (3), the RGB 
components may be manipulated by executing the exact same compiled 
computer program code as described earlier in steps (a) through (d) for 
the RGB664 case. For RGB555 data, the status of the two-byte register 
after each of steps (a) through (d) is shown as follows: 
__________________________________________________________________________ 
Step (a): 
( 0 0 0 0 0 0 0 0 0 0 g1 
g2 
g3 
g4 
g5 
0 ) 
Step (b): 
( 0 0 0 0 0 g1 
g2 
g3 
g4 
g5 
0 0 0 0 0 0 ) 
Step (c): 
( r1 
r2 
r3 
r4 
r5 
g1 
g2 
g3 
g4 
g5 
0 0 0 0 0 0 ) 
Step (d): 
( r1 
r2 
r3 
r4 
r5 
g1 
g2 
g3 
g4 
g5 
b1 
b2 
b3 
b4 
b5 
0 ) 
__________________________________________________________________________ 
The LSB of the two-byte format for RGB555 is then available for use as an 
alpha channel. 
According to a preferred embodiment, the present invention is implemented 
in software running on a general-purpose processor. By designing a 
different set of lookup tables for each different supported RGB16 6 
format, the same compiled computer software code can be executed for any 
of the RGB16 formats. The only difference is the configuration of the 
lookup tables Rtable, Gtable, and Btable, which can be initialized during 
run-time processing once for each selection of a different RGB16 format. 
Moreover, the selection of RGB16 format can change during run-time 
processing without having to change the executable code; only the lookup 
tables need to be reconfigured. 
As such, the present invention provides a relatively short set-up time to 
switch from one RGB16 color format to the another RGB16 color format, as 
opposed to other implementations that would have to load a whole new 
executable code during run-time processing. The present invention also 
provides a smaller executable code than other implementations that 
explicitly support different RGB16 color formats, for example, with a case 
statement with explicit code for each different RGB16 color format. 
Referring now to FIG. 3, there is shown a flow diagram of the color 
conversion processing for a sequence of video images, according to a 
preferred embodiment of the present invention. According to this 
embodiment, image data is converted from the subsampled YUV9 color format 
to a specified RGB16 color format, where the specification of RGB16 color 
format can change from frame to frame. 
In particular, after one of the supported RGB16 color formats is selected 
at during run-time processing (step 302 of FIG. 3), the lookup tables 
Rtable, Gtable, and Btable are configured (i.e., initialized) based on 
that selection (step 304). One or more video frames are then converted 
from subsampled YUV9 color format to the selected RGB16 color format (step 
306). This color conversion of video frames continues until and if the 
selected RGB16 color format is to be changed (step 308), in which case 
processing returns to steps 302 and 304 to select a new RGB16 color format 
and reconfigure the lookup tables accordingly for color conversion of 
additional video frames into the newly selected RGB16 color format. 
Referring now to FIG. 4, there is shown a flow diagram of the color 
conversion processing for each video frame of subsampled YUV9 data (step 
306 of FIG. 3), according to a preferred embodiment of the present 
invention. The processing of FIG. 4 is designed to take advantage of the 
fact that there are one U component and one V component for every 
(4.times.4) block of Y components in YUV9 data. It does so by implementing 
certain operations outside of the loop that processes the 16 different Y 
components per block. 
In particular, if there is another set of YUV9 data in the frame to be 
converted (step 402 of FIG. 4), then the intermediate contributions from 
the U and V components to the R, G, and B components (i.e., RV, GU, GV, 
and BU) are generated once for the current (4.times.4) block of Y 
components, based on lookup table operations as shown in Equations 
(14)-(17) (step 404). 
As long as there is another Y component in the current (4.times.4) block 
(step 406), the next Y component and the corresponding dither 
contributions d.sub.r, d.sub.g, and d.sub.b are selected (step 408) and 
used along with the intermediate contributions RV, GU, GV and BU to 
generate the R, G, and B components based on lookup table operations as 
shown in Equations (18)-(20) (step 410). The resulting R, G, and B 
components are then combined into the appropriate two-byte word format 
using steps (a) through (d) as described earlier in this specification for 
the RGB664 case (step 412). 
In a preferred embodiment, the selection of the dither contributions 
d.sub.r, d.sub.g, and d.sub.b is based on three (4.times.4) dither 
matrices D.sub.R, D.sub.G, and D.sub.B defined according to Equations 
(30)-(32) as follows: 
##EQU3## 
In a preferred embodiment, the dither contributions are selected as those 
matrix elements corresponding to (i.e., having the same relative location 
as) the current Y component within the (4.times.4) block. 
Referring now to FIG. 5, there is shown a block diagram of host processor 
208 of decoding system 200 of FIG. 2, according to a preferred embodiment 
of the present invention. Video decoder 502 receives an encoded bitstream, 
decodes the bitstream, and generates decoded image data in a subsampled 
YUV9 color format. Color converter 504 color converts the YUV9 data into 
RGB16 data based on a selected RGB16 color format. In this embodiment of 
the present invention, video decoder 502 functions as the source of image 
data for color converter 504 to convert. In alternative embodiments, the 
source of image data for color conversion nay be other than a video 
decoder. For example, the source of image data for color conversion under 
the present invention may be a graphics data generator, a camera 
generating still images, or any other suitable source of image data that 
is to be color converted into an RGB16 color format. 
In embodiments of the present invention based on Equations (18)-(20), 
dithering is achieved by adding dither contributions to the indices for a 
single set of R, G, and B lookup tables (for a selected RGB16 color 
format). In alternative embodiments, two or more sets of R, G, and B 
lookup tables may be used (for a single selected RGB16 color format) to 
achieve dithering, where each set of R, G, and B tables has dithering 
built in to the lookup tables ahead of time. These latter embodiments tend 
to use more memory than the former embodiments (because they have more 
tables), but (depending on the processor) may provide faster 
implementation (because they don't rely on the addition of dither 
contributions to generate the table indices). 
The present invention was described in the context of color converting 
image data from subsamnpled YUV9 color format to a selected RGB16 color 
format. The present invention also covers input data in other color 
formats, including other subsampled YUV color formats (e.g., YUV12 or 
YUV16), full-sampled YUV color format (e.g., YUV24), and, in general, 
image data represented in other suitable three-component color spaces, 
such as YIQ and the like. 
Furthermore, the present invention was described in the context of color 
converting sequences of video frames. Those skilled in the art will 
understand that the present invention also covers situations in which 
images other than video frames are color converted, including for example 
one or more graphics and/or still images. 
The present invention can be embodied in the form of methods and 
apparatuses for practicing those methods. The present invention can also 
be embodied in the form of computer program code embodied in tangible 
media, such as floppy diskettes, CD-ROMs, hard drives, or any other 
computer-readable storage medium, wherein, when the computer program code 
is loaded into and executed by a computer, the computer becomes an 
apparatus for practicing the invention. The present invention can also be 
embodied in the form of computer program code, for example, whether stored 
in a storage medium, loaded into and/or executed by a computer, or 
transmitted over some transmission medium, such as over electrical wiring 
or cabling, through fiber optics, or via electromagnetic radiation, 
wherein, when the computer program code is loaded into and executed by a 
computer, the computer becomes an apparatus for practicing the invention. 
When implemented on a general-purpose microprocessor, the computer program 
code segments combine with the microprocessor to provide a unique device 
that operates analogous to specific logic circuits. 
It will be further understood that various changes in the details, 
materials, and arrangements of the parts which have been described and 
illustrated in order to explain the nature of this invention may be made 
by those skilled in the art without departing from the principle and scope 
of the invention as expressed in the following claims.