6

Sto lavorando su uno strumento di visualizzazione dati utilizzando OpenGL, e lo spazio colore LAB è lo spazio colore più comprensibile per la visualizzazione dei dati ho a che fare con (3 assi di dati vengono mappati sui 3 assi dello spazio colore) . Esiste un algoritmo veloce (ad esempio, non un intero non esponenziale, adatto per l'esecuzione in uno shader) per la conversione approssimativa dei valori LAB in e da valori RGB?Algoritmo approssimativo veloce per la conversione RGB/LAB?

+0

Spero che ci sia, ma dubito che esista. La parte della radice del cubo sarà difficile da simulare. Forse usando l'interpolazione lineare tra un piccolo numero di punti equivalenti? –

+0

Bene, ecco una sottoregione: i valori specificati in, ad es. OpenGL in modo tale che i valori RGB siano lineari (gamma applicata automaticamente) o no (compensazione gamma esplicita)? Se sono lineari, ciò significherebbe che il passo XYZ-> RGB richiede solo una moltiplicazione di matrice, corretto? –

risposta

0

Se facendo il calcolo di conversione reale in uno shader è troppo complesso/costoso, è sempre possibile utilizzare una tabella di ricerca. Poiché entrambi gli spazi colore hanno 3 componenti, è possibile utilizzare una trama RGB 3D per rappresentare la tabella di ricerca.

Usando una texture 3D potrebbe suonare come un sacco di spese generali. Poiché 8 bit/componente viene spesso utilizzato per rappresentare i colori in OpenGL, è necessaria una trama 3D 256x256x256. A 4 byte/texel, si tratta di una trama di 64 MByte, che non è scandalosa, ma molto sostanziale.

Tuttavia, a seconda di come lisciare i valori nella tabella di traduzione sono, si potrebbe essere in grado di cavarsela con una risoluzione più bassa. Tenere presente che il campionamento della trama utilizza l'interpolazione lineare. Se l'interpolazione lineare a tratti è abbastanza buona con una determinata risoluzione di base della tabella di ricerca, è possibile ridurne notevolmente le dimensioni.

Se andate in questa direzione e non potete permettervi di usare 64 MB per la LUT, dovrete giocare con la dimensione della LUT e fare un possibile compromesso tra dimensione/prestazioni e qualità.

+1

Non sono sicuro di seguire i tuoi calcoli. Se hai 8 * bit * per componente, il tuo tavolo non deve essere 256x256x256? –

+0

@MarkRansom Argh, sì, lo so. Sembrava un po 'troppo bello per essere vero. –

+0

@MarkRansom Ok, aggiornato. Potrebbe sembrare leggermente meno attraente ora, ma almeno spero sia corretto. Grazie per averlo indicato. –

Problemi correlati