Please consider a donation to the Higher Intellect project. See https://preterhuman.net/donate.php or the Donate to Higher Intellect page for more info.

The Pixel Rosetta Stone: Packings and Colorspaces

From Higher Intellect Vintage Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Assembled by Chris Pirazzi. Information provided by folks throughout the company, including Brian Beach, David Blythe, Nelson Bolyard, Terry Crane, Patricia Creek, Hilton Goldstein, Bent Hagemark, Angela Lai, Michael Minakami, Paul Ning, Michael Portuesi, Mark Segal, Paul Spencer, Mike Travis, Ashok Yerneni, and several mailing lists.

This document has two goals:

  • Describe all of the current VL packings.
  • Describe the current OpenGL, IRIS GL, DM, and CL packings which overlap with the VL packings or are otherwise useful to video developers.

Introduction

Tower of Babel?

Your first question is probably "Which of these zillions of packings are useful?" Each of these packings has some reason to exist, but the three most commonly used packings are:

  • Good ol' 4-byte-per-pixel OpenGL RGBA.
    • Implemented on all VL and OpenGL devices.
  • 2-byte-per-pixel 4:2:2 sampled YCrCb.
    • Implemented on all VL devices (watch out for colorspace issues).
  • The older 4-byte-per-pixel IRIS GL ABGR.
    • Implemented on all VL and IRIS GL devices up to IRIX 5.3.

Packing vs. Colorspace

In our model, all images have four components,

numbered 1 through 4.

A packing

  • determines which of the four components are sampled.
  • determines the sampling pattern (4:4:4, 4:2:2, etc.), which specifies where and how often each component of the image is sampled.
  • allocates a certain number of bits to represent the component samples, and positions those samples along with possible padding in memory. Each sample is an unsigned number.

A colorspace

  • determines the color of each of the components. two choices:

    Our Component Number

    (meaningful only in this document)

         1           2           3           4     
    "rgba" color set r g b a
    "vyua" color set v / Cr y u / Cb a

  • specifies a canonical minimum and maximum value for each component. There are two choices (full-range vs. headroom-range), described in The Colorspaces below.

See The Colorspaces below for further information about color set and range, and how to identify which

colorspace your library expects.

In most SGI libraries, a single token encodes both colorspace and packing. For the VL of divo and beyond, the two parameters are specified separately (using VL_PACKING and VL_COLORSPACE).

Packings

How to Read the Packing Diagrams

In the diagrams below,

  • As you move from left to right along the diagram,
    • Each byte goes from the most significant bit to the least significant bit.
    • The bytes increase in memory address by 1.
    • Component samples go from most significant bit to least significant bit.
  • We show the smallest repeating spatial pattern of component samples that is a multiple of 8 bits wide.
  • No additional padding or alignment is to be inferred. For example, this 24-bit-per-pixel diagram indicates 3-byte quantities packed together in memory. The values are not padded out to 32 bit boundaries.
  • When an "x" ("don't care") appears in a bit of the diagram, it means:
    • Readers may get any garbage in the bit.
    • Writers may leave the bit as garbage.
  • When a "0" appears in a bit of the diagram, it means:
    • Readers may assume the bit is zero.
    • Writers must zero out the bit.
    • Exception: writers in a memory-to-video VL path may leave the bit as garbage.
  • The packing really defines a bit layout for the abstract components 1, 2, 3, 4, but for convenience we have filled the component slots with the "rgba" or "vyua" color set where appropriate. See The Colorspaces below for more information.
  • For packings which use 4:2:2 or 4:2:0 sampling, we also show the spatial location of each component sample. We indicate "left" and "right" for 4:2:2, and "top left," "top right," "bottom left," "bottom right," and "center" for 4:2:0. Our diagrams assume row-major, left-to-right ordering of pixels in memory.
  • Following each packing diagram is a list of comments and library tokens which refer to that packing. We list the color set ("rgba" or "vyua") and the library ("VL," "OpenGL," "IRIS GL," "DM," or "CL") for each library token. "DM" refers to the tokens in /usr/lib/dmedia/dm_image.h, which are used by several libraries (libdmedia (dmParams, dmIC, dmColor), libmoviefile, libmovieplay, and others). See The Colorspaces below for more information.
  • We indicate which packings are supported by which VL devices. "Supported by xxx hardware" means the xxx device natively transfers data of that packing in real-time. "Supported by xxx software" means the xxx device's VL software implementation will automatically convert pixels from a native device format into that packing, which may or may not happen in real time.

Pixel Packings, Sorted by Width

8 Bit Pixel Packings

Pixel 1
Byte 1
yyyyyyyy
  • (vyua) Monochrome/luma-only signal
  • (vyua) Supported by vino hardware
  • (vyua) Supported by ev1 software
  • (vyua) Supported by ev3 software for single-link i/o
  • (vyua) Supported by divo hardware
  • (vyua) (DM) DM_IMAGE_PACKING_LUMINANCE
  • (vyua) (CL) CL_FORMAT_GRAYSCALE
  • (vyua) (VL) VL_PACKING_4_8 + VL_COLORSPACE_{CCIR,YUV}
  • (vyua) (VL) VL_PACKING_Y_8_P
  • (vyua) (OpenGL) GL_LUMINANCE GL_UNSIGNED_BYTE
  • (vyua) (IRIS GL) PM_LUMINANCE PM_UNSIGNED_BYTE on RealityEngine



Pixel 1
Byte 1
bbgggrrr
  • (rgba) Supported by vino hardware
  • (rgba) Supported by Newport (indy) graphics and XL graphics hardware
  • (rgba) Supported by ev1 software
  • (rgba) Supported by ev3 software for single-link i/o
  • (rgba) Supported by divo hardware
  • (rgba) (DM) DM_IMAGE_PACKING_BGR233
  • (rgba) (CL) CL_FORMAT_BGR233
  • (rgba) (VL) VL_PACKING_R444_332 + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (VL) VL_PACKING_RGB_332_P
  • (rgba) (IRIS GL) PM_SIZE=9 on Newport, XL


