Технологии сжатия текстур реферат

Обновлено: 04.07.2024

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

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

Что такое "нормальное сжатие" - такие вещи, как JPEG и PNG? Вы спрашиваете о различиях между этими форматами и поддерживаемыми аппаратными средствами, такими как DXT и ASTC?

(Наконец-то тема, о которой я немного знаю!) В отличие от PNG / JPEG, это произвольный доступ. Если вы хотите получить доступ к Texel (XY), вы можете быстро определить небольшой объем данных, необходимых для создания этого texel. JPG или PNG может потребовать распаковки до всех данных! Разделы 1 и 2 статьи Википедии - хорошее резюме.

Как написал SimonF. Это чрезвычайно широкий вопрос, и ответ зависит от того, какой тип вас интересует. Вы смотрели спецификацию, например, для DXT?

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

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

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

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

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

@ Натан-Рид. Из того, что я видел, все HW-декодеры могут быть реализованы с чистым логическим путем (битовое декодирование, некоторый поиск, некоторая математика в пути данных), но без необходимости в цикле / регистре. Вам известна какая-либо схема, которая добавляет задержку цикла к поиску текстуры? (Я для забавы реализовал декодер VHDL ETC1) У меня сложилось впечатление, что в каждый блок текстуры (TU) встроены декодеры.

Требования

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

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

Асимметричное кодирование / декодирование : хотя, возможно, немного более спорным, они утверждают, что приемлемо иметь процесс кодирования намного медленнее, чем декодирование. Учитывая, что декодирование должно осуществляться с частотой заполнения 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 с большими векторами (например, 2bpp ARGB)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Global + Local

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

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

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

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

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

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

Другие схемы

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

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

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

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

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

Выполнил:
ст.гр. МПр-31 ФМФ
Блинов Д.А.
Проверил:
Шутов А.В.

Владимир 2011 г.

Оглавление
Введение 3
1. Кодирование данных 51.1. Способ представления информации в ПК 5
1.2. Идея кодирования со сжатием 6
2. Сжатие с потерями качества 8
2.1. Алгоритмы и способы компрессии мультимедийных данных 8
2.2. MPEG-4 10
2.3. DivX 14
2.4. MPEG Layer 3 15
3. Алгоритмы архивации без потери качества 20
3.1. Алгоритм Хаффмана 20
3.2. Арифметическое кодирование 26
3.3. Алгоритм Лемпеля – Зива - Велча (Lempel-Ziv-Welch)28
3.4. Двухступенчатое кодирование. Алгоритм Лемпеля-Зива 29
Заключение 30
Список использованной литературы 31

Введение
Насколько актуальна идея архивации и насколько применимы алгоритмы архивации в контексте сегодняшних реалий? А реалии говорят сами за себя: объемы жестких дисков (да и оперативной памяти) у рядовых пользователей сейчас насколько велики, что многие просто непредставляют: как использовать весь потенциал таких больших хранилищ данных. Стоит ли в таких условиях задумываться о сути архиваторов и следует ли вообще их использовать?
Есть целый ряд причин, по которым многие все еще не перестают пользоваться архиваторами. Перечислю некоторые из них:
* при передаче файлов по почте или с помощью терминальных программ критичным является каждый килобайт, да и, кроме того, припересылке большого числа файлов (особенно со сложной структурой каталогов) проще в письмо вложить всего один файл - архив;

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

* пишущий DVD-ROM стал стандартом для ПК среднего класса, многие из нас сталкиваются с проблемой, когда на компакт диск необходимо перенести очень сложную структуру каталогов, тогда как файловая система компакт-диска не допускает более чем восьмикратный уровень вложенности папок. Это было бы очень серьезной проблемой, еслибы не архиваторы, позволяющие упаковывать всю структуру в один файл (для таких целей некоторые архиваторы содержат метод сжатия "Без сжатия");

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

