Come funziona la compressione delle trame hardware?

È evidente che comprime i dati rispetto all'array di pixel.

Ma cosa lo differenzia dalla normale compressione (come png, jpeg)?

Come ha accennato il commento di Simon, una delle principali differenze tra la compressione delle trame hardware e l'altra compressione delle immagini comunemente usata è che la prima non usa la codifica entropica. La codifica entropica è l'uso di stringhe di bit più brevi per rappresentare schemi ricorrenti o ripetitivi nei dati di origine, come si vede nei formati contenitore come ZIP, molti formati di immagine comuni come GIF, JPEG e PNG e anche in molti audio comuni e formati video.

La codifica entropica è efficace nel comprimere tutti i tipi di dati, ma produce intrinsecamente un rapporto di compressione variabile. Alcune aree dell'immagine potrebbero avere pochi dettagli (o il dettaglio è previsto bene dal modello di codifica che stai utilizzando) e richiedere pochissimi bit, ma altre aree potrebbero avere dettagli complessi che richiedono più bit per codificare. Ciò rende difficile implementare l'accesso casuale, in quanto non esiste un modo semplice per calcolare dove nei dati compressi è possibile trovare il pixel in un dato ( x ,  y) coordinate. Inoltre, la maggior parte degli schemi di codifica entropica sono stateful, quindi non è possibile iniziare semplicemente a decodificare in un punto arbitrario nel flusso; devi iniziare dall'inizio per costruire lo stato corretto. Tuttavia, è necessario l'accesso casuale per il campionamento delle trame, poiché uno shader può campionare da qualsiasi posizione in una trama in qualsiasi momento.

Pertanto, anziché la codifica entropica, la compressione hardware utilizza schemi a blocchi fissi con rapporto fisso. Ad esempio, nella compressione DXT / BCn , la trama viene suddivisa in blocchi di 4 × 4 pixel, ognuno dei quali è codificato in 64 o 128 bit (a seconda del formato scelto); in ASTC , diversi formati utilizzano blocchi di dimensioni da 4 × 4 a 12 × 12 e tutti i blocchi sono codificati in 128 bit. I dettagli su come i bit rappresentano i dati dell'immagine variano tra i formati (e possono anche variare da un blocco all'altro all'interno della stessa immagine), ma poiché il rapporto è fisso, è facile per l'hardware calcolare dove in memoria trovare il blocco contenente un dato ( x , y pixel ) e ogni blocco è autonomo, quindi può essere decodificato indipendentemente da qualsiasi altro blocco.

Un'altra considerazione nella compressione delle trame hardware è che la decodifica dovrebbe essere implementabile in modo efficiente nell'hardware. Ciò significa che le operazioni matematiche pesanti e il flusso di dati complessi sono fortemente sfavorevoli. I formati BCn, ad esempio, possono essere decodificati eseguendo una manciata di operazioni matematiche a numeri interi a 8 bit per blocco per popolare una piccola tabella di ricerca, quindi solo cercando la voce di tabella appropriata per pixel. Ciò richiede pochissima area su chip, il che è importante perché probabilmente si desidera decodificare più blocchi in parallelo e quindi sono necessarie diverse copie dell'hardware di decodifica.

Al contrario, i formati basati su DCT come JPEG richiedono una quantità non banale di matematica per pixel, per non parlare di un flusso di dati complesso che scambia e trasmette vari valori intermedi attraverso i pixel all'interno di un blocco. (Guarda questo articolo per alcuni dei dettagli cruenti della decodifica DCT.) Questo sarebbe molto più grossolano per l'implementazione hardware, che immagino sia il motivo per cui AFAICT, nessun hardware GPU ha mai implementato la compressione delle texture basata su DCT o wavelet .

"Come funziona la compressione delle trame (hardware)" è un argomento di grandi dimensioni. Spero di poter fornire alcuni spunti senza duplicare il contenuto della risposta di Nathan .

Requisiti

La compressione delle trame differisce in genere dalle tecniche di compressione delle immagini "standard", ad esempio JPEG / PNG, in quattro modi principali, come indicato in Rendering da trame compresse di Beers et al :

1. Velocità di decodifica : non si desidera che la compressione delle trame sia più lenta (almeno evidentemente) rispetto all'utilizzo di trame non compresse. Dovrebbe anche essere relativamente semplice da decomprimere poiché ciò può aiutare a ottenere una decompressione rapida senza costi hardware e di alimentazione eccessivi.