Pixel 1
Byte 1
rrrbbggg
  • (rgba) Obsolete: used with Indigo Entry graphics and Starter Video.
  • (rgba) Pixmode man page incorrectly describes this packing.
  • (rgba) (DM) DM_IMAGE_PACKING_RBG323
  • (rgba) (CL) CL_FORMAT_RBG323
  • (rgba) (VL) VL_PACKING_X444_332 + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (VL) VL_PACKING_RBG_323
  • (rgba) (IRIS GL) PM_SIZE=8 on Indigo Entry


Pixel 1
Byte 1
rrrgggbb
  • (rgba) Supported by O2 (CRM) graphics
  • (rgba) Supported by divo hardware
  • (rgba) (DM) DM_IMAGE_PACKING_RGB332
  • (rgba) (VL) VL_PACKING_444_332 + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (OpenGL) GL_RGB GL_UNSIGNED_BYTE_3_3_2_EXT


12 Bit Pixel Packings

Pixels 1-4
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6
uuuuuuuuyyyyyyyyvvvvvvvvyyyyyyyyyyyyyyyyyyyyyyyy
center top left center top right bottom left bottom right


16 Bit Pixel Packings

Pixel 1
Byte 1Byte 2
yyyyyyyyaaaaaaaa
  • (vyua) Luminance/Alpha packing supported by colorspace library and GL
  • (vyua) (DM) DM_IMAGE_PACKING_LUMINANCE_ALPHA
  • (vyua) (OpenGL) GL_LUMINANCE_ALPHA GL_UNSIGNED_BYTE
  • (vyua) (IRIS GL) PM_LUMINANCEA PM_UNSIGNED_BYTE on RealityEngine


Pixels 1-2
Byte 1Byte 2Byte 3Byte 4
vvvvvvvvyyyyyyyyuuuuuuuuyyyyyyyy
left right
  • (vyua) Rarely used. 4:2:2 sampling.
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_242_8 + VL_COLORSPACE_{CCIR,YUV}


Pixels 1-2
Byte 1Byte 2Byte 3Byte 4
uuuuuuuuyyyyyyyyvvvvvvvvyyyyyyyy
left right
  • (vyua) Most commonly used 4:2:2 packing.
  • (vyua) Supported by vino hardware
  • (vyua) Supported by ev1 software
  • (vyua) Supported by ev3 hardware for single link i/o
  • (vyua) Supported by sirius hardware
  • (vyua) Supported by mvp hardware
  • (vyua) Supported by divo hardware
  • (vyua) Supported by O2 (CRM) graphics hardware. For OpenGL examples, check out Displaying In-Memory Video Using OpenGL and Rendering graphics onto video.
  • (vyua) (DM) DM_IMAGE_PACKING_CbYCrY
  • (vyua) (CL) CL_FORMAT_YCbCr422
  • (vyua) (VL) VL_PACKING_R242_8 + VL_COLORSPACE_{CCIR,YUV}
  • (vyua) (VL) VL_PACKING_YVYU_422_8
  • (vyua) (CL) CL_FORMAT_YCbCr422DC: actually a 4:2:0 packing. CL_FORMAT_YCbCr422DC and DM_IMAGE_PACKING_CbYCrYYY for info.
  • (vyua) (OpenGL) GL_YCRCB_422_SGIX GL_UNSIGNED_BYTE


Pixel 1
Byte 1Byte 2
arrrrrgggggbbbbb
  • (rgba) Supported by O2 (CRM) graphics hardware for pbuffers and textures, but not glDrawPixels(). Even though the token DM_IMAGE_PACKING_XRGB1555 is used, the upper bit is really alpha.
  • (rgba) Supported by mvp hardware
  • (rgba) Supported by divo hardware
  • (rgba) Quicktime file 16-bit uncompressed format with alpha.
  • (rgba) (DM) DM_IMAGE_PACKING_XRGB1555
  • (rgba) (VL) VL_PACKING_X4444_5551 + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (VL) VL_PACKING_ARGB_1555


Pixel 1
Byte 1Byte 2
rrrrrgggggbbbbba
  • (rgba) Apparently Useless. Not supported by any graphics or video hardware.
  • (rgba) (DM) DM_IMAGE_PACKING_RGBA5551
  • (rgba) (OpenGL) GL_RGBA GL_UNSIGNED_SHORT_5_5_5_1_EXT


Pixel 1
Byte 1Byte 2
rrrrrggggggbbbbb
  • (rgba) Supposedly common in the PC world.
  • (rgba) Supported by divo hardware
  • (rgba) (VL) VL_PACKING_444_5_6_5 + VL_COLORSPACE_{RGB,RP175}


24 Bit Pixel Packings

Pixel 1
Byte 1Byte 2Byte 3
rrrrrrrrggggggggbbbbbbbb
vvvvvvvvyyyyyyyyuuuuuuuu
  • (rgba) Supported by divo hardware
  • (rgba) Supported by Octane ev3 hardware for dual-link RGB i/o
  • (rgba) (DM) DM_IMAGE_PACKING_RGB
  • (rgba) (VL) VL_PACKING_444_8 + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (VL) VL_PACKING_BGR_8_P
  • (rgba) (OpenGL) GL_RGB GL_UNSIGNED_BYTE
  • (rgba) (IRIS GL) PM_RGB PM_UNSIGNED_BYTE on RealityEngine
  • (vyua) Supported by ev3 hardware for dual-link YCrCb i/o
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_444_8 + VL_COLORSPACE_{CCIR,YUV}
  • (vyua) (VL) VL_PACKING_UYV_8_P


Pixel 1
Byte 1Byte 2Byte 3
bbbbbbbbggggggggrrrrrrrr
uuuuuuuuyyyyyyyyvvvvvvvv
  • (rgba) Supported by divo hardware
  • (rgba) (DM) DM_IMAGE_PACKING_BGR
  • (rgba) (CL) CL_FORMAT_BGR
  • (rgba) (VL) VL_PACKING_R444_8 + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (VL) VL_PACKING_RGB_8_P
  • (rgba) (IRIS GL) PM_BGR PM_UNSIGNED_BYTE on RealityEngine
  • (vyua) Supported by divo hardware
  • (vyua) (DM) DM_IMAGE_PACKING_CbYCr
  • (vyua) (CL) CL_FORMAT_YCbCr
  • (vyua) (VL) VL_PACKING_R444_8 + VL_COLORSPACE_{CCIR,YUV}


