1Name 2 3 OES_compressed_ETC1_RGB8_texture: 4 5Name Strings 6 7 GL_OES_compressed_ETC1_RGB8_texture 8 9Contact 10 11 Jacob Strom (jacob.strom 'at' ericsson.com) 12 13Notice 14 15 Copyright (c) 2005-2013 The Khronos Group Inc. Copyright terms at 16 http://www.khronos.org/registry/speccopyright.html 17 18Specification Update Policy 19 20 Khronos-approved extension specifications are updated in response to 21 issues and bugs prioritized by the Khronos OpenGL ES Working Group. For 22 extensions which have been promoted to a core Specification, fixes will 23 first appear in the latest version of that core Specification, and will 24 eventually be backported to the extension document. This policy is 25 described in more detail at 26 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 27 28IP Status 29 30 See Ericsson's "IP Statement" 31 32Status 33 34 Ratified by the Khronos BOP, July 22, 2005. 35 36Version 37 38 Last Modified Date: April 24, 2008 39 40Number 41 42 OpenGL ES Extension #5 43 44Dependencies 45 46 Written based on the wording of the OpenGL ES 1.0 specification 47 48Overview 49 50 The goal of this extension is to allow direct support of 51 compressed textures in the Ericsson Texture Compression (ETC) 52 formats in OpenGL ES. 53 54 ETC-compressed textures are handled in OpenGL ES using the 55 CompressedTexImage2D call. 56 57 The definition of the "internalformat" parameter in the 58 CompressedTexImage2D call has been extended to support 59 ETC-compressed textures. 60 61 62Issues 63 64 Question: "How does the data format correspond to compressed files 65 created with tool etcpack?" 66 67 If etcpack is used to convert a .ppm file to this format, the top 68 left pixel in the .ppm image will end up in the first block, which 69 in turn will end up at u=0, v=0 when sent to 70 glCompressedTexImage2D. Thus it works exactly the same way as just 71 sending the raw image data from the .ppm format directly to 72 glTexImage2D. 73 74New Procedures and Functions 75 76 None 77 78 79New Tokens 80 81 Accepted by the <internalformat> parameter of CompressedTexImage2D 82 83 ETC1_RGB8_OES 0x8D64 84 85Additions to Chapter 2 of the OpenGL 1.3 Specification (OpenGL 86Operation) 87 88 None 89 90Additions to Chapter 3 of the OpenGL 1.3 Specification (Rasterization) 91 92 Add to Table 3.17: Specific Compressed Internal Formats 93 94 Compressed Internal Formats Base Internal Format 95 =========================== ==================== 96 ETC1_RGB8_OES RGB 97 98 99 Add to Section 3.8.3, Alternate Image Specification 100 101 ETC1_RGB8_OES: 102 ============== 103 104 If <internalformat> is ETC1_RGB8_OES, the compressed texture is an 105 ETC1 compressed texture. 106 107 The texture is described as a number of 4x4 pixel blocks. If the 108 texture (or a particular mip-level) is smaller than 4 pixels in 109 any dimension (such as a 2x2 or a 8x1 texture), the texture is 110 found in the upper left part of the block(s), and the rest of the 111 pixels are not used. For instance, a texture of size 4x2 will be 112 placed in the upper half of a 4x4 block, and the lower half of the 113 pixels in the block will not be accessed. 114 115 Pixel a1 (see Figure 3.9.0) of the first block in memory will 116 represent the texture coordinate (u=0, v=0). Pixel a2 in the 117 second block in memory will be adjacent to pixel m1 in the first 118 block, etc until the width of the texture. Then pixel a3 in the 119 following block (third block in memory for a 8x8 texture) will be 120 adjacent to pixel d1 in the first block, etc until the height of 121 the texture. Calling glCompressedTexImage2D to get an 8x8 texture 122 using the first, second, third and fourth block shown in Figure 123 3.9.0 would have the same effect as calling glTexImage2D where the 124 bytes describing the pixels would come in the following memory 125 order: a1 e1 i1 m1 a2 e2 i2 m2 b1 f1 j1 n1 b2 f2 j2 n2 c1 g1 k1 o1 126 c2 g2 k2 o2 d1 h1 l1 p1 d2 h2 l2 p2 a3 e3 i3 m3 a4 e4 i4 m4 b3 f3 127 j3 n3 b4 f4 j4 n4 c3 g3 k3 o3 c4 g4 k4 o4 d3 h3 l3 p3 d4 h4 l4 p4. 128 129 The number of bits that represent a 4x4 texel block is 64 bits if 130 <internalformat> is given by ETC1_RGB8_OES. 131 132 The data for a block is a number of bytes, 133 134 {q0, q1, q2, q3, q4, q5, q6, q7} 135 136 where byte q0 is located at the lowest memory address and q7 at 137 the highest. The 64 bits specifying the block is then represented 138 by the following 64 bit integer: 139 140 int64bit = 256*(256*(256*(256*(256*(256*(256*q0+q1)+q2)+q3)+q4)+q5)+q6)+q7; 141 142 Each 64-bit word contains information about a 4x4 pixel block as 143 shown in Figure 3.9.1. There are two modes in ETC1; the 144 'individual' mode and the 'differential' mode. Which mode is 145 active for a particular 4x4 block is controlled by bit 33, which 146 we call 'diffbit'. If diffbit = 0, the 'individual' mode is 147 chosen, and if diffbit = 1, then the 'differential' mode is 148 chosen. The bit layout for the two modes are different: The bit 149 layout for the individual mode is shown in Tables 3.17.1a and 150 3.17.1c, and the bit layout for the differential mode is laid out 151 in Tables 3.17.1b and 3.17.1c. 152 153 In both modes, the 4x4 block is divided into two subblocks of 154 either size 2x4 or 4x2. This is controlled by bit 32, which we 155 call 'flipbit'. If flipbit=0, the block is divided into two 2x4 156 subblocks side-by-side, as shown in Figure 3.9.2. If flipbit=1, 157 the block is divided into two 4x2 subblocks on top of each other, 158 as shown in Figure 3.9.3. 159 160 In both individual and differential mode, a 'base color' for each 161 subblock is stored, but the way they are stored is different in 162 the two modes: 163 164 In the 'individual' mode (diffbit = 0), the base color for 165 subblock 1 is derived from the codewords R1 (bit 63-60), G1 (bit 166 55-52) and B1 (bit 47-44), see Table 3.17.1a. These four bit 167 values are extended to RGB888 by replicating the four higher order 168 bits in the four lower order bits. For instance, if R1 = 14 = 169 1110b, G1 = 3 = 0011b and B1 = 8 = 1000b, then the red component 170 of the base color of subblock 1 becomes 11101110b = 238, and the 171 green and blue components become 00110011b = 51 and 10001000b = 172 136. The base color for subblock 2 is decoded the same way, but 173 using the 4-bit codewords R2 (bit 59-56), G2 (bit 51-48)and B2 174 (bit 43-40) instead. In summary, the base colors for the subblocks 175 in the individual mode are: 176 177 base col subblock1 = extend_4to8bits(R1, G1, B1) 178 base col subblock2 = extend_4to8bits(R2, G2, B2) 179 180 In the 'differential' mode (diffbit = 1), the base color for 181 subblock 1 is derived from the five-bit codewords R1', G1' and 182 B1'. These five-bit codewords are extended to eight bits by 183 replicating the top three highest order bits to the three lowest 184 order bits. For instance, if R1' = 28 = 11100b, the resulting 185 eight-bit red color component becomes 11100111b = 231. Likewise, 186 if G1' = 4 = 00100b and B1' = 3 = 00011b, the green and blue 187 components become 00100001b = 33 and 00011000b = 24 188 respectively. Thus, in this example, the base color for subblock 1 189 is (231, 33, 24). The five bit representation for the base color 190 of subblock 2 is obtained by modifying the 5-bit codewords R1' G1' 191 and B1' by the codewords dR2, dG2 and dB2. Each of dR2, dG2 and 192 dB2 is a 3-bit two-complement number that can hold values between 193 -4 and +3. For instance, if R1' = 28 as above, and dR2 = 100b = 194 -4, then the five bit representation for the red color component 195 is 28+(-4)=24 = 11000b, which is then extended to eight bits to 196 11000110b = 198. Likewise, if G1' = 4, dG2 = 2, B1' = 3 and dB2 = 197 0, the base color of subblock 2 will be RGB = (198, 49, 24). In 198 summary, the base colors for the subblocks in the differential 199 mode are: 200 201 base col subblock1 = extend_5to8bits(R1', G1', B1') 202 base col subblock2 = extend_5to8bits(R1'+dR2, G1'+dG2, B1'+dG2) 203 204 Note that these additions are not allowed to under- or overflow 205 (go below zero or above 31). (The compression scheme can easily 206 make sure they don't.) For over- or underflowing values, the 207 behavior is undefined for all pixels in the 4x4 block. Note also 208 that the extension to eight bits is performed _after_ the 209 addition. 210 211 After obtaining the base color, the operations are the same for 212 the two modes 'individual' and 'differential'. First a table is 213 chosen using the table codewords: For subblock 1, table codeword 1 214 is used (bits 39-37), and for subblock 2, table codeword 2 is used 215 (bits 36-34), see Table 3.17.1. The table codeword is used to 216 select one of eight modifier tables, see Table 3.17.2. For 217 instance, if the table code word is 010b = 2, then the modifier 218 table [-29, -9, 9 29] is selected. Note that the values in Table 219 3.17.2 are valid for all textures and can therefore be hardcoded 220 into the decompression unit. 221 222 Next, we identify which modifier value to use from the modifier 223 table using the two 'pixel index' bits. The pixel index bits are 224 unique for each pixel. For instance, the pixel index for pixel d 225 (see Figure 3.9.1) can be found in bits 19 (most significant bit, 226 MSB), and 3 (least significant bit, LSB), see Table 3.17.1c. Note 227 that the pixel index for a particular texel is always stored in 228 the same bit position, irrespectively of bits 'diffbit' and 229 'flipbit'. The pixel index bits are decoded using table 230 3.17.3. If, for instance, the pixel index bits are 01b = 1, and 231 the modifier table [-29, -9, 9, 29] is used, then the modifier 232 value selected for that pixel is 29 (see table 3.17.3). This 233 modifier value is now used to additively modify the base 234 color. For example, if we have the base color (231, 8, 16), we 235 should add the modifier value 29 to all three components: (231+29, 236 8+29, 16+29) resulting in (260, 37, 45). These values are then 237 clamped to [0, 255], resulting in the color (255, 37, 45), and we 238 are finished decoding the texel. 239 240 ETC1 compressed textures support only 2D images without 241 borders. CompressedTexture2D will produce an INVALID_OPERATION if 242 <border> is non-zero. 243 244 245 Add table 3.17.1: Texel Data format for ETC1 compressed 246 textures: 247 248 ETC1_RGB8_OES: 249 250 a) bit layout in bits 63 through 32 if diffbit = 0 251 252 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 253 ----------------------------------------------- 254 | base col1 | base col2 | base col1 | base col2 | 255 | R1 (4bits)| R2 (4bits)| G1 (4bits)| G2 (4bits)| 256 ----------------------------------------------- 257 258 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 259 --------------------------------------------------- 260 | base col1 | base col2 | table | table |diff|flip| 261 | B1 (4bits)| B2 (4bits)| cw 1 | cw 2 |bit |bit | 262 --------------------------------------------------- 263 264 265 b) bit layout in bits 63 through 32 if diffbit = 1 266 267 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 268 ----------------------------------------------- 269 | base col1 | dcol 2 | base col1 | dcol 2 | 270 | R1' (5 bits) | dR2 | G1' (5 bits) | dG2 | 271 ----------------------------------------------- 272 273 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 274 --------------------------------------------------- 275 | base col 1 | dcol 2 | table | table |diff|flip| 276 | B1' (5 bits) | dB2 | cw 1 | cw 2 |bit |bit | 277 --------------------------------------------------- 278 279 280 c) bit layout in bits 31 through 0 (in both cases) 281 282 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 283 ----------------------------------------------- 284 | most significant pixel index bits | 285 | p| o| n| m| l| k| j| i| h| g| f| e| d| c| b| a| 286 ----------------------------------------------- 287 288 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 289 -------------------------------------------------- 290 | least significant pixel index bits | 291 | p| o| n| m| l| k| j| i| h| g| f| e| d| c | b | a | 292 -------------------------------------------------- 293 294 295 Add table 3.17.2: Intensity modifier sets for ETC1 compressed textures: 296 297 table codeword modifier table 298 ------------------ ---------------------- 299 0 -8 -2 2 8 300 1 -17 -5 5 17 301 2 -29 -9 9 29 302 3 -42 -13 13 42 303 4 -60 -18 18 60 304 5 -80 -24 24 80 305 6 -106 -33 33 106 306 7 -183 -47 47 183 307 308 309 Add table 3.17.3 Mapping from pixel index values to modifier values for 310 ETC1 compressed textures: 311 312 pixel index value 313 --------------- 314 msb lsb resulting modifier value 315 ----- ----- ------------------------- 316 1 1 -b (large negative value) 317 1 0 -a (small negative value) 318 0 0 a (small positive value) 319 0 1 b (large positive value) 320 321 322 323 Add figure 3.9.0: Pixel layout for a 8x8 texture using four ETC1 324 compressed blocks. Note how pixel a2 in the second block is 325 adjacent to pixel m in the first block. 326 327 First block in mem Second block in mem 328 ---- ---- ---- ---- .... .... .... .... --> u direction 329 |a1 |e1 |i1 |m1 |a2 :e2 :i2 :m2 : 330 | | | | | : : : : 331 ---- ---- ---- ---- .... .... .... .... 332 |b1 |f1 |j1 |n1 |b2 :f2 :j2 :n2 : 333 | | | | | : : : : 334 ---- ---- ---- ---- .... .... .... .... 335 |c1 |g1 |k1 |o1 |c2 :g2 :k2 :o2 : 336 | | | | | : : : : 337 ---- ---- ---- ---- .... .... .... .... 338 |d1 |h1 |l1 |p1 |d2 :h2 :l2 :p2 : 339 | | | | | : : : : 340 ---- ---- ---- ---- ---- ---- ---- ---- 341 :a3 :e3 :i3 :m3 |a4 |e4 |i4 |m4 | 342 : : : : | | | | | 343 .... .... .... .... ---- ---- ---- ---- 344 :b3 :f3 :j3 :n3 |b4 |f4 |j4 |n4 | 345 : : : : | | | | | 346 .... .... .... .... ---- ---- ---- ---- 347 :c3 :g3 :k3 :o3 |c4 |g4 |k4 |o4 | 348 : : : : | | | | | 349 .... .... .... .... ---- ---- ---- ---- 350 :d3 :h3 :l3 :p3 |d4 |h4 |l4 |p4 | 351 : : : : | | | | | 352 .... .... .... .... ---- ---- ---- ---- 353 | Third block in mem Fourth block in mem 354 v 355 v direction 356 357 Add figure 3.9.1: Pixel layout for a ETC1 compressed block: 358 359 ---- ---- ---- ---- 360 |a |e |i |m | 361 | | | | | 362 ---- ---- ---- ---- 363 |b |f |j |n | 364 | | | | | 365 ---- ---- ---- ---- 366 |c |g |k |o | 367 | | | | | 368 ---- ---- ---- ---- 369 |d |h |l |p | 370 | | | | | 371 ---- ---- ---- ---- 372 373 374 Add figure 3.9.2: Two 2x4-pixel subblocks side-by-side: 375 376 377 subblock 1 subblock 2 378 ---- ---- ---- ---- 379 |a e |i m | 380 | | | 381 | | | 382 |b f |j n | 383 | | | 384 | | | 385 |c g |k o | 386 | | | 387 | | | 388 |d h |l p | 389 | | | 390 ---- ---- ---- ---- 391 392 393 Add figure 3.9.3: Two 4x2-pixel subblocks on top of each other: 394 395 ---- ---- ---- ---- 396 |a e i m | 397 | | 398 | | subblock 1 399 |b f j n | 400 | | 401 ------------------- 402 |c g k o | 403 | | 404 | | subblock 2 405 |d h l p | 406 | | 407 ---- ---- ---- ---- 408 409 410Additions to Chapter 4 of the OpenGL 1.3 Specification (Per-Fragment 411Operations and the Frame Buffer) 412 413 None 414 415Additions to Chapter 5 of the OpenGL 1.3 Specification (Special 416Functions) 417 418 None 419 420 421Additions to Chapter 6 of the OpenGL 1.3 Specification (State and 422State Requests) 423 424 None 425 426Additions to Appendix A of the OpenGL 1.3 Specification (Invariance) 427 428 None 429 430Additions to the AGL/GLX/WGL Specification 431 432 None 433 434GLX Protocol 435 436 None 437 438Errors 439 440 INVALID_OPERATION is generated by CompressedTexSubImage2D, 441 TexSubImage2D, or CopyTexSubImage2D if the texture image <level> 442 bound to <target> has internal format ETC1_RGB8_OES. 443 444New State 445 446 The queries for NUM_COMPRESSED_TEXTURE_FORMATS and 447 COMPRESSED_TEXTURE_FORMATS include ETC1_RGB8_OES. 448 449 450Revision History 451 04/20/2005 0.1 (Jacob Strom) 452 - Original draft. 453 04/26/2005 0.2 (Jacob Strom) 454 - Minor bugfixes. 455 05/10/2005 0.3 (Jacob Strom) 456 - Minor bugfixes. 457 06/30/2005 0.9 (Jacob Strom) 458 - Merged iPACKMAN and iPACKMANalpha. 459 07/04/2005 0.92 (Jacob Strom) 460 - Changed name from iPACKMAN to Ericsson Texture Compression 461 07/07/2005 0.98 (Jacob Strom) 462 - Removed alpha formats 463 07/27/2005 1.00 (Jacob Strom) 464 - Added token value for ETC1_RGB8_OES 465 07/28/2005 1.001 (Jacob Strom) 466 - Changed typos found by Eric Fausett 467 10/25/2006 1.1 (Jacob Strom) 468 - Added clarification on small textures and endianess 469 04/02/2008 1.11 (Jacob Strom) 470 - Added clarification on coordinate system orientation 471 04/24/2008 1.12 (Jacob Strom) 472 - Improve error description 473