Из выше сказанного можно сделать важный вывод: архивация сейчасиспользуется для увеличения скорости передачи при ограниченной пропускной способности, что не уменьшает значимость алгоритмов сжатия, скорее наоборот. Приведу примеры, демонстрирующие эту общую тенденцию:
* протоколы модемной связи используют простейшие алгоритмы сжатия (вроде замены одинаковых подцепочек байтов "aaaaaabbbbbbbb" на "6a8b") для увеличения скорости передачи файлов при неизменной пропускнойспособности самого канала связи.

* всем известно, что игры - наиболее ресурсоемкие программные продукты. Особенно 3D-игры. Современные видеокарты на борту содержат от 32 до 2048 мегабайт, что обусловлено большим объемом передаваемых по шине текстур и z-буфера. Компания S3 предложила инновационную технологию сжатия текстур (сейчас эта технология используется несколькими производителямивидеочипов). Суть идеи состоит в том, что, при одних и тех же частоте работы и объеме видеопамяти, можно достичь гораздо более высокой производительности, ведь текстуры сжимаются довольно эффективно, а, следовательно, увеличивается скорость их передачи и доступная память используется более эффективно.
Заинтересовавшись идеей реализации архиватора, я провел небольшое.

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

Чтобы решить эту проблему, мы используем технологию сжатия текстур. Использование этой технологии может значительно сократить использование APP памяти (совместно используемой видеопамяти), что позволяет использовать более богатые материалы при ограниченных ограничениях памяти.

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

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

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

3.1 DXT

Коэффициент сжатия: DXT1, DXT4, DXT5 - 4: 1, DXT2, DXT3 - 2: 1.

Android-телефон, который в основном поддерживает платформу Windows и графический процессор серии Tegra

3.2 ETC

Этот ряд можно назвать наиболее широко используемым форматом.

ETC1 поддерживает практически все устройства Android на рынке, все iPhone

ETC2 поддерживает большинство современных Android-машин, iPhone 5S и выше

3.3 PVRTC

Сжатие текстур PowerVR. Различие между форматом PVRTC и форматами сжатия на основе блоков, такими как S3TC и ETC, заключается в том, что в нем используются две билинейно масштабированные карты низкого разрешения, которые объединяются друг с другом в зависимости от точности и веса каждого пикселя. Визуализирует текстуры, а 2-bpp и 4-bpp поддерживают данные ARGB. Формат PVRTC имеет относительно высокую степень сжатия, а также с потерями.

Эта серия является наиболее широко поддерживаемым форматом для iPhone

Поддерживает только текстуры с равной длиной и мощностью до степени 2.

Поддерживает некоторые устройства Android (GPU: серия PowerVR), модели iPhone полной серии

Поддерживаемый графический процессор

3.4 ASTC

ASTC (Adaptive Scalable Texture Compression), который был предложен ARM, был одобрен организацией Khronos в прошлом году и был включен в стандарт, но это не обязательно

Есть несколько методов сжатия на выбор, с различными степенями сжатия

Эта серия может быть названа серией с наилучшими характеристиками и простотой использования.

Поддержка некоторых моделей Android высокого класса, iPhone6 и выше

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

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

4.1 Основные преимущества

Значительное сокращение использования памяти (видеопамять)

Никаких дополнительных накладных расходов на производительность

Прост в использовании, требует лишь небольшого количества кода

4.2 Основные недостатки

Аппаратное обеспечение, рассмотрим совместимость

Размер файла сжатой текстуры больше, чем у обычных файлов PNG и JPG

Требуются дополнительные производственные инструменты и не могут быть созданы непосредственно на мобильном телефоне

5.1 Сохранить формат

Сжатая текстура - это метод кодирования данных изображения, нам все еще не хватает контейнера для его переноса. Так же, как файл MP4 является контейнером для видео H264.

Мы выбрали формат, используя KTX.

KTX - это формат хранения текстур, разработанный для программ OpenGL и OpenGLES. Это может легко идентифицировать формат текстуры и другую связанную информацию, сохраненную в нем.

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

Предварительные сведения о работе с текстурами и о форматах их хранения

Первый танк – это полигональная модель, а второй – та же модель, на которую наложены текстуры.

