Generally, you set color space with VL_COLORSPACE. VL_FORMAT values are provided for compatibility with existing applications. Table 3-3 shows the correspondence.

VL_FORMAT works in conjunction with VL_VIDEO node parameters to select the input connector on the OCTANE Personal Video option board. Applied to video source nodes, VL_FORMAT has five parameters, as summarized in Table 3-4.

---

Note: The O2Cam connector can be a digital input when an appropriate third-party serial digital converter is connected to it.

---

These control parameters must be used in conjunction with VL_VIDEO source node parameters to select the connector:

Table 3-5 summarizes how the VL_VIDEO source node parameters and the VL_FORMAT parameters work together.

To select a video input format, call vlGetNode() with the video source node number of interest. After setting up a path, set the VL_FORMAT control on that node to the appropriate value. For example, to select the composite video BNC, get a node by passing node number VL_EVO_NODE_NUMBER_VIDEO_3 to vlGetNode(), set up a path, and then set VL_FORMAT to VL_FORMAT_COMPOSITE, as illustrated in this example:

src_node = vlGetNode(svr, VL_SRC, VL_VIDEO,VL_EVO_NODE_NUMBER_VIDEO_3);
path = vlCreatePath(svr, dev, src_node, drain_node); 
vlSetupPaths(svr, (VLPathList)&path, 1, VL_SHARE, VL_SHARE); 
ctlVal.intVal = VL_FORMAT_COMPOSITE; 
vlSetControl(svr, path, src_node, VL_FORMAT, &ctlVal); 

Because there is only one VL_VIDEO drain node, it has no number parameters and drives all output connectors at once. Thus, it is not strictly necessary to set a VL_FORMAT value to select the output connector. However, Table 3-6 shows VL_FORMAT values for various connectors.

Applied to OCTANE Personal Video memory nodes, VL_ZOOM does not increase the size of an image, but decimates only. VL_ZOOM changes the x and y scale factors by the same amount. The effective scale size is determined by both VL_ZOOM and VL_ASPECT: the horizontal scale factor is VL_ZOOM * VL_ASPECT, and the vertical scale factor is VL_ZOOM. An example using VL_ASPECT is given later in this section.

Besides the setting of VL_ASPECT, scaling with VL_ZOOM depends on the capture type and the packing. Table 3-9 summarizes the minimum values achievable for VL_ZOOM applied to memory source and drain nodes; for these minimum values, you must also use VL_ASPECT.

VL_ZOOM takes a nonzero fraction as its argument; do not use negative values.

To correct the x scale, use VL_ASPECT. The following example sets the horizontal scale to 1/2 and the vertical scale to 1/1:

val.fractVal.numerator=1;
val.fractVal.denominator=1;
vlSetControl(svr, path, memnode, VL_ZOOM, &val);
     val.fractVal.numeriator=1;
     val.fractVal.denominator=2;
vlSetControl(svr, path, memnode, VL_ASPECT, &val);

On video source and drain nodes, you can set VL_ZOOM to unity (1/1) only, because OCTANE Personal Video device does not support scaling on a video node.

On screen source nodes, if the VL_ZOOM value makes the resulting size invalid (that is, larger than a frame size), the size is constrained and a VLControlChanged event is generated. If the scaled size of the selected graphics region is smaller than the video frame size, use VL_OFFSET on the drain node to position the generated video.

Because the OCTANE Personal Video option can scale data coming from the screen source node, the minimum size (2 x 2) is the size after zooming. However, user-specified VL_SIZE numbers refer to the size before zooming. Thus, the minimum size the user can specify is the size that, when zoomed, yields 2 x 2. For example:

/*
 Set the (unzoomed) size to 20 pixels by 20 lines
*/
val.xyVal.x = 20;
val.xyVal.y = 20;
if (vlSetControl(server, screeen_path, screen_source_node, VL_SIZE, &val)) {
    vlPerror(“Unable to set size”);
    exit(1);
}
/*
  Set the scale factor to 1/10. This results in a scaled size of 
  20*1/10 by 20*1/10, or 2 pixels by 2 lines
*/
val.fractVal.numerator = 1;
val.fractVal.denominator = 10;
if (vlSetControl(server, screen_path, screen_source_node, VL_ZOOM, &val)) {
    vlPerror(“Unable to set zoom”);
    exit(1);
}

This fragment causes the screen source node to send xsize × ysize video with as much scaling as possible, assuming the size is smaller than the video stream:

if (vlGetControl(server, screen_path, screen_source, VL_SIZE, &val))
{
   vlPerror("Unable to get size");
   exit(1);
}
if (val.xyVal.x/xsize < val.xyVal.y/ysize)
   zoom_denom = (val.xyVal.x + xsize - 1)/xsize;
else
   zoom_denom = (val.xyVal.y + ysize - 1)/ysize;
