Как работает аппаратное сжатие текстур?

То, что он сжимает данные по сравнению с массивом пикселей, очевидно.

Но что отличает его от обычного сжатия (например, png, jpeg)?

Как отмечалось в комментарии Саймона, одно существенное различие между аппаратным сжатием текстур и другим обычно используемым сжатием изображений заключается в том, что в первом не используется энтропийное кодирование. Энтропийное кодирование - это использование более коротких битовых строк для представления часто встречающихся или повторяющихся шаблонов в исходных данных - как это видно в таких форматах контейнеров, как ZIP, во многих распространенных форматах изображений, таких как GIF, JPEG и PNG, а также во многих распространенных аудио и видео форматы.

Энтропийное кодирование хорошо сжимает все виды данных, но само по себе создает переменную степень сжатия. Некоторые области изображения могут иметь мало деталей (или детали хорошо предсказываются используемой моделью кодирования) и требуют очень мало битов, но другие области могут иметь сложные детали, которые требуют большего количества битов для кодирования. Это затрудняет реализацию произвольного доступа, поскольку не существует простого способа вычислить, где в сжатых данных вы можете найти пиксель при заданном ( x ,  y) координаты. Кроме того, большинство схем энтропийного кодирования являются сохраняющими состояние, поэтому невозможно просто начать декодирование в произвольном месте в потоке; Вы должны начать с самого начала, чтобы создать правильное состояние. Однако для выборки текстуры необходим произвольный доступ, поскольку шейдер может в любой момент выполнить выборку из любой точки текстуры.

Таким образом, вместо энтропийного кодирования в аппаратном сжатии используются схемы с фиксированным соотношением блоков. Например, при сжатии DXT / BCn текстура разделяется на блоки 4 × 4 пикселя, каждый из которых кодируется в 64 или 128 битах (в зависимости от выбранного формата); в ASTC разные форматы используют размеры блоков от 4 × 4 до 12 × 12, и все блоки кодируются в 128 битах. Детали того, как биты представляют данные изображения, различаются в разных форматах (и могут даже варьироваться от одного блока к другому в пределах одного и того же изображения), но, поскольку соотношение фиксировано, аппаратному обеспечению легко вычислить, где в памяти найти блок содержащий данный ( x , y ) пиксель, и каждый блок является автономным, поэтому он может быть декодирован независимо от любых других блоков.

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

Напротив, основанные на DCT форматы, такие как JPEG, требуют нетривиального количества математики на пиксель, не говоря уже о сложном потоке данных, который меняет местами и передает различные промежуточные значения по пикселям в блоке. (Посмотрите в этой статье некоторые подробности о декодировании DCT.) Это было бы гораздо сложнее для аппаратной реализации, и я предполагаю, почему AFAICT, ни одно из графических процессоров никогда не реализовывало DCT или вейвлет-сжатие текстур ,

«Как (аппаратное) сжатие текстур работает» - большая тема. Надеюсь, я смогу дать некоторые идеи, не дублируя содержание ответа Натана .

Требования

Сжатие текстур обычно отличается от «стандартных» методов сжатия изображений, например, JPEG / PNG, четырьмя основными способами, как обрисовано в общих чертах в Beers et al., Rendering from Compressed Textures :

1. Скорость декодирования : Вы не хотите, чтобы сжатие текстур было медленнее (по крайней мере, заметно), чем использование несжатых текстур. Распаковка также должна быть относительно простой, поскольку это может помочь добиться быстрой распаковки без чрезмерных затрат на оборудование и электроэнергию.

2. Произвольный доступ : вы не можете легко предсказать, какие тексели потребуются во время данного рендера. Если какое-то подмножество M обращенных текселей происходит, скажем, из середины изображения, важно, чтобы вам не нужно было декодировать все «предыдущие» строки текстуры, чтобы определить M ; в JPEG и PNG это необходимо, поскольку декодирование пикселей зависит от ранее декодированных данных.
   Обратите внимание, что, сказав это, только потому, что у вас есть «случайный» доступ, не означает, что вы должны пытаться выполнить произвольную выборку полностью

3. Степень сжатия и визуальное качество : Бирс и др. Утверждают (убедительно), что потеря качества сжатого результата с целью улучшения степени сжатия является достойным компромиссом. При 3D-рендеринге данные, вероятно, будут обрабатываться (например, фильтроваться, затемняться и т. Д.), Поэтому некоторая потеря качества может быть замаскирована.

4. Асимметричное кодирование / декодирование : хотя, возможно, немного более спорным, они утверждают, что приемлемо иметь процесс кодирования намного медленнее, чем декодирование. Учитывая, что декодирование должно осуществляться с частотой заполнения HW, это обычно приемлемо. (Я признаю, что сжатие PVRTC, ETC2 и некоторых других при максимальном качестве может быть быстрее)

