1Name 2 3 NV_texture_compression_latc 4 5Name Strings 6 7 GL_NV_texture_compression_latc 8 9Contributors 10 11 Contributors to the OpenGL EXT_texture_compression_latc extension 12 Greg Roth, NVIDIA 13 14Contact 15 16 Ian Stewart, NVIDIA Corporation (istewart 'at' nvidia.com) 17 18Status 19 20 Complete. 21 22Version 23 24 Last Modifed Date: Oct 26, 2012 25 NVIDIA Revision: 1 26 27Number 28 29 OpenGL ES Extension #130 30 31Dependencies 32 33 This extension is written against the OpenGL ES 2.0.25 34 Specification. 35 36 This extension interacts with NV_texture_array 37 38Overview 39 40 This extension introduces four new block-based texture compression 41 formats suited for unsigned and signed luminance and luminance-alpha 42 textures (hence the name "latc" for Luminance-Alpha Texture 43 Compression). 44 45 These formats are designed to reduce the storage requirements and 46 memory bandwidth required for luminance and luminance-alpha textures 47 by a factor of 2-to-1 over conventional uncompressed luminance and 48 luminance-alpha textures with 8-bit components. 49 50 The compressed signed luminance-alpha format is reasonably suited 51 for storing compressed normal maps. 52 53New Tokens 54 55 Accepted by the <internalformat> parameter of CompressedTexImage2D 56 and CompressedTexSubImage2D: 57 58 COMPRESSED_LUMINANCE_LATC1_NV 0x8C70 59 COMPRESSED_SIGNED_LUMINANCE_LATC1_NV 0x8C71 60 COMPRESSED_LUMINANCE_ALPHA_LATC2_NV 0x8C72 61 COMPRESSED_SIGNED_LUMINANCE_ALPHA_LATC2_NV 0x8C73 62 63Additions to Chapter 3 of the OpenGL ES 2.0.25 Specification 64 65 Modify Section 3.7.3, "Compressed Texture Images" 66 67 (Replace first two sentences with) 68 69 Texture images may also be specified or modified using image data 70 already stored in a known compressed image format. The GL defines 71 some specific compressed formats, and others may be defined by GL 72 extensions. 73 74 (Insert after section describing CompressedTexImage2D) 75 76 The specific compressed texture formats supported by 77 CompressedTexImage2D, and the corresponding base internal format 78 for each specific format, are defined in table 3.X. 79 80 Table 3.X: "Specific compressed texture formats" 81 82 Compressed Internal Formats Base Internal Format 83 =========================== ==================== 84 COMPRESSED_LUMINANCE_LATC1_NV LUMINANCE 85 COMPRESSED_SIGNED_LUMINANCE_LATC1_NV LUMINANCE 86 COMPRESSED_LUMINANCE_ALPHA_LATC2_NV LUMINANCE_ALPHA 87 COMPRESSED_SIGNED_LUMINANCE_ALPHA_LATC2_NV LUMINANCE_ALPHA 88 89 (Replace last paragraph with) 90 91 If the internal format is one of COMPRESSED_LUMINANCE_LATC1_NV, 92 COMPRESSED_SIGNED_LUMINANCE_LATC1_NV, 93 COMPRESSED_LUMINANCE_ALPHA_LATC2_NV, or 94 COMPRESSED_SIGNED_LUMINANCE_ALPHA_LATC2_NV, the compressed texture 95 is stored using one of the two LATC compressed texture image 96 encodings and is easily edited along 4x4 texel boundaries. In this 97 case, CompressedTexImage2D will result in an INVALID_OPERATION 98 error if one of the following conditions occurs: 99 100 * <width> is not a multiple of four, and <width> plus 101 <xoffset> is not equal to TEXTURE_WIDTH; 102 103 * <height> is not a multiple of four, and <height> plus 104 <yoffset> is not equal to TEXTURE_HEIGHT; or 105 106 * <xoffset> or <yoffset> is not a multiple of four. 107 108 For any other formats, calling CompressedTexSubImage2D will result 109 in an INVALID_OPERATION error if <xoffset> or <yoffset> is not 110 equal to zero, or if <width> and <height> do not match the width 111 and height of the texture, respectively. The contents of any texel 112 outside the region modified by the call are undefined. These 113 restrictions may be relaxed for other specific compressed internal 114 formats whose images are easily modified. 115 116Interactions with NV_texture_array 117 118 If NV_texture_array is supported, the LATC compressed formats may 119 also be used as the internal formats given to 120 CompressedTexImage3DNV and CompressedTexSubImage3DNV. The 121 restrictions for the <width>, <height>, <xoffset>, and <yoffset> 122 parameters of the CompressedTexSubImage2D function when used with 123 LATC compressed texture formats, described in this extension, also 124 apply to the identically named parameters of 125 CompressedTexSubImage3DNV. 126 127Errors 128 129 INVALID_OPERATION is generated by CopyTexSubImage2D if the texture 130 image <level> bound to <target> has internal format 131 COMPRESSED_LUMINANCE_LATC1_NV, 132 COMPRESSED_SIGNED_LUMINANCE_LATC1_NV, 133 COMPRESSED_LUMINANCE_ALPHA_LATC2_NV, or 134 COMPRESSED_SIGNED_LUMINANCE_ALPHA_LATC2_NV. 135 136 INVALID_OPERATION is generated by CompressedTexSubImage2D if 137 <internalformat> is COMPRESSED_LUMINANCE_LATC1_NV, 138 COMPRESSED_SIGNED_LUMINANCE_LATC1_NV, 139 COMPRESSED_LUMINANCE_ALPHA_LATC2_NV, or 140 COMPRESSED_SIGNED_LUMINANCE_ALPHA_LATC2_NV and any of the 141 following apply: 142 143 * <width> is not a multiple of four, and <width> plus 144 <xoffset> is not equal to the texture width; 145 146 * <height> is not a multiple of four, and <height> plus 147 <yoffset> is not equal to the texture height; or 148 149 * <xoffset> or <yoffset> is not a multiple of four. 150 151New State 152 153 The queries for NUM_COMPRESSED_TEXTURE_FORMATS and 154 COMPRESSED_TEXTURE_FORMATS include COMPRESSED_LUMINANCE_LATC1_NV, 155 COMPRESSED_SIGNED_LUMINANCE_LATC1_NV, 156 COMPRESSED_LUMINANCE_ALPHA_LATC2_NV, and 157 COMPRESSED_SIGNED_LUMINANCE_ALPHA_LATC2_NV. 158 159Appendix 160 161 LATC Compressed Texture Image Formats 162 163 Compressed texture images stored using the LATC compressed image 164 encodings are represented as a collection of 4x4 texel blocks, 165 where each block contains 64 or 128 bits of texel data. The image 166 is encoded as a normal 2D raster image in which each 4x4 block is 167 treated as a single pixel. If an LATC image has a width or height 168 that is not a multiple of four, the data corresponding to texels 169 outside the image are irrelevant and undefined. 170 171 When an LATC image with a width of <w>, height of <h>, and block 172 size of <blocksize> (8 or 16 bytes) is decoded, the corresponding 173 image size (in bytes) is: 174 175 ceil(<w>/4) * ceil(<h>/4) * blocksize. 176 177 When decoding an LATC image, the block containing the texel at 178 offset (<x>, <y>) begins at an offset (in bytes) relative to the 179 base of the image of: 180 181 blocksize * (ceil(<w>/4) * floor(<y>/4) + floor(<x>/4)). 182 183 The data corresponding to a specific texel (<x>, <y>) are 184 extracted from a 4x4 texel block using a relative (x,y) value of 185 186 (<x> modulo 4, <y> modulo 4). 187 188 There are four distinct LATC image formats: 189 190 COMPRESSED_LUMINANCE_LATC1_NV: Each 4x4 block of texels consists 191 of 64 bits of unsigned luminance image data. 192 193 Each luminance image data block is encoded as a sequence of 8 194 bytes, called (in order of increasing address): 195 196 lum0, lum1, bits_0, bits_1, bits_2, bits_3, bits_4, bits_5 197 198 The 6 "bits_*" bytes of the block are decoded into a 48-bit 199 bit vector: 200 201 bits = bits_0 + 202 256 * (bits_1 + 203 256 * (bits_2 + 204 256 * (bits_3 + 205 256 * (bits_4 + 206 256 * bits_5)))) 207 208 lum0 and lum1 are 8-bit unsigned integers that are unpacked to 209 luminance values LUM0 and LUM1 as though they were pixels with 210 a <format> of LUMINANCE and a type of UNSIGNED_BTYE. 211 212 bits is a 48-bit unsigned integer, from which a three-bit control 213 code is extracted for a texel at location (x,y) in the block 214 using: 215 216 code(x,y) = bits[3*(4*y+x)+2..3*(4*y+x)+0] 217 218 where bit 47 is the most significant and bit 0 is the least 219 significant bit. 220 221 The luminance value L for a texel at location (x,y) in the block 222 is given by: 223 224 LUM0, if lum0 > lum1 and code(x,y) == 0 225 LUM1, if lum0 > lum1 and code(x,y) == 1 226 (6*LUM0+ LUM1)/7, if lum0 > lum1 and code(x,y) == 2 227 (5*LUM0+2*LUM1)/7, if lum0 > lum1 and code(x,y) == 3 228 (4*LUM0+3*LUM1)/7, if lum0 > lum1 and code(x,y) == 4 229 (3*LUM0+4*LUM1)/7, if lum0 > lum1 and code(x,y) == 5 230 (2*LUM0+5*LUM1)/7, if lum0 > lum1 and code(x,y) == 6 231 ( LUM0+6*LUM1)/7, if lum0 > lum1 and code(x,y) == 7 232 233 LUM0, if lum0 <= lum1 and code(x,y) == 0 234 LUM1, if lum0 <= lum1 and code(x,y) == 1 235 (4*LUM0+ LUM1)/5, if lum0 <= lum1 and code(x,y) == 2 236 (3*LUM0+2*LUM1)/5, if lum0 <= lum1 and code(x,y) == 3 237 (2*LUM0+3*LUM1)/5, if lum0 <= lum1 and code(x,y) == 4 238 ( LUM0+4*LUM1)/5, if lum0 <= lum1 and code(x,y) == 5 239 MINLUM, if lum0 <= lum1 and code(x,y) == 6 240 MAXLUM, if lum0 <= lum1 and code(x,y) == 7 241 242 MINLUM and MAXLUM are 0.0 and 1.0 respectively. 243 244 Since the decoded texel has a luminance format, the resulting 245 RGBA value for the texel is (L,L,L,1). 246 247 248 COMPRESSED_SIGNED_LUMINANCE_LATC1_NV: Each 4x4 block of texels 249 consists of 64 bits of signed luminance image data. The luminance 250 values of a texel are extracted in the same way as 251 COMPRESSED_LUMINANCE_LATC1_NV except lum0, lum1, LUM0, LUM1, 252 MINLUM, and MAXLUM are signed values defined as follows: 253 254 lum0 and lum1 are 8-bit signed (two's complement) integers. 255 256 { lum0 / 127.0, lum0 > -128 257 LUM0 = { 258 { -1.0, lum0 == -128 259 260 { lum1 / 127.0, lum1 > -128 261 LUM1 = { 262 { -1.0, lum1 == -128 263 264 MINLUM = -1.0 265 266 MAXLUM = 1.0 267 268 CAVEAT for signed lum0 and lum1 values: the expressions "lum0 269 > lum1" and "lum0 <= lum1" above are considered undefined 270 (read: may vary by implementation) when lum0 equals -127 and 271 lum1 equals -128, This is because if lum0 were remapped to 272 -127 prior to the comparison to reduce the latency of a 273 hardware decompressor, the expressions would reverse their 274 logic. Encoders for the signed LA formats should avoid 275 encoding blocks where lum0 equals -127 and lum1 equals -128. 276 277 278 COMPRESSED_LUMINANCE_ALPHA_LATC2_NV: Each 4x4 block of texels 279 consists of 64 bits of compressed unsigned luminance image data 280 followed by 64 bits of compressed unsigned alpha image data. 281 282 The first 64 bits of compressed luminance are decoded exactly 283 like COMPRESSED_LUMINANCE_LATC1_NV above. 284 285 The second 64 bits of compressed alpha are decoded exactly 286 like COMPRESSED_LUMINANCE_LATC1_NV above except the decoded 287 value L for this second block is considered the resulting 288 alpha value A. 289 290 Since the decoded texel has a luminance-alpha format, the 291 resulting RGBA value for the texel is (L,L,L,A). 292 293 294 COMPRESSED_SIGNED_LUMINANCE_ALPHA_LATC2_NV: Each 4x4 block of 295 texels consists of 64 bits of compressed signed luminance image 296 data followed by 64 bits of compressed signed alpha image data. 297 298 The first 64 bits of compressed luminance are decoded exactly 299 like COMPRESSED_SIGNED_LUMINANCE_LATC1_NV above. 300 301 The second 64 bits of compressed alpha are decoded exactly 302 like COMPRESSED_SIGNED_LUMINANCE_LATC1_NV above except the 303 decoded value L for this second block is considered the 304 resulting alpha value A. 305 306 Since this image has a luminance-alpha format, the resulting 307 RGBA value is (L,L,L,A). 308 309Issues 310 311 1) How are signed integer values mapped to floating-point values? 312 313 RESOLVED: A signed 8-bit two's complement value X is computed 314 to a floating-point value Xf with the formula: 315 316 { X / 127.0, X > -128 317 Xf = { 318 { -1.0, X == -128 319 320 This conversion means -1, 0, and +1 are all exactly 321 representable, however -128 and -127 both map to -1.0. 322 Mapping -128 to -1.0 avoids the numerical awkwardness of 323 having a representable value slightly more negative than -1.0. 324 325 2) Should the NUM_COMPRESSED_TEXTURE_FORMATS and 326 COMPRESSED_TEXTURE_FORMATS queries return the LATC formats? 327 328 RESOLVED: No. 329 330 The OpenGL ES 2.0.25 specification says "The only values 331 returned by this query [GL_COMPRESSED_TEXTURE_FORMATS] are 332 those corresponding to 'internalformat' parameters accepted by 333 CompressedTexImage2D and suitable for general-purpose usage. 334 The renderer will not enumerate formats with restrictions that 335 need to be specifically understood prior to use." 336 337 Historically, OpenGL implementations have advertised the RGB 338 and RGBA versions of the S3TC extensions compressed format 339 tokens through this mechanism. 340 341 The specification is not sufficiently clear about what 342 "suitable for general-purpose usage" means. Historically that 343 seems to mean unsigned RGB or unsigned RGBA. The DXT1 format 344 supporting alpha (GL_COMPRESSED_RGBA_S3TC_DXT1_NV) is not 345 exposed in the list (at least for NVIDIA drivers) because the 346 alpha is always 1.0 except when it is 0.0 when RGB is required 347 to be black. NVIDIA's implementation even limits itself to 348 true linear RGB or RGBA formats, specifically not including 349 NV_sRGB_formats's sRGB S3TC compressed formats. 350 351 Adding luminance and luminance-alpha texture formats (and 352 certainly signed versions of luminance and luminance-alpha 353 formats) invites potential comptaibility problems with old 354 applications using this mechanism since old applications are 355 unlikely to expect non-RGB or non-RGBA formats to be 356 advertised through this mechanism. However no specific 357 misinteractions with old applications is known. 358 359 Applications that seek to use the LATC formats should do so by 360 looking for this extension's name in the string returned by 361 glGetString(GL_EXTENSIONS) rather than what 362 GL_NUM_COMPRESSED_TEXTURE_FORMATS and 363 GL_COMPRESSED_TEXTURE_FORMATS return. 364 365 3) The EXT_texture_compression_latc extension already lists 366 GL_NV_texture_compression_latc as a name string. Do these 367 extensions conflict? 368 369 RESOLVED: No. 370 371 The EXT_texture_compression_latc extension, written 372 against the OpenGL 1.3 specification, was originally an 373 NVIDIA-proprietary extension and published as 374 NV_texture_compression_latc. It was later promoted to be an EXT 375 extension, in part with S3, and was renamed. However, NVIDIA 376 OpenGL implementations continue to expose the 377 GL_NV_texture_compression_latc string for legacy reasons. 378 379 This extension, written against the OpenGL ES 2.0.25 380 specification, provides a subset of the functionality of 381 EXT_texture_compression_latc limited only by the differences 382 between the OpenGL 1.3 and OpenGL ES 2.0 specifications. For 383 example, format conversion from uncompressed data to compressed 384 LATC formats via TexImage2D is not supported by this extension. 385 386 If the driver exporting the GL_NV_texture_compression_latc 387 string is an OpenGL ES 2.0 driver (or an OpenGL driver using an 388 ES 2.0 profile), this extension describes the available 389 functionality. Otherwise, see EXT_texture_compression_latc. 390 391Revision History 392 393 Rev. Date Author Changes 394 ---- -------- --------- ------------------------------------- 395 1 10/26/2012 istewart First revision, based of the 396 EXT_texture_compression_latc 397 specification. 398 399# vim:ai:ts=4:sts=4:expandtab:textwidth=70 400