The OCTANE Personal Video option supports three native color spaces—RGB, YUV, and CCIR. The choice of color space is determined by the external equipment for video I/O connections, by the system for connections to the graphics subsystem, and by application software for transfers to and from system memory. Application software can avoid all color-space conversions during video I/O. The OCTANE Personal Video option can translate between YUV and RGB with high accuracy in real time.
Understanding the capabilities of the OCTANE Personal Video option to perform color-space conversions and the results of these conversions allows developers and end users to maximize the quality of their output. This appendix explains
The OCTANE Personal Video option uses a minimum of ten bits of precision for each color component at all steps of its internal pipeline. Representations for the three native internal color representations are explained separately in this section.
RGB is the color space used by the graphics subsystem; screen sources and drains and some memory transfers use this color space. RGB has the most accurate representation of visible colors, because all possible combinations are valid. This color space does not support superblack or other nonvisible color values. Each component is represented by a 10-bit value between 0 and 1023. Black has the value [0,0,0], and white is [1023,1023,1023].
When converting to RGB, each resulting RGB component is clamped to the range [0..1023]. It is possible to overflow the clamping mechanism when dramatically illegal colors are input. Overflows occur only when the resulting red, green, or blue value is greater than 2047 or less than -2048.
 | Note: Do not use 4:2:2 coding with RGB data. |
The YUV color space is obtained from RGB by the matrix transformation in equation 1.
 |
The V, Y, and U values range from [0..1023]. Black has the VYU value [512,0,512]. White has the value [512,1023,512].
This color space is used by the Betacam, M-II, and YUV formats. With proper filtering, 4:2:2 coding can be used.
The CCIR color space is obtained from RGB by the matrix transformation in equation 2.
 |
