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

13

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

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

чокнутый урод
источник
Что такое "нормальное сжатие" - такие вещи, как JPEG и PNG? Вы спрашиваете о различиях между этими форматами и поддерживаемыми аппаратными средствами, такими как DXT и ASTC?
Натан Рид
6
(Наконец-то тема, о которой я немного знаю!) В отличие от PNG / JPEG, это произвольный доступ. Если вы хотите получить доступ к Texel (XY), вы можете быстро определить небольшой объем данных, необходимых для создания этого texel. JPG или PNG может потребовать распаковки до всех данных! Разделы 1 и 2 статьи Википедии - хорошее резюме.
Саймон Ф
Как написал SimonF. Это чрезвычайно широкий вопрос, и ответ зависит от того, какой тип вас интересует. Вы смотрели спецификацию, например, для DXT?
Ималлетт

Ответы:

25

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

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

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

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

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

Натан Рид
источник
отличный ответ. Также вы можете добавить, что в некоторых статьях упоминается, что в некоторых ситуациях вы можете выполнить сжатие самостоятельно и декодировать его с помощью клиентского кода в пиксельном шейдере, а не зависеть от выделенного оборудования. я не знаю, как это можно использовать в реальном мире, это может стоить только исследований, но оно существует.
v.oddou
1
@ Nathan-Reed - сжатие на основе преобразования, собственно, в проекте Talisman от Microsofts использовалась схема сжатия TREC, которая (в качестве одного из режимов) использовала DCT, но, в отличие от JPEG, допускала произвольный доступ к блокам (я подозреваю, что должна быть таблица, содержащая адреса). Это тогда позволило бы данные переменной длины для различных блоков, но косвенность неприятна для HW - причина VQ TC вышла из моды. FWIW Я экспериментировал с дюжиной идей TC B4 PVRTC; некоторые были с фиксированной скоростью, основанные на преобразовании, но «пропущенные» коэффициенты все еще используют биты. BTC-подобные фиксированные местоположения коэффициентов подразумевают «свободную» информацию.
Саймон Ф
2
@ Натан-Рид. Из того, что я видел, все HW-декодеры могут быть реализованы с чистым логическим путем (битовое декодирование, некоторый поиск, некоторая математика в пути данных), но без необходимости в цикле / регистре. Вам известна какая-либо схема, которая добавляет задержку цикла к поиску текстуры? (Я для забавы реализовал декодер VHDL ETC1) У меня сложилось впечатление, что в каждый блок текстуры (TU) встроены декодеры.
Ромен Пекуа
31

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

Требования

Сжатие текстур обычно отличается от «стандартных» методов сжатия изображений, например, 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 это 2bpp VQ результат. Карта индекса:Индексная карта 2bpp VQ

Сжатие данных 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 областей разделов с генератором псевдослучайных разделов, и переменное разрешение для данных индекса и / или точности цветов и цветовых моделей.

Саймон Ф
источник
1
Вау, это должно быть где-то в блоге! Отличный ответ!
Гламперт
2
Рад, что это помогает. Что касается блога, я написал это десять лет назад, но у меня действительно нет времени, чтобы сделать их.
Саймон Ф
1
Веб-сайт, на котором размещен старый блог, мертв. Это последняя архивная версия: web.archive.org/web/20160322090245/http://web.onetel.net.uk/...
ahcox