Pixel 1
Byte 1Byte 2Byte 3
rrrrrrggggggbbbbbbaaaaaa
vvvvvvyyyyyyuuuuuuaaaaaa
  • (rgba) 6 bits per pixel
  • (rgba) Supported by divo hardware
  • (rgba) (VL) VL_PACKING_4444_6 + VL_COLORSPACE_{RGB,RP175}
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_4444_6 + VL_COLORSPACE_{CCIR,YUV}


OpenGL-Like 32-bit Packings:

Pixel 1
Byte 1Byte 2Byte 3Byte 4
rrrrrrrrggggggggbbbbbbbbaaaaaaaa
vvvvvvvvyyyyyyyyuuuuuuuuaaaaaaaa
  • (rgba) Default OpenGL Packing
  • (rgba) Supported by ev1 software (A is 0)
  • (rgba) Supported by ev3 software for single-link i/o (A is 0)
  • (rgba) Supported by ev3 hardware for dual-link RGBA i/o
  • (rgba) Supported by sirius hardware
  • (rgba) Supported by mvp hardware (A is a settable constant)
  • (rgba) Supported by divo hardware
  • (rgba) (DM) DM_IMAGE_PACKING_RGBA
  • (rgba) (VL) VL_PACKING_4444_8 + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (VL) VL_PACKING_ABGR_8
  • (rgba) (OpenGL) GL_RGBA GL_UNSIGNED_BYTE (the default)
  • (rgba) (IRIS GL) PM_RGBA PM_UNSIGNED_BYTE on RealityEngine
  • (vyua) Supported by ev3 hardware for dual-link YCrCbA i/o
  • (vyua) Supported by sirius hardware
  • (vyua) Supported by mvp hardware (A is a settable constant)
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_4444_8 + VL_COLORSPACE_{CCIR,YUV}
  • (vyua) (VL) VL_PACKING_AUYV_4444_8 or VL_PACKING_AUYV_8


Pixel 1
Byte 1Byte 2Byte 3Byte 4
rrrrrrrrggggggggbbbbbbbbxxxxxxxx
  • (rgba) Use DM_IMAGE_PACKING_RGBA instead of DM_IMAGE_PACKING_RGBX unless you specifically want to inform a piece of software (such as dmColor) not to spend processing time on the alpha channel.
  • (rgba) (DM) DM_IMAGE_PACKING_RGBX


IRIS GL-Like 32-bit Packings:

Pixel 1
Byte 1Byte 2Byte 3Byte 4
aaaaaaaabbbbbbbbggggggggrrrrrrrr
aaaaaaaauuuuuuuuyyyyyyyyvvvvvvvv
  • (rgba) Default IRIS GL Packing
  • (rgba) Supported by vino hardware (A is a settable constant)
  • (rgba) Supported by ev1 software (A is 0)
  • (rgba) Supported by ev3 software for single-link i/o (A is 0)
  • (rgba) Supported by ev3 hardware for dual-link RGBA i/o
  • (rgba) Supported by sirius hardware
  • (rgba) Supported by mvp hardware (A is a settable constant)
  • (rgba) Supported by divo hardware
  • (rgba) (DM) DM_IMAGE_PACKING_ABGR
  • (rgba) (CL) CL_FORMAT_ABGR
  • (rgba) (VL) VL_PACKING_R4444_8 + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (VL) VL_PACKING_RGBA_8
  • (rgba) (OpenGL) GL_ABGR_EXT GL_UNSIGNED_BYTE
  • (rgba) (IRIS GL) PM_ABGR PM_UNSIGNED_BYTE (the default)
  • (vyua) Supported by ev3 hardware for dual-link YCrCbA i/o. Non-full-size (cropped or zoomed) output may have green padding on some Octane ev3 models.
  • (vyua) Supported by sirius hardware
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_R4444_8 + VL_COLORSPACE_{CCIR,YUV}
  • (vyua) (VL) VL_PACKING_YUVA_4444_8


Pixel 1
Byte 1Byte 2Byte 3Byte 4
xxxxxxxxbbbbbbbbggggggggrrrrrrrr
xxxxxxxxuuuuuuuuyyyyyyyyvvvvvvvv
  • (rgba) Use DM_IMAGE_PACKING_ABGR instead of DM_IMAGE_PACKING_XBGR unless you specifically want to inform a piece of software (such as dmColor) not to spend processing time on the alpha channel.
  • (rgba) Often interchangeable with Default IRIS GL Packing
  • (rgba) Supported by ev1 software
  • (rgba) Supported by ev3 software for single-link i/o
  • (rgba) Supported by ev3 hardware for dual-link RGBA i/o
  • (rgba) Supported by sirius hardware
  • (rgba) Supported by divo hardware
  • (rgba) (DM) DM_IMAGE_PACKING_XBGR
  • (rgba) (CL) CL_FORMAT_XBGR
  • (rgba) (VL) VL_PACKING_R0444_8 + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (VL) VL_PACKING_RGB_8
  • (vyua) Supported by ev3 hardware for dual-link YCrCbA i/o
  • (vyua) Supported by sirius hardware
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_R0444_8 + VL_COLORSPACE_{CCIR,YUV}
  • (vyua) (VL) VL_PACKING_YUV_444_8


Unusual 32-bit Packings:

Pixel 1
Byte 1Byte 2Byte 3Byte 4
aaaaaaaarrrrrrrrggggggggbbbbbbbb
  • (rgba) Quicktime 32-bit uncompressed format with alpha.
  • (rgba) (DM) DM_IMAGE_PACKING_ARGB


Pixel 1
Byte 1Byte 2Byte 3Byte 4
xxxxxxxxrrrrrrrrggggggggbbbbbbbb
xxxxxxxxvvvvvvvvyyyyyyyyuuuuuuuu
  • (rgba) Quicktime file 32-bit uncompressed format without alpha
  • (rgba) Supported by divo hardware
  • (rgba) (DM) DM_IMAGE_PACKING_XRGB
  • (rgba) (VL) VL_PACKING_0444_8 + VL_COLORSPACE_{RGB,RP175}
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_0444_8 + VL_COLORSPACE_{CCIR,YUV}


