Jak działa kompresja tekstur sprzętu?


13

To, że kompresuje dane w porównaniu do macierzy pikseli, jest oczywiste.

Ale czym się różni od normalnej kompresji (np. Png, jpeg)?


Co to jest „normalna kompresja” - takie rzeczy jak JPEG i PNG? Czy pytasz o różnice między tymi a obsługiwanymi sprzętowo formatami, takimi jak DXT i ASTC?
Nathan Reed,

6
(W końcu temat, o którym trochę wiem!) Tym, co odróżnia go od PNG / JPEG, jest dostęp losowy. Biorąc pod uwagę, że chcesz uzyskać dostęp do Texela (XY), możesz szybko określić niewielki rozmiar danych potrzebnych do jego wytworzenia. JPG lub PNG może wymagać dekompresji do wszystkich danych! Sekcje 1 i 2 artykułu w Wikipedii są dobrym podsumowaniem.
Simon F,

Jak napisał SimonF. To jest bardzo szerokie pytanie, a odpowiedź zależy od tego, jakiego typu jesteś zainteresowany. Czy sprawdziłeś specyfikację np. DXT?
imallett

Odpowiedzi:


25

Jak wspomniał komentarz Simona, jedną z głównych różnic między sprzętową kompresją tekstur a innymi powszechnie stosowanymi kompresjami obrazów jest to, że te pierwsze nie używają kodowania entropijnego. Kodowanie entropii polega na stosowaniu krótszych ciągów bitów do reprezentowania często występujących lub powtarzających się wzorców w danych źródłowych - jak widać w formatach kontenerów, takich jak ZIP, wielu popularnych formatach obrazów, takich jak GIF, JPEG i PNG, a także w wielu popularnych audio i formaty wideo.

Kodowanie entropijne jest dobre w kompresji wszelkiego rodzaju danych, ale samo w sobie daje zmienny współczynnik kompresji. Niektóre obszary obrazu mogą zawierać mało szczegółów (lub szczegóły są dobrze przewidywane przez używany model kodowania) i wymagają bardzo niewielu bitów, ale inne obszary mogą mieć złożone szczegóły, które wymagają większej liczby bitów do zakodowania. Utrudnia to wdrożenie losowego dostępu, ponieważ nie ma prostego sposobu obliczenia, gdzie w skompresowanych danych można znaleźć piksel w danym ( xy) współrzędne. Ponadto większość schematów kodowania entropijnego jest stanowa, więc nie można po prostu rozpocząć dekodowania w dowolnym miejscu w strumieniu; musisz zacząć od początku, aby zbudować właściwy stan. Jednak losowy dostęp jest konieczny do próbkowania tekstury, ponieważ moduł cieniujący może próbkować z dowolnego miejsca w teksturze w dowolnym momencie.

Tak więc, zamiast kodowania entropijnego, kompresja sprzętowa wykorzystuje schematy blokowe o stałym stosunku. Na przykład w kompresji DXT / BCn tekstura jest dzielona na bloki 4 × 4 piksele, z których każdy jest kodowany w 64 lub 128 bitach (w zależności od wybranego formatu); w ASTC różne formaty używają rozmiarów bloków od 4 × 4 do 12 × 12, a wszystkie bloki są kodowane w 128 bitach. Szczegóły dotyczące tego, jak bity reprezentują dane obrazu, różnią się w zależności od formatu (i mogą nawet różnić się w zależności od bloku na tym samym obrazie), ale ponieważ współczynnik jest stały, sprzęt może łatwo obliczyć, gdzie w pamięci znaleźć blok zawierający dany piksel ( x , y ), a każdy blok jest samodzielny, dzięki czemu można go dekodować niezależnie od innych bloków.

Innym aspektem kompresji tekstur sprzętowych jest to, że dekodowanie powinno być wydajnie implementowane w sprzęcie. Oznacza to, że ciężkie operacje matematyczne i złożone przepływy danych są zdecydowanie niekorzystne. Na przykład formaty BCn można dekodować, wykonując garść 8-bitowych liczb całkowitych operacji matematycznych na blok, aby wypełnić małą tabelę odnośników, a następnie po prostu sprawdzając odpowiedni wpis tabeli na piksel. Wymaga to bardzo małego obszaru na chipie, co jest ważne, ponieważ prawdopodobnie chcesz dekodować kilka bloków równolegle, a zatem potrzebujesz kilku kopii sprzętu dekodującego.