Такое изображение используется в случаях, когда текстурированный объект виден с большого расстояния, или когда его размеры уменьшены. Идея использования MIP-карт строится на том факте, что мы попросту не можем различить мелкие детали объекта, который находится далеко от нас или имеет маленькие размеры. Основываясь на этой идее, различные фрагменты карты можно использовать для представления различных частей текстуры, основываясь на размерах объекта. Это увеличивает скорость рендеринга за счёт того, что уменьшенные варианты основной текстуры имеют намного меньше текселей (пикселей текстуры), то есть GPU приходится обрабатывать меньше данных для вывода текстурированной модели. Кроме того, так как MIP-карты обычно подвергаются сглаживанию, серьёзно уменьшается количество заметных артефактов. Здесь мы рассмотрим MIP-карты в форматах PNG, ETC (KTX), ETC2 (KTX), PVRTC, и S3TC.

Portable Network Graphics (PNG)

PNG – это растровый формат хранения изображения, особенно заметный тем, что в нём используется алгоритм сжатия графических данных без потерь информации. Он поддерживает цветные индексированные изображения (24 бита RGB или 32 бита RGBA), полноцветные и полутоновые изображения, а так же – альфа-канал.

Преимущества

Недостатки

Файлы имеют большие размеры. Это увеличивает размер приложений и потребление памяти.
Сравнительно высокая потребность в вычислительных ресурсах (что ведет к ухудшению производительности).

Ericsson Texture Compression (ETC)

Ericsson Texture Compression – это формат сжатия текстур, который оперирует блоками пикселей размером 4x4. Изначально Khronos использовал ETC как стандартный формат для Open GL ES 2.0. (эта версия ещё называется ETC1). В результате этот формат доступен практически на всех Android-устройствах. С выходом OpenGL ES 3.0. в качестве нового стандарта использован формат ETC2 – переработанная версия ETC1. Основное различие между этими двумя стандартами заключается в алгоритме, который оперирует пиксельными группами. Улучшения в алгоритме привели к более высокой точности вывода мелких деталей изображений. Как результат, качество изображений улучшилось, а размер файлов – нет.

ETC1 и ETC2 поддерживают сжатие 24-битных RGB-данных, но они не поддерживают сжатие изображений с альфа-каналом. Кроме того, есть два разных формата файлов, относящихся к алгоритму ETC: это KTX и PKM.

KTX – это стандартный формат файла Khronos Group, он предоставляет контейнер, в котором можно хранить множество изображений. Когда MIP-карта создаётся с использованием KTX, генерируется единственный KTX-файл. Формат PKM-файла гораздо проще, такие файлы, в основном, используют для хранения отдельных изображений. Как результат, при использовании PKM в ходе создания MIP-карты получатся несколько PKM-файлов вместо единственного KTX. Поэтому для хранения MIP-карт использовать формат PKM не рекомендуется.

Преимущества

Размер ETC-файлов, заметно меньше чем размер PNG-файлов.
Формат поддерживает аппаратное ускорение практически на всех Android-устройствах.

Недостатки

Качество не так высоко, как у PNG (ETC – это формат сжатия изображений с потерями информации).
Нет поддержки прозрачности.

PowerVR Texture Compression (PVRTC)

PowerVR Texture Compression – это формат компрессии графических данных с потерями, с фиксированным уровнем сжатия, который используется, преимущественно, в устройствах Imagination Technology PowerVR MBX, SGX и Rogue. Он применяется в качестве стандартного метода сжатия изображений в iPhone, iPod, iPad.

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

Преимущества

Поддержка альфа-каналов.
Поддержка RGBA для варианта 2-bpp (2 бита на пиксель) и для варианта 4-bpp (4 бита на пиксель).
Размер файлов намного меньше, чем у PNG.
Поддержка аппаратного ускорения на GPU PoverVR.

Недостатки

Качество не так высоко, как при использовании PNG (PVRTC – это формат сжатия изображений с потерями).
PVRTC поддерживается только на аппаратном обеспечении PoverVR.
Обеспечивается поддержка квадратных POT-текстур, то есть текстур, ширина и высота которых являются степенью числа 2, хотя в некоторых случаях имеется поддержка прямоугольных текстур.

