Note: Updated Lurker's Guide available (but not this page!)

This page belongs to the old 1990s SGI Lurker's Guide. As of 2008, several of the Lurker's Guide pages have been updated for HDTV and for modern OS platforms like Windows and Mac. This particular page is not one of those, but you can see what new stuff is available here. Thanks!

The Pixel Rosetta Stone: Packings and Colorspaces

Assembled by Chris Pirazzi. Information provided by folks throughout the company, including Brian Beach, David Blythe, Nelson Bolyard, Terry Crane, Patricia Creek, Carolyn Curtis, 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.

This document makes no attempt at generality. As new packings and colorspaces are born, or otherwise become useful to video developers, we'll change our descriptive mechanism to fit them. The sections are:

• Introduction:
  • Tower of Babel?
  • Packing vs. Colorspace
• Packings:
  • How to Read the Packing Diagrams
  • Pixel Packings, Sorted by Width
  • Pixel Packings, Sorted By Library
  • Where Do the Memory-Only VL_PACKING Names Come From?
• Sampling Pattern Definitions:
  • 4:4:4 and 4:4:4:4 Sampling
  • 4:2:2 and 4:2:2:4 Sampling
  • 4:2:0 Sampling
  • 4:1:1 Sampling
• How to Tell Which Colorspace You Have

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. See Sampling Pattern Definitions for more information.
• allocates a certain number of bits to represent the component samples, and positions those samples along with possible padding in memory.
• determines the encoding of each component sample:
  • 1-10 bit component samples are unsigned numbers.
    Numerical range is [0 to 2^nbits-1] where nbits is 1-10.
  • 12-13 bit component samples are two's complement signed numbers.
    Numerical range is [-2^(nbits-1), 2^(nbits-1)-1] where nbits is 12-13.

  The 1-10 bit unsigned representations provide different levels of precision for the same range of component levels. So value 0 and value 2^nbits-1 represent the same component level regardless of nbits.

  The 12-13 bit signed representations provide precision equivalent to the 10 bit unsigned representation, over a wider range of component levels than the 10 bit unsigned representation. A 10 bit unsigned component with value V represents the same component level as a 12-13 bit signed component with value V. The 12-13 bit signed representation therefore can represent component levels outside the normal 10 bit range.

A colorspace

• determines the color of each of the components. two choices:
  • 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."

