image processing

Сжатие текстур, часть V. ASTC и Basis Universal

  • Дата публикации: 14.04.2025
  • /Метки: image processing, ktx
  • /Комментарии: 0

Продолжение серии постов о сжатых текстурных форматах. Предыдущие части: часть I, часть II, часть III, часть IV.

Вот мы и подошли к state of the art текстурного сжатия по состоянию на 2025 год.

ASTC

Adaptive Scalable Texture Compression

Современный формат, созданный с учетом особенностей мобильных платформ. На сегодняшний день крайне мало распространен. Программно поддерживается в Vulkan и новейших версиях OpenGL ES, но аппаратно — далеко не всеми видеокартами. В десктопном OpenGL поддержки нет и, судя по всему, не предвидится (но это не проблема — см. ниже).

В отличие от S3TC, BPTC и RGTC, формат работает с блоками от 4×4 до 12×12. Размер блока ASTC всегда составляет 16 байт, поэтому чем больше блок, тем выше степень сжатия, но ниже качество. Можно выбирать формат блока (например, 5×5, 6×6, 8×8 и т.д.) в зависимости от баланса между качеством и размером. ASTC поддерживает от 1 до 4 каналов.

ASTC поддерживает HDR и является на сегодняшний день единственным универсальным решением для сжатия HDR-текстур на мобильных GPU.

Basis Universal

Использовать ASTC напрямую непрактично, если вы хотите охватить широкий спектр платформ и конфигураций. Для этого была придумана особая система хранения сжатых текстур, которая позволяет приложениям на лету транскодировать их в формат, подходящий для каждой конкретной платформы — ASTC, BPTC, S3TC, RGTC, PVRTC и в несжатые форматы. Basis Universal охватывает как LDR, так и HDR-текстуры в рамках пяти режимов сжатия: ETC1S, UASTC LDR 4×4, UASTC HDR 4×4, UASTC HDR 6×6, UASTC HDR 6×6 intermediate.

ETC1S. Режим низкого и среднего качества, основанный на подмножестве ETC1. Поддерживает переменный баланс веса/качества (наподобие JPEG). Поддерживает альфа-канал. Этот вид текстур можно быстро транскодировать практически в любые другие сжатые форматы.

UASTC (Universal ASTC) LDR 4×4. Подмножество ASTC для стандартных LDR-текстур с 8 битами на канал. Транскодируется также очень эффективно, особенно в ASTC и BC7.

UASTC HDR 4×4. Режим для HDR-текстур, подмножество ASTC HDR 4×4 8bpp. Разработан для обеспечения высокого качества, эффективно транскодируется (с небольшими потерями) в BC6H. В ASTC HDR превращается вообще без какого-либо оверхеда и без потерь. Этот режим также можно транскодировать в различные несжатые HDR-форматы 32-64 bpp.

UASTC HDR 6×6. Режим HDR-текстур 3.56 bpp. Также на 100% эквивалентен ASTC.

UASTC HDR 6×6 Intermediate («GPU Photo»). Быстро транскодирутся в ASTC HDR 6×6, BC6H и различные несжатые HDR-форматы.

ETC1S и UASTC LDR 4×4 могут быть транскодированы в:

  • ASTC LDR 4×4 L/LA/RGB/RGBA 8bpp
  • BC1-5 RGB/RGBA/X/XY
  • BC7 RGB/RGBA
  • ETC1 RGB, ETC2 RGBA, ETC2 EAC R11/RG11
  • PVRTC1 4bpp RGB/RGBA, PVRTC2 RGB/RGBA
  • ATC RGB/RGBA, FXT1 RGB
  • Несжатые LDR-форматы.

UASTC HDR 4×4 и UASTC HDR 6×6 могут быть транскодированы в:

  • ASTC HDR 4×4 (8bpp, только UASTC HDR 4×4)
  • ASTC HDR 6×6 RGB (3.56bpp, ASTC HDR 6×6 или UASTC HDR 6×6 intermediate)
  • BC6H RGB (8bpp, UASTC HDR 4×4 или UASTC HDR 6×6)
  • Несжатые HDR-форматы.

KTX2 и суперкомпрессия

Basis Universal — это отлично, но как с ним работать и с удобством хранить? Для упрощения этой задачи Khronos Group предложили формат контейнера KTX2, развитие KTX. Если Basis Universal — это механизм сжатия, то KTX2 — чемодан, в который можно упаковать вообще все. Он поддерживает все существующие форматы сжатия, включая ASTC, UASTC, ETC1S, BC1-7, ETC, PVRTC, и сверх того позволяет сжимать текстуры при помощи lossless-алгоритмов (Zstandard, Zlib, BasisLZ). Несжатые форматы, определенные спецификацией Vulkan, также поддерживаются в полной мере. В KTX можно хранить не только 1D-, 2D- и 3D-текстуры, но и кубические карты, mip-уровни и массивы текстур.

Khronos предоставляет набор утилит KTX Software для конвертации изображений в KTX/KTX2, а также для валидации и анализа файлов. Плюс, разумеется, библиотека libktx для декодирования файлов в приложениях — она полностью берет на себя задачу по транскодированию, и на выходе вы получаете текстуру в нужном вам формате, которую остается лишь отправить в графический API.

SDL_Image и загрузчики текстур

Вслед за KTX я решил улучшить в движке ситуацию с поддержкой стандартных форматов изображений. Отныне Dagon загружает текстуры с помощью SDL_Image, если библиотека присутствует, системно или локально. В противном случае используется старый загрузчик на основе dlib.image. Преимуществом такого подхода является гарантированная под Windows поддержка огромного числа форматов, включая современные WebP и AVIF; также автоматически решается застарелая проблема с декодированием прогрессивных JPEG.

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

(далее…)

KTX в Dagon

Наконец-то реализовал давнюю идею поддержки текстур в формате KTX (Khronos Texture). Это контейнер, специально созданный для OpenGL и Vulkan и поддерживающий большое количество форматов текстур, включая сжатые. Особенно интересен KTX2, который позволяет хранить текстуры в формате Basis Universal — он хорош тем, что позволяет при создании игровых ресурсов не волноваться, что сжатие не будет поддерживаться на системах каких-то пользователей. Формат сжатия выбирается движком игры на основе информации от видеодрайвера, а затем текстура на лету транскодируется в этот формат. Эта фича нужна главным образом на мобильных платформах, но и в десктопном движке не помешает — Basis Universal сжимает очень эффективно и транскодируется в S3TC или BPTC за считанные мгновения.

Текстура KTX1/KTX2 загружается в объект KTXAsset, при его создании необходимо указать приоритет транскодирования. Если это TranscodePriority.Size, то загрузчик отдает предпочтение S3TC, если TranscodePriority.Quality — BPTC (при наличии поддержки). Также можно использовать TranscodePriority.Uncompressed, чтобы получить наилучшее качество — текстура будет распакована в RGBA8.

Пример:

TextureAsset aTextureBox;
TextureAsset aTextureEnvmap;

// В конструкторе сцены:

registerKTXLoader(assetManager);

// На стадии запроса ассетов:

aTextureBox = addTextureAsset("data/box.ktx2");
aTextureBox.conversion.hint = TranscodeHint.Size;

aTextureEnvmap = addTextureAsset("data/cubemap.ktx2");
aTextureEnvmap.conversion.hint = TranscodeHint.Quality;

// При создании материалов:

material.baseColorTexture = aTextureBox.texture;
environment.ambientMap = aTextureEnvmap.texture;

Сжатие текстур, часть IV. Мобильные форматы: ETC и PVRTC

  • Дата публикации: 24.12.2024
  • /Метки: image processing
  • /Комментарии: 0

Продолжение серии постов о сжатых текстурных форматах. Предыдущие части: часть I, часть II, часть III.

Ситуация со сжатием текстур на мобильных платформах довольно запутанная, так как 3D-ускорители там существенно отличаются от десктопных. К сожалению, ни iOS, ни Android не поддерживают S3TC (и, тем более, BPTC). В мобильных системах используются свои специализированные форматы сжатия — ETC на Android и PVRTC на iOS.

ETC1 и ETC2

Ericsson Texture Compression / iPACKMAN

Формат сжатия от Ericsson. Поддерживается как в мобильных устройствах, так и в современных браузерах (кроме Firefox).

