XXX - Not complete -- needs errors & GLX protocol work Name SGIX_icc_texture Name Strings GL_SGIX_icc_texture Version $Date: 1999/06/09 18:23:05 $ $Revision: 1.16 $ Number 154 Dependencies OpenGL 1.1 is required. EXT_texture3D affects the definition of this extension SGIS_texture4D affects the definition of this extension Overview This extension defines new host and internal formats for the storage of compressed images. The formats utilize a variant of color cell compression, in which 4x4 pixel blocks are represented by two color values and a two bit index per pixel. Two additional values are interpolated between the two explicitly stored values, and each pixel's index selects one of these four values. For RGB and RGBA images, two RGB colors and a single index per pixel are used to store the R, G, and B channels. For RGBA and LUMINANCE_ALPHA formats, the alpha channel is encoded independently using two alpha values and an index per pixel. Issues - Do we really want compressed textures to be a full-blown host format that may be used to specify things like color tables? Orthogonality says yes, simplicity says no. A: ICC formats don't seem useful for things other than textures so limit it to that. - What about one, three, and four dimensional textures? A: Three and four should work as stacks of 2D textures. One could be made to work but the natural hardware implementation would be to have a block represent a 16x1 subimage. The locality probably wouldn't be good and equivalent results could be obtained with texture filtering. - Method of dealing with width & height of host image is awkward when downloading small mipmap levels since UNPACK_ROW_LENGTH must be set. Should we say that the rounding up happens automatically? A: Yes. - Should unpacking of ICC formats be described in the section about pixel rectangles (with the rest of the unpacking) or in the section about texture downloads (since they cannot be used in any other situation)? Similar question for readbacks. - There are still some problems with the sized and base internal formats. We're ok for now since there is only one sized internal format for each base internal format. Can we get rid of the unsized internal formats? - Need to say that pixel transfer modes are not applied. Ideally this should be done in such a way that removing this restriction in a later extension is not a problem. We could say that trying to do a ICC download with a non-identity pixel transfer operation applied results in an error, but checking for non-identity pixel transfer operations can be tricky. - Is there any way to change this extension such that implementations which don't support a certain compressed format can "fake it?" With the "no compressor" limitation this might require the texture manager to maintain a shadowed copy of the compressed texture and put decompressed versions in texture memory. - Need to document behavior when interlacing is on. Won't work but should it be ignored or an error? Reasoning - This spec is designed to avoid adding the ability to compress into the ICC formats within GL. Therefore, we do not allow subtexture downloads which are not aligned to the 4x4 tile size or downloads of host images which are not already in a ICC format. This ability can be added by a subsequent extension. For now, the compression should go in a GLU extension. New Procedures and Functions None New Tokens Accepted by the parameter of TexImage2D, TexImage3DEXT, and TexImage4DSGIS: RGB_ICC_SGIX 0x8460 RGBA_ICC_SGIX 0x8461 ALPHA_ICC_SGIX 0x8462 LUMINANCE_ICC_SGIX 0x8463 INTENSITY_ICC_SGIX 0x8464 LUMINANCE_ALPHA_ICC_SGIX 0x8465 Accepted by the and parameters of TexImage2D, TexImage3DEXT, and TexImage4DSGIS: R5_G6_B5_ICC_SGIX 0x8466 R5_G6_B5_A8_ICC_SGIX 0x8467 ALPHA16_ICC_SGIX 0x8468 LUMINANCE16_ICC_SGIX 0x8469 INTENSITY16_ICC_SGIX 0x846A LUMINANCE16_ALPHA8_ICC_SGIX 0x846B Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation) None Additions to Chapter 3 of the 1.1 Specification (Rasterization) The following is added to the end if the last paragraph in the introduction: "Six ICC formats are described in this section: R5_G6_B5_ICC_SGIX, R5_G6_B5_A8_ICC_SGIX, ALPHA16_ICC_SGIX, LUMINANCE16_ICC_SGIX, INTENSITY16_ICC_SGIX, and LUMINANCE16_ALPHA8_ICC_SGIX. The ICC formats are used only as arguments to texture download commands and not as arguments to other commands which take pixel data from client memory. If the format argument to a command other than a texture download command is an enumerant for a ICC format, the error INVALID_ENUM is generated. Other restrictions on the use of ICC formats are described below and in Section 3.8" The following is added to section 3.6.3 at the end of the subsection entitled "Unpacking": If the data in host memory is in one of the ICC formats, the data is treated as being a sequence of blocks each of which represents a 4x4 pixel subimage. The blocks are stored in a row-major order, analogous to the host memory storage of pixels. The length of each block in words and how it is decoded depends on the specific ICC format. This information is given in the subsection "Decompression from ICC." For each format, the block length is a non-zero integer number of words. The type argument to the function must be set to GL_UNSIGNED_SHORT or the error INVALID_ENUM will be generated. A ICC-compressed image in host memory must be made of complete 4x4 blocks. The width and height arguments give the uncompressed size and both must be multiples of four. The number of pixels in a row of the host image is determined in the same manner as for uncompressed host images. If this value is not a multiple of four, it is rounded up to the next multiple of four. The resulting value is referred to as l. If p indicates the location in memory of the first byte of the first block of the first row, then the first byte of the first block of the Nth row is indicated by p + (N/4)k where N is the row number (counting from zero). N must be a multiple of four; rows which are not four-aligned may not be individually accessed. k is defined as: k = ceil(sl / a) * a where s is the size of a block for the given format in GL ubytes and a is the value of UNPACK_ALIGNMENT. The height h of the host image is assumed to be: h = ceil((height + s) / 4) * 4 where s is the value of SKIP_ROWS and height is the value of the height argument to the pixel function. In other words, the sum of the value of SKIP_ROWS and the height argument to the function is rounded up to the next multiple of four to give the height of the host image. Subrectangles of ICC images may be extracted in a manner similar to uncompressed images as determined by the parameters UNPACK_ROW_LENGTH, UNPACK_SKIP_ROWS, and UNPACK_SKIP_PIXELS. For compressed images, the lower left corner of the subrectangle must be aligned to four-pixel boundaries in both x and y. The values of UNPACK_SKIP_ROWS and UNPACK_SKIP_PIXELS must be multiples of four (positive, negative, or zero) or the error INVALID_OPERATION is generated. Before obtaining the first group from memory, the pointer p is effectively advanced by (UNPACK_SKIP_PIXELS / 4)s + (UNPACK_SKIP_ROWS/4)k bytes. ceil(width / 4) blocks are obtained from contiguous memory (without advancing the pointer), after which the pointer is advanced by k bytes. ceil(height/4) sets of ceil(width/4) blocks are obtained this way. The following is added to the end of table 3.5: Element Meaning Target Name and Order Buffer ---- --------------- -------- RGB_ICC_SGIX R, G, B Components Color RGBA_ICC_SGIX R, G, B, A Components Color LUMINANCE_ICC_SGIX Luminance Component Color LUMINANCE_ALPHA_ICC_SGIX Luminance, A Components Color The following subsection is added to section 3.6.3 just prior to the subsection entitled "Conversion to floating-point": Decompression from ICC After being extracted from host memory, a ICC-compressed image is converted into a floating-point color image. Each 4x4 block is decompressed independently using mechanisms described below. We start by describing mechanisms we will describe mechanisms common to all ICC formats and then describe the organization of the data within a block for each format. In this section, we assume that byte swapping (if SWAP_BYTES is TRUE) has already taken place. Each ICC format contains one or two fields containing 2-bit indices for the each of the 16 pixels in the block. Within the field, the indices are stored in bottom-to-top, left-to-right order regardless of user-specified pixel storage modes. The index of the bottom left pixel is stored in the two high-order bits of the first byte of the field. The index of the top right pixel is stored in the low-order bits of the last byte. For ICC formats which contain RGB data (R5_G6_B5_ICC_SGIX and R5_G6_B5_A8_ICC_SGIX), two field contain RGB color values. The fields are each 16 bits wide with the top 5 bits specifying the red value, the middle 6 bits specifying the green value, and the lower 5 bits specifying the blue value. For ICC formats which contain luminance data (LUMINANCE16_ICC_SGIX and LUMINANCE16_ALPHA8_ICC_SGIX), two 16-bit wide fields contain luminance values. For ICC formats which contain alpha data (R5_G6_B5_A8_ICC_SGIX and LUMINANCE16_ALPHA8_ICC_SGIX), two 8-bit wide fields contain alpha values. For each channel, the bits are interpreted as unsigned fixed-point values between 0 and 1 and are converted to floating point using the formula: f = c / ((2**N) - 1) where f is the floating-point representation of the value, c is the value of the bitfield (interpreted as an unsigned integer), N is the number of bits in the fixed-point color value, and the division is performed in floating-point. Once the color fields have been extracted and converted into floating point RGB, L, or A values, intermediate values are constructed from them. For each pair of fields c0 and c1, four values are created: v0 = c0 v1 = (2 * c0 + c1) / 3 v2 = (c0 + 2 * c1) / 3 v3 = c1 Operations are performed with unspecified precision. For fields which encode RGB data, the computations are performed independently on a per-channel basis to give the vectors RGB0, RGB1, RGB2, and RGB3. For fields which encode alpha data, the computations give the values A0, A1, A2, and A3. For fields which encode luminance data, the computations give L0, L1, L2, and L3. After the intermediate values are created, indices for each pixel are used to choose the output value for the pixel. The indices are each two bits. R5_G6_B5_ICC_SGIX values contain one index per pixel to choose the intermediate value RGB0, RGB1, RGB2, or RGB3. R5_G6_B5_A8_ICC_SGIX values contain two indices per pixel: one to choose the RGB value and one to choose the alpha value. Similarly, LUMINANCE16_A8_ICC_SGIX values contain an index per pixel to choose the luminance value and an index per pixel to choose the alpha value. LUMINANCE16_ICC_SGIX values contain an index per pixel to choose the luminance value. In each case, an index value of 0 results in the channel (or channels) being set to the 0th intermediate value (RGB0, A0, or L0). A value of 1 gives the 1st intermediate value and so on. The bit encodings for the formats are described below. Each description assumes that the first byte is in the lowest memory location and the last byte is in the highest memory location. The high-order bit of each byte is assumed to be the "first." An R5_G6_B5_ICC_SGIX encoded block consists of 64 bits divided into 3 fields. The first is a 32 bit field containing the two-bit indices for the RGB channels. The second and third fields are 16 bit R5G6B5 values containing c0 and c1 for the RGB channels. R5_G6_B5_A8_ICC_SGIX blocks encode RGB and alpha independently. An R5_G6_B5_A8_ICC_SGIX encoded block consists of 128 bits divided into 7 fields. The first 64 bits of the block contain the two-bit RGB indices followed by the two 16-bit R5G6B5 values for c0 and c1 (this encoding is equivalent to the 64-bit R5_G6_B5_ICC_SGIX block described above). The fourth field is 32 bits wide and contains indices for the alpha values. The fifth and sixth fields are 8 bit alpha representing c0 and c1. The seventh field is 16 bits wide and is unused. It is necessary to pad out the block so that the 16-bit color boundaries will always fall on half-word boundaries in host memory. An ALPHA16_ICC_SGIX, LUMINANCE16_ICC_SGIX, or INTENSITY16_ICC_SGIX encoded block consists of 64 bits divided into 3 fields. The first is a 32 bit field containing the two-bit indices for the alpha, luminance, or intensity values. The second and third fields are 16 bit unsigned fixed-point alpha, luminance, or intensity values containing c0 and c1 respectively. This encoding is identical to the encoding of R5_G6_B5_ICC_SGIX blocks except that the c0 and c1 fields represent alpha, luminance, or intensity instead of RGB. A LUMINANCE16_ALPHA8_ICC_SGIX encoded block is identical to a R5_G6_B5_A8_ICC_SGIX block except that sixteen-bit unsigned luminance values are stored in place of the sixteen-bit RGB values. After decompression, the image is recombined into a ceil(width / 4) * 4 by ceil(height / 4) * 4 image of RGB, RGBA, A, L, I, or LA pixels. Pixels whose y positions in the image (where the bottom row is 0 and the top row is (ceil(height / 4) * 4) - 1) are greater than (height - 1) are discarded. Likewise, pixels whose x positions are greater than (width - 1) are discarded. The following is added to Section 3.8: In the paragraph beginning "The image itself (pointed to by data)" the sentence beginning "Each color component is converted" is prefixed by "If the internal format of the texture is not one of RGB_ICC_SGIX, RGBA_ICC_SGIX, LUMINANCE_ICC_SGIX, LUMINANCE_ALPHA_ICC_SGIX, R5_G6_B5_ICC_SGIX, R5_G6_B5_A8_ICC_SGIX, LUMINANCE16_ICC_SGIX, or LUMINANCE16_ALPHA8_ICC_SGIX." The following is added to the end of the paragraph: "If the internal format is one of the ICC formats, the format parameter of the function must either be equal to the internal format parameter (if the internal format parameter is sized) or contain the same channels as the internal format (if the internal format is unsized) or the error INVALID_ENUM will be generated. Also, a ICC internal format may not be specified for a one-dimensional texture. If the format parameter to TexImage1D is set to one of the ICC internal formats, the error INVALID_ENUM is generated." The sentence in the paragraph describing CopyTexImage2D which reads: "Parameters level, internalformat, and border are specified using the same values, with the same meanings, as the equivalent arguments of TexImage2D, except that internalformat may not be specified as 1, 2, 3, or 4." is changed to read: "Parameters level, internalformat, and border are specified using the same values, with the same meanings, as the equivalent arguments of TexImage2D, except that internalformat may not be specified as 1, 2, 3, 4, or any of the ICC internal formats." The following is added to the end of the paragraph which describes the subtexture download and copy commands: "CopyTexSubImage1D and CopyTexSubImage2D may not be used with a target texture whose internal format is one of the ICC formats or the error INVALID_OPERATION is generated. For TexSubImage1D and TexSubImage2D, the target texture have a ICC internal format but requirements in addition to those mentioned above are enforced. The xoffset and yoffset parameters must be multiples of four or the error INVALID_OPERATION is generated. Also, the width parameter must either be a multiple of four which is less than the width of the texture minus xoffset or be equal to the width of the texture minus xoffset or the error INVALID_VALUE is generated. The height parameter must either a multiple of four which is less than the height of the texture minus yoffset or be equal to the height of the texture minus yoffset or the error INVALID_VALUE is generated. In other words, the subimage may not partially cover a 4x4 region of the target texture. Additionally, for TexSubImage2D, TexSubImage3DEXT, and TexSubImage4DSGIS calls, the format parameter must have the same channels as the base internal format of the texture or the error INVALID_ENUM will be generated." The following is added to Table 3.8: Sized Base R G B A L I Internal Format Internal Format Bits Bits Bits Bits Bits Bits --------------- --------------- ---- ---- ---- ---- ---- ---- R5_G6_B5_ICC_SGIX RGB 5 6 5 R5_G6_B5_A8_ICC_SGIX RGBA 5 6 5 8 LUMINANCE16_ICC_SGIX LUMINANCE 16 LUMINANCE16_ALPHA8_ICC_SGIX LUMINANCE_ALPHA 8 16 The caption for Table 3.8 is updated as follows: Correspondence of sized internal formats to base internal formats and desired component resolutions for each sized internal format. For ICC compressed formats, the component resolutions do not directly reflect the stored size of each pixel, but rather the resolution of the two color values stored for each 4x4 pixel block. Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations and the Frame Buffer) The following is added to the first paragraph of section 4.3.2 after the sentence beginning "The arguments after x and y: "As in the case of TexImage, ICC formats may only be used for reading back ICC textures or the error INVALID_ENUM is generated. For more information, see Chapter 6 (State and State Requests). Additionally, the host ICC format must have the same channels as the base internal format of the source ICC texture of the error INVALID_ENUM is generated. During TexSubImage readbacks of ICC textures, the " Additions to Chapter 5 of the 1.1 Specification (Special Functions) None Additions to Chapter 6 of the 1.1 Specification (State and State Requests) Added to the end of the paragraph in the introduction which talks about the GetTexImage command: "Additional restrictions apply if the format is one of the ICC formats. The internal format of the texture must have a base internal format equal to the format parameter or the error INVALID_ENUM is generated. Similarly to the download case, the width and height of the data read back is rounded up to the next multiples of 4 such that only complete compressed tiles are returned." Additions to the GLX Specification None Dependencies on EXT_texture3D If EXT_texture3D is not supported, all references to TexImage3DEXT, TexSubImage3DEXT, CopyTexImage3DEXT, and CopyTexSubImage3DEXT are ignored. Dependencies on SGIS_texture4D If SGIS_texture4D is not supported, all references to TexImage4DSGIS, TexSubImage4DSGIS, CopyTexImage4DSGIS, and CopyTexSubImage4DSGIS are ignored. Errors XXX New State None New Implementation Dependent State None