Texture Compression • Modern graphic applications use lots of textures ARM “Timbuktu” demo
Texture Compression • …but textures are big – At 24 bits/pixel, multi-megabytes
• This is a problem – – – –
Big downloads Big memory footprint Big memory bandwidth Big power drain
• So we have to compress them
Why Not Just Use PNG? • It addresses the download problem. – … but …
• Texture compression – – – –
Random access Fast Fixed data access cost Fixed bit rate
• PNG, JPEG – – – –
Sequential access Slow, complex decode Unbounded data access cost Variable bit rate
Block-Based Compression • Texture compression methods all work basically the same way • Split image into blocks – Random access – Fast
• Decode pixel from block – Fixed data access cost – Fixed bit rate
• Blocks have two sizes – Footprint (NxM pixels) – Data size (n bits)
• Lossy!
Codec Choices – 2D BC6
HDR RGB+A
64
HDR RGBA
All Major Players
HDR XY+Z
48 48
ETC, BC2 BC3, BC7
HDR X+Y
PVRTC
RGB+A
PVRTC
32 32 32
RBGA ETC, BC1
XY+Z
BC7
24 24
RGB ETC, BC5
HDR L
16 16
X+Y ETC, BC4
LA
16 8
L 1
2
3
4
5
Compressed bits/pixel
6
7
8
Input bits/pixel
HDR RGB Input Color Formats
64
Problems Today • What a lot of standards! – Too much fragmentation – More work to target wide range of devices – Low bitrate encodings are proprietary and IPencumbered – Few bit rates, coarse tradeoff of size against quality – Limited feature set (2D, low dynamic range only)
• So what could we do?
A New Standard • Flexibility is key – Give the content creator fine control of tradeoff between quality and resolution – Give the encoder fine control over allocation of bits to data items
• Preserve native resolution – Bit rate can always be traded off against spatial resolution • That’s the content creator’s job, not the compression format’s
– Even at 1 bit/pixel, try to retain high frequency detail