Ранняя история и техника

Некоторых может удивить, что сжатие текстур существует уже более трех десятилетий. Имитаторам полета 70-х и 80-х годов требовался доступ к относительно большим объемам текстурных данных, и, учитывая, что 1 МБ ОЗУ в 1980 г. составлял> 6000 долл. США , сокращение текстурного пространства было крайне необходимо. В качестве другого примера, в середине 70-х даже небольшое количество высокоскоростной памяти и логики, например, достаточно для скромного кадрового буфера 512x512 RGB, может вернуть вам цену небольшого дома.

Тем не менее, AFAIK, явно не упоминаемый как сжатие текстур, в литературе и патентах вы можете найти ссылки на методы, включая:
a. простые формы математического / процедурного синтеза текстур,
б. использование одноканальной текстуры (например, 4bpp), которая затем умножается на значение RGB для текстуры,
c. YUV и
д. палитры (литература, предлагающая использовать подход Гекберта для сжатия)

Моделирование данных изображения

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

Кроме того, поскольку сжатие текстур имеет тенденцию использовать кодирование с фиксированной скоростью, процесс сжатия обычно включает в себя этап поиска, чтобы найти набор параметров, которые при подаче в модель будут генерировать хорошее приближение исходной текстуры. Этот шаг поиска, однако, может занять много времени.
(За возможным исключением таких инструментов, как optipng , это еще одна область, где типичное использование PNG и JPEG отличается от схем сжатия текстур)

Прежде чем продолжить, чтобы помочь в дальнейшем понимании TC, стоит взглянуть на анализ основных компонентов (PCA) - очень полезный математический инструмент для сжатия данных.

Пример текстуры

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

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

ПК и (после середины 90-х) консольное сжатие текстур

Чтобы сократить расходы на передачу данных, некоторые компьютерные игры и игровые приставки ранних версий также использовали изображения палитр, которые являются формой векторного квантования (VQ). Подходы на основе палитры предполагают, что данное изображение использует только относительно небольшие части цветового куба RGB (A). Проблема с текстурами палитры заключается в том, что степень сжатия для достижения качества обычно довольно скромна. Пример текстуры, сжатой до «4bpp» (с использованием GIMP), снова показал, что это довольно жесткое изображение для схем VQ.

VQ с большими векторами (например, 2bpp ARGB)

Вдохновленные Beers и соавторами, консоль Dreamcast использовала VQ для кодирования блоков размером 2x2 или даже 2x4 пикселей одним байтом. В то время как «векторы» в текстурах палитры являются 3 или 4-мерными, блоки пикселей 2 × 2 можно считать 16-мерными. Схема сжатия предполагает, что имеется достаточное приблизительное повторение этих векторов.

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

Пример изображения сжимают со схемой 2bpp Dreamcast это . Карта индекса:

Сжатие данных VQ может быть выполнено различными способами, однако, IIRC , вышеупомянутое было сделано с использованием PCA, чтобы получить и затем разделить 16D-векторы вдоль главного вектора на 2 набора так, чтобы два репрезентативных вектора минимизировали среднеквадратичную ошибку. Затем процесс повторялся до 256 векторов-кандидатов. Глобальный метод k-средних / алгоритма Ллойда был применен для улучшения представителей.

Преобразования цветового пространства

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

3dfx Voodoo система при условии «ЯБ» , 8bpp, «Ограниченный канал» система сжатия, разделить каждый 8 битный текселей в формате 322, и применять выбранный пользователем преобразование цветов к тому , что данные для отображения его в RGB. Таким образом, главная ось имела 8 уровней и меньшие оси, по 4 каждая.

Чип S3 Virge имел слегка более простую схему 4bpp, которая позволяла пользователю указать для всей текстуры два конечных цвета, которые должны лежать на главной оси, наряду с монохромной текстурой 4bpp. Затем значение на пиксель смешивает конечные цвета с соответствующими весами для получения результата RGB.

Схемы на основе BTC

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

В этой схеме изображения разбиты, как правило, на блоки 4 × 4 пикселя, которые могут быть сжаты независимо с помощью, по сути, алгоритма локализованного VQ. Каждый блок представлен двумя «значениями», a и b , и набором индексных битов 4x4, которые определяют, какое из двух значений использовать для каждого пикселя.

S3TC : 4bpp RGB (+ 1bit альфа)
Хотя некоторые цвета , варианты BTC для сжатия изображений были предложены, для нас интереса представляет Iourcha и коллега S3TC , некоторые из которых , как представляется, повторное открытие нескольких забытого Hoffert и др , что был использован в QuickTime Apple.

