1Name 2 3 EXT_texture_compression_rgtc 4 5Name Strings 6 7 GL_EXT_texture_compression_rgtc 8 9Contributors 10 11 Mark J. Kilgard, NVIDIA 12 Pat Brown, NVIDIA 13 Yanjun Zhang, S3 14 Attila Barsi, Holografika 15 Jason Schmidt, NVIDIA 16 Slawomir Grajewski, Intel 17 Daniel Koch, NVIDIA 18 19Contact 20 21 Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) 22 23Status 24 25 Shipping for GeForce 8 Series (November 2006, Release 95) 26 27Version 28 29 Date: March 28, 2017 30 Revision: 2 31 32Number 33 34 OpenGL Extension #332 35 OpenGL ES Extension #286 36 37Dependencies 38 39 OpenGL 1.3, ARB_texture_compression, or OpenGL ES 3.0 required 40 41 This extension is written against the OpenGL 2.0 (September 7, 42 2004) specification. 43 44 This extension interacts with OpenGL 2.0 and ARB_texture_non_power_of_two. 45 46 This extension interacts with the OpenGL ES 3.2 specification. 47 48Overview 49 50 This extension introduces four new block-based texture compression 51 formats suited for unsigned and signed red and red-green textures 52 (hence the name "rgtc" for Red-Green Texture Compression). 53 54 These formats are designed to reduce the storage requirements 55 and memory bandwidth required for red and red-green textures by 56 a factor of 2-to-1 over conventional uncompressed luminance and 57 luminance-alpha textures with 8-bit components (GL_LUMINANCE8 and 58 GL_LUMINANCE8_ALPHA8). 59 60 The compressed signed red-green format is reasonably suited for 61 storing compressed normal maps. 62 63 This extension uses the same compression format as the 64 EXT_texture_compression_latc extension except the color data is stored 65 in the red and green components rather than luminance and alpha. 66 Representing compressed red and green components is consistent with 67 the BC4 and BC5 compressed formats supported by DirectX 10. 68 69New Procedures and Functions 70 71 None. 72 73New Tokens 74 75 In OpenGL 2.0, these tokens are accepted by the <internalformat> parameter 76 of TexImage2D, CopyTexImage2D, and CompressedTexImage2D and 77 the <format> parameter of CompressedTexSubImage2D. 78 79 In OpenGL ES 3.2, these tokens are accepted by the <internalFormat> 80 parameter of TexImage2D, TexStorage2D, and CompressedTexImage2D and 81 the <format> parameter of CompressedTexSubImage2D. 82 83 COMPRESSED_RED_RGTC1_EXT 0x8DBB 84 COMPRESSED_SIGNED_RED_RGTC1_EXT 0x8DBC 85 COMPRESSED_RED_GREEN_RGTC2_EXT 0x8DBD 86 COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT 0x8DBE 87 88Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) 89 90 None. 91 92Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) 93 94 -- Section 3.8.1, Texture Image Specification 95 96 Add to Table 3.17 (page 155): Specific compressed internal formats 97 98 Compressed Internal Format Base Internal Format 99 ------------------------------------------- -------------------- 100 COMPRESSED_RED_RGTC1_EXT RGB 101 COMPRESSED_SIGNED_RED_RGTC1_EXT RGB 102 COMPRESSED_RED_GREEN_RGTC2_EXT RGB 103 COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT RGB 104 105 -- Section 3.8.2, Alternative Texture Image Specification Commands 106 [Section 8.6 in OpenGL ES 3.2] 107 108 Add to the end of the section (page 163): 109 110 "If the internal format of the texture image 111 being modified is COMPRESSED_RED_RGTC1_EXT, 112 COMPRESSED_SIGNED_RED_RGTC1_EXT, COMPRESSED_RED_GREEN_RGTC2_EXT, 113 or COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT, the texture is stored 114 using one of the two RGTC compressed texture image encodings (see 115 appendix). Such images are easily edited along 4x4 texel boundaries, 116 so the limitations on TexSubImage2D or CopyTexSubImage2D parameters 117 are relaxed. TexSubImage2D and CopyTexSubImage2D will result in 118 an INVALID_OPERATION error only if one of the following conditions 119 occurs: 120 121 * <width> is not a multiple of four, <width> plus <xoffset> is not 122 equal to TEXTURE_WIDTH, and either <xoffset> or <yoffset> is 123 non-zero; 124 125 * <height> is not a multiple of four, <height> plus <yoffset> is not 126 equal to TEXTURE_HEIGHT, and either <xoffset> or <yoffset> is 127 non-zero; or 128 129 * <xoffset> or <yoffset> is not a multiple of four. 130 131 The contents of any 4x4 block of texels of an RGTC compressed texture 132 image that does not intersect the area being modified are preserved 133 during valid TexSubImage2D and CopyTexSubImage2D calls." 134 135 -- Section 3.8.3, Compressed Texture Images [Section 8.7 in OpenGL ES 3.2] 136 137 Add after the 4th paragraph (page 164) at the end of the 138 CompressedTexImage discussion: 139 140 "If <internalformat> is COMPRESSED_RED_RGTC1_EXT, 141 COMPRESSED_SIGNED_RED_RGTC1_EXT, COMPRESSED_RED_GREEN_RGTC2_EXT, 142 or COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT, the compressed texture is 143 stored using one of several RGTC compressed texture image formats. 144 The RGTC texture compression algorithm supports only 2D images 145 without borders. CompressedTexImage1D and CompressedTexImage3D 146 produce an INVALID_ENUM error if <internalformat> is an RGTC format. 147 CompressedTexImage2D will produce an INVALID_OPERATION error if 148 <border> is non-zero. 149 150 Add to the end of the section (page 166) at the end of the 151 CompressedTexSubImage discussion: 152 153 "If the internal format of the texture image 154 being modified is COMPRESSED_RED_RGTC1_EXT, 155 COMPRESSED_SIGNED_RED_RGTC1_EXT, COMPRESSED_RED_GREEN_RGTC2_EXT, 156 or COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT, the texture is stored 157 using one of the several RGTC compressed texture image formats. 158 Since the RGTC texture compression algorithm supports only 2D images, 159 CompressedTexSubImage1D and CompressedTexSubImage3D produce an 160 INVALID_ENUM error if <format> is an RGTC format. Since RGTC images 161 are easily edited along 4x4 texel boundaries, the limitations on 162 CompressedTexSubImage2D are relaxed. CompressedTexSubImage2D will 163 result in an INVALID_OPERATION error only if one of the following 164 conditions occurs: 165 166 * <width> is not a multiple of four, and <width> plus <xoffset> is not 167 equal to TEXTURE_WIDTH; 168 169 * <height> is not a multiple of four, and <height> plus <yoffset> is 170 not equal to TEXTURE_HEIGHT; or 171 172 * <xoffset> or <yoffset> is not a multiple of four. 173 174 The contents of any 4x4 block of texels of an RGTC compressed texture 175 image that does not intersect the area being modified are preserved 176 during valid TexSubImage2D and CopyTexSubImage2D calls." 177 178 -- Section 3.8.8, Texture Minification [Section 8.14 in OpenGL ES 3.2] 179 180 Add a sentence to the last paragraph (page 174) just prior to the 181 "Mipmapping" subheading: 182 183 "If the texture's internal format lacks components that exist in 184 the texture's base internal format, such components are considered 185 zero when the texture border color is sampled. (So despite the 186 RGB base internal format of the COMPRESSED_RED_RGTC1_EXT and 187 COMPRESSED_SIGNED_RED_RGTC1_EXT formats, the green and blue 188 components of the texture border color are always considered 189 zero. Likewise for the COMPRESSED_RED_GREEN_RGTC2_EXT, and 190 COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT formats, the blue component 191 is always considered zero.)" 192 193Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment 194Operations and the Frame Buffer) 195 196 None. 197 198Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) 199 200 None. 201 202Additions to Chapter 6 of the OpenGL 2.0 Specification (State and 203State Requests) 204 205 None. 206 207Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) 208 209 None. 210 211Additions to the AGL/GLX/WGL Specifications 212 213 None. 214 215Additions to Appendix C of the OpenGL ES 3.2 Specification (Compressed Texture 216Image Formats) 217 218 Add a new Section C.3 (RGTC Compressed Texture Image Formats) 219 220 RGTC formats are described in the "RGTC Compressed Texture Image Formats" 221 chapter of the Khronos Data Format Specification. The mapping between 222 OpenGL ES RGTC formats and that specification is shown in table C.3. 223 224 OpenGL ES format Data Format Specification 225 Description 226 ------------------------------- ------------------------- 227 COMPRESSED_RED_RGTC1_EXT BC4 unsigned 228 COMPRESSED_SIGNED_RED_RGTC1_EXT BC4 signed 229 COMPRESSED_RED_GREEN_RGTC2_EXT BC5 unsigned 230 COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT BC5 signed 231 232GLX Protocol 233 234 None. 235 236Dependencies on ARB_texture_compression 237 238 If ARB_texture_compression is supported, all the 239 errors and accepted tokens for CompressedTexImage1D, 240 CompressedTexImage2D, CompressedTexImage3D, CompressedTexSubImage1D, 241 CompressedTexSubImage2D, and CompressedTexSubImage3D also apply 242 respectively to the ARB-suffixed CompressedTexImage1DARB, 243 CompressedTexImage2DARB, CompressedTexImage3DARB, 244 CompressedTexSubImage1DARB, CompressedTexSubImage2DARB, and 245 CompressedTexSubImage3DARB. 246 247Dependencies on OpenGL 2.0 or ARB_texture_non_power_of_two 248 249 If OpenGL 2.0 or ARB_texture_non_power_of_two is supported, compressed 250 texture images can have sizes that are neither multiples of four nor small 251 values like one or two. The original version of this specification didn't 252 allow TexSubImage2D and CompressedTexSubImage2D to update only a portion 253 of such images. The spec has been updated to allow such edits in the 254 spirit of the resolution of issue (3) of the EXT_texture_compression_s3tc 255 specification. See the "Implementation Note" section for more details. 256 257Interactions with the OpenGL ES 3.2 Specification 258 259 If implemented in OpenGL ES, replace the addition to Table 3.17 260 in Section 3.8.1 with an addition to Table 8.17 in Section 8.7: 261 262 Compressed Internal Format Base Block Border 3D Cube 263 Internal Width x Type Tex Map 264 Format Height Array 265 Tex 266 --------------------------------- -------- ------- ------ --- ----- 267 COMPRESSED_RED_RGTC1_EXT RED 4x4 unorm 268 COMPRESSED_SIGNED_RED_RGTC1_EXT RED 4x4 snorm 269 COMPRESSED_RED_GREEN_RGTC2_EXT RG 4x4 unorm 270 COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT RG 4x4 snorm 271 272 273 Also, add to Section 8.4, Table 8.2: Valid combinations of format, type, 274 and sized internalFormat 275 276 External 277 Bytes 278 Format Type Per Pixel Internal Format 279 ------ ------------- --------- -------------------------------------- 280 RED UNSIGNED_BYTE 4 COMPRESSED_RED_RGTC1_EXT 281 RED SIGNED_BYTE 4 COMPRESSED_SIGNED_RED_RGTC1_EXT 282 RG UNSIGNED_BYTE 8 COMPRESSED_RED_GREEN_RGTC2_EXT 283 RG SIGNED_BYTE 8 COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT 284 285 286 In OpenGL ES, queries to GL_NUM_COMPRESSED_TEXTURE_FORMATS and 287 GL_COMPRESSED_TEXTURE_FORMATS should return the RGTC formats. 288 289 In OpenGL ES, INVALID_OPERATION is generated by TexImage2D and TexStorage2D 290 if an RGTC format is used as the <internalFormat> parameter with a <type> 291 and <format> combination NOT listed: 292 293 InternalFormat Format Type 294 ---------------------- ---------- -------------- 295 COMPRESSED_RED_RGTC1_EXT RED UNSIGNED_BYTE 296 COMPRESSED_SIGNED_RED_RGTC1_EXT RED SIGNED_BYTE 297 COMPRESSED_RED_GREEN_RGTC2_EXT RG UNSIGNED_BYTE 298 COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT RG SIGNED_BYTE 299 300Errors 301 302 INVALID_ENUM is generated by CompressedTexImage1D 303 or CompressedTexImage3D if <internalformat> is 304 COMPRESSED_RED_RGTC1_EXT, COMPRESSED_SIGNED_RED_RGTC1_EXT, 305 COMPRESSED_RED_GREEN_RGTC2_EXT, or 306 COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT. 307 308 INVALID_OPERATION is generated by CompressedTexImage2D 309 if <internalformat> is COMPRESSED_RED_RGCT1_EXT, 310 COMPRESSED_SIGNED_RED_RGTC1_EXT, COMPRESSED_RED_GREEN_RGTC2_EXT, 311 or COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT and <border> is not equal 312 to zero. 313 314 INVALID_ENUM is generated by CompressedTexSubImage1D 315 or CompressedTexSubImage3D if 316 <format> is COMPRESSED_RED_RGCT1_EXT, 317 COMPRESSED_SIGNED_RED_RGTC1_EXT, COMPRESSED_RED_GREEN_RGTC2_EXT, 318 or COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT. 319 320 INVALID_OPERATION is generated by TexSubImage2D or CopyTexSubImage2D if 321 TEXTURE_INTERNAL_FORMAT is COMPRESSED_RED_RGCT1_EXT, 322 COMPRESSED_SIGNED_RED_RGTC1_EXT, COMPRESSED_RED_GREEN_RGTC2_EXT, or 323 COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT and any of the following apply: 324 325 * <width> is not a multiple of four, <width> plus <xoffset> is not 326 equal to TEXTURE_WIDTH, and either <xoffset> or <yoffset> is 327 non-zero; 328 329 * <height> is not a multiple of four, <height> plus <yoffset> is not 330 equal to TEXTURE_HEIGHT, and either <xoffset> or <yoffset> is 331 non-zero; or 332 333 * <xoffset> or <yoffset> is not a multiple of four. 334 335 INVALID_OPERATION is generated by CompressedTexSubImage2D if 336 TEXTURE_INTERNAL_FORMAT is COMPRESSED_RED_RGCT1_EXT, 337 COMPRESSED_SIGNED_RED_RGTC1_EXT, COMPRESSED_RED_GREEN_RGTC2_EXT, or 338 COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT and any of the following apply: 339 340 * <width> is not a multiple of four, and <width> plus <xoffset> is not 341 equal to TEXTURE_WIDTH; 342 343 * <height> is not a multiple of four, and <height> plus <yoffset> is 344 not equal to TEXTURE_HEIGHT; or 345 346 * <xoffset> or <yoffset> is not a multiple of four. 347 348 The following restrictions from the ARB_texture_compression 349 specification do not apply to RGTC texture formats, since subimage 350 modification is straightforward as long as the subimage is properly 351 aligned. 352 353 DELETE: INVALID_OPERATION is generated by TexSubImage1D, TexSubImage2D, 354 DELETE: TexSubImage3D, CopyTexSubImage1D, CopyTexSubImage2D, or 355 DELETE: CopyTexSubImage3D if the internal format of the texture image is 356 DELETE: compressed and <xoffset>, <yoffset>, or <zoffset> does not equal 357 DELETE: -b, where b is value of TEXTURE_BORDER. 358 359 DELETE: INVALID_VALUE is generated by CompressedTexSubImage1D, 360 DELETE: CompressedTexSubImage2D, or CompressedTexSubImage3D if the 361 DELETE: entire texture image is not being edited: if <xoffset>, 362 DELETE: <yoffset>, or <zoffset> is greater than -b, <xoffset> + <width> is 363 DELETE: less than w+b, <yoffset> + <height> is less than h+b, or <zoffset> 364 DELETE: + <depth> is less than d+b, where b is the value of 365 DELETE: TEXTURE_BORDER, w is the value of TEXTURE_WIDTH, h is the value of 366 DELETE: TEXTURE_HEIGHT, and d is the value of TEXTURE_DEPTH. 367 368 See also errors in the GL_ARB_texture_compression specification. 369 370New State 371 372 4 new state values are added for the per-texture object 373 GL_TEXTURE_INTERNAL_FORMAT state. 374 375 In the "Textures" state table( page 278), increment the 376 TEXTURE_INTERNAL_FORMAT subscript for Z by 4 in the "Type" row. 377 378 [NOTE: The OpenGL 2.0 specification actually should read "n x Z48*" 379 because of the 6 generic compressed internal formats in table 3.18.] 380 381New Implementation Dependent State 382 383 None 384 385Appendix 386 387 RGTC Compressed Texture Image Formats 388 389 Compressed texture images stored using the RGTC compressed image 390 encodings are represented as a collection of 4x4 texel blocks, 391 where each block contains 64 or 128 bits of texel data. The image 392 is encoded as a normal 2D raster image in which each 4x4 block is 393 treated as a single pixel. If an RGTC image has a width or height 394 that is not a multiple of four, the data corresponding to texels 395 outside the image are irrelevant and undefined. 396 397 When an RGTC image with a width of <w>, height of <h>, and block 398 size of <blocksize> (8 or 16 bytes) is decoded, the corresponding 399 image size (in bytes) is: 400 401 ceil(<w>/4) * ceil(<h>/4) * blocksize. 402 403 When decoding an RGTC image, the block containing the texel at offset 404 (<x>, <y>) begins at an offset (in bytes) relative to the base of the 405 image of: 406 407 blocksize * (ceil(<w>/4) * floor(<y>/4) + floor(<x>/4)). 408 409 The data corresponding to a specific texel (<x>, <y>) are extracted 410 from a 4x4 texel block using a relative (x,y) value of 411 412 (<x> modulo 4, <y> modulo 4). 413 414 There are four distinct RGTC image formats: 415 416 417 COMPRESSED_RED_RGTC1: Each 4x4 block of texels consists of 418 64 bits of unsigned red image data. 419 420 Each red image data block is encoded as a sequence of 8 bytes, called 421 (in order of increasing address): 422 423 red0, red1, bits_0, bits_1, bits_2, bits_3, bits_4, bits_5 424 425 The 6 "bits_*" bytes of the block are decoded into a 48-bit bit 426 vector: 427 428 bits = bits_0 + 429 256 * (bits_1 + 430 256 * (bits_2 + 431 256 * (bits_3 + 432 256 * (bits_4 + 433 256 * bits_5)))) 434 435 red0 and red1 are 8-bit unsigned integers that are unpacked to red 436 values RED0 and RED1 as though they were pixels with a <format> 437 of LUMINANCE and a type of UNSIGNED_BTYE. 438 439 bits is a 48-bit unsigned integer, from which a three-bit control 440 code is extracted for a texel at location (x,y) in the block 441 using: 442 443 code(x,y) = bits[3*(4*y+x)+2..3*(4*y+x)+0] 444 445 where bit 47 is the most significant and bit 0 is the least 446 significant bit. 447 448 The red value R for a texel at location (x,y) in the block is 449 given by: 450 451 RED0, if red0 > red1 and code(x,y) == 0 452 RED1, if red0 > red1 and code(x,y) == 1 453 (6*RED0+ RED1)/7, if red0 > red1 and code(x,y) == 2 454 (5*RED0+2*RED1)/7, if red0 > red1 and code(x,y) == 3 455 (4*RED0+3*RED1)/7, if red0 > red1 and code(x,y) == 4 456 (3*RED0+4*RED1)/7, if red0 > red1 and code(x,y) == 5 457 (2*RED0+5*RED1)/7, if red0 > red1 and code(x,y) == 6 458 ( RED0+6*RED1)/7, if red0 > red1 and code(x,y) == 7 459 460 RED0, if red0 <= red1 and code(x,y) == 0 461 RED1, if red0 <= red1 and code(x,y) == 1 462 (4*RED0+ RED1)/5, if red0 <= red1 and code(x,y) == 2 463 (3*RED0+2*RED1)/5, if red0 <= red1 and code(x,y) == 3 464 (2*RED0+3*RED1)/5, if red0 <= red1 and code(x,y) == 4 465 ( RED0+4*RED1)/5, if red0 <= red1 and code(x,y) == 5 466 MINRED, if red0 <= red1 and code(x,y) == 6 467 MAXRED, if red0 <= red1 and code(x,y) == 7 468 469 MINRED and MAXRED are 0.0 and 1.0 respectively. 470 471 Since the decoded texel has a red format, the resulting RGBA value 472 for the texel is (R,0,0,1). 473 474 475 COMPRESSED_SIGNED_RED_RGTC1: Each 4x4 block of texels consists of 476 64 bits of signed red image data. The red values of a texel are 477 extracted in the same way as COMPRESSED_RED_RGTC1 except red0, red1, 478 RED0, RED1, MINRED, and MAXRED are signed values defined as follows: 479 480 red0 and red1 are 8-bit signed (two's complement) integers. 481 482 { red0 / 127.0, red0 > -128 483 RED0 = { 484 { -1.0, red0 == -128 485 486 { red1 / 127.0, red1 > -128 487 RED1 = { 488 { -1.0, red1 == -128 489 490 MINRED = -1.0 491 492 MAXRED = 1.0 493 494 CAVEAT for signed red0 and red1 values: the expressions "red0 > 495 red1" and "red0 <= red1" above are considered undefined (read: may 496 vary by implementation) when red0 equals -127 and red1 equals -128, 497 This is because if red0 were remapped to -127 prior to the comparison 498 to reduce the latency of a hardware decompressor, the expressions 499 would reverse their logic. Encoders for the signed LA formats should 500 avoid encoding blocks where red0 equals -127 and red1 equals -128. 501 502 503 COMPRESSED_RED_GREEN_RGTC2: Each 4x4 block of texels consists of 504 64 bits of compressed unsigned red image data followed by 64 bits 505 of compressed unsigned green image data. 506 507 The first 64 bits of compressed red are decoded exactly like 508 COMPRESSED_RED_RGTC1 above. 509 510 The second 64 bits of compressed green are decoded exactly like 511 COMPRESSED_RED_RGTC1 above except the decoded value R for this 512 second block is considered the resulting green value G. 513 514 Since the decoded texel has a red-green format, the resulting RGBA 515 value for the texel is (R,G,0,1). 516 517 518 COMPRESSED_SIGNED_RED_GREEN_RGTC2: Each 4x4 block of texels consists 519 of 64 bits of compressed signed red image data followed by 64 bits 520 of compressed signed green image data. 521 522 The first 64 bits of compressed red are decoded exactly like 523 COMPRESSED_SIGNED_RED_RGTC1 above. 524 525 The second 64 bits of compressed green are decoded exactly like 526 COMPRESSED_SIGNED_RED_RGTC1 above except the decoded value R 527 for this second block is considered the resulting green value G. 528 529 Since this image has a red-green format, the resulting RGBA value is 530 (R,G,0,1). 531 532Issues 533 534 1) What should these new formats be called? 535 536 RESOLVED: "rgtc" for Red-Green Texture Compression. 537 538 2) How should the uncompressed and filtered texels be returned by 539 texture fetches? 540 541 RESOLVED: Red values show up as (R,0,0,1) where R is the red 542 value, green and blue are forced to 0, and alpha is forced to 1. 543 Likewise, red-green values show up as (R,G,0,1) where G is the 544 green value. 545 546 Prior extensions such as NV_float_buffer and NV_texture_shader 547 have introduced formats such as GL_FLOAT_R_NV and GL_DSDT_NV where 548 one- and two-component texture formats show up as (X,0,0,1) or 549 (X,Y,0,1) RGBA texels. The RGTC formats mimic these two-component 550 formats. 551 552 The (X,Y,0,1) convention, particularly with signed components, 553 is nice for normal maps because a normalized vector can be 554 formed by a shader program by computing sqrt(abs(1-X*X-Y*Y)) 555 for the Z component. 556 557 While GL_RED is a valid external format, core OpenGL provides 558 no GL_RED_GREEN external format. Applications can either use 559 GL_RGB or GL_RGBA and pad out the blue and alpha components, 560 or use the two-component GL_LUMINANCE_ALPHA color format and 561 use the color matrix functionality to swizzle the luminance and 562 alpha values into red and green respectively. 563 564 3) Should red and red-green compression formats with signed 565 components be introduced when the core specification lacked 566 uncompressed red and red-green texture formats? 567 568 RESOLVED: Yes, signed red and red-green compression formats 569 should be added. 570 571 Signed red-green formats are suited for compressed normal maps. 572 Compressed normal maps may well be the dominant use of this 573 extension. 574 575 Unsigned red-green formats require an extra "expand normal" 576 operation to convert [0,1] to [-1,+1]. Direct support for signed 577 red-green formats avoids this step in a shader program. 578 579 4) Should there be a mix of signed red and unsigned green or 580 vice versa? 581 582 RESOLVED: No. 583 584 NV_texture_shader provided an internal format 585 (GL_SIGNED_RGB_UNSIGNED_ALPHA_NV) with mixed signed and unsigned 586 components. The format saw little usage. There's no reason to 587 think a GL_SIGNED_RED_UNSIGNED_GREEN format would be any more 588 useful or popular. 589 590 5) How are signed integer values mapped to floating-point values? 591 592 RESOLVED: A signed 8-bit two's complement value X is computed to 593 a floating-point value Xf with the formula: 594 595 { X / 127.0, X > -128 596 Xf = { 597 { -1.0, X == -128 598 599 This conversion means -1, 0, and +1 are all exactly representable, 600 however -128 and -127 both map to -1.0. Mapping -128 to -1.0 601 avoids the numerical awkwardness of have a representable value 602 slightly more negative than -1.0. 603 604 This conversion is intentionally NOT the "byte" conversion listed 605 in Table 2.9 for component conversions. That conversion says: 606 607 Xf = (2*X + 1) / 255.0 608 609 The Table 2.9 conversion is incapable of exactly representing 610 zero. 611 612 6) How will signed components resulting 613 from GL_COMPRESSED_SIGNED_RED_RGTC1_EXT and 614 GL_COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT texture fetches interact 615 with fragment coloring? 616 617 RESOLVED: The specification language for this extension is silent 618 about clamping behavior leaving this to the core specification 619 and other extensions. The clamping or lack of clamping is left 620 to the core specification and other extensions. 621 622 For assembly program extensions supporting texture fetches 623 (ARB_fragment_program, NV_fragment_program, NV_vertex_program3, 624 etc.) or the OpenGL Shading Language, these signed formats will 625 appear as expected with unclamped signed components as a result 626 of a texture fetch instruction. 627 628 If ARB_color_buffer_float is supported, its clamping controls 629 will apply. 630 631 NV_texture_shader extension, if supported, adds support for 632 fixed-point textures with signed components and relaxed the 633 fixed-function texture environment clamping appropriately. If the 634 NV_texture_shader extension is supported, its specified behavior 635 for the texture environment applies where intermediate values 636 are clamped to [-1,1] unless stated otherwise as in the case 637 of explicitly clamped to [0,1] for GL_COMBINE. or clamping the 638 linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND. 639 640 Otherwise, the conventional core texture environment clamps 641 incoming, intermediate, and output color components to [0,1]. 642 643 This implies that the conventional texture environment 644 functionality of unextended OpenGL 1.5 or OpenGL 2.0 without 645 using GLSL (and with none of the extensions referred to above) 646 is unable to make proper use of the signed texture formats added 647 by this extension because the conventional texture environment 648 requires texture source colors to be clamped to [0,1]. Texture 649 filtering of these signed formats would be still signed, but 650 negative values generated post-filtering would be clamped to 651 zero by the core texture environment functionality. The 652 expectation is clearly that this extension would be co-implemented 653 with one of the previously referred to extensions or used with 654 GLSL for the new signed formats to be useful. 655 656 7) Should a specific normal map compression format be added? 657 658 RESOLVED: No. 659 660 It's probably short-sighted to design a format just for normal 661 maps. Indeed, NV_texture_shader added a GL_SIGNED_HILO_NV 662 format with exactly the kind of "hemisphere remap" useful for 663 normal maps and the format went basically unused. Instead, 664 this extension provides the mechanism for compressed normal maps 665 based on the more conventional red-green format. 666 667 The GL_COMPRESSED_RED_GREEN_RGTC2_EXT and 668 GL_COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT formats are sufficient 669 for normal maps with additional shader instructions used to 670 generate the 3rd component. 671 672 8) Should uncompressed signed red and red-green formats be added 673 by this extension? 674 675 RESOLVED: No, this extension is focused on just adding compressed 676 texture formats. 677 678 The NV_texture_shader extension adds such uncompressed signed 679 texture formats. A distinct multi-vendor extension for signed 680 fixed-point texture formats could provide all or a subset of 681 the signed fixed-point uncompressed texture formats introduced 682 by NV_texture_shader. 683 684 9) What compression ratios does this extension provide? 685 686 The RGTC1 formats are 8 bytes (64 bits) per 4x4 pixel block. 687 A 4x4 block of GL_LUMINANCE8 data requires 16 bytes (1 byte 688 per texel). This is a 2-to-1 compression ratio. 689 690 The RGTC2 formats are 16 bytes (128 bits) per 4x4 pixel block. 691 A 4x4 block of GL_LUMINANCE8_ALPHA8 data requires 32 bytes 692 (2 bytes per texel). This is again a 2-to-1 compression ratio. 693 694 In contrast, the comparable compression ratio for the S3TC 695 formats is 4-to-1. 696 697 Arguably, the lower compression ratio allows better compression 698 quality particularly because the RGTC formats compress each 699 component separately. 700 701 10) How do these new formats compare with the existing GL_LUMINANCE4, 702 GL_LUMINANCE4_ALPHA4, and GL_LUMINANCE6_ALPHA2 internal formats? 703 704 RESOLVED: The existing GL_LUMINANCE4, GL_LUMINANCE4_ALPHA4, 705 and GL_LUMINANCE6_ALPHA2 internal formats provide a similar 706 2-to-1 compression ratio but mandate a uniform quantization 707 for all components. In contrast, this extension provides a 708 compression format with 3-bit quantization over a specifiable 709 min/max range that can vary per 4x4 texel tile. 710 711 Additionally, many OpenGL implementations do not natively support 712 the GL_LUMINANCE4, GL_LUMINANCE4_ALPHA4, and GL_LUMINANCE6_ALPHA2 713 internal formats but rather silently promote these formats 714 to store 8 bits per component, thereby eliminating any 715 storage/bandwidth advantage for these formats. 716 717 11) Does this extension require EXT_texture_compression_s3tc? 718 719 RESOLVED: No. 720 721 As written, this specification does not rely on wording of the 722 EXT_texture_compression_s3tc extension. For example, certain 723 discussion added to Sections 3.8.2 and 3.8.3 is quite similar 724 to corresponding EXT_texture_compression_s3tc language. 725 726 12) Should anything be said about the precision of texture filtering 727 for these new formats? 728 729 RESOLVED: No precision requirements are part of the specification 730 language since OpenGL extensions typically leave precision 731 details to the implementation. 732 733 Realistically, at least 8-bit filtering precision can be expected 734 from implementations (and probably more). 735 736 13) Should these formats be allowed to specify 3D texture images 737 when NV_texture_compression_vtc is supported? 738 739 RESOLVED: The NV_texture_compression_vtc stacks 4x4 blocks into 740 4x4x4 bricks. It may be more desirable to represent compressed 741 3D textures as simply slices of 4x4 blocks. 742 743 However the NV_texture_compression_vtc extension expects data 744 passed to the glCompressedTexImage commands to be "bricked" 745 rather than blocked slices. 746 747 14) How is the texture border color handled for the blue component 748 of an RGTC2 texture and the green and blue components of an 749 RGTC1 texture? 750 751 RESOLVED: The base texture format is RGB for the RGTC1 and 752 RGTC2 texture formats. This would mean table 3.15 would be 753 used to determine how the texture border color is interpreted 754 and which components are considered. 755 756 However since only red or red/green components exist for the 757 RGTC1 and RGTC2 formats, it makes little sense to require 758 the blue component be supplied by the texture border color and 759 hence be involved (meaningfully only when the border is sampled) 760 in texture filtering. 761 762 For this reason, a statement is added to section 3.8.8 says that 763 if a texture's internal format lacks components that exist in 764 the texture's base internal format, such components contain 765 zero (ignoring the texture's corresponding texture border color 766 component value) when the texture border color is sampled. 767 768 So the green and blue components of the filtered result of a 769 RGTC1 texture are always zero, even when the border is sampled. 770 Similarly the blue component of the filtered result of a RGTC2 771 texture is always zero, even when the border is sampled. 772 773 15) What should glGetTexLevelParameter return for 774 GL_TEXTURE_GREEN_SIZE and GL_TEXTURE_BLUE_SIZE for the RGTC1 775 formats? What should glGetTexLevelParameter return for 776 GL_TEXTURE_BLUE_SIZE for the RGTC2 formats? 777 778 RESOLVED: Zero bits. 779 780 These formats always return 0.0 for these respective components 781 and have no bits devoted to these components. 782 783 Returning 8 bits for red size of RGTC1 and the red and green 784 sizes of RGTC2 makes sense because that's the maximum potential 785 precision for the uncompressed texels. 786 787 16) Should the token names contain R and RG or RED and RED_GREEN? 788 789 RESOLVED: RED and RED_GREEN. 790 791 Saying RGB and RGBA makes sense for three- and four-component 792 formats rather than spelling out the component names because 793 RGB and RGBA are used so commonly and spelling out the names it 794 too wordy. 795 796 But for 1- and 2-component names, we follow the precedent by 797 GL_LUMINANCE and GL_LUMINANCE_ALPHA. This extension spells out 798 the component names of 1- and 2-component names. 799 800 Another reason to avoid R and RG is the existing meaning of 801 the GL_R and GL_RED tokens. GL_RED already exists as a token 802 name for a single-component external format. GL_R also already 803 exists as a token name but refers to the R texture coordinate, 804 not the red color component. 805 806 17) Can you use the GL_RED external format with glTexImage2D and other 807 such commands to load textures with the 808 GL_COMPRESSED_RED_RGTC1_EXT or GL_COMPRESSED_SIGNED_RED_RGTC1_EXT 809 internal formats? 810 811 RESOLVED: Yes. 812 813 GL_RED has been a valid external format parameter to glTexImage 814 and similar commands since OpenGL 1.0. 815 816 18) Should any of the generic compression GL_COMPRESSED_* tokens in 817 OpenGL 2.1 map to RGTC formats? 818 819 RESOLVED: No. The RGTC formats are missing color components 820 so are not adequate implementations for any of the generic 821 compression formats. 822 823 19) Should the GL_NUM_COMPRESSED_TEXTURE_FORMATS and 824 GL_COMPRESSED_TEXTURE_FORMATS queries return the RGTC formats? 825 826 RESOLVED: Not in OpenGL, yes in OpenGL ES. 827 828 The OpenGL 2.1 specification says "The only values returned 829 by this query [GL_COMPRESSED_TEXTURE_FORMATS"] are those 830 corresponding to formats suitable for general-purpose usage. 831 The renderer will not enumerate formats with restrictions that 832 need to be specifically understood prior to use." 833 834 Compressed textures with just red or red-green components are 835 not general-purpose so should not be returned by these queries 836 because they have restrictions. 837 838 Applications that seek to use the RGTC formats should do so 839 by looking for this extension's name in the string returned by 840 glGetString(GL_EXTENSIONS) rather than 841 what GL_NUM_COMPRESSED_TEXTURE_FORMATS and 842 GL_COMPRESSED_TEXTURE_FORMATS return. 843 844 The OpenGL ES 3.2 specification does not include the requirement 845 for general-purpose usage, and so these queries should return the 846 RGTC formats in an ES context. 847 848Implementation Note 849 850 This extension allows TexSubImage2D and CompressedTexSubImage2D to perform 851 partial updates to compressed images, but generally requires that the 852 updated area be aligned to 4x4 block boundaries. If the width or height 853 is not a multiple of four, there will be 4x4 blocks at the edge of the 854 image that contain "extra" texels that are not part of the image. This 855 spec has an exception allowing edits that partially cover such blocks as 856 long as the edit covers all texels in the block belonging to the image. 857 For example, in a 2D texture of size 70x50, it is legal to update the 858 single partial block covering the four texels from (68,48) to (69,49) by 859 setting (<xoffset>, <yoffset>) to (68,48) and <width> and <height> to 2. 860 861 This specification derived some of its language from the 862 EXT_texture_compression_s3tc specification. When that extension was 863 originally written, non-bordered textures were required to have widths and 864 heights that were powers of two. Therefore, the only cases where partial 865 blocks could occur were if the width or height of the texture image was 866 one or two. The original spec language allowed partial block edits only 867 if the width or height of the region edited was equal to the full texture 868 size. That language didn't handle cases such as the 70x50 example above. 869 870 This specification was updated in April, 2009 to allow such edits. 871 Multiple OpenGL implementers correctly implemented the original 872 restriction, and partial edits that include partially covered tiles will 873 result in INVALID_OPERATION errors on older drivers. 874 875Revision History 876 877 Revision 1.1, April 24, 2007: mjk 878 - Add caveat about how signed LA decompression happens when 879 lum0 equals -127 and lum1 equals -128. This caveat matches 880 a decoding allowance in DirectX 10. 881 882 Revision 1.2, January 21, 2008: mjk 883 - Add issues #18 and #19. 884 885 Revision 1.3, April 14, 2009: pbrown 886 - Add interaction with non-power-of-two textures from OpenGL 2.0 / 887 ARB_texture_non_power_of_two. Allow CompressedTexSubImage2D to 888 perform edits that include partial tiles at the edge of the image as 889 long as the specified width/height parameters line up with the edge. 890 Thanks to Emil Persson for finding this issue. 891 892 Revision 2, March 28, 2017: jaschmidt 893 - Add interactions with the OpenGL ES 3.2 specification. 894 - repace incorrect references to COMPRESSED_LUMINANCE_LACT1_EXT with 895 correct references to COMPRESSED_RED_RGTC1_EXT. 896