Сжатие текстур в этот формат может быть медленным.

S3 Texture Compression (S3TC) или DirectX Texture Compression (DXTC)

S3 Texture Compression – это формат сжатия графических данных с потерями, с фиксированным уровнем сжатия. Его особенности делают этот формат идеальным для сжатия текстур, используемых в 3D-приложениях, рассчитанных на использование графического ускорителя. Интеграция S3TC с Microsoft DirectX 6.0 и OpenGL 1.3 способствовала его широкому распространению. Существует как минимум 5 различных вариантов формата S3TC (от DXT1 до DXT5). Приложение-пример поддерживает чаще всего используемые варианты (DXT1, DXT3 и DXT5).

DXT1 обеспечивает наиболее сильное сжатие. Каждый входной 16-пиксельный блок конвертируется в 64-битный блок, состоящий из двух 16-битных RGB 5:6:5 цветовых значений и 2-х битной таблицы подстановок размером 4x4. Поддержка прозрачности ограничена одним цветом (1-битная прозрачность).

DXT3 конвертирует каждый блок из 16 пикселей в 128 бит, 64 бита приходятся на данные альфа-канала, 64 – на цветовую информацию. DXT3 очень хорошо подходит для изображений или текстур с резкими переходами между прозрачными и непрозрачными областями. Однако если градаций прозрачности нет, а прозрачные участки в изображении имеются, стоит рассмотреть использование DXT1.

DXT5, как и DXT3, конвертирует каждый блок из 16 пикселей в 128 бит, 64 бита приходятся на данные альфа-канала, 64 – на цветовую информацию. Однако, в отличие от DXT3, DXT5 подходит для изображений или текстур с плавными переходами между прозрачными и непрозрачными областями.

Преимущества

Размер файла значительно меньше аналогичного PNG-файла.
Достойное качество, низкий процент артефактов в виде полосок, связанных с наложением цветов.
Хорошая скорость кодирования и декодирования.
Аппаратное ускорение на множестве GPU. На настольных системах поддерживается практически всеми решениями, постепенно распространяется и на платформе Android.

Недостатки

Качество ниже, чем у PNG (S3TC – это формат сжатия изображений с потерями информации).
Поддерживается не на всех Android-устройствах.

Доступ к данным текстур

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

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

Обратите внимание

Заголовок PVRTC упакован с учётом наличия члена данных 64-битного пиксельного формата (mPixelFormat в примере). В коде, скомпилированном для ARM, проводится выравнивание заголовка с добавлением к нему 4 дополнительных байтов, в итоге он, из исходного 52-байтового, становится 56-байтовым. Это приводит к тому, что при выводе на ARM-устройствах изображение искажается. В коде, скомпилированном для процессоров от Intel, подобного не происходит. Упаковка заголовка решает проблему с выравниванием на ARM-устройствах, в итоге текстура отображается правильно как на ARM-устройствах, так и на Intel-устройствах.

Вот как выглядит искажение изображения на ARM-устройстве, вызванное выравниванием заголовка

О приложении-примере

Пример Android Texture Compression, фрагменты которого будут приведены ниже, позволяет всем желающим быстро сравнивать качество текстур пяти форматов. А именно, это Portable Network Graphics (PNG), Ericsson Texture Compression (ETC), Ericsson Texture Compression 2 (ETC2), PowerVR Texture Compression (PVRTC), и S3 Texture Compression (S3TC), который иногда называют DirectX Texture Compression (DXTC).

В примере показано, как загружать и использовать текстуры этих форматов с помощью OpenGL ES в Android. Изображения, хранящиеся в разных форматах, располагаются рядом друг с другом, что позволяет сравнить их размер и качество. Выбор наиболее подходящего под конкретный проект формата хранения сжатых текстур позволяет разработчику найти верный баланс между размером приложения, визуальным качеством картинки и производительностью.

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