The Cr, Y, and Cb 10-bit values are clamped to the range [4..1019]. Black has the CrYCb value [512,64,512]. White has the value [512,940,512]. For 8 bits, the values are clamped to the range [1..254]; black has the CrYCb value [128,16,128], and white has the value [128,235,128].
This color space is used by the component digital formats. With proper filtering, 4:2:2 coding can be used.
The OCTANE Personal Video option can process and store each color space explained in the previous section. For best precision, the input color space should be maintained through the processing path. For example, an application that implements DDR functionality could choose to store data in the native representation of the input signal: Betacam data could be stored as YUV, input from an RGB camera as RGB, and data from a D1 deck as CCIR. If the application works in this way, no conversions are performed and the data is passed directly through the system. In particular, CCIR601 data coming from a D1 deck is bit-accurate in this case.
However, it might not be desirable for the application to work this way. If that is the case, the application can use all of the conversion, decimation and interpolation capabilities of the OCTANE Personal Video option to perform real-time color space and 4:2:2 ⇔ 4:4:4 conversions.
Conversions are performed only when absolutely required. Each incoming stream can be converted from its current color space to any other color space. Conversions can also be performed when going to graphics and digital video outputs.
The output color space controls conversions. For example, if you blend a CCIR stream from a digital video input with an RGB stream from graphics and send the result to the digital video output, the RGB signal is converted to CCIR before the blend occurs. The CCIR stream is not converted. If you sent the same blend to a Betacam output, both streams are converted to YUV before the blend.
The two major concerns when performing conversions from one color space to another are precision and range.
The OCTANE Personal Video option stores colors at all steps in its pipeline with a minimum of 10 bits of precision. When performing color-space conversions, the data is converted to 12-bit signed values before it is passed to the matrix multipliers. The matrix multipliers have 15-bit coefficients and 26-bit accumulators. The most significant 16 bits of the matrix-multiplication result are passed on to additional hardware, which applies any needed offsets and then clamps to the proper range.
Silicon Graphics, Inc., has verified both through simulation and hardware testing that the maximal error for two conversions (RGB to CCIR to RGB) is four units out of 1024. The matrix coefficients have been biased to round slightly high rather than slightly low to avoid the type of problems that can otherwise easily occur in the blue component.
Conversions between RGB and YUV are more accurate (a maximum error of 3 in 1024 after two conversions), since data is not as compressed in the YUV representation.
Different color spaces allocate the available bits of precision in different ways. The RGB space is designed to maximize the accuracy of color representations. The YUV and CCIR color spaces are designed to strongly uncouple chrominance and luminance information.
Since RGB represents visible colors, it is contained inside the YUV and CCIR spaces. The CCIR color space also has a slight amount of additional headroom that was intended to prevent aliasing artifacts when Finite Impulse Response filtering operations are performed on the digital data.
Whenever a conversion operation is performed between CCIR and RGB or between CCIR and YUV, the colors that are not representable in the destination color space must be somehow mapped into colors that are representable. The usual way to do this is to clamp each component to the available range in the destination color space. Other methods, such as projecting towards the center of the representable space, might produce results that appear to be better in some cases, but are not feasible to implement in hardware.
When converting from CCIR to YUV, the axes of the two spaces are parallel, so the result of this clamping operation is very predictable. Superblack and superwhite are clipped to black and white, respectively, and oversaturated colors might also be clipped.
When converting from RGB to YUV or CCIR, clamping never occurs, because all RGB colors are representable in those color spaces.
When converting from CCIR or YUV to RGB, the results of clamping are much less intuitive, because these conversions involve rotation and scaling operations, with the result that the component axes in one color space do not align with those in the other.
Figure D-1 shows the RGB color cube inside the CCIR color space. The volume contained within the outer (CCIR) cube, but outside the inner (RGB) cube, represents “illegal” colors that cannot be displayed.
As shown in the figure, the CCIR color space allocates almost three quarters of its available bit combinations to illegal colors. When any of these color values are converted to RGB, the result is clamped to the edge of the RGB cube. Since the inner cube contains the displayable colors, this clamping operation has no impact on them.
If CCIR is converted to RGB and back to CCIR using certain types of test signals, the output can appear to be vastly wrong. A common and extreme version of this is the signal that simultaneously ramps Cr, Y, and Cb from the minimum to maximum possible values.
In Figure D-2, the heavy diagonal line passing through the figure is the set of colors in the luma/chroma ramp test signal. As shown in the figure, a large portion of this pattern is outside the RGB cube. In fact, over two thirds of this pattern is outside the displayable range.
This section includes example graphs that display the results of converting from CCIR to RGB and back. They show the same type of result you would see if you brought a digital signal into the OCTANE Personal Video option, passed it through a memory node using RGB format, and sent it back out to the digital output.
These effects do not occur if you simply pass digital data through the OCTANE Personal Video board using the CCIR format. In these cases, the output matches the input on a bit-by-bit basis.
| Note: These examples show conversion from CCIR to full-range RGB, without use of the constant-hue algorithm. |
This example, like the other two in this section, consists of three graphs. Each graph displays the input CCIR pattern, intermediate RGB pattern, and output CCIR pattern for a given color component. Figure D-3 shows the red and Cr components, Figure D-4 the green and Y components, and Figure D-5 the blue and Cb components. In this example and the others, if the input and output CCIR values are identical, only two lines are shown.
In this example, conversion to RGB and back has no effect on the image. The 100% amplitude color bar signal lies within the visible range and therefore is perfectly represented in RGB.
In this example, the conversion to RGB and back affects only the superblack and superwhite regions. All luminance values that are blacker than black are clamped to black; all values whiter than white are clamped to white.
In the RGB color space, each component ramps from 0 to 1023 as the input luminance ramps from 64 (black) to 940 (white). This test pattern lies along the Y axis of the color cubes.
This example is the most extreme of the three, and shows how surprising the results of color conversions can be when arbitrary synthetic CCIR inputs are used.
Each CCIR input signal ramps from 0 to 1023 simultaneously. As mentioned in the first example, over two thirds of this pattern lies outside the legal range. The portion within the legal range is represented exactly, but the region outside is clamped to the RGB cube surface.