Pixel 1
Byte 1Byte 2Byte 3Byte 4
uuuuuuuuyyyyyyyyvvvvvvvvaaaaaaaa
  • (vyua) Rarely Used. Component order not compatible with any hardware.
  • 4:4:4:4 sampled YCrCb with alpha.
  • (vyua) (DM) DM_IMAGE_PACKING_CbYCrA


4:4:4:4 10_10_10_2 32-bit Packings:

Pixel 1
Byte 1Byte 2Byte 3Byte 4
rrrrrrrrrrggggggggggbbbbbbbbbbaa
vvvvvvvvvvyyyyyyyyyyuuuuuuuuuuaa
  • (rgba) Supported by sirius hardware
  • (rgba) Supported by divo hardware
  • (rgba) Supported by Octane ev3 hardware for dual-link RGBA i/o
  • (rgba) (VL) VL_PACKING_4444_10_10_10_2 + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (VL) VL_PACKING_A_2_BGR_10
  • (rgba) (OpenGL) GL_RGBA GL_UNSIGNED_INT_10_10_10_2_EXT
  • (vyua) Supported by sirius hardware
  • (vyua) Supported by divo hardware
  • (vyua) Supported by Octane ev3 hardware for dual-link YCrCbA i/o
  • (vyua) (VL) VL_PACKING_4444_10_10_10_2 + VL_COLORSPACE_{CCIR,YUV}
  • (vyua) (VL) VL_PACKING_A_2_UYV_10


Pixel 1
Byte 1Byte 2Byte 3Byte 4
aabbbbbbbbbbggggggggggrrrrrrrrrr
aauuuuuuuuuuyyyyyyyyyyvvvvvvvvvv
  • (rgba) Supported by divo hardware
  • (rgba) (VL) VL_PACKING_R4444_10_10_10_2 + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (OpenGL) GL_ABGR_EXT GL_UNSIGNED_INT_10_10_10_2_EXT
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_R4444_10_10_10_2 + VL_COLORSPACE_{CCIR,YUV}


4:2:2:4 10_10_10_2 32-bit Packings:

Pixels 1-2
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
vvvvvvvvvvyyyyyyyyyyaaaaaaaaaa00uuuuuuuuuuyyyyyyyyyyaaaaaaaaaa00
left 00left right 00
  • (vyua) 4:2:2:4 sampling (2 bits of A)
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_2424_10_10_10_2Z + VL_COLORSPACE_{CCIR,YUV}


Pixels 1-2
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
uuuuuuuuuuyyyyyyyyyyaaaaaaaaaa00vvvvvvvvvvyyyyyyyyyyaaaaaaaaaa00
left 00left right 00
  • (vyua) 4:2:2:4 sampling (2 bits of A)
  • (vyua) Supported by ev3 hardware for dual-link YCrCbA i/o. Note YCrCb data is 4:2:2---only alpha is extracted from second link.
  • (vyua) Supported by sirius hardware
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_R2424_10_10_10_2Z + VL_COLORSPACE_{CCIR,YUV}
  • (vyua) (VL) VL_PACKING_AYU_AYV_10


4:2:2 10_in_16 32-bit Packings:

Pixels 1-2
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
vvvvvvvvvv000000yyyyyyyyyy000000uuuuuuuuuu000000yyyyyyyyyy000000
left 000000left 000000left 000000right 000000
  • (vyua) 4:2:2 sampling
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_242_10_in_16_L + VL_COLORSPACE_{CCIR,YUV}


Pixels 1-2
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
000000vvvvvvvvvv000000yyyyyyyyyy000000uuuuuuuuuu000000yyyyyyyyyy
000000left 000000left 000000left 000000right
  • (vyua) 4:2:2 sampling
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_242_10_in_16_R + VL_COLORSPACE_{CCIR,YUV}


Pixels 1-2
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
uuuuuuuuuu000000yyyyyyyyyy000000vvvvvvvvvv000000yyyyyyyyyy000000
left 000000left 000000left 000000right 000000
  • (vyua) 4:2:2 sampling
  • (vyua) Supported by ev3 hardware for single-link i/o
  • (vyua) Supported by mvp hardware
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_R242_10_in_16_L + VL_COLORSPACE_{CCIR,YUV}
  • (vyua) (VL) VL_PACKING_YVYU_422_10


Pixels 1-2
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
000000uuuuuuuuuu000000yyyyyyyyyy000000vvvvvvvvvv000000yyyyyyyyyy
000000left 000000left 000000left 000000right
  • (vyua) 4:2:2 sampling
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_R242_10_in_16_R + VL_COLORSPACE_{CCIR,YUV}


36 Bit Pixel Packings

Pixel 1Pixel 2
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8Byte 9
rrrrrrrrrrrrggggggggggggbbbbbbbbbbbbrrrrrrrrrrrrggggggggggggbbbbbbbbbbbb
vvvvvvvvvvvvyyyyyyyyyyyyuuuuuuuuuuuuvvvvvvvvvvvvyyyyyyyyyyyyuuuuuuuuuuuu
  • (rgba) 12 bits per component.
  • (rgba) Supported by divo hardware
  • (rgba) (VL) VL_PACKING_444_12 + VL_COLORSPACE_{RGB,RP175}
  • XXX is this what IRIS GL _12 means?
  • (rgba) (IRIS GL) PM_RGB PM_UNSIGNED_SHORT_12 on RealityEngine
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_444_12 + VL_COLORSPACE_{CCIR,YUV}


48 Bit Pixel Packings

Pixel 1
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6
rrrrrrrrrrrrggggggggggggbbbbbbbbbbbbaaaaaaaaaaaa
vvvvvvvvvvvvyyyyyyyyyyyyuuuuuuuuuuuuaaaaaaaaaaaa
  • (rgba) 12 bits per component.
  • (rgba) Supported by divo hardware
  • (rgba) (VL) VL_PACKING_4444_12 + VL_COLORSPACE_{RGB,RP175}
  • XXX is this what IRIS GL _12 means?
  • (rgba) (IRIS GL) PM_RGBA PM_UNSIGNED_SHORT_12 on RealityEngine
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_4444_12 + VL_COLORSPACE_{CCIR,YUV}


64 Bit Pixel Packings