Рассматриваемый здесь пример основан на коде, который создал Уильям Гуо (William Guo). Кристиано Феррейра (Christiano Ferreira), специалист по графическим приложениям Intel, дополнил его примером использования сжатия текстур ETC2. Загрузить код можно здесь.

Форматы сжатия текстур: размеры и качество

Загрузка PNG

С MIP-картами в формате PNG можно работать с помощью простой функции glGenerateMipmap из Khronos OpenGL, которая была создана специально для этой цели. Мы, для чтения и загрузки PNG-файлов, воспользовались кодом, подготовленным Шоном Барретом (Sean Barret), stb_image.c, который находится в открытом доступе. Так же этот код используется для нахождения и выборки участка текстуры, который нужно обработать.

Загрузка ETC / ETC2

Как было упомянуто выше, ETC-текстуры могут храниться в файлах формата KTX и PKM. KTX – это стандартный формат сжатия, используемый как контейнер для нескольких изображений, он идеально подходит для создания MIP-карт. В свою очередь, PKM создан для хранения отдельных сжатых изображений, поэтому создание на его основе MIP-карт приводит к необходимости генерировать множество файлов, а это неэффективно. Поддержка MIP-карт для ETC в примере ограничена форматом KTX.

Khronos предоставляет библиотеку с открытым кодом, написанную на C (libktx), в которой поддерживается загрузка MIP-карт из KTX-файлов. Мы этой библиотекой воспользовались и реализовали код в функции LoadTextureETC_KTX, ответственной за загрузку текстур. Функция, которая непосредственно загружает KTX-файлы, называется ktxLoadTextureM. Она позволяет загружать нужную текстуру из данных в памяти. Эта функция – часть библиотеки libktx, документацию по ней можно найти на сайте Khronos.

Вот фрагмент кода, который инициализирует текстуру и предоставляет поддержку MIP-карт для формата ETC (KTX).

Загрузка PVRTC

Поддержка MIP-карт для PVRTC-текстур – задачка чуть посложнее. После чтения заголовка определяется смещение, которое равняется сумме размеров заголовка и метаданных. Метаданные идут следом за заголовком, они не являются частью изображения. Для каждого сгенерированного уровня карты пиксели группируются в блоки (различия зависят от того, применяется ли кодировка 4 бита на пиксель или 2 бита – и тот и другой варианты подходят для PVRTC). Далее, происходит поиск границ, фиксируется ширина и высота блоков. Затем вызывается функция glCompressedTexImage(), она идентифицирует двумерное изображение в сжатом формате PVRTC. Далее, вычисляется размер пиксельных данных и то, что получилось, добавляется к ранее найденному смещению для того, чтобы сгруппировать набор пикселей для следующего фрагмента карты. Этот процесс повторяется до тех пор, пока не будут обработаны все текстуры, из которых состоит карта.

Загрузка S3TC

После загрузки файла, хранящего S3TC-текстуры, определяется его формат и выполняется чтение MIP-карты, расположенной за заголовком. Производится обход фрагмента карты, пиксели группируются в блоки. Затем, для идентификации двумерного изображения в сжатых данных, вызывается функция glCompressedTexImage(). Общий размер блока затем добавляется к смещению для того, чтобы можно было найти начало следующего фрагмента карты и выполнить те же действия. Это повторяется до тех пор, пока не будут обработаны все уровни карты. Вот фрагмент кода, который инициализирует текстуру и предоставляет поддержку MIP-карт для формата S3TC.

Выводы

В зависимости от конкретной ситуации, выбор наиболее подходящего формата хранения сжатых текстур может улучшить внешний вид изображений, серьёзно уменьшить размер приложения и значительно повысить производительность. Тщательный подбор оптимального метода сжатия текстур способен дать разработчикам и их приложениям серьёзные конкурентные преимущества. В приложении-примере Android Texture Compression показано, как работать с текстурами наиболее популярных в Android-среде форматов. Загружайте код и добавляйте в свои проекты поддержку наиболее подходящих для них форматов сжатия текстур.

Читайте также: