Community Hub0 Subscribers
Community hub
Ericsson Texture Compression
View on Wikipediafrom Wikipedia
Ericsson Texture Compression (ETC) is a lossy texture compression technique developed in collaboration with Ericsson Research in early 2005. It was originally developed under the name iPACKMAN[1] and based on an earlier compression scheme called PACKMAN.[2]
ETC1
[edit]The original 'ETC1' compression scheme provides 6x compression of 24-bit RGB data. It does not port the compression of images with Alpha components, although there are work-arounds for this.[3]
ETC1 takes 4x4 groups of pixel data and compresses each into a single 64-bit word. The 4×4 pixel group is first divided into two 4×2 chunks - either horizontally or vertically. Each half is given a base color - either using 4/4/4 RGB or by giving one of them a 5/5/5 RGB and having the other be a 3/3/3 bit offset from that base. Each 4×2 region also has a 3-bit brightness range selection. Each pixel is then offset from the base color by adding one of four signed values to the base color for its half of the 4×4 group.
This format is a part of the OpenGL ES graphics standard extensions[4] for embedded devices such as mobile phones and has been approved by the Khronos Group for use in the WebGL graphics standard for browser-side World Wide Web graphics. [citation needed]
Android version 2.2 (Froyo) includes support for ETC1.[5][3]
ETC2
[edit]The 'ETC2' scheme expands ETC1 in a backwards-compatible way to provide higher quality RGB compression,[6] as well as compression of RGBA (RGB plus alpha).
The following ETC2 codecs are mandatory in OpenGL ES 3.0[7] and OpenGL 4.3:[8]
GL_COMPRESSED_RGB8_ETC2— Compresses RGB888 data, the followup of ETC1.GL_COMPRESSED_RGBA8_ETC2_EAC— Compresses RGBA8888 data with full alpha support.GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2— Compresses RGBA data where pixels are either fully transparent or fully opaque.
sRGB variants of the above codecs are also available.
EAC
[edit]EAC is built on the same principles as ETC1/ETC2 but is used for one- or two-channel data. The following four EAC codecs are included as mandatory in OpenGL ES 3.0 and OpenGL 4.3:
GL_COMPRESSED_R11_EAC— one channel unsigned dataGL_COMPRESSED_SIGNED_R11_EAC— one channel signed dataGL_COMPRESSED_RG11_EAC— two channel unsigned dataGL_COMPRESSED_SIGNED_RG11_EAC— two channel signed data
Encoding
[edit]The RGBA and RG11 formats are encoded in 128 bits per 4x4 block, while the rest are encoded in 64 bits per block. For RGBA, the RGB channels are encoded in a regular 64-bit block, while the A channel gets its own 64-bit block. RG11 formats are encoded similarly, with one 64-bit block per component.
Software
[edit]A software utility called ETCPACK for compression and decompression of ETC1/ETC2 textures is available for free download in code form from Ericsson on GitHub.[9]
See also
[edit]- S3 Texture Compression (S3TC)
- Adaptive Scalable Texture Compression (ASTC)
References
[edit]- ^ iPACKMAN: High-Quality, Low-Complexity Textures Compression for Mobile Phones -- Jacob Ström (Ecsson Research), Tomas Akeinine-Möller (Lund University)
- ^ PACKMAN: Texture Compression for Mobies -- Jacob Ström (Ericsson Research), Tomas Akeinine-Möller (Lund University).
- ^ a b "Sample code for handling alpha channels in ETC1 from ARM". Archived from the original on 2011-10-27. Retrieved 2011-11-03.
- ^ OES_compressed_ETC1_RGB8_texture, A description of the ETC1- compression algorithm and texture format in OpenGL ES extension registry
- ^ Release notes for Android 2.2 Archived 2010-10-11 at the Wayback Machine, (Froyo)
- ^ Paper about ETC2: Texture Compression using Invalid Combinations
- ^ "OpenGL ES Version 3.0 Specification" (PDF). Archived from the original (PDF) on 2016-03-06. Retrieved 2012-08-07.
- ^ OpenGL Version 4.3 Specification
- ^ Ericsson ETCPACK on Github
External links
[edit]- Ericsson ETCPACK on github
- Sample code for handling alpha channels in ETC1 from ARM
- rg_etc1, A fast, high quality, ZLIB-licensed ETC1 block packer/unpacker in a single C++ source file
- etcpak, an extremely fast Ericsson Texture Compression utility for rapid assets preparation by Bartosz Taudul
- etc2comp, a fast Ericsson Texture Compression program.
Ericsson Texture Compression
View on Grokipediafrom Grokipedia
Overview
Introduction
Ericsson Texture Compression (ETC) is a family of lossy texture compression codecs developed by Ericsson Research to reduce memory bandwidth requirements in real-time graphics applications, particularly on resource-constrained mobile devices.[2] Introduced in collaboration with hardware vendors in the mid-2000s, ETC enables efficient storage and transmission of texture data by minimizing bus congestion and power consumption without significantly compromising visual fidelity.[2][3] At its core, ETC compresses textures by encoding 4×4 pixel blocks into fixed bit rates, such as 4 bits per pixel (bpp) for RGB data, allowing GPUs to decode and rasterize images rapidly while preserving perceptual quality.[2] This fixed-rate approach ensures predictable memory usage, making it suitable for embedded systems where variable compression ratios could introduce inefficiencies.[2] The ETC family encompasses several formats tailored to different needs: ETC1 provides RGB-only compression at 4 bpp, EAC handles single-channel (e.g., red) or dual-channel (e.g., red-green) data at 4 or 8 bpp for applications like normal maps, and ETC2 extends ETC1 with full RGBA support, including alpha blending and punchthrough modes for enhanced quality (up to 1.0 dB improvement over ETC1).[2] ETC2 maintains backward compatibility with ETC1, facilitating adoption across platforms.[2][3] Key advantages of ETC include hardware-accelerated decoding in fixed-function pipelines, which eliminates decompression artifacts during rendering, and standardized support in APIs like OpenGL ES 3.0 and OpenGL 4.3, enabling widespread use on over 370 million Android devices as of 2012.[2] These features make ETC a cornerstone for mobile game development and graphics optimization.[2][3]History and Development
Ericsson Texture Compression (ETC) originated from research efforts at Ericsson Research aimed at optimizing texture storage for resource-constrained mobile devices. The foundational work began with the PACKMAN algorithm, introduced in 2004 as a lossy compression scheme designed to reduce memory bandwidth demands in mobile phones and PDAs, where bus widths were typically limited to 16 or 32 bits per cycle.[4] This was followed in early 2005 by iPACKMAN, a refined extension developed in collaboration with external academic partners, which improved image quality while maintaining low hardware complexity for real-time decompression.[5] iPACKMAN, later renamed ETC1, focused on RGB texture compression and was specifically tailored to address bandwidth bottlenecks in early mobile GPUs, enabling more efficient rendering without excessive power consumption or pipeline stalls.[5] ETC1 gained formal recognition through standardization in the OpenGL ES 2.0 specification, released in 2007, which included it as an optional texture compression format to support embedded graphics applications.[6] Practical adoption accelerated with its integration into Android version 2.2 (Froyo) in 2010, and by 2012 it was available on over 370 million devices, establishing it as a de facto standard for mobile texture compression.[2] However, ETC1's limitations, such as the absence of native alpha channel support and inadequate handling of single- or two-channel textures like normal maps, prompted further development. To overcome these shortcomings, Ericsson Research introduced EAC (Ericsson Texture Compression for one- and two-channel textures) around 2010, providing specialized compression for R and RG formats with both unsigned and signed variants.[2] This innovation culminated in ETC2, a unified extension released in 2012 that incorporated EAC alongside enhancements to ETC1, including full alpha support and backward compatibility. ETC2 was standardized as mandatory in OpenGL ES 3.0 and OpenGL 4.3 that same year, ensuring widespread hardware support and higher quality compression—approximately 1.0 dB better in PSNR than ETC1—while continuing to prioritize efficiency for mobile and embedded systems.[2]Formats
ETC1
Ericsson Texture Compression 1 (ETC1) is a lossy compression format designed for RGB textures, achieving a fixed rate of 4 bits per pixel by encoding 4×4 pixel blocks in 64 bits. This provides a 6:1 compression ratio for 24-bit RGB data, enabling efficient storage and transmission in resource-constrained environments such as mobile graphics. Developed by Ericsson Research, ETC1 was standardized in OpenGL ES 2.0 via the OES_compressed_ETC1_RGB8_texture extension and became widely adopted on Android devices.[7][2] Each 64-bit block is divided into two 4×2 or 2×4 subblocks, determined by a flip bit (bit 32: 0 for horizontal, 1 for vertical orientation). The upper 32 bits (63–32) encode the base colors and mode, while the lower 32 bits (31–0) contain 2-bit indices for each of the 16 pixels. Two encoding modes are supported: individual mode (diffbit 33 = 0), which uses separate 4:4:4 RGB base colors for each subblock (12 bits per subblock: R1 bits 63–60, G1 55–52, B1 47–44; R2 59–56, G2 51–48, B2 43–40), and differential mode (diffbit 33 = 1), which uses a shared 5:5:5 RGB base for the first subblock (R1' 63–59, G1' 55–51, B1' 47–43) modified by 3-bit signed differentials for the second (dR 58–56, dG 50–48, dB 42–40, ranging from -4 to +3). Each subblock also includes a 3-bit table selector (codeword 1: bits 39–37; codeword 2: 36–34) that indexes one of eight predefined 4-entry intensity modifier tables, applied to the base color based on the 2-bit pixel index (e.g., index 00 adds the first table entry, clamped to [0, 255]). These tables provide relative brightness adjustments, such as [-8, -2, 2, 8] for table 0, to approximate per-pixel colors within the subblock.[7] ETC1 supports only 2D textures without borders, producing an INVALID_OPERATION error for non-zero borders in OpenGL. It lacks native alpha channel support, requiring separate textures for transparency in applications like games. Additionally, the limited color precision and fixed subblock structure can lead to visible artifacts, particularly in high-contrast or detailed images where the intensity modifiers fail to capture fine gradients accurately. All valid ETC1 blocks are backwards compatible with the later ETC2 format, allowing seamless loading as RGB data without alpha.[7][2]EAC
Ericsson Texture Compression's EAC (Ericsson Android Compression) format is designed for compressing single- or dual-channel texture data, such as luminance or chrominance components, at a fixed rate of 4 bits per pixel. For one-channel data (e.g., R11 EAC), a 4×4 texel block is encoded into 64 bits, while two-channel data (e.g., RG11 EAC) uses 128 bits, consisting of two independent 64-bit blocks side by side. This enables efficient storage of non-RGB data like alpha channels or normal map components without correlating channels, distinguishing it from multi-channel color formats.[8] The base structure of an EAC block centers on a single intensity value per channel, unlike subblock-based approaches in RGB formats, with an 8-bit base codeword defining the primary intensity level for the entire 4×4 block. This base codeword occupies bits 63–56 (for little-endian byte order), followed by a 4-bit index (bits 55–52) selecting one of 16 predefined multiplier tables and a 4-bit table selector (bits 51–48) for further refinement. The remaining 48 bits (47–0) provide 3-bit indices for each of the 16 texels, referencing offset values from the selected multiplier table to adjust the base intensity. These offsets are quantized, typically drawing from tables with values like -1, -2, -3, -10, 0, 1, 2, and 9, scaled relative to a base delta for granular control over intensity variations.[8] EAC supports both unsigned and signed modes to accommodate different data ranges. In unsigned mode, values span 0 to 2047 (approximately 11-bit precision after scaling), suitable for non-negative data, while signed mode covers -1024 to 1023, ideal for bidirectional values like displacement in height maps. Decoding involves computing each texel's value as the clamped sum of the scaled base codeword and the texel-specific modifier from the multiplier table, using formulas such as [4](/page/8-4) + \text{modifier} \times \text{multiplier} \times 8, [0](/page/0), 2047) for unsigned R11 EAC and [0](/page/0), 2047) - [1024](/page/1024) for signed R11 EAC; these operations ensure linear output for direct shader use. For RG11 EAC, the process applies independently to each channel's block.[8] EAC is primarily applied to alpha channels for transparency in textures, single-component height or displacement maps, and paired components (e.g., X and Y) in normal maps, where channel independence preserves detail without RGB assumptions. A key aspect is that EAC blocks are not interpretable by ETC1 or base ETC2 RGB decoders, necessitating dedicated hardware or software handling, though implementations often reuse ETC2 alpha decoding logic with minor modifications like truncation. In practice, EAC integrates with ETC2 for full RGBA textures by attaching an R11 EAC block for alpha to an ETC1-compatible RGB block.[8]ETC2
ETC2, or Ericsson Texture Compression 2, extends the original ETC1 format by unifying it with the Enhanced AC (EAC) format to provide comprehensive support for RGBA textures, including alpha transparency, while maintaining the 4x4 texel block structure.[8] This unification allows for compressed RGBA8888 textures at 8 bits per pixel using 128-bit blocks, where the first 64 bits handle RGB data via an ETC1-compatible scheme and the remaining 64 bits manage the alpha channel through EAC.[8] ETC2 also supports sRGB color space variants, enabling accurate gamma correction during decoding for nonlinear color representation.[8] The format defines several encoding modes to optimize for different texture characteristics. In the RGB + separate alpha mode, a 128-bit block combines a 64-bit ETC1 RGB sub-block with a 64-bit EAC alpha sub-block, where the alpha is computed as a base codeword modified by a multiplier and per-pixel indices, yielding 8-bit alpha values per texel.[8] The punch-through alpha mode uses a single 64-bit block to encode RGB data in 63 bits alongside a 1-bit alpha threshold, allowing binary transparency (0 or 255 per texel) where transparent pixels have RGB set to (0,0,0); this mode selects from differential, T, H, or planar RGB encoding based on bit patterns.[8] For smooth gradients on planar surfaces, the T-mode employs a 64-bit block with two RGB444 base colors (24 bits total), a 3-bit distance selector indexing predefined deltas, and 32 bits of 2-bit per-pixel indices to select among four derived colors using a T-shaped interpolation pattern for smooth horizontal gradients.[9][8] ETC2 ensures backwards compatibility by treating valid ETC1 blocks as opaque RGB in ETC2 decoders, falling back seamlessly for RGB-only textures without alpha.[8] It defines mandatory compressed formats in graphics APIs, such asGL_COMPRESSED_RGBA8_ETC2 for RGBA8888 and GL_COMPRESSED_RGB8_ETC2 for RGB8, integrated into OpenGL ES 3.0 and later specifications.[8]
Compared to ETC1, ETC2 introduces native alpha channel support, eliminating the need for separate textures or overlays, and provides punch-through alpha for efficient handling of sharp transparent edges in sprites or UI elements.[9] Additionally, modes like T-mode and planar reduce artifacts in gradients and flat areas by using invalid ETC1 bit combinations to signal advanced encoding, achieving approximately 1 dB higher PSNR quality on average for RGB compression.[9][10]
Technical Specifications
Block Structure
Ericsson Texture Compression (ETC) formats employ a standardized block structure to achieve fixed-rate compression suitable for real-time graphics rendering. Each block represents a 4×4 array of pixels, enabling efficient memory usage and random access in texture sampling. This 4×4 partitioning is universal across ETC variants, including ETC1, EAC, and ETC2, with RGB data compressed at 64 bits per block (4 bits per pixel) and RGBA at 128 bits per block (8 bits per pixel) to accommodate alpha channels.[8][11] The block is divided into two 4×2 subblocks, each covering 8 pixels, to facilitate parallel processing and local color adaptation. The orientation of these subblocks—either horizontal (two 2×4 regions side-by-side) or vertical (two 4×2 regions stacked)—is determined by a single flip bit in the block header, allowing flexibility in handling varying texture gradients without increasing bit overhead. This subblock division is a core feature shared by ETC1 and ETC2 RGB modes, promoting hardware-friendly decoding.[7][8] Bit allocation within a 64-bit RGB block typically includes a compact header (e.g., 2 bits for mode selection like differential or individual, plus the flip bit), base colors or intensities (around 32 bits total, such as 16 bits per subblock in RGB565-like encoding), modifier table indices (3–4 bits per subblock to select from predefined offset tables), and pixel indices (2 bits per pixel, totaling 32 bits for the 16 pixels to reference modifiers). For RGBA blocks, this structure is extended by pairing two 64-bit blocks or using dedicated alpha encoding in EAC. These allocations ensure a balance between color fidelity and compression ratio, with headers and indices enabling differential encoding for smoother gradients.[7][8][11] Textures using ETC must align blocks on 4×4 boundaries to maintain decoding efficiency; if dimensions are not multiples of 4, padding is applied to the nearest multiple, ensuring complete blocks without partial encoding. This alignment requirement supports direct GPU access and avoids artifacts in mipmapping.[8][11] Pixel values are reconstructed using a general formula that adds a selected modifier to a base color:
where $ m_i $ is the modifier value from the chosen table, indexed by the 2-bit pixel codeword and clamped to the valid range (e.g., [0, 255] for 8-bit channels). Base colors are typically expanded from quantized representations (e.g., 4–5 bits per channel) before applying modifiers, providing perceptual quality through luminance adjustments. This additive model is foundational across ETC formats, with table values derived from 8–16 predefined sets of offsets (e.g., ±8, ±2 levels).[7][8]
Encoding Modes
Ericsson Texture Compression employs two primary encoding modes—differential and individual—to represent colors within each 4x4 texel block, allowing adaptation to varying color distributions while maintaining a fixed 64-bit block size. These modes are selected during encoding to minimize reconstruction error, with a flip bit providing additional flexibility in subblock assignment. The differential mode uses a shared base color for both subblocks, derived from a 5-bit RGB codeword, while the second subblock's base color is obtained by adding component-wise 3-bit signed deltas (ranging from -4 to +3 in the 5-bit domain, yielding effective 8-bit differences of approximately -32 to +24 after bit replication). Per-pixel 2-bit indices then select offsets from a 4-entry modifier table, applied uniformly across RGB components for luminance adjustment; the table is chosen via a 3-bit selector from 8 predefined sets, with representative offsets such as -8, -2, 2, and 8 in the base table.[7][1] The individual mode, suited for high-detail areas with disparate subblock colors, encodes independent base colors for each subblock using 4-bit RGB codewords (RGB444), extended to 8 bits via replication (value × 17). Similar to differential mode, 2-bit per-pixel indices access a 4-entry modifier table per subblock, with the same 8 selectable tables providing offsets; this approach avoids delta computation, prioritizing direct color specification at the cost of fewer bits for intensity variation. In extensions like ETC2, punchthrough transparency is supported in individual and differential modes by replacing the flip bit with a transparent bit and using a dedicated pixel index to indicate alpha=0, providing binary alpha (0 or 255) without full per-pixel alpha storage.[8][1] A flip bit (1 bit) swaps subblock assignments to optimize partitioning, alternating between horizontal (two 4×2 subblocks) and vertical (two 2×4 subblocks) layouts for better alignment with image gradients. Full implementations use 3 bits per subblock for finer granularity across the 8 tables.[7] Encoding selects the optimal configuration by evaluating combinations of modes, orientations, and modifier table selections (8 per subblock) along with base color quantizations, choosing the one with the lowest error, typically measured as mean squared error (MSE). The error metric is computed as the sum of squared differences between original and reconstructed pixels:
where subscripts and denote original and reconstructed values for the 16 texels, often weighted perceptually (e.g., factors of 0.299 for R, 0.587 for G, 0.114 for B) to align with human vision.[1][8]