Pixel 1
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
rrrrrrrrrr000000gggggggggg000000bbbbbbbbbb000000aaaaaaaaaa000000
vvvvvvvvvv000000yyyyyyyyyy000000uuuuuuuuuu000000aaaaaaaaaa000000
  • (rgba) Supported by ev3 hardware for dual-link RGBA i/o
  • (rgba) Supported by divo hardware
  • (rgba) (VL) VL_PACKING_4444_10_in_16_L + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (VL) VL_PACKING_ABGR_10
  • (vyua) Supported by ev3 hardware for dual-link YCrCb i/o
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_4444_10_in_16_L + VL_COLORSPACE_{CCIR,YUV}
  • (vyua) (VL) VL_PACKING_AUYV_4444_10


Pixel 1
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
000000rrrrrrrrrr000000gggggggggg000000bbbbbbbbbb000000aaaaaaaaaa
000000vvvvvvvvvv000000yyyyyyyyyy000000uuuuuuuuuu000000aaaaaaaaaa
  • (rgba) Supported by divo hardware
  • (rgba) (VL) VL_PACKING_4444_10_in_16_R + VL_COLORSPACE_{RGB,RP175}
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_4444_10_in_16_R + VL_COLORSPACE_{CCIR,YUV}


Pixel 1
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
aaaaaaaaaa000000bbbbbbbbbb000000gggggggggg000000rrrrrrrrrr000000
aaaaaaaaaa000000uuuuuuuuuu000000yyyyyyyyyy000000vvvvvvvvvv000000
  • (rgba) Supported by ev3 hardware for dual-link RGBA i/o
  • (rgba) Supported by divo hardware
  • (rgba) (VL) VL_PACKING_R4444_10_in_16_L + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (VL) VL_PACKING_RGBA_10
  • (vyua) Supported by ev3 hardware for dual-link YCrCbA i/o. Non-full-size (cropped or zoomed) output may have green padding on some Octane ev3 models.
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_R4444_10_in_16_L + VL_COLORSPACE_{CCIR,YUV}
  • (vyua) (VL) VL_PACKING_YUVA_4444_10



Pixel 1
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
000000aaaaaaaaaa000000bbbbbbbbbb000000gggggggggg000000rrrrrrrrrr
000000aaaaaaaaaa000000uuuuuuuuuu000000yyyyyyyyyy000000vvvvvvvvvv
  • (rgba) Supported by divo hardware
  • (rgba) (VL) VL_PACKING_R4444_10_in_16_R + VL_COLORSPACE_{RGB,RP175}
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_R4444_10_in_16_R + VL_COLORSPACE_{CCIR,YUV}


Pixel 1
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
xxxxxxxxxx000000bbbbbbbbbb000000gggggggggg000000rrrrrrrrrr000000
xxxxxxxxxx000000uuuuuuuuuu000000yyyyyyyyyy000000vvvvvvvvvv000000
  • (rgba) Supported by ev3 hardware for dual-link RGBA i/o
  • (rgba) Supported by divo hardware
  • (rgba) (VL) VL_PACKING_R4440_10_in_16_L + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (VL) VL_PACKING_RGB_10
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_R4440_10_in_16_L + VL_COLORSPACE_{CCIR,YUV}
  • (vyua) (VL) VL_PACKING_YUV_444_10


Pixel 1
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
000000xxxxxxxxxx000000bbbbbbbbbb000000gggggggggg000000rrrrrrrrrr
000000xxxxxxxxxx000000uuuuuuuuuu000000yyyyyyyyyy000000vvvvvvvvvv
  • (rgba) Supported by divo hardware
  • (rgba) (VL) VL_PACKING_R4440_10_in_16_R + VL_COLORSPACE_{RGB,RP175}
  • (vyua) Supported by divo hardware
  • (vyua) (VL) VL_PACKING_R4440_10_in_16_R + VL_COLORSPACE_{CCIR,YUV}


Pixel 1
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
aaaaaaaaaaaa0000bbbbbbbbbbbb0000gggggggggggg0000rrrrrrrrrrrr0000
  • (rgba) Supported by divo hardware, for use with extended RGB components
  • (rgba) (VL) VL_PACKING_R4444_12_in_16_L + VL_COLORSPACE_{RGB,RP175}
  • (rgba) (IRIS GL) PM_SIZE=64 on RealityEngine


Pixel 1
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
0000aaaaaaaaaaaa0000bbbbbbbbbbbb0000gggggggggggg0000rrrrrrrrrrrr
  • (rgba) Supported by divo hardware, for use with extended RGB components
  • (rgba) (VL) VL_PACKING_R4444_12_in_16_R + VL_COLORSPACE_{RGB,RP175}


Pixel 1
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
aaaaaaaaaaaaa000bbbbbbbbbbbbb000ggggggggggggg000rrrrrrrrrrrrr000
  • (rgba) Supported by divo hardware, for use with extended RGB components
  • (rgba) (VL) VL_PACKING_R4444_13_in_16_L + VL_COLORSPACE_{RGB,RP175}


Pixel 1
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
000aaaaaaaaaaaaa000bbbbbbbbbbbbb000ggggggggggggg000rrrrrrrrrrrrr
  • (rgba) Supported by divo hardware, for use with extended RGB components
  • (rgba) (VL) VL_PACKING_R4444_13_in_16_R + VL_COLORSPACE_{RGB,RP175}


Pixel 1
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
rrrrrrrrrrrrrrrrggggggggggggggggbbbbbbbbbbbbbbbbaaaaaaaaaaaaaaaa
  • (rgba) may be interchangeable with VL _L tokens above depending on video device
  • (rgba) (OpenGL) GL_RGBA GL_UNSIGNED_SHORT
  • (rgba) (IRIS GL) PM_RGBA PM_UNSIGNED_SHORT on RealityEngine


Pixel 1
Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8
aaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbggggggggggggggggrrrrrrrrrrrrrrrr
  • (rgba) may be interchangeable with VL _L tokens above depending on video device
  • (rgba) (OpenGL) GL_ABGR_EXT GL_UNSIGNED_SHORT
  • (rgba) (IRIS GL) PM_ABGR PM_UNSIGNED_SHORT on RealityEngine


The Packings, Sorted by Library

OpenGL Pixel Packings

