Khronos Data Format Specification License Information
Copyright (C) 2014-2019 The Khronos Group Inc. All Rights Reserved.
This specification is protected by copyright laws and contains material proprietary to the Khronos Group, Inc. It or any components may not be reproduced, republished, distributed, transmitted, displayed, broadcast, or otherwise exploited in any manner without the express prior written permission of Khronos Group. You may use this specification for implementing the functionality therein, without altering or removing any trademark, copyright or other notice from the specification, but the receipt or possession of this specification does not convey any rights to reproduce, disclose, or distribute its contents, or to manufacture, use, or sell anything that it may describe, in whole or in part.
This version of the Data Format Specification is published and copyrighted by Khronos, but is not a Khronos ratified specification. Accordingly, it does not fall within the scope of the Khronos IP policy, except to the extent that sections of it are normatively referenced in ratified Khronos specifications. Such references incorporate the referenced sections into the ratified specifications, and bring those sections into the scope of the policy for those specifications.
Khronos Group grants express permission to any current Promoter, Contributor or Adopter member of Khronos to copy and redistribute UNMODIFIED versions of this specification in any fashion, provided that NO CHARGE is made for the specification and the latest available update of the specification for any version of the API is used whenever possible. Such distributed specification may be reformatted AS LONG AS the contents of the specification are not changed in any way. The specification may be incorporated into a product that is sold as long as such product includes significant independent work developed by the seller. A link to the current version of this specification on the Khronos Group website should be included whenever possible with specification distributions.
Khronos Group makes no, and expressly disclaims any, representations or warranties, express or implied, regarding this specification, including, without limitation, any implied warranties of merchantability or fitness for a particular purpose or non-infringement of any intellectual property. Khronos Group makes no, and expressly disclaims any, warranties, express or implied, regarding the correctness, accuracy, completeness, timeliness, and reliability of the specification. Under no circumstances will the Khronos Group, or any of its Promoters, Contributors or Members or their respective partners, officers, directors, employees, agents, or representatives be liable for any damages, whether direct, indirect, special or consequential damages for lost revenues, lost profits, or otherwise, arising from or in connection with these materials.
Khronos, SYCL, SPIR, WebGL, EGL, COLLADA, StreamInput, OpenVX, OpenKCam, glTF, OpenKODE, OpenVG, OpenWF, OpenSL ES, OpenMAX, OpenMAX AL, OpenMAX IL and OpenMAX DL are trademarks and WebCL is a certification mark of the Khronos Group Inc. OpenCL is a trademark of Apple Inc. and OpenGL and OpenML are registered trademarks and the OpenGL ES and OpenGL SC logos are trademarks of Silicon Graphics International used under license by Khronos. All other product names, trademarks, and/or company names are used solely for identification and belong to their respective owners.
| Revision History | ||
|---|---|---|
| Revision 0.1 | Jan 2015 | AG |
| Initial sharing | ||
| Revision 0.2 | Feb 2015 | AG |
| Added clarification, tables, examples | ||
| Revision 0.3 | Feb 2015 | AG |
| Further cleanup | ||
| Revision 0.4 | Apr 2015 | AG |
| Channel ordering standardized | ||
| Revision 0.5 | Apr 2015 | AG |
| Typos and clarification | ||
| Revision 1.0 | May 2015 | AG |
| Submission for 1.0 release | ||
| Revision 1.0 rev 2 | Jun 2015 | AG |
| Clarifications for 1.0 release | ||
| Revision 1.0 rev 3 | Jul 2015 | AG |
| Added KHR_DF_SAMPLE_DATATYPE_LINEAR | ||
| Revision 1.0 rev 4 | Jul 2015 | AG |
| Clarified KHR_DF_SAMPLE_DATATYPE_LINEAR | ||
| Revision 1.0 rev 5 | Mar 2019 | AG |
| Clarification and typography | ||
| Revision 1.1 | Nov 2015 | AG |
| Added definitions of compressed texture formats | ||
| Revision 1.1 rev 2 | Jan 2016 | AG |
| Added definitions of floating point formats | ||
| Revision 1.1 rev 3 | Feb 2016 | AG |
| Fixed typo in sRGB conversion (thank you, Tom Grim!) | ||
| Revision 1.1 rev 4 | Mar 2016 | AG |
| Fixed typo/clarified sRGB in ASTC, typographical improvements | ||
| Revision 1.1 rev 5 | Mar 2016 | AG |
| Switch to official Khronos logo, removed scripts, restored title | ||
| Revision 1.1 rev 6 | Jun 2016 | AG |
| ASTC "block footprint" note, fixed credits/changelog/contents | ||
| Revision 1.1 rev 7 | Sep 2016 | AG |
| ASTC multi-point "part" and quint decode typo fixes | ||
| Revision 1.1 rev 8 | Jun 2017 | AG |
| ETC2 legibility and table typo fix | ||
| Revision 1.1 rev 9 | Mar 2019 | AG |
| Typo fixes and much reformatting | ||
Table of Contents
- 1. Introduction
- 2. Overview
- 3. Required concepts not in the “format”
- 4. Translation to API-specific representations
- 5. Data format descriptor
- 6. Descriptor block
- 7. Khronos Basic Data Format Descriptor Block
- 8. Extension for more complex formats
- 9. Frequently Asked Questions
- 9.1. Why have a binary format rather than a human-readable one?
- 9.2. Why not use an existing representation such as those on FourCC.org?
- 9.3. Why have a descriptive format?
- 9.4. Why describe this standard within Khronos?
- 9.5. Why should I use this format if I don’t need most of the fields?
- 9.6. Why not expand each field out to be integer for ease of decoding?
- 9.7. Can this descriptor be used for text content?
- 10. Floating-point formats
- 11. Example format descriptors
- 12. Compressed Texture Image Formats
- 13. S3TC Compressed Texture Image Formats
- 14. RGTC Compressed Texture Image Formats
- 15. BPTC Compressed Texture Image Formats
- 16. ETC1 Compressed Texture Image Formats
- 17. ETC2 Compressed Texture Image Formats
- 17.1. Format RGB ETC2
- 17.2. Format RGB ETC2 with sRGB encoding
- 17.3. Format RGBA ETC2
- 17.4. Format RGBA ETC2 with sRGB encoding
- 17.5. Format Unsigned R11 EAC
- 17.6. Format Unsigned RG11 EAC
- 17.7. Format Signed R11 EAC
- 17.8. Format Signed RG11 EAC
- 17.9. Format RGB ETC2 with punchthrough alpha
- 17.10. Format RGB ETC2 with punchthrough alpha and sRGB encoding
- 18. ASTC Compressed Texture Image Formats
- 18.1. What is ASTC?
- 18.2. Design Goals
- 18.3. Basic Concepts
- 18.4. Block Encoding
- 18.5. LDR and HDR Modes
- 18.6. Configuration Summary
- 18.7. Decode Procedure
- 18.8. Block Determination and Bit Rates
- 18.9. Block Layout
- 18.10. Block mode
- 18.11. Color Endpoint Mode
- 18.12. Integer Sequence Encoding
- 18.13. Endpoint Unquantization
- 18.14. LDR Endpoint Decoding
- 18.15. HDR Endpoint Decoding
- 18.16. Weight Decoding
- 18.17. Weight Unquantization
- 18.18. Weight Infill
- 18.19. Weight Application
- 18.20. Dual-Plane Decoding
- 18.21. Partition Pattern Generation
- 18.22. Data Size Determination
- 18.23. Void-Extent Blocks
- 18.24. Illegal Encodings
- 18.25. LDR PROFILE SUPPORT
- 18.26. HDR PROFILE SUPPORT
- 19. External references
- 20. Contributors
Abstract
This document describes a data format specification for non-opaque (user-visible) representations of user data to be used by, and shared between, Khronos standards. The intent of this specification is to avoid replication of incompatible format descriptions between standards and to provide a definitive mechanism for describing data that avoids excluding useful information that may be ignored by other standards. Other APIs are expected to map internal formats to this standard scheme, allowing formats to be shared and compared. This document also acts as a reference for the memory layout of a number of common compressed texture formats.
Many APIs operate on bulk data — buffers, images, volumes, etc. — each composed of many elements with a fixed and often simple representation. Frequently, multiple alternative representations of data are supported: vertices can be represented with different numbers of dimensions, textures may have different bit depths and channel orders, and so on. Sometimes the representation of the data is highly specific to the application, but there are many types of data that are common to multiple APIs — and these can reasonably be described in a portable manner. In this standard, the term data format describes the representation of data.
It is typical for each API to define its own enumeration of the data formats on which it can operate. This causes a problem when multiple APIs are in use: the representations are likely to be incompatible, even where the capabilities intersect. When additional format-specific capabilities are added to an API which was designed without them, the description of the data representation often becomes inconsistent and disjoint. Concepts that are unimportant to the core design of an API may be represented simplistically or inaccurately, which can be a problem as the API is enhanced or when data is shared.
Some APIs do not have a strict definition of how to interpret their data. For example, a rendering API may treat all color channels of a texture identically, leaving the interpretation of each channel to the user’s choice of convention. This may be true even if color channels are given names that are associated with actual colors — in some APIs, nothing stops the user from storing the blue quantity in the red channel and the red quantity in the blue channel. Without enforcing a single data interpretation on such APIs, it is nonetheless often useful to offer a clear definition of the color interpretation convention that is in force, both for code maintenance and for communication with external APIs which do have a defined interpretation. Should the user wish to use an unconventional interpretation of the data, an appropriate descriptor can be defined that is specific to this choice, in order to simplify automated interpretation of the chosen representation and to provide concise documentation.
Where multiple APIs are in use, relying on an API-specific representation as an intermediary can cause loss of important information. For example, a camera API may associate color space information with a captured image, and a printer API may be able to operate with that color space, but if the data is passed through an intermediate compute API for processing and that API has no concept of a color space, the useful information may be discarded.
The intent of this standard is to provide a common, consistent, machine-readable way to describe those data formats which are amenable to non-proprietary representation. This standard provides a portable means of storing the most common descriptive information associated with data formats, and an extension mechanism that can be used when this common functionality must be supplemented.
While this standard is intended to support the description of many kinds of data, the most common class of bulk data used in Khronos standards represents color information. For this reason, the range of standard color representations used in Khronos standards is diverse, and a significant portion of this specification is devoted to color formats.
Later sections provide a description of the memory layout of a number of common texture compression formats.
This document describes a standard layout for a data structure that can be used to define the representation of simple, portable, bulk data. Using such a data structure has the following benefits:
- Ensuring a precise description of the portable data
- Simplifying the writing of generic functionality that acts on many types of data
- Offering portability of data between APIs
The “bulk data” may be, for example:
- Pixel/texel data
- Vertex data
- A buffer of simple type
The layout of proprietary data structures is beyond the remit of this specification, but the large number of ways to describe colors, vertices and other repeated data makes standardization useful.
The data structure in this specification describes the elements in the bulk data in memory, not the layout of the whole. For example, it may describe the size, location and interpretation of color channels within a pixel, but is not responsible for determining the mapping between spatial coordinates and the location of pixels in memory. That is, two textures which share the same pixel layout can share the same descriptor as defined in this specification, but may have different sizes, line strides, tiling or dimensionality. An example pixel format is described in Figure 1: a single 5:6:5-bit pixel with blue in the low 5 bits, green in the next 6 bits, and red in the top 5 bits of a 16-bit word as laid out in memory on a little-endian machine (see Table 24).
In some cases, the elements of bulk texture data may not correspond to a conventional texel. For example, in a compressed texture it is common for the atomic element of the buffer to represent a rectangular block of texels. Alternatively the representation of the output of a camera may have a repeating pattern according to a Bayer or other layout, as shown in Figure 2. It is this repeating and self-contained atomic unit, termed a texel block, that is described by this standard.
The sampling or reconstruction of texel data is not a function of the data format. That is, a texture has the same format whether it is point sampled or a bicubic filter is used, and the manner of reconstructing full color data from a camera sensor is not defined. Where information making up the data format has a spatial aspect, this is part of the descriptor: it is part of the descriptor to define the spatial configuration of color samples in a Bayer sensor or whether the chroma difference channels in a Y′CBCR format are considered to be centered or co-sited, but not how this information must be used to generate coordinate-aligned full color values.
The data structure defined in this specification is termed a data format descriptor. This is an extensible block of contiguous memory, with a defined layout. The size of the data format descriptor depends on its content, but is also stored in a field at the start of the descriptor, making it possible to copy the data structure without needing to interpret all possible contents.
The data format descriptor is divided into one or more descriptor blocks, each also consisting of contiguous data, as shown in Table 1. These descriptor blocks may, themselves, be of different sizes, depending on the data contained within. The size of a descriptor block is stored as part of its data structure, allowing applications to process a data format descriptor while skipping contained descriptor blocks that it does not need to understand. The data format descriptor mechanism is extensible by the addition of new descriptor blocks.
Table 1. Data format descriptor and descriptor blocks
Data format descriptor
|
The diversity of possible data makes a concise description that can support every possible format impractical. This document describes one type of descriptor block, a basic descriptor block, that is expected to be the first descriptor block inside the data format descriptor where present, and which is sufficient for a large number of common formats, particularly for pixels. Formats which cannot be described within this scheme can use additional descriptor blocks of other types as necessary.
Later sections of this specification provide a description of the in-memory representation of a number of common compressed texture formats.
Data format: The interpretation of individual elements in bulk data. Examples include the channel ordering and bit positions in pixel data or the configuration of samples in a Bayer image. The format describes the elements, not the bulk data itself: an image’s size, stride, tiling, dimensionality, border control modes, and image reconstruction filter are not part of the format and are the responsibility of the application.
Data format descriptor: A contiguous block of memory containing information about how data is represented, in accordance with this specification. A data format descriptor is a container, within which can be found one or more descriptor blocks. This specification does not define where or how the the data format descriptor should be stored, only its content. For example, the descriptor may be directly prepended to the bulk data, perhaps as part of a file format header, or the descriptor may be stored in a CPU memory while the bulk data that it describes resides within GPU memory; this choice is application-specific.
(Data format) descriptor block: A contiguous block of memory with a defined layout, held within a data format descriptor. Each descriptor block has a common header that allows applications to identify and skip descriptor blocks that it does not understand, while continuing to process any other descriptor blocks that may be held in the data format descriptor.
Basic (data format) descriptor block: The initial form of descriptor block as described in this standard. Where present, it must be the first descriptor block held in the data format descriptor. This descriptor block can describe a large number of common formats and may be the only type of descriptor block that many portable applications will need to support.
Texel block: The units described by the Basic Data Format Descriptor: a repeating element within bulk data. In simple texture formats, a texel block may describe a single pixel. In formats with subsampled channels, the texel block may describe several pixels. In a block-based compressed texture, the texel block typically describes the compression block unit. The basic descriptor block supports texel blocks of up to four dimensions.
Sample: In this standard, texel blocks are considered to be composed of contiguous bit patterns with a single channel or component type and a single spatial location. A typical ARGB pixel has four samples, one for each channel, held at the same coordinate. A texel block from a Bayer sensor might have a different location for different channels, and may have multiple samples representing the same channel at multiple locations. A Y′CBCR buffer with downsampled chroma may have more luma samples than chroma, each at different locations.
Plane: In some formats, a texel block is not contiguous in memory. In a two-dimensional texture, the texel block may be spread across multiple scan lines, or channels may be stored independently. The basic format descriptor block defines a texel block as being made of a number of concatenated bits which may come from different regions of memory, where each region is considered a separate plane. For common formats, it is sufficient to require that the contribution from each plane is an integer number of bytes. This specification places no requirements on the ordering of planes in memory — the plane locations are described outside the format. This allows support for multiplanar formats which have proprietary padding requirements that are hard to accommodate in a more terse representation.
In many existing APIs, planes may be “downsampled” differently. For example, in these APIs, a Y′CBCR (colloquially YUV) 4:2:0 buffer as in Table 2 (with byte offsets shown for each channel/location) would typically be represented with three planes (Table 3), one for each channel, with the luma (Y′) plane containing four times as many pixels as the chroma (CB and CR) planes, and with two horizontal lines of the luma held within the same plane for each horizontal line of the chroma planes.
Table 2. Possible memory representation of a 4×4 Y′CBCR 4:2:0 buffer
Y′ channel | ||||||||||||||||
| ||||||||||||||||
CB channel | ||||||||||||||||
| ||||||||||||||||
CR channel | ||||||||||||||||
|
Table 3. Plane descriptors for the above Y′CBCR-format buffer in a conventional API
Y′ plane | offset 0 | byte stride 4 | downsample 1×1 |
CB plane | offset 16 | byte stride 2 | downsample 2×2 |
CR plane | offset 20 | byte stride 2 | downsample 2×2 |
This approach does not extend logically to more complex formats such as a Bayer grid. Therefore in this specification, we would instead define the luma channel as in Table 4, using two planes, vertically interleaved (in a linear mapping between addresses and samples) by the selection of a suitable offset and line stride, with each line of luma samples contiguous in memory. Only one plane is used for each of the chroma channels (or one plane collectively if the chroma samples are stored adjacently).
Table 4. Plane descriptors for the above Y′CBCR-format buffer using this standard
Y′ plane 1 | offset 0 | byte stride 8 | plane bytes 2 |
Y′ plane 2 | offset 4 | byte stride 8 | plane bytes 2 |
CB plane | offset 16 | byte stride 2 | plane bytes 1 |
CR plane | offset 20 | byte stride 2 | plane bytes 1 |
The same approach can be used to represent a static interlaced image, with a texel block consisting of two planes, one per field. This mechanism is all that is required to represent a static image without downsampled channels; however correct reconstruction of interlaced, downsampled color difference formats (such as Y′CBCR), which typically involves interpolation of the nearest chroma samples in a given field rather than the whole frame, is beyond the remit of this specification. There are many proprietary and often heuristic approaches to sample reconstruction, particularly for Bayer-like formats and for multi-frame images, and it is not practical to document them here.
There is no expectation that the internal format used by an API that wishes to make use of the Khronos Data Format Specification must use this specification’s representation internally: reconstructing downsampling information from this standard’s representation in order to revert to the more conventional representation should be trivial if required.
There is no requirement that the number of bytes occupied by the texel block be the same in each plane. The descriptor defines the number of bytes that the texel block occupies in each plane, which for most formats is sufficient to allow access to consecutive elements. For a two-dimensional data structure, it is up to the controlling interface to resolve byte stride between consecutive lines. For a three-dimensional structure, the controlling API may need to add a level stride. Since these strides are determined by the data size and architecture alignment requirements, they are not considered to be part of the format.
This specification encodes how atomic data should be interpreted in a manner which is independent of the layout and dimensionality of the collective data. Collections of data may have a “compatible format” in that their format descriptor may be identical, yet be different sizes. Some additional information is therefore expected to be recorded alongside the “format description”.
The API which controls the bulk data is responsible for controlling which memory location corresponds to the indexing mechanism chosen. A texel block has the concept of a coordinate offset within the block, which implies that if the data is accessed in terms of spatial coordinates, a texel block has spatial locality as well as referring to contiguous memory (per plane). For texel blocks which represent only a single spatial location, this is irrelevant; for block-based compression, for formats with downsampled channels, or for Bayer-like formats, the texel block represents a finite extent in up to four dimensions. However, the mapping from coordinate system to the memory location containing a texel block is beyond the control of this API.
The minimum requirements for accessing a linearly-addressed buffer is to store the start address and a stride (typically in bytes) between texels in each dimension of the buffer, for each plane contributing to the texel block. For the first dimension, the memory stride between texels may simply be the byte size of texel block in that plane — this implies that there are no gaps between texel blocks. For other dimensions, the stride is a function of the size of the data structure being represented — for example, in a compact representation of a two-dimensional buffer, the texel block at coordinate (x,y+1) might be found at the address of coordinate (x,y) plus the buffer width multiplied by the texel size in bytes. Similarly in a three-dimensional buffer, the address of the pixel at (x,y,z+1) may be at the address of (x,y,z) plus the byte size of a two-dimensional slice of the texture. In practice, even linear layouts may have padding, and often more complex relationships between coordinates and memory location are used to encourage locality of reference. The details of all of these data structures are beyond the remit of this specification.
Most simple formats contain a single plane of data. Those formats which require additional planes compared with a conventional representation are typically downsampled Y′CBCR formats, which already have the concept of separate storage for different color channels. While this specification uses multiple planes to describe texel blocks that span multiple scan lines if the data is disjoint, there is no expectation that the API using the data formats needs to maintain this representation — interleaved planes should be easy to identify and coalesce if the API requires a more conventional representation of downsampled formats.
Some image representations are composed of tiles of texels which are held contiguously in memory, with the texels within the tile stored in some order that improves locality of reference for multi-dimensional access. This is a common approach to improve memory efficiency when texturing. While it is possible to represent such a tile as a large texel block (up to the maximum representable texel block size in this specification), this is unlikely to be an efficient approach, since a large number of samples will be needed and the layout of a tile usually has a very limited number of possibilities. In most cases, the layout of texels within the tile should be described by whatever interface is aware of image-specific information such as size and stride, and only the format of the texels should be described by a format descriptor.
The complication to this is where texel blocks larger than a single pixel are themselves encoded using proprietary tiling. The spatial layout of samples within a texel block is required to be fixed in the basic format descriptor — for example, if the texel block size is 2×2 pixels, the top left pixel might always be expected to be in the first byte in that texel block. In some proprietary memory tiling formats, such as ones that store small rectangular blocks in raster order in consecutive bytes or in Morton order, this relationship may be preserved, and the only proprietary operation is finding the start of the texel block. In other proprietary layouts such as Hilbert curve order, or when the texel block size does not divide the tiling size, a direct representation of memory may be impossible. In these cases, it is likely that this data format standard would be used to describe the data as it would be seen in a linear format, and the mapping from coordinates to memory would have to be hidden in proprietary translation. As a logical format description, this is unlikely to be critical, since any software which accesses such a layout will necessarily need proprietary knowledge anyway.
The data format container described here is too unwieldy to be expected to be used directly in most APIs. The expectation is that APIs and users will define data descriptors in memory, but have API-specific names for the formats that the API supports. If these names are enumeration values, a mapping can be provided by having an array of pointers to the data descriptors, indexed by the enumeration. It may commonly be necessary to provide API-specific supplementary information in the same array structure, particularly where the API natively associates concepts with the data which is not uniquely associated with the content.
In this approach, it is likely that an API would predefine a number of common data formats which are natively supported. If there is a desire to support dynamic creation of data formats, this array could be made extensible with a manager returning handles.
Even where an API supports only a fixed set of formats, it is flexible to provide a comparison with user-provided format descriptors in order to establish whether a format is compatible.
The layout of the data structures described here are assumed to be little-endian for the purposes of data transfer, but may be implemented in the natural endianness of the platform for internal use.
The data format descriptor consists of a contiguous area of memory, as shown in Table 5, divided into one or more descriptor blocks, which are tagged by the type of descriptor that they contain. The size of the data format descriptor varies according to its content.
Table 5. Data Format Descriptor layout
| totalSize |
Descriptor block | First descriptor |
Descriptor block | Second descriptor (optional) etc. |
The totalSize field, measured in bytes, allows the full format descriptor
to be copied without need for details of the descriptor to be interpreted.
totalSize includes its own uint32_t, not just the following
descriptor blocks.
For example, we will see below that a four-sample Khronos Basic
Data Format Descriptor Block occupies 88 bytes; if there are no
other descriptor blocks in the data format descriptor, the totalSize
field would then indicate 88 + 4 bytes (for the totalSize field
itself) for a final value of 92.
Each Descriptor Block has the same prefix, shown in Table 6.
Table 6. Descriptor Block layout
| vendorId | (descriptorType << 16) |
| versionNumber | (descriptorBlockSize << 16) |
Format-specific data | |
The vendorId is a 16-bit value uniquely assigned to organisations, allocated by Khronos; ID 0 is used to identify Khronos itself. The ID 0xFFFF is reserved for internal use which is guaranteed not to clash with third-party implementations; this ID should not be shipped in libraries to avoid conflicts with development code.
The descriptorType is a unique identifier defined by the vendor to distinguish between potential data representations.
The versionNumber is vendor-defined, and is intended to allow for backwards-compatible updates to existing descriptor blocks.
The descriptorBlockSize indicates the size in bytes of this Descriptor Block, remembering that there may be multiple Descriptor Blocks within one container, as shown in Table 7. The descriptorBlockSize therefore gives the offset between the start of the current Descriptor Block and the start of the next — so the size includes the vendorId, descriptorType, versionNumber and descriptorBlockSize fields, which collectively contribute 8 bytes.
Having an explicit descriptorBlockSize allows implementations to skip a descriptor block whose format is unknown, allowing known data to be interpreted and unknown information to be ignored. Some descriptor block types may not be of a uniform size, and may vary according to the content within.
This specification initially describes only one type of descriptor block. Future revisions may define additional descriptor block types for additional applications — for example, to describe data with a large number of channels or pixels described in an arbitrary color space. Vendors can also implement proprietary descriptor blocks to hold vendor-specific information within the standard Descriptor.
Table 7. Data format descriptor header and descriptor block headers
totalSize | |||
| |||
|
One basic descriptor block, shown in Table 8 is intended to cover a large amount of metadata that is typically associated with common bulk data — most notably image or texture data. While this descriptor contains more information about the data interpretation than is needed by many applications, having a relatively comprehensive descriptor reduces the risk that metadata needed by different APIs will be lost in translation.
The format is described in terms of a repeating axis-aligned texel block composed of samples. Each sample contains a single channel of information with a single spatial offset within the texel block, and consists of an amount of contiguous data. This descriptor block consists of information about the interpretation of the texel block as a whole, supplemented by a description of a number of samples taken from one or more planes of contiguous memory. For example, a 24-bit red/green/blue format may be described as a 1×1 pixel region, containing three samples, one of each color, in one plane. A Y′CBCR 4:2:0 format may consist of a repeating 2×2 region consisting of four Y′ samples and one sample each of CB and CR.
Table 8. Basic Data Format Descriptor layout
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 24 + 16 × #samples (descriptorBlockSize) | ||
colorModel | colorPrimaries | transferFunction | flags |
texelBlockDimension0 | texelBlockDimension1 | texelBlockDimension2 | texelBlockDimension3 |
bytesPlane0 | bytesPlane1 | bytesPlane2 | bytesPlane3 |
bytesPlane4 | bytesPlane5 | bytesPlane6 | bytesPlane7 |
Sample information for first sample | |||
Sample information for second sample (optional), etc. | |||
The fields of the Basic Data Format Descriptor Block are described in the following sections.
The vendorId for the Basic Data Format Descriptor Block is 0,
defined as KHR_DF_VENDORID_KHRONOS in the enum khr_df_vendorid_e.
The descriptorType for the Basic Data Format Descriptor Block is 0,
a value reserved in the enum of Khronos-specific descriptor types,
khr_df_khr_descriptortype_e, as KHR_DF_KHR_DESCRIPTORTYPE_BASICFORMAT.
The versionNumber relating to the Basic Data Format Descriptor Block as described in this specification is 0.
The size of the Basic Data Format Descriptor Block depends on the number of samples contained within it. The memory requirements for this format are 24 bytes of shared data plus 16 bytes per sample. The descriptorBlockSize is measured in bytes.
The colorModel determines the set of color (or other data) channels which may be encoded within the data, though there is no requirement that all of the possible channels from the colorModel be present. Most data fits into a small number of common color models, but compressed texture formats each have their own color model enumeration. Note that the data need not actually represent a color — this is just the most common type of content using this descriptor. Some standards use color container for this concept.
The available color models are described in the khr_df_model_e enumeration,
and are represented as an unsigned 8-bit value.
Note that the numbering of the component channels is chosen such that those channel types which are common across multiple color models have the same enumeration value. That is, alpha is always encoded as channel ID 15, depth is always encoded as channel ID 14, and stencil is always encoded as channel ID 13. Luma/Luminance is always in channel ID 0. This numbering convention is intended to simplify code which can process a range of color models. Note that there is no guarantee that models which do not support these channels will not use this channel ID. Particularly, RGB formats do not have luma in channel 0, and a 16-channel undefined format is not obligated to represent alpha in any way in channel number 15.
The value of each enumerant is shown in parentheses following the enumerant name.
When the data format is unknown or does not fall into a predefined category, utilities which perform automatic conversion based on an interpretation of the data cannot operate on it. This format should be used when there is no expectation of portable interpretation of the data using only the basic descriptor block.
For portability reasons, it is recommended that pixel-like formats
with up to sixteen channels, but which cannot have those channels
described in the basic block, be represented with a basic descriptor
block with the appropriate number of samples from UNSPECIFIED channels,
and then for the channel description to be stored in an extension block.
This allows software which understands only the basic descriptor to
be able to perform operations that depend only on channel location,
not channel interpretation (such as image cropping). For example, a
camera may store a raw format taken with a modified Bayer sensor,
with RGBW (red, green, blue and white) sensor sites, or RGBE
(red, green, blue and “emerald”). Rather than trying to encode the
exact color coordinates of each sample in the basic descriptor,
these formats could be represented by a four-channel UNSPECIFIED
model, with an extension block describing the interpretation of
each channel.
This color model represents additive colors of three channels, nominally red, green and blue, supplemented by channels for alpha, depth and stencil, as shown in Table 9. Note that in many formats, depth and stencil are stored in a completely independent buffer, but there are formats for which integrating depth and stencil with color data makes sense.
Table 9. Basic Data Format RGBSDA channels
| Channel number | Name | Description | |
|---|---|---|---|
0 | | Red | |
1 | | Green | |
2 | | Blue | |
13 | | Stencil | |
14 | | Depth | |
15 | | Alpha (opacity) | |
Portable representation of additive colors with more than three primaries requires an extension to describe the full color space of the channels present. There is no practical way to do this portably without taking significantly more space.
This color model represents color differences with three channels, nominally luma (Y′) and two color-difference chroma channels, U (CB) and V (CR), supplemented by channels for alpha, depth and stencil, as shown in Table 10. These formats are distinguished by CB and CR being a delta between the Y′ channel and the blue and red channels respectively, rather than requiring a full color matrix. The conversion between Y′CBCR and RGB color spaces is defined in this case by the choice of value in the colorPrimaries field.
![[Note]](images/icons/note.png){kind=icon} | |
Most single-channel luma/luminance monochrome data formats should
select |
Table 10. Basic Data Format YUVSDA channels
| Channel number | Name | Description | |
|---|---|---|---|
0 | | Y/Y′ (luma/luminance) | |
1 | | CB (alias for U) | |
1 | | U (alias for CB) | |
2 | | CR (alias for V) | |
2 | | V (alias for CR) | |
13 | | Stencil | |
14 | | Depth | |
15 | | Alpha (opacity) | |
| |
Terminology for this color model is often abused. This model is based on the idea of creating a representation of monochrome light intensity as a weighted average of color channels, then calculating color differences by subtracting two of the color channels from this monochrome value. Proper names vary for each variant of the ensuing numbers, but YUV is colloquially used for all of them. In the television standards from which this terminology is derived, Y′CBCR is more formally used to describe the representation of these color differences. |
This color model represents color differences with three channels, nominally luma (Y) and two color-difference chroma channels, I and Q, supplemented by channels for alpha, depth and stencil, as shown in Table 11. This format is distinguished by I and Q each requiring all three additive channels to evaluate. I and Q are derived from CB and CR by a 33-degree rotation.
Table 11. Basic Data Format YIQSDA channels
| Channel number | Name | Description | |
|---|---|---|---|
0 | | Y (luma) | |
1 | | I (in-phase) | |
2 | | Q (quadrature) | |
13 | | Stencil | |
14 | | Depth | |
15 | | Alpha (opacity) | |
This color model represents the ICC perceptually-uniform L*a*b* color space, combined with the option of an alpha channel, as shown in Table 12.
Table 12. Basic Data Format LABSDA channels
| Channel number | Name | Description | |
|---|---|---|---|
0 | | L* (luma) | |
1 | | a* | |
2 | | b* | |
13 | | Stencil | |
14 | | Depth | |
15 | | Alpha (opacity) | |
This color model represents secondary (subtractive) colors and the combined key (black) channel, along with alpha, as shown in Table 13.
Table 13. Basic Data Format CMYKA channels
| Channel number | Name | Description | |
|---|---|---|---|
0 | | Cyan | |
1 | | Magenta | |
2 | | Yellow | |
3 | | Key/Black | |
15 | | Alpha (opacity) | |
This “color model” represents channel data used for coordinate values, as shown in Table 14 — for example, as a representation of the surface normal in a bump map. Additional channels for higher-dimensional coordinates can be used by extending the channel number within the 4-bit limit of the channelType field.
Table 14. Basic Data Format XYZW channels
| Channel number | Name | Description | |
|---|---|---|---|
0 | | X | |
1 | | Y | |
2 | | Z | |
3 | | W | |
This color model represents color differences with three channels, value (luminance or luma), saturation (distance from monochrome) and hue (dominant wavelength), supplemented by an alpha channel, as shown in Table 15. In this model, the hue relates to the angular offset on a color wheel.
Table 15. Basic Data Format angular HSVA channels
| Channel number | Name | Description | |
|---|---|---|---|
0 | | V (value) | |
1 | | S (saturation) | |
2 | | H (hue) | |
15 | | Alpha (opacity) | |
This color model represents color differences with three channels, lightness (maximum intensity), saturation (distance from monochrome) and hue (dominant wavelength), supplemented by an alpha channel, as shown in Table 16. In this model, the hue relates to the angular offset on a color wheel.
Table 16. Basic Data Format angular HSLA channels
| Channel number | Name | Description | |
|---|---|---|---|
0 | | L (lightness) | |
1 | | S (saturation) | |
2 | | H (hue) | |
15 | | Alpha (opacity) | |
This color model represents color differences with three channels, value (luminance or luma), saturation (distance from monochrome) and hue (dominant wavelength), supplemented by an alpha channel, as shown in Table 17. In this model, the hue is generated by interpolation between extremes on a color hexagon.
Table 17. Basic Data Format hexagonal HSVA channels
| Channel number | Name | Description | |
|---|---|---|---|
0 | | V (value) | |
1 | | S (saturation) | |
2 | | H (hue) | |
15 | | Alpha (opacity) | |
This color model represents color differences with three channels, lightness (maximum intensity), saturation (distance from monochrome) and hue (dominant wavelength), supplemented by an alpha channel, as shown in Table 18. In this model, the hue is generated by interpolation between extremes on a color hexagon.
Table 18. Basic Data Format hexagonal HSLA channels
| Channel number | Name | Description | |
|---|---|---|---|
0 | | L (lightness) | |
1 | | S (saturation) | |
2 | | H (hue) | |
15 | | Alpha (opacity) | |
This color model represents low-cost approximate color differences with three channels, nominally luma (Y) and two color-difference chroma channels, Cg (green/purple color difference) and Co (orange/cyan color difference), supplemented by a channel for alpha, as shown in Table 19.
Table 19. Basic Data Format YCoCgA channels
| Channel number | Name | Description | |
|---|---|---|---|
0 | | Y | |
1 | | Cg | |
2 | | Co | |
15 | | Alpha (opacity) | |
A number of compressed formats are supported as part of khr_df_model_e.
In general, these formats will have the texel block dimensions of the
compression block size. Most contain a single sample of channel type 0
at offset 0,0 — where further samples are required, they should also
be sited at 0,0. By convention, models which have multiple channels that
are disjoint in memory have these channel locations described accurately.
The ASTC family of formats have a number of possible channels, and are distinguished by samples which reference some set of these channels. The texelBlockDimension fields determine the compression ratio for ASTC.
Floating-point compressed formats have lower and upper limits specified
in floating point format. Integer compressed formats with a lower and
upper of 0 and UINT32_MAX (for unsigned formats) or INT32_MIN
and INT32_MAX (for signed formats) are assumed to map the full
representable range to 0..1 or -1..1 respectively.
This model represents the DXT1 or BC1 format. Channel 0 indicates color. If a second sample is present it should use channel 1 to indicate that the “special value” of the format should represent transparency — otherwise the “special value” represents opaque black.
This model represents the DXT2/3 format, also described as BC2. The alpha premultiplication state (the distinction between DXT2 and DXT3) is recorded separately in the descriptor. This model has two channels: ID 0 contains the color information and ID 15 contains the alpha information. The alpha channel is 64 bits and at offset 0; the color channel is 64 bits and at offset 64. No attempt is made to describe the 16 alpha samples for this position independently, since understanding the other channels for any pixel requires the whole texel block.
This model represents the DXT4/5 format, also described as BC3. The alpha premultiplication state (the distinction between DXT4 and DXT5) is recorded separately in the descriptor. This model has two channels: ID 0 contains the color information and ID 15 contains the alpha information. The alpha channel is 64 bits and at offset 0; the color channel is 64 bits and at offset 64.
This model represents the Direct3D BC4 format for single-channel interpolated 8-bit data. The model has a single channel of id 0 with offset 0 and length 64 bits.
This model represents the Direct3D BC5 format for dual-channel interpolated 8-bit data. The model has two channels, 0 (red) and 1 (green), which should have their bit depths and offsets independently described: the red channel has offset 0 and length 64 bits and the green channel has offset 64 and length 64 bits.
This model represents the Direct3D BC6H format for RGB floating-point data. The model has a single channel 0, representing all three channels, and occupying 128 bits.
This model represents the Direct3D BC7 format for RGBA data. This model has a single channel 0 of 128 bits.
This model represents the original Ericsson Texture Compression format, with a guarantee that the format does not rely on ETC2 extensions. It contains a single channel of RGB data.
This model represents the updated Ericsson Texture Compression format, ETC2, and also the related R11 EAC and RG11 EAC formats. Channel ID 0 represents red, and is used for the R11 EAC format. Channel ID 1 represents green, and both red and green should be present for the RG11 EAC format. Channel ID 2 represents RGB combined content, for ETC2. Channel 15 indicates the presence of alpha. If the texel block size is 8 bytes and the RGB and alpha channels are co-sited, “punch through” alpha is supported. If the texel block size is 16 bytes and the alpha channel appears in the first 8 bytes, followed by 8 bytes for the RGB channel, 8-bit separate alpha is supported.
This model represents Adaptive Scalable Texture Compression as a single
channel in a texel block of 16 bytes. ASTC HDR (high dynamic range) and
LDR (low dynamic range) modes are distinguished by the channelId containing
the flag KHR_DF_SAMPLE_DATATYPE_FLOAT: an ASTC texture that is guaranteed by
the user to contain only LDR-encoded blocks should have the channelId
KHR_DF_SAMPLE_DATATYPE_FLOAT bit clear, and an ASTC texture that may include
HDR-encoded blocks should have the channelId KHR_DF_SAMPLE_DATATYPE_FLOAT
bit set to 1. ASTC supports a number of compression ratios defined by different
texel block sizes; these are selected by changing the texel block size fields
in the data format. The single sample has a size of 128 bits.
ASTC encoding is described in Section 18.
It is not sufficient to define a buffer as containing, for example,
additive primaries. Additional information is required to define
what “red” is provided by the “red” channel. A full definition of
primaries requires an extension which provides the full color space
of the data, but a subset of common primary spaces can be identified
by the khr_df_primaries_e enumeration, represented as an unsigned 8-bit
integer value.
This “set of primaries” identifies a data representation whose color representation is unknown or which does not fit into this list of common primaries. Having an “unspecified” value here precludes users of this data format from being able to perform automatic color conversion unless the primaries are defined in another way. Formats which require a proprietary color space — for example, raw data from a Bayer sensor that records the direct response of each filtered sample — can still indicate that samples represent “red”, “green” and “blue”, but should mark the primaries here as “unspecified” and provide a detailed description in an extension block.
This value represents the Color Primaries defined by the ITU-R BT.709 specification, which are also shared by sRGB.
RGB data is distinguished between BT.709 and sRGB by the Transfer Function. Conversion to and from BT.709 Y′CBCR (YUV) representation uses the color conversion matrix defined in the BT.709 specification. This is the preferred set of color primaries used by HDTV and sRGB, and likely a sensible default set of color primaries for common rendering operations.
KHR_DF_PRIMARIES_SRGB is provided as a synonym for KHR_DF_PRIMARIES_BT709.
This value represents the Color Primaries defined in the ITU-R BT.601 specification for standard-definition television, particularly for 625-line signals. Conversion to and from BT.601 Y′CBCR (YUV) typically uses the color conversion matrix defined in the BT.601 specification.
This value represents the Color Primaries defined in the ITU-R BT.601 specification for standard-definition television, particularly for 525-line signals. Conversion to and from BT.601 Y′CBCR (YUV) typically uses the color conversion matrix defined in the BT.601 specification.
This value represents the Color Primaries defined in the ITU-R BT.2020 specification for ultra-high-definition television. Conversion to and from BT.2020 Y′CBCR (YUV) uses the color conversion matrix defined in the BT.2020 specification.
This value represents the theoretical Color Primaries defined by the International Color Consortium for the ICC XYZ linear color space.
This value represents the Color Primaries defined for the Academy Color Encoding System.
Many color representations contain a non-linear transfer function
which maps between a linear (intensity-based) representation and
a more perceptually-uniform encoding.
Common transfer functions are represented as an unsigned 8-bit integer
and encoded in the enumeration khr_df_transfer_e.
A fully-flexible transfer function requires an extension with a full
color space definition.
Where the transfer function can be described as a simple power curve,
applying the function is commonly known as “gamma correction”.
The transfer function is applied to a sample only when the sample’s
KHR_DF_SAMPLE_DATATYPE_LINEAR bit is 0; if this bit is 1, the
sample is represented linearly irrespective of the transferFunction.
When a color model contains more than one channel in a sample and
the transfer function should be applied only to a subset of those
channels, the convention of that model should be used when applying
the transfer function. For example, ASTC stores both alpha and RGB
data but is represented by a single sample; in ASTC, any sRGB transfer
function is not applied to the alpha channel of the ASTC texture.
In this case, the KHR_DF_SAMPLE_DATATYPE_LINEAR bit being zero means that
the transfer function is “applied” to the ASTC sample in a way that only
affects the RGB channels. This is not a concern for most color models,
which explicitly store different channels in each sample.
If all the samples are linear, KHR_DF_TRANSFER_LINEAR should be used.
In this case, no sample should have the KHR_DF_SAMPLE_DATATYPE_LINEAR
bit set.
The enumerant value for each of the following transfer functions is shown in parentheses alongside the title.
This value should be used when the transfer function is unknown, or specified only in an extension block, precluding conversion of color spaces and correct filtering of the data values using only the information in the basic descriptor block.
This value represents a linear transfer function: for color data, there is a linear relationship between numerical pixel values and the intensity of additive colors. This transfer function allows for blending and filtering operations to be applied directly to the data values.
This value represents the non-linear transfer function defined in the sRGB specification for mapping between numerical pixel values and intensity.
That is, the conversion from linear $(R, G, B)$ encoding to nonlinear $(R', G', B')$ encoding is:
The corresponding conversion from nonlinear $(R', G', B')$ encoding to linear $(R, G, B)$ encoding is:
This value represents the non-linear transfer function defined by the ITU and used in the BT.601, BT.709 and BT.2020 specifications.
This value represents the non-linear transfer function defined by the original NTSC television broadcast specification.
| |
More recent formulations of this transfer functions, such as that defined in SMPTE 170M-2004, use it ITU formulation described above. |
This value represents a nonlinear Transfer Function used by some Sony video cameras to represent an increased dynamic range.
The format supports some configuration options in the form of
boolean flags; these are described in the enumeration
khr_df_flags_e and represented in an unsigned 8-bit integer value.
If the KHR_DF_FLAG_ALPHA_PREMULTIPLIED bit is set, any color
information in the data should be interpreted as having been
previously scaled by the alpha channel when performing blending
operations.
The value KHR_DF_FLAG_ALPHA_STRAIGHT (= 0) is provided
to represent this flag not being set, which indicates that the color
values in the data should be interpreted as needing to be scaled
by the alpha channel when performing blending operations. This flag
has no effect if there is no alpha channel in the format.
The texelBlockDimension fields define an integer bound on the range of coordinates covered by the repeating block described by the samples. Four separate values, represented as unsigned 8-bit integers, are supported, corresponding to successive dimensions. The Basic Data Format Descriptor Block supports up to four dimensions of encoding within a texel block, supporting, for example, a texture with three spatial dimensions and one temporal dimension. Nothing stops the data structure as a whole from having higher dimensionality: for example, a two-dimensional texel block can be used as an element in a six-dimensional look-up table.
The value held in each of these fields is one fewer than the size of the block in that dimension — that is, a value of 0 represents a size of 1, a value of 1 represents a size of 2, etc. A texel block which covers fewer than four dimensions should have a size of 1 in each dimension that it lacks, and therefore the corresponding fields in the representation should be 0.
For example, a Y′CBCR 4:2:0 representation may use a Texel Block of 2×2 pixels in the nominal coordinate space, corresponding to the four Y′ samples, as shown in Table 20. The texel block dimensions in this case would be 2×2×1×1 (in the X, Y, Z and T dimensions, if the fourth dimension is interpreted as T). The texelBlockDimension[0..3] values would therefore be:
Table 20. Example Basic Data Format texelBlockDimension values for Y′CBCR 4:2:0
texelBlockDimension0 | 1 |
texelBlockDimension1 | 1 |
texelBlockDimension2 | 0 |
texelBlockDimension3 | 0 |
The Basic Data Format Descriptor divides the image into a number of planes, each consisting of an integer number of consecutive bytes. The requirement that planes consist of consecutive data means that formats with distinct subsampled channels — such as Y′CBCR 4:2:0 — may require multiple planes to describe a channel. A typical Y′CBCR 4:2:0 image has two planes for the Y′ channel in this representation, offset by one line vertically.
The use of byte granularity to define planes is a choice to allow large texels (of up to 255 bytes). A consequence of this is that formats which are not byte-aligned on each addressable unit, such as 1-bit-per-pixel formats, need to represent a texel block of multiple samples, covering multiple texels.
A maximum of eight independent planes is supported in the Basic Data Format Descriptor. Formats which require more than eight planes — which are rare — require an extension.
The bytesPlane[0..7] fields each contain an unsigned 8-bit integer which represents the number of bytes which that plane contributes to the format. The first field which contains the value 0 indicates that only a subset of the 8 possible planes are present; that is, planes which are not present should be given the bytesPlane value of 0, and any bytesPlane values after the first 0 are ignored. If no bytesPlane value is zero, 8 planes are considered to exist.
As an exception, if bytesPlane0 has the value 0, the first plane is considered to hold indices into a color palette, which is described by one or more additional planes and samples in the normal way. The first sample in this case should describe a 1×1×1×1 texel holding an unsigned integer value. The number of bits used by the index should be encoded in this sample, with a maximum value of the largest palette entry held in sampleUpper. Subsequent samples describe the entries in the palette, starting at an offset of bit 0. Note that the texel block in the index plane is not required to be byte-aligned in this case, and will not be for paletted formats which have small palettes. The channel type for the index is irrelevant.
For example, consider a 5-color paletted texture which describes each of these colors using 8 bits of red, green, blue and alpha. The color model would be RGBSDA, and the format would be described with two planes. bytesPlane0 would be 0, indicating the special case of a palette, and bytesPlane1 would be 4, representing the size of the palette entry. The first sample would then have a number of bits corresponding to the number of bits for the palette — in this case, three bits, corresponding to the requirements of a 5-color palette. The sampleUpper value for this sample is 4, indicating only 5 palette entries. Four subsequent samples represent the red, green, blue and alpha channels, starting from bit 0 as though the index value were not present, and describe the contents of the palette. The full data format descriptor for this example is provided in Table 29 as one of the example format descriptors.
The layout and position of the information within each plane is determined by a number of samples, each consisting of a single channel of data and with a single corresponding position within the texel block, as shown in Table 21.
The bytes from the plane data contributing to the format are treated as though they have been concatenated into a bit stream, with the first byte of the lowest-numbered plane providing the lowest bits of the result. Each sample consists of a number of consecutive bits from this bit stream.
If the content for a channel cannot be represented in a single sample, for example because the data for a channel is non-consecutive within this bit stream, additional samples with the same coordinate position and channel number should follow from the first, in order increasing from the least significant bits from the channel data.
Note that some native big-endian formats may need to be supported with multiple samples in a channel, since the constituent bits may not be consecutive in a little-endian interpretation. There is an example, Table 31, in the list of format descriptors provided. In this case, the sampleLower and sampleUpper fields for the combined sample are taken from the first sample to belong uniquely to this channel/position pair.
By convention, to avoid aliases for formats, samples should be listed in order starting with channels at the lowest bits of this bit stream. Ties should be broken by increasing channel type id, as shown in Table 36.
The number of samples present in the format is determined by the descriptorBlockSize field. There is no limit on the number of samples which may be present, other than the maximum size of the Data Format Descriptor Block. There is no requirement that samples should access unique parts of the bit-stream: formats such as combined intensity and alpha, or shared exponent formats, require that bits be reused. Nor is there a requirement that all the bits in a plane be used (a format may contain padding).
Table 21. Basic Data Format Descriptor Sample Information
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
bitOffset | bitLength | channelType | |
samplePosition0 | samplePosition1 | samplePosition2 | samplePosition3 |
sampleLower | |||
sampleUpper | |||
The bitOffset field describes the offset of the least significant bit of this sample from the least significant bit of the least significant byte of the concatenated bit stream for the format. Typically the bitOffset of the first sample is therefore 0; a sample which begins at an offset of one byte relative to the data format would have a bitOffset of 8. The bitOffset is an unsigned 16-bit integer quantity.
The bitLength field describes the number of consecutive bits from the concatenated bit stream that contribute to the sample. This field is an unsigned 8-bit integer quantity, and stores the number of bits contributed minus 1; thus a single-byte channel should have a bitLength field value of 7. If a bitLength of more than 256 is required, further samples should be added; the value for the sample is composed in increasing order from least to most significant bit as subsequent samples are processed.
The channelType field is an unsigned 8-bit quantity.
The bottom four bits of the channelType indicates which channel is being described by this sample. The list of available channels is determined by the colorModel field of the Basic Data Format Descriptor Block, and the channelType field contains the number of the required channel within this list — see the colorModel field for the list of channels for each model.
The top four bits of the channelType are described by the
khr_df_sample_datatype_qualifiers_e enumeration:
If the KHR_DF_SAMPLE_DATATYPE_LINEAR bit is not set, the sample value is
modified by the transfer function defined in the format’s transferFunction
field; if this bit is set, the sample is considered to contain a
linearly-encoded value irrespective of the format’s transferFunction.
If the KHR_DF_SAMPLE_DATATYPE_EXPONENT bit is set, this sample holds an
exponent (in integer form) for this channel. For example, this would be
used to describe the shared exponent location in shared exponent formats
(with the exponent bits listed separately under each channel). An exponent
is applied to any integer sample of the same type. If this bit is not set,
the sample is considered to contain mantissa information. If the
KHR_DF_SAMPLE_DATATYPE_SIGNED bit is also set, the exponent is considered
to be two’s complement — otherwise it is treated as unsigned. The bias of
the exponent can be determined by the exponent’s sampleLower value. The
presence or absence of an implicit leading digit in the mantissa of a format
with an exponent can be determined by the sampleUpper value of the
mantissa.
If the KHR_DF_SAMPLE_DATATYPE_SIGNED bit is set, the sample holds a signed
value in two’s complement form. If this bit is not set, the sample holds
an unsigned value. It is possible to represent a sign/magnitude integer
value by having a sample of unsigned integer type with the same channel
and sample location as a 1-bit signed sample.
If the KHR_DF_SAMPLE_DATATYPE_FLOAT bit is set, the sample holds floating
point data in a conventional format of 10, 11 or 16 bits, as described in
Section 10, or of 32, or 64 bits as described in [IEEE 754]. Unless
a genuine unsigned format is intended, KHR_DF_SAMPLE_DATATYPE_SIGNED should
be set. Less common floating point representations can be generated with
multiple samples and a combination of signed integer, unsigned integer and
exponent fields, as described above and in Section 10.4.
The sample has an associated location within the 4-dimensional space of the texel block. Each sample has an offset relative to the 0,0 position of the texel block, determined in units of half a coordinate. This allows the common situation of downsampled channels to have samples conceptually sited at the midpoint between full resolution samples. Support for offsets other than multiples of a half coordinates require an extension. The direction of the sample offsets is determined by the coordinate addressing scheme used by the API. There is no limit on the dimensionality of the data, but if more than four dimensions need to be contained within a single texel block, an extension will be required.
Each samplePosition is an 8-bit unsigned integer quantity. samplePosition0 is the X offset of the sample, samplePosition1 is the Y offset of the sample, etc. Formats which use an offset larger than 127.5 in any dimension require an extension.
It is legal, but unusual, to use the same bits to represent multiple samples at different coordinate locations.
sampleLower, combined with sampleUpper, is used to represent the mapping between the numerical value stored in the format and the conceptual numerical interpretation. For unsigned formats, sampleLower typically represents the value which should be interpreted as zero (the black point). For signed formats, sampleLower typically represents “-1”. For color difference models such as Y′CBCR, sampleLower represents the lower extent of the color difference range (which corresponds to an encoding of -0.5 in numerical terms).
If the channel encoding is an integer format, the sampleLower value is represented as a 32-bit integer — signed or unsigned according to whether the channel encoding is signed. Signed negative values should be sign-extended if the channel has fewer than 32 bits, such that the value encoded in sampleLower is itself negative. If the channel encoding is a floating point value, the sampleLower value is also floating point. If the number of bits in the sample is greater than 32, the lowest representable value for sampleLower is interpreted as the smallest value representable in the channel format.
If the channel consists of multiple co-sited integer samples, for example because the channel bits are non-contiguous, there are two possible behaviors. If the total number of bits in the channel is less than or equal to 32, the sampleLower values in the samples corresponding to the least-significant bits of the sample are ignored, and only the sampleLower from the most-significant sample is considered. If the number of bits in the channel exceeds 32, the sampleLower values from the sample corresponding to the most-significant bits within any 32-bit subset of the total number are concatenated to generate the final sampleLower value. For example, a 48-bit signed integer may be encoded in three 16-bit samples. The first sample, corresponding to the least-significant 16 bits, will have its sampleLower value ignored. The next sample of 16 bits takes the total to 32, and so the sampleLower value of this sample should represent the lowest 32 bits of the desired 48-bit virtual sampleLower value. Finally, the third sample indicates the top 16 bits of the 48-bit channel, and its sampleLower contains the top 16 bits of the 48-bit virtual sampleLower value.
The sampleLower value for an exponent should represent the exponent bias — the value that should be subtracted from the encoded exponent to indicate that the mantissa’s sampleUpper value will represent 1.0. See Section 10.4 for more detail on this.
For example, the BT.709 television broadcast standard dictates that the Y′ value stored in an 8-bit encoding should fall between the range 16 and 235. In this case, sampleLower should contain the value 16.
In OpenGL terminology, a “normalized” channel contains an integer value which is mapped to the range 0..1.0. A channel which is not normalized contains an integer value which is mapped to a floating point equivalent of the integer value. Similarly an “snorm” channel is a signed normalized value mapping from -1.0 to 1.0. Setting sampleLower to the minimum signed integer value representable in the channel is equivalent to defining an “snorm” texture.
sampleUpper, combined with sampleLower, is used to represent the mapping between the numerical value stored in the format and the conceptual numerical interpretation. sampleUpper typically represents the value which should be interpreted as “1.0” (the “white point”). For color difference models such as Y′CBCR, sampleUpper represents the upper extent of the color difference range (which corresponds to an encoding of 0.5 in numerical terms).
If the channel encoding is an integer format, the sampleUpper value is represented as a 32-bit integer — signed or unsigned according to whether the channel encoding is signed. If the channel encoding is a floating point value, the sampleUpper value is also floating point. If the number of bits in the sample is greater than 32, the highest representable value for sampleUpper is interpreted as the largest value representable in the channel format. If the channel encoding is the mantissa of a custom floating point format (that is, the encoding is integer but the same sample location and channel is shared by a sample that encodes an exponent), the presence of an implicit “1” digit can be represented by setting the sampleUpper value to a value one larger than can be encoded in the available bits for the mantissa, as described in Section 10.4.
The sampleUpper value for an exponent should represent the largest conventional legal exponent value. If the encoded exponent exceeds this value, the encoded floating point value encodes either an infinity or a NaN value, depending on the mantissa. See Section 10.4 for more detail on this.
If the channel consists of multiple co-sited integer samples, for example because the channel bits are non-contiguous, there are two possible behaviors. If the total number of bits in the channel is less than or equal to 32, the sampleUpper values in the samples corresponding to the least-significant bits of the sample are ignored, and only the sampleUpper from the most-significant sample is considered. If the number of bits in the channel exceeds 32, the sampleUpper values from the sample corresponding to the most-significant bits within any 32-bit subset of the total number are concatenated to generate the final sampleUpper value. For example, a 48-bit signed integer may be encoded in three 16-bit samples. The first sample, corresponding to the least-significant 16 bits, will have its sampleUpper value ignored. The next sample of 16 bits takes the total to 32, and so the sampleUpper value of this sample should represent the lowest 32 bits of the desired 48-bit virtual sampleUpper value. Finally, the third sample indicates the top 16 bits of the 48-bit channel, and its sampleUpper contains the top 16 bits of the 48-bit virtual sampleUpper value.
For example, the BT.709 television broadcast standard dictates that the Y′ value stored in an 8-bit encoding should fall between the range 16 and 235. In this case, sampleUpper should contain the value 235.
In OpenGL terminology, a “normalized” channel contains an integer value which is mapped to the range 0..1.0. A channel which is not normalized contains an integer value which is mapped to a floating point equivalent of the integer value. Similarly an “snorm” channel is a signed normalized value mapping from -1.0 to 1.0. Setting sampleUpper to the maximum signed integer value representable in the channel for a signed channel type is equivalent to defining an “snorm” texture. Setting sampleUpper to the maximum unsigned value representable in the channel for an unsigned channel type is equivalent to defining a “normalized” texture. Setting sampleUpper to “1” is equivalent to defining an “unnormalized” texture.
Sensor data from a camera typically does not cover the full range of the bit depth used to represent it. sampleUpper can be used to specify an upper limit on sensor brightness — or to specify the value which should map to white on the display, which may be less than the full dynamic range of the captured image.
There is no guarantee or expectation that image data be guaranteed to fall between sampleLower and sampleUpper unless the users of a format agree that convention.
Some formats will require more channels than can be described in the Basic Format Descriptor, or may have more specific color requirements. For example, it is expected than an extension will be available which places an ICC color profile block into the descriptor block, allowing more color channels to be specified in more precise ways. This will significantly enlarge the space required for the descriptor, and is not expected to be needed for most common uses. A vendor may also use an extension block to associate metadata with the descriptor — for example, information required as part of hardware rendering. So long as software which uses the data format descriptor always uses the totalSize field to determine the size of the descriptor, this should be transparent to user code.
The extension mechanism is the preferred way to support even simple extensions such as additional color spaces transfer functions that can be supported by an additional enumeration. This approach improves compatibility with code which is unaware of the additional values. Simple extensions of this form that have cross-vendor support have a good chance of being incorporated more directly into future revisions of the specification, allowing application code to distinguish them by the versionId field.
As an example, consider a single-channel 32-bit depth buffer, as shown in Table 22. A tiled renderer may wish to indicate that this buffer is “virtual”: it will be allocated real memory only if needed, and will otherwise exist only a subset at a time in an on-chip representation. Someone developing such a renderer may choose to add a vendor-specific extension (with ID 0xFFFF to indicate development work and avoid the need for a vendor ID) which uses a boolean to establish whether this depth buffer exists only in virtual form. Note that the mere presence or absence of this extension within the data format descriptor itself forms a boolean, but for this example we will assume that an extension block is always present, and that a boolean is stored within. We will give the enumeration 32 bits, in order to simplify the possible addition of further extensions.
In this example (which should not be taken as an implementation suggestion), the data descriptor would first contain a descriptor block describing the depth buffer format as conventionally described, followed by a second descriptor block that contains only the enumeration. The descriptor itself has a totalSize that includes both of these descriptor blocks.
Table 22. Example of a depth buffer with an extension to indicate a virtual allocation
56 (totalSize: total size of the two blocks plus one 32-bit value)
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
It is possible for a vendor to use the extension block to store peripheral information required to access the image — plane base addresses, stride, etc. Since different implementations have different kinds of non-linear ordering and proprietary alignment requirements, this is not described as part of the standard. By many conventional definitions, this information is not part of the “format”, and particularly it ensures that an identical copy of the image will have a different descriptor block (because the addresses will have changed) and so a simple bitwise comparison of two descriptor blocks will disagree even though the “format” matches. Additionally, many APIs will use the format descriptor only for external communication, and have an internal representation that is more concise and less flexible. In this case, it is likely that address information will need to be represented separately from the format anyway. For these reasons, it is an implementation choice whether to store this information in an extension block, and how to do so, rather than being specified in this standard..
While it is not expected that every new container will have a unique data descriptor or that analysis of the data format descriptor will be on a critical path in an application, it is still expected that comparison between formats may be time-sensitive. The data format descriptor is designed to allow relatively efficient queries for subsets of properties, to allow a large number of format descriptors to be stored, and to be amenable to hardware interpretation or processing in shaders. These goals preclude a text-based representation such as an XML schema.
Formats in FourCC.org do not describe in detail sufficient information for many APIs, and are sometimes inconsistent.
Enumerations are fast and easy to process, but are limited in that any software can only be aware of the enumeration values in place when it was defined. Software often behaves differently according to properties of a format, and must perform a look-up on the enumeration — if it knows what it is — in order to change behaviors. A descriptive format allows for more flexible software which can support a wide range of formats without needing each to be listed, and simplifies the programming of conditional behavior based on format properties.
Khronos supports multiple standards that have a range of internal data representations. There is no requirement that this standard be used specifically with other Khronos standards, but it is hoped that multiple Khronos standards may use this specification as part of a consistent approach to inter-standard operation.
While a library may not use all the data provided in the data format descriptor that is described within this standard, it is common for users of data — particularly pixel-like data — to have additional requirements. Capturing these requirements portably reduces the need for additional metadata to be associated with a proprietary descriptor. It is also common for additional functionality to be added retrospectively to existing libraries — for example, Y′CBCR support is often an afterthought in rendering APIs. Having a consistent and flexible representation in place from the start can reduce the pain of retrofitting this functionality.
Note that there is no expectation that the format descriptor from this standard be used directly, although it can be. The impact of providing a mapping between internal formats and format descriptors is expected to be low, but offers the opportunity both for simplified access from software outside the proprietary library and for reducing the effort needed to provide a complete, unambiguous and accurate description of a format in human-readable terms.
There is a trade-off between size and decoding effort. It is assumed that data which occupies the same 32-bit word may need to be tested concurrently, reducing the cost of comparisons. When transferring data formats, the packing reduces the overhead. Within these constraints, it is intended that most data can be extracted with low-cost operations, typically being byte-aligned (other than sample flags) and with the natural alignment applied to multi-byte quantities.
For simple ASCII content, there is no reason that plain text could not be described in some way, and this may be useful for image formats that contain comment sections. However, since many multilingual text representations do not have a fixed character size, this use is not seen as an obvious match for this standard.
Some common floating-point numeric representations are defined in [IEEE 754]. Additional floating point formats are defined in this section.
A 16-bit floating-point number has a 1-bit sign (S), a 5-bit exponent (E), and a 10-bit mantissa (M). The value V of a 16-bit floating-point number is determined by the following:
If the floating-point number is interpreted as an unsigned 16-bit integer N, then
An unsigned 11-bit floating-point number has no sign bit, a 5-bit exponent (E), and a 6-bit mantissa (M). The value V of an unsigned 11-bit floating-point number is determined by the following:
If the floating-point number is interpreted as an unsigned 11-bit integer N, then
An unsigned 10-bit floating-point number has no sign bit, a 5-bit exponent (E), and a 5-bit mantissa (M). The value V of an unsigned 10-bit floating-point number is determined by the following:
If the floating-point number is interpreted as an unsigned 10-bit integer N, then
Rather than attempting to enumerate every possible floating-point
format variation in this specification, the data format descriptor
can be used to describe the components of arbitrary floating-point
data, as follows. Note that non-standard floating point formats do
not use the KHR_DF_SAMPLE_DATATYPE_FLOAT bit.
An example of use of the 16-bit floating point format described in Section 10.1 but described in terms of a custom floating point format is provided in Table 38. Note that this is provided for example only, and this particular format would be better described using the standard 16-bit floating point format as documented in Table 39.
The mantissa of a custom floating point format should be represented
as an integer channelType. If the mantissa represents a signed
quantity encoded in two’s complement, the KHR_DF_SAMPLE_DATATYPE_SIGNED
bit should be set. To encode a signed mantissa represented in
sign-magnitude format, the main part of the mantissa should be
represented as an unsigned integer quantity (with
KHR_DF_SAMPLE_DATATYPE_SIGNED not set), and an additional one-bit
sample with KHR_DF_SAMPLE_DATATYPE_SIGNED set should be used
to identify the sign bit. By convention, a sign bit should be encoded
in a later sample than the corresponding mantissa.
The sampleUpper and sampleLower values for the mantissa should be set to indicate the representation of 1.0 and 0.0 (for unsigned formats) or -1.0 (for signed formats) respectively when the exponent is in a 0 position after any bias has been corrected. If there is an implicit “1” bit, these values for the mantissa will exceed what can be represented in the number of available mantissa bits.
For example, the shared exponent formats shown in Table 32 does not have an implicit “1” bit, and therefore the sampleUpper values for the 9-bit mantissas are 256 — this being the mantissa value for 1.0 when the exponent is set to 0.
For the 16-bit signed floating point format described in Section 10.1, sampleUpper should be set to 1024, indicating the implicit “1” bit which is above the 10 bits representable in the mantissa. sampleLower should be 0 in this case, since the mantissa uses a sign-magnitude representation.
By convention, the sampleUpper and sampleLower values for a sign bit are 0 and -1 respectively.
The KHR_DF_SAMPLE_DATATYPE_EXPONENT bit should be set in a sample
which contains the exponent of a custom floating point format.
The sampleLower for the exponent should indicate the exponent bias. That is, the mantissa should be scaled by two raised to the power of the stored exponent minus this sampleLower value.
The sampleUpper for the exponent indicates the maximum legal exponent value. Values above this are used to encode infinities and not-a-number (NaN) values. sampleUpper can therefore be used to indicate whether or not the format supports these encodings.
Floating point values encoded with an exponent of 0 (before bias) and a mantissa of 0 are used to represent the value 0. An explicit sign bit can distinguish between +0 and -0.
Floating point values encoded with an exponent of 0 (before bias) and a non-zero mantissa are assumed to indicate a denormalized number, if the format has an implicit “1” bit. That is, when the exponent is 0, the “1” bit becomes explicit and the exponent is considered to be the negative sample bias minus one.
Floating point values encoded with an exponent larger than the exponent’s sampleUpper value and with a mantissa of 0 are interpreted as representing +/- infinity, depending on the value of an explicit sign bit. Note that in some formats, no exponent above sampleUpper is possible — for example, Table 32.
Floating point values encoded with an exponent larger than the exponent’s sampleUpper value and with a mantissa of non-0 are interpreted as representing not-a-number (NaN).
Note that these interpretations are compatible with the corresponding numerical representations in [IEEE 754].
Given an optional sign bit S, a mantissa value of M and an exponent value of E, a format with an implicit “1” bit can be converted from its representation to a real value as follows:
If there is no implicit “1” bit (that is, the sampleUpper value of the mantissa is representable in the number of bits assigned to the mantissa), the value can be converted to a real value as follows:
A descriptor block for a format without an implicit “1” (and with the added complication of having the same exponent bits shared across multiple channels, which is why an implicit “1” bit does not make sense) is shown in Table 32. In the case of this particular example, the above equations simplify to:
Where:
Note that in general conversion from a real number to any representation may require rounding, truncation and special value management rules which are beyond the scope of a data format specification and may be documented in APIs which generate these formats.
Table 23. Four co-sited 8-bit sRGB channels, assuming premultiplied alpha
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
92 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 88 (descriptorBlockSize) | ||
|
|
|
|
0 (texelBlockDimension0) | 0 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
4 (bytesPlane0) | 0 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the first sample | |||
0 (bitOffset) | 7 (= “8”) (bitLength) | 0 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Sample information for the second sample | |||
8 (bitOffset) | 7 (= “8”) (bitLength) | 1 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Sample information for the third sample | |||
16 (bitOffset) | 7 (= “8”) (bitLength) | 2 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Sample information for the fourth sample | |||
24 (bitOffset) | 7 (= “8”) (bitLength) | 31 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Table 24. 565 RGB packed 16-bit format as written to memory by a little-endian architecture
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
76 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 72 (descriptorBlockSize) | ||
|
|
|
|
0 (texelBlockDimension0) | 0 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
2 (bytesPlane0) | 0 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the first sample: 5 bits of blue | |||
0 (bitOffset) | 4 (= “5”) (bitLength) | 2 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
31 (sampleUpper) | |||
Sample information for the second sample: 6 bits of green | |||
5 (bitOffset) | 5 (= “6”) (bitLength) | 1 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
63 (sampleUpper) | |||
Sample information for the third sample: 5 bits of red | |||
11 (bitOffset) | 4 (= “5”) (bitLength) | 0 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
31 (sampleUpper) | |||
Table 25. A single 8-bit monochrome channel
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
44 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 40 (descriptorBlockSize) | ||
|
|
|
|
0 (texelBlockDimension0) | 0 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
4 (bytesPlane0) | 0 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the first sample | |||
0 (bitOffset) | 7 (= “8”) (bitLength) | 0 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Table 26. A single 1-bit monochrome channel, as an 8×1 texel block to allow byte-alignment, part 1 of 2
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
156 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 152 (descriptorBlockSize) | ||
|
|
|
|
7 (texelBlockDimension0) | 0 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
1 (bytesPlane0) | 0 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the first sample | |||
0 (bitOffset) | 0 (= “1”) (bitLength) | 0 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
1 (sampleUpper) | |||
Sample information for the second sample | |||
1 (bitOffset) | 0 (= “1”) (bitLength) | 0 (channelType) ( | |
2 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
1 (sampleUpper) | |||
Sample information for the third sample | |||
2 (bitOffset) | 0 (= “1”) (bitLength) | 0 (channelType) ( | |
4 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
1 (sampleUpper) | |||
Table 27. A single 1-bit monochrome channel, as an 8×1 texel block to allow byte-alignment, part 2 of 2
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
Sample information for the fourth sample | |||
3 (bitOffset) | 0 (= “1”) (bitLength) | 0 (channelType) ( | |
6 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
1 (sampleUpper) | |||
Sample information for the fifth sample | |||
4 (bitOffset) | 0 (= “1”) (bitLength) | 0 (channelType) ( | |
8 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
1 (sampleUpper) | |||
Sample information for the sixth sample | |||
5 (bitOffset) | 0 (= “1”) (bitLength) | 0 (channelType) ( | |
10 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
1 (sampleUpper) | |||
Sample information for the seventh sample | |||
6 (bitOffset) | 0 (= “1”) (bitLength) | 0 (channelType) ( | |
12 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
1 (sampleUpper) | |||
Sample information for the eighth sample | |||
7 (bitOffset) | 0 (= “1”) (bitLength) | 0 (channelType) ( | |
14 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
1 (sampleUpper) | |||
Table 28. 2×2 Bayer pattern: four 8-bit distributed sRGB channels, spread across two lines (as two planes)
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
92 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 88 (descriptorBlockSize) | ||
|
|
|
|
1 (texelBlockDimension0) | 1 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
2 (bytesPlane0) | 2 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the first sample | |||
0 (bitOffset) | 7 (= “8”) (bitLength) | 0 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Sample information for the second sample | |||
8 (bitOffset) | 7 (= “8”) (bitLength) | 1 (channelType) ( | |
2 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Sample information for the third sample | |||
16 (bitOffset) | 7 (= “8”) (bitLength) | 1 (channelType) ( | |
0 (samplePosition0) | 2 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Sample information for the fourth sample | |||
24 (bitOffset) | 7 (= “8”) (bitLength) | 2 (channelType) ( | |
2 (samplePosition0) | 2 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Table 29. Four co-sited 8-bit channels in the sRGB color space described by an 5-entry, 3-bit palette
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
108 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 104 (descriptorBlockSize) | ||
|
|
|
|
0 (texelBlockDimension0) | 0 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
0 (bytesPlane0) | 4 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the palette index | |||
0 (bitOffset) | 2 (= “3”) (bitLength) | 0 (channelType) (irrelevant) | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
4 (sampleUpper) — this specifies that there are 5 palette entries | |||
Sample information for the first sample | |||
0 (bitOffset) | 7 (= “8”) (bitLength) | 0 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Sample information for the second sample | |||
8 (bitOffset) | 7 (= “8”) (bitLength) | 1 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Sample information for the third sample | |||
16 (bitOffset) | 7 (= “8”) (bitLength) | 2 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Sample information for the fourth sample | |||
24 (bitOffset) | 7 (= “8”) (bitLength) | 31 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Table 30. Y′CBCR 4:2:0: BT.709 reduced-range data, with CB and CR aligned to the midpoint of the Y samples
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
124 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 120 (descriptorBlockSize) | ||
|
|
|
|
1 (texelBlockDimension0) | 1 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
2 (bytesPlane0) | 2 (bytesPlane1) | 1 (bytesPlane2) | 1 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the first Y sample | |||
0 (bitOffset) | 7 (= “8”) (bitLength) | 0 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
16 (sampleLower) | |||
235 (sampleUpper) | |||
Sample information for the second Y sample | |||
8 (bitOffset) | 7 (= “8”) (bitLength) | 0 (channelType) ( | |
2 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
16 (sampleLower) | |||
235 (sampleUpper) | |||
Sample information for the third Y sample | |||
16 (bitOffset) | 7 (= “8”) (bitLength) | 0 (channelType) ( | |
0 (samplePosition0) | 2 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
16 (sampleLower) | |||
235 (sampleUpper) | |||
Sample information for the fourth Y sample | |||
24 (bitOffset) | 7 (= “8”) (bitLength) | 0 (channelType) ( | |
2 (samplePosition0) | 2 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
16 (sampleLower) | |||
235 (sampleUpper) | |||
Sample information for the U sample | |||
32 (bitOffset) | 7 (= “8”) (bitLength) | 1 (channelType) ( | |
1 (samplePosition0) | 1 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
16 (sampleLower) | |||
240 (sampleUpper) | |||
Sample information for the V sample | |||
36 (bitOffset) | 7 (= “8”) (bitLength) | 2 (channelType) ( | |
1 (samplePosition0) | 1 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
16 (sampleLower) | |||
240 (sampleUpper) | |||
Table 31. 565 RGB packed 16-bit format as written to memory by a big-endian architecture
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
92 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 88 (descriptorBlockSize) | ||
|
|
|
|
0 (texelBlockDimension0) | 0 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
2 (bytesPlane0) | 0 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the first sample: bit 0 belongs to green, bits 0..2 of channel in 13..15 | |||
13 (bitOffset) | 2 (= “3”) (bitLength) | 1 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
63 (sampleUpper) | |||
Sample information for the second sample: bits 3..5 of green in 0..2 | |||
0 (bitOffset) | 2 (= “3”) (bitLength) | 1 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) — ignored, taken from first sample | |||
0 (sampleUpper) — ignored, taken from first sample | |||
Sample information for the third sample | |||
3 (bitOffset) | 4 (= “5”) (bitLength) | 2 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
31 (sampleUpper) | |||
Sample information for the fourth sample | |||
8 (bitOffset) | 4 (= “5”) (bitLength) | 1 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
31 (sampleUpper) | |||
Table 32. R9G9B9E5 shared-exponent format
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
124 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 120 (descriptorBlockSize) | ||
|
|
|
|
0 (texelBlockDimension0) | 0 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
4 (bytesPlane0) | 0 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the R mantissa | |||
0 (bitOffset) | 8 (= “9”) (bitLength) | 0 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
256 (sampleUpper) — mantissa at 1.0 | |||
Sample information for the R exponent | |||
27 (bitOffset) | 4 (= “5”) (bitLength) | 32 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
15 (sampleUpper) — exponent bias | |||
Sample information for the G mantissa | |||
9 (bitOffset) | 8 (= “9”) (bitLength) | 1 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
256 (sampleUpper) — mantissa at 1.0 | |||
Sample information for the G exponent | |||
27 (bitOffset) | 4 (= “5”) (bitLength) | 33 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
15 (sampleUpper) — exponent bias | |||
Sample information for the B mantissa | |||
18 (bitOffset) | 8 (= “9”) (bitLength) | 2 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
256 (sampleUpper) — mantissa at 1.0 | |||
Sample information for the B exponent | |||
27 (bitOffset) | 4 (= “5”) (bitLength) | 34 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
15 (sampleUpper) — exponent bias | |||
Table 33. Acorn 256-color format (2 bits each independent RGB, 2 bits shared “tint”)
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
108 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 104 (descriptorBlockSize) | ||
|
|
|
|
0 (texelBlockDimension0) | 0 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
1 (bytesPlane0) | 0 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the R value and tint (shared low bits) | |||
0 (bitOffset) | 3 (= “4”) (bitLength) | 0 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
15 (sampleUpper) — unique R upper value | |||
Sample information for the G tint (shared low bits) | |||
0 (bitOffset) | 1 (= “2”) (bitLength) | 1 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
0 (sampleUpper) — ignored, not unique | |||
Sample information for the G unique (high) bits | |||
4 (bitOffset) | 1 (= “2”) (bitLength) | 1 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
15 (sampleUpper) — unique G upper value | |||
Sample information for the B tint (shared low bits) | |||
0 (bitOffset) | 1 (= “2”) (bitLength) | 2 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
0 (sampleUpper) — ignored, not unique | |||
Sample information for the B unique (high) bits | |||
6 (bitOffset) | 1 (= “2”) (bitLength) | 2 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
15 (sampleUpper) — unique B upper value | |||
Table 34. V210 format (full-range Y′CBCR) part 1 of 2
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
220 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 216 (descriptorBlockSize) — 12 samples | ||
|
|
|
|
5 (dimension0) | 0 (dimension1) | 0 (dimension2) | 0 (dimension3) |
16 (bytesPlane0) | 0 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the shared U0/U1 value | |||
0 (bitOffset) | 9 (= “10”) (bitLength) | 1 (channelType) ( | |
1 (assume mid-sited) | 0 | 0 | 0 |
0 (sampleLower) | |||
1023 (sampleUpper) | |||
Sample information for the Y′0 value | |||
10 (bitOffset) | 9 (= “10”) (bitLength) | 0 (channelType) ( | |
0 | 0 | 0 | 0 |
0 (sampleLower) | |||
1023 (sampleUpper) | |||
Sample information for the shared V0/V1 value | |||
20 (bitOffset) | 9 (= “10”) (bitLength) | 2 (channelType) ( | |
1 (assume mid-sited) | 0 | 0 | 0 |
0 (sampleLower) | |||
1023 (sampleUpper) | |||
Sample information for the Y′1 value | |||
32 (bitOffset) | 9 (= “10”) (bitLength) | 0 (channelType) ( | |
2 | 0 | 0 | 0 |
0 (sampleLower) | |||
1023 (sampleUpper) | |||
Sample information for the shared U2/U3 value | |||
42 (bitOffset) | 9 (= “10”) (bitLength) | 1 (channelType) ( | |
5 (assume mid-sited) | 0 | 0 | 0 |
0 (sampleLower) | |||
1023 (sampleUpper) | |||
Sample information for the Y′2 value | |||
52 (bitOffset) | 9 (= “10”) (bitLength) | 0 (channelType) ( | |
4 | 0 | 0 | 0 |
0 (sampleLower) | |||
1023 (sampleUpper) | |||
Table 35. V210 format (full-range Y′CBCR) part 2 of 2
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
Sample information for the shared V2/V3 value | |||
64 (bitOffset) | 9 (= “10”) (bitLength) | 2 (channelType) ( | |
5 (assume mid-sited) | 0 | 0 | 0 |
0 (sampleLower) | |||
1023 (sampleUpper) | |||
Sample information for the Y′3 value | |||
74 (bitOffset) | 9 (= “10”) (bitLength) | 0 (channelType) ( | |
6 | 0 | 0 | 0 |
0 (sampleLower) | |||
1023 (sampleUpper) | |||
Sample information for the shared U4/U5 value | |||
84 (bitOffset) | 9 (= “10”) (bitLength) | 1 (channelType) ( | |
9 (assume mid-sited) | 0 | 0 | 0 |
0 (sampleLower) | |||
1023 (sampleUpper) | |||
Sample information for the Y′4 value | |||
96 (bitOffset) | 9 (= “10”) (bitLength) | 0 (channelType) ( | |
8 | 0 | 0 | 0 |
0 (sampleLower) | |||
1023 (sampleUpper) | |||
Sample information for the shared V4/V5 value | |||
106 (bitOffset) | 9 (= “10”) (bitLength) | 2 (channelType) ( | |
9 (assume mid-sited) | 0 | 0 | 0 |
0 (sampleLower) | |||
1023 (sampleUpper) | |||
Sample information for the Y′4 value | |||
116 (bitOffset) | 9 (= “10”) (bitLength) | 0 (channelType) ( | |
10 | 0 | 0 | 0 |
0 (sampleLower) | |||
1023 (sampleUpper) | |||
Table 36. Intensity-alpha format showing aliased samples
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
92 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 88 (descriptorBlockSize) | ||
|
|
|
|
0 (texelBlockDimension0) | 0 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
1 (bytesPlane0) | 0 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the first sample | |||
0 (bitOffset) | 7 (= “8”) (bitLength) | 0 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Sample information for the second sample | |||
0 (bitOffset) | 7 (= “8”) (bitLength) | 1 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Sample information for the third sample | |||
0 (bitOffset) | 7 (= “8”) (bitLength) | 2 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Sample information for the fourth sample | |||
0 (bitOffset) | 7 (= “8”) (bitLength) | 31 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
255 (sampleUpper) | |||
Table 37. A 48-bit signed middle-endian red channel: three co-sited 16-bit little-endian words, high word first
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
76 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 72 (descriptorBlockSize) | ||
|
|
|
|
0 (texelBlockDimension0) | 0 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
6 (bytesPlane0) | 0 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the first sample | |||
32 (bitOffset) | 15 (= “16”) (bitLength) | 64 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) — ignored, overridden by second sample | |||
0 (sampleUpper) — ignored, overridden by second sample | |||
Sample information for the second sample | |||
16 (bitOffset) | 15 (= “16”) (bitLength) | 64 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0x00000000 (sampleLower) — bottom 32 bits of sampleLower | |||
0xFFFFFFFF (sampleUpper) — bottom 32 bits of sampleUpper | |||
Sample information for the third sample | |||
0 (bitOffset) | 15 (= “16”) (bitLength) | 64 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0xFFFF8000 (sampleLower) — top 16 bits of sampleLower, sign-extended | |||
0x7FFF (sampleUpper) — top 16 bits of sampleUpper | |||
Table 38. A single 16-bit floating-point red value, described explicitly (example only!)
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
76 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 72 (descriptorBlockSize) | ||
|
|
|
|
0 (texelBlockDimension0) | 0 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
2 (bytesPlane0) | 0 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information for the first sample (mantissa) | |||
0 (bitOffset) | 9 (= “10”) (bitLength) | 0 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0 (sampleLower) | |||
1024 (sampleUpper) — implicit 1 | |||
Sample information for the second sample (sign bit) | |||
15 (bitOffset) | 0 (= “1”) (bitLength) | 64 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0xFFFFFFFF (sampleLower) | |||
0x0 (sampleUpper) | |||
Sample information for the third sample (exponent) | |||
10 (bitOffset) | 4 (= “5”) (bitLength) | 32 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
15 (sampleLower) — bias | |||
30 (sampleUpper) — support for infinities (because 31 can be encoded) | |||
Table 39. A single 16-bit floating-point red value, described normally
| Byte 0 (LSB) | Byte 1 | Byte 2 | Byte 3 (MSB) |
|---|---|---|---|
44 (totalSize) | |||
0 (vendorId) | 0 (descriptorType) | ||
0 (versionNumber) | 40 (descriptorBlockSize) | ||
|
|
|
|
0 (texelBlockDimension0) | 0 (texelBlockDimension1) | 0 (texelBlockDimension2) | 0 (texelBlockDimension3) |
2 (bytesPlane0) | 0 (bytesPlane1) | 0 (bytesPlane2) | 0 (bytesPlane3) |
0 (bytesPlane4) | 0 (bytesPlane5) | 0 (bytesPlane6) | 0 (bytesPlane7) |
Sample information | |||
0 (bitOffset) | 15 (= “16”) (bitLength) | 192 (channelType) ( | |
0 (samplePosition0) | 0 (samplePosition1) | 0 (samplePosition2) | 0 (samplePosition3) |
0xbf80000 (sampleLower) = -1.0 | |||
0x3f80000 (sampleUpper) = 1.0 | |||
For computer graphics, a number of texture compression schemes exist, which both reduce the overall texture memory footprint and reduce the bandwidth requirements of using the textures. In this context, “texture compression” is distinct from “image compression” in that texture compression schemes are designed to allow efficient random access as part of texture sampling. “Image compression” can further reduce image redundancy by considering the image as a whole, but doing so is impractical for efficient texture access operations.
The common compression schemes are “block-based”, and rely on similarities between nearby texel regions to describe “blocks” of nearby texels in a unit:
- The “S3TC” schemes describe a block of 4×4 RGB texels in terms of a low-precision pair of color “endpoints”, and allow each texel to specify an interpolation point between these endpoints. Alpha channels, if present, may be described similarly or with an explict per-texel alpha value.
- The “RGTC” schemes provide one- and two-channel schemes for interpolating between two “endpoints” per 4×4 texel block, and are intended to provide efficient schemes for normal encoding, complementing the three-channel approach of S3TC.
- “BPTC” schemes offer a number of ways of encoding and interpolating endpoints, and allow the 4×4 texel block to be divided into multiple “subsets” which can be encoded independently, which can be useful for managing different regions with sharp transitions.
- “ETC1” provides ways of encoding 4×4 texel blocks as two regions of 2×4 or 4×2 texels, each of which are specified as a base color; texels are then encoded as offsets relative to these bases, varying by a grayscale offset.
- “ETC2” is a superset of ETC1 and includes additional schemes for color patterns that would fit poorly into ETC1 options.
- “ASTC” allows a wide range of ways of encoding each color block, and supports choosing different block sizes to encode the texture, providing a range of compression ratios; it also supports 3D and HDR textures.
As can be seen above, the compression schemes have a number of features in common — particularly in having a number of endpoints described encoded in some of the bits of the texel block. For consistency and to make the terms more concise, the following descriptions use some slightly unusual terminology:
The value Xnm refers to bit m (starting at 0) of the nth X value. For example, R13 would refer to bit 3 of red value 1 — R, G, B and A (capitalized and italicized) are generally used to refer to color channels. Similarly, R12..3 refers to bits 2..3 of red value 1.
Although unusual, this terminology should be unambiguous (e.g. none of the formats require exponentiation of arguments).
This description is derived from the EXT_texture_compression_s3tc extension.
Compressed texture images stored using the S3TC compressed image formats are represented as a collection of 4×4 texel blocks, where each block contains 64 or 128 bits of texel data. The image is encoded as a normal 2D raster image in which each 4×4 block is treated as a single pixel. If an S3TC image has a width or height that is not a multiple of four, the data corresponding to texels outside the image are irrelevant and undefined.
When an S3TC image with a width of w, height of h, and block size of blocksize (8 or 16 bytes) is decoded, the corresponding image size (in bytes) is:
When decoding an S3TC image, the block containing the texel at offset (x, y) begins at an offset (in bytes) relative to the base of the image of:
The data corresponding to a specific texel (x, y) are extracted from a 4×4 texel block using a relative (x, y) value of
There are four distinct S3TC image formats:
Each 4×4 block of texels consists of 64 bits of RGB image data.
Each RGB image data block is encoded as a sequence of 8 bytes, called (in order of increasing address):
The 8 bytes of the block are decoded into three quantities:
color0 and color1 are 16-bit unsigned integers that are unpacked to RGB colors RGB0 and RGB1 as though they were 16-bit unsigned packed pixels with the R channel in the high 5 bits, G in the next 6 bits and B in the low 5 bits:
bits is a 32-bit unsigned integer, from which a two-bit control code is extracted for a texel at location (x, y) in the block using:
where bits[31] is the most significant and bits[0] is the least significant bit.
The RGB color for a texel at location (x, y) in the block is given in Table 40.
Table 40. Block decoding for BC1
| Texel value | Condition |
|---|---|
RGB0 | color0 > color1 and code(x, y) = 0 |
RGB1 | color0 > color1 and code(x, y) = 1 |
$(2\times \mathit{RGB}_0 + \mathit{RGB}_1)\over 3$ | color0 > color1 and code(x, y) = 2 |
$(\mathit{RGB}_0 + 2\times RGB_1)\over 3$ | color0 > color1 and code(x, y) = 3 |
RGB0 | color0 ≤ color1 and code(x, y) = 0 |
RGB1 | color0 ≤ color1 and code(x, y) = 1 |
$(\mathit{RGB}_0+\mathit{RGB}_1)\over 2$ | color0 ≤ color1 and code(x, y) = 2 |
BLACK | color0 ≤ color1 and code(x, y) = 3 |
Arithmetic operations are done per component, and BLACK refers to an RGB color where red, green, and blue are all zero.
Since this image has an RGB format, there is no alpha component and the image is considered fully opaque.
Each 4×4 block of texels consists of 64 bits of RGB image data and minimal alpha information. The RGB components of a texel are extracted in the same way as BC1 with no alpha.
The alpha component for a texel at location (x, y) in the block is given by Table 41.
The red, green, and blue components of any texels with a final alpha of 0 should be encoded as zero (black).
| |
Figure 3 shows an example BC1 texel block: color0, encoded as $\left({{29}\over{31}}, {{60}\over{63}}, {{1}\over{31}}\right)$ , and color1, encoded as $\left({{20}\over{31}}, {{2}\over{63}}, {{30}\over{31}}\right)$ , are shown as circles. The interpolated values are shown as small diamonds. Since 29 > 20, there are two interpolated values, accessed when code(x, y) = 2 and code(x, y) = 3. Figure 4 shows the example BC1 texel block with the colors swapped: color0, encoded as $\left({{20}\over{31}}, {{2}\over{63}}, {{30}\over{31}}\right)$ , and color1, encoded as $\left({{29}\over{31}}, {{60}\over{63}}, {{1}\over{31}}\right)$ , are shown as circles. The interpolated value is shown as a small diamonds. Since 20 ≤ 29, there is one interpolated value for code(x, y) = 2, and code(x, y) = 3 represents (R, G, B) = (0, 0, 0). If the format is BC1 with alpha, code(x, y) = 3 is transparent (alpha = 0). If the format is BC1 with no alpha, code(x, y) = 3 represents opaque black. |
Each 4×4 block of texels consists of 64 bits of uncompressed alpha image data followed by 64 bits of RGB image data.
Each RGB image data block is encoded according to the BC1 formats, with the exception that the two code bits always use the non-transparent encodings. In other words, they are treated as though color0 > color1, regardless of the actual values of color0 and color1.
Each alpha image data block is encoded as a sequence of 8 bytes, called (in order of increasing address):
The 8 bytes of the block are decoded into one 64-bit integer:
alpha is a 64-bit unsigned integer, from which a four-bit alpha value is extracted for a texel at location (x, y) in the block using:
where bits[63] is the most significant and bits[0] is the least significant bit.
The alpha component for a texel at location (x, y) in the block is given by $\mathit{alpha}(x,y)\over 15$ .
Each 4×4 block of texels consists of 64 bits of compressed alpha image data followed by 64 bits of RGB image data.
Each RGB image data block is encoded according to the BC1 formats, with the exception that the two code bits always use the non-transparent encodings. In other words, they are treated as though color0 > color1, regardless of the actual values of color0 and color1.
Each alpha image data block is encoded as a sequence of 8 bytes, called (in order of increasing address):
The alpha0 and alpha1 are 8-bit unsigned bytes converted to alpha components by multiplying by $1\over 255$ .
The 6 bits bytes of the block are decoded into one 48-bit integer:
bits is a 48-bit unsigned integer, from which a three-bit control code is extracted for a texel at location (x, y) in the block using:
where bits[47] is the most-significant and bits[0] is the least-significant bit.
The alpha component for a texel at location (x, y) in the block is given by Table 42.
Table 42. Alpha encoding for BC3 blocks
| Alpha value | Condition |
|---|---|
alpha0 | code(x, y) = 0 |
alpha1 | code(x, y) = 1 |
$(6\times\mathit{alpha}_0 + 1\times\mathit{alpha}_1)\over 7$ | alpha0 > alpha1 and code(x, y) = 2 |
$(5\times\mathit{alpha}_0 + 2\times\mathit{alpha}_1)\over 7$ | alpha0 > alpha1 and code(x, y) = 3 |
$(4\times\mathit{alpha}_0 + 3\times\mathit{alpha}_1)\over 7$ | alpha0 > alpha1 and code(x, y) = 4 |
$(3\times\mathit{alpha}_0 + 4\times\mathit{alpha}_1)\over 7$ | alpha0 > alpha1 and code(x, y) = 5 |
$(2\times\mathit{alpha}_0 + 5\times\mathit{alpha}_1)\over 7$ | alpha0 > alpha1 and code(x, y) = 6 |
$(1\times\mathit{alpha}_0 + 6\times\mathit{alpha}_1)\over 7$ | alpha0 > alpha1 and code(x, y) = 7 |
$(4\times\mathit{alpha}_0 + 1\times\mathit{alpha}_1)\over 5$ | alpha0 ≤ alpha1 and code(x, y) = 2 |
$(3\times\mathit{alpha}_0 + 2\times\mathit{alpha}_1)\over 5$ | alpha0 ≤ alpha1 and code(x, y) = 3 |
$(2\times\mathit{alpha}_0 + 3\times\mathit{alpha}_1)\over 5$ | alpha0 ≤ alpha1 and code(x, y) = 4 |
$(1\times\mathit{alpha}_0 + 4\times\mathit{alpha}_1)\over 5$ | alpha0 ≤ alpha1 and code(x, y) = 5 |
0.0 | alpha0 ≤ alpha1 and code(x, y) = 6 |
1.0 | alpha0 ≤ alpha1 and code(x, y) = 7 |
This description is derived from the “RGTC Compressed Texture Image Formats” section of the OpenGL 4.5 specification.
Compressed texture images stored using the RGTC compressed image encodings are represented as a collection of 4×4 texel blocks, where each block contains 64 or 128 bits of texel data. The image is encoded as a normal 2D raster image in which each 4×4 block is treated as a single pixel. If an RGTC image has a width or height that is not a multiple of four, the data corresponding to texels outside the image are irrelevant and undefined.
When an RGTC image with a width of w, height of h, and block size of blocksize (8 or 16 bytes) is decoded, the corresponding image size (in bytes) is:
When decoding an RGTC image, the block containing the texel at offset $(x,y)$ begins at an offset (in bytes) relative to the base of the image of:
The data corresponding to a specific texel (x, y) are extracted from a 4×4 texel block using a relative (x, y) value of
There are four distinct RGTC image formats described in the following sections.
Each 4×4 block of texels consists of 64 bits of unsigned red image data.
Each red image data block is encoded as a sequence of 8 bytes, called (in order of increasing address):
The 6 bits{0..5} bytes of the block are decoded into a 48-bit bit vector:
red0 and red1 are 8-bit unsigned integers that are unpacked to red values RED0 and RED1 by multiplying by $1\over 255$ .
bits is a 48-bit unsigned integer, from which a three-bit control code is extracted for a texel at location (x, y) in the block using:
where bits[47] is the most-significant and bits[0] is the least-significant bit.
The red value R for a texel at location (x, y) in the block is given by Table 43.
Table 43. Block decoding for BC4
| R value | Condition |
|---|---|
RED0 | red0 > red1, code(x, y) = 0 |
RED1 | red0 > red1, code(x, y) = 1 |
${ 6 \times \mathit{RED}_0 + \mathit{RED}_1 } \over 7$ | red0 > red1, code(x, y) = 2 |
${ 5 \times \mathit{RED}_0 + 2 \times \mathit{RED}_1 } \over 7$ | red0 > red1, code(x, y) = 3 |
${ 4 \times \mathit{RED}_0 + 3 \times \mathit{RED}_1 } \over 7$ | red0 > red1, code(x, y) = 4 |
${ 3 \times \mathit{RED}_0 + 4 \times \mathit{RED}_1 } \over 7$ | red0 > red1, code(x, y) = 5 |
${ 2 \times \mathit{RED}_0 + 5 \times \mathit{RED}_1 } \over 7$ | red0 > red1, code(x, y) = 6 |
${ \mathit{RED}_0 + 6 \times \mathit{RED}_1 } \over 7$ | red0 > red1, code(x, y) = 7 |
RED0 | red0 ≤ red1, code(x, y) = 0 |
RED1 | red0 ≤ red1, code(x, y) = 1 |
${ 4 \times \mathit{RED}_0 + \mathit{RED}_1 } \over 5$ | red0 ≤ red1, code(x, y) = 2 |
${ 3 \times \mathit{RED}_0 + 2 \times \mathit{RED}_1 } \over 5$ | red0 ≤ red1, code(x, y) = 3 |
${ 2 \times \mathit{RED}_0 + 3 \times \mathit{RED}_1 } \over 5$ | red0 ≤ red1, code(x, y) = 4 |
${ \mathit{RED}_0 + 4 \times \mathit{RED}_1 } \over 5$ | red0 ≤ red1, code(x, y) = 5 |
REDmin | red0 ≤ red1, code(x, y) = 6 |
REDmax | red0 ≤ red1, code(x, y) = 7 |
REDmin and REDmax are 0.0 and 1.0 respectively.
Since the decoded texel has a red format, the resulting RGBA value for the texel is (R, 0, 0, 1).
Each 4×4 block of texels consists of 64 bits of signed red image data. The red values of a texel are extracted in the same way as BC4 unsigned except red0, red1, RED0, RED1, REDmin, and REDmax are signed values defined as follows:
red0 and red1 are 8-bit signed (two’s complement) integers.
CAVEAT: For signed red0 and red1 values: the expressions red0 > red1 and red0 ≤ red1 above are considered undefined (read: may vary by implementation) when red0 = -127 and red1 = -128. This is because if red0 were remapped to -127 prior to the comparison to reduce the latency of a hardware decompressor, the expressions would reverse their logic. Encoders for the signed red-green formats should avoid encoding blocks where red0 = -127 and red1 = -128.
Each 4×4 block of texels consists of 64 bits of compressed unsigned red image data followed by 64 bits of compressed unsigned green image data.
The first 64 bits of compressed red are decoded exactly like BC4 unsigned above. The second 64 bits of compressed green are decoded exactly like BC4 unsigned above except the decoded value R for this second block is considered the resulting green value G.
Since the decoded texel has a red-green format, the resulting RGBA value for the texel is (R, G, 0, 1).
Each 4×4 block of texels consists of 64 bits of compressed signed red image data followed by 64 bits of compressed signed green image data.
The first 64 bits of compressed red are decoded exactly like BC4 signed above. The second 64 bits of compressed green are decoded exactly like BC4 signed above except the decoded value R for this second block is considered the resulting green value G.
Since this image has a red-green format, the resulting RGBA value is (R, G, 0, 1).
This description is derived from the “BPTC Compressed Texture Image Formats” section of the OpenGL 4.5 specification. More information on BC7, BC7 modes and BC6h can be found in Microsoft’s online documentation.
Compressed texture images stored using the BPTC compressed image formats are represented as a collection of 4×4 texel blocks, each of which contains 128 bits of texel data stored in little-endian order. The image is encoded as a normal 2D raster image in which each 4×4 block is treated as a single pixel. If a BPTC image has a width or height that is not a multiple of four, the data corresponding to texels outside the image are irrelevant and undefined. When a BPTC image with width w, height h, and block size blocksize (16 bytes) is decoded, the corresponding image size (in bytes) is:
When decoding a BPTC image, the block containing the texel at offset (x, y) begins at an offset (in bytes) relative to the base of the image of:
The data corresponding to a specific texel (x, y) are extracted from a 4×4 texel block using a relative (x, y) value of:
There are two distinct BPTC image formats each of which has two variants. BC7 with or without an sRGB transform function used in the encoding of the RGB channels compresses 8-bit unsigned, normalized fixed-point data. BC6H in signed or unsigned form compresses high dynamic range floating-point values. The formats are similar, so the description of the BC6H format will reference significant sections of the BC7 description.
Each 4×4 block of texels consists of 128 bits of RGBA image data, of which the RGB channels may be encoded linearly or with the sRGB transfer function.
Each block contains enough information to select and decode a number of colors called endpoints, pairs of which forms subsets, then to interpolate between those endpoints in a variety of ways, and finally to remap the result into the final output by indexing into these interpolated values according to a partition layout which maps each relative coordinate to a subset.
Each block can contain data in one of eight modes. The mode is identified by the lowest bits of the lowest byte. It is encoded as zero or more zeros followed by a one. For example, using ‘x’ to indicate a bit not included in the mode number, mode 0 is encoded as xxxxxxx1 in the low byte in binary, mode 5 is xx100000, and mode 7 is 10000000. Encoding the low byte as zero is reserved and should not be used when encoding a BPTC texture; hardware decoders processing a texel block with a low byte of 0 should return 0 for all channels of all texels.
All further decoding is driven by the values derived from the mode listed in Table 44 and Table 45. The fields in the block are always in the same order for all modes. In increasing bit order after the mode, these fields are: partition pattern selection, rotation, index selection, color, alpha, per-endpoint P-bit, shared P-bit, primary indices, and secondary indices. The number of bits to be read in each field is determined directly from these tables, as shown in Table 46.
| |
Per texel block, CB = 3(each of R, G, B)×2(endpoints)×NS(#subsets)×CB(bits/channel/endpoint). AB = 2(endpoints)×NS(#subsets)×AB(bits/endpoint). {IB,IB2} = 16(texels)×{IB,IB2}(#index bits/texel) - NS(1bit/subset). |
Table 44. Mode-dependent BPTC parameters
Mode | NS | PB | RB | ISB | CB | AB | EPB | SPB | IB | IB2 | M | CB | AB | EPB | SPB | IB | IB2 | |
Bits per… | …texel block | …channel/endpoint | …endpoint | …subset | …texel | Bits per texel block (total) | ||||||||||||
0 | 3 | 4 | 0 | 0 | 4 | 0 | 1 | 0 | 3 | 0 | 1 | 72 | 0 | 6 | 0 | 45 | 0 | |
1 | 2 | 6 | 0 | 0 | 6 | 0 | 0 | 1 | 3 | 0 | 2 | 72 | 0 | 0 | 2 | 46 | 0 | |
2 | 3 | 6 | 0 | 0 | 5 | 0 | 0 | 0 | 2 | 0 | 3 | 90 | 0 | 0 | 0 | 29 | 0 | |
3 | 2 | 6 | 0 | 0 | 7 | 0 | 1 | 0 | 2 | 0 | 4 | 84 | 0 | 4 | 0 | 30 | 0 | |
4 | 1 | 0 | 2 | 1 | 5 | 6 | 0 | 0 | 2 | 3 | 5 | 30 | 12 | 0 | 0 | 31 | 47 | |
5 | 1 | 0 | 2 | 0 | 7 | 8 | 0 | 0 | 2 | 2 | 6 | 42 | 16 | 0 | 0 | 31 | 31 | |
6 | 1 | 0 | 0 | 0 | 7 | 7 | 1 | 0 | 4 | 0 | 7 | 42 | 14 | 2 | 0 | 63 | 0 | |
7 | 2 | 6 | 0 | 0 | 5 | 5 | 1 | 0 | 2 | 0 | 8 | 60 | 20 | 4 | 0 | 30 | 0 | |
Table 45. Full descriptions of the BPTC mode columns
M | Mode identifier bits |
NS | Number of subsets |
PB | Partition selection bits |
RB | Rotation bits |
ISB | Index selection bit |
CB | Color bits |
AB | Alpha bits |
EPB | Endpoint P-bits (all channels) |
SPB | Shared P-bits |
IB | Index bits |
IB2 | Secondary index bits |
Each block can be divided into between 1 and 3 groups of pixels called subsets, which have different endpoints. There are two endpoint colors per subset, grouped first by endpoint, then by subset, then by channel. For example, mode 1, with two subsets and six color bits, would have six bits of red for endpoint 0 of the first subset, then six bits of red for endpoint 1, then the two ends of the second subset, then green and blue stored similarly. If a block has any alpha bits, the alpha data follows the color data with the same organization. If not, alpha is overridden to 255. These bits are treated as the high bits of a fixed-point value in a byte for each color channel of the endpoints: {ER7..0, EG7..0, EB7..0, EA7..0} per endpoint. If the mode has shared P-bits, there are two endpoint bits, the lower of which applies to both endpoints of subset 0 and the upper of which applies to both endpoints of subset 1. If the mode has per-endpoint P-bits, then there are 2 × subsets P-bits stored in the same order as color and alpha. Both kinds of P-bits are added as a bit below the color data stored in the byte. So, for mode 1 with six red bits, the P-bit ends up in bit 1. For final scaling, the top bits of the value are replicated into any remaining bits in the byte. For the example of mode 1, bit 7 (which originated as bit 5 of the 6-bit encoded channel) would be replicated to bit 0. Table 47 and Table 48 show the origin of each endpoint color bit for each mode.
Table 46. Bit layout for BC7 modes (LSB..MSB)
Mode 0 | 0: M0 = 1 | 1..4: PB0..3 | ||||
5..8: R00..3 | 9..12: R10..3 | 13..16: R20..3 | 17..20: R30..3 | 21..24: R40..3 | 25..28: R50..3 | |
29..32: G00..3 | 33..36: G10..3 | 37..40: G20..3 | 41..44: G30..3 | 45..48: G40..3 | 49..52: G50..3 | |
53..56: B00..3 | 57..60: B10..3 | 61..64: B20..3 | 65..68: B30..3 | 69..72: B40..3 | 73..76: B50..3 | |
77: EPB00 | 78: EPB10 | 79: EPB20 | 80: EPB30 | 81: EPB40 | 82: EPB50 | |
83..127: IB0..44 | ||||||
Mode 1 | 0..1: M0..1 = 01 | 2..7: PB0..5 | ||||
8..13: R00..5 | 14..19: R10..5 | 20..25: R20..5 | 26..31: R30..5 | |||
32..37: G00..5 | 38..43: G10..5 | 44..49: G20..5 | 50..55: G30..5 | |||
56..61: B00..5 | 62..67: B10..5 | 68..73: B20..5 | 74..79: B30..5 | |||
80: SPB00 | 81: SPB10 | 82..127: IB0..45 | ||||
Mode 2 | 0..2: M0..2 = 001 | 3..8: PB0..5 | ||||
9..13: R00..4 | 14..18: R10..4 | 19..23: R20..4 | 24..28: R40..4 | 29..33: R40..4 | 34..38: R50..4 | |
39..43: G00..4 | 44..48: G10..4 | 49..53: G20..4 | 54..58: G40..4 | 59..63: G40..4 | 64..68: G50..4 | |
69..73: B00..4 | 74..78: B10..4 | 79..83: B20..4 | 84..88: B40..4 | 89..93: B40..4 | 94..98: B50..4 | |
99..127: IB0..28 | ||||||
Mode 3 | 0..3: M0..3 = 0001 | 4..9: PB0..5 | ||||
10..16: R00..6 | 17..23: R10..6 | 24..30: R20..6 | 31..37: R30..6 | |||
38..44: G00..6 | 45..51: G10..6 | 52..58: G20..6 | 59..65: G30..6 | |||
66..72: B00..6 | 73..79: B10..6 | 80..86: B20..6 | 87..93: B30..6 | |||
94: EPB00 | 95: EPB10 | 96: EPB20 | 97: EPB30 | 98..127: IB0..29 | ||
Mode 4 | 0..4: M0..4 = 00001 | 5..6: RB0..1 | 7: ISB0 | |||
8..12: R00..4 | 13..17: R10..4 | 18..22: G00..4 | 23..27: G10..4 | 28..32: B00..4 | 33..37: B10..4 | |
38..43: A00..5 | 44..49: A10..5 | 50..80: IB0..30 | 81..127: IB20..46 | |||
Mode 5 | 0..5: M0..5 = 000001 | 6..7: RB0..1 | ||||
8..14: R00..6 | 15..21: R10..6 | 22..28: G00..6 | 29..34: G10..6 | 35..41: B00..6 | 42..49: B10..6 | |
50..57: A00..7 | 58..65: A10..7 | 66..96: IB0..30 | 97..127: IB20..30 | |||
Mode 6 | 0..6: M0..6 = 0000001 | |||||
7..13: R00..6 | 14..20: R10..6 | 21..27: G00..6 | 28..34: G10..6 | 35..41: B00..6 | 42..48: B10..6 | |
49..55: A00..6 | 56..62: A10..6 | 63: EPB00 | 64: EPB10 | 65..127: IB0..62 | ||
Mode 7 | 0..7: M0..7 = 00000001 | 8..13: PB0..5 | ||||
14..18: R00..4 | 19..23: R10..4 | 24..28: R20..4 | 29..33: R30..4 | |||
34..38: G00..4 | 39..43: G10..4 | 44..48: G20..4 | 49..53: G30..4 | |||
54..58: B00..4 | 59..63: B10..4 | 64..68: B20..4 | 69..73: B30..4 | |||
74..78: A00..4 | 79..83: A10..4 | 84..88: A20..4 | 89..93: A30..4 | |||
94: EPB00 | 95: EPB10 | 96: EPB20 | 97: EPB30 | 98..127: IB0..29 | ||
Table 47. Bit sources for BC7 endpoints (modes 0..2, MSB..LSB per channel)
Mode 0 | |||||||||||||||||||||||||||||||
ER07..0 | EG07..0 | EB07..0 | EA07..0 | ||||||||||||||||||||||||||||
8 | 7 | 6 | 5 | 77 | 8 | 7 | 6 | 32 | 31 | 30 | 29 | 77 | 32 | 31 | 30 | 56 | 55 | 54 | 53 | 77 | 56 | 55 | 54 | 255 | |||||||
ER17..0 | EG17..0 | EB17..0 | EA17..0 | ||||||||||||||||||||||||||||
12 | 11 | 10 | 9 | 78 | 12 | 11 | 10 | 36 | 35 | 34 | 33 | 78 | 36 | 35 | 34 | 60 | 59 | 58 | 57 | 78 | 60 | 59 | 58 | 255 | |||||||
ER27..0 | EG27..0 | EB27..0 | EA27..0 | ||||||||||||||||||||||||||||
16 | 15 | 14 | 13 | 79 | 16 | 15 | 14 | 40 | 39 | 38 | 37 | 79 | 40 | 39 | 38 | 64 | 63 | 62 | 61 | 79 | 64 | 63 | 62 | 255 | |||||||
ER37..0 | EG37..0 | EB37..0 | EA37..0 | ||||||||||||||||||||||||||||
20 | 19 | 18 | 17 | 80 | 20 | 19 | 18 | 44 | 43 | 42 | 41 | 80 | 44 | 43 | 42 | 68 | 67 | 66 | 65 | 80 | 68 | 67 | 66 | 255 | |||||||
ER47..0 | EG47..0 | EB47..0 | EA47..0 | ||||||||||||||||||||||||||||
24 | 23 | 22 | 21 | 81 | 24 | 23 | 22 | 48 | 47 | 46 | 45 | 81 | 48 | 47 | 46 | 72 | 71 | 70 | 69 | 81 | 72 | 71 | 70 | 255 | |||||||
ER57..0 | EG57..0 | EB57..0 | EA57..0 | ||||||||||||||||||||||||||||
28 | 27 | 26 | 25 | 82 | 28 | 27 | 26 | 52 | 51 | 50 | 49 | 82 | 52 | 51 | 50 | 76 | 75 | 74 | 73 | 82 | 76 | 75 | 74 | 255 | |||||||
Mode 1 | |||||||||||||||||||||||||||||||
ER07..0 | EG07..0 | EB07..0 | EA07..0 | ||||||||||||||||||||||||||||
13 | 12 | 11 | 10 | 9 | 8 | 80 | 13 | 37 | 36 | 35 | 34 | 33 | 32 | 80 | 37 | 61 | 60 | 59 | 58 | 57 | 56 | 80 | 61 | 255 | |||||||
ER17..0 | EG17..0 | EB17..0 | EA17..0 | ||||||||||||||||||||||||||||
19 | 18 | 17 | 16 | 15 | 14 | 80 | 19 | 43 | 42 | 41 | 40 | 39 | 38 | 80 | 43 | 67 | 66 | 65 | 64 | 63 | 62 | 80 | 67 | 255 | |||||||
ER27..0 | EG27..0 | EB27..0 | EA27..0 | ||||||||||||||||||||||||||||
25 | 24 | 23 | 22 | 21 | 20 | 81 | 25 | 49 | 48 | 47 | 46 | 45 | 44 | 81 | 49 | 73 | 72 | 71 | 70 | 69 | 68 | 81 | 73 | 255 | |||||||
ER37..0 | EG37..0 | EB37..0 | EA37..0 | ||||||||||||||||||||||||||||
31 | 30 | 29 | 28 | 27 | 26 | 81 | 31 | 55 | 54 | 53 | 52 | 51 | 50 | 81 | 55 | 79 | 78 | 77 | 76 | 75 | 74 | 81 | 79 | 255 | |||||||
Mode 2 | |||||||||||||||||||||||||||||||
ER07..0 | EG07..0 | EB07..0 | EA07..0 | ||||||||||||||||||||||||||||
13 | 12 | 11 | 10 | 9 | 13 | 12 | 11 | 43 | 42 | 41 | 40 | 39 | 43 | 42 | 41 | 73 | 72 | 71 | 70 | 69 | 73 | 72 | 71 | 255 | |||||||
ER17..0 | EG17..0 | EB17..0 | EA17..0 | ||||||||||||||||||||||||||||
18 | 17 | 16 | 15 | 14 | 18 | 17 | 16 | 48 | 47 | 46 | 45 | 44 | 48 | 47 | 46 | 78 | 77 | 76 | 75 | 74 | 78 | 77 | 76 | 255 | |||||||
ER27..0 | EG27..0 | EB27..0 | EA27..0 | ||||||||||||||||||||||||||||
23 | 22 | 21 | 20 | 19 | 23 | 22 | 21 | 53 | 52 | 51 | 50 | 49 | 53 | 52 | 51 | 83 | 82 | 81 | 80 | 79 | 83 | 82 | 81 | 255 | |||||||
ER37..0 | EG37..0 | EB37..0 | EA37..0 | ||||||||||||||||||||||||||||
28 | 27 | 26 | 25 | 24 | 28 | 27 | 26 | 58 | 57 | 56 | 55 | 54 | 58 | 57 | 56 | 88 | 87 | 86 | 85 | 84 | 88 | 87 | 86 | 255 | |||||||
ER47..0 | EG47..0 | EB47..0 | EA47..0 | ||||||||||||||||||||||||||||
33 | 32 | 31 | 30 | 29 | 33 | 32 | 31 | 63 | 62 | 61 | 60 | 59 | 63 | 62 | 61 | 93 | 92 | 91 | 90 | 89 | 93 | 92 | 91 | 255 | |||||||
ER57..0 | EG57..0 | EB57..0 | EA57..0 | ||||||||||||||||||||||||||||
38 | 37 | 36 | 35 | 34 | 38 | 37 | 36 | 68 | 67 | 66 | 65 | 64 | 68 | 67 | 66 | 98 | 97 | 96 | 95 | 94 | 98 | 97 | 96 | 255 | |||||||
Table 48. Bit sources for BC7 endpoints (modes 3..7, MSB..LSB per channel)
Mode 3 | |||||||||||||||||||||||||||||||
ER07..0 | EG07..0 | EB07..0 | EA07..0 | ||||||||||||||||||||||||||||
16 | 15 | 14 | 13 | 12 | 11 | 10 | 94 | 44 | 43 | 42 | 41 | 40 | 39 | 38 | 94 | 72 | 71 | 70 | 69 | 68 | 67 | 66 | 94 | 255 | |||||||
ER17..0 | EG17..0 | EB17..0 | EA17..0 | ||||||||||||||||||||||||||||
23 | 22 | 21 | 20 | 19 | 18 | 17 | 95 | 51 | 50 | 49 | 48 | 47 | 46 | 45 | 95 | 79 | 78 | 77 | 76 | 75 | 74 | 73 | 95 | 255 | |||||||
ER27..0 | EG27..0 | EB27..0 | EA27..0 | ||||||||||||||||||||||||||||
30 | 29 | 28 | 27 | 26 | 25 | 24 | 96 | 58 | 57 | 56 | 55 | 54 | 53 | 52 | 96 | 86 | 85 | 84 | 83 | 82 | 81 | 80 | 96 | 255 | |||||||
ER37..0 | EG37..0 | EB37..0 | EA37..0 | ||||||||||||||||||||||||||||
37 | 36 | 35 | 34 | 33 | 32 | 31 | 97 | 65 | 64 | 63 | 62 | 61 | 60 | 59 | 97 | 93 | 92 | 91 | 90 | 89 | 88 | 87 | 97 | 255 | |||||||
Mode 4 | |||||||||||||||||||||||||||||||
ER07..0 | EG07..0 | EB07..0 | EA07..0 | ||||||||||||||||||||||||||||
12 | 11 | 10 | 9 | 8 | 12 | 11 | 10 | 22 | 21 | 20 | 19 | 18 | 22 | 21 | 20 | 32 | 31 | 30 | 29 | 28 | 32 | 31 | 30 | 43 | 42 | 41 | 40 | 39 | 38 | 43 | 42 |
ER17..0 | EG17..0 | EB17..0 | EA17..0 | ||||||||||||||||||||||||||||
17 | 16 | 15 | 14 | 13 | 17 | 16 | 15 | 27 | 26 | 25 | 24 | 23 | 27 | 26 | 25 | 37 | 36 | 35 | 34 | 33 | 37 | 36 | 35 | 49 | 48 | 47 | 46 | 45 | 44 | 49 | 48 |
Mode 5 | |||||||||||||||||||||||||||||||
ER07..0 | EG07..0 | EB07..0 | EA07..0 | ||||||||||||||||||||||||||||
14 | 13 | 12 | 11 | 10 | 9 | 8 | 14 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 28 | 42 | 41 | 40 | 39 | 38 | 37 | 36 | 42 | 57 | 56 | 55 | 54 | 53 | 52 | 51 | 50 |
ER17..0 | EG17..0 | EB17..0 | EA17..0 | ||||||||||||||||||||||||||||
21 | 20 | 19 | 18 | 17 | 16 | 15 | 21 | 35 | 34 | 33 | 32 | 31 | 30 | 29 | 35 | 49 | 48 | 47 | 46 | 45 | 44 | 43 | 49 | 65 | 64 | 63 | 62 | 61 | 60 | 59 | 58 |
Mode 6 | |||||||||||||||||||||||||||||||
ER07..0 | EG07..0 | EB07..0 | EA07..0 | ||||||||||||||||||||||||||||
13 | 12 | 11 | 10 | 9 | 8 | 7 | 63 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 63 | 41 | 40 | 39 | 38 | 37 | 36 | 35 | 63 | 55 | 54 | 53 | 52 | 51 | 50 | 49 | 63 |
ER17..0 | EG17..0 | EB17..0 | EA17..0 | ||||||||||||||||||||||||||||
20 | 19 | 18 | 17 | 16 | 15 | 14 | 64 | 34 | 33 | 32 | 31 | 30 | 29 | 28 | 64 | 48 | 47 | 46 | 45 | 44 | 43 | 42 | 64 | 62 | 61 | 60 | 59 | 58 | 57 | 56 | 64 |
Mode 7 | |||||||||||||||||||||||||||||||
ER07..0 | EG07..0 | EB07..0 | EA07..0 | ||||||||||||||||||||||||||||
18 | 17 | 16 | 15 | 14 | 94 | 18 | 17 | 38 | 37 | 36 | 35 | 34 | 94 | 38 | 37 | 58 | 57 | 56 | 55 | 54 | 94 | 58 | 57 | 78 | 77 | 76 | 75 | 74 | 94 | 78 | 77 |
ER17..0 | EG17..0 | EB17..0 | EA17..0 | ||||||||||||||||||||||||||||
23 | 22 | 21 | 20 | 19 | 95 | 23 | 22 | 43 | 42 | 41 | 40 | 39 | 95 | 43 | 42 | 63 | 62 | 61 | 60 | 59 | 95 | 63 | 62 | 83 | 82 | 81 | 80 | 79 | 95 | 83 | 82 |
ER27..0 | EG27..0 | EB27..0 | EA27..0 | ||||||||||||||||||||||||||||
28 | 27 | 26 | 25 | 24 | 96 | 28 | 27 | 48 | 47 | 46 | 45 | 44 | 96 | 48 | 47 | 68 | 67 | 66 | 65 | 64 | 96 | 68 | 67 | 88 | 87 | 86 | 85 | 84 | 96 | 88 | 87 |
ER37..0 | EG37..0 | EB37..0 | EA37..0 | ||||||||||||||||||||||||||||
33 | 32 | 31 | 30 | 29 | 97 | 33 | 32 | 53 | 52 | 51 | 50 | 49 | 97 | 53 | 52 | 73 | 72 | 71 | 70 | 69 | 97 | 73 | 72 | 93 | 92 | 91 | 90 | 89 | 97 | 93 | 92 |
A texel in a block with one subset is always considered to be in subset zero. Otherwise, a number encoded in the partition bits is used to look up a partition pattern in Table 49 or Table 50 for 2 subsets and 3 subsets respectively. This partition pattern is accessed by the relative x and y offsets within the block to determine the subset which defines the pixel at these coordinates.
The endpoint colors are interpolated using index values stored in the block. The index bits are stored in y-major order. That is, the bits for the index value corresponding to a relative (x, y) position of (0, 0) are stored in increasing order in the lowest index bits of the block (but see the next paragraph about anchor indices), the next bits of the block in increasing order store the index bits of (1, 0), followed by (2, 0) and (3, 0), then (0, 1) etc.
Each index has the number of bits indicated by the mode except for one special index per subset called the anchor index. Since the interpolation scheme between endpoints is symmetrical, we can save one bit on one index per subset by ordering the endpoints such that the highest bit for that index is guaranteed to be zero — and not storing that bit.
Each anchor index corresponds to an index in the corresponding partition number in Table 49 or Table 50, and are indicated in bold italics in those tables. In partition zero, the anchor index is always index zero — that is, at a relative position of (0,0) (as can be seen in Table 49 and Table 50, index 0 always corresponds to partition zero). In other partitions, the anchor index is specified by Table 51, Table 52, and Table 53.
| |
In summary, the bit offset for index data with relative x,y coordinates within the texel block is: \begin{align*}
\textrm{index offset}_{x,y} &= \begin{cases}
0, & x = y = 0 \\
\textrm{IB} \times (x + 4\times y) - 1, & \textrm{NS} = 1,\ 0 < x + 4\times y \\
\textrm{IB} \times (x + 4\times y) - 1, & \textrm{NS} = 2,\ 0 < x + 4\times y \leq \textrm{anchor}_2[\mathit{part}] \\
\textrm{IB} \times (x + 4\times y) - 2, & \textrm{NS} = 2,\ \textrm{anchor}_2[\mathit{part}] < x + 4\times y \\
\textrm{IB} \times (x + 4\times y) - 1, & \textrm{NS} = 3,\ 0 < x + 4\times y \leq \textrm{anchor}_{3,2}[\mathit{part}],\ x + 4\times y \leq \textrm{anchor}_{3,2}[\mathit{part}]\\
\textrm{IB} \times (x + 4\times y) - 3, & \textrm{NS} = 3,\ x + 4\times y > \textrm{anchor}_{3,2}[\mathit{part}],\ x + 4\times y > \textrm{anchor}_{3,3}[\mathit{part}] \\
\textrm{IB} \times (x + 4\times y) - 2, & \textrm{NS} = 3,\ \textrm{otherwise} \\
\end{cases} \\
\end{align*} where anchor2 is Table 51, anchor3,2 is Table 52, anchor3,3 is Table 53, and part is encoded in the partition selection bits PB. |
If secondary index bits are present, they follow the primary index bits and are read in the same manner. The anchor index information is only used to determine the number of bits each index has when read from the block data.
The endpoint color and alpha values used for final interpolation are the decoded values corresponding to the applicable subset as selected above. The index value for interpolating color comes from the secondary index bits for the texel if the mode has an index selection bit and its value is one, and from the primary index bits otherwise. The alpha index comes from the secondary index bits if the block has a secondary index and the block either doesn’t have an index selection bit or that bit is zero, and from the primary index bits otherwise.
| |
As an example of the texel decode process, consider a block encoded with mode 2 — that is, M0 = 0, M1 = 0, M2 = 1. This mode has three subsets, so Table 50 is used to determine which subset applies to each texel. Let us assume that this block has partition pattern 6 encoded in the partition selection bits, and that we wish to decode the texel at relative (x, y) offset (1, 2) — that is, index 9 in y-major order. We can see from Table 50 that this texel is partitioned into subset 1 (the second of three), and therefore by endpoints 2 and 3. Mode 2 stores two index bits per texel, except for index 0 (which is the anchor index for subset 0), index 15 (for subset 1, as indicated in Table 52) and index 3 (for subset 2, as indicated in Table 53). Index 9 is therefore stored in two bits starting at index bits offset 14 (for indices 1..2 and 4..8) plus 2 (for indices 0 and 3) — a total of 16 bit offset into the index bits or, as seen in Table 46, bits 115 and 116 of the block. These two bits are used to interpolate between endpoints 2 and 3 using Equation 1 with weights from the two-bit index row of Table 54, as described below. |
Table 49. Partition table for 2-subset BPTC, with the 4×4 block of values for each partition number
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | |||||||||||||||||||||||||||||||
0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | |||||||
0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | |||||||
0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | |||||||
0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | |||||||
8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | |||||||||||||||||||||||||||||||
0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |||||||
0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | |||||||
0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | |||||||
0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||||||
16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | |||||||||||||||||||||||||||||||
0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | |||||||
1 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | |||||||
1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | |||||||
1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | |||||||
24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | |||||||||||||||||||||||||||||||
0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | |||||||
0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | |||||||
0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | |||||||
0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | |||||||
32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | |||||||||||||||||||||||||||||||
0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 1 | |||||||
0 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | |||||||
0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 0 | |||||||
0 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | |||||||
40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | |||||||||||||||||||||||||||||||
0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | |||||||
0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | |||||||
1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 1 | 0 | |||||||
1 | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | |||||||
48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | |||||||||||||||||||||||||||||||
0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | |||||||
1 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | |||||||
0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | |||||||
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | |||||||
56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | |||||||||||||||||||||||||||||||
0 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 1 | 0 | 0 | |||||||
1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 1 | 0 | 0 | |||||||
1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | |||||||
1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | |||||||
Table 50. Partition table for 3-subset BPTC, with the 4×4 block of values for each partition number
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | |||||||||||||||||||||||||||||||
0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 2 | 2 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 2 | 2 | 0 | 0 | 1 | 1 | |||||||
0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 2 | 0 | 0 | 1 | 0 | 0 | 2 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 2 | 2 | 0 | 0 | 1 | 1 | |||||||
0 | 2 | 2 | 1 | 2 | 2 | 1 | 1 | 2 | 2 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | 1 | 2 | 2 | 0 | 0 | 2 | 2 | 1 | 1 | 1 | 1 | 2 | 2 | 1 | 1 | |||||||
2 | 2 | 2 | 2 | 2 | 2 | 2 | 1 | 2 | 2 | 1 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 2 | 2 | 0 | 0 | 2 | 2 | 1 | 1 | 1 | 1 | 2 | 2 | 1 | 1 | |||||||
8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | |||||||||||||||||||||||||||||||
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 2 | 0 | 1 | 1 | 2 | 0 | 1 | 2 | 2 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | |||||||
0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 1 | 2 | 0 | 1 | 1 | 2 | 0 | 1 | 2 | 2 | 0 | 1 | 1 | 2 | 2 | 0 | 0 | 1 | |||||||
1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 2 | 2 | 2 | 2 | 0 | 0 | 1 | 2 | 0 | 1 | 1 | 2 | 0 | 1 | 2 | 2 | 1 | 1 | 2 | 2 | 2 | 2 | 0 | 0 | |||||||
2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 0 | 0 | 1 | 2 | 0 | 1 | 1 | 2 | 0 | 1 | 2 | 2 | 1 | 2 | 2 | 2 | 2 | 2 | 2 | 0 | |||||||
16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | |||||||||||||||||||||||||||||||
0 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 2 | 2 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |||||||
0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | 1 | 2 | 2 | 0 | 0 | 2 | 2 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 0 | |||||||
0 | 1 | 1 | 2 | 2 | 0 | 0 | 1 | 1 | 1 | 2 | 2 | 0 | 0 | 2 | 2 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 1 | 0 | 1 | 2 | 2 | 2 | 2 | 1 | 0 | |||||||
1 | 1 | 2 | 2 | 2 | 2 | 0 | 0 | 1 | 1 | 2 | 2 | 1 | 1 | 1 | 1 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 1 | 0 | 1 | 2 | 2 | 2 | 2 | 1 | 0 | |||||||
24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | |||||||||||||||||||||||||||||||
0 | 1 | 2 | 2 | 0 | 0 | 1 | 2 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2 | 2 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | |||||||
0 | 1 | 2 | 2 | 0 | 0 | 1 | 2 | 1 | 2 | 2 | 1 | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 2 | 0 | 1 | 1 | 0 | 0 | 1 | 2 | 2 | 2 | 0 | 0 | 0 | |||||||
0 | 0 | 1 | 1 | 1 | 1 | 2 | 2 | 1 | 2 | 2 | 1 | 1 | 2 | 2 | 1 | 1 | 1 | 0 | 2 | 2 | 0 | 0 | 2 | 0 | 1 | 2 | 2 | 2 | 2 | 1 | 1 | |||||||
0 | 0 | 0 | 0 | 2 | 2 | 2 | 2 | 0 | 1 | 1 | 0 | 1 | 2 | 2 | 1 | 0 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 0 | 0 | 1 | 1 | 2 | 2 | 2 | 1 | |||||||
32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | |||||||||||||||||||||||||||||||
0 | 0 | 0 | 0 | 0 | 2 | 2 | 2 | 0 | 0 | 1 | 1 | 0 | 1 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 2 | 0 | 0 | 1 | 2 | 0 | 0 | 0 | 1 | 1 | |||||||
0 | 0 | 0 | 2 | 0 | 0 | 2 | 2 | 0 | 0 | 1 | 2 | 0 | 1 | 2 | 0 | 1 | 1 | 1 | 1 | 1 | 2 | 0 | 1 | 2 | 0 | 1 | 2 | 2 | 2 | 0 | 0 | |||||||
1 | 1 | 2 | 2 | 0 | 0 | 1 | 2 | 0 | 0 | 2 | 2 | 0 | 1 | 2 | 0 | 2 | 2 | 2 | 2 | 2 | 0 | 1 | 2 | 1 | 2 | 0 | 1 | 1 | 1 | 2 | 2 | |||||||
1 | 2 | 2 | 2 | 0 | 0 | 1 | 1 | 0 | 2 | 2 | 2 | 0 | 1 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 2 | 0 | 0 | 1 | 2 | 0 | 0 | 0 | 1 | 1 | |||||||
40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | |||||||||||||||||||||||||||||||
0 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 2 | 2 | 0 | 0 | 2 | 2 | 0 | 2 | 2 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | |||||||
1 | 1 | 2 | 2 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 2 | 2 | 0 | 0 | 1 | 1 | 1 | 2 | 2 | 1 | 2 | 2 | 2 | 2 | 2 | 1 | 2 | 1 | |||||||
2 | 2 | 0 | 0 | 2 | 2 | 2 | 2 | 2 | 1 | 2 | 1 | 0 | 0 | 2 | 2 | 0 | 0 | 2 | 2 | 0 | 2 | 2 | 0 | 2 | 2 | 2 | 2 | 2 | 1 | 2 | 1 | |||||||
0 | 0 | 1 | 1 | 2 | 2 | 2 | 2 | 2 | 1 | 2 | 1 | 1 | 1 | 2 | 2 | 0 | 0 | 1 | 1 | 1 | 2 | 2 | 1 | 0 | 1 | 0 | 1 | 2 | 1 | 2 | 1 | |||||||
48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | |||||||||||||||||||||||||||||||
0 | 1 | 0 | 1 | 0 | 2 | 2 | 2 | 0 | 0 | 0 | 2 | 0 | 0 | 0 | 0 | 0 | 2 | 2 | 2 | 0 | 0 | 0 | 2 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | |||||||
0 | 1 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 2 | 2 | 1 | 1 | 2 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 2 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | |||||||
0 | 1 | 0 | 1 | 0 | 2 | 2 | 2 | 0 | 0 | 0 | 2 | 2 | 1 | 1 | 2 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 2 | 0 | 1 | 1 | 0 | 2 | 1 | 1 | 2 | |||||||
2 | 2 | 2 | 2 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 2 | 2 | 1 | 1 | 2 | 0 | 2 | 2 | 2 | 0 | 0 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 1 | 1 | 2 | |||||||
56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | |||||||||||||||||||||||||||||||
0 | 1 | 1 | 0 | 0 | 0 | 2 | 2 | 0 | 0 | 2 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2 | 0 | 2 | 2 | 2 | 0 | 1 | 0 | 1 | 0 | 1 | 1 | 1 | |||||||
0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 2 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 0 | 1 | 1 | |||||||
2 | 2 | 2 | 2 | 0 | 0 | 1 | 1 | 1 | 1 | 2 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2 | 0 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 0 | 1 | |||||||
2 | 2 | 2 | 2 | 0 | 0 | 2 | 2 | 0 | 0 | 2 | 2 | 2 | 1 | 1 | 2 | 0 | 0 | 0 | 1 | 1 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 0 | |||||||