1XXX - Not complete -- needs errors & GLX protocol 2work 3 4 5Name 6 7 SGIX_icc_texture 8 9Name Strings 10 11 GL_SGIX_icc_texture 12 13Version 14 15 $Date: 1999/06/09 18:23:05 $ $Revision: 1.16 $ 16 17Number 18 19 154 20 21Dependencies 22 23 OpenGL 1.1 is required. 24 EXT_texture3D affects the definition of this extension 25 SGIS_texture4D affects the definition of this extension 26 27Overview 28 29 This extension defines new host and internal formats for the 30 storage of compressed images. The formats utilize a variant of 31 color cell compression, in which 4x4 pixel blocks are represented 32 by two color values and a two bit index per pixel. Two additional 33 values are interpolated between the two explicitly stored values, 34 and each pixel's index selects one of these four values. For RGB 35 and RGBA images, two RGB colors and a single index per pixel are 36 used to store the R, G, and B channels. For RGBA and 37 LUMINANCE_ALPHA formats, the alpha channel is encoded 38 independently using two alpha values and an index per pixel. 39 40Issues 41 42 - Do we really want compressed textures to be a full-blown host 43 format that may be used to specify things like color tables? 44 Orthogonality says yes, simplicity says no. 45 46 A: ICC formats don't seem useful for things other than textures 47 so limit it to that. 48 49 - What about one, three, and four dimensional textures? 50 51 A: Three and four should work as stacks of 2D textures. One 52 could be made to work but the natural hardware implementation 53 would be to have a block represent a 16x1 subimage. The 54 locality probably wouldn't be good and equivalent results could 55 be obtained with texture filtering. 56 57 - Method of dealing with width & height of host image is awkward 58 when downloading small mipmap levels since UNPACK_ROW_LENGTH 59 must be set. Should we say that the rounding up happens 60 automatically? 61 62 A: Yes. 63 64 - Should unpacking of ICC formats be described in the section 65 about pixel rectangles (with the rest of the unpacking) or in 66 the section about texture downloads (since they cannot be used 67 in any other situation)? Similar question for readbacks. 68 69 - There are still some problems with the sized and base internal 70 formats. We're ok for now since there is only one sized 71 internal format for each base internal format. Can we get rid 72 of the unsized internal formats? 73 74 - Need to say that pixel transfer modes are not applied. Ideally this 75 should be done in such a way that removing this restriction in a 76 later extension is not a problem. We could say that trying to 77 do a ICC download with a non-identity pixel transfer operation 78 applied results in an error, but checking for non-identity pixel 79 transfer operations can be tricky. 80 81 - Is there any way to change this extension such that 82 implementations which don't support a certain compressed format 83 can "fake it?" With the "no compressor" limitation this might 84 require the texture manager to maintain a shadowed copy of the 85 compressed texture and put decompressed versions in texture 86 memory. 87 88 - Need to document behavior when interlacing is on. Won't work 89 but should it be ignored or an error? 90 91Reasoning 92 93 - This spec is designed to avoid adding the ability to compress 94 into the ICC formats within GL. Therefore, we do not allow 95 subtexture downloads which are not aligned to the 4x4 tile size 96 or downloads of host images which are not already in a ICC 97 format. This ability can be added by a subsequent extension. 98 For now, the compression should go in a GLU extension. 99 100New Procedures and Functions 101 102 None 103 104New Tokens 105 106 Accepted by the <internalformat> parameter of TexImage2D, 107 TexImage3DEXT, and TexImage4DSGIS: 108 109 RGB_ICC_SGIX 0x8460 110 RGBA_ICC_SGIX 0x8461 111 ALPHA_ICC_SGIX 0x8462 112 LUMINANCE_ICC_SGIX 0x8463 113 INTENSITY_ICC_SGIX 0x8464 114 LUMINANCE_ALPHA_ICC_SGIX 0x8465 115 116 Accepted by the <internalformat> and <format> parameters of 117 TexImage2D, TexImage3DEXT, and TexImage4DSGIS: 118 119 R5_G6_B5_ICC_SGIX 0x8466 120 R5_G6_B5_A8_ICC_SGIX 0x8467 121 ALPHA16_ICC_SGIX 0x8468 122 LUMINANCE16_ICC_SGIX 0x8469 123 INTENSITY16_ICC_SGIX 0x846A 124 LUMINANCE16_ALPHA8_ICC_SGIX 0x846B 125 126Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation) 127 128 None 129 130Additions to Chapter 3 of the 1.1 Specification (Rasterization) 131 132 The following is added to the end if the last paragraph in the 133 introduction: "Six ICC formats are described in this section: 134 R5_G6_B5_ICC_SGIX, R5_G6_B5_A8_ICC_SGIX, ALPHA16_ICC_SGIX, 135 LUMINANCE16_ICC_SGIX, INTENSITY16_ICC_SGIX, and 136 LUMINANCE16_ALPHA8_ICC_SGIX. The ICC formats are used only as 137 arguments to texture download commands and not as arguments to 138 other commands which take pixel data from client memory. If the 139 format argument to a command other than a texture download command 140 is an enumerant for a ICC format, the error INVALID_ENUM is 141 generated. Other restrictions on the use of ICC formats are 142 described below and in Section 3.8" 143 144 The following is added to section 3.6.3 at the end of the 145 subsection entitled "Unpacking": 146 147 If the data in host memory is in one of the ICC formats, the data 148 is treated as being a sequence of blocks each of which represents 149 a 4x4 pixel subimage. The blocks are stored in a row-major order, 150 analogous to the host memory storage of pixels. The length of 151 each block in words and how it is decoded depends on the specific 152 ICC format. This information is given in the subsection 153 "Decompression from ICC." For each format, the block length is a 154 non-zero integer number of words. The type argument to the 155 function must be set to GL_UNSIGNED_SHORT or the error 156 INVALID_ENUM will be generated. 157 158 A ICC-compressed image in host memory must be made of complete 4x4 159 blocks. The width and height arguments give the uncompressed size 160 and both must be multiples of four. The number of pixels in a row 161 of the host image is determined in the same manner as for 162 uncompressed host images. If this value is not a multiple of 163 four, it is rounded up to the next multiple of four. The 164 resulting value is referred to as l. If p indicates the location 165 in memory of the first byte of the first block of the first row, 166 then the first byte of the first block of the Nth row is indicated 167 by 168 169 p + (N/4)k 170 171 where N is the row number (counting from zero). N must be a 172 multiple of four; rows which are not four-aligned may not be 173 individually accessed. k is defined as: 174 175 k = ceil(sl / a) * a 176 177 where s is the size of a block for the given format in GL ubytes 178 and a is the value of UNPACK_ALIGNMENT. 179 180 The height h of the host image is assumed to be: 181 182 h = ceil((height + s) / 4) * 4 183 184 where s is the value of SKIP_ROWS and height is the value of the 185 height argument to the pixel function. In other words, the sum of 186 the value of SKIP_ROWS and the height argument to the function is 187 rounded up to the next multiple of four to give the height of the 188 host image. 189 190 Subrectangles of ICC images may be extracted in a manner similar 191 to uncompressed images as determined by the parameters 192 UNPACK_ROW_LENGTH, UNPACK_SKIP_ROWS, and UNPACK_SKIP_PIXELS. For 193 compressed images, the lower left corner of the subrectangle must 194 be aligned to four-pixel boundaries in both x and y. The values 195 of UNPACK_SKIP_ROWS and UNPACK_SKIP_PIXELS must be multiples of 196 four (positive, negative, or zero) or the error INVALID_OPERATION 197 is generated. Before obtaining the first group from memory, the 198 pointer p is effectively advanced by (UNPACK_SKIP_PIXELS / 4)s + 199 (UNPACK_SKIP_ROWS/4)k bytes. ceil(width / 4) blocks are 200 obtained from contiguous memory (without advancing the pointer), 201 after which the pointer is advanced by k bytes. ceil(height/4) 202 sets of ceil(width/4) blocks are obtained this way. 203 204 The following is added to the end of table 3.5: 205 206 Element Meaning Target 207 Name and Order Buffer 208 ---- --------------- -------- 209 RGB_ICC_SGIX R, G, B Components Color 210 RGBA_ICC_SGIX R, G, B, A Components Color 211 LUMINANCE_ICC_SGIX Luminance Component Color 212 LUMINANCE_ALPHA_ICC_SGIX Luminance, A Components Color 213 214 The following subsection is added to section 3.6.3 just prior to 215 the subsection entitled "Conversion to floating-point": 216 217 Decompression from ICC 218 219 After being extracted from host memory, a ICC-compressed image is 220 converted into a floating-point color image. Each 4x4 block is 221 decompressed independently using mechanisms described below. We 222 start by describing mechanisms we will describe mechanisms common 223 to all ICC formats and then describe the organization of the data 224 within a block for each format. In this section, we assume that 225 byte swapping (if SWAP_BYTES is TRUE) has already taken place. 226 227 Each ICC format contains one or two fields containing 2-bit 228 indices for the each of the 16 pixels in the block. Within the 229 field, the indices are stored in bottom-to-top, left-to-right 230 order regardless of user-specified pixel storage modes. The index 231 of the bottom left pixel is stored in the two high-order bits of 232 the first byte of the field. The index of the top right pixel is 233 stored in the low-order bits of the last byte. 234 235 For ICC formats which contain RGB data (R5_G6_B5_ICC_SGIX and 236 R5_G6_B5_A8_ICC_SGIX), two field contain RGB color values. The 237 fields are each 16 bits wide with the top 5 bits specifying the 238 red value, the middle 6 bits specifying the green value, and the 239 lower 5 bits specifying the blue value. For ICC formats which 240 contain luminance data (LUMINANCE16_ICC_SGIX and 241 LUMINANCE16_ALPHA8_ICC_SGIX), two 16-bit wide fields contain 242 luminance values. For ICC formats which contain alpha data 243 (R5_G6_B5_A8_ICC_SGIX and LUMINANCE16_ALPHA8_ICC_SGIX), two 8-bit 244 wide fields contain alpha values. For each channel, the bits are 245 interpreted as unsigned fixed-point values between 0 and 1 and are 246 converted to floating point using the formula: 247 248 f = c / ((2**N) - 1) 249 250 where f is the floating-point representation of the value, c is 251 the value of the bitfield (interpreted as an unsigned integer), N 252 is the number of bits in the fixed-point color value, and the 253 division is performed in floating-point. 254 255 Once the color fields have been extracted and converted into 256 floating point RGB, L, or A values, intermediate values are 257 constructed from them. For each pair of fields c0 and c1, four 258 values are created: 259 260 v0 = c0 261 v1 = (2 * c0 + c1) / 3 262 v2 = (c0 + 2 * c1) / 3 263 v3 = c1 264 265 Operations are performed with unspecified precision. For fields 266 which encode RGB data, the computations are performed independently 267 on a per-channel basis to give the vectors RGB0, RGB1, RGB2, and 268 RGB3. For fields which encode alpha data, the computations give 269 the values A0, A1, A2, and A3. For fields which encode luminance 270 data, the computations give L0, L1, L2, and L3. 271 272 After the intermediate values are created, indices for each pixel 273 are used to choose the output value for the pixel. The indices 274 are each two bits. R5_G6_B5_ICC_SGIX values contain one index per 275 pixel to choose the intermediate value RGB0, RGB1, RGB2, or RGB3. 276 R5_G6_B5_A8_ICC_SGIX values contain two indices per pixel: one to 277 choose the RGB value and one to choose the alpha value. 278 Similarly, LUMINANCE16_A8_ICC_SGIX values contain an index per 279 pixel to choose the luminance value and an index per pixel to 280 choose the alpha value. LUMINANCE16_ICC_SGIX values contain an 281 index per pixel to choose the luminance value. In each case, an 282 index value of 0 results in the channel (or channels) being set to 283 the 0th intermediate value (RGB0, A0, or L0). A value of 1 gives 284 the 1st intermediate value and so on. 285 286 The bit encodings for the formats are described below. Each 287 description assumes that the first byte is in the lowest memory 288 location and the last byte is in the highest memory location. The 289 high-order bit of each byte is assumed to be the "first." 290 291 An R5_G6_B5_ICC_SGIX encoded block consists of 64 bits divided 292 into 3 fields. The first is a 32 bit field containing the two-bit 293 indices for the RGB channels. The second and third fields are 16 294 bit R5G6B5 values containing c0 and c1 for the RGB channels. 295 296 R5_G6_B5_A8_ICC_SGIX blocks encode RGB and alpha independently. 297 An R5_G6_B5_A8_ICC_SGIX encoded block consists of 128 bits divided 298 into 7 fields. The first 64 bits of the block contain the two-bit 299 RGB indices followed by the two 16-bit R5G6B5 values for c0 and c1 300 (this encoding is equivalent to the 64-bit R5_G6_B5_ICC_SGIX block 301 described above). The fourth field is 32 bits wide and contains 302 indices for the alpha values. The fifth and sixth fields are 8 303 bit alpha representing c0 and c1. The seventh field is 16 bits 304 wide and is unused. It is necessary to pad out the block so that 305 the 16-bit color boundaries will always fall on half-word 306 boundaries in host memory. 307 308 An ALPHA16_ICC_SGIX, LUMINANCE16_ICC_SGIX, or INTENSITY16_ICC_SGIX 309 encoded block consists of 64 bits divided into 3 fields. The 310 first is a 32 bit field containing the two-bit indices for the 311 alpha, luminance, or intensity values. The second and third 312 fields are 16 bit unsigned fixed-point alpha, luminance, or 313 intensity values containing c0 and c1 respectively. This encoding 314 is identical to the encoding of R5_G6_B5_ICC_SGIX blocks except 315 that the c0 and c1 fields represent alpha, luminance, or intensity 316 instead of RGB. 317 318 A LUMINANCE16_ALPHA8_ICC_SGIX encoded block is identical to a 319 R5_G6_B5_A8_ICC_SGIX block except that sixteen-bit unsigned 320 luminance values are stored in place of the sixteen-bit RGB 321 values. 322 323 After decompression, the image is recombined into a ceil(width / 324 4) * 4 by ceil(height / 4) * 4 image of RGB, RGBA, A, L, I, or LA 325 pixels. Pixels whose y positions in the image (where the bottom 326 row is 0 and the top row is (ceil(height / 4) * 4) - 1) are 327 greater than (height - 1) are discarded. Likewise, pixels whose x 328 positions are greater than (width - 1) are discarded. 329 330 The following is added to Section 3.8: 331 332 In the paragraph beginning "The image itself (pointed to by data)" 333 the sentence beginning "Each color component is converted" is 334 prefixed by "If the internal format of the texture is not one of 335 RGB_ICC_SGIX, RGBA_ICC_SGIX, LUMINANCE_ICC_SGIX, 336 LUMINANCE_ALPHA_ICC_SGIX, R5_G6_B5_ICC_SGIX, R5_G6_B5_A8_ICC_SGIX, 337 LUMINANCE16_ICC_SGIX, or LUMINANCE16_ALPHA8_ICC_SGIX." The 338 following is added to the end of the paragraph: "If the internal 339 format is one of the ICC formats, the format parameter of the 340 function must either be equal to the internal format parameter (if 341 the internal format parameter is sized) or contain the same 342 channels as the internal format (if the internal format is 343 unsized) or the error INVALID_ENUM will be generated. Also, a ICC 344 internal format may not be specified for a one-dimensional 345 texture. If the format parameter to TexImage1D is set to one of 346 the ICC internal formats, the error INVALID_ENUM is generated." 347 348 The sentence in the paragraph describing CopyTexImage2D which 349 reads: "Parameters level, internalformat, and border are specified 350 using the same values, with the same meanings, as the equivalent 351 arguments of TexImage2D, except that internalformat may not be 352 specified as 1, 2, 3, or 4." is changed to read: "Parameters 353 level, internalformat, and border are specified using the same 354 values, with the same meanings, as the equivalent arguments of 355 TexImage2D, except that internalformat may not be specified as 1, 356 2, 3, 4, or any of the ICC internal formats." 357 358 The following is added to the end of the paragraph which describes 359 the subtexture download and copy commands: "CopyTexSubImage1D and 360 CopyTexSubImage2D may not be used with a target texture whose 361 internal format is one of the ICC formats or the error 362 INVALID_OPERATION is generated. For TexSubImage1D and 363 TexSubImage2D, the target texture have a ICC internal format but 364 requirements in addition to those mentioned above are enforced. 365 The xoffset and yoffset parameters must be multiples of four or 366 the error INVALID_OPERATION is generated. Also, the width 367 parameter must either be a multiple of four which is less than the 368 width of the texture minus xoffset or be equal to the width of the 369 texture minus xoffset or the error INVALID_VALUE is generated. 370 The height parameter must either a multiple of four which is less 371 than the height of the texture minus yoffset or be equal to the 372 height of the texture minus yoffset or the error INVALID_VALUE is 373 generated. In other words, the subimage may not partially cover a 374 4x4 region of the target texture. Additionally, for 375 TexSubImage2D, TexSubImage3DEXT, and TexSubImage4DSGIS calls, the 376 format parameter must have the same channels as the base internal 377 format of the texture or the error INVALID_ENUM will be 378 generated." 379 380 The following is added to Table 3.8: 381 382 Sized Base R G B A L I 383 Internal Format Internal Format Bits Bits Bits Bits Bits Bits 384 --------------- --------------- ---- ---- ---- ---- ---- ---- 385 R5_G6_B5_ICC_SGIX RGB 5 6 5 386 R5_G6_B5_A8_ICC_SGIX RGBA 5 6 5 8 387 LUMINANCE16_ICC_SGIX LUMINANCE 16 388 LUMINANCE16_ALPHA8_ICC_SGIX LUMINANCE_ALPHA 8 16 389 390 The caption for Table 3.8 is updated as follows: 391 392 Correspondence of sized internal formats to base internal formats 393 and desired component resolutions for each sized internal format. 394 For ICC compressed formats, the component resolutions do not 395 directly reflect the stored size of each pixel, but rather the 396 resolution of the two color values stored for each 4x4 pixel 397 block. 398 399 400Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations 401and the Frame Buffer) 402 403 The following is added to the first paragraph of section 4.3.2 404 after the sentence beginning "The arguments after x and y: "As in 405 the case of TexImage, ICC formats may only be used for reading 406 back ICC textures or the error INVALID_ENUM is generated. For 407 more information, see Chapter 6 (State and State Requests). 408 409Additionally, the host ICC format must have the same 410 channels as the base internal format of the source ICC texture of 411 the error INVALID_ENUM is generated. During TexSubImage readbacks of ICC 412 textures, the " 413 414Additions to Chapter 5 of the 1.1 Specification (Special Functions) 415 416 None 417 418Additions to Chapter 6 of the 1.1 Specification (State and State Requests) 419 420 Added to the end of the paragraph in the introduction which talks 421 about the GetTexImage command: "Additional restrictions apply if 422 the format is one of the ICC formats. The internal format of the 423 texture must have a base internal format equal to the format 424 parameter or the error INVALID_ENUM is generated. Similarly to 425 the download case, the width and height of the data read back is 426 rounded up to the next multiples of 4 such that only complete 427 compressed tiles are returned." 428 429Additions to the GLX Specification 430 431 None 432 433Dependencies on EXT_texture3D 434 435 If EXT_texture3D is not supported, all references to 436 TexImage3DEXT, TexSubImage3DEXT, CopyTexImage3DEXT, and 437 CopyTexSubImage3DEXT are ignored. 438 439Dependencies on SGIS_texture4D 440 441 If SGIS_texture4D is not supported, all references to 442 TexImage4DSGIS, TexSubImage4DSGIS, CopyTexImage4DSGIS, and 443 CopyTexSubImage4DSGIS are ignored. 444 445Errors 446 447 XXX 448 449New State 450 451 None 452 453New Implementation Dependent State 454 455 None 456