OpenGL can represent many more packings than we can list. The OpenGL packings which overlap with the other library packings, where:

  • GL_UNPACK_SWAP_BYTES is disabled.
  • GL_c_SCALE at 1.0 and GL_c_BIAS at 0.0. These can be used to convert between full-range and headroom-range. See The Colorspaces below.
  • GL_MAP_COLOR is false. This can also be used to do the range conversion.

are:

  • GL_LUMINANCE GL_UNSIGNED_BYTE
  • GL_RGB GL_UNSIGNED_BYTE_3_3_2_EXT
  • GL_LUMINANCE_ALPHA GL_UNSIGNED_BYTE
  • GL_YCRCB_422_SGIX GL_UNSIGNED_BYTE
  • GL_RGBA GL_UNSIGNED_SHORT_5_5_5_1_EXT
  • GL_RGB GL_UNSIGNED_BYTE
  • GL_RGBA GL_UNSIGNED_BYTE (the default)
  • GL_ABGR_EXT GL_UNSIGNED_BYTE
  • GL_RGBA GL_UNSIGNED_INT_10_10_10_2_EXT
  • GL_ABGR_EXT GL_UNSIGNED_INT_10_10_10_2_EXT
  • GL_RGBA GL_UNSIGNED_SHORT
  • GL_ABGR_EXT GL_UNSIGNED_SHORT

IRIS GL Pixel Packings

IRIS GL can represent many more packings than we can list. The IRIS GL packings which overlap with the other library packings, where:

  • PM_SHIFT is 0.
  • PM_ADD24 is 0.
  • PM_TTOB and PM_RTOL are disabled.
  • PM_ZDATA is 0.

are

  • PM_LUMINANCE PM_UNSIGNED_BYTE on RealityEngine
  • PM_SIZE=9 on Newport, XL
  • PM_SIZE=8 on Indigo Entry
  • PM_LUMINANCEA PM_UNSIGNED_BYTE on RealityEngine
  • PM_RGB PM_UNSIGNED_BYTE on RealityEngine
  • PM_BGR PM_UNSIGNED_BYTE on RealityEngine
  • PM_RGBA PM_UNSIGNED_BYTE on RealityEngine
  • PM_ABGR PM_UNSIGNED_BYTE (the default)
  • PM_RGB PM_UNSIGNED_SHORT_12 on RealityEngine
  • PM_RGBA PM_UNSIGNED_SHORT_12 on RealityEngine
  • PM_SIZE=64 on RealityEngine
  • PM_RGBA PM_UNSIGNED_SHORT on RealityEngine
  • PM_ABGR PM_UNSIGNED_SHORT on RealityEngine

Digital Media Library (DM) Pixel Packings

This list is complete as of IRIX 6.3:

  • DM_IMAGE_PACKING_LUMINANCE
  • DM_IMAGE_PACKING_BGR233
  • DM_IMAGE_PACKING_RBG323
  • DM_IMAGE_PACKING_RGB332
  • DM_IMAGE_PACKING_CbYCrYYY - CL_FORMAT_YCbCr422DC and DM_IMAGE_PACKING_CbYCrYYY for an example.
  • DM_IMAGE_PACKING_LUMINANCE_ALPHA
  • DM_IMAGE_PACKING_CbYCrY
  • DM_IMAGE_PACKING_XRGB1555
  • DM_IMAGE_PACKING_RGBA5551
  • DM_IMAGE_PACKING_RGB
  • DM_IMAGE_PACKING_BGR
  • DM_IMAGE_PACKING_CbYCr
  • DM_IMAGE_PACKING_RGBA
  • DM_IMAGE_PACKING_RGBX
  • DM_IMAGE_PACKING_ABGR
  • DM_IMAGE_PACKING_XBGR
  • DM_IMAGE_PACKING_ARGB
  • DM_IMAGE_PACKING_XRGB
  • DM_IMAGE_PACKING_CbYCrA

Compression Library (CL) Pixel Packings

This list is complete as of IRIX 6.3:

Traditional VL Pixel Packings

This list is complete as of IRIX 6.3. Here are the ones we document:

  • VL_PACKING_Y_8_P
  • VL_PACKING_RGB_332_P
  • VL_PACKING_RBG_323
  • VL_PACKING_YVYU_422_8
  • VL_PACKING_ARGB_1555
  • VL_PACKING_BGR_8_P
  • VL_PACKING_UYV_8_P
  • VL_PACKING_RGB_8_P
  • VL_PACKING_ABGR_8
  • VL_PACKING_AUYV_4444_8 or VL_PACKING_AUYV_8
  • VL_PACKING_RGBA_8
  • VL_PACKING_YUVA_4444_8
  • VL_PACKING_RGB_8
  • VL_PACKING_YUV_444_8
  • VL_PACKING_A_2_BGR_10
  • VL_PACKING_A_2_UYV_10
  • VL_PACKING_AYU_AYV_10
  • VL_PACKING_YVYU_422_10
  • VL_PACKING_ABGR_10
  • VL_PACKING_AUYV_4444_10
  • VL_PACKING_RGBA_10
  • VL_PACKING_YUVA_4444_10
  • VL_PACKING_RGB_10
  • VL_PACKING_YUV_444_10

Here are the remaining tokens:

  • VL_PACKING_VUY_411_SV - obsolete Starter Video packing
  • VL_PACKING_RGB_332 - obsolete: use VL_PACKING_RGB_332_P
  • VL_PACKING_BGR_332 - obsolete: use VL_PACKING_RGB_332_P
  • VL_PACKING_RGB_332_IP - obsolete: use VL_PACKING_RGB_332_P
  • VL_PACKING_BGR_332_P - obsolete: use VL_PACKING_RGB_332_P
  • VL_PACKING_BGR_332_IP - obsolete: use use VL_PACKING_RGB_332_P
  • VL_PACKING_RGB_565 - obsolete: use VL_PACKING_444_5_6_5
  • VL_PACKING_RGB_565_P - obsolete: use VL_PACKING_444_5_6_5
  • VL_PACKING_RGB_565_IP - obsolete: use VL_PACKING_444_5_6_5
  • VL_PACKING_Y_8_IP - obsolete: use VL_PACKING_Y_8_P