2. Accesso casuale : non è possibile prevedere facilmente quali texel saranno richiesti durante un determinato rendering. Se alcuni sottogruppi, M , dei texel accessibili provengono, per esempio, dal centro dell'immagine, è essenziale che non sia necessario decodificare tutte le linee "precedenti" della trama per determinare M ; con JPEG e PNG questo è necessario poiché la decodifica dei pixel dipende dai dati precedentemente decodificati.
   Nota, detto questo, solo perché hai accesso "casuale", non significa che dovresti provare a campionare in modo completamente arbitrario

3. Tasso di compressione e qualità visiva : Beers et al sostengono (in modo convincente) che perdere un po 'di qualità nel risultato compresso al fine di migliorare il tasso di compressione è un compromesso utile. Nel rendering 3D, i dati verranno probabilmente manipolati (ad esempio, filtrati, ombreggiati, ecc.) E quindi potrebbe essere mascherata una certa perdita di qualità.

4. Codifica / decodifica asimmetrica : anche se forse leggermente più controversa, sostengono che è accettabile che il processo di codifica sia molto più lento della decodifica. Dato che la decodifica deve essere conforme ai tassi di riempimento HW, ciò è generalmente accettabile. (Devo ammettere che la compressione di PVRTC, ETC2 e alcuni altri alla massima qualità potrebbe essere più veloce)

Storia e tecniche antiche

Potrebbe sorprendere alcuni apprendere che la compressione delle trame esiste da oltre tre decenni. I simulatori di volo degli anni '70 e '80 necessitavano dell'accesso a quantità relativamente grandi di dati di trama e dato che 1 MB di RAM nel 1980 era> $ 6000 , ridurre l'impronta della trama era essenziale. Come altro esempio, a metà degli anni '70, anche una piccola quantità di memoria e logica ad alta velocità, ad esempio abbastanza per un modesto buffer di frame RGB 512x512 ) potrebbe farti il prezzo della piccola casa.

Tuttavia, AFAIK, non esplicitamente indicato come compressione delle trame, nella letteratura e nei brevetti è possibile trovare riferimenti a tecniche tra cui:
a. forme semplici di sintesi matematica / procedurale delle trame,
b. utilizzo di una trama a canale singolo (es. 4bpp) che viene poi moltiplicata per un valore RGB per trama,
c. YUV e
d. tavolozze (la letteratura che suggerisce l'uso dell'approccio di Heckbert per eseguire la compressione)

Modellazione di dati immagine

Come notato sopra, la compressione delle trame è quasi sempre in perdita e quindi il problema diventa quello di provare a rappresentare i dati importanti in modo compatto eliminando le informazioni meno significative. I vari schemi che verranno descritti di seguito hanno tutti un modello implicito "parametrizzato" che approssima il comportamento tipico dei dati di trama e della risposta dell'occhio.

Inoltre, poiché la compressione delle trame tende a utilizzare la codifica a velocità fissa, il processo di compressione di solito include un passaggio di ricerca per trovare l'insieme di parametri che, quando immessi nel modello, genereranno una buona approssimazione della trama originale. Tale passaggio di ricerca, tuttavia, può richiedere molto tempo.
(Con la possibile eccezione di strumenti come optipng , questa è un'altra area in cui l'uso tipico di PNG e JPEG differisce dagli schemi di compressione delle trame)

Prima di progredire ulteriormente, per aiutare a comprendere meglio TC, vale la pena dare un'occhiata all'analisi dei componenti principali (PCA) , uno strumento matematico molto utile per la compressione dei dati.

Esempio di trama

Per confrontare i vari metodi, useremo la seguente immagine:

Si noti che questa è un'immagine abbastanza dura, specialmente per i metodi palette e VQTC in quanto abbraccia gran parte del cubo di colore RGB e solo il 15% dei texel usa colori ripetuti.

