Современные форматы сжатия текстур

В статье представлен детальный анализ технологий сжатия текстур, используемых в современных персональных компьютерах, планшетах и смартфонах. Рассматриваются основные требования к методам сжатия и алгоритмам аппаратной реализации с учетом качества компрессии-декомпрессии текстур. Анализируется семейство S3TC (ВС1-ВС3), которое было одной из первых массово-используемых технологий сжатия текстур. За ними последовали форматы ВС4, ВС5, а позже ВС6Н и ВС7, значительно улучшившие визуальное качество компрессии-декомпрессии за счет более гибкого формата хранения базовых цветов, улучшенной процедуры интерполяции промежуточных цветов и возможности разделения блока на отдельные регионы. Рассматривается также семейство ETC корпорации Ericsson, нацеленное на мобильные устройства и включающее форматы PACKMAN, ETC1 (iPACKMAN) и ETC2/EAC. Также представлена аналогичная технология PVRTC от Imagination Technologies, включающая форматы PVRTC 4bpp/2bpp и PVRTC2 4bpp/2bpp. Завершает статью анализ технологии сжатия текстур ASTC, разработанной фирмами ARM и AMD, с разбором метода кодирования BISE и прочих особенностей используемых алгоритмов.

Ключевые слова: компьютерная графика, сжатие текстур, компрессия текстур, декомпрессия текстур, S3TC, DXT, BCn, BC6H, BC7, ETC, ETC2, EAC, PVRTC, PVRTC2, ASTC.

Введение

Использование различных видов текстур является неотъемлемой частью современной компьютерной графики. Это позволяет существенно улучшить визуальную детализацию трехмерных объектов без усложнения геометрии. В простейшем случае текстуры представляют собой двухмерное изображение, накладываемое на трёхмерный объект. Отдельные точки растра, составляющие текстуру, принято называть текселями (texel – texture element). Кроме информации о цвете текстура может содержать карту высот, нормалей, отражений и прочую информацию (Рис. 1). При этом в современных интерактивных приложениях текстуры занимают более половины используемого объёма видеопамяти (1). Однако применение большого количества текстур крупных размеров предъявляет высокие требования к видеопамяти. В связи с этим широкое распространение получили различные технологии сжатия текстур. При этом текстура передается и хранится в памяти в сжатом виде, и распаковывается непосредственно на графическом процессоре, как правило, между кэшами L1 и L2 . Такой подход позволяет не только уменьшить занимаемый текстурами объем памяти, но и сэкономить пропускную способность, которая в большинстве случаев является куда более дефицитным ресурсом. Кроме этого, использование сжатия положительно сказывается на энергопотреблении за счёт уменьшения объёма используемой памяти и снижения трафика на интерфейсе GPU↔память, что очень существенно для мобильных устройств (ноутбуков, планшетов, смартфонов).

Рис. 1. Пример использования различных видов текстур.
А – карта диффузного отражения, Б – карта нормалей, В – карта смещений.

Особенности текстурного сжатия

В большинстве случаев, текстуры представляют собой обычные двухмерные изображения. Однако, универсальные алгоритмы сжатия без потерь (RLE, LZW, Deflate) и популярные графические форматы, такие как JPEG, PNG, TIFF, плохо подходят для текстур. Основная причина – это невозможность доступа к произвольному участку текстуры без распаковки всего файла. При отрисовке трёхмерного объекта используются только те фрагменты текстуры, которые попали в кадр, при этом смежность элементов объекта не обязательно означает смежность элементов текстуры (Рис. 2). Кроме этого, заранее неизвестно в какой последовательности будут запрошены различные части текстуры. Поэтому общая производительность системы визуализации очень сильно зависит от эффективности произвольного доступа к текселям. Именно эта особенность обуславливает основные свойства различных форматов сжатия текстур.

Рис. 2. Пример отображения текстуры на трёхмерный объект.
(Текстура и 3D-модель из Microsoft DirectX 9 SDK)

Для текстурного сжатия характерно разбиение всего изображения на блоки фиксированного размера и независимое сжатие каждого блока. Некоторые форматы немного отходят от этой концепции (Семейство PVRTC). Применительно к компьютерной графике, для текстурной компрессии важны следующие свойства:

•Произвольный доступ. Необходимо, чтобы формат сжатой текстуры позволял осуществлять быстрый доступ к произвольному участку текстуры. В связи с этим, почти все известные компрессоры имеют фиксированный уровень сжатия. Это, в свою очередь, автоматически означает сжатие с потерями. Тем не менее, существуют подходы и с нефиксированным уровнем сжатия. Например, в работе (2) предлагается подход к сжатию текстур без потерь и с переменным уровнем сжатия, где для повышения производительности произвольного доступа предлагается модификация системы кэширования.

•Высокая скорость распаковки. Время доступа к текстурам является крайне важным фактором, влияющим на общую производительность видеоподсистемы. Отсюда вытекают два следующих свойства:

oПростота аппаратной реализации декодера. Алгоритм декомпрессии должен быть относительно простым. Поэтому дискретно-косинусные (DCT, discrete cosine transform) и вейвлет преобразования, как правило, не используются.

oВыборка необходимых данных за одно обращение в память. Любое дополнительное обращения к памяти (например, к палитре или другим таблицам) приводит к увеличению задержки при распаковке. Наличие косвенных ссылок также снижает эффективность кэширования из-за снижения локальности обращений к памяти.

•Высокая степень сжатия. Это основной параметр, определяющий насколько сильно снижаются требования к пропускной способности памяти для текстурных операций. Степень сжатия принято выражать в среднем количестве бит на тексель или bpp. Типичные значения bpp для текстурных компрессоров от 2bpp до 8bpp.

•Изображение разбивается на блоки небольшого размера, обычно 4х4 текселя. Блоки меньшего размера сложнее поддаются сжатию. С другой стороны блоки слишком большого размера могут отрицательно сказаться на проценте кэш-попаданий. Желательно также, чтобы размер блока был меньше ширины шины памяти, чтобы снизить задержки и упростить аппаратную реализацию (3). Современные графические процессоры в персональных компьютерах имеют ширину шины памяти от 64 до 512 бит. Ввиду жестких ограничений на ширину шины памяти в мобильных устройствах часто используются кодеки с очень высокой степенью сжатия (2bpp) или с меньшими размерами блоков.

•Приемлемое качество сжатого изображения. Очевидно, что вносимые компрессором искажения должны быть, по-возможности, минимальными.

Сжатие для ускорения загрузки

Далее в данной статье речь будет вестись именно о форматах, имеющих аппаратную поддержку декодирования и позволяющих обращаться к произвольному участку текстуры без полной распаковки. Однако можно отметить такое направление, как сжатие текстур для ускорения их загрузки в видеопамять. Оно используется для ускорения загрузки текстур с диска или по сети, что актуально для современных приложений, в которых объём текстур измеряется гигабайтами.

Здесь основной задачей является уменьшение занимаемого объёма. В данном случае отсутствуют такие ограничения, как необходимость произвольного доступа к текселям, что позволяет существенно увеличить степень сжатия. После загрузки такой текстуры в видеопамять, она распаковывается с использование программируемых шейдеров. Конечным результатом может быть несжатый формат текстуры или формат, аппаратно поддерживаемый графическим процессором. При этом в видеопамяти может постоянно находиться полный набор текстур в сжатом виде и активный набор в аппаратно поддерживаемом формате.

По сравнению с универсальными методами сжатия (RLE, LZW, Deflate), специализированный подход позволяет увеличить степень компрессии. В случае игровых консолей данный приём позволяет разместить больше контента на одном оптическом диске.

К примеру, технология Virtual Texturing используемая в графическом движке IdTech5 (4) при подгрузке отдельных частей текстур позволяет транскодировать их из формата, близкого к JPEG, в формат DXT. Однако итоговая текстура будет содержать артефакты сжатия, вносимые обоими форматами.

Среди прочих работ так же можно отметить статью (5), в которой предлагается схема способная производить сжатие текстур с различными уровнями детализации (mipmaps) без потерь и с потерями, а также работу (6), описывающую алгоритм сжатия без потерь текстур в формате ETC.

Качество и скорость сжатия

Понятно, что разница между оригинальным и восстановленным изображением во многом определяется форматом, в котором хранится сжатая текстура. Но кроме этого на качество в значительной степени влияет реализация компрессора. К сожалению, для большинства форматов преобразование текстуры в сжатый вид является нетривиальной задачей. И наилучший результат в отношении качества дают методы, основанные на переборе. Найти алгоритм, который делал бы это более рациональным способом зачастую проблематично. Полный перебор позволяет получить текстуру с наилучшим возможным для данного формата качеством, однако это очень долго. Из выше сказанного следует, что при сравнении качества сжатых текстур необходимо обязательно указывать, как производилась компрессия.

Как это ни странно, но качество также может пострадать при распаковке. Так, например, аппаратная реализация декодера текстур формата DXT1 на графических чипах GeForce/GeForce2 была такова, что все операции выполнялись в режиме 16 бит, без конвертации в 24 бита (7). Это приводило к появлению дополнительных артефактов при распаковке (Рис. 3).

Рис. 3. Артефакты сжатия. А – без сжатия, Б – dxt1 на видеокарте S3 Savage2000,
B – dxt1 на видеокарте NVidia GeForce 256. (Источник: iXBT (7))

Традиционный подход к сжатию текстур заключается в использовании предварительно сжатых текстур. В современных системах визуализации все чаще используются динамически генерируемые данные (карты окружений для имитации отражения, и т.д.), что делает актуальной задачу быстрого сжатия текстур в темпе генерации кадров ресурсами графического процессора. Стоит также отметить, что текстурное сжатие в реальном времени используется при передаче по сети видеопотоков высокого разрешения, например, в системе UltraGrid (8) (9).

И хотя для некоторых форматов уже существуют быстрые алгоритмы компрессии (10) (11) (12), сжатие динамически генерируемых данных требует разработки новых подходов из-за архитектурных особенностей видео адаптеров. К примеру, пиксельный шейдер не имеет доступа к соседним пикселам кадрового буфера, и гарантировать неизменность пикселей в любом блоке 4х4 можно только по завершению отрисовки всего кадра. В этом смысле сжатие кадрового буфера лучше ложится на так называемые тайловые архитектуры (tile-based). Тем не менее, на современных графических ускорителях динамически сгенерированную текстуру можно сжать уже после её записи в видеопамять. Однако текущие 3D API (Direct3D 11.2 и OpenGL 4.4) сильно снижают выигрыш от такого сжатия из-за необходимости проведения лишних операций копирования (13).

Далее в данной статье будут более подробно рассмотрены наиболее известные стандартные форматы сжатия текстур:

•семейство форматов S3TC, используемое в графических процессорах для ПК

•семейства ETC и PVRTC, разработанные для мобильных устройств

•новый формат ASTC, претендующий на все платформы.

Ранние работы связанные с текстурным сжатием

В простейшем случае каждый пиксель изображения можно закодировать одним числом (обычно 4 или 8 бит), определяющим индекс в таблице цветов (палитре). Такой подход широко применялся для реализации кадрового буфера в первых игровых консолях и старых видеоадаптерах, которые были жестко ограниченны по объему памяти. Но использование палитры не подходит для сжатия текстур, ввиду следующих недостатков:

•малая степень сжатия (8bpp)

•низкое качество из-за ограничения количества уникальных цветов (256 цветов при 8bpp)

•необходимость двух обращений в память (выборка индекса цвета и выборка соответствующего значения из палитры). Это увеличивает задержки и отрицательно сказывается на эффективности использования пропускной способности памяти. А при аппаратной реализации выделенной памяти для палитры, её необходимо перезаписывать каждый раз при смене текстуры.

Данный метод является частным случаем векторного квантования (VQ, Vector Quantisation), в котором вектор представлен одним пикселем. Более сложный вариант VQ-сжатия, в котором один вектор представляет сразу несколько соседних пикселей, использовался в игровой консоли Sega Dreamcast (14), что позволило добиться коэффициентов сжатия 1:5 и 1:8 при приемлемом качестве.

Альтернативным подходом является блочное сжатие, предполагающее разбиение изображения на независимые блоки. Каждый блок содержит всю необходимую для распаковки информацию, что позволяет получить значение цвета текселя за одно обращение в память.

Первым подобным алгоритмом был Block Truncating Coding (BTC), предназначенный для сжатия черно-белых изображений (в оттенках серого). Основная идея алгоритма – сохранить математическое ожидание и среднеквадратическое отклонение яркости. При этом в результирующем изображении внутри каждого блока используется только два уровня яркости a и b (Рис. 4). Формат сжатого блока предполагает хранение обоих этих уровней и битовой карты, где каждый бит соответствует одному пикселю.

Рис. 4. Пример кодирования BTC (А – исходный блок,
Б – битовая карта, В – восстановленный блок)

При компрессии на первом шаге изображение разбивается на блоки размера MxN (обычно 4x4). Для каждого блока вычисляются математическое ожидание и среднеквадратическое отклонение . Далее вычисляется битовая карта: 1 означает, что значение яркости данного пикселя больше , а 0 – меньше. Уровни яркости а и b вычисляются по формулам 1.1 и 1.2, что позволяет сохранить математическое ожидание и среднеквадратическое отклонение.

где – количество пикселей в блоке, а – количество “1” в битовой карте.

Большим преимуществом BTC является простота реализации и крайне малые вычислительные затраты на декомпрессию. При использовании блоков 4x4 и глубины цвета 8bpp уровень сжатия равен 2bpp. BTC использовался в камере марсохода NASA (Mars Pathfinder Project) (15).

В случае цветных изображений можно использовать BTC отдельно для каждого цветового канала, что даст уровень сжатия 6bpp. Однако подобная схема сильно снижает качество итогового изображения (Рис. 5). Позже для сжатия цветных изображений была предложена модификация BTC в виде алгоритма CCC (Color Cell Compression), позволившая получить уровни сжатия 2bpp и 3bpp. В алгоритме ССС, так же как и в BTC, все значения квантуются на два уровня, но используется только одна битовая карта для всех трех каналов.

Рис. 5. Пример кодирования BTC (сверху оригинал, снизу восстановленные изображения)

На первом этапе кодирования для каждого пикселя рассчитывается яркость по формуле 1.3 и средняя яркость всего блока . Битовая карта строится путём сравнения яркости пикселя со средней яркостью. Далее некоторым образом выбираются базовые цвета a и b.

(1.3)

В одной из схем CCC базовые цвета сохраняются в формате RGB565 в самом сжатом блоке. Таким образом, размер сжатого блока составляет 48 бит (по 16 бит на базовые цвета и 16 бит на битовую карту), а уровень сжатия – 3bpp. В другой схеме в блоке сохраняются не сами базовые цвета a и b, а их 8-ми битные индексы в общей для всего изображения палитре, что даёт уровень сжатия 2bpp.

Достоинства CCC – это высокий уровень сжатия и простота реализации. Среди недостатков – невысокое качество, так как внутри блока могут использоваться только два уникальных цвета. Тем не менее, основные идеи CCC используются в современных форматах сжатия текстур.

Семейство S3TC

Изначально разработанный и запатентованный компанией S3 Incorporated формат S3TC (16) является одним из наиболее распространённых форматов сжатия. Данный формат вошёл в API DirectX 6.0 под именем DXT1, а его модификации для текстур с альфа-каналом под – именами DXT2-DXT5, которые все вместе зачастую именуются DXTC (DirectX Texture Compression). В качестве расширений OpenGL и OpenGL ES формат DXT1 описан в спецификации EXT_texture_compression_dxt1 (17), являющейся частью спецификации EXT_texture_compression_s3tc (18), в которой дополнительно описаны форматы DXT3 и DXT5.

Затем, начиная с DirectX10, данные форматы стали называться BC1-BC3 (Block Compression), и к ним прибавились форматы BC4 и BC5, которые ранее были известны под именами ATI1/3Dc+ и ATI2/3Dc. Появление формата 3Dc было продиктовано необходимостью сжатия карт нормалей, ибо DXT1 для таких текстур зачастую давал неудовлетворительное качество. Соответствующие форматам BC4 и BC5 спецификации OpenGL называются EXT_texture_compression_rgtc (19), ARB_texture_compression_rgtc (20) и EXT_texture_compression_latc (21).

В DirectX11 появились ещё два формата: BC6H, нацеленный на текстуры с широким динамическим диапазоном, и BC7, призванный существенно улучшить качество сжатия для обычных текстур. Данные форматы довольно сильно отличаются от своих предшественников. Со стороны OpenGL оба эти формата описаны в спецификации ARB_texture_compression_bptc (22).

Во всех форматах семейства S3TC используются блоки исходного изображения размером 4x4. В данном разделе подробно рассмотрены все стандартные форматы этого семейства.

Формат блока BC1 (S3TC/DXT1)

Так же, как и CCC, формат BC1 предполагает хранение в сжатом блоке двух базовых цветов c0 и c1 и битовой карты или таблицы индексов (Рис. 6). Но при кодировании для каждого исходного текселя используются двухбитовые индексы, поэтому внутри блока доступно 4 цвета. Это существенно повышает качество по сравнению с CCC. Два дополнительных цвета с2 и с3 получаются путём интерполяции базовых цветов. Сами базовые цвета сохраняются в сжатом блоке в формате RGB565, то есть по 5 бит на красный и синий каналы, и 6 бит на зелёный цветовой канал. Таким образом, уровень сжатия BC1 получается равен 4bpp. Доступные внутри блока 4 цвета, могут рассматриваться как локальная палитра.

Рис. 6. Пример блока BC1

В формате BC1 различаются блоки двух типов: первый тип не поддерживает прозрачные тексели, а второй – поддерживает.

В большинстве реализаций, два дополнительных цвета c2 и c3 для блоков первого типа вычисляются по формуле 2.1. Если же предположить, что интенсивности цветов внутри блока распределены по нормальному закону, то дополнительные цвета из формулы 2.2, дадут меньшую ошибку сжатия. Такой подход используется в видеокартах nVidia (23). Поэтому на одних и тех же наборах сжатых данных результат декомпрессии может различаться. Более того, аппаратная реализация преобразования цвета из RGB565 в RGB888 и вычисления с2 и с3 может иметь некоторые упрощения, что также влияет на итоговый результат. Однако, в обоих случаях, все четыре цвета будут лежать на одном отрезке в пространстве RGB.

(2.1)

(2.2)

Блоки второго типа позволяют дополнительно закодировать однобитовый альфа-канал, что может использоваться для текстур с простым эффектом прозрачности, когда отдельный тексель может быть только полностью прозрачен или полностью непрозрачен. Для блоков второго типа с3 рассчитывается по формуле 2.3, а с2 считается абсолютно прозрачным. Кроме этого, некоторые блоки исходного изображения, не содержащие прозрачные тексели, могут быть более точно закодированы блоками второго типа.

(2.3)

Различаются типы блоков между собой за счёт избыточности кодирования. Действительно, если в сжатом блоке поменять местами базовые цвета и пересчитать таблицу индексов, то при декомпрессии получится тот же самый блок. Поэтому блоки, у которых с0, интерпретированное как 16-ти битное целое число, больше чем с1, считаются блоками первого типа, все остальные блоки – блоками второго типа.

Выбор базовых цветов является сложной задачей и оказывает сильное влияние на качество восстановленной текстуры. Существует много вариантов нацеленных как на скорость сжатия (10) (11) (24), так и на высокое качество (25).

В 2004 году компанией NVidia было предложено расширение NV_texture_compression_vtc для OpenGL (26), которое добавляет поддержку сжатия 3D-текстур с возможными размерами блока 4x4x1, 4x4x2, 4x4x3, 4x4x4. Однако с точки зрения подходов к сжатию текстур в данном расширении не предлагаются новые идеи. Соответствующий сжатый блок представляет собой просто 1, 2, 3 или 4 блока S3TC/BC1, каждый из которых кодирует соответствующий двумерный срез 4x4.

Формат блока BC2 (DXT2/DXT3)

Формат ВС1 относительно неплохо справляется с 24-битными текстурами, но не позволяет работать с 32-битными текстурами типа RGBA8888 с полноценным альфа-каналом. В альфа-канале может храниться информация о прозрачности, отражающей способности или о других свойствах материала. Для таких текстур в Direct3D предназначены форматы BC2 и BC3. Блок BC2 занимает 128 бит, т.е. в два раза больше, чем BC1. Уровень сжатия 8bpp. В BC2 (Рис. 7) значения альфа-канала хранятся в первой половине блока в явном виде с точностью 4 бита (alpha a - alpha m), а вторая половина представляет из себя блок BC1. Фактически BC2 соответствует текстуре формата RGBA8884 со сжатием цветовых каналов.

Рис. 7. Структура блока BC2. (Источник: Programming Guide for Direct3D 10 (27))

Декодирование цветовых каналов ведётся так же, как и блока BC1, с той лишь разницей, что он всегда рассматривается как блок первого типа с четырьмя доступными цветами внутри блока.

При работе с полупрозрачными текстурами при смешивании с фоном, значение цвета текселя необходимо умножать на коэффициент прозрачности из альфа-канала. В связи с этим в некоторых ситуациях удобно хранить в текстуре значения цветовых каналов уже умноженные на этот коэффициент, что обозначается термином «pre-multiplied alpha». Для таких ситуаций был предложен формат DXT2. Для формата же DXT3 предполагается хранение цветовых компонент в исходном виде. Тем не менее, с точки зрения хранения и декодирования разница в этих форматах отсутствует. Имя формата всего на всего давало приложению подсказку о смысле хранимых в цветовых каналах данных. Поэтому в формате BC3 эти ситуации не различаются, и приложение само ответственно за интерпретацию данных. Важно отметить, что для корректности результата, фильтрация текстур должна производиться со значениями, умноженными на альфа-канал.

Режим pre-multiplied alpha обладает определёнными преимуществами при фильтрации текстур и альфа-смешивании по сравнению с хранением исходных значений цветовых каналов и позволяет упростить аппаратную реализацию. Подробности о pre-multiplied alpha можно прочитать в статье «Jim Blinn's Corner: Compositing, Part 1: Theory» (28).

Формат блока BC3 (DXT4/DXT5)

Блок BC3, так же как и BC2, состоит из 64 бит, предназначенных для хранения альфа-канала, и 64 бит, повторяющих блок BC1. Но тут альфа-канал хранится в сжатом виде (Рис. 8), аналогичном сжатию BC1: в блоке содержатся два базовых значения alpha_0 и alpha_1 с точностью 8 бит и таблица 3-битовых индексов, позволяющая любой точке принимать одно из восьми допустимых значений локальной палитры.

Рис. 8. Структура блока BC3. (Источник: Programming Guide for Direct3D 10 (27))

Для значений альфа-канала выделяются два типа блоков: когда alpha_0 > alpha_1, шесть дополнительных значений локальной палитры вычисляются при помощи линейной интерполяции, в противном случае – только четыре значения, а оставшиеся два соответствуют максимальному и минимальному допустимому значению. Формирование локальной палитры проиллюстрировано в листинге 1. Для цветовых данных блок всегда рассматривается как блок первого типа, и используются формулы 2.1 или 2.2.

$if( alpha_0 > alpha_1 ) { // 6 interpolated alpha values. alpha_2 = 6/7*alpha_0 + 1/7*alpha_1; // bit code 010 alpha_3 = 5/7*alpha_0 + 2/7*alpha_1; // bit code 011 alpha_4 = 4/7*alpha_0 + 3/7*alpha_1; // bit code 100 alpha_5 = 3/7*alpha_0 + 4/7*alpha_1; // bit code 101 alpha_6 = 2/7*alpha_0 + 5/7*alpha_1; // bit code 110 alpha_7 = 1/7*alpha_0 + 6/7*alpha_1; // bit code 111 } else { // 4 interpolated alpha values. alpha_2 = 4/5*alpha_0 + 1/5*alpha_1; // bit code 010 alpha_3 = 3/5*alpha_0 + 2/5*alpha_1; // bit code 011 alpha_4 = 2/5*alpha_0 + 3/5*alpha_1; // bit code 100 alpha_5 = 1/5*alpha_0 + 4/5*alpha_1; // bit code 101 alpha_6 = 0; // bit code 110 alpha_7 = 255; // bit code 111 }$

Листинг 1. Формирование локальной палитры для альфа-канала.
(Источник: Programming Guide for Direct3D 10 (27))

По аналогии с DXT2/DXT3, форматы DXT4/DXT5 в Direct3D 9 отличаются смыслом содержимого цветовых каналов: для DXT4 предполагается хранение значений уже умноженных на коэффициент прозрачности, а для DXT5 – исходных значений. И точно также BC3 не делает различий между этими случаями.

В большинстве случаев формат BC3 позволяет получить лучшую точность значений альфа-канала, по сравнению с BC2.

Формат блока BC4 (ATI1/3Dc+)

Формат BC4 (Рис. 9) представляет собой первую половину блока BC3 и предназначен для сжатия текстур, содержащих всего один канал (например, карта высот или отражающей способности). Значение элементов таких текстур принято ассоциировать с красным цветовым каналом.

Рис. 9. Структура блока BC4. (Источник: Programming Guide for Direct3D 10 (27))

$if( red_0 > red_1 ) { // 6 interpolated color values red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010 red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011 red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100 red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101 red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110 red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111 } else { // 4 interpolated color values red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010 red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011 red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100 red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101 red_6 =-1.0f; // bit code 110 red_7 = 1.0f; // bit code 111 }$

Листинг 2. Пример формирования локальной палитры для блока BC4.
(Источник: Programming Guide for Direct3D 10 (27))

Декодирование блока осуществляется точно так же, как и декодирование значений альфа-канала в формате BC3. Однако BC4, как правило, используется для хранения чисел с плавающей запятой в диапазонах [0, 1] или [-1, 1], и значения red_0 и red_1 в сжатом блоке интерпретируются соответствующим образом. Формирование палитры для случая [-1, 1] показано в листинге 2.

Формат блока BC5 (ATI2/3Dc)

Формат 3Dc был изначально разработан компанией ATI специально для сжатия текстур, содержащих карты нормалей, так как формат DXT1 не обеспечивал необходимого качества сжатия для подобных данных. В таких текстурах содержится информация о векторе нормали поверхности, что позволяет рассчитывать освещённость объектов с высоким уровнем детализации без повышения геометрической сложности объекта (Рис. 1.Б). В цветовых каналах подобных текстур хранятся координаты вектора нормали в трёхмерном пространстве, и все значения интерпретируются как вещественные числа в диапазоне [-1, 1]. Проблема сжатия заключается в том, что в BC1 значения разных цветовых каналов связаны между собой, так как используется одна общая таблица индексов. Для обычных изображений это допущение уместно, но не для карт нормалей, где корреляция каналов намного слабее. Кроме этого BC1 плохо подходит для сжатии плавных градиентов (Рис. 10).

Рис. 10. Пример сжатия карты нормалей. (Источник: ATI 3Dc White Paper (29))

Как правило, нормали должны иметь единичную длину, поэтому их можно задать только двумя координатами x и y, а z можно вычислить по формуле 2.4. В случае использования нормалей типа tangent space (24), знак z всегда берётся положительный.

(2.4)

Блок BC5 состоит из двух блоков BC4, что позволяет сохранить два канала независимо (Рис. 11). За счёт этого, а также благодаря большему набору допустимых значений внутри блока, BC5 обеспечивает результат, существенно превосходящий BC1 по качеству.

Рис. 11. Структура блока BC5. (Источник: Programming Guide for Direct3D 10 (27))

Декодирование каждого полублока совпадает с декодированием BC4. Однако автоматического вычисления координаты z не происходит, так как формат BC5 может использоваться для любых двухканальных текстур, и распакованные значения заполняют красный и зелёный цветовые каналы. При работе с нормалями недостающая координата может быть вычислена в пиксельном шейдере.

Соответствующие форматам BC4 и BC5 спецификации OpenGL называются EXT_texture_compression_rgtc (19), ARB_texture_compression_rgtc (20) и EXT_texture_compression_latc (21). При этом и rgtc и latc варианты спецификаций описывают оба формата BC4 и BC5. Только в rgtc распакованные данные интерпретируются как значения красного или красного и зелёного цветовых каналов, а в latc – как значения яркости или альфа-канала и яркости.

Общая информация о форматах BC6H и BC7

Основными недостатками BC1, лимитирующими точность воспроизведения исходного изображения, являются:

•малая точность представления базовых цветов (формат RGB565). К тому же, неравномерное распределение бит по каналам может приводить к искажению цветов. К примеру, большинство чистых оттенков серого не могут быть представлены в RGB565: цвет RGB565(12, 24, 12) соответствует слегка фиолетовому RGB888(99, 97, 99), а RGB565(12, 25, 12) уже слишком зелёному RGB888(99, 101, 99).

•малый размер локально палитры. Внутри блока доступно всего 4 различных цвета.

•ограничения на доступные внутри блока цвета. Так как локальная палитра получается путём линейной интерполяции базовых цветов, то все тексели внутри сжатого блока будут располагаться на одной прямой в пространстве RGB, что может приводить к некорректным результатам (Рис. 12).

Рис. 12. Пример кодирования "сложного" для BC1 блока

Решаются эти проблемы в новых форматах за счёт хранения в блоке до трёх пар базовых цветов и повышении точности представления базовых цветов. Оба формата используют блоки размером 128 бит, что определяет их уровень сжатия 8bpp. В зависимости от типа блока, в нём отличается набор полей и их размер, что позволяет для каждого блока исходного изображения использовать именно тот расклад полей, который обеспечивает минимальную ошибку. При этом тип блока задаётся явно первыми битами, а количество типов блоков увеличилось до 14 для BC6H, и до 8 для BC7. Это придаёт большую гибкость, но сильно усложняет процесс сжатия.

Использование нескольких пар базовых цветов основано на разделении всех текселей внутри блока на отдельные группы или регионы, и в каждом регионе используется своя пара базовых цветов. Разделение на регионы возможно только одним из предопределённых стандартом способов. Пример возможных разбиений приведён на Рис. 13. Номер конкретного разбиения указывается в сжатом блоке. Всего определено по 64 различных делений для блоков с двумя и тремя регионами.

Рис. 13. Первые восемь вариантов разделения блока на 2 и 3 региона

Рис. 14. Упрощённый пример декодирования блока BC6H/BC7 с двумя регионами

Как и прежде значение из таблицы индексов задаёт пропорции, в которых смешиваются базовые цвета при распаковке. А расположение текселя и номер разбиения определяют, какую пару базовых цветов использовать. Упрощённый пример декодирования приведён на Рис. 14, где первая пара базовых цветов обозначена как A0 и A1, а вторая – B0, B1. Для декодирования текселей, относящихся к региону 0 (обозначен зелёным цветом) используются цвета А0 и A1, а цвета B0 и B1 используются для региона 1. Стоит отметить, что размер индекса может составлять от двух до четырёх бит. То есть внутри одного региона доступно от 2 до 14 промежуточных точек между базовыми цветами.

Немаловажной особенностью форматов BC6H и BC7 является требование соблюдения аппаратурой побитовой точности при распаковке относительно эталонного декомпрессора, включая обработку некорректных блоков. Более подробную информацию обо всех типах блоков можно найти в документации к Direct3D (30) и в спецификации расширения OpenGL ARB_texture_compression_bptc (22). Описание форматов BC6H и BC7 входят в основную спецификацию OpenGL начиная с версии OpenGL 4.2 Core Profile (31).

Интерполяция промежуточных цветов

В формате DXT1 не оговаривалось, каким именно способом должны формироваться промежуточные цвета внутри блока. В новых же форматах коэффициенты для линейной интерполяции строго заданы стандартом. Пример псевдокода для BC7 приведён в листинге 3. Размер одного индекса (indexprecision) может составлять 2, 3 или 4 бита. Основание для коэффициентов интерполяции всегда выбирается равным 64.

Листинг 3. Интерполяция значений промежуточных цветов для блоков BC7.
(Источник: Programming Guide for Direct3D 11 (30))

Не вдаваясь в подробности, можно сказать, что интерполяция промежуточных цветов для блоков BC6H отличается только используемым типом данных.

Кодирование таблицы индексов

В DXT1 взаимным расположением базовых цветов неявно кодировался тип блока. В новых форматах этот же трюк используется для уменьшения размеров таблицы индексов. Каждая пара базовых цветов позволяет сохранить один бит. Для примера, выберем самый левый верхний индекс, соответствующий текселю 0. Если его старший бит равен 1, то мы можем поменять местами соответствующие базовые цвета, что приведёт к инверсии всех индексов данного региона. Таким образом, всегда можно расположить базовые цвета так, чтобы для одного определённого индекса в каждом регионе, старший бит равнялся 0. И данные биты можно не сохранять в сжатом блоке. Такие индексы называются якорными (anchor). Для региона 0 это всегда тексель 0. Расположение якорного индекса для некоторых разбиений приведено на Рис. 15.

Рис. 15. Расположение якорного индекса для некоторых блоков с двумя и тремя регионами

Формат блока BC7

Табл. 1. Размеры используемых полей для всех типов блоков BC7

В Табл. 1 представлены размеры в битах (кроме столбца «Количество») для различных полей блока BC7:

•Color – размер в битах каждого цветового канала

•Alpha – размер в битах значения альфа-канала

•P-bit – наличие P-бита

•P-shared – наличие разделяемого P-бита

•Rotation – размер в битах поля Rotation

•ISB – наличие однобитового селектора таблицы индексов (idxMode)

•Количество – количество регионов в данном типе блока

•Partition – размер в битах номера разделения

•Index1 – размер в битах отдельного индекса в таблице индексов

•Index2 – размер в битах отдельного индекса в дополнительной таблице индексов

•Table – размер в битах таблицы индексов

Код режима в Табл. 1 указан как значение младшего байта, где наименьший значащий бит расположен справа. На рисунках же наименьший значащий бит располагается слева, поэтому значения записаны в обратном порядке.

Поле “Partition” в формате BC7 Mode 0 (Рис. 16) имеет длину 4 бита, поэтому при кодировании могут использоваться только первые 16 вариантов разделения текселей на регионы. Во всех остальных типах блоков BC7, использующих 2 или 3 региона, доступны все 64 варианта деления.

Значение нового поля “P-бит”, а также соответствующей буквы в обозначении формата RGBP/RGBAP, можно продемонстрировать на примере блока BC7 Mode 0 (Рис. 16). В данном типе блока присутствуют 3 пары базовых цветов в формате RGB444 и по одному P-биту для каждого базового цвета. При распаковке каждый базовый цвет предварительно расширяется до RGB555, где в качестве последнего бита во все цветовые каналы подставляется P-бит. По сравнению с хранением цвета сразу в формате RGB555 такой подход позволяет сэкономить по 2 бита для каждого базового цвета, а ошибка не превышает одного наименьшего бита в одном из цветовых каналов.

В формате BC7 Mode 1 используется разделяемый P-бит (P-shared). Это означает, что один P-бит сохраняется не для одного базового цвета, а для целой пары. То есть оба базовых цвета в паре будут использовать один и тот же P-бит.

Рис. 16. Формат блока BC7 Mode 0. (Источник: Programming Guide for Direct3D 11 (30))

Рис. 17. Формат блока BC7 Mode 4. (Источник: Programming Guide for Direct3D 11 (30))

Форматы BC7 Mode 4 (Рис. 17) и BC7 Mode 5 имеют по две таблицы индексов, позволяя сохранить один из каналов независимо от остальных. Их можно использовать для независимого хранения блока цветовых каналов и альфа-канала (по аналогии с блоком BC3), когда значения цветовых и альфа-канала обладают слабой корреляцией. Однако имеется возможность сохранить независимо (со своей таблицей индексов) любой другой канал. Для выбора того, какой именно из каналов будет сохраняться отдельно, используется двухбитное поле “Rotation”.

В формате BC7 Mode 4 индексы в двух таблицах имеют разный размер и, соответственно, обеспечивают разную точность. Поле “ISB” (idxMode) позволяет указать какая из этих таблиц будет использоваться для альфа-канала, а какая – для цветовых каналов. Но точно так же за счёт изменения поля “Rotation”, в качестве канала с независимой таблицей индексов может выступать любой из цветовых каналов.

Формат блока BC6H

Формат BC6H предназначен для сжатия текстур с широким динамическим диапазоном или HDR текстур (High Dynamic Range) (32). Альфа-канал не поддерживается, а для представления значений цветовых каналов используются 16 битные числа с плавающей запятой. Формат BC6H определён для двух вариантов – знакового и беззнакового. Соответственно, декодер может работать в знаковом или беззнаковом режиме. Тем не менее, значения на выходе декодера всегда являются знаковыми и соответствуют формату IEEE 754 half/binary16 (Рис. 18А). Перед передачей в шейдер эти значения конвертируются в 32 битный тип float. Все типы блоков полностью совпадают для обеих версий BC6H, разница заключается лишь в трактовке значений базовых цветов. Условно, можно сказать, что для знаковой версии внутреннее представление значений соответствует Рис. 18А, а для беззнаковой – Рис. 18Б. На практике режимы работы декодера отличаются обработкой знаковых разрядов при деквантовании цветов, и финальным преобразованием типа данных в half.

Рис. 18. Форматы 16-битного числа с плавающей запятой (А – знаковый, Б – беззнаковый)

Всего определенно 14 типов блоков (Табл. 2). BC6H поддерживает только один или два региона в блоке, то есть только одну или две пары базовых цветов. Номер разделения на регионы кодируется 5 битами, поэтому для выбора доступны только первые 32 варианта. В большинстве типов блоков (кроме Mode 10 и Mode 11) используется дельта-кодирование базовых цветов – непосредственно сохраняется только один базовый цвет e0, а для остальных сохраняется разница с e0.

Табл. 2. Размеры используемых полей для всех типов блоков BC6H

При декодировании BC6H используется только целочисленная арифметика, в том числе и на этапе интерполяции, хотя финальные значения интерпретируются как числа с плавающей запятой. Это возможно за счёт метода кодирования чисел с плавающей запятой: мантисса располагается в младших битах, а экспонента – в старших, и экспонента кодируется в прямом коде со смещением. Поэтому интерпретация таких двоичных чисел как целочисленных имеет определённый математический смысл. В частности, для любых положительных вещественных A и B таких, что A > B, отношение A > B сохранится и при интерпретации двоичного кода как целых чисел. Пример целочисленной арифметики с вычислением среднего значения приведён в листинге 4. При использовании линейной интерполяции, если двоичный порядок интерполируемых значений сильно отличается, итоговое преобразование будет иметь экспоненциальный характер (Рис. 19).

union {
float f;
unsigned int i;
} A, B, C;
A.f = 3.75f; // A = 0x40700000 A.f = 3.7500000 A.i = 1081081856
B.f = 20.0f; // B = 0x41a00000 B.f = 20.000000 B.i = 1101004800
C.f = (A.f + B.f) / 2; // C = 0x413e0000 C.f = 11.875000 C.i = 1094582272
C.i = (A.i + B.i) / 2; // C = 0x41080000 C.f = 8.5000000 C.i = 1091043328

Листинг 4. Пример применения целочисленной арифметики к вещественным числам

Рис. 19. Пример линейной интерполяции вещественных чисел (Веществ.)
и целых при последующей интерпретации их как вещественных (Целочисл.)

Декодирование цветов локальной палитры состоит из четырёх этапов:

•Знаковое расширение и обратное дельта-кодирование. В случае знакового формата BC6H знаковое расширение (копирование знакового бита в старшие разряды) применяется ко всем значениям цветов и дельтам, хранящимся в сжатом блоке, а в случае беззнакового формата – только к дельтам. Далее для всех типов блоков кроме Mode 10 и Mode 11, значение базового цвета e1 и, в случае блока с двумя регионами, цветов e2 и e3 вычисляется как сумма e0 и соответствующей дельты. В блоках Mode 10 и Mode 11 значения всех базовых цветов хранятся в явном виде.

•Деквантование базовых цветов. Для беззнакового формата деквантование выполняется как (((X << 16) + 0x8000) >> uBitsPerComp), где uBitsPerComp равен размеру в битах цветовых каналов e0. Граничные случаи (ноль, максимальное значение) учитываются отдельно.

•Целочисленная интерполяция осуществляется так же как и при декодировании BC7. С учётом наличия знаковых и беззнаковых форматов, диапазон возможных значений на входе будет составлять от -32768 до 65535. Поэтому интерполятор реализуется с использованием 17-битных знаковых чисел.

•Коррекция. Так как в формате IEEE 754 максимальное значение экспоненты (все единицы) отведено для кодирования специальных значений INF/NaN, полученные после интерполяции числа домножаются на 31/32 в знаковом и на 31/64 в беззнаковом варианте. Финальное число интерпретируется как IEEE 754 half.

Семейство ETC

Формат ETC (Ericsson Texture Compression) изначально разрабатывался для использования в мобильных решениях и на сегодняшний день является стандартным для устройств на платформе Android. ETC1 поддерживается в стандартах OpenGL ES и WebGL в виде расширений OES_compressed_ETC1_RGB8_texture (33) и WEBGL_compressed_texture_etc1 (34). Описание форматов ETC1 и ETC2 входят в основную спецификацию OpenGL начиная с версии OpenGL 4.3 Core Profile (35).

Первая версия формата, представленная в 2004 году, носила название PACKMAN (3). Позже, в 2005 году был представлен формат iPACKMAN (36), более известный как ETC1, который получил широкое распространение в мобильных устройствах. Последующее развитие данной схемы сжатия вылилось в появление в 2007 году формата ETC2 (37).

Рис. 20. Концепция сжатия ETC. (Источник: ETC2 Paper (37))

Во всём семействе форматов ETC эксплуатируется тот факт, что человек более восприимчив к изменению яркости, нежели к изменению цвета. Поэтому в сжатой текстуре в каждом подблоке (блоки ETC1/ETC2 состоят из двух подблоков) сохраняется только один ключевой цвет, но изменение яркости кодируется для каждого отдельного текселя (Рис. 20). Преимущество такого подхода состоит в том, что изменение яркости задаётся всего одним целым числом, которое прибавляется ко всем цветовым каналам. Количество различных уровней яркости внутри подблока ограничено четырьмя, и для ETC также применимо понятие локальной палитры, как набора цветов, доступных внутри сжатого блока.

Патенты на форматы сжатия ETC1 (38) (39) и ETC2 (40) (41) принадлежат шведской компании Ericsson (Telefonaktiebolaget L. M. Ericsson).

PACKMAN

В ситуации, когда размер сжатого блока оказывается меньше или равен ширине шины памяти, можно существенно упростить аппаратную реализацию за счёт отказа от промежуточных буферов при считывании из памяти и ликвидации соответствующих простоев графического конвейера (3). Но так как мобильные устройства обладают очевидными ограничениями на ширину шины памяти, при разработке формата PACKMAN было принято решение использовать блоки размером 2х4 текселя. В итоге сжатый блок PACKMAN занимает всего 32 бита. Таким образом, уровень сжатия составляет 4bpp, что соответствует формату BC1.

В сжатом блоке сохраняется всего один ключевой цвет в формате RGB444, а остальные цвета получаются путём изменения его яркости. Хотя основная идея ETC сильно отличается от BC1, процесс декодирования блока, в сущности, повторяет распаковку BC1: при декодировании сначала восстанавливается локальная палитра, состоящая из 4-х цветов, а затем для каждого текселя выбирается цвет из этой палитры, согласно таблице двухбитных индексов, непосредственно хранящейся в сжатом блоке (Рис. 21). Но из-за маленького размера блока на информацию о яркости остаётся всего 4 бита. Поэтому используется специальная предопределённая таблица возможных значений отклонений яркости (Табл. 3). Номер записи в таблице яркостей и кодируется этими 4-мя битами.

Рис. 21. Пример декодирования блока PACKMAN

Индекс	0	1	2	3	4	5	6	7
Яркость 00	2	4	6	12	8	19	28	42
Яркость 01	8	12	31	34	50	47	80	127
Яркость 10	-2	-4	-6	-12	-8	-19	-28	-42
Яркость 11	-8	-12	-31	-34	-50	-47	-80	-127

Табл. 3. Предопределённые модификаторы яркости для формата PACKMAN

Легко заметить, что верхняя половина Табл. 3 отличается от нижней только знаком, что позволяет упростить аппаратную реализацию декодера. Непоказанные в таблице яркости для индексов 8-15 равны удвоенным значениям для индексов 0-7. Сами значения в этой таблице были получены путём оптимизации общей ошибки сжатия для тестового набора изображений.

ETC1 (iPACKMAN)

Основные проблемы формата PACKMAN были связаны с низкой точностью хранения базового цвета (RGB444) и невозможностью использования нескольких различных базовых цветов внутри блока. Для улучшения качества сжатия был предложен формат ETC1.

Блок ETC1 имеет размер 4х4 текселя и состоит из двух подблоков, практически идентичных блокам PACKMAN. Для решения проблемы с точностью представления базового цвета в дополнение к варианту, когда данные подблоков сохраняются независимо, был введён дифференциальный тип блока, когда для первого подблока базовый цвет сохраняется с повышенной точностью в формате RGB555, а для второго – только разности для каждого цветового канала, по 3 бита на канал. Первый тип блока называется Individual, а второй – Differential (Рис. 22).

Рис. 22. Формат блока ETC1

N	0	1	2	3	4	5	6	7
Яркость 00	2	5	9	13	18	24	33	47
Яркость 01	8	17	29	42	60	80	106	183
Яркость 10	-2	-5	-9	-13	-18	-24	-33	-47
Яркость 11	-8	-17	-29	-42	-60	-80	-106	-183

Табл. 4. Предопределённые модификаторы яркости для форматов ETC1 и ETC2

Но для кодирования типа блока требуется ещё один бит, поэтому размер поля индекса таблицы яркостей (T0 и T1 на Рис. 22) пришлось сократить до 3 бит. Соответственно таблица яркостей (Табл. 4) теперь содержит только 8 записей, и значения в ней по понятным причинам отличаются от Табл. 3. Но так как уменьшаются поля для обоих подблоков, то высвобождается целых два бита. Один из них определяет собственно тип блока (diff), а второй говорит о том, как расположены подблоки внутри блока – горизонтально или вертикально (flip).

ETC2

Дифференциальный режим и возможность поворота подблоков существенно улучшили качество сжатия. Тем не менее, внутри каждого подблока можно сохранить только один базовый цвет. Поэтому подблоки, в которых хроматическая составляющая цветов текселей сильно различается, будут сжаты с большой ошибкой. Так же для ETC1 определённую сложность представляют блоки с плавными градиентами.

В формате ETC2 данные проблемы решаются путём введения дополнительных типов блоков. Новые типы блоков кодируются комбинациями, которые недопустимы в формате ETC1. Поэтому аппаратный декодер ETC2 полностью совместим с форматом ETC1. Некорректные комбинации возникают для блоков типа Differential, когда сумма значения базового цвета и дельты выходит за границы допустимого для 5-битного числа диапазона [0, 31] и происходит переполнение. Подобные блоки рассматриваются как один из новых типов блоков. Все возможные комбинации значений R0 и dR1 приводящие к переполнению приведены в Табл. 5.

R0	dR1	R0 и dR1 двоичн.	Кодируемые биты
0	-4	00000 100	0000
0	-3	00000 101	0001
0	-2	00000 110	0010
0	-1	00000 111	0011
1	-4	00001 100	0100
1	-3	00001 101	0101
1	-2	00001 110	0110
29	3	11101 011	0111
2	-4	00010 100	1000
2	-3	00010 101	1001
30	2	11110 010	1010
30	3	11110 011	1011
3	-4	00011 100	1100
31	1	11111 001	1101
31	2	11111 010	1110
31	3	11111 011	1111

Табл. 5. Комбинации значения цвета R0 и дельты dR1,
приводящие к переполнению

Внутри такого блока можно закодировать 59 бит полезной информации для одного нового типа блока: из 64 бит блока 1 бит уходит на diff и 8 бит на R0 и dR1, но можно дополнительно использовать по два младших бита R0 и dR1 (столбец «Кодируемые биты» в Табл. 5).

Переполнением в зелёном канале можно закодировать ещё один режим. Правда полезная информационная нагрузка будет ещё меньше, так в таком блоке не должно быть переполнения в красном канале, иначе он будет рассматриваться как блок предыдущего типа. Но на это тратится всего один бит. Достаточно сравнить два старших бита R0 – их неравенство гарантирует отсутствие переполнения (что видно из Табл. 5). Итого 58 бит на второй дополнительный режим.

Аналогичным образом кодируется третий режим с 57 битами полезной нагрузки. Все возможные типы блоков приведены в Табл. 6.

Тип блока	diff	Переполнение
Тип блока	diff	R	G	B
Individual	0	-	-	-
59-bit mode (T-mode)	1	Да	-	-
58-bit mode (H-mode)	1	Нет	Да	-
57-bit mode (Planar mode)	1	Нет	Нет	Да
Differential	1	Нет	Нет	Нет

Табл. 6. Типы блоков ETC2

В T- и H-блоках младшие 32 бита также отведены под таблицу индексов, но локальная палитра восстанавливается совсем другим способом. В T-блоке два базовых цвета A (r0,g0,b0) и B (r1,g1,b1) непосредственно сохраняются в формате RGB444. Оставшиеся 3 бита кодируют величину d. Два других цвета в локальной палитре вычисляются как С0=(A – (d, d, d)) и С1=(A + (d, d, d)), при этом значения A и B предварительно конвертируется в формат RGB888. Таким образом, цвета локальной палитры образуют в пространстве RGB силуэт буквы T (Рис. 23). Такой расклад подходит для кодирования блоков, где основная часть точек лежит вдоль одной прямой, но в то же время присутствует отдельное скопление точек. Следует отметить, что величина d кодируется не непосредственно – значение 3 битового поля используется как индекс в LUT-таблице {3,6,11,16,23,32,41,64}.

Рис. 23. Пример расположения точек T-блока. (Источник: ETC2 Paper (37))

Н-блок очень похож на T-блок. В сжатом блоке также сохраняются цвета A и B и индекс d, но в локальной палитре используются цвета C0, C1, C2, C3. Соответственно все ключевые цвета образуют силуэт буквы H (Рис. 24). Такой режим подходит для кодирования блоков, где точки лежат вдоль двух прямях. Но в H-блоке доступно на 1 бит меньше, чем в T-блоке, а данных необходимо сохранить столько же (2 цвета RGB444, индекс d и таблицу индексов). Эта проблема решается с помощью трюка, использованного в формате BC1. Здесь в силу полной симметричности цвета A и B можно поменять местами, поэтому недостающий бит кодируется взаимным расположением цветов A и B.

Рис. 24. Пример расположения точек H-блока. (Источник: ETC2 Paper (37))

Тип блока Planar используется для кодирования плавных градиентов. Все доступные 57 бит отводятся для хранения трёх базовых цветов С₀, C_H, C_V в формате RGB676 (Рис. 25). И цвета всех текселей в блоке вычисляются с помощью линейной фильтрации (формула 3.1). X и Y соответствуют координатам текселя внутри блока и принимают значения от 0 до 3.

(3.1)

Рис. 25. Расположение ключевых точек и пример распаковки блока ETC2-Planar

Кроме варианта для сжатия RGB изображений, в OpenGL определён так называемый «punch through alpha» вариант ETC2. То есть формат для текстур с простым эффектом прозрачности или с однобитовым альфа-каналом. В таком варианте ETC2 отсутствует тип блока Individual, соответственно блоки типа T, H и Planar определяются только по наличию переполнения в каком-либо цветовом канале. Бит diff, который служил для различения Individual и Differential блоков теперь влияет на декодирование Differential блока. Если он равен «1», то блок распаковывается, как и раньше, а если «0» – то для модификации яркости используется Табл. 7, где индекс «10» определяет полностью прозрачный тексель. Распаковка T, H и Planar блоков ведётся без изменений и все тексели считаются полностью непрозрачными.

N	0	1	2	3	4	5	6	7
Яркость 00	0	0	0	0	0	0	0	0
Яркость 01	8	17	29	42	60	80	106	183
Яркость 10	прозр.	прозр.	прозр.	прозр.	прозр.	прозр.	прозр.	прозр.
Яркость 11	-8	-17	-29	-42	-60	-80	-106	-183

Табл. 7. Предопределённые модификаторы яркости для формата ETC2 "punch through alpha"

EAC

В исходном варианте формата ETC2 нет возможности сохранения полноценного альфа-канала, что критично для многих видов текстур. А для карт нормалей важно качественное сжатие двух независимых цветовых каналов, что ETC2 также не поддерживает. Для подобных случаев используется блок EAC размером 64 бита, позволяющий закодировать один канал для 4х4 текселей с высокой точностью. В OpenGL определены следующие форматы, включающие в себя EAC:

•COMPRESSED_RGBA8_ETC2_EAC / COMPRESSED_SRGB8_ALPHA8_ETC2_EAC – 128 битный блок, одна половина которого является блоком ETC2, хранящим RGB компоненты, а вторая половина – блоком EAC, хранящим альфа-канал. Является аналогом BC3.

•COMPRESSED_R11_EAC / COMPRESSED_SIGNED_R11_EAC – 64 битный блок, аналог BC4. Один блок EAC, хранящий значения красного цветового канала.

•COMPRESSED_RG11_EAC / COMPRESSED_SIGNED_RG11_EAC – 128 битный блок, аналог BC5. Два независимых блока EAC, хранящие значения красного и зелёного цветовых каналов.

Распаковка EAC во всех обозначенных случаях несколько различается, но незначительно. Поэтому рассмотрим только формат EAC из блока COMPRESSED_RGBA8_ETC2_EAC. Подробности обо всех вариантах ETC и EAC могут быть найдены в спецификациях OpenGL 4.4 Core Profile (42).

Сам принцип сжатия EAC повторяет идеи, использованные в ETC: для всего блока 4х4 сохраняется одно базовое значение (base), а на основании индекса, сохраняемого для каждого текселя, изменяется его «яркость». Также имеется таблица (Табл. 8), определяющая изменение «яркости» (Luminance) для каждого значения индекса, и для каждого блока номер используемой из этой таблицы записи (N) хранится непосредственно внутри блока. Единственное новое дополнение – значение модификатора яркости предварительно умножается на коэффициент (Mul), так же хранящийся в сжатом блоке. Итого значение текселя A вычисляется по формуле 3.2, где функция clamp255 приводит вышедшие за границы диапазона [0; 255] значения к 0 или к 255.

(3.2)

Базовое значение хранится без потери точности с использованием 8 бит (Рис. 26). Индексы текселей трёхбитные, поэтому внутри блока доступно 8 различных значений.

Рис. 26. Формат блока EAC

N	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
Яркость 000	3	-3	-2	-2	-3	-3	-4	-3	-2	-2	-2	-2	-3	-1	-4	-3
Яркость 001	-6	-7	-5	-4	-6	-7	-7	-5	-6	-5	-4	-5	-4	-2	-6	-5
Яркость 010	-9	-10	-8	-6	-8	-9	-8	-8	-8	-8	-8	-7	-7	-3	-8	-7
Яркость 011	-15	-13	-13	-13	-12	-11	-11	-11	-10	-10	-10	-10	-10	-10	-9	-9
Яркость 100	2	2	1	1	2	2	3	2	1	1	1	1	2	0	3	2
Яркость 101	5	6	4	3	5	6	6	4	5	4	3	4	3	1	5	4
Яркость 110	8	9	7	5	7	8	7	7	7	7	7	6	6	2	7	6
Яркость 111	14	12	12	12	11	10	10	10	9	9	9	9	9	9	8	8

Табл. 8. Предопределённые модификаторы (Mod) для формата EAC

Приведём пример распаковки одного значения. Допустим, в сжатом блоке мы имеем базовое значение 1101 1110₂, mul = 1010₂, N = 1101₂ и индекс текселя 001₂. Получаем base = 222, mul=10, N=13. В нашем случае N соответствует набору модификаторов {-1, -2, -3, -10, 0, 1, 2, 9} (столбец №13 в Табл. 8), а индекс 001₂ – конкретному значению mod=-2. Подставляя всё в формулу 3.2 получаем A=clamp255(222 + 10 × (-2)) или A=202.

Семейство PVRTC

Формат PVRTC (14), разработанный для семейства графических ядер PowerVR и запатентованный компанией Imagination Technologies (43) (44) (45) (46), используется в устройствах Apple, таких как iPhone и iPad. Для новых процессоров PowerVR 5XT и PowerVR6 была представлена усовершенствованная версия формата сжатия PVRTC2. Соответствующие расширения OpenGL ES называются IMG_texture_compression_pvrtc (47), IMG_texture_compression_pvrtc2 (48), EXT_pvrtc_sRGB (49). Расширение для WebGL – WEBGL_compressed_texture_pvrtc (50).

Формат PVRTC является самым закрытым среди упомянутых в данном обзоре. Кроме исходной статьи автора PVRTC «Texture Compression using Low-Frequency Signal Modulation» (14) и нескольких заметок от разработчиков Imagination Technologies (51) (52) (53) в открытом доступе практически нет никакой технической информации. Даже в описании расширений OpenGL ES и WebGL отсутствуют детали о формате сжатого блока и работе компрессора. Тем не менее, разработчики библиотеки crunch для сжатия текстур ведут эксперименты с целью написания открытого компрессора PVRTC (54) (55).

Подходы к сжатию, использованные в PVRTC, непохожи на рассмотренные ранее. Строго говоря, PVRTC не является блочным кодеком. Основная идея перекликается с вейвлет сжатием и состоит в выделении низкочастотного и высокочастотного сигналов. В роли низкочастотного сигнала выступают две версии исходного изображения A и B, уменьшенные в 4 раза по вертикали и по горизонтали. Высокочастотный сигнал представлен коэффициентами модуляции М. При распаковке изображения A и B сначала увеличиваются до исходного размера, а затем смешиваются между собой в пропорциях, задаваемых сигналом модуляции (Рис. 27). Значение модуляции задаётся для каждого текселя исходной текстуры.

Рис. 27. Иллюстрация основной идеи сжатия PVRTC. (Источник: PVRTC Paper (14))

Такой подход позволяет в большей степени, нежели остальные форматы, использовать пространственную локальность цветов текселей. Вдобавок сжатие PVRTC не вносит блочных артефактов в изображение. Кодирование участков текстуры с плавными градиентами также не вызывает трудностей.

В последних семействах графических ядер PowerVR Series5XT и PowerVR Series6 от Imagination Technologies была добавлена поддержка нового формата PVRTC2 (51) (52) (53). Обе версии PVRTC и PVRTC2 имеют режимы с коэффициентом сжатия 4bpp и 2bpp.

С выходом обновлённой версии формата появилась небольшая путаница с наименованиями. Дело в том, что после появления исходного формата PVRTC довольно популярным обозначением для его двух режимов сжатия стало PVRTC2 и PVRTC4, что совпадает с именем нового формата. Imagination Technologies рекомендует использовать следующие обозначения: PVRTC 4bpp, PVRTC 2bpp, PVRTC2 4bpp, PVRTC2 2bpp (или PVRTCII 2bpp/4bpp).

PVRTC 4bpp

С точки зрения производительности выборка значений из трёх разных изображений для распаковки всего одного текселя это не самая лучшая идея. Поэтому физически сжатые данные хранятся 64-битными блоками. Каждый такой блок содержит один пиксель изображения A и B, и значение сигнала модуляции для соответствующего участка 4х4 (Рис. 28).

Рис. 28. Формат блока PVRTC 4bpp

Любой из цветов A и B может быть сохранён как с альфа-каналом, так и без, что определяется старшим битом. Точность представления синего цветового канала цвета A на один бит меньше. Итого возможные форматы цвета A – RGB554 или ARGB3443, цвета B – RGB555 или ARGB3444.

Для распаковки произвольного текселя в общем случае требуется прочитать 4 соседних блока PVRTC (Рис. 29). Это необходимо, чтобы восстановить соответствующие участки увеличенных изображений A и B. При этом содержащейся в четырёх блоках информации достаточно, чтобы восстановить участок текстуры размером 5х5. Схематично пример декодирования представлен на Рис. 30.

Рис. 29. Участок текстуры, декодируемый при
помощи четырёх соседних блоков PVRTC

Рис. 30. Пример декодирования PVRTC 4bpp

Увеличиваются A и B до исходных размеров при помощи билинейной фильтрации. После чего смешиваются в пропорциях определяемых сигналом модуляции (Табл. 9). Бит Mode(Рис. 28) позволяет закодировать в данном блоке однобитовый альфа-канал без снижения точности представления цветов (режим «punch through alpha»). Когда бит Mode равен «1», индекс текселя «10» используется для кодирования нулевого значения альфа-канала (полностью прозрачный тексель).

Индекс текселя (сигнал модуляции)	Коэффициент смешивания (Mode=0)	Коэффициент смешивания (Mode=1)
00	0/8	0/8
01	3/8	4/8
10	5/8	4/8 (+ «punch through alpha»)
11	8/8	8/8

Табл. 9. Коэффициенты смешивания, используемые в PVRTC

Стоит отметить, что, несмотря на существенно различающиеся идеи, используемые для сжатия, BC1 может рассматриваться как частный случай PVRTC, где для увеличения изображений A и B используется ступенчатая функция.

Может показаться, что необходимость чтения сразу четырёх блоков будет губительна для производительности. Но это не совсем так. Во-первых, негативный эффект сглаживается текстурным кэшем, и для соседних областей потребуется только выборка недостающих блоков. Во-вторых, перед передачей в шейдер, значения текселей подвергаются билинейной фильтрации или более сложному варианту фильтрации. А для этого как минимум требуются значения блока текселей 2х2. И для PVRTC вся информация, необходимая для распаковки произвольного блока текселей 2х2, всегда может быть выбрана из четырёх соседних сжатых блоков. А при обычном блочном сжатии (S3TC/ETC) для текселей, находящихся на границе блоков, также может потребоваться выборка четырёх сжатых блоков.

Компрессия текстур в формат PVRTC является сложной операцией. Переборные методы в данном случае осложняются тем, что изменение любого базового цвета влияет на участок размером 7х7 (Рис. 31). Эта же особенность осложняет создание текстурных атласов и динамическое изменение сжатых текстур. Соответственно при компоновке текстуры необходимо выдерживать определённое расстояние между соседними элементами.

Рис. 31. Область влияния базового цвета для формата PVRTC

PVRTC 2bpp

Для формата PVRTC определён режим с очень высокой степенью сжатия 2bpp. Набор и размер полей в таком режиме совпадает с режимом 4bpp (Рис. 32). Но изображения A и B (низкочастотные сигналы) стали ещё в 2 раза меньше по горизонтали. Поэтому поле «сигнал модуляции» теперь содержит информацию об участке текселей размером 8х4. Поменялись и режимы модуляции. При бите «Mode» равном «0» каждому текселю соответствует отдельный однобитовый индекс. В противном случае используются двухбитные индексы, но только для половины текселей, и расположены они в шахматном порядке. Коэффициенты смешивания для текселей не имеющих индексов вычисляются как среднее арифметическое двух или четырёх соседей.

Рис. 32. Формат блока PVRTC 2bpp

Схематичный пример декодирования участка текстуры для режима PVRTC 2bpp приведён на Рис. 33. Предполагается, что поле «Mode» во всех четырёх сжатых блоках равно «0».

Рис. 33. Пример декодирования PVRTC 2bpp (Mode=0)

PVRTC2 4bpp

Новый формат PVRTC2 позволяет повысить качество сжатия и ликвидировать некоторые недостатки старого формата. Например, в PVRTC2 добавлена возможность хранения NPOT-текстур. NPOT (Non Power Of Two) – это текстуры с разрешением отличным от степени двойки. Непосредственно к формату это не имеет особого отношения, но для этого требуется определённая поддержка со стороны аппаратуры. В частности, “железо” должно уметь правильно вычислять адрес необходимого сжатого блока.

Повышение качества сжатия достигается за счёт введения новых типов блоков или режимов декодирования. В PVRTC базовые цвета A и B могли иметь альфа-канал независимо друг от друга. И под указание формата цвета в сжатом блоке отводилось 2 бита. Однако ситуация, когда у одного цвета указан альфа-канал, а у другого не указан, не всегда востребована. Поэтому первый бит (Opacity) теперь отвечает за формат обоих цветов, а второй (Hard) используется для кодирования новых типов блоков (Рис. 34).

Рис. 34. Формат блока PVRTC2

Бит Mode наряду с битом Hard позволяет задать четыре режима декодирования, два из которых появились в PVRTC2 (Табл. 10).

Бит «Hard»	Бит «Mode»	Режим декодирования
0	0	Обычный с интерполяцией
0	1	Punch-through alpha
1	0	Без интерполяции
1	1	Локальная палитра

Табл. 10. Режимы декодирования PVRTC2 4bpp

При значении бита Hard равному «0» используются старые режимы декодирования PVRTC, но с небольшими изменениями в плане обработки альфа-канала. Во-первых, в режиме «punch-through alpha» цветовые каналы для прозрачных пикселей сбрасываются в нулевое значение, что соответствует цвету умноженному на значение альфа-канала (premultiplied alpha). Такой подход обладает преимуществами при фильтрации и смешивании изображений (см. Формат блока BC2 (DXT2/DXT3)). Во-вторых, изменилась процедура преобразования альфа-канала в 8-битный формат. Теперь значения альфа-канала для изображений A и B преобразуются по-разному, что отражено в листинге 5, где AlphaA3, AlphaB3 – 3-битовое представление альфа-канала в сжатом блоке, а AlphaA8, AlphaB8 – результирующие 8-битное значение. Любопытно, что AlphaB8 не может принимать значение “0”, а AlphaA8 – “255”.

temp = (AlphaB3 << 1) | 1;
AlphaB8 = (temp << 4) | temp;

temp = (AlphaA3 << 1) | 0;
AlphaA8 = (temp << 4) | temp;

Листинг 5. Преобразование альфа-канала
в 8-битное представление в формате PVRTC2

Новые режимы с битом Hard равным “1” призваны упростить создание текстурных атласов и улучшить сжатие некоторых “сложных” для PVRTC участков. В режиме “Без интерполяции” увеличение изображений A и B производится без интерполяции. Вместо этого все тексели соответствующего блока 4x4 имеют одинаковый цвет. Последующий этап распаковки не отличается от PVRTC – участки изображений A и B смешиваются в пропорциях, задаваемых сигналом модуляции. Следует отметить, что действие флага Hard, хранящегося в сжатом блоке распространяется не на те тексели, которые хранятся в сжатом блоке, а на тексели смещённые вниз и вправо (Рис. 35). Для граничных блоков действие флага Hard распространяется циклически на тексели с противоположного края текстуры.

Рис. 35. Зона воздействия флага Hard

Пример декодирования в подобном режиме приведён на Рис. 36. Такой режим является аналогом S3TC компрессии. Действительно, если все соседние блоки имеют флаги Hard=1 Mode=0, то декомпрессия сжатого блока PVRTC2 будет независимой от соседей, и практически совпадать с распаковкой блока BC1. Таким образом, данный режим может использоваться для сохранения границ отдельных элементов текстурных атласов.

Рис. 36. Пример декодирования PVRTC2
в режиме без интерполяции (Hard=1 Mode=0)

В режиме локальной палитры (Hard=1 Mode=1) смешиваний цветов не происходит. Пары цветов A и B из соседних блоков просто объединяются в локальную палитру, а конкретный цвет определяется индексом (сигналом модуляции). Всего внутри зоны действия флага Hard доступно 8 цветов – по 4 элемента изображений A и B. Но размер индекса (2 бита) позволяет выбрать только один из четырёх цветов. Поэтому для любого конкретного текселя доступно только 4 из 8 окружающих его базовых цветов. Доступные для выбора цвета для каждого текселя приведены на Рис. 37.

Здесь изображены четыре блока PVRTC2 необходимые для распаковки. Блок P задаёт режим декодирования для текселей, закрашенных серым цветом. Базовые цвета изображений A и B, хранящихся в сжатых блоках обозначены как Pa, Pb, Qa, Qb, Ra, Rb, Sa, Sb. Они и составляют локальную палитру распаковываемой области. На увеличенном участке для каждого текселя подписаны доступные для выбора цвета. Исключение составляет только самый верхний левый тексель P* – для него цвета формируются, путём смешивания Pa и Pb.

Рис. 37. Доступные цвета локальной палитры.
(Источник: US Patent 8526726 (46))

Формат ASTC

ASTC (Adaptive Scalable Texture Compression) был совместно разработан компаниями ARM и AMD и в окончательном варианте представлен в 2012 году (56). Спецификация формата (57) была одобрена консорциумом Khronos для включения в OpenGL. Соответствующее расширение для OpenGL и OpenGL ES называется KHR_texture_compression_astc_hdr (58). Аппаратная поддержка данного формата имеется у графических ядер ARM начиная с моделей Mali-T628 и Mali-T678 (59). Патенты на используемые в ASTC подходы к сжатию принадлежат компании ARM (60) (61) (62) (63). Тем не менее, ASTC является полностью открытым и свободным от лицензионных отчислений форматом.

В зависимости от вида текстуры, к схеме сжатия предъявляются очень различающиеся требования:

•Возможность хранить от 1 до 4 цветовых каналов. Конечно, одно- или двухканальные текстуры можно хранить и в PVRTC2, и в ETC2, и в BC7, но в таком случае большая часть данных внутри сжатого блока будет расходоваться зря.

•Хорошее качество при слабой корреляции некоторых цветовых каналов. Актуально для карт нормалей и, как правило, для альфа-канала в RGBA изображениях.

•Поддержка стандартного (LDR) или широкого (HDR) динамического диапазона. Сжатие HDR-текстур поддерживает только BC6H, но без возможности хранения альфа-канала.

•Кроссплатформенность. Например, PVRTC доступен только на платформе iOS, BC6H/BC7 отсутствует в мобильных устройствах, а ETC не поддерживается на GPU для настольных ПК. Это доставляет большие неудобства разработчикам кроссплатформенных приложений.

•Возможность гибко варьировать соотношение уровня сжатия и качества. В зависимости от вида для текстуры допустим различный уровень ошибок сжатия, а конкретные изображения по-разному поддаются сжатию, некоторые лучше, некоторые хуже. Рассмотренные ранее форматы предоставляют не более двух вариантов (BC1/BC7 или PVRTC 4bpp/2bpp). То есть мы не можем воспользоваться уровнем сжатия 5bpp, если 8bpp избыточен, а 4bpp недостаточен. Необходимая полоса пропускания увеличивается в 2 раза без значительного улучшения качества.

•Поддержка 2D или 3D текстур.

Новая схема сжатия разрабатывалась с оглядкой на все эти требования. Формат ASTC имеет фиксированный размер сжатого блока равный 128 битам. Но размер кодируемого участка текстуры варьируется от 4х4 до 12х12 текселей для двумерных текстур, и от 3х3х3 до 6х6х6 для трёхмерных, что и обеспечивает широкие возможности выбора соотношения качества и уровня сжатия (Табл. 11).

№	2D текстуры			3D текстуры
№	Размер блока	Уровень сжатия	Инкремент	Размер блока	Уровень сжатия	Инкремент
1	4x4	8.00 bpp	125%	3x3x3	4.74 bpp	133%
2	5x4	6.40 bpp	125%	4x3x3	3.56 bpp	133%
3	5x5	5.12 bpp	120%	4x4x3	2.67 bpp	134%
4	6x5	4.27 bpp	120%	4x4x4	2.00 bpp	125%
5	6x6	3.56 bpp	114%	5x4x4	1.60 bpp	125%
6	8x5	3.20 bpp	120%	5x5x4	1.28 bpp	125%
7	8x6	2.67 bpp	105%	5x5x5	1.02 bpp	120%
8	10x5	2.56 bpp	120%	6x5x5	0.85 bpp	120%
9	10x6	2.13 bpp	107%	6x6x5	0.71 bpp	120%
10	8x8	2.00 bpp	125%	6x6x6	0.59 bpp	-
11	10x8	1.60 bpp	125%
12	10x10	1.28 bpp	120%
13	12x10	1.07 bpp	120%
14	12x12	0.89 bpp	-

Табл. 11. Возможные размеры блока и уровни сжатия ASTC

При этом ASTC является самым гибким форматом и поддерживает LDR, HDR, 2D и 3D текстуры, от 1 до 4 каналов. Необычным является поддержка режимов с уровнем сжатия менее 1bpp.

Сам метод сжатия похож на используемый в S3TC/BC7: в сжатом блоке хранятся до четырёх пар базовых цветов и коэффициенты интерполяции, то есть информация о том, в какой пропорции смешивать эти цвета для каждого текселя. Принадлежность каждого текселя к одной из пар базовых цветов определяется номером предопределённого разбиения блока на регионы. В случае слабой корреляции одного канала с остальными, для него сохраняется отдельная таблица с коэффициентами интерполяции. Любой набор цветовых каналов, для которых сохраняется отдельная таблица коэффициентов, называется срезом.

Пожалуй, основным и самым интересным нововведением ASTC является метод кодирования целых чисел с использованием дробного количества бит. И в то же время этот подход может быть эффективно реализован в аппаратуре.

Метод кодирования BISE

Метод BISE (Bounded Integer Sequence Encoding) позволяет эффективно закодировать последовательность целых чисел в диапазоне от 0 до N-1, где N не является степенью двойки (с учётом того, что любое значение от 0 до N-1 равновероятно) (64) (56).

Для примера возьмём последовательность из 5 чисел, которые могут принимать значения 0, 1 или 2. При стандартном подходе необходимо выделить по 2 бита на число, итого – 10 бит. Однако всего существует 3⁵=243 различных последовательности, что очень близко 2⁸=256. То есть всю последовательность целиком можно закодировать при помощи 8 бит и отдельное значение будет занимать 1.6 бита. По аналогии с битом, отдельный троичный символ, принято называть тритом. Таким образом, 5 трит могут быть представлены при помощи 8 бит.

Перейдём к кодированию произвольного количества значений в диапазоне от 0 до N-1, где N=3*2ⁿ. Отдельное такое значение может быть представлено в виде одного трита и n бит. К примеру, если N=12, то любое число представимо в виде , где t – трит, а b₀, b₁ – биты. Всю последовательность можно разбить на группы из 5 значений, последнюю группу можно при необходимости дополнить нулями. В двоичном виде отдельную группу можно представить в виде битовой строкой , где t_i – двухбитное представление трита, а B_i – оставшиеся младшие биты отдельного значения. Попросту говоря, два старших бита каждого числа обозначили, как t_i.

Теперь закодируем эти триты в виде 8-битного числа T, по возможности оставив на своих местах битовую и тритовую “информацию”. Получим битовую строку , где T_[_i_:_j_] – отдельные биты числа T. Такая строка на 2 бита меньше исходной. Но это не самое главное. Оказывается, такая последовательность обладает свойством сохранения лидирующих нулей. Допустим, последняя группа в нашей последовательности была дополнена двумя нулями, то есть и равны нулю. Это означает, что и тоже будут равны нулю, и их можно не сохранять. Таким образом, последовательность из любого количества элементов (от 0 до 3*2ⁿ-1) можно закодировать с расходом памяти, близким к теоретическому минимуму. В то же время, декодирование отдельного значения не требует чтения всей строки и относительно эффективно в аппаратном исполнении.

Аналогичные рассуждения можно повторить с тройками чисел от 0 до N-1, где N=5*2ⁿ, введя понятие квинт, как пятеричная цифра. Три квинта (5³=125) могут быть закодированы при помощи 7 бит (2⁷=128). Использование тритов и квинтов при кодировании последовательностей позволяет сильно снизить потери относительно обычного двоичного кодирования (Рис. 38).

Рис. 38. Сравнение потерь при двоичном кодировании и BISE.
(Источник: ASTC intro at CGDC2013 (65))

При помощи BISE в блоке ASTC кодируются базовые цвета и коэффициенты интерполяции. Дополнительным бонусом при кодировании таким способом являются удобные для реализации знаменатели у коэффициентов интерполяции. При использовании одного трита имеем три {0, ½, 1} возможных значения коэффициента, и пять {0, ¼, ½, ¾, 1} при использовании одного квинта. Кроме этого BISE позволяет очень плавно варьировать точность представления базовых цветов. Варианты, где компоненты базовых цветов хранятся с использованием тритов или квинтов представлены в Табл. 12.

Диапазон	Количество используемых символов			Размер в битах
Диапазон	Трит	Квинт	Бит	Эффективный	Теор. мин.
0..5	1		1	~ 2.60	2.58
0..9		1	1	~ 3.33	3.32
0..11	1		2	~ 3.60	3.58
0..19		1	2	~ 4.33	4.32
0..23	1		3	~ 4.60	4.58
0..39		1	3	~ 5.33	5.32
0..47	1		4	~ 5.60	5.58
0..79		1	4	~ 6.33	6.32
0..95	1		5	~ 6.60	6.58
0..159		1	5	~ 7.33	7.32
0..191	1		6	~ 7.60	7.58

Табл. 12. Варианты кодирования значений цветовых каналов

После BISE-декодирования значения цветовых компонент деквантуются до стандартного диапазона [0, 255].

Прочие особенности

Среди прочих нововведений можно отметить реализацию разбиения сжимаемых блоков на регионы. В форматах BC6H/BC7 для этого использовалась предопределённая таблица (Рис. 13). Ввиду большого разнообразия размеров блоков, количества регионов и доступных номеров разделения на регионы (под номер разделения в ASTC отводится 10 бит против 6 в BC7) такая таблица имела бы просто огромные размеры. Вместо этого, разделение генерируется специальной хэш-функцией. На вход она принимает номер разделения, размер блока, координаты текселя внутри блока, а на выходе выдаёт номер региона данного текселя. Хэш-функция достаточно проста для реализации в железе. Эта же функция вычисляет номер региона при использовании 3D-текстур. Все варианты разделений на регионы для блока размером 8х8 приведены на Рис. 39.

Рис. 39. Варианты разделения блока 8х8 на регионы.
(Источник: ARM Mail Graphics blogs (66))

Ещё одна значимая особенность ASTC – это способ представления коэффициентов интерполяции. В семействе S3TC они представлялись индексами – по одному 2-, 3- или 4-битному индексу на каждый тексель. Однако размера блока (128 бит) не хватит для хранения даже однобитовых индексов в случае блока 12х12. В ASTC было предложено использовать независимый растр для текселей и для коэффициентов интерполяции. К примеру, для блока 12х12 текселей может быть сохранено только 4х6 коэффициентов интерполяции. При распаковке, если растры не совпадают, то эффективное значение коэффициента интерполяции получается путём билинейной фильтрации (сетка коэффициентов интерполяции увеличивается до размеров блока). Но это совсем не аналогично простому масштабированию блока, как может показаться. К примеру, для блоков с плавными градиентами вполне может быть достаточно сетки коэффициентов интерполяции 2х2. В то же время в таком блоке могут присутствовать и резкие границы за счёт использования нескольких регионов. При этом количество доступных внутри блока оттенков для одной пары базовых цветов никак не ограничивается размером индекса. Для каждого сжимаемого блока можно выбрать своё количество коэффициентов интерполяции. Например, в блоках с вертикальными линиями можно использовать сетки коэффициентов 4х2 или 8х4.

Всю эту информацию о конфигурации отдельного блока (размер сетки коэффициентов, количество регионов, формат представления базовых цветов и пр.) необходимо как-то хранить внутри сжатого блока, что потенциально отнимает биты от базовых цветов и коэффициентов интерполяции. Но именно эта высочайшая гибкость обеспечивает отличное качество сжатия. Потому что для каждого блока можно найти именно тот баланс распределения доступных битов по различным полям, который обеспечивает минимальную ошибку сжатия. При одинаковом и даже большем уровне сжатия, формат ASTC обеспечивает лучшее качество, чем PVRTC, ETC и BC1-BC5. Превосходство составляет в среднем 1.5 – 2 dB PSNR, в то время как 0.25 dB является видимым и ощутимым для среднего наблюдателя. BC6H и BC7 сравнимы по качеству c ASTC. BC7 в среднем превосходит ASTC на 0.5dB, но при достигаемом качестве в районе 45dB, эту разницу довольно сложно заметить (56).

ASTC – это первый стандартный формат для сжатия 3D-текстур, использующий корреляцию между цветами по всем трём направлениям. Расширение VTC от nVidia (26) тоже нацелено на 3D-текстуры, но оно предполагает независимую упаковку отдельных слоёв участка 4х4х1 – 4х4х4 в обычные блоки BC1. В ASTC используется трёхмерная сетка коэффициентов интерполяции и разделение на регионы всего сжимаемого блока. Это возможно как раз, за счёт использования хэш-функции для генерации номера региона. Правда масштабирование сетки коэффициентов интерполяции осуществляется не трилинейной фильтрацией, а симплекс фильтрацией (67). Эксперименты показывают, что при одинаковом уровне сжатия, сжатие трёхмерного участка вместо послойного сжатия даёт улучшение качества около 2 dB (68).

Кроме этого, все возможности ASTC являются “ортогональными” в том смысле, что могут использоваться независимо друг от друга. То есть вполне можно сжимать 3D-текстуру с двумя независимыми HDR каналами.

Формат блока ASTC

Для каждой конкретной текстуры ряд глобальных параметров, влияющих на распаковку является постоянным и его не имеет смысла хранить в сжатом блоке. Это такие параметры как:

•Тип текстуры LDR/HDR

•Количество измерений 2D/3D

•Размер блока

•Тип возвращаемого значения sRGB/RGB

Остальные параметры так или иначе закодированы в блоке, и могут отличаться в разных блоках одной текстуры:

•Размер сетки коэффициентов интерполяции

•Диапазон значений коэффициентов интерполяции (для BISE-декодирования)

•Коэффициенты интерполяции

•Количество регионов

•Номер разделения на регионы

•Формат базовых цветов

•Базовые цвета

•Количество срезов (1 или 2)

•Распределение каналов по срезам

Текстура может быть закодирована как 1-,2-,3- или 4-канальное изображение, но на выходе декодера всегда получается RGBA изображение. В случае LDR sRGB режима значения каналов на выходе представляются 8-битным целым числом, во всех остальных случаях в формате FP16. Формат блока ASTC представлен на Рис. 40.

Рис. 40. Формат блока ASTC

Все поля кроме BlockMode и Part имеют переменный размер.

В Part хранится число (p-1), где p – количество регионов. В случае двух срезов, кол-во регионов должно быть от 1 до 3. Поле BlockMode полностью определяет количество и диапазон значений для коэффициентов интерполяции. Так же в BlockMode хранится информация о количестве срезов. ConfigData и MoreConfigData определяют формат хранения базовых цветов.

Для 2D блоков в BlockMode выделяется 5 полей – A, B, R, D, H (Табл. 13). Отдельный код отведён для режима Void-extent, в котором весь блок является одноцветным. Кроме самого цвета, в таком блоке может содержаться информация о количестве соседних блоков с таким же цветом. Кэш-система может использовать эту информацию, чтобы даже не читая сжатые блоки из памяти, сразу вернуть цвет соседних текселей.

Табл. 13. Формат поля BlockMode для 2D блоков.
(Источник: ASTC Specification (57))

Поля A и B определяют ширину (N) и высоту (M) сетки коэффициентов интерполяции, D (double) – говорит о наличии второго среза, а R (range) и H (high precision) задают диапазон значений для коэффициентов интерполяции (Табл. 14). Биты R₁ и R₂ не могут быть одновременно равны 0, иначе нельзя будет однозначно декодировать блок.

H	R	Диапазон	Количество используемых для кодирования символов
H	R	Диапазон	Трит	Квинт	Бит
0	000	Неисп.
0	001	Неисп.
0	010	0..1			1
0	011	0..2	1
0	100	0..3			2
0	101	0..4		1
0	110	0..5	1		1
0	111	0..7			3
1	000	Неисп.
1	001	Неисп.
1	010	0..9		1	1
1	011	0..11	1		2
1	100	0..15			4
1	101	0..19		1	2
1	110	0..23	1		3
1	111	0..31			5

Табл. 14. Кодирование диапазона для коэффициентов интерполяции

Поля ConfigData и MoreConfigData определяют формат хранения базовых цветов. Каждая пара может иметь свой формат. Всего определено 16 таких форматов: 10 для LDR и 6 для HDR цветов. В HDR-текстурах в сжатом блоке цвета могут быть представлены любым из этих форматов. Цвета в паре закодированы одним из следующих методов:

•Независимые значения равной битовой длины k.

•Base+offset. (Аналог блока ETC-differential). Первое значение в паре представлено с большей точностью (k+1), а для восстановления второго используется смещение длинной (k-1) бит.

•Base+scale. Два RGB значения представляются при помощи четырёх чисел (R, G, B, s). Первый цвет равен (R, G, B), а второй – (sR, sG, sB).

Для целей данной статьи нет необходимости углубляться в детали формата. Эту информация можно получить из оригинальной статьи (56) и спецификации на формат ASTC (57).

Упрощённо декодирование блока ASTC осуществляется следующим образом. Сначала по полю BlockMode выясняется количество и диапазон квантованных коэффициентов интерполяции. Коэффициенты считываются с хвоста блока при помощи BISE-декодирования. Коэффициенты деквантуются до диапазона 0..64. В случае, если количество коэффициентов меньше количества текселей в блоке, используется билинейная фильтрация для масштабирования сетки коэффициентов до размеров блока текселей.

Далее по значению поля Part определяется количество регионов и номер разделения считывается из сжатого блока. При помощи хэш-функции генерируется номер региона для каждого текселя.

По полям ConfigData и MoreConfigData и количеству регионов определяется формат представления всех базовых цветов и определяется общее количество скалярных значений, которые необходимо прочитать. Однако диапазон этих значений не указывается в сжатом блоке. Но зная количество бит, занимаемых коэффициентами интерполяции и конфигурационной информации можно подсчитать, сколько бит доступно в блоке для хранения базовых цветов. А зная количество элементов в BISE последовательности можно определить максимальный диапазон, с которым они могут поместиться в это количество бит. Информация для восстановления базовых цветов всегда сохраняется с использованием максимального возможного диапазона. Далее базовые цвета распаковываются при помощи BISE-декодирования и деквантуются.

По номеру региона узнаётся необходимая пара базовых цветов для каждого текселя, и значения этих цветов смешиваются в пропорции задаваемой коэффициентом интерполяции.

Краткая характеристика рассмотренных форматов сжатия текстур

Формат	Размер блока	Размер сжимаемого участка	Уровень сжатия	Качество	Сжимаемые цветовые компоненты Описание
BC1 (S3TC, DXT1)	64 bit	4x4	4bpp	Medium	RGB или RGB + 1-bit Alpha. Базовая схема сжатия S3TC. Сложности со сжатием многоцветных блоков и градиентов. Базовые цвета хранятся в формате RGB565.
BC2 (DXT2, DXT3)	128 bit	4x4	8bpp	Medium	RGBA BC1 + альфа-канал без сжатия с точностью 4 бита
BC3 (DXT4, DXT5)	128 bit	4x4	8bpp	Medium	RGBA BC1 + BC4 для хранения альфа-канала
BC4 (ATI1, 3Dc+)	64 bit	4x4	4bpp	Medium+	R Вариация S3TC для сжатия одного канала. Базовые цвета хранятся с точностью 8 бит.
BC5, (ATI2, 3Dc)	128 bit	4x4	8bpp	Medium+	RG Сжатие двухкомпонентных текстур с использованием двух блоков BC4. Используется в случае слабой корреляции каналов, например, для карт нормалей.
BC6H	128 bit	4x4	8bpp	Very high	RGB (в формате с плавающей запятой FP16) Модификация BC7 для сжатия HDR текстур. Точность базовых цветов от 6 до 16 бит.
BC7	128 bit	4x4	8bpp	Very high	RGB, RGBA Подход основан на S3TC, но добавлена поддержка разделения блока на регионы и широкий выбор формата хранения базовых цветов. Высококачественная замена форматов BC1-BC5. Точность базовых цветов от (4+1) до (7+1) бит.
PACKMAN	32 bit	2x4	4bpp	Med/low	RGB Подход основан на использовании таблицы модификации яркости. Сложности со сжатием многоцветных блоков. Базовые цвета хранятся в формате RGB444.
ETC, (iPACKMAN)	64 bit	4x4	4bpp	Medium+	RGB Объединение двух блоков PACKMAN в единый блок с добавлением нового режима differential.
ETC2	64 bit	4x4	4bpp	High	RGB или RGB + 1-bit Alpha Дальнейшее развитие формата ETC с добавлением трёх новых режимов. Поддерживает градиенты, но не подходит для карт нормалей.
EAC	64 bit	4x4	4bpp	High	R Адаптация подхода ETC для сжатия одного канала. Аналог блока BC4.
2x EAC	128 bit	4x4	8bpp	High	RG Два блока EAC. Аналог BC5.
ETC2+EAC	128 bit	4x4	8bpp	High	RGBA ETC2 + EAC блок. Аналог блока BC3.
PVRTC	64 bit	4x4, 8x4 (не блочное сжатие)	4bpp, 2bpp	Medium+, Low	RGBA, RGB или RGB + 1-bit Alpha Схема сжатия без разделения на независимые блоки. Поддерживает градиенты, но имеются проблемы с текстурными атласами.
PVRTC2	64 bit	4x4, 8x4 (не блочное сжатие)	4bpp, 2bpp	High, Med/low	RGBA, RGB или RGB + 1-bit Alpha Дальнейшее развитие PVRTC с двумя новыми типами блоков. Улучшено качество и добавлена поддержка текстурных атласов.
ASTC	128 bit	4x4 to 12x12 3x3x3 to 6x6x6	0.89 – 8 bpp 0.59 – 4.74 bpp	Любое от low до very high	R, RG, RGB, RGBA in both 8-bit and FP16 formats Наиболее гибкий во всех отношениях формат. Поддерживает LDR, HDR и 3D текстуры. Принцип сжатия схож с BC7, но используются BISE-кодирование, гибкая структура блока и прочие улучшения.

Табл. 15. Краткая характеристика рассмотренных форматов сжатия текстур (неактуальные форматы помечены тёмным фоном).

Выбор конкретного формата сжатия ограничивается используемой аппаратной платформой. Так, на ПК доступно только семейство S3TC, а в мобильных устройствах – ETC или PVRTC, в зависимости от платформы (также встречается поддержка форматов BC1-BC5, но их использование не сильно распространенно). Поддержка формата ASTC имеется пока только у некоторых мобильных процессоров.

В рамках семейства S3TC:

•BC7 предоставляет наилучшее качество для RGB и RGBA текстур и заменяет собой форматы BC2 и BC3

•BC1 можно использовать при отсутствии необходимости в высоком качестве для RGB текстур

•BC4 и BC5 применяются для одно- и двухканальных текстур

•BC6H позволяет сжимать HDR-текстуры

PVRTC2 полностью замещает собой формат PVRTC, улучшая качество сжатия и решая некоторые проблемы своего предшественника. PVRTC2 поддерживает RGB и RGBA текстуры.

ETC2 является результатом развития форматов ETC и PACKMAN и также полностью замещает их. ETC2 поддерживает только RGB текстуры, но различные комбинации блоков ETC2 и EAC предоставляют функционал, полностью аналогичный набору форматов BC1-BC5.

Формат ASTC поддерживает сжатие любых типов текстур и предоставляет различные варианты уровней сжатия.

Заключение

Сжатие текстур является неотъемлемой частью современной компьютерной графики. Уже сейчас многие смартфоны обладают разрешением FullHD (1920x1080), а в сегменте настольных компьютеров и рабочих станций началась гонка за сверхвысокие разрешения класса 4K и 8K (3840x2160 и 7680x4320), что значительно повышает нагрузку на шину памяти графического процессора. Можно ожидать, что среднее разрешение текстур также будет расти.

Таким образом, увеличение коэффициента сжатия является острым вопросом. При этом в различных случаях допустим различный уровень ошибок сжатия. Поэтому для наиболее эффективного использования шины памяти, формат сжатия должен предоставлять выбор соотношения уровня сжатия и качества. На сегодняшний день этому требованию в полной мере отвечает только формат ASTC. Его поддержка пока отсутствует в графических процессорах, используемых в ПК. Но мы считаем, что с её появлением, ASTC сможет заменить собой все рассмотренные форматы, так как он позволяет сжимать любые типы текстур, а при равном уровне сжатия незначительно уступает по качеству только формату BC7. Это также упростит создание кроссплатформенных приложений, потому что разработчики смогут ориентироваться на единый формат, поддерживаемый всеми платформами.

Дальнейшее развитие форматов сжатия текстур может быть связано как с эволюцией существующих подходов и их расширением на блоки большего размера, так и с применением схем с переменным уровнем сжатия. Последний вариант позволил бы затрачивать большее количество бит только для тех участков текстур, где это необходимо.

Работа выполнена при технической поддержке компании AMD (Advanced Micro Devices, Inc.), а также при государственной финансовой поддержке ведущих университетов Российской Федерации (субсидия 074-U01). Авторы также благодарят Владимира Кибардина за помощь в написании английской версии статьи.

Список литературы

1.McDonald John. Eliminating Texture Waste: Borderless Ptex. 2013. GDC2013.

2.Inada T. and McCool M. D. Compressed lossless texture representation and caching. New York, NY, USA : ACM, 2006. Proceedings of the 21st ACM SIGGRAPH/EUROGRAPHICS symposium on Graphics hardware. pp. 111-120.

3.Strom Jacob and Akenine-Moller Tomas. PACKMAN: Texture Compression for Mobile Phones. . New York, NY, USA : ACM, 2004. ACM SIGGRAPH 2004 Sketches.

4.van Waveren, J.M.P. id Tech 5 Challenges: From Texture Virtualization to Massive Parallelization. Siggraph. Part of Beyond programmable shading course. 2009.

5.Olano M., et al., et al. Variable Bit Rate GPU Texture Decompression. 2011. Computer Graphics Forum, vol. 30, pp. 1299–1308.

6.Strom Jacob and Wennersten Per. Lossless Compression of Already Compressed Textures. Strom Jacob and Wennersten Per. s.l.: Eurographics Association. High Performance Graphics, 2011, pp. 177-182.

7.Воробьев Андрей. 3DGiТоги июль 2001 года — Влияние технологии S3TC (FXT1) на качество и скорость. 2001. Available at: http://www.ixbt.com/video/0701i-video-s3tc1.html

8.WesleyandSmith Ian N., Liska Milos and Holub Petr. Implementation of DXT Compression for UltraGrid. Implementation of DXT Compression for UltraGrid. s.l. : CESNET, 2008.

9.Petr Holub, et al., et al. GPU-accelerated DXT and JPEG compression schemes for low-latency network transmissions of HD, 2K, and 4K video. Future Generation Computer Systems, vol. 29, № 8, 2013, pp. 1991-2006.

10.van Waveren, J.M.P. Real-Time DXT Compression. Id Software. 2006. Tech. rep.

11.FastDXT. URL: http://www.evl.uic.edu/cavern/fastdxt/

12.Fast CPU DXT Compression. 2012. URL: http://software.intel.com/en-us/vcsource/samples/dxt-compression

13.Перминов Илья. Повышение эффективности обработки динамически сжимаемых текстур. Научно-технический вестник информационных технологий, механики и оптики, т. 6 (88), 2013 г, стр. 164-165.

14.Fenney Simon. Texture compression using low-frequency signal modulation. Eurographics Association, 2003. Graphics Hardware. pp. 84-91.

15.Rover Camera Instrument Description. URL: http://pdsimg.jpl.nasa.gov/data/mpfr-m-rvrcam-2-edr-v1.0/mprv_0001/document/rcinst.htm

16.Iourcha Konstantine I., Hong Zhou and Nayak Krishna S. System and method for fixed-rate block-based image compression with inferred pixel values. US Patent 5,956,431 US, 1999.

17.EXT_texture_compression_dxt1 extension specification. 2008. URL: http://www.opengl.org/registry/specs/EXT/texture_compression_dxt1.txt

18.EXT_texture_compression_s3tc extension specification. 2013. URL: http://www.opengl.org/registry/specs/EXT/texture_compression_s3tc.txt

19.EXT_texture_compression_rgtc extension specification. 2008. URL: http://www.opengl.org/registry/specs/EXT/texture_compression_rgtc.txt

20.ARB_texture_compression_rgtc extension specification. 2009. URL: http://www.opengl.org/registry/specs/ARB/texture_compression_rgtc.txt

21.EXT_texture_compression_latc extension specification. [Online] 2009. URL: http://www.opengl.org/registry/specs/EXT/texture_compression_latc.txt

22.ARB_texture_compression_bptc extension specification. [Online] 2011. URL: http://www.opengl.org/registry/specs/ARB/texture_compression_bptc.txt

23.Castano Ignacio. GPU DXT Decompression. 2009. URL: http://www.ludicon.com/castano/blog/2009/03/gpu-dxt-decompression/

24.van Waveren, J.M.P. and Castano, Ignacio. Real-Time Normal Map DXT Compression. Real-Time Normal Map DXT Compression. 2008.

25.Brown Simon. DXT Compression Techniques. 2006. URL: http://www.sjbrown.co.uk/2006/01/19/dxt-compression-techniques/

26.NV_texture_compression_vtc extension specification. 2004. URL: http://www.opengl.org/registry/specs/NV/texture_compression_vtc.txt

27.Block Compression (Direct3D 10). URL: http://msdn.microsoft.com/en-us/library/windows/desktop/bb694531

28.Blinn James F. Jim Blinn's Corner: Compositing, Part 1: Theory. IEEE-CGA, Vol. 14, 1994, pp. 83-87.

29.3Dc™ White Paper. URL: http://www.hardwaresecrets.com/datasheets/3Dc_White_Paper.pdf

30.Texture Block Compression in Direct3D 11. URL: http://msdn.microsoft.com/en-us/library/windows/desktop/hh308955

31.The OpenGL Graphics System: A Specification Version 4.2 (Core Profile). The OpenGL Graphics System: A Specification Version 4.2 (Core Profile). 2012.

32.Sovremennaya terminologiya 3D grafiki [Modern terminology 3D graphics]. URL: http://www.ixbt.com/video2/terms2k5.shtml#hdr

33.OES_compressed_ETC1_RGB8_texture extension specification. 2008. URL: http://www.khronos.org/registry/gles/extensions/OES/OES_compressed_ETC1_RGB8_texture.txt

34.WEBGL_compressed_texture_etc1 Extension Draft Specification. 2013. URL: http://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_etc1/

35.The OpenGL Graphics System: A Specification Version 4.3 (Core Profile). The OpenGL Graphics System: A Specification Version 4.3 (Core Profile). 2013.

36.Strom Jacob and Akenine-Moller Tomas. iPACKMAN: High-quality, Low-complexity Texture Compression for Mobile Phones. New York, NY, USA : ACM, 2005. Proceedings of the ACM SIGGRAPH/EUROGRAPHICS Conference on Graphics Hardware. pp. 63-70.

37.Strom Jacob and Pettersson Martin. ETC2: Texture Compression Using Invalid Combinations. Aire-la-Ville, Switzerland : Eurographics Association, 2007. Proceedings of the 22Nd ACM SIGGRAPH/EUROGRAPHICS Symposium on Graphics Hardware. pp. 49-54.

38.Strom Jacob and Akenine-Moller Tomas. Multi-mode alpha image processing. US Patent 7,693,337 US, 2010.

39.Multi-mode image processing. US Patent 7,734,105 US, 2010.

40.Multi-mode image processing. US Patent 7,751,630 US, 2010.

41.Pettersson Martin and Strom Jacob. Texture compression based on two hues with modified brightness. US Patent 8,144,981 US, 2012.

42.The OpenGL Graphics System: A Specification Version 4.4 (Core Profile). The OpenGL Graphics System: A Specification Version 4.4 (Core Profile). 2013.

43.Fenney Simon. Method and apparatus for compressing data and decompressing compressed data. US Patent 7,236,649 US, 2007.

44.Method and apparatus for compressing data and decompressing compressed data. US Patent 7,242,811 US, 2007.

45.Method and apparatus for compressing data and decompressing compressed data. US Patent 8,204,324 US, 2012.

46.Method and apparatus for compressing data and decompressing compressed data. US Patent 8,526,726 US, 2013.

47.IMG_texture_compression_pvrtc extension specification. 2012. URL: http://www.khronos.org/registry/gles/extensions/IMG/IMG_texture_compression_pvrtc.txt

48.IMG_texture_compression_pvrtc2 extension specification. 2012. URL: http://www.khronos.org/registry/gles/extensions/IMG/IMG_texture_compression_pvrtc2.txt

49.EXT_pvrtc_sRGB extension specification. 2013. URL: http://www.khronos.org/registry/gles/extensions/EXT/EXT_pvrtc_sRGB.txt

50.WEBGL_compressed_texture_pvrtc Extension Draft Specification. 2013. URL: http://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_pvrtc/

51.Voica Alexandru. PVRTC: the most efficient texture compression standard for the mobile graphics world. [Online] January 2013. URL: http://withimagination.imgtec.com/index.php/powervr/pvrtc-the-most-efficient-texture-compression-standard-for-the-mobile-graphics-world

52.Taking texture compression to a new dimension with PVRTC2. January 2013. URL: http://withimagination.imgtec.com/index.php/powervr/pvrtc2-taking-texture-compression-to-a-new-dimension

53.Beets Kristof. Understanding PowerVR Series5XT: PVRTC, PVRTC2 and texture compression. June 2013. URL: http://withimagination.imgtec.com/index.php/powervr/understanding-powervr-series5xt-pvrtc-pvrtc2-and-texture-compression-part-6

54.Geldreich Rich. PVRTC Compression - First Experiments. URL: https://sites.google.com/site/richgel99/early-pvrtc-compression-experiments

55.PVRTC Compression - First Coded 4bpp. PVR Texture. URL: https://sites.google.com/site/richgel99/pvrtc-compression2

56.Nystad, Jorn, et al., et al., Adaptive Scalable Texture Compression. Eurographics Association. High Performance Graphics, 2012, pp. 105-114.

57.Ellis Sean and Nystad Jorn. ASTC Specification. 2012.

58.KHR_texture_compression_astc_hdr extension specification. 2013. URL: http://www.opengl.org/registry/specs/KHR/texture_compression_astc_hdr.txt

59.ARM Launches Second Generation of MALI-T600 Graphics Processors Driving Improved User Experience for Tablets, Smartphones and Smart-TVs. 2012. URL: http://www.arm.com/about/newsroom/arm-launches-second-generation-of-mali-t600-graphics-processors-driving-improved-user-experience.php

60.Lassen Jorn and Nystad Anders. Method of and apparatus for encoding and decoding data. UK Patent Application 2491689 GB, 2012.

61.Method of and apparatus for encoding and decoding data. UK Patent Application 2491448 GB, 2012.

62.Method of and apparatus for encoding and decoding data. UK Patent Application 2491687 GB, 2012.

63.Method of and apparatus for encoding and decoding data. UK Patent Application 2491688 GB, 2012.

64.Nystad Jorn Lassen, Anders and Olson, Tomas. Flexible Texture Compression Using Bounded Integer Sequence Encoding. New York, NY, USA : ACM, 2011. SIGGRAPH Asia 2011 Sketches. pp. 32:1--32:2.

65.Ellis Sean. ARM ASTC Texture Compression. CGDC (China Game Developers Conference), 2013.

66.Smith Stacy. ASTC does it. 2013. URL: http://community.arm.com/groups/arm-mali-graphics/blog/2013/10/22/astc-does-it

67.Gustavson Stefan. Simplex noise demystified. 2005. URL: http://www.itn.liu.se/~stegu/simplexnoise/simplexnoise.pdf

68.Ellis Sean. More ASTC in ARM Mali GPUs – High Dynamic Range and 3D. 2013. URL: http://malideveloper.arm.com/engage-with-mali/more-astc-in-arm-mali-gpus-high-dynamic-range-and-3d/

TEXTURE COMPRESSION TECHNIQUES

T. Paltashev¹, I. Perminov²

¹ Advanced Micro Devices, Sunnyvale, CA, United States of America

² University ITMO, St. Petersburg, Russian Federation

Timour.Paltashev@gmail.com, timour.paltashev@amd.com, i.am.perminov@gmail.com

Abstract

In this paper, we present a detailed analysis and comparison of texture compression techniques and their hardware implementations used in modern PCs, tablets and smartphones, based on their characteristics, such as compression rates and image quality. First, we review the family of the earliest massively used compression schemes, the S3TC (BC1-BC3). Then, we move on to BC4, BC5, BC6H and BC7 formats, which improved the image quality by providing more flexibility as well as introducing block partitioning. We also analyze the mobile targeted ETC family (PACKMAN, ETC1 (iPACKMAN) and ETC2/EAC), developed by Ericsson, and the PVRTC family of formats, created by Imagination Technologies. Finally, we present ASTC, the latest texture compression technology resulted from a collaboration of AMD and ARM. BISE encoding and other features of ASTC are described in details.

Key words: computer graphics, texture compression, texture decompression, S3TC, DXT, BCn, BC6H, BC7, ETC, ETC2, EAC, PVRTC, PVRTC2, ASTC.

References

1.McDonald John. Eliminating Texture Waste: Borderless Ptex. 2013. GDC2013.

3.Strom Jacob and Akenine-Moller Tomas. PACKMAN: Texture Compression for Mobile Phones. . New York, NY, USA : ACM, 2004. ACM SIGGRAPH 2004 Sketches.

4.van Waveren, J.M.P. id Tech 5 Challenges: From Texture Virtualization to Massive Parallelization. Siggraph. Part of Beyond programmable shading course. 2009.

5.Olano M., et al., et al. Variable Bit Rate GPU Texture Decompression. 2011. Computer Graphics Forum, vol. 30, pp. 1299–1308.

6.Strom Jacob and Wennersten Per. Lossless Compression of Already Compressed Textures. Strom Jacob and Wennersten Per. s.l.: Eurographics Association. High Performance Graphics, 2011, pp. 177-182.

7.Vorobev Andrey. 3DGiTogi iyul 2001 goda — Vliyanie tekhnologii S3TC (FXT1) na kachestvo i skorost [3DGiTogi ]uly 2001 - impact of technology S3TC (FXT1) on quality and speed]. 2001. Available at: http://www.ixbt.com/video/0701i-video-s3tc1.html

8.WesleyandSmith Ian N., Liska Milos and Holub Petr. Implementation of DXT Compression for UltraGrid. Implementation of DXT Compression for UltraGrid. s.l. : CESNET, 2008.

10.van Waveren, J.M.P. Real-Time DXT Compression. Id Software. 2006. Tech. rep.

11.FastDXT. Available at: http://www.evl.uic.edu/cavern/fastdxt/

12.Fast CPU DXT Compression. 2012. Available at: http://software.intel.com/en-us/vcsource/samples/dxt-compression

13.Ilya Perminov. Povyshenie effektivnosti obrabotki dinamicheski szhimaemykh tekstur [Improvement of Dynamic Texture Compression]. Nauchno-tekhnicheskiy vestnik informatsionnykh tekhnologiy, mekhaniki i optiki [Scientific and Technical Journal of Information Technologies, Mechanics and Optics], vol. 6 (88), 2013 г., стр. 164-165.

14.Fenney Simon. Texture compression using low-frequency signal modulation. Eurographics Association, 2003. Graphics Hardware. pp. 84-91.

15.Rover Camera Instrument Description. Available at: http://pdsimg.jpl.nasa.gov/data/mpfr-m-rvrcam-2-edr-v1.0/mprv_0001/document/rcinst.htm

16.Iourcha Konstantine I., Hong Zhou and Nayak Krishna S. System and method for fixed-rate block-based image compression with inferred pixel values. US Patent 5,956,431 US, 1999.

17.EXT_texture_compression_dxt1 extension specification. 2008. Available at: http://www.opengl.org/registry/specs/EXT/texture_compression_dxt1.txt

18.EXT_texture_compression_s3tc extension specification. 2013. Available at: http://www.opengl.org/registry/specs/EXT/texture_compression_s3tc.txt

19.EXT_texture_compression_rgtc extension specification. 2008. Available at: http://www.opengl.org/registry/specs/EXT/texture_compression_rgtc.txt

20.ARB_texture_compression_rgtc extension specification. 2009. Available at: http://www.opengl.org/registry/specs/ARB/texture_compression_rgtc.txt

21.EXT_texture_compression_latc extension specification. [Online] 2009. Available at: http://www.opengl.org/registry/specs/EXT/texture_compression_latc.txt

22.ARB_texture_compression_bptc extension specification. [Online] 2011. Available at: http://www.opengl.org/registry/specs/ARB/texture_compression_bptc.txt

23.Castano Ignacio. GPU DXT Decompression. 2009. Available at: http://www.ludicon.com/castano/blog/2009/03/gpu-dxt-decompression/

24.van Waveren, J.M.P. and Castano, Ignacio. Real-Time Normal Map DXT Compression. Real-Time Normal Map DXT Compression. 2008.

25.Brown Simon. DXT Compression Techniques. 2006. Available at: http://www.sjbrown.co.uk/2006/01/19/dxt-compression-techniques/

26.NV_texture_compression_vtc extension specification. 2004. Available at: http://www.opengl.org/registry/specs/NV/texture_compression_vtc.txt

27.Block Compression (Direct3D 10). Available at: http://msdn.microsoft.com/en-us/library/windows/desktop/bb694531

28.Blinn James F. Jim Blinn's Corner: Compositing, Part 1: Theory. IEEE-CGA, Vol. 14, 1994, pp. 83-87.

29.3Dc™ White Paper. Available at: http://www.hardwaresecrets.com/datasheets/3Dc_White_Paper.pdf

30.Texture Block Compression in Direct3D 11. Available at: http://msdn.microsoft.com/en-us/library/windows/desktop/hh308955

31.The OpenGL Graphics System: A Specification Version 4.2 (Core Profile). The OpenGL Graphics System: A Specification Version 4.2 (Core Profile). 2012.

32.Sovremennaya terminologiya 3D grafiki [Modern terminology 3D graphics]. Available at: http://www.ixbt.com/video2/terms2k5.shtml#hdr

33.OES_compressed_ETC1_RGB8_texture extension specification. 2008. Available at: http://www.khronos.org/registry/gles/extensions/OES/OES_compressed_ETC1_RGB8_texture.txt

34.WEBGL_compressed_texture_etc1 Extension Draft Specification. 2013. Available at: http://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_etc1/