Memory-Only (divo and Beyond) VL Pixel Packings

  • VL_PACKING_4_8
  • VL_PACKING_R444_332
  • VL_PACKING_X444_332
  • VL_PACKING_444_332
  • VL_PACKING_242_8
  • VL_PACKING_R242_8
  • VL_PACKING_X4444_5551
  • VL_PACKING_444_5_6_5
  • VL_PACKING_444_8
  • VL_PACKING_R444_8
  • VL_PACKING_4444_6
  • VL_PACKING_4444_8
  • VL_PACKING_R4444_8
  • VL_PACKING_R0444_8
  • VL_PACKING_0444_8
  • VL_PACKING_4444_10_10_10_2
  • VL_PACKING_R4444_10_10_10_2
  • VL_PACKING_2424_10_10_10_2Z
  • VL_PACKING_R2424_10_10_10_2Z
  • VL_PACKING_242_10_in_16_L
  • VL_PACKING_242_10_in_16_R
  • VL_PACKING_R242_10_in_16_L
  • VL_PACKING_R242_10_in_16_R
  • VL_PACKING_444_12
  • VL_PACKING_4444_12
  • VL_PACKING_4444_10_in_16_L
  • VL_PACKING_4444_10_in_16_R
  • VL_PACKING_R4444_10_in_16_L
  • VL_PACKING_R4444_10_in_16_R
  • VL_PACKING_R4440_10_in_16_L
  • VL_PACKING_R4440_10_in_16_R
  • VL_PACKING_R4444_12_in_16_L
  • VL_PACKING_R4444_12_in_16_R
  • VL_PACKING_R4444_13_in_16_L
  • VL_PACKING_R4444_13_in_16_R

Where Do the Memory-Only VL_PACKING Names Come From?

The naming scheme for the new memory-only VL_PACKING tokens (found in the VL of divo and beyond) works like this:

  • VL_PACKING_{Direction}{Sampling}_{Detail}{Padding}
  • Direction:
    • Normal packing order is component 1, 2, 3, 4 (read from left to right in the diagrams in The Colorspaces below). Direction is empty.
    • Some packings have component order 4, 3, 2, 1. Direction is R for "reverse."
    • Some packings have neither component order. Direction is X.
  • Sampling (video industry terminology also shown):
    • 4: ("vyua" color set only) only component 2 (Y).
    • 444: 4:4:4 sampling: components 1, 2, 3, sampled once per pixel.
    • 4444: 4:4:4:4 sampling: components 1, 2, 3, 4, sampled once per pixel.
    • 4440 or 0444: 4:4:4 sampling: same as 4444 except the space for component 4 (alpha) is filled with zeroes.
    • 242: ("vyua" color set only) 4:2:2 sampling: component 2 (Y) sampled once per pixel, component 1 and 3 (Cr and Cb) sampled every 2 pixels.
    • 2424: ("vyua" color set only) 4:2:2:4 sampling: component 2 (Y) and 4 (alpha) sampled once per pixel, component 1 and 3 (Cr and Cb) sampled every 2 pixels.
  • Detail: indicates how many bits are allocated to each component and whether the components are padded out to byte boundaries. Component widths listed in order (component 1, 2, 3, 4). Specify padded components with "n_in_m." If all components have same width and padding, specify only one width and padding.
  • Padding: packings in which components are padded either left- or right-justify each n-bit component into an m-bit cell. Packings where the components occur in the high order bits of the cells end in _L. Packings where components occur in the low order bits of the cells end in _R. Padding is empty for packings without padding.

Extended RGB Components

A few of the VL-supported packings have components with more than 10 bits per component, which may seem strange since the highest-resolution video signals only carry 10 bits per component. These packings are for use with extended-range components, a feature (soon to be released on Onyx2/divo systems) which is currently beyond the scope of this document. We will add more information about extended-range components when the support is released.

Sampling Pattern Definitions

4:4:4 and 4:4:4:4 Sampling

Some of the diagrams indicate 4:4:4 or 4:4:4:4 sampling. This video industry terminology simply means that each of your 3 or 4 components

is sampled at every pixel.

There is no particularly good reason why the terminology is 4:4:4 rather than 8:8:8 or any other N:N:N. N needed to be at least 4 in order to describe 4:1:1.

4:2:2 and 4:2:2:4 Sampling

