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.

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 (C_B) and V (C_R), supplemented by channels for alpha, depth and stencil, as shown in Table 10. These formats are distinguished by C_B and C_R 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′C_BC_R and RGB color spaces is defined in this case by the choice of value in the colorPrimaries field as described in Section 15.1.

	Most single-channel luma/luminance monochrome data formats should select KHR_DF_MODEL_YUVSDA and use only the Y channel, unless there is a reason to do otherwise.

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. See Section 15.1 for more detail.

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 C_B and C_R by a 33-degree rotation.

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.

This color model represents secondary (subtractive) colors and the combined key (black) channel, along with alpha, as shown in Table 13.

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.

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.

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.

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.

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.

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.

This color model represents the “Constant luminance” $Y'_CC'_\mathit{BC}C'_\mathit{RC}$ color model defined as an optional representation in ITU-T BT.2020 and described in Section 15.2.

This color model represents the “Constant intensity IC_TC_P color model” defined as an optional representation in ITU-T BT.2100 and described in Section 15.3.

This color model represents channel data used to describe color coordinates in the CIE 1931 XYZ coordinate space, as shown in Table 22.

This color model represents channel data used to describe chromaticity coordinates in the CIE 1931 xyY coordinate space, as shown in Table 23.

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

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 and described in Section 14.1, 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′C_BC_R (YUV) representation uses the color conversion matrix defined in the BT.709 specification, and described in Section 15.1.1, except in the case of sYCC (which can be distinguished by the use of the sRGB transfer function), in which case conversion to and from BT.709 Y′C_BC_R representation uses the color conversion matrix defined in the BT.601 specification, and described in Section 15.1.2. 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, and described in Section 14.2. Conversion to and from BT.601 Y′C_BC_R (YUV) typically uses the color conversion matrix defined in the BT.601 specification and described in Section 15.1.2.

This value represents the Color Primaries defined in the ITU-R BT.601 specification for standard-definition television, particularly for 525-line signals, and described in Section 14.3. Conversion to and from BT.601 Y′C_BC_R (YUV) typically uses the color conversion matrix defined in the BT.601 specification and described in Section 15.1.2.

This value represents the Color Primaries defined in the ITU-R BT.2020 specification for ultra-high-definition television and described in Section 14.4. Conversion to and from BT.2020 Y′C_BC_R (YUV uses the color conversion matrix defined in the BT.2020 specification and described in Section 15.1.3.

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 and described in Section 14.7.

This value represents the Color Primaries defined for the Academy Color Encoding System compositor and described in Section 14.8.

This value represents the Color Primaries defined for the NTSC 1953 color television transmission standard and described in Section 14.5.

This value represents the Color Primaries defined for 525-line PAL signals, described in Section 14.6.

This value represents the Color Primaries defined for the Display P3 color space, described in Section 14.9.

This value represents the Color Primaries defined in Adobe RGB (1998), described in Section 14.10.

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. This is described in Section 13.3.

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 is described in Section 13.2.

This value represents the non-linear transfer function defined by the original NTSC television broadcast specification. This is described in Section 13.8.

	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, and is described in Section 13.13.

This value represents a nonlinear Transfer Function used by some Sony video cameras to represent a further increased dynamic range, and is described in Section 13.14.

This value represents the nonlinear OETF defined in BT.1886 and described in Section 13.4.

This value represents the Hybrid Log Gamma OETF defined by the ITU in BT.2100 for high dynamic range television, and described in Section 13.5.

This value represents the Hybrid Log Gamma OETF defined by the ITU in BT.2100 for high dynamic range television, and described in Section 13.5.

This value represents the Perceptual Quantization EOTF defined by the ITU in BT.2100 for high dynamic range television, and described in Section 13.6.

This value represents the Perceptual Quantization EOTF defined by the ITU in BT.2100 for high dynamic range television, and described in Section 13.6.

This value represents the transfer function defined in DCI P3 and described in Section 13.7.

This value represents the OETF for legacy PAL systems described in Section 13.9.

This value represents the EOTF for legacy 625-line PAL systems described in Section 13.10.

This value represents the transfer function associated with the legacy ST-240 (SMPTE240M) standard, described in Section 13.11.

This value represents the nonlinear Transfer Function used in the ACEScc Academy Color Encoding System logarithmic encoding system for use within Color Grading Systems, S-2014-003, defined in [aces]. This is described in Section 13.15.

This value represents the nonlinear Transfer Function used in the ACEScc Academy Color Encoding System quasi-logarithmic encoding system for use within Color Grading Systems, S-2016-001, defined in [aces]. This is described in Section 13.16.

This value represents the transfer function defined in the Adobe RGB (1998) specification and described in Section 13.12.

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 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′C_BC_R, 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′C_BC_R, 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.

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