"Як (апаратне) стиснення текстури працює" - велика тема. Сподіваюсь, я можу дати деяку інформацію, не дублюючи змісту відповіді Натана .
Вимоги
Стиснення текстури зазвичай відрізняється від "стандартних" методів стиснення зображення, наприклад, JPEG / PNG чотирма основними способами, як зазначено в " Візуалізація Beers et al. Від стиснених текстур" :
Швидкість декодування : Ви не хочете, щоб стиснення текстур було повільніше (принаймні, не помітно), ніж використання нестиснених текстур. Декомпресія також повинна бути досить простою, оскільки це може допомогти досягти швидкої декомпресії без зайвих апаратних та енерговитрат.
Випадковий доступ : Ви не можете легко передбачити, які текстилі будуть потрібні під час заданої візуалізації. Якщо якась підмножина M із текстів, що звертаються, походить із, скажімо, середини зображення, важливо, щоб вам не потрібно було розшифровувати всі "попередні" рядки текстури, щоб визначити M ; для JPEG та PNG це необхідно, оскільки декодування пікселів залежить від раніше декодованих даних.
Зауважте, що, сказавши це, тільки тому, що у вас є "випадковий" доступ, не означає, що слід намагатися зробити вибірку повністю довільно
Коефіцієнт стиснення та візуальна якість : Beers et al стверджують (переконливо), що втрата деякої якості стислого результату з метою підвищення швидкості стиснення є корисною компромісом. У режимі 3D-рендерінгу дані, мабуть, будуть маніпулювати (наприклад, відфільтровані та заштриховані тощо), тому деякі втрати якості цілком можуть бути замасковані.
Асиметричне кодування / декодування : Хоча, можливо, трохи більш спірним, вони стверджують, що прийнятним є процес кодування набагато повільніше, ніж декодування. Зважаючи на те, що розшифровка повинна здійснюватися при швидкості заповнення HW, це, як правило, прийнятно. (Я визнаю, що стиснення PVRTC, ETC2 та деяких інших при максимальній якості може бути швидшим)
Рання історія та методи
Дехто може здивувати, коли дізнаються, що стиснення текстури існує вже більше трьох десятиліть. Симулятори польоту з 70-х та 80-х потребували доступу до відносно великої кількості текстурних даних, враховуючи, що 1 Мб оперативної пам’яті в 1980 р. Становив> 6000 доларів , зменшення нанесення текстури було надзвичайно важливим. Як інший приклад, у середині 70-х років навіть невелика кількість швидкодіючої пам’яті та логіки, наприклад, достатньо для скромного буфера кадрів 512x512 RGB ) може повернути вам ціну невеликого будинку.
Хоча AFAIK, не прямо названий стисненням текстури, в літературі та патентах ви можете знайти посилання на методи, включаючи:
a. прості форми синтезу математичної / процедурної текстури,
b. використання текстури одноканального каналу (наприклад, 4bpp), яка потім множиться на значення RGB на одну текстуру,
c. ЮВ, і
д. палітри (література, що пропонує використання підходу Гекберта для стиснення)
Моделювання графічних даних
Як зазначалося вище, стиснення текстури майже завжди є втратним, і, отже, проблема стає спробою представити важливі дані компактним способом під час розпорядження менш вагомою інформацією. Різні схеми, які будуть описані нижче, мають неявну "параметризовану" модель, яка наближає типову поведінку текстурних даних та відповіді очей.
Крім того, оскільки стиснення текстури має тенденцію до використання кодування з фіксованою швидкістю, процес стиснення зазвичай включає етап пошуку, щоб знайти набір параметрів, які при подачі в модель будуть генерувати гарне наближення до вихідної текстури. Однак цей крок пошуку може зайняти багато часу.
(За можливим винятком таких інструментів, як optipng , це ще одна область, де типове використання PNG та JPEG відрізняється від схем стиснення текстури)
Перш ніж прогресувати далі, для подальшого розуміння ТС варто переглянути аналіз основних компонентів (PCA) - дуже корисний математичний інструмент для стиснення даних.
Приклад текстури
Для порівняння різних методів ми використаємо наступне зображення:
Зауважте, що це досить жорстке зображення, особливо для палітри та методів VQTC, оскільки воно охоплює велику частину кольорового куба RGB, і лише 15% текстолів використовують повторювані кольори.
Стиснення текстури консолі ПК та (після середини 90-х)
Для зменшення витрат на дані деякі ПК для ПК та ранніх ігрових консолей також використовували зображення палітри, що є формою векторної квантування (VQ). Підходи на основі палітри припускають, що для даного зображення використовуються лише відносно невеликі частини кольорового куба RGB (A). Проблема текстур палітри полягає в тому, що рівень стиснення для досягнутої якості, як правило, досить скромний. Приклад текстури, стиснутої до "4bpp" (за допомогою GIMP),
знову зауважив, що це відносно жорстке зображення для VQ-схем.
VQ з більшими векторами (наприклад, 2bpp ARGB)
Натхненний Beers et al, консоль Dreamcast використовував VQ для кодування блоків 2x2 або навіть 2x4 пікселя з одиничними байтами. Хоча «вектори» в палітрі текстур є 3-х або 4-мірними, блоки 2x2 пікселів можна вважати 16-мірними. Схема стиснення передбачає достатнє, приблизне повторення цих векторів.
Навіть незважаючи на те, що VQ може досягти задовільної якості за допомогою ~ 2bpp, проблема цих схем полягає в тому, що він вимагає залежних зчитувань пам'яті: Початковому зчитуванню з індексної карти для визначення коду пікселя слідує секунда, щоб фактично отримати дані, пов'язані з пікселями. з цим кодом. Додаткові кеші можуть допомогти зменшити деяку частину затримки, але додають складності обладнання.
Приклад зображення, стисненого за допомогою схеми Dreambb 2bpp
. Індексна карта:
Стиснення даних VQ можна здійснити різними способами, однак IIRC , вищезгадане було зроблено за допомогою PCA для отримання, а потім розподілу 16D векторів уздовж основного вектора на 2 набори, щоб два репрезентативних вектора мінімізували середню квадратичну помилку. Потім процес повторювався, поки не було створено 256 векторів-кандидатів. Тоді для вдосконалення представників було застосовано глобальний підхід до алгоритму к-засобів / алгоритму Ллойда .
Кольорові космічні перетворення
Кольорові просторові трансформації також використовують PCA, зазначаючи, що глобальний розподіл кольорів часто поширюється уздовж основної осі з набагато меншим поширенням по інших осях. Для уявлень YUV припущення полягають у тому, що а) основна вісь часто знаходиться в напрямку луми, і що б) око чутливіше до змін у цьому напрямку.
Система 3dfx Voodoo забезпечила "YAB" , 8bpp, "Вузький канал", який розділив кожну 8-бітну текселю на формат 322, і застосував вибране користувачем перетворення кольорів до цих даних, щоб зіставити їх у RGB. Таким чином, головна вісь мала 8 рівнів, а менші осі - по 4.
Мікросхема S3 Virge мала трохи простішу схему 4bpp, яка дозволила користувачеві вказати для всієї текстури два кінцеві кольори, які повинні лежати на головній осі, а також монохромну текстуру 4bpp. Значення на піксель потім змішувало кінцеві кольори з відповідними вагами для отримання результату RGB.
Схеми на основі BTC
Перегортаючи деяку кількість років, Delp і Мітчелл розробили просту (монохромну) схему стиснення зображення під назвою Блокування кодування обрізання (BTC) . Цей документ також включав алгоритм стиснення, але для наших цілей ми в основному зацікавлені в отриманих стислих даних і в процесі декомпресії.
У цій схемі зображення розбиваються, як правило, на 4х4 піксельні блоки, які можна стискати незалежно, фактично з локалізованим алгоритмом VQ. Кожен блок представлений двома "значеннями", a і b , і 4x4 набором бітів індексу, які ідентифікують, яке з двох значень використовувати для кожного пікселя.
S3TC : 4bpp RGB (+ 1bit альфа)
Хоча деякі кольори , варіанти BTC для стиснення зображень були запропоновані, для нас інтересу представляє Iourcha і колега S3TC , деякі з яких , як видається, повторне відкриття декількох забутого Hoffert і ін , що використовувався в Quicktime Apple.
Оригінальний S3TC, без варіантів DirectX, стискає блоки або RGB, або RGB + 1bit Alpha до 4bpp. Кожен блок текстури 4x4 замінюється двома кінцевими кольорами, A і B , з яких до двох інших кольорів виводяться лінійні суміші з фіксованою вагою. Далі кожен текстовий блок має 2-розрядний індекс, який визначає, як вибрати один із цих чотирьох кольорів.
Наприклад, нижче - розділ 4х4 пікселів тестового зображення, стисненого інструментом AMD / ATI Compresssenator. ( Технічно це взято з версії тестового зображення 512x512, але пробачте мою відсутність часу для оновлення прикладів ).
Це ілюструє процес стиснення: обчислюється середня і основна вісь кольорів. Потім найкраще підходить для того, щоб знайти дві кінцеві точки, які лежать на осі, яка разом з двома похідними 1: 2 і 2: 1 змішується (або в деяких випадках суміш 50:50) цих кінцевих точок, мінімізує помилку. Кожен оригінальний піксель відображається в одному з цих кольорів для отримання результату.
Якщо, як і в цьому випадку, кольори розумно наближені до головної осі, похибка буде відносно низькою. Однак якщо, як і в сусідньому блоці 4x4, показаному нижче, кольори будуть більш різноманітними, помилка буде вище.
Приклад зображення, стисненого компресоратором AMD, створює:
Оскільки кольори визначаються незалежно за блоком, на кордонах блоку можуть бути розриви, але, поки роздільна здатність зберігається досить високою, ці блокові артефакти можуть залишатися непоміченими:
ETC1 : 4bpp RGB
Ericsson Texture Compression також працює з текстильними блоками 4x4, але робить припущення, що, як і YUV, головна вісь локального набору текстилів часто дуже сильно корелює з "luma". Набір текселів може бути представлений просто середнім кольором і сильно квантована, скалярна "довжина" проекції текстолів на цю припущену вісь.
Оскільки це зменшує витрати на зберігання даних відносно, наприклад, S3TC, це дозволяє ETC ввести схему розподілу, за допомогою якої блок 4x4 підрозділяється на пару горизонтальних 4x2 або вертикальних 2x4 підблоків. Кожен з них має свій середній колір. Приклад зображення створює:
Область навколо дзьоба також ілюструє горизонтальну та вертикальну перегородку блоків 4x4.
Глобальний + Локальний
Існують деякі системи стиснення текстури, які є схрещуванням між глобальними та локальними схемами, такі як розподілена палітра Іванова та Кузьміна або метод PVRTC .
PVRTC : 4 і 2 bpp RGBA
PVRTC передбачає, що (на практиці, білінеарне) збільшене зображення є хорошим наближенням до цілі з повною роздільною здатністю і що різниця між наближенням і ціллю, тобто дельта-зображення, є локально монохроматичною, тобто має домінуючу головну вісь. Крім того, передбачається, що локальна головна вісь може бути інтерпольована по зображенню.
(робити: Додати зображення, що показують розбиття)
Приклад текстури, стиснутої PVRTC1 4bpp, створює:
з областю навколо дзьоба:
Порівняно з BTC-схемами, блокові артефакти, як правило, усуваються, але іноді можуть бути "перестрілки", якщо у вихідному зображенні є сильні розриви, наприклад навколо силует голови лорікет.
У варіанті 2bpp, природно, вища помилка, ніж у 4bpp (відзначимо втрату точності навколо синіх, високочастотних областей біля шиї), але, мабуть, все ще досить якісної:
Примітка про витрати на декомпресію
Хоча алгоритми стиснення для схем, описаних вище, мають помірну та високу вартість оцінки, алгоритми декомпресії, особливо для апаратних реалізацій, є відносно недорогими. Наприклад, ETC1 вимагає трохи більше декількох MUX і низькоточних добавників; S3TC ефективно трохи більше допоміжних блоків для здійснення суміші; і PVRTC, знову трохи більше. Теоретично, ці прості схеми TC можуть дозволяти архітектурі GPU уникати декомпресії лише перед етапом фільтрації, тим самим максимізуючи ефективність внутрішніх кеш-пам'яток.
Інші схеми
Інші поширені режими ТС, які слід згадати:
ETC2 - це (4bpp) надмножина ETC1, яка покращує обробку регіонів з розподілом кольорів, які не узгоджуються з "luma". Існує також 4bpp варіант, який підтримує 1 бітну альфа, і 8bpp формат для RGBA.
ATC - це фактично невелика різниця на S3TC .
FXT1 (3dfx) був більш амбітним варіантом теми S3TC .
BC6 & BC7: 8bpp, блокова система, що підтримує ARGB. Крім режимів HDR, вони використовують більш складну систему розподілу, ніж система ETC, щоб спробувати покращити моделювання розподілу кольорів зображення.
PVRTC2: 2 та 4bpp ARGB. Це вводить додаткові режими, включаючи режим подолання обмежень із сильними межами у зображеннях.
ASTC: Це також блокова система, але дещо складніша тим, що вона має велику кількість можливих розмірів блоків, орієнтованих на широкий діапазон bpp. Вона також включає такі функції, як до 4 областей розділів з генератором псевдовипадкових розділів, і змінною роздільною здатністю для даних індексу та / або кольорової точності та кольорових моделей.