val.fractVal.numerator = 1;
val.fractVal.denominator = zoom_denom;
if (vlSetControl(server, screen_path, screen_source_node, VL_ZOOM, &val))
{
   /* allow this error to fall through */
   vlPerror("Unable to set zoom");
}
val.xyVal.x = xsize;
val.xyVal.y = ysize;
if (vlSetControl(server, screen_path, screen_source_node,
VL_SIZE, &val))
{
   vlPerror("Unable to set size");
   exit(1);

}.

The VL_CAPTURE_NONINTERLEAVED capture type specifies that frame-size units are captured noninterleaved. Each field is placed in its own buffer, with the dominant field in the first buffer. If one of the fields of a frame is dropped, all fields are dropped. Consequently, an application is guaranteed that the field order is maintained; no special synchronization is necessary to ensure that fields from different frames are mixed.

The rate (VL_RATE) for noninterleaved capture is in terms of fields and must be even. For NTSC, the capture rate may be from 2 to 60 fields per second, and for PAL 2 to 50 fields per second. Because a frame is always captured as a whole, a rate of 30 fields per second results in the following field mask:

1100110011001100...

The first bit in the field mask corresponds to the dominant field of a frame. The OCTANE Personal Video option waits for a dominant field before it starts the transfer.

If VL_CAPTURE_NONINTERLEAVED is specified for playback, similar guarantees apply as for capture. If one field is lost during playback, it is not possible to “take back” the field. The OCTANE Personal Video option resynchronizes on the next frame boundary, although black or “garbage” video might be present between the erring field and the frame boundary.

The rate during playback also follows the rules for capture. For each 1 in the mask above, a field from the VL buffer is output. During the 0 fields, the previous frame is repeated. Note that the previous frame is output, not just the last field. If there are a pair of buffers, the dominant field is placed in the first buffer.

Interleaved capture interleaves the two fields of a frame and places them in a single buffer; the order of the frames depends on the value set for VL_EVO_DOMINANCE_FIELD (see Table B-2 or Table B-3 in Appendix B for details). The OCTANE Personal Video option guarantees that the interleaved fields are from the same frame: if one field of a frame is dropped, then both are dropped.

The rate for interleaved frames is in frames per second: 1 to 30 frames per second for NTSC and 1 to 25 frames per second for PAL. A rate of 15 frames per second results in every other frame being captured. Expressed as a field mask, the following sequence is captured:

1100110011001100....

As with VL_CAPTURE_NONINTERLEAVED, the OCTANE Personal Video option begins processing the field mask when a dominant field is encountered.

During playback, a frame is deinterleaved and output as two consecutive fields, with the dominant field output first. If one of the fields is lost, the OCTANE Personal Video option resynchronizes to a frame boundary before playing the next frame. During the resynchronization period, black or “garbage” data may be displayed.

Rate control follows similar rules as for capture. For each 1 in the mask above, a field from the interleaved frame is output. During 0 periods, the previous frame is repeated.

In the VL_CAPTURE_EVEN_FIELDS capture type, only even (F2) fields are captured, with each field placed in its own buffer. Expressed as a field mask, the captured fields are

1010101010101010...

The OCTANE Personal Video option begins processing this field mask when an even field is encountered.

The rate for this capture type is expressed in even fields. For NTSC, the range is 1 to 30 fields per second, and for PAL 1 to 25 fields per second. A rate of 15 fields per second (NTSC) indicates that every other even field is captured, yielding a field mask of

1000100010001000...

During playback, the even field is repeated as both the F1 and F2 fields, until it is time to output the next buffer. If a field is lost during playback, black or “garbage” data might be displayed until the next buffer is scheduled to be displayed.

The VL_CAPTURE_ODD_FIELDS capture type works the same way as VL_CAPTURE_EVEN_FIELDS, except that only odd (F1) fields are captured, with each field placed in its own buffer. The rate for this capture type is expressed in odd fields. A rate of 15 fields per second (NTSC) indicates that every other odd field is captured. Field masks are the same as for VL_CAPTURE_EVEN_FIELDS.

The VL_CAPTURE_FIELDS capture type captures both even and odd fields and places each in its own buffer. Unlike VL_CAPTURE_NONINTERLEAVED, there is no guarantee that fields are dropped in frame units. Field synchronization can be performed by examining the UST (Unadjusted System Time), the MSC (Media Stream Count), or the dmedia info sequence number associated with each field. These synchronization features are explained in Chapter 4, “Synchronizing Data Streams and Signals.”

The rate for this capture type is expressed in fields. For NTSC, the range is 1 to 60 fields per second, and for PAL 1 to 50 fields per second. A rate of 30 fields per second (NTSC) indicates that every other field is captured, resulting in the following field mask:

101010101010101010...

Contrast this with the rate of 30 for VL_CAPTURE_NONINTERLEAVED, which captures every other frame.