Some of the diagrams indicate 4:2:2 sampling. These packings make sense only in the "vyua" colorspaces. It means that for every two pixels, we get two luma samples (two Y's) but only one chroma sample (one sample of Cr and Cb, which together determine the chroma), like this:

422.gif

The chroma samples belong at the same instant in space as the left Y sample (the chrominance samples and the left Y are "co-sited"). Our diagrams for 4:2:2 packings show the spatial location of each Y, Cr, or Cb component as "left" or "right." The first pixel of each line is

a "left" pixel.

Converting 4:4:4 video to 4:2:2 video is like converting 44.1kHz audio into 22.05kHz audio: just dropping every other Cr,Cb sample will yield extremely poor results. Real video devices which need to convert between 4:4:4 and 4:2:2 use carefully designed filters. The characteristics of the required filter are specified in ITU-R BT.601-4 (Rec. 601).

4:2:2 sampled packings that also include alpha are called 4:2:2:4. There is one alpha value per pixel, like the Y value.

4:2:0 Sampling

The MPEG and H.261 video compression standards use 4:2:0 sampling. Like 4:2:2 sampling, 4:2:0 sampling only makes sense for "vyua" packings. In this case, there is one chroma sample (one pair of Cr and Cb) for every four luminance samples (Y), like this:

420.gif

The chroma samples occur at the spatial center of four luminance samples. The concept of "pixel" becomes difficult to define! Our diagrams for 4:2:0 packings show the spatial location of each Y, Cr, or Cb component as "top left," "top right," "bottom left," "bottom right," and "center," according to their position in this pattern. The top left luminance sample of the image is a "top left"

sample.

The DM has a 4:2:0 packing called DM_IMAGE_PACKING_CbYCrYYY. The CL has a 4:2:0 packing called CL_FORMAT_YCbCr422DC (for "Duplicate Chroma") which represents 4:2:0 data redundantly as 4:2:2 data. This is what the software MPEG codec uses. CL_FORMAT_YCbCr422DC and DM_IMAGE_PACKING_CbYCrYYY for an example.

4:1:1 Sampling

Another subsampling method with similar "compression" as 4:2:0 is 4:1:1. With 4:1:1, four horizontally adjacent Y samples on the same line are paired with one Cr,Cb sample. The Cr,Cb sample and the "leftmost" Y sample are co-sited. The leftmost Y sample of each line is a "leftmost" sample. This method generally looks worse than 4:2:0 at the same cost, and it is not currently used by any SGI

libraries.

Colorspaces

The Colorspaces

Each component of an image has:

  • a color which it represents,
  • a canonical minimum value, and
  • a canonical maximum value.

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

  • full-range:
    • [0, (2^nbits)-1]
    • This range provides the maximum resolution for each component.
  • headroom-range:
    • Cr and Cb: [(2^n)/16, 15*(2^n)/16]
    • Y, A, R, G, B: [(2^n)/16, 235*(2^n)/256]
    • This range is defined for 8 and 10 bits in ITU-R BT.601-4 (Rec. 601).
    • example: 8-bit components: Cr and Cb: [16, 240]. Y, A, R, G, B: [16, 235].
    • example: 10-bit components: Cr and Cb: [64, 960]. Y, A, R, G, B: [64, 940].
    • This range provides numerical headroom, which is often useful when processing video images.

There are two sets of colors which are commonly used together:

  • RGB ("rgba" in diagrams above): The familiar red, green, and blue, plus alpha.

    Our Component Number

    (meaningful only in this document)

         1           2           3           4     
    Interpretation r g b a

  • YCrCb/YUV ("vyua" in diagrams above): Separate luma and chroma, plus alpha.

    Our Component Number

    (meaningful only in this document)

         1           2           3           4     
    Interpretation v / Cr y u / Cb a

    The most common representation of color from the video world, YCrCb or YUV 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 formerly CCIR 601).

    When referring to the chroma components, it's probably better to use Cr and Cb than V and U, because the analog NTSC video specification ANSI/SMPTE 170M uses V and U with a slightly different meaning. This document uses the letters "v" and "u" in the diagrams above for typographical convenience.

What color is R, G, B, Y, Cr, or Cb? An excellent book for more information about colorspaces is "A Technical Introduction to Digital

Video" by Charles A. Poynton (New York: Wiley, 1996).

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

How to Tell Which Colorspace You Have

For OpenGL, IRIS GL, DM, and CL:

  • the library constant indicates whether the data is "rgba" or "vyua"
  • "rgba" data is full-range by default.
  • "vyua" data in DM and CL may be full-range or headroom-range. You must determine this from context.
  • "vyua" data in OpenGL is headroom-range by default. For information on the SGIX_ycrcb OpenGL extension, see glDrawPixels(3G), Displaying In-Memory Video Using OpenGL and Rendering graphics onto video.

For VL, using the traditional VL_PACKING tokens from IRIX 6.2:

  • the VL_PACKING constant indicates whether the data is "rgba" or "vyua"
  • "rgba" data on vino, ev1, cosmo2, ev3, and mvp will always be full-range by default.
  • "vyua" data on vino, ev1, cosmo2, ev3, and mvp will always be headroom-range by default.
  • you can program ev3 to deliver headroom-range "rgba" data (also called RP175 RGBA) by setting VL_FORMAT on the memory node to VL_FORMAT_DIGITAL_COMPONENT_RGB_SERIAL. This only works if the video signal at the jack is also VL_FORMAT_DIGITAL_COMPONENT_RGB* (ev3 will not automatically do color conversion like sirius does).
  • ev3 has an optional high-quality colorspace converter which you can program to convert between all sorts of colorspaces using ev3-specific controls.
  • on sirius, when you set up a vid-to-mem or mem-to-vid transfer, you must specify the range and color set you want explicitly. You do this by specifying VL_FORMAT on your memory node, like so:

    Color SetFull-Range ComponentsHeadroom-Range Components
    "rgba"VL_FORMAT_RGBnot supported
    "vyua"VL_FORMAT_SMPTE_YUVVL_FORMAT_DIGITAL_COMPONENT

    Sirius will give you data in your desired range and color set regardless of the input signal format. If the colorspace implied by VL_FORMAT on the video node disagrees with that implied by VL_FORMAT on the memory node, then sirius will

    do colorspace conversion for you.

The VL that comes with the divo product and beyond makes all of the parameters (packing, set of colors, range of components) explicit in a clean way:

  • You use VL_PACKING to specify only the memory layout. The new memory-only VL_PACKING tokens are disjoint from the old, and the old tokens are still honored, so this change is backwards-compatible.
  • You use VL_COLORSPACE to specify the colorspace parameters:

    Color SetFull-Range ComponentsHeadroom-Range Components
    "rgba"VL_COLORSPACE_RGBVL_COLORSPACE_RP175
    "vyua"VL_COLORSPACE_YUVVL_COLORSPACE_CCIR

    There is also a VL_COLORSPACE_NONE, which is useful when you want to treat Rec. 601 digital video as a raw 10-bit data stream (as in SDDI).

  • Like sirius, divo will perform colorspace conversion if the colorspace implied by VL_FORMAT on the video node disagrees with that implied by VL_COLORSPACE on the memory node.

When Dealing with JPEG Data (cosmo1, cosmo2, mvp+ICE, JFIF files, MV/QT files):

  • compressed JPEG data (which internally uses "vyua" colors) from video-to-compression-to-memory and memory-to-compression-to-video paths with cosmo1 and cosmo2 is always headroom-range.
  • if you use cosmo2 or mvp+ICE in memory-to-memory mode,
    • with full-range "rgba" pixels on one end, then the other end is always headroom-range JPEG.
    • with any kind (full-range or headroom-range) of "vyua" pixels on one end, then the other end has the same kind of JPEG data.
  • if you use cosmo1 in memory-to-memory mode with full-range "rgba" pixels on one end, you will get full-range JPEG data out the other end. Don't feed full-range JPEG data into a cosmo1 memory-to-compression-to-video path. Bad Things will happen.
  • Note that the JPEG image file format, JFIF, requires full-range JPEG data, whereas motion JPEG movie file formats store headroom-range JPEG data. There is a proposed extension to JFIF to support headroom-range images.