Compressione PC e console (dopo la metà degli anni '90)

Per ridurre i costi dei dati, alcuni giochi per PC e console per i primi giochi si sono avvalsi anche delle immagini della tavolozza, che è una forma di Quantizzazione vettoriale (VQ). Gli approcci basati su palette presuppongono che una determinata immagine utilizzi solo porzioni relativamente piccole del cubo di colore RGB (A). Un problema con le trame della palette è che i tassi di compressione per la qualità raggiunta sono generalmente piuttosto modesti. La trama di esempio compressa in "4bpp" (usando GIMP) prodotta

nuovo Nota che questa è un'immagine relativamente dura per gli schemi VQ.

VQ con vettori più grandi (ad es. 2bpp ARGB)

Ispirata da Beers et al., La console Dreamcast utilizzava VQ per codificare blocchi di pixel 2x2 o addirittura 2x4 con byte singoli. Mentre i "vettori" nella palette sono tridimensionali, i blocchi di pixel 2x2 possono essere considerati di 16 dimensioni. Lo schema di compressione presuppone che vi sia una ripetizione approssimativa e sufficiente di questi vettori.

Anche se VQ può raggiungere una qualità soddisfacente con ~ 2 bpp, il problema con questi schemi è che richiede letture di memoria dipendenti: una lettura iniziale dalla mappa dell'indice per determinare il codice per il pixel è seguita da un secondo per recuperare effettivamente i dati pixel associati con quel codice. Le cache aggiuntive possono aiutare ad alleviare parte della latenza sostenuta, ma aggiungono complessità all'hardware.

L'immagine di esempio compressa con lo schema Dreamcast 2bpp è . La mappa dell'indice è:

La compressione dei dati VQ può essere fatta in vari modi, tuttavia, IIRC , quanto sopra è stato fatto usando PCA per derivare e quindi suddividere i vettori 16D lungo il vettore principale in 2 set in modo tale che due vettori rappresentativi minimizzassero l'errore quadratico medio. Il processo è quindi continuato fino a quando sono stati prodotti 256 vettori candidati. È stato quindi applicato un approccio di algoritmo k-medie / Lloyd globale per migliorare i rappresentanti.

Trasformazioni dello spazio colore

Le trasformazioni dello spazio colore fanno anche uso di PCA notando che la distribuzione globale del colore è spesso diffusa lungo un asse maggiore con una diffusione molto minore lungo gli altri assi. Per le rappresentazioni YUV, i presupposti sono che a) l'asse maggiore è spesso nella direzione del luma e che b) l'occhio è più sensibile ai cambiamenti in questa direzione.

Il sistema Voodoo 3dfx ha fornito "YAB" , un sistema di compressione "Narrow Channel" da 8 bpp, che ha suddiviso ogni texel a 8 bit in un formato 322 e applicato una trasformazione colore selezionata dall'utente a quei dati per mapparlo in RGB. L'asse principale aveva quindi 8 livelli e gli assi più piccoli, 4 ciascuno.

Il chip S3 Virge aveva uno schema leggermente più semplice, 4 bpp, che permetteva all'utente di specificare, per l'intera trama , due colori finali, che dovrebbero trovarsi sull'asse principale, insieme a una trama monocromatica a 4 bpp. Il valore per pixel ha quindi miscelato i colori finali con pesi appropriati per produrre il risultato RGB.

Schemi basati su BTC

Riavvolgendo alcuni anni, Delp e Mitchell hanno progettato un semplice schema di compressione delle immagini (monocromatico) chiamato Block Truncation Coding , (BTC) . Questo documento includeva anche un algoritmo di compressione ma, per i nostri scopi, siamo principalmente interessati ai dati compressi risultanti e al processo di decompressione.

In questo schema, le immagini sono suddivise, in genere, in blocchi di pixel 4x4, che possono essere compressi indipendentemente con, in effetti, un algoritmo VQ localizzato. Ogni blocco è rappresentato da due "valori", un e B , e un insieme di bit 4x4 indice, che identificano quale dei due valori da utilizzare per ciascun pixel.

S3TC : 4bpp RGB (+ 1bit alpha)
Sebbene siano state proposte diverse varianti cromatiche di BTC per la compressione delle immagini, per noi è interessante l' S3TC di Iourcha et al , alcune delle quali sembrano essere una riscoperta dell'opera un po 'dimenticata di Hoffert et al che è stato utilizzato in Quicktime di Apple.

L'S3TC originale, senza le varianti DirectX, comprime i blocchi di RGB o RGB + 1bit Alpha a 4bpp. Ogni blocco 4x4 nella trama è sostituito da due colori finali, A e B , dai quali fino a due altri colori sono derivati ​​da miscele lineari a peso fisso. Inoltre, ogni texel nel blocco ha un indice a 2 bit che determina come selezionare uno di questi quattro colori.

Ad esempio, di seguito è riportata una sezione di 4x4 pixel dell'immagine di prova compressa con lo strumento Compressore AMD / ATI. ( Tecnicamente è tratto da una versione 512x512 dell'immagine di prova, ma perdona la mia mancanza di tempo per aggiornare gli esempi ).

Questo illustra il processo di compressione: vengono calcolati la media e l'asse principale dei colori. Viene quindi eseguito un adattamento ottimale per trovare due punti finali che "giacciono" sull'asse che, insieme alle due miscele derivate 1: 2 e 2: 1 (o in alcuni casi una fusione 50:50) di tali punti finali, che minimizza l'errore. Ogni pixel originale viene quindi mappato su uno di quei colori per produrre il risultato.

