Zakaj 32bpp ni dovolj

• Marko Dolenc :: 22. nov 2001

Verjamem, da je marsikdo precej debelo pogledal, ko je prebral naslov tega članka, pa nič zato. Še nedolgo tega smo po svetovnih forumih lahko prebirali žolčne razprave o tem, da med 16 in 32bpp sploh ni razlike. Ustvarila sta se dva tabora, ki se nista preveč lepo gledala in na vse mogoče načine skušala dokazati svoj prav. Kakšna je torej dejansko razlika med 16 in 32bpp ter zakaj celo 32bpp že skoraj ni več dovolj?

Nekaj teorije o barvah

Barve na računalniškem zaslonu so sestavljene iz treh komponent: rdeče, zelene in modre (RGB). Obstaja pa še četrta komponenta (alpha), ki pa je za opazovalca povsem nevidna in se uporablja izključno pri renderiranju za določanje prosojnosti, osvetljenosti in podobne trike. Vsak kanal ima lahko vrednost od 0.0 do 1.0.

Človeško oko je sposobno razpoznati okoli štiri milijone različnih barv, kar je približno 2²² (se še kdo sprašuje zakaj je 3dfx trdil da njihov post filter dvigne barvno globino na 22bpp? ;)). S tega stališča je 2¹⁶ (16bpp) premalo, 2²⁴ (24bpp) nekako ravno prav, 2³² (32bpp) pa že bistveno preveč. Vendar to ni čisto tako...

Barve v pomnilniku

V računalniški pomnilnik lahko zapisujemo le bite in ne tudi decimalnih vrednosti. Ko torej rečemo, da imamo 16bitne barve to običajno pomeni, da imamo 5 bitov za rdečo, 6 za zeleno in 5 za modro. Poimenovanje formata je precej samoumnevno - R5G6B5. Hitro tudi opazimo, da je za zeleno na voljo kar šest bitov, kar pa tudi ni naklučje, saj človeško oko precej bolje zaznava zelene odtenke. Posledično to pomeni, da imamo na zaslonu lahko 32 odtenkov (2⁵) rdeče in modre, ter 64 odtenkov (2⁶) zelene. Te odtenke se linearno razporedi na celotno območje barve od 0.0 do 1.0.

Za 16bpp načinom pride 24bpp način, ki pa je že praktično izginil. Razlogi za to so predvsem v predpomnilnikih grafičnih kartic, ki so optimizirani za delo z "lepimi" števili (potence števila 2). Poleg tega pa razen nekaj manjše porabe pomnilnika ne nudi nobene prednosti pred 32bpp načinom.

32bpp način nudi 8 bitov za vsako od treh osnovnih barv, poleg tega pa vsebuje še 8 bitov za alpha komponento. 32-bitni barvni način pa omogoča tudi izbiro 32-bitnega Z-bufferja (globinska slika), ki nudi višjo globinsko natančnost ter 8 bitni stencil buffer (ki se uporablja za sence in še marsikaj). Vendar se 32 bitni Z-buffer uveljavlja šele sedaj, zato v času bojev med 16bpp in 32bpp praktično ni bil argumenta v prid uporabi 32bpp.

Zgodba bi se lahko pri 32bpp končala, saj imamo 2²⁴ različnih barv, kar je več kot dovolj za človeško oko zraven pa še 8 bitov za alpha kanal, kar je tudi nekako dovolj. Torej, zakaj se zgodba tukaj še ne konča?

Matematika in renderiranje

Kot smo spoznali že v zgornjih dveh poglavjih, imamo opravka z dvema vrstama števil. Decimalna števila so zelo pripravna za računanje in grafični čipi dejansko delajo z pravimi decimalnimi števili v območju 0.0 do 1.0 za vsako barvno komponento posebej. V računalniški pomnilnik pa lahko zapisujemo le cela števila zato jih moramo pač iz decimalne vrednosti narediti celo število. To naredimo zelo enostavno:

KomponentaVPomnilniku = Komponenta * 2ŠteviloBitovZaKomponento

. Če še vedno ostanejo kakšne decimalke, jih enostavno porežemo in v osnovi tukaj ne izgubimo veliko natančnosti.

Vendar pa se današnji pogoni, kljub temu, da so grafične kartice sposobne izrisati po več tekstur v enem prehodu, vedno bolj in bolj naslanjajo na takoimenovani multi-pass (ko mora kartica za vsako piko narediti po več prehodov). Igre kot so Unreal, Quake 3,... že danes potrebujejo tudi do 8 (!!) nivojev, kar lahko predstavlja problem (tako pri hitrosti kot tudi pri kvaliteti). Če hoče neka igra tako narediti

a*b*c*d

, kjer je recimo a=0.75, b=0.85, c=0.55, d=0.9 bo rezultat izgledal tako:

Barva = a*b*c*d = 0.75 * 0.85 * 0.55 * 0.9 Barva = 0.3155625	Barva = 0.11000 * 0.11011 * 0.10001 * 0.11100 Barva = 0.25	Barva = 0.11000000 * 0.11011001 * 0.10001100 * 0.11100110 Barva = 0.29296875
Lep izračun	Rezultat grafične kartice pri 16bpp	Rezultat grafične kartice pri 32bpp

Že v zgornji tabeli se lepo vidi,da rezultata pri 16bpp in 32bpp odstopata za 0.04296875 kar znese 11 odtenkov določene barve! V najnovejših pogonih (Doom 3) pa bo problem še večji. Primer malo bolj komplicirane formule za per-pixel lighting:

Diffuse = A * Sself * (N' dotProduct L) * C * F * D
 Diffuse - osvetlitev
 A - koeficient razdalje
 Sself - koeficient za senčenje
 N' - normala (vektor odboja svetlobe)
 L - vektor proti usmerjen proti luči
 C - barva luči
 F - barvni filter (za realiziranje usmerjenih luči (spot lights) in podobno)
 D - barva materiala

Zgornja formula pa je dejansko samo en del izračuna... Zraven moramo upoštevati še formulo za "specular highlights" (odboji svetlobe), ki je precej podobna zgornji, ter dejstvo da moramo vse to narediti za vsako luč posebej. GeForce2 potrebuje samo za zgornjo formulo 3 prehode. GeForce3 in Radeon 2 precej zmanjšata število teh prehodov, vendar še vedno prihaja do precejšnjih izgub.

Kaj sledi

DirectX 8.1 že podpira nov format za teksture A2R10G10B10, ki delno omili problem, vendar pa nudi premajhno globino za alpha komponento. DirectX 9 pa bo dejansko ta problem odpravil, saj bodo na voljo kar 64bpp in celo 128bpp formati, ki bodo omogočili da se bo vsaka komponenta zapisala s 16 ali pa kar z 32 biti.

Zaključek

Tako! Upam, da je sedaj bolj jasno v čem je največja razlika med 16bpp in 32bpp, ter da nebo kdo preveč debelo pogledal, ko bo prišel ven DirectX 9.0 z svojimi 128bpp. Pa če sem se kje pri računanju za kakšen bit uštel, me ne preveč grdo gledati ;).