Colordepth a 24 bit non è sufficiente?

Ho notato che in gradienti molto morbidi, la colordepth a 24 bit non è sufficiente in quanto puoi vedere le transizioni del colore. Questo sporge di più nelle scene buie o nei cieli notturni.

Perché nessuno cambia la profondità di campo in due byte per canale? So che sarebbe un sacco di lavoro e un sacco di hardware dovrebbe essere rivalutato, ma lo trovo un po 'fastidioso. Non credo davvero che la tecnologia dell'hardware non sia abbastanza matura.

Allora perché nessuno lo sta facendo?

Ecco una foto di "The War Z" in cui puoi vedere cosa intendo:

Più o meno lo hai detto tu stesso: "Lo so, sarebbe un sacco di lavoro e molto hardware dovrebbe essere sostituito." Mentre la fine hardware-grafica delle cose sarebbe in realtà relativamente semplice (se costosa - il raddoppio della dimensione di tutte le trame e buffer di frame è tutt'altro che banale), l '"ecosistema" per immagini con una maggiore profondità di colore semplicemente non è a posto per tipo di estensione che rende questa una spesa utile per conto di nessuno, poiché nessun produttore di LCD si sta concentrando sul tentativo di ottenere fino a 16 bit per pixel (anche se ci sono stati alcuni esperimenti a 10BPP, che si adatta comodamente ancora un segnale RGB in un 32- bit channel).

In breve, è semplicemente troppo lavoro per quello che la maggior parte delle persone considera ancora poco guadagno. Potrebbe anche essere "un po 'fastidioso", ma quel livello di fastidio è così scarso che altri miglioramenti della qualità dell'immagine hanno avuto la priorità.

Sì, non sei la prima persona a notare questo . :) Con gli attuali rapporti di contrasto elevato, 8 bit per componente non sono sufficienti per creare una sfumatura uniforme senza bande visibili, a meno che non venga utilizzato il dithering.

L'uso di più di 8 bit per canale su un display è chiamato " deep color " dai produttori di display. Non è molto diffuso a causa di un problema con pollo e uova. Un display a colori profondi è inutile senza una scheda video in grado di produrre colori profondi e un motore di gioco che supporta il rendering a colori profondi. Allo stesso modo, non ha senso un motore di gioco o una scheda video che supporti colori profondi senza display. Quindi non c'è molto incentivo per i produttori di hardware e gli sviluppatori di giochi ad aggiungere supporto per questa tecnologia, poiché da entrambe le estremità non esiste un mercato che giustifichi il costo dello sviluppo.

Inoltre, ci sono altri modi per correggere le bande grazie alla precisione limitata a 8 bit. Come accennato in precedenza, i motori di gioco possono utilizzare il dithering per nascondere le bande.

