Name
OES_compressed_ETC1_RGB8_texture:
Name Strings
GL_OES_compressed_ETC1_RGB8_texture
Contact
Jacob Strom (jacob.strom 'at' ericsson.com)
Notice
Copyright (c) 2005-2013 The Khronos Group Inc. Copyright terms at
http://www.khronos.org/registry/speccopyright.html
IP Status
See Ericsson's "IP Statement"
Status
Ratified by the Khronos BOP, July 22, 2005.
Version
Last Modified Date: April 24, 2008
Number
OpenGL ES Extension #5
Dependencies
Written based on the wording of the OpenGL ES 1.0 specification
Overview
The goal of this extension is to allow direct support of
compressed textures in the Ericsson Texture Compression (ETC)
formats in OpenGL ES.
ETC-compressed textures are handled in OpenGL ES using the
CompressedTexImage2D call.
The definition of the "internalformat" parameter in the
CompressedTexImage2D call has been extended to support
ETC-compressed textures.
Issues
Question: "How does the data format correspond to compressed files
created with tool etcpack?"
If etcpack is used to convert a .ppm file to this format, the top
left pixel in the .ppm image will end up in the first block, which
in turn will end up at u=0, v=0 when sent to
glCompressedTexImage2D. Thus it works exactly the same way as just
sending the raw image data from the .ppm format directly to
glTexImage2D.
New Procedures and Functions
None
New Tokens
Accepted by the <internalformat> parameter of CompressedTexImage2D
ETC1_RGB8_OES 0x8D64
Additions to Chapter 2 of the OpenGL 1.3 Specification (OpenGL
Operation)
None
Additions to Chapter 3 of the OpenGL 1.3 Specification (Rasterization)
Add to Table 3.17: Specific Compressed Internal Formats
Compressed Internal Formats Base Internal Format
=========================== ====================
ETC1_RGB8_OES RGB
Add to Section 3.8.3, Alternate Image Specification
ETC1_RGB8_OES:
==============
If <internalformat> is ETC1_RGB8_OES, the compressed texture is an
ETC1 compressed texture.
The texture is described as a number of 4x4 pixel blocks. If the
texture (or a particular mip-level) is smaller than 4 pixels in
any dimension (such as a 2x2 or a 8x1 texture), the texture is
found in the upper left part of the block(s), and the rest of the
pixels are not used. For instance, a texture of size 4x2 will be
placed in the upper half of a 4x4 block, and the lower half of the
pixels in the block will not be accessed.
Pixel a1 (see Figure 3.9.0) of the first block in memory will
represent the texture coordinate (u=0, v=0). Pixel a2 in the
second block in memory will be adjacent to pixel m1 in the first
block, etc until the width of the texture. Then pixel a3 in the
following block (third block in memory for a 8x8 texture) will be
adjacent to pixel d1 in the first block, etc until the height of
the texture. Calling glCompressedTexImage2D to get an 8x8 texture
using the first, second, third and fourth block shown in Figure
3.9.0 would have the same effect as calling glTexImage2D where the
bytes describing the pixels would come in the following memory
order: a1 e1 i1 m1 a2 e2 i2 m2 b1 f1 j1 n1 b2 f2 j2 n2 c1 g1 k1 o1
c2 g2 k2 o2 d1 h1 l1 p1 d2 h2 l2 p2 a3 e3 i3 m3 a4 e4 i4 m4 b3 f3
j3 n3 b4 f4 j4 n4 c3 g3 k3 o3 c4 g4 k4 o4 d3 h3 l3 p3 d4 h4 l4 p4.
The number of bits that represent a 4x4 texel block is 64 bits if
<internalformat> is given by ETC1_RGB8_OES.
The data for a block is a number of bytes,
{q0, q1, q2, q3, q4, q5, q6, q7}
where byte q0 is located at the lowest memory address and q7 at
the highest. The 64 bits specifying the block is then represented
by the following 64 bit integer:
int64bit = 256*(256*(256*(256*(256*(256*(256*q0+q1)+q2)+q3)+q4)+q5)+q6)+q7;
Each 64-bit word contains information about a 4x4 pixel block as
shown in Figure 3.9.1. There are two modes in ETC1; the
'individual' mode and the 'differential' mode. Which mode is
active for a particular 4x4 block is controlled by bit 33, which
we call 'diffbit'. If diffbit = 0, the 'individual' mode is
chosen, and if diffbit = 1, then the 'differential' mode is
chosen. The bit layout for the two modes are different: The bit
layout for the individual mode is shown in Tables 3.17.1a and
3.17.1c, and the bit layout for the differential mode is laid out
in Tables 3.17.1b and 3.17.1c.
In both modes, the 4x4 block is divided into two subblocks of
either size 2x4 or 4x2. This is controlled by bit 32, which we
call 'flipbit'. If flipbit=0, the block is divided into two 2x4
subblocks side-by-side, as shown in Figure 3.9.2. If flipbit=1,
the block is divided into two 4x2 subblocks on top of each other,
as shown in Figure 3.9.3.
In both individual and differential mode, a 'base color' for each
subblock is stored, but the way they are stored is different in
the two modes:
In the 'individual' mode (diffbit = 0), the base color for
subblock 1 is derived from the codewords R1 (bit 63-60), G1 (bit
55-52) and B1 (bit 47-44), see Table 3.17.1a. These four bit
values are extended to RGB888 by replicating the four higher order
bits in the four lower order bits. For instance, if R1 = 14 =
1110b, G1 = 3 = 0011b and B1 = 8 = 1000b, then the red component
of the base color of subblock 1 becomes 11101110b = 238, and the
green and blue components become 00110011b = 51 and 10001000b =
136. The base color for subblock 2 is decoded the same way, but
using the 4-bit codewords R2 (bit 59-56), G2 (bit 51-48)and B2
(bit 43-40) instead. In summary, the base colors for the subblocks
in the individual mode are:
base col subblock1 = extend_4to8bits(R1, G1, B1)
base col subblock2 = extend_4to8bits(R2, G2, B2)
In the 'differential' mode (diffbit = 1), the base color for
subblock 1 is derived from the five-bit codewords R1', G1' and
B1'. These five-bit codewords are extended to eight bits by
replicating the top three highest order bits to the three lowest
order bits. For instance, if R1' = 28 = 11100b, the resulting
eight-bit red color component becomes 11100111b = 231. Likewise,
if G1' = 4 = 00100b and B1' = 3 = 00011b, the green and blue
components become 00100001b = 33 and 00011000b = 24
respectively. Thus, in this example, the base color for subblock 1
is (231, 33, 24). The five bit representation for the base color
of subblock 2 is obtained by modifying the 5-bit codewords R1' G1'
and B1' by the codewords dR2, dG2 and dB2. Each of dR2, dG2 and
dB2 is a 3-bit two-complement number that can hold values between
-4 and +3. For instance, if R1' = 28 as above, and dR2 = 100b =
-4, then the five bit representation for the red color component
is 28+(-4)=24 = 11000b, which is then extended to eight bits to
11000110b = 198. Likewise, if G1' = 4, dG2 = 2, B1' = 3 and dB2 =
0, the base color of subblock 2 will be RGB = (198, 49, 24). In
summary, the base colors for the subblocks in the differential
mode are:
base col subblock1 = extend_5to8bits(R1', G1', B1')
base col subblock2 = extend_5to8bits(R1'+dR2, G1'+dG2, B1'+dG2)
Note that these additions are not allowed to under- or overflow
(go below zero or above 31). (The compression scheme can easily
make sure they don't.) For over- or underflowing values, the
behavior is undefined for all pixels in the 4x4 block. Note also
that the extension to eight bits is performed _after_ the
addition.
After obtaining the base color, the operations are the same for
the two modes 'individual' and 'differential'. First a table is
chosen using the table codewords: For subblock 1, table codeword 1
is used (bits 39-37), and for subblock 2, table codeword 2 is used
(bits 36-34), see Table 3.17.1. The table codeword is used to
select one of eight modifier tables, see Table 3.17.2. For
instance, if the table code word is 010b = 2, then the modifier
table [-29, -9, 9 29] is selected. Note that the values in Table
3.17.2 are valid for all textures and can therefore be hardcoded
into the decompression unit.
Next, we identify which modifier value to use from the modifier
table using the two 'pixel index' bits. The pixel index bits are
unique for each pixel. For instance, the pixel index for pixel d
(see Figure 3.9.1) can be found in bits 19 (most significant bit,
MSB), and 3 (least significant bit, LSB), see Table 3.17.1c. Note
that the pixel index for a particular texel is always stored in
the same bit position, irrespectively of bits 'diffbit' and
'flipbit'. The pixel index bits are decoded using table
3.17.3. If, for instance, the pixel index bits are 01b = 1, and
the modifier table [-29, -9, 9, 29] is used, then the modifier
value selected for that pixel is 29 (see table 3.17.3). This
modifier value is now used to additively modify the base
color. For example, if we have the base color (231, 8, 16), we
should add the modifier value 29 to all three components: (231+29,
8+29, 16+29) resulting in (260, 37, 45). These values are then
clamped to [0, 255], resulting in the color (255, 37, 45), and we
are finished decoding the texel.
ETC1 compressed textures support only 2D images without
borders. CompressedTexture2D will produce an INVALID_OPERATION if
<border> is non-zero.
Add table 3.17.1: Texel Data format for ETC1 compressed
textures:
ETC1_RGB8_OES:
a) bit layout in bits 63 through 32 if diffbit = 0
63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48
-----------------------------------------------
| base col1 | base col2 | base col1 | base col2 |
| R1 (4bits)| R2 (4bits)| G1 (4bits)| G2 (4bits)|
-----------------------------------------------
47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
---------------------------------------------------
| base col1 | base col2 | table | table |diff|flip|
| B1 (4bits)| B2 (4bits)| cw 1 | cw 2 |bit |bit |
---------------------------------------------------
b) bit layout in bits 63 through 32 if diffbit = 1
63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48
-----------------------------------------------
| base col1 | dcol 2 | base col1 | dcol 2 |
| R1' (5 bits) | dR2 | G1' (5 bits) | dG2 |
-----------------------------------------------
47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
---------------------------------------------------
| base col 1 | dcol 2 | table | table |diff|flip|
| B1' (5 bits) | dB2 | cw 1 | cw 2 |bit |bit |
---------------------------------------------------
c) bit layout in bits 31 through 0 (in both cases)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
-----------------------------------------------
| most significant pixel index bits |
| p| o| n| m| l| k| j| i| h| g| f| e| d| c| b| a|
-----------------------------------------------
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
--------------------------------------------------
| least significant pixel index bits |
| p| o| n| m| l| k| j| i| h| g| f| e| d| c | b | a |
--------------------------------------------------
Add table 3.17.2: Intensity modifier sets for ETC1 compressed textures:
table codeword modifier table
------------------ ----------------------
0 -8 -2 2 8
1 -17 -5 5 17
2 -29 -9 9 29
3 -42 -13 13 42
4 -60 -18 18 60
5 -80 -24 24 80
6 -106 -33 33 106
7 -183 -47 47 183
Add table 3.17.3 Mapping from pixel index values to modifier values for
ETC1 compressed textures:
pixel index value
---------------
msb lsb resulting modifier value
----- ----- -------------------------
1 1 -b (large negative value)
1 0 -a (small negative value)
0 0 a (small positive value)
0 1 b (large positive value)
Add figure 3.9.0: Pixel layout for a 8x8 texture using four ETC1
compressed blocks. Note how pixel a2 in the second block is
adjacent to pixel m in the first block.
First block in mem Second block in mem
---- ---- ---- ---- .... .... .... .... --> u direction
|a1 |e1 |i1 |m1 |a2 :e2 :i2 :m2 :
| | | | | : : : :
---- ---- ---- ---- .... .... .... ....
|b1 |f1 |j1 |n1 |b2 :f2 :j2 :n2 :
| | | | | : : : :
---- ---- ---- ---- .... .... .... ....
|c1 |g1 |k1 |o1 |c2 :g2 :k2 :o2 :
| | | | | : : : :
---- ---- ---- ---- .... .... .... ....
|d1 |h1 |l1 |p1 |d2 :h2 :l2 :p2 :
| | | | | : : : :
---- ---- ---- ---- ---- ---- ---- ----
:a3 :e3 :i3 :m3 |a4 |e4 |i4 |m4 |
: : : : | | | | |
.... .... .... .... ---- ---- ---- ----
:b3 :f3 :j3 :n3 |b4 |f4 |j4 |n4 |
: : : : | | | | |
.... .... .... .... ---- ---- ---- ----
:c3 :g3 :k3 :o3 |c4 |g4 |k4 |o4 |
: : : : | | | | |
.... .... .... .... ---- ---- ---- ----
:d3 :h3 :l3 :p3 |d4 |h4 |l4 |p4 |
: : : : | | | | |
.... .... .... .... ---- ---- ---- ----
| Third block in mem Fourth block in mem
v
v direction
Add figure 3.9.1: Pixel layout for a ETC1 compressed block:
---- ---- ---- ----
|a |e |i |m |
| | | | |
---- ---- ---- ----
|b |f |j |n |
| | | | |
---- ---- ---- ----
|c |g |k |o |
| | | | |
---- ---- ---- ----
|d |h |l |p |
| | | | |
---- ---- ---- ----
Add figure 3.9.2: Two 2x4-pixel subblocks side-by-side:
subblock 1 subblock 2
---- ---- ---- ----
|a e |i m |
| | |
| | |
|b f |j n |
| | |
| | |
|c g |k o |
| | |
| | |
|d h |l p |
| | |
---- ---- ---- ----
Add figure 3.9.3: Two 4x2-pixel subblocks on top of each other:
---- ---- ---- ----
|a e i m |
| |
| | subblock 1
|b f j n |
| |
-------------------
|c g k o |
| |
| | subblock 2
|d h l p |
| |
---- ---- ---- ----
Additions to Chapter 4 of the OpenGL 1.3 Specification (Per-Fragment
Operations and the Frame Buffer)
None
Additions to Chapter 5 of the OpenGL 1.3 Specification (Special
Functions)
None
Additions to Chapter 6 of the OpenGL 1.3 Specification (State and
State Requests)
None
Additions to Appendix A of the OpenGL 1.3 Specification (Invariance)
None
Additions to the AGL/GLX/WGL Specification
None
GLX Protocol
None
Errors
INVALID_OPERATION is generated by CompressedTexSubImage2D,
TexSubImage2D, or CopyTexSubImage2D if the texture image <level>
bound to <target> has internal format ETC1_RGB8_OES.
New State
The queries for NUM_COMPRESSED_TEXTURE_FORMATS and
COMPRESSED_TEXTURE_FORMATS include ETC1_RGB8_OES.
Revision History
04/20/2005 0.1 (Jacob Strom)
- Original draft.
04/26/2005 0.2 (Jacob Strom)
- Minor bugfixes.
05/10/2005 0.3 (Jacob Strom)
- Minor bugfixes.
06/30/2005 0.9 (Jacob Strom)
- Merged iPACKMAN and iPACKMANalpha.
07/04/2005 0.92 (Jacob Strom)
- Changed name from iPACKMAN to Ericsson Texture Compression
07/07/2005 0.98 (Jacob Strom)
- Removed alpha formats
07/27/2005 1.00 (Jacob Strom)
- Added token value for ETC1_RGB8_OES
07/28/2005 1.001 (Jacob Strom)
- Changed typos found by Eric Fausett
10/25/2006 1.1 (Jacob Strom)
- Added clarification on small textures and endianess
04/02/2008 1.11 (Jacob Strom)
- Added clarification on coordinate system orientation
04/24/2008 1.12 (Jacob Strom)
- Improve error description
