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?
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:
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
- (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
- (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
- (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
- (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
|
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:
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
Digital Media Library (DM) Pixel Packings
This list is complete as of IRIX 6.3:
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:
Here are the remaining tokens:
Memory-Only (divo and Beyond) VL Pixel Packings
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.