^{(Immagine di un gatto con una tavolozza di 256 colori, senza e con retinatura. Creato dall'utente Wapcaplet di Wikipedia , utilizzato con licenza CC-By-SA 3.0 .)}

L'aggiunta di una leggera retinatura di ± 0,5 / 255 prima di scrivere il valore di pixel nel framebuffer è estremamente efficace per nascondere le strisce su gradienti morbidi ed è sostanzialmente impercettibile. Se utilizzi un motore HDR, lo fai durante la fase di modifica del toner.

Infine, come altri hanno notato, la compressione delle trame può essere una fonte più grande di artefatti simili a bande nell'immagine rispetto alla precisione a 8 bit. Questo potrebbe essere ciò che sta succedendo con il cielo in quella foto, anche se è difficile da dire: ha così tanta compressione JPEG su di esso che qualsiasi artefatto dovuto alla compressione DXT è praticamente sommerso.

Vale anche la pena notare che molti pannelli LCD non sono nemmeno 8 bit per canale. Quelli più economici tendono a usare meno bit e utilizzare vari trucchi per cercare di nasconderlo. Ad esempio, potrebbero passare rapidamente tra due colori adiacenti per rappresentare quello in mezzo. http://www.anandtech.com/show/1557/3

Ci sono alcuni dettagli su come DXGI supporta 10 bit per canale e più luminoso dei colori bianchi su http://msdn.microsoft.com/en-us/library/windows/desktop/jj635732%28v=vs.85%29.aspx

D3D ha anche supportato più di 8 bit per canale per anni. Non c'è nulla che possa impedire a uno sviluppatore di fare un dithering da 16 bit per canale a 8 bit se pensano che sia una buona idea.

Naturalmente ciò non sarà di grande aiuto se i dati di origine (trama, ecc.) Sono solo 8 bit (o più probabilmente DXT1, che in realtà è 5-6-5 bit per canale). Credo che sia quello che succede con il cielo in quello screenshot (una sfocatura gaussiana di 8 bpp lo rende molto più fluido per me) ma è difficile esserne certi.

La risposta di Steven Stadnicki è corretta: i giochi usano raramente trame di precisione più elevata perché richiedono troppa memoria di trama e, di conseguenza, troppa larghezza di banda di memoria quando campionano la trama in un pixel shader. Tuttavia, ci sono soluzioni che non richiedono grandi trame. (Pubblicherei questo come commento, ma è troppo lungo.)

Homeworld risolve questo problema codificando l'immagine del cielo come gradienti di vertice . Questa tecnica funziona alla grande per immagini di grandi dimensioni a bassa frequenza (ad es. Gradienti lisci) - come i cieli - in cui la trama copre un numero enorme di pixel di gioco.

Un'altra possibile soluzione è applicare la normalizzazione dell'istogramma all'immagine del cielo. Se i dati di trama si trovano in un intervallo di valori ristretto, come un cielo notturno scuro, la maggior parte dei bit in ciascun canale di colore non trasporta dati utili. Invece, fai questo:

• Crea la trama originale in un formato a 16 bit, come un TIFF a 16 bit.
• Quando prepari le trame per il motore di gioco, trova il pixel più scuro presente nell'immagine e tieni traccia di questo come offset. Supponiamo che questo valore di pixel sia 0,1 in un intervallo possibile di 0-1.
• Quindi, trova il pixel più luminoso e sottrai il pixel più scuro per ottenere l'intervallo di valori nell'immagine. Quindi, se il pixel più luminoso è ancora piuttosto scuro - diciamo 0.35 - l'intervallo è solo 0,35 - 0,1 = 0,25. Nell'immagine è presente solo il 25% dell'intervallo di valori.
• Genera la tua trama di gioco compressa in DXT / BC . Sottrai il valore più scuro da ogni pixel e moltiplica per utilizzare l'intera gamma di colori. Nel calcolo di esempio sottraggiamo il nostro valore scuro di 0,1 e, poiché è presente solo il 25% dell'intervallo di valori disponibile, moltiplichiamo ogni valore di pixel per 4x per creare la trama del gioco. Assicurati di fare tutto questo prima di quantizzare l'immagine sorgente a 16 bit fino all'ingresso 8bpp al compressore DXT. L'immagine di output ora utilizzerà l'intero intervallo di valori supportati dal formato di gioco. Stiamo allocando tutti i nostri bit per rappresentare i valori effettivamente presenti nell'immagine.
• Memorizza da qualche parte l'offset del valore scuro (0,1) e l'intervallo (0,25) nei metadati. Passale come input al tuo pixel shader.
• Nel codice pixel shader, campiona la tua texture spostata ed espansa, convertila in un valore float e quindi esegui una moltiplicazione / aggiunta per ripristinare il valore del colore originale. In altre parole, moltiplicare per 0,25 e aggiungere 0,1 per ripristinare il valore memorizzato nell'immagine di origine.

Assicurarsi che il codice shader sia gamma corretto . Se esegui la matematica (illuminazione e post-elaborazione) su campioni di trama che non vengono convertiti dallo spazio colore sRGB allo spazio lineare, vedrai artefatti di bande come quello che descrivi. La correzione gamma è stata creata per aiutare ad alleviare questo tipo di problema assegnando più bit a valori scuri in cui i tuoi occhi sono più sensibili alle variazioni di valore. Ma puoi facilmente rompere le cose se non tieni conto della correzione gamma durante il calcolo, ad esempio illuminazione, esposizione o post-elaborazione FX. Le domande frequenti sulla gamma sono utili.

24 bit non è abbastanza, ma è molto più comune che problemi come questo siano causati da algoritmi di compressione delle immagini, aliasing o altri artefatti digitali. Inoltre, non trascurare il ruolo della tecnologia di visualizzazione: indipendentemente dagli ingressi digitali, il display potrebbe non produrre i passaggi appropriati nella luminosità effettiva.