W przeciwieństwie do tego formaty oparte na DCT, takie jak JPEG, wymagają nietrywialnej ilości matematyki na piksel, nie wspominając już o złożonym przepływie danych, który zamienia i transmituje różne wartości pośrednie między pikselami w bloku. (Spójrz na ten artykuł, aby zobaczyć niektóre krwawe szczegóły dekodowania DCT.) Byłoby to znacznie bardziej nieprzyjemne dla implementacji sprzętowej, co, jak sądzę, właśnie dlatego AFAICT, żaden sprzęt GPU nigdy nie wdrożył kompresji tekstur opartych na DCT lub falkach .


doskonała odpowiedź. możesz także dodać, że jest kilka dokumentów wspominających, że w niektórych sytuacjach możesz samodzielnie kompresować i dekodować go za pomocą kodu klienta w module cieniującym piksele, zamiast polegać na dedykowanym sprzęcie. nie znam takiego zastosowania w świecie rzeczywistym, które może być warte jedynie badań, ale istnieje.
v.oddou

1
@ Nathan-Reed ponownie kompresja oparta na transformacji, w rzeczywistości projekt Talisman firmy Microsofts zastosował schemat kompresji o nazwie TREC, który (jako jeden z trybów) używał DCT, ale w przeciwieństwie do JPEG, pozwalał na losowy dostęp do bloków (podejrzewam, że musiała istnieć tabela zawierająca adresy). Pozwoliłoby to następnie na dane o zmiennej długości dla różnych bloków, ale dla HW pośrednictwo jest nieprzyjemne - powód, dla którego VQ TC wyszła z mody. FWIW Eksperymentowałem z około tuzinem pomysłów TC B4 PVRTC; niektóre były oparte na stałej szybkości, oparte na transformacji, ale „brakujące” współczynniki nadal używają bitów. Stałe lokalizacje koefektów podobne do BTC implikują „darmowe” informacje.
Simon F

2
@ Nathan-Reed. Z tego, co widziałem, wszystkie dekodery HW mogą być implementowane przy użyciu czystej ścieżki logicznej (dekodowanie bitów, wyszukiwanie, matematyka na ścieżce danych), ale bez konieczności zapętlania / rejestrowania. Czy znasz jakiś schemat, który dodaje opóźnienie cyklu do wyszukiwania tekstury? (Dla zabawy wdrożyłem dekoder VHDL ETC1) Miałem wrażenie, że każda jednostka tekstury (TU) ma wbudowane dekodery.
Romain Piquois,

31

„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 . :

  1. 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.

  2. 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ć

  3. 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.

  4. 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:

mały lorikeet + tekst
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.
wprowadź opis zdjęcia tutaj

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 Wynik 2Qp VQ. Mapa indeksów to:Mapa indeksu VQ 2bpp

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.
wprowadź opis zdjęcia tutaj

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.
wprowadź opis zdjęcia tutaj

Przykładowy obraz skompresowany za pomocą AMD Compressonator daje:
wprowadź opis zdjęcia tutaj

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:
wprowadź opis zdjęcia tutaj

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.
wprowadź opis zdjęcia tutaj
wprowadź opis zdjęcia tutaj

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.
wprowadź opis zdjęcia tutaj

wprowadź opis zdjęcia tutaj

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ść:
wprowadź opis zdjęcia tutaj

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.


1
Wow, to powinien być gdzieś blog! Świetna odpowiedź!
glampert

2
Cieszę się, że to pomaga. Co do bloga, napisałem to dziesięć lat temu, ale tak naprawdę nie mam czasu, aby to zrobić.
Simon F,

1
Witryna obsługująca stary blog jest martwa. To jest najnowsza zarchiwizowana wersja: web.archive.org/web/20160322090245/http://web.onetel.net.uk/…
ahcox
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.