Se, come in questo caso, i colori sono ragionevolmente approssimati dall'asse principale, l'errore sarà relativamente basso. Tuttavia, se, come nel blocco 4x4 adiacente mostrato di seguito, i colori sono più diversi, l'errore sarà maggiore.

L'immagine di esempio, compressa con AMD Compressonator produce:

Poiché i colori sono determinati in modo indipendente per blocco, possono esserci discontinuità ai limiti del blocco ma, purché la risoluzione sia mantenuta sufficientemente elevata, questi artefatti del blocco possono passare inosservati:

ETC1 :
Compressione tessitura RGB Ericsson 4bpp funziona anche con blocchi 4x4 di texel ma presuppone che, proprio come YUV, l'asse principale di un insieme locale di texel sia spesso fortemente correlato con "luma". L'insieme di texel può quindi essere rappresentato solo da un colore medio e da una 'lunghezza' scalare altamente quantizzata della proiezione dei texel su quell'asse assunto.

Poiché ciò riduce i costi di archiviazione dei dati relativi, ad esempio, S3TC, consente a ETC di introdurre uno schema di partizionamento, in base al quale il blocco 4x4 è suddiviso in una coppia di sottoblocchi orizzontali 4x2 o verticali 2x4. Ognuno di questi ha il proprio colore medio. L'immagine di esempio produce: L'area intorno al becco illustra anche il partizionamento orizzontale e verticale dei blocchi 4x4.

Globale + locale

Esistono alcuni sistemi di compressione delle trame che sono un incrocio tra schemi globali e locali, come quello delle palette distribuite di Ivanov e Kuzmin o il metodo del PVRTC .

PVRTC : RGBA 4 & 2 bpp
PVRTC presume che un'immagine (in pratica, bilineare) ingrandita sia una buona approssimazione del bersaglio a piena risoluzione e che la differenza tra approssimazione e bersaglio, cioè l'immagine delta, sia localmente monocromatica, cioè ha un asse principale dominante. Inoltre, presuppone che l'asse principale locale possa essere interpolato sull'immagine.

(da fare: aggiungi immagini che mostrano la suddivisione)

La trama di esempio, compressa con PVRTC1 4bpp produce: con l'area attorno al becco: rispetto agli schemi BTC, gli artefatti del blocco vengono generalmente eliminati ma a volte può esserci un "superamento" se ci sono forti discontinuità nell'immagine sorgente, ad esempio intorno la sagoma della testa del lorichetto.

La variante 2bpp ha, naturalmente, un errore più elevato rispetto alla 4bpp (nota perdita di precisione attorno al blu, aree ad alta frequenza vicino al collo) ma probabilmente ancora ragionevolmente di qualità:

Una nota sui costi di decompressione

Sebbene gli algoritmi di compressione per gli schemi sopra descritti abbiano un costo di valutazione da moderato a elevato, gli algoritmi di decompressione, specialmente per le implementazioni hardware, sono relativamente economici. ETC1, ad esempio, richiede poco più di qualche MUX e additivi di bassa precisione; S3TC ha effettivamente leggermente più unità di addizione per eseguire il blending; e PVRTC, leggermente più di nuovo. In teoria, questi semplici schemi TC potrebbero consentire a un'architettura GPU di evitare la decompressione fino a poco prima della fase di filtraggio, massimizzando così l'efficacia delle cache interne.

Altri schemi

Altre modalità TC comuni che dovrebbero essere menzionate sono:

• ETC2 - è un superset (4bpp) di ETC1 che migliora la gestione delle regioni con distribuzioni di colore che non si allineano bene con 'luma'. Esistono anche una variante da 4 bpp che supporta l'alfa a 1 bit e un formato da 8 bpp per RGBA.

• ATC - È effettivamente una piccola variazione su S3TC .

• FXT1 (3dfx) era una variante più ambiziosa del tema S3TC .

• BC6 e BC7: un sistema basato su blocchi da 8 bpp che supporta ARGB. Oltre alle modalità HDR, queste usano un sistema di partizionamento più complesso di quello dell'ETC per tentare di modellare meglio la distribuzione del colore dell'immagine.

• PVRTC2: 2 e 4bpp ARGB. Questo introduce modalità aggiuntive tra cui una per superare i limiti con forti limiti nelle immagini.

• ASTC: Anche questo è un sistema basato su blocchi, ma è un po 'più complicato in quanto ha un gran numero di possibili dimensioni di blocchi che colpiscono una vasta gamma di bpp. Include anche funzionalità come fino a 4 aree di partizione con un generatore di partizioni pseudo-casuale e risoluzione variabile per i dati di indice e / o la precisione del colore e i modelli di colore.