Field mask processing begins on the first field after the transfer is started; field dominance, evenness, or oddness play no role in this capture type.

Each component of an image has

Normally, a component stays within the minimum and maximum values. For example, for a luma signal such as Y, you can think of these limits as the black level and the peak white level, respectively. For a component with n bits, there are two possibilities for [minimum value, maximum value]:

Two sets of colors are commonly used together, RGB (RGBA) and YCrCb/YUV (VYUA). YCrCb (YUV), the most common representation of color from the video world, represents each color by a luma component called Y and two components of chroma, called Cr (or V), and Cb (or U). The luma component is loosely related to brightness or luminance, and the chroma components make up a quantity loosely related to hue. These components are defined rigorously in ITU-R BT.601-4 (also known as Rec. 601 and CCIR 601).

The alpha channel is not a color. For that channel, the canonical minimum value means completely transparent, and the canonical maximum value means completely opaque.

For more information about color spaces, see A Technical Introduction to Digital Video, by Charles A. Poynton (New York: Wiley, 1996).

For OpenGL, IRIS GL, and DM:

In the VL_PACKING tokens from IRIX 6.2, the VL_PACKING constant indicates whether the data is RGBA or VYUA (as in VL_PACKING_UYV_8_P). The VL for the OCTANE Personal Video option (for IRIX 6.4) makes all of the parameters (packing, set of colors, range of components) explicit:

The OCTANE Personal Video option performs color-space conversion if the color space implied by VL_FORMAT on the video node disagrees with that implied by VL_COLORSPACE. VL_COLORSPACE applies to memory source and drain nodes only.

In addition to the standard color-space conversion model, the OCTANE Personal Video color-space feature provides a constant-hue algorithm. This algorithm allows illegal YUV values to survive a YUV-to-RGB-to-YUV conversion. In normal conversion, YUV values that cannot be represented in the RGB color space are clamped or otherwise forced into the legal RGB range. Because the YUV (YCrCb) color space is a superset of the RGB color space, illegal RGB values can be generated when YUV is converted to RGB. If the constant-hue block is disabled, then the illegal RGB values are clipped by the output lookup table (LUT). The lost (clipped) information can result in significantly degraded quality when the image is subsequently transformed back to YUV for video output.

The constant-hue algorithm saves the normally lost information in a correction factor that can be stored in the alpha channel. To restore the original YUV image, this correction factor must be saved with the pixel data.

If the constant-hue algorithm is enabled, the illegal RGB values are converted into legal R'G'B' values. A constant-hue factor, used to restore R'G'B' to the original YUV values, can optionally be stored in the alpha channel. If the constant-hue factor is not saved, then the R'G'B' image appears as if it were range-compressed. A particular control (VL_EVO_CSC_ALPHA_CORRECTION) determines whether the alpha channel is replaced by the constant-hue factors, or if the alpha from the color-space converter's input is retained.

Note that because the correction factor computed by the algorithm is directly related to the pixel value, the correction factor is invalidated if the pixel value is recalculated (for example, during compositing).

The controls for constant hue are

---

Note: VL_EVO_CSC_ALPHA_CORRECTION has no effect if VL_EVO_CSC_CONST_HUE is disabled. When both VL_EVO_CSC_CONST_HUE and VL_EVO_CSC_ALPHA_CORRECTION are enabled, it is not advisable to load the alpha LUT.

---

By default, the constant-hue processing block is enabled, but the constant-hue factor is not stored in the alpha channel (the input alpha is retained).

If the constant-hue factor is not stored in the alpha channel, you might need to range-limit or expand the input alpha value. For example, when full-range RGBA is converted to YCrCbA, the range is limited from 0-255 to CCIRs (16-235). The range is altered using the output alpha LUT. The default contents of this LUT are determined by the input and output ranges.

In addition to standard conversions, the color-space converter can be loaded with user-defined input lookup tables, matrix multiplier coefficients, and output lookup tables. Applications can manipulate the tables and coefficients to perform color correction, colorization, or other image-processing functions. See Appendix D for a description of the color-space converter model and the relationships between the various internal processing blocks.

Table 3-12 summarizes image-processing controls. Access for all these controls is GST:

The control VL_EVO_CSC_COEF specifies the matrix multiplier coefficients. It has a data pointer pointing to an array of nine integers. The coefficients are stored in the following order:

Each coefficient is a 32-bit fractional two's complement value. The magnitude of each coefficient is from -4 to 3.999. Table 3-13 shows values.

For OCTANE Personal Video color-space conversion, the valid range for data[0], data[4], and data[8] is from -4 to 3.999; for the other six coefficients, the valid range is from -2 to 1.999. The 31st and 30th bits of the other six coefficients must be either all 0's or all 1's for the range from -2 to 1.999; otherwise they are clamped to the valid range.