ETC1 поддерживается практически на всех android-устройствах и является стандартным форматом сжатия в OpenGL ES 2.0. Не поддерживает прозрачность. Блок 4×4 преобразуется в 64-битное представление. Блок разбивается на два субблока (4×2 или 2×4), им присваиваются базовые цвета — либо каждому RGB 4:4:4, либо одному 5:5:5, а второму смещение 3:3:3 относительно первого. Пиксели в субблоке представляются в виде суммы базового цвета и одного из четырех смещений — так называемых модификаторов: pixelColor = baseColor + RGB(modifier, modifier, modifier). Модификаторы, определяемые спецификацией, представляют собой 4×8 таблицу констант — целочисленных значений со знаком. Индексы ряда в таблице [0, 7] хранятся как два 3-битных значения (по одному на субблок), индексы столбца [0, 3] — как 16 2-битных значений (по одному на каждый пиксель). Оставшиеся два бита определяют ориентацию субблоков (flip-бит) и тип хранения базовых цветов (diff-бит). Результат суммирования нормализуется в 8 бит на канал.

ETC2 является стандартным форматом сжатия в OpenGL ES 3.0. Поддерживает прозрачность. ETC2 — это обратно-совместимое надмножество ETC1. Альфа-канал кодируется по такому же принципу, что и цвет: значение прозрачности для пикселя — это сумма базовой альфы и модификатора из таблицы констант 8×16. Блоку 4×4 присваиваются дополнительные 64 бита: 8-битное базовое значение альфа, 4-битный индекс ряда в таблице модификаторов, 4-битный множитель и 16 3-битных индексов столбцов.

Также в ETC2 есть отдельный режим punch-through (GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2), аналогичный ETC1, но в котором diff-бит заменяется битом прозрачности — таким образом, блок интерпретируется либо как полностью прозрачный, либо как полностью непрозрачный.

PVRTC1 и PVRTC2

PowerVR Texture Compression

Используется в видеоускорителях PowerVR (iPhone и другие устройства Apple). Основной целью разработчики формата поставили устранение разрывов цвета вдоль границ блоков, которая присуща S3TC. PVRTC поддерживает альфа-канал.

Имеет две разновидности — 4bpp и 2bpp. На блок всегда выделяется 64 бита информации, поэтому в режиме 4bpp блок имеет размер 4×4 пикселя, в режиме 2bpp — 8×4. В некоторых аппаратных реализациях блоки расположены в памяти не в порядке сканирования (снизу вверх, слева направо), а в Z-последовательности для увеличения пространственной локальности и, как следствие, более эффективного кэширования.

В каждом блоке хранится шесть переменных: для PVRTC1 — данные модуляции (32 бит), флаг punch-through alpha (1 бит), цвет A (15 бит), флаг прозрачности цвета A (1 бит), цвет B (14 бит) и флаг прозрачности цвета B (1 бит). Для PVRTC2 — данные модуляции (32 бит), флаг модуляции (1 бит), цвет B (15 бит), флаг hard transition (1 бит), цвет A (15 бит) и флаг прозрачности (1 бит). Битовая глубина значений A и B задается по-разному в зависимости от того, есть ли альфа-канал: либо RGB 5:5:4(5), либо RGBA 3:4:4:3(4), в скобках указан вариант для 15-битного цвета. Дополнительный бит прозрачности определяет наличие у цвета альфа-канала. В PVRTC его можно задавать независимо для A и B, когда как в PVRTC2 бит прозрачности только один, и оба цвета должны быть в одинаковом формате — либо RGB, либо RGBA. Цвет пикселя вычисляется билинейной интерполяцией цветов A и B. Каждому пикселю блока сопоставляется, в зависимости от разновидности формата, 2-битное или 1-битное значение модуляции, кодирующее вес интерполяции между A и B.

PVRTC2 расширяет алгоритм поддержкой четырех разных режимов блока, задаваемых флагами hard transition в сочетании с флагом модуляции: стандартная билинейная, punch-through alpha, резкий переход, локальная палитра.

Стеганография в dlib

Моя статья 2016 года, изначально написанная для блога LightHouse Software. Приведенный код актуален и сегодня.

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

(далее…)