Оригинальный S3TC, без вариантов DirectX, сжимает блоки RGB или RGB + 1-битный Alpha до 4bpp. Каждый блок 4x4 в текстуре заменяется двумя конечными цветами, A и B , из которых до двух других цветов получаются линейными смешиваниями с фиксированным весом. Кроме того, каждый тексель в блоке имеет 2-битный индекс, который определяет, как выбрать один из этих четырех цветов.

Например, ниже приведен фрагмент 4х4 пикселя тестового изображения, сжатого с помощью инструмента AMD / ATI Compressenator. ( Технически это взято из 512x512 версии тестового изображения, но простите, что я не успел обновить примеры ). Это иллюстрирует процесс сжатия: рассчитывается среднее значение и главная ось цветов. Затем выполняется наилучшая подгонка, чтобы найти две конечные точки, которые «лежат» на оси, которая, наряду с двумя полученными смешениями 1: 2 и 2: 1 (или в некоторых случаях смесью 50:50) этих конечных точек, которые минимизирует ошибку. Каждый оригинальный пиксель затем сопоставляется с одним из этих цветов для получения результата.

Если, как и в этом случае, цвета разумно аппроксимируются главной осью, ошибка будет относительно низкой. Однако если, как и в соседнем блоке 4x4, показанном ниже, цвета более разнообразны, ошибка будет выше.

Образ изображения, сжатый с помощью AMD Compressonator, создает:

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

ETC1 : сжатие текстур RGB
Ericsson 4bpp также работает с блоками текселей 4x4, но делает предположение, что, как и YUV, главная ось локального набора текселей часто очень сильно коррелирует с «яркостью». Затем набор текселей может быть представлен просто средним цветом и сильно квантованной скалярной «длиной» проекции текселей на эту предполагаемую ось.

Поскольку это снижает затраты на хранение данных, скажем, S3TC, это позволяет ETC вводить схему разделения, посредством которой блок 4x4 подразделяется на пару горизонтальных субблоков 4x2 или 2x4. У каждого из них свой средний цвет. Пример изображения дает: Область вокруг клюва также иллюстрирует горизонтальное и вертикальное разделение блоков 4x4.

Global + Local

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

PVRTC : 4 & 2 bpp RGBA
PVRTC предполагает, что (на практике, билинейно) масштабированное изображение является хорошим приближением к цели с полным разрешением и что разница между приближением и целью, то есть дельта-изображением, является локально монохроматической, т.е. имеет доминирующую главную ось. Кроме того, предполагается, что локальная главная ось может быть интерполирована по всему изображению.

(сделать: добавить изображения, показывающие разбивку)

Пример текстуры, сжатой с помощью PVRTC1 4bpp, создает: с областью вокруг клюва: по сравнению с BTC-схемами, блочные артефакты обычно устраняются, но иногда может быть «перерегулирование», если в исходном изображении имеются сильные разрывы, например, вокруг силуэт головы лорикета.

Вариант 2bpp, естественно, имеет более высокую погрешность, чем 4bpp (обратите внимание на потерю точности вокруг синих, высокочастотных областей около шеи), но, возможно, все еще достаточно хорошего качества:

Примечание о стоимости декомпрессии

Хотя алгоритмы сжатия для схем, описанных выше, имеют среднюю или высокую стоимость оценки, алгоритмы распаковки, особенно для аппаратных реализаций, относительно недороги. Например, ETC1 требует чуть больше нескольких MUX и сумматоров низкой точности; S3TC эффективно немного больше дополнительных единиц для выполнения смешивания; и PVRTC, еще немного. Теоретически, эти простые схемы TC могут позволить архитектуре графического процессора избежать распаковки вплоть до этапа фильтрации, тем самым максимизируя эффективность внутренних кэшей.

Другие схемы

Другие распространенные режимы TC, которые следует упомянуть:

• ETC2 - это (4bpp) надмножество ETC1, которое улучшает обработку областей с распределением цветов, которое не совпадает с «luma». Есть также вариант 4bpp, который поддерживает 1-битную альфа, и формат 8bpp для RGBA.

• ATC - это небольшая вариация S3TC .

• FXT1 (3dfx) был более амбициозным вариантом темы S3TC .

• BC6 и BC7: 8-битная блочная система с поддержкой ARGB. Помимо режимов HDR, они используют более сложную систему разделения, чем в ETC, чтобы попытаться лучше моделировать распределение цвета изображения.

• PVRTC2: 2 & 4bpp ARGB. Это вводит дополнительные режимы, в том числе один для преодоления ограничений с сильными границами на изображениях.

• ASTC: Это также система, основанная на блоках, но несколько более сложная в том смысле, что она имеет большое количество возможных размеров блоков, ориентированных на широкий диапазон значений bpp. Он также включает в себя такие функции, как до 4 областей разделов с генератором псевдослучайных разделов, и переменное разрешение для данных индекса и / или точности цветов и цветовых моделей.