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