• specifies a canonical minimum and maximum value for each component.

  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 an unsigned component with n bits, there are two possibilities for [minimum value, maximum value]:

  • full-range:
    • [0, (2^n)-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.
    • Values in the range [0,(2^n)/256-1] and [255*(2^n)/256,(2^n)-1] are strictly forbidden. Input devices will strip out all such values. Output devices will substitute all such values with another nearby value.

  As described above, 12-13 bit signed components have the same scale and offset as 10 bit unsigned components, but can represent additional values outside of the unsigned 10 bit range. Therefore, 12-13 bit signed components have the same canonical minimum and maximum value as 10 bit unsigned components.

In most SGI libraries, a single token encodes both colorspace and packing. Often, details of the colorspace are implicit. For the VL of divo and beyond, the two parameters are specified separately and explicitly, using VL_PACKING and VL_COLORSPACE. See How to Tell Which Colorspace You Have to understand which libraries use which colorspace when.

If you were wondering, 12-13 bit signed components are useful for storing rgba components which have been converted from the vyua color set. For example, this happens when you transfer in-memory RGB pixels to or from an external Rec. 601 digital video signal. Because of the way the color sets are defined, there exist vyua values which map outside of the normal rgba color cube. The rgba values must either be clamped, in which case information is lost, or the rgba component representation must be allowed to exceed the normal values. This is fully described in the most excellent Appendix "Color-Space Conversions" of the DIVO (Digital Video Option) XIO Board Owner's Guide.

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.
• When an "s" appears in a bit of the diagram, the bit contains a sign extension (replication) of the next least significant bit.
• When a "p" appears in a bit of the diagram, it means:
  • This packing contains 10-, 12-, or 13-bit components left-justified in larger words. See VL_PACKING_R242_10_in_16_L for an example.
  • The "p" bits constitue the padding of the least significant bits of the word.
  • Readers may assume the bit is zero.
  • Exception: Readers in a divo video-to-memory VL path may assume that the bits are replicated from the component found in the same word. Assume the component's bits are numbered with 0 as the least significant bit. Assume there are n contiguous "p" bits to the right of the component. Those "p" bits contain a copy of bits [9,9-n+1] of the component. This device dependency is unfortunate.
  • 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 Packing vs. Colorspace 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 Packing vs. Colorspace 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
y	y	y	y	y	y	y	y

• (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
b	b	g	g	g	r	r	r

• (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
r	r	r	b	b	g	g	g

• (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
r	r	r	g	g	g	b	b

• (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 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6
u	u	u	u	u	u	u	u	y	y	y	y	y	y	y	y	v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y	y	y	y	y	y	y	y	y	y	y	y	y	y	y	y	y
center								top left								center								top right								bottom left								bottom right

• (vyua) 4:2:0 sampling as in MPEG and H.261
• (vyua) (DM) DM_IMAGE_PACKING_CbYCrYYY - See the document CL_FORMAT_YCbCr422DC and DM_IMAGE_PACKING_CbYCrYYY for an example.
• (vyua) the CL also has a 4:2:0 packing: check out CL_FORMAT_YCbCr422DC.

16 Bit Pixel Packings

Pixel 1
Byte 1								Byte 2
y	y	y	y	y	y	y	y	a	a	a	a	a	a	a	a

• (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 1								Byte 2								Byte 3								Byte 4
v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y	u	u	u	u	u	u	u	u	y	y	y	y	y	y	y	y
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 1								Byte 2								Byte 3								Byte 4
u	u	u	u	u	u	u	u	y	y	y	y	y	y	y	y	v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y
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. See the document CL_FORMAT_YCbCr422DC and DM_IMAGE_PACKING_CbYCrYYY for info.
• (vyua) (OpenGL) GL_YCRCB_422_SGIX GL_UNSIGNED_BYTE

Pixel 1
Byte 1								Byte 2
a	r	r	r	r	r	g	g	g	g	g	b	b	b	b	b

• (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 1								Byte 2
r	r	r	r	r	g	g	g	g	g	b	b	b	b	b	a

• (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 1								Byte 2
r	r	r	r	r	g	g	g	g	g	g	b	b	b	b	b

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

20 Bit Pixel Packings

Pixels 1-2
Byte 1								Byte 2								Byte 3								Byte 4								Byte 5
u	u	u	u	u	u	u	u	u	u	y	y	y	y	y	y	y	y	y	y	v	v	v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y	y	y
left																														right

• (vyua) 4:2:2 sampling
• (vyua) Supported by divo hardware
• (vyua) (VL) VL_PACKING_R242_10 + VL_COLORSPACE_{CCIR,YUV}

Pixels 1-2
Byte 1								Byte 2								Byte 3								Byte 4								Byte 5
v	v	v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y	y	y	u	u	u	u	u	u	u	u	u	u	y	y	y	y	y	y	y	y	y	y
left																														right

• (vyua) 4:2:2 sampling
• (vyua) Supported by divo hardware
• (vyua) (VL) VL_PACKING_242_10 + VL_COLORSPACE_{CCIR,YUV}

24 Bit Pixel Packings

Pixel 1
Byte 1								Byte 2								Byte 3
r	r	r	r	r	r	r	r	g	g	g	g	g	g	g	g	b	b	b	b	b	b	b	b
v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y	u	u	u	u	u	u	u	u

• (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 1								Byte 2								Byte 3
b	b	b	b	b	b	b	b	g	g	g	g	g	g	g	g	r	r	r	r	r	r	r	r
u	u	u	u	u	u	u	u	y	y	y	y	y	y	y	y	v	v	v	v	v	v	v	v

• (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 1								Byte 2								Byte 3
r	r	r	r	r	r	g	g	g	g	g	g	b	b	b	b	b	b	a	a	a	a	a	a
v	v	v	v	v	v	y	y	y	y	y	y	u	u	u	u	u	u	a	a	a	a	a	a

• (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 1								Byte 2								Byte 3								Byte 4
r	r	r	r	r	r	r	r	g	g	g	g	g	g	g	g	b	b	b	b	b	b	b	b	a	a	a	a	a	a	a	a
v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y	u	u	u	u	u	u	u	u	a	a	a	a	a	a	a	a

• (rgba) Most commonly used 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 (most commonly used OpenGL packing)
• (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 1								Byte 2								Byte 3								Byte 4
r	r	r	r	r	r	r	r	g	g	g	g	g	g	g	g	b	b	b	b	b	b	b	b	x	x	x	x	x	x	x	x

• (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 1								Byte 2								Byte 3								Byte 4
a	a	a	a	a	a	a	a	b	b	b	b	b	b	b	b	g	g	g	g	g	g	g	g	r	r	r	r	r	r	r	r
a	a	a	a	a	a	a	a	u	u	u	u	u	u	u	u	y	y	y	y	y	y	y	y	v	v	v	v	v	v	v	v

• (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 IRIS GL packing)
• (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 1								Byte 2								Byte 3								Byte 4
x	x	x	x	x	x	x	x	b	b	b	b	b	b	b	b	g	g	g	g	g	g	g	g	r	r	r	r	r	r	r	r
x	x	x	x	x	x	x	x	u	u	u	u	u	u	u	u	y	y	y	y	y	y	y	y	v	v	v	v	v	v	v	v

• (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 1								Byte 2								Byte 3								Byte 4
a	a	a	a	a	a	a	a	r	r	r	r	r	r	r	r	g	g	g	g	g	g	g	g	b	b	b	b	b	b	b	b

• (rgba) Quicktime 32-bit uncompressed format with alpha.
• (rgba) (DM) DM_IMAGE_PACKING_ARGB

Pixel 1
Byte 1								Byte 2								Byte 3								Byte 4
x	x	x	x	x	x	x	x	r	r	r	r	r	r	r	r	g	g	g	g	g	g	g	g	b	b	b	b	b	b	b	b
x	x	x	x	x	x	x	x	v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y	u	u	u	u	u	u	u	u

• (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 1								Byte 2								Byte 3								Byte 4
u	u	u	u	u	u	u	u	y	y	y	y	y	y	y	y	v	v	v	v	v	v	v	v	a	a	a	a	a	a	a	a

• (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 1								Byte 2								Byte 3								Byte 4
r	r	r	r	r	r	r	r	r	r	g	g	g	g	g	g	g	g	g	g	b	b	b	b	b	b	b	b	b	b	a	a
v	v	v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y	y	y	u	u	u	u	u	u	u	u	u	u	a	a

• (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 1								Byte 2								Byte 3								Byte 4
a	a	b	b	b	b	b	b	b	b	b	b	g	g	g	g	g	g	g	g	g	g	r	r	r	r	r	r	r	r	r	r
a	a	u	u	u	u	u	u	u	u	u	u	y	y	y	y	y	y	y	y	y	y	v	v	v	v	v	v	v	v	v	v

• (rgba) Not currently supported by any VL device
• (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) Not currently supported by any VL device
• (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 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
v	v	v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y	y	y	a	a	a	a	a	a	a	a	a	a	0	0	u	u	u	u	u	u	u	u	u	u	y	y	y	y	y	y	y	y	y	y	a	a	a	a	a	a	a	a	a	a	0	0
left																														0	0	left										right																				0	0

• (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 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
u	u	u	u	u	u	u	u	u	u	y	y	y	y	y	y	y	y	y	y	a	a	a	a	a	a	a	a	a	a	0	0	v	v	v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y	y	y	a	a	a	a	a	a	a	a	a	a	0	0
left																														0	0	left										right																				0	0

• (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 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
v	v	v	v	v	v	v	v	v	v	p	p	p	p	p	p	y	y	y	y	y	y	y	y	y	y	p	p	p	p	p	p	u	u	u	u	u	u	u	u	u	u	p	p	p	p	p	p	y	y	y	y	y	y	y	y	y	y	p	p	p	p	p	p
left										p	p	p	p	p	p	left										p	p	p	p	p	p	left										p	p	p	p	p	p	right										p	p	p	p	p	p

• (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 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
0	0	0	0	0	0	v	v	v	v	v	v	v	v	v	v	0	0	0	0	0	0	y	y	y	y	y	y	y	y	y	y	0	0	0	0	0	0	u	u	u	u	u	u	u	u	u	u	0	0	0	0	0	0	y	y	y	y	y	y	y	y	y	y
0	0	0	0	0	0	left										0	0	0	0	0	0	left										0	0	0	0	0	0	left										0	0	0	0	0	0	right

• (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 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
u	u	u	u	u	u	u	u	u	u	p	p	p	p	p	p	y	y	y	y	y	y	y	y	y	y	p	p	p	p	p	p	v	v	v	v	v	v	v	v	v	v	p	p	p	p	p	p	y	y	y	y	y	y	y	y	y	y	p	p	p	p	p	p
left										p	p	p	p	p	p	left										p	p	p	p	p	p	left										p	p	p	p	p	p	right										p	p	p	p	p	p

• (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 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
0	0	0	0	0	0	u	u	u	u	u	u	u	u	u	u	0	0	0	0	0	0	y	y	y	y	y	y	y	y	y	y	0	0	0	0	0	0	v	v	v	v	v	v	v	v	v	v	0	0	0	0	0	0	y	y	y	y	y	y	y	y	y	y
0	0	0	0	0	0	left										0	0	0	0	0	0	left										0	0	0	0	0	0	left										0	0	0	0	0	0	right

• (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 1																																				Pixel 2
Byte 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8								Byte 9
r	r	r	r	r	r	r	r	r	r	r	r	g	g	g	g	g	g	g	g	g	g	g	g	b	b	b	b	b	b	b	b	b	b	b	b	r	r	r	r	r	r	r	r	r	r	r	r	g	g	g	g	g	g	g	g	g	g	g	g	b	b	b	b	b	b	b	b	b	b	b	b
v	v	v	v	v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y	y	y	y	y	u	u	u	u	u	u	u	u	u	u	u	u	v	v	v	v	v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y	y	y	y	y	u	u	u	u	u	u	u	u	u	u	u	u

• (rgba) Note: components are two's complement signed integers
• (rgba) Supported by divo hardware
• (rgba) (VL) VL_PACKING_444_12 + VL_COLORSPACE_{RGB,RP175}
• (vyua) Note: components are two's complement signed integers
• (vyua) Supported by divo hardware
• (vyua) (VL) VL_PACKING_444_12 + VL_COLORSPACE_{CCIR,YUV}

48 Bit Pixel Packings

Pixel 1
Byte 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6
r	r	r	r	r	r	r	r	r	r	p	p	p	p	p	p	g	g	g	g	g	g	g	g	g	g	p	p	p	p	p	p	b	b	b	b	b	b	b	b	b	b	p	p	p	p	p	p
v	v	v	v	v	v	v	v	v	v	p	p	p	p	p	p	y	y	y	y	y	y	y	y	y	y	p	p	p	p	p	p	u	u	u	u	u	u	u	u	u	u	p	p	p	p	p	p

• (rgba) Supported by divo hardware
• (rgba) (VL) VL_PACKING_444_10_in_16_L + VL_COLORSPACE_{RGB,RP175}
• (vyua) Supported by divo hardware
• (vyua) (VL) VL_PACKING_444_10_in_16_L + VL_COLORSPACE_{CCIR,YUV}

Pixel 1
Byte 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6
r	r	r	r	r	r	r	r	r	r	r	r	g	g	g	g	g	g	g	g	g	g	g	g	b	b	b	b	b	b	b	b	b	b	b	b	a	a	a	a	a	a	a	a	a	a	a	a
v	v	v	v	v	v	v	v	v	v	v	v	y	y	y	y	y	y	y	y	y	y	y	y	u	u	u	u	u	u	u	u	u	u	u	u	a	a	a	a	a	a	a	a	a	a	a	a

• (rgba) Note: components are two's complement signed integers
• (rgba) Supported by divo hardware
• (rgba) (VL) VL_PACKING_4444_12 + VL_COLORSPACE_{RGB,RP175}
• (vyua) Note: components are two's complement signed integers
• (vyua) Supported by divo hardware
• (vyua) (VL) VL_PACKING_4444_12 + VL_COLORSPACE_{CCIR,YUV}

64 Bit Pixel Packings

Pixel 1
Byte 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
r	r	r	r	r	r	r	r	r	r	p	p	p	p	p	p	g	g	g	g	g	g	g	g	g	g	p	p	p	p	p	p	b	b	b	b	b	b	b	b	b	b	p	p	p	p	p	p	a	a	a	a	a	a	a	a	a	a	p	p	p	p	p	p
v	v	v	v	v	v	v	v	v	v	p	p	p	p	p	p	y	y	y	y	y	y	y	y	y	y	p	p	p	p	p	p	u	u	u	u	u	u	u	u	u	u	p	p	p	p	p	p	a	a	a	a	a	a	a	a	a	a	p	p	p	p	p	p

• (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 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
0	0	0	0	0	0	r	r	r	r	r	r	r	r	r	r	0	0	0	0	0	0	g	g	g	g	g	g	g	g	g	g	0	0	0	0	0	0	b	b	b	b	b	b	b	b	b	b	0	0	0	0	0	0	a	a	a	a	a	a	a	a	a	a
0	0	0	0	0	0	v	v	v	v	v	v	v	v	v	v	0	0	0	0	0	0	y	y	y	y	y	y	y	y	y	y	0	0	0	0	0	0	u	u	u	u	u	u	u	u	u	u	0	0	0	0	0	0	a	a	a	a	a	a	a	a	a	a

• (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 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
a	a	a	a	a	a	a	a	a	a	p	p	p	p	p	p	b	b	b	b	b	b	b	b	b	b	p	p	p	p	p	p	g	g	g	g	g	g	g	g	g	g	p	p	p	p	p	p	r	r	r	r	r	r	r	r	r	r	p	p	p	p	p	p
a	a	a	a	a	a	a	a	a	a	p	p	p	p	p	p	u	u	u	u	u	u	u	u	u	u	p	p	p	p	p	p	y	y	y	y	y	y	y	y	y	y	p	p	p	p	p	p	v	v	v	v	v	v	v	v	v	v	p	p	p	p	p	p

• (rgba) Supported by ev3 hardware for dual-link RGBA i/o
• (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) (VL) VL_PACKING_R4444_10_in_16_L + VL_COLORSPACE_{CCIR,YUV}
• (vyua) (VL) VL_PACKING_YUVA_4444_10

Pixel 1
Byte 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
x	x	x	x	x	x	x	x	x	x	p	p	p	p	p	p	b	b	b	b	b	b	b	b	b	b	p	p	p	p	p	p	g	g	g	g	g	g	g	g	g	g	p	p	p	p	p	p	r	r	r	r	r	r	r	r	r	r	p	p	p	p	p	p

• (rgba) Supported by ev3 hardware for dual-link RGBA i/o
• (rgba) (VL) VL_PACKING_R4440_10_in_16_L + VL_COLORSPACE_{RGB,RP175}
• (rgba) (VL) VL_PACKING_RGB_10

Pixel 1
Byte 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
r	r	r	r	r	r	r	r	r	r	r	r	p	p	p	p	g	g	g	g	g	g	g	g	g	g	g	g	p	p	p	p	b	b	b	b	b	b	b	b	b	b	b	b	p	p	p	p	a	a	a	a	a	a	a	a	a	a	a	a	p	p	p	p

• (rgba) Note: components are two's complement signed integers
• (rgba) Supported by divo hardware
• (rgba) (VL) VL_PACKING_4444_12_in_16_L + VL_COLORSPACE_{RGB,RP175}
• (rgba) (IRIS GL) PM_SIZE=64 on RealityEngine

Pixel 1
Byte 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
s	s	s	s	r	r	r	r	r	r	r	r	r	r	r	r	s	s	s	s	g	g	g	g	g	g	g	g	g	g	g	g	s	s	s	s	b	b	b	b	b	b	b	b	b	b	b	b	s	s	s	s	a	a	a	a	a	a	a	a	a	a	a	a

• (rgba) Note: components are two's complement signed integers
• (rgba) Supported by divo hardware
• (rgba) (VL) VL_PACKING_4444_12_in_16_R + VL_COLORSPACE_{RGB,RP175}

Pixel 1
Byte 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
r	r	r	r	r	r	r	r	r	r	r	r	r	p	p	p	g	g	g	g	g	g	g	g	g	g	g	g	g	p	p	p	b	b	b	b	b	b	b	b	b	b	b	b	b	p	p	p	a	a	a	a	a	a	a	a	a	a	a	a	a	p	p	p

• (rgba) Note: components are two's complement signed integers
• (rgba) Supported by divo hardware
• (rgba) (VL) VL_PACKING_4444_13_in_16_L + VL_COLORSPACE_{RGB,RP175}

Pixel 1
Byte 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
s	s	s	r	r	r	r	r	r	r	r	r	r	r	r	r	s	s	s	g	g	g	g	g	g	g	g	g	g	g	g	g	s	s	s	b	b	b	b	b	b	b	b	b	b	b	b	b	s	s	s	a	a	a	a	a	a	a	a	a	a	a	a	a

• (rgba) Note: components are two's complement signed integers
• (rgba) Supported by divo hardware
• (rgba) (VL) VL_PACKING_4444_13_in_16_R + VL_COLORSPACE_{RGB,RP175}

Pixel 1
Byte 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
r	r	r	r	r	r	r	r	r	r	r	r	r	r	r	r	g	g	g	g	g	g	g	g	g	g	g	g	g	g	g	g	b	b	b	b	b	b	b	b	b	b	b	b	b	b	b	b	a	a	a	a	a	a	a	a	a	a	a	a	a	a	a	a

• (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 1								Byte 2								Byte 3								Byte 4								Byte 5								Byte 6								Byte 7								Byte 8
a	a	a	a	a	a	a	a	a	a	a	a	a	a	a	a	b	b	b	b	b	b	b	b	b	b	b	b	b	b	b	b	g	g	g	g	g	g	g	g	g	g	g	g	g	g	g	g	r	r	r	r	r	r	r	r	r	r	r	r	r	r	r	r

• (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

Pixel 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 Packing vs. Colorspace.
• 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 (most commonly used OpenGL packing)
• 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 IRIS GL packing)
• 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 - See the document 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:

• CL_FORMAT_GRAYSCALE
• CL_FORMAT_BGR233
• CL_FORMAT_RBG323
• CL_FORMAT_YCbCr422
• CL_FORMAT_YCbCr422DC: actually a 4:2:0 packing. See the document CL_FORMAT_YCbCr422DC and DM_IMAGE_PACKING_CbYCrYYY for info.
• CL_FORMAT_BGR
• CL_FORMAT_YCbCr
• CL_FORMAT_ABGR
• CL_FORMAT_XBGR

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

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_R242_10
• VL_PACKING_242_10
• 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_444_10_in_16_L
• 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_R4440_10_in_16_L
• VL_PACKING_4444_12_in_16_L
• VL_PACKING_4444_12_in_16_R
• VL_PACKING_4444_13_in_16_L
• VL_PACKING_4444_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 Packing vs. Colorspace 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.

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. Here's an example with Y, Cr, and Cb (4:4:4 could also refer to R, G, B):

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. 4:2:2 sampling is described by ITU-R BT.601-4 (Rec. 601). 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:

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 video 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 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

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).

The MPEG I and H.261 video compression standards use this 4:2:0 sampling pattern:

The chroma samples occur at the spatial center of four luminance samples. The concept of "pixel" becomes difficult to define!

The 4:2:0 tokens DM_IMAGE_PACKING_CbYCrYYY. and CL_FORMAT_YCbCr422DC imply the above sampling pattern. CL_FORMAT_YCbCr422DC (for "Duplicate Chroma") represents 4:2:0 data redundantly as 4:2:2 data. See the document "CL_FORMAT_YCbCr422DC and DM_IMAGE_PACKING_CbYCrYYY" for an example. These are the tokens you use with SGI's software MPEG I codec. Currently (10/7/97) they are the only 4:2:0 tokens in any SGI library, because MPEG I and H.261 are currently the only shipped 4:2:0 codecs. Our 4:2:0 pixel packing diagrams 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 the pattern above. The top left luminance sample of the image is a "top left" sample.

In addition to supporting 4:4:4 and Rec.601 4:2:2, the MPEG II video compression standard supports this 4:2:0 sampling pattern:

It differs from MPEG I/H.261 only in the position of the chroma samples. Why the MPEG committee changed it is beyond us. Perhaps they wanted to make conversion from Rec.601 4:2:2 to MPEG II 4:2:0 less computationally expensive.

If we had any MPEG II 4:2:0 packing diagrams above, we would label each component as "top left," "top right," "bottom left," "bottom right," and "middle left." The top left luminance sample of the image is a "top left" sample.

Unlike MPEG I or H.261, MPEG II understands the concept of fields (see Fields: Why Video Is Crucially Different from Graphics). Each row in the sampling pattern above is one picture line of an interleaved frame. The MPEG II spec defines how the rows of Cr,Cb samples coincide temporally with the rows of Y samples.

Not to be outdone, the 625-line DVC compression standard (not DVCPRO) specifies this 4:2:0 sampling pattern:

DVC is also field-aware, and again this diagram is meant to show an interleaved frame. In the 625-line DVC sampling pattern, Cr and Cb samples are no longer co-sited. Instead, we get a whole line of Cr samples from each field, then we get a whole line of Cb samples from each field. The top two lines of the standard DVC frame contain Cr samples.

4:1:1 Sampling

Another subsampling method with similar "compression" as 4:2:0 is 4:1:1. The 525-line DVC compression standard, and both the 525- and 625-line variants of the DVCPRO compression standard, use this pattern:

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. It seems like kind of a bummer that 525-line DVC uses it.

How to Tell Which Colorspace You Have

In most SGI libraries, a single token encodes both colorspace and packing. Often, details of the colorspace are implicit. For the VL of divo and beyond, the two parameters are specified separately and explicitly, using VL_PACKING and VL_COLORSPACE. This section tells you which libraries use which colorspace when.

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 Set	Full-Range Components	Headroom-Range Components
  "rgba"	VL_FORMAT_RGB	not supported
  "vyua"	VL_FORMAT_SMPTE_YUV	VL_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 Set	Full-Range Components	Headroom-Range Components
  "rgba"	VL_COLORSPACE_RGB	VL_COLORSPACE_RP175
  "vyua"	VL_COLORSPACE_YUV	VL_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.