Per la matematica dello shader, perché RGB lineare dovrebbe mantenere la gamma di sRGB?

sRGB è spesso contrastato con "RGB lineare".

• Le immagini vengono archiviate su disco e passate ai display in sRGB, che ha un'intensità percettiva approssimativamente uniforme.
• La matematica dello shader viene eseguita in RGB lineare, che è fisicamente uniforme in intensità.
• È possibile applicare la correzione gamma per la conversione tra i due.

Ora, sRGB ha uno standard che specifica colorimetricamente la sua gamma, dicendo esattamente dove si trovano il rosso, il verde, il blu e il bianco. Ma non esiste uno standard corrispondente solo per "RGB lineare". Si può dire che qualsiasi triangolo su un diagramma di cromaticità sia lineare e, in effetti, ci sono diverse gamme ben note tra cui scegliere:

In pratica, quando diciamo "RGB lineare", intendiamo "sRGB senza la correzione gamma". (Questo è implicitamente ciò che stiamo facendo quando applichiamo la correzione gamma sRGB come fase finale di post-elaborazione, ma ignoriamo gli spazi colore per il resto della pipeline di rendering.)

Ma perché quella gamma RGB è quella corretta da utilizzare per i calcoli di interpolazione e illuminazione? Sembra arbitrario. Semmai, non vorremmo usare la gamma più ampia possibile per i calcoli interni e quindi tagliare o ridimensionare i colori alla gamma del dispositivo di output alla fine?

L'illuminazione RGB sarà approssimativa, non importa quale sia, quindi non importa quale gamma scegliamo e potremmo anche scegliere quella più vicina a ciò che il display supporta nativamente? È solo negligenza? O i calcoli in queste diverse gamme in realtà producono esattamente gli stessi risultati, in qualche modo?

Parlare di RGB lineare deve essere evitato perché non ti dice nulla sulle caratteristiche intrinseche del colore dello spazio RGB, ovvero Primarie, Whitepoint e Color Component Transfer Functions. Alcuni anni fa, supponendo che sRGB fosse mediocre ma al giorno d'oggi con DCI-P3 e BT.2020 molto comuni, bisogna escluderlo.

La gamma ideale per il rendering è quella che minimizzerà gli errori rispetto a un riferimento del mondo reale o più convenientemente un rendering spettrale di verità di base. La prima cosa da asporto da questa frase è che i vari colori RGB non sono equivalenti e non produrranno risultati simili.

Si potrebbe pensare che eseguendo due rendering con gli stessi colori di base ma uno in cui sono codificati con sRGB / BT.709 e l'altro in cui sono codificati con DCI-P3 e quindi convertendo le due immagini risultanti in ad esempio ACES2065-1 produce le stesse immagini ma non è così. Alcune operazioni matematiche a causa della natura dell'algebra e delle matrici lineari dipendono dai dati primari del colore dello spazio RGB, ovvero dalla base dei colori. Le stesse operazioni eseguite in diversi colori RGB produrranno valori di tristimolo diversi una volta riconvertiti nello spazio colore CIE XYZ. Ad esempio, le operazioni di moltiplicazione, divisione e potenza dipendono dai primari del colore dello spazio RGB, mentre l'addizione e la sottrazione no.

Questa immagine illustra l'effetto della moltiplicazione di vari colori da soli in diversi colori RGB: i colori risultanti sono diversi. I vari campioni vengono generati come segue: 3 valori casuali di spazio colore sRGB vengono raccolti e convertiti nei tre spazi colore RGB studiati, vengono esponenziati, convertiti nuovamente in spazio colore sRGB, tracciati nel diagramma di cromaticità CIE 1931 a sinistra e visualizzati come campioni sul giusto.

Test e ricerche condotte da Ward ed Eydelberg-Vileshin (2002) , Langlands e Mansencal (2014) e Mansencal (2014) hanno mostrato che le gamme con primarie più vicine al locus spettrale, ovvero primarie spettralmente acute, tendono a minimizzare gli errori rispetto al terreno spettrale la verità rende.

Ecco un'immagine che ho recentemente reso con Mitsuba per riconvalidare le nostre scoperte con Anders:

Questi sono rendering della stessa scena usando primari BT.709 (prima fila), 47 bin spettrali (seconda fila), primari BT.2020 (terza fila), meno spettrali BT.709 primari rende i residui (quarta fila), meno BT .2020 primarie rende i residui (quinta fila). L'ultima riga mostra le immagini composite assemblate con tre strisce verticali rispettivamente dei rendering primari BT.709, primari spettrali e BT.2020. L'illuminazione diretta tende a corrispondere tra i rendering. Le aree che mostrano l'effetto di più rimbalzi di luce, ad esempio il soffitto, nei rendering delle primarie BT.709 e BT.2020 tendono a mostrare una maggiore saturazione, specialmente nei rendering delle primarie BT.709 o una leggera perdita di energia, specialmente nella BT .2020 render. Escludendo gli outlier, ad es. La sorgente di luce visibile, l'RMSE con il rendering spettrale sono 0,0083e0,0116 per il rendering rispettivamente delle primarie BT.2020 e delle primarie BT.709.

Ora non significa che funzioneranno sempre meglio, e si potrebbe essere in grado di produrre esempi che mostreranno una propensione verso BT.709 / sRGB. L'aspetto principale è che i rendering RGB non possono eguagliare i rendering spettrali e le gamme ampie e nitide tendono a funzionare meglio. Per quanto riguarda la scelta di uno spazio colore di rendering, ne sceglierei uno con una vasta gamma che comprende la gamma Pointer e DCI-P3, BT.2020 o ACEScg sono candidati eccellenti per questo.

In pratica, quando diciamo "RGB lineare", intendiamo "sRGB senza la correzione gamma".

Sarebbe più corretto affermare che esiste lo "spazio colore sRGB" e lo "spazio colore sRGB linearizzato", con la definizione di specifica sRGB la conversione da uno all'altro.

Sì, ci sono infiniti spazi colore "RGB lineari". Ma la cosa che tutti questi spazi colore "RGB lineari" hanno in comune è che sono lineari . Ciò significa che, se raddoppi il valore di qualsiasi componente, raddoppi l'intensità della luce che il componente rappresenta. Questo è essenzialmente ciò che significa essere "lineare": esiste una mappatura lineare tra i valori di colore e l'intensità risultante di quel colore chiaro.

Questo è importante perché le equazioni di illuminazione non funzionano se i valori di colore non si associano linearmente alle intensità di luce. Ma alle equazioni non importa quale spazio colore lineare usi; devi solo sceglierne uno.

Pertanto lo spazio colore sRGB linearizzato non è più corretto di uno spazio colore Adobe RGB linearizzato o di uno spazio colore CMYK SWOP linearizzato. Ciò che conta sono esattamente due cose:

1. Lo spazio colore rappresenta una mappatura lineare di valori per intensità di luce.
2. Lo spazio colore scelto viene costantemente utilizzato nell'equazione dell'illuminazione. Cioè, tutti i colori usati nell'equazione dell'illuminazione provengono dallo stesso spazio colore (lineare).

L'illuminazione RGB sarà approssimativa a prescindere da cosa, quindi non importa quale gamma scegliamo e potremmo anche scegliere quella più vicina a ciò che il display supporta nativamente?

Questo, e il fatto che la conversione sRGB è integrata nell'hardware in questi giorni, mentre altre conversioni di spazio colore spesso non lo sono. Quindi, se vuoi usare uno spazio cromatico Adobe RGB linearizzato, devi fare molto lavoro nei tuoi shader per linearizzare i valori di texel ed eseguire correttamente l'interpolazione bilineare / trilineare su di essi (che deve essere eseguita dopo la linearizzazione) prima ancora di poter applicare li all'equazione dell'illuminazione. E poi devi fare la conversione da Adobe RGB linearizzato a sRGB linearizzato, in modo da poter scrivere su un'immagine framebuffer sRGB per la visualizzazione.

Oppure puoi semplicemente usare sRGB linearizzato ovunque e avere prestazioni. Quest'ultimo tende a vincere.

Ci sono due lati del perché sRGB in particolare. Per le immagini di input non HDR, si sostiene che si dovrebbe supporre che siano compresse in sRGB (se questa affermazione è accurata è una storia diversa). Quindi, prima di poter eseguire qualsiasi operazione matematica lineare su di essi, è necessario decomprimerli da sRGB. È anche possibile che un'immagine sia stata acquisita e compressa in una rappresentazione diversa che non sia sRGB, nel qual caso è necessario decomprimere quella rappresentazione specifica. In ogni caso, la codifica implica una certa gamma a cui l'immagine di input non sfuggirà mai (perché le immagini archiviate in sRGB sono in genere troncate a 8 bit per canale), ma la matematica dello shader non deve rimanere in quella gamma dopo l'input l'immagine è decompressa. Ma alla fine devi considerare il display.

Se hai un'immagine ed è tempo di visualizzarla, la codifichi in una rappresentazione richiesta dal dispositivo di visualizzazione. I CRT hanno scelto sRGB, quindi gli LCD hanno emulato questo, quindi la compressione sRGB per la visualizzazione del monitor è stata la scelta comune negli ultimi decenni e che ha limitato l'output a rimanere all'interno della gamma sRGB, altrimenti si verificherà il clipping. I display a portata più ampia non devono attenersi a quella gamma esatta.

(Penso che la base per l'affermazione che le immagini create dall'uomo siano codificate in sRGB sia perché si presume che quelle immagini siano state create su schermi sRGB)

Quindi ora puoi probabilmente capire perché sRGB in particolare era supportato nell'hardware per input matematici di shader e visualizzazione di immagini. È il caso comune. Inoltre, ha buoni meriti per ridurre gli artefatti di bande cromatiche percettive, quindi è un buon modo per comprimere i colori in 8 bit e mantenerli plausibili per l'uomo.

Se si consentono valori al di fuori dell'intervallo 0..1, quindi anche con le primarie abbastanza limitate di sRGB, è ancora possibile rivolgersi all'intera gamma visiva umana. Pertanto, per la memorizzazione di valori di colore chiaro in virgola mobile non dovrebbe importare troppo quali primari si utilizzano. Tuttavia, fare qualsiasi tipo di matematica moltiplicativa diventa un po 'strano, poiché le coordinate arbitrarie delle primarie fungono da "perno" del ridimensionamento. Le primarie di sRGB sono generalmente utilizzate perché tradizionalmente i tuoi dati di input sono codificati in sRGB e il display di output in uscita è sRGB o rec709 ... Con rec2020, la metà di ciò è cambiata, ma per ora, la maggior parte dei tuoi dati di input è probabilmente ancora codificata in sRGB, quindi usando le stesse primarie della tua memoria sono solo l'opzione più semplice.