„Jak działa kompresja tekstur (sprzętowa)” to duży temat. Mam nadzieję, że uda mi się uzyskać pewne spostrzeżenia bez powielania treści odpowiedzi Nathana .
Wymagania
Kompresja tekstur zazwyczaj różni się od „standardowych” technik kompresji obrazu, np. JPEG / PNG, na cztery główne sposoby, jak opisano w Renderowaniu z kompresowanych tekstur Beersa i in . :
Szybkość dekodowania : Nie chcesz, aby kompresja tekstur była wolniejsza (przynajmniej nie zauważalnie) niż przy użyciu nieskompresowanych tekstur. Dekompresja powinna być również stosunkowo prosta, ponieważ może to pomóc w szybkiej dekompresji bez nadmiernych kosztów sprzętu i energii.
Dostęp losowy : nie można łatwo przewidzieć, które tekstury będą wymagane podczas danego renderowania. Jeśli jakiś podzbiór M dostępnych tekstów pochodzi, powiedzmy, ze środka obrazu, istotne jest, aby nie musieć dekodować wszystkich „poprzednich” linii tekstury w celu ustalenia M ; w przypadku JPEG i PNG jest to konieczne, ponieważ dekodowanie pikseli zależy od wcześniej zdekodowanych danych.
Pamiętaj, że powiedziawszy to, tylko dlatego, że masz „losowy” dostęp, nie oznacza, że powinieneś próbować całkowicie dowolnie próbkować
Współczynnik kompresji i jakość wizualna : Beers i wsp. (Przekonująco) twierdzą, że utrata pewnej jakości wyniku kompresji w celu poprawy współczynnika kompresji jest opłacalna. Podczas renderowania 3D dane prawdopodobnie zostaną zmanipulowane (np. Przefiltrowane i zacienione itp.), Więc pewna utrata jakości może zostać dobrze zamaskowana.
Asymetryczne kodowanie / dekodowanie : Choć może nieco bardziej sporne, twierdzą, że dopuszczalne jest, aby proces kodowania był znacznie wolniejszy niż dekodowanie. Biorąc pod uwagę, że dekodowanie musi odbywać się przy współczynniku wypełnienia HW, jest to ogólnie dopuszczalne. (Przyznaję, że kompresja PVRTC, ETC2 i niektórych innych przy maksymalnej jakości może być szybsza)
Wczesna historia i techniki
Niektórzy mogą zaskoczyć, że kompresja tekstur istnieje już od ponad trzydziestu lat. Symulatory lotów z lat 70. i 80. wymagały dostępu do stosunkowo dużych ilości danych tekstur, a biorąc pod uwagę, że 1 MB pamięci RAM w 1980 r. Wynosiło> 6000 USD , niezbędne było zmniejszenie śladu tekstur. Jako kolejny przykład, w połowie lat 70., nawet niewielka ilość szybkiej pamięci i logiki, np. Wystarczająca na skromny bufor ramki RGB 512x512 ) może obniżyć cenę małego domu.
Chociaż, AFAIK, nie jawnie dalej kompresji tekstur, w literaturze i patentów można znaleźć odnośniki do technik, w tym:
a. proste formy matematycznej / proceduralnej syntezy tekstur,
b. zastosowanie tekstury jednokanałowej (np. 4 pb), która jest następnie mnożona przez wartość RGB dla tekstury,
c. YUV oraz
d. palety (literatura sugerująca zastosowanie podejścia Heckberta do kompresji)
Modelowanie danych obrazu
Jak wspomniano powyżej, kompresja tekstur jest prawie zawsze stratna, dlatego problemem staje się próba przedstawienia ważnych danych w zwarty sposób, przy jednoczesnym usuwaniu mniej znaczących informacji. Różne schematy, które zostaną opisane poniżej, mają domyślny „sparametryzowany” model, który aproksymuje typowe zachowanie danych tekstury i reakcji oka.
Ponadto, ponieważ kompresja tekstur zwykle wykorzystuje kodowanie o stałej szybkości, proces kompresji zwykle obejmuje etap wyszukiwania w celu znalezienia zestawu parametrów, które po wprowadzeniu do modelu wygenerują dobre przybliżenie oryginalnej tekstury. Ten etap wyszukiwania może być jednak czasochłonny.
(Z możliwym wyjątkiem narzędzi takich jak optipng , jest to kolejny obszar, w którym typowe użycie PNG i JPEG różni się od schematów kompresji tekstur)
Zanim przejdziemy dalej, aby lepiej zrozumieć TC, warto przyjrzeć się głównej analizie składników (PCA) - bardzo przydatnemu matematycznemu narzędziu do kompresji danych.
Przykładowa tekstura
Aby porównać różne metody, użyjemy następującego obrazu:
Zauważ, że jest to dość trudny obraz, szczególnie w przypadku metod paletowych i VQTC, ponieważ obejmuje znaczną część kostki kolorów RGB, a tylko 15% tekstur używa powtarzających się kolorów.
Kompresja tekstur na PC i (po połowie lat 90.)
Aby obniżyć koszty danych, niektóre gry na PC i wczesne konsole do gier również korzystały z obrazów paletowych, które są formą Vector Quantization (VQ). Podejścia oparte na palecie zakładają, że dany obraz używa tylko stosunkowo niewielkich części kostki kolorów RGB (A). Problem z teksturami palet polega na tym, że stopień kompresji dla osiągniętej jakości jest ogólnie raczej niewielki. Przykładowa tekstura skompresowana do „4bpp” (przy użyciu GIMP)
ponownie wygenerowała Zauważ, że jest to stosunkowo trudny obraz dla schematów VQ.
VQ z większymi wektorami (np. ARB 2bpp)
Zainspirowana przez Beers i wsp. Konsola Dreamcast wykorzystała VQ do kodowania bloków 2x2 lub nawet 2x4 pikseli za pomocą pojedynczych bajtów. Podczas gdy „wektory” w teksturach palety są 3 lub 4 wymiarowe, bloki 2x2 pikseli można uznać za 16 wymiarowe. Schemat kompresji zakłada, że wystarczające, przybliżone powtórzenie tych wektorów.
Mimo że VQ może osiągnąć zadowalającą jakość przy ~ 2 pz, problem z tymi schematami polega na tym, że wymaga on zależnych odczytów pamięci: po wstępnym odczycie z mapy indeksów w celu ustalenia kodu piksela następuje sekunda, aby faktycznie pobrać powiązane dane piksela z tym kodem. Dodatkowe pamięci podręczne mogą pomóc w zmniejszeniu niektórych opóźnień, ale zwiększają złożoność sprzętu.
Przykładowy obraz skompresowany za pomocą schematu Dreamcast 2bpp to
. Mapa indeksów to:
Kompresję danych VQ można przeprowadzić na różne sposoby, jednak IIRC , powyższe zostało wykonane przy użyciu PCA w celu uzyskania, a następnie podzielenie wektorów 16D wzdłuż głównego wektora na 2 zestawy tak, że dwa reprezentatywne wektory zminimalizowały średni błąd kwadratu. Następnie proces powtarzał się, aż wytworzono 256 kandydujących wektorów. Następnie zastosowano globalne podejście oparte na algorytmie k-średnich / Lloyda w celu ulepszenia przedstawicieli.
Transformacje przestrzeni kolorów
Transformacje przestrzeni kolorów wykorzystują również PCA, zauważając, że globalny rozkład kolorów jest często rozłożony wzdłuż głównej osi, przy znacznie mniejszym rozłożeniu wzdłuż innych osi. W przypadku reprezentacji YUV przyjmuje się, że a) główna oś często jest w kierunku lumy i b) oko jest bardziej wrażliwe na zmiany w tym kierunku.
System 3dfx Voodoo dostarczył system kompresji „YAB” , 8bpp „Narrow Channel”, który podzielił każdy 8-bitowy texel na format 322 i zastosował transformację kolorów wybraną przez użytkownika do tych danych, aby zmapować je na RGB. Główna oś miała więc 8 poziomów, a mniejsze - po 4.
Układ S3 Virge miał nieco prostszy schemat 4 bpp, który pozwolił użytkownikowi określić dla całej tekstury dwa kolory końcowe, które powinny znajdować się na głównej osi, wraz z monochromatyczną teksturą 4 pb. Wartość na piksel zmieszała następnie kolory końcowe z odpowiednimi wagami, aby uzyskać wynik RGB.
Systemy oparte na BTC
Cofając się o kilka lat, Delp i Mitchell opracowali prosty (monochromatyczny) schemat kompresji obrazu o nazwie Block Truncation Coding (BTC) . Ten artykuł zawiera również algorytm kompresji, ale dla naszych celów jesteśmy głównie zainteresowani uzyskanymi skompresowanymi danymi i procesem dekompresji.
W tym schemacie obrazy są podzielone, zazwyczaj, na bloki 4x4 pikseli, które można niezależnie kompresować za pomocą zlokalizowanego algorytmu VQ. Każdy blok jest reprezentowany przez dwie „wartości”, i b oraz zestaw 4x4 indeksów bitów, które określają, które z dwóch wartości do wykorzystania dla każdego piksela.
S3TC : 4bpp RGB (+ 1 bit alpha)
Chociaż kilka kolorów warianty BTC do kompresji obrazu zaproponowano, interesuje nas to Iourcha wsp na S3TC , z których część wydaje się być ponowne odkrycie nieco zapomnianej pracy Hoffert wsp że był używany w Apple's Quicktime.
Oryginalny S3TC, bez wariantów DirectX, kompresuje bloki RGB lub RGB + 1bit Alpha do 4bpp. Każdy blok 4x4 w teksturze jest zastępowany dwoma końcowymi kolorami, A i B , z których maksymalnie dwa inne kolory pochodzą z liniowych mieszanek o stałej wadze. Ponadto każdy tekst w bloku ma 2-bitowy indeks, który określa, jak wybrać jeden z tych czterech kolorów.
Na przykład poniżej znajduje się sekcja 4x4 pikseli obrazu testowego skompresowanego za pomocą narzędzia AMD / ATI Compressenator. ( Technicznie pochodzi z wersji testowej 512x512, ale wybacz mi brak czasu na aktualizację przykładów ).
To ilustruje proces kompresji: obliczana jest średnia i główna oś kolorów. Następnie wykonuje się najlepsze dopasowanie, aby znaleźć dwa punkty końcowe, które „leżą” na osi, która wraz z dwoma pochodnymi 1: 2 i 2: 1 łączy (lub w niektórych przypadkach 50:50) tych punktów końcowych, które minimalizuje błąd. Każdy oryginalny piksel jest następnie mapowany na jeden z tych kolorów, aby uzyskać wynik.
Jeśli, podobnie jak w tym przypadku, kolory są w przybliżeniu przybliżone przez oś główną, błąd będzie stosunkowo niski. Jeśli jednak, podobnie jak w pokazanym poniżej sąsiednim bloku 4x4, kolory są bardziej zróżnicowane, błąd będzie wyższy.
Przykładowy obraz skompresowany za pomocą AMD Compressonator daje:
Ponieważ kolory są określane niezależnie dla bloku, mogą występować nieciągłości na granicach bloków, ale dopóki rozdzielczość jest utrzymywana wystarczająco wysoka, artefakty blokowe mogą pozostać niezauważone:
ETC1 :
Kompresja tekstur Ericsson RGB 4bpp działa również z blokami tekstur 4x4, ale zakłada, że podobnie jak YUV, główna oś lokalnego zestawu tekstur jest często bardzo silnie skorelowana z „luma”. Zestaw tekstur może być następnie reprezentowany przez zwykły kolor i wysoce skwantowaną skalarną „długość” rzutu tekstur na tę założoną oś.
Ponieważ zmniejsza to koszty przechowywania danych w stosunku do powiedzmy S3TC, umożliwia ETC wprowadzenie schematu partycjonowania, w którym blok 4x4 jest podzielony na parę poziomych podbloków 4x2 lub pionowych 2x4. Każdy z nich ma swój własny średni kolor. Przykładowy obraz przedstawia:
Obszar wokół dzioba ilustruje również poziomy i pionowy podział bloków 4x4.
Globalny + lokalny
Istnieje kilka systemów kompresji tekstur, które stanowią skrzyżowanie schematów globalnych i lokalnych, takich jak rozproszone palety Iwanowa i Kuźmina lub metoda PVRTC .
PVRTC : 4 i 2 bpp RGBA
PVRTC zakłada, że (w praktyce, dwuliniowo) obraz przeskalowany jest dobrym przybliżeniem do celu o pełnej rozdzielczości i że różnica między przybliżeniem a celem, tj. Obraz delta, jest lokalnie monochromatyczna, tj. ma dominującą oś główną. Ponadto zakłada, że lokalna oś główna może być interpolowana w poprzek obrazu.
(do zrobienia: dodawanie zdjęć pokazujących podział)
Przykładowa tekstura skompresowana za pomocą PVRTC1 4bpp daje:
z obszarem wokół dzioba:
W porównaniu ze schematami BTC, artefakty blokowe są zazwyczaj eliminowane, ale czasami może wystąpić „przeregulowanie”, jeśli występują silne nieciągłości w obrazie źródłowym, na przykład wokół sylwetka głowy lorikeet.
Wariant 2 pb ma oczywiście wyższy błąd niż 4 pb (zauważ utratę precyzji wokół niebieskich obszarów o wysokiej częstotliwości w pobliżu szyi), ale prawdopodobnie nadal ma rozsądną jakość:
Uwaga na temat kosztów dekompresji
Chociaż algorytmy kompresji dla schematów opisanych powyżej mają koszt oceny od umiarkowanego do wysokiego, algorytmy dekompresji, szczególnie dla implementacji sprzętowych, są stosunkowo niedrogie. Na przykład ETC1 wymaga niewiele więcej niż kilku MUX i dodatków o niskiej precyzji; S3TC skutecznie nieco więcej jednostek dodających do przeprowadzenia mieszania; i PVRTC, nieco więcej. Teoretycznie te proste schematy TC mogą pozwolić architekturze GPU uniknąć dekompresji aż do tuż przed etapem filtrowania, maksymalizując w ten sposób efektywność wewnętrznych pamięci podręcznych.
Inne programy
Inne popularne tryby TC, o których należy wspomnieć, to:
ETC2 - jest nadzbiorem ETC1 (4 pb), który poprawia obsługę regionów z rozkładami kolorów, które nie są dobrze dopasowane do „luma”. Istnieje również wariant 4bpp, który obsługuje 1 bit alfa, oraz format 8bpp dla RGBA.
ATC - jest skutecznie małą odmianą S3TC .
FXT1 (3dfx) był bardziej ambitnym wariantem motywu S3TC .
BC6 i BC7: oparty na blokach system 8bpp obsługujący ARGB. Oprócz trybów HDR wykorzystują one bardziej złożony system partycjonowania niż ETC, aby spróbować lepiej modelować rozkład kolorów obrazu.
PVRTC2: ARGB 2 i 4 bpp. Wprowadza to dodatkowe tryby, w tym jeden, aby pokonać ograniczenia z silnymi granicami na obrazach.
ASTC: Jest to również system oparty na blokach, ale jest nieco bardziej skomplikowany, ponieważ ma dużą liczbę możliwych rozmiarów bloków ukierunkowanych na szeroki zakres bpp. Zawiera także funkcje, takie jak do 4 regionów partycji z pseudolosowym generatorem partycji oraz zmienną rozdzielczość danych indeksu i / lub modeli precyzji kolorów i kolorów.