„Számítógépes grafika házi feladat tutorial” változatai közötti eltérés

Eddig a képalkotáskor a színeknek a (0, 1) tartományon kívül eső részét levágtuk. Ez nagyon sok esetben nem túl valósághű eredményhez vezet. Például vegyünk két 20 W-os izzót és világítsunk meg vele egy kockát.  

 

Az eddigi módszereinkkel ez így néz ki:

 

A kép baloldala jól néz ki, van két egészen hihető árnyékunk. Maga a kocka is egész jó. Viszont a képnek szinte a teljes jobb oldala kiégett, és minden ugyan olyan fehér, ordít róla, hogy mű. És ezek csak 2 db 20 W-os izzó...

 

Vegyünk két 50 W-os izzót:

 

A kocka még mindig jól néz ki. Ellenben itt már árnyékok is kiégtek, és az árnyékok nagy része ugyan olyan fényes, mint az, ami közvetlenül meg van világítva. És ezek még mindig teljesen hétköznapi értékek, két db 50 W-os izzó... Ha ez nem megy, akkor a Nappal mit kezdjünk?

 

Egy megoldás lehetne, hogy mindent sokkal sötétebbre veszünk, úgy, hogy a Nap fénye legyen a teljesen fehér. Annál világosabbal nem nagyon szoktunk dolgozni. Igen ám, de az emberi szem egy sötét szobában se teljesen vak, ha hihető képet akarunk, akkor egy olyan algoritmus kéne, ami ilyen körülmények között is élvezhető képet ad.

 

A megoldás az, hogy ne lineáris színskálát használjuk. Ez azt jelenti, hogy pl. kétszer akkora fényerősségű képponthoz ne kétszer olyan fényes pixelt rajzoljunk ki, hanem csak egy picivel világosabbat. Például használjuk logaritmikus skálát, ahol ha egy fényerősség értékét négyzetre emeljük, akkor kétszer olyan fényes pixelt rajzolunk hozzá. Ez persze csak 1-nél nagyobb fényerősségekre működik, és ez mindig véges tartományt eredményez. Olyan függvény kéne, ami a (0, végtelen) tartományt (ún. High Dynamic Range - HDR) a (0, 1) tartományra (Low Dynamic Range - LDR) képzli le, de úgy, hogy még a (0, 1) tartománybeli értékekből is élvezhető képet állítson elő. A HDR színből LDR szín előállítását tonemappingnek hívjuk.

Egy lehetséges megoldás a Reinhard operátor. Előadáson ez szokott szerepelni.

 

Először is kell számolnunk az adott fénynek a luminanciáját (jele: Y).

* Ez azt adja meg, hogy az adott fény az emberi szem számára mennyire látszódik fényesnek.

* A látható spektrum szélén lévő színek (pl a kék és a piros) adott fényerősség mellet nem látszanak nagyon fényesnek. Viszont a spektrum közepén lévő színek, főleg a zöld, ugyan akkora fényerősség mellett, mint a többi szín, sokkal világosabbnak látszik.

 

A kísérletileg meghatározott képlet, ami az érzékelt fényerősséget meghatározza: <code>Y = 0.2126f*r + 0.7152f*g + 0.0722f*b</code>

 

Az új luminancia értéke: <code>Y' = Y / (Y + 1);</code>

 

Az új szín pedig: color' = <code>color * Y' / Y;</code>

 

Az új szín luminanciája garantáltan a (0, 1) tartományba esik, de szín komponenseire ez nem feltétlen igaz. Pl: Color(0, 0, 10) -> Color(0, 0, 4.1928). Ebből következik, hogy az eredményt továbbra is szaturálni kell. Ez igazándiból nem zavaró. Nagyon ritkán okoz különbséget, és akkor se feltűnő.

 

Az eredmény viszont lényegesen sötétebb lesz mint az eredeti kép.

 

Például 2 db 50 W-os izzó esetén:

Nagyon fényes képek élvezhetőségén a Reinhard operator nagyon sokat javít. Viszont az alapból sötét képeken csak tovább ront.

 

Például két db 5 W-os izzó esetén:

A Reinhard operátor a semminél jobb, de nem az igazi.

 

Az egyik legszebb tonemap, az az a leképezés, amit Kodak filmek használnak. Ki gondolta volna, hogy Kodak ért ahhoz, hogy hogyan kell szép képet csinálni... Az algoritmus, ami ezt leutánozza a "filmic tonemap" nevet kapta, az eredetére utalva.

 

A pontosan algoritmus lassú, és bonyolult, egy logaritmus képzésen alapul, de 3 texture lookup is van benne.

De Jim Hejl (az EA games egyik fejlesztője) talált hozzá egy nagyon egyszerű, de meglepően pontos közelítést.

Először is, WTF???? Nyugi, én se ismerek ismerek olyan embert, aki értené, hogy ez miért működik. Ennek a "random képletnek" egy apró szépséghibája, hogy sRGB színtérbe állítja elő a színt, viszont nekünk sima RBG színt kell adnunk az OpenGL-nek, ezért az eredményt komponensenként 2.2-edik hatványra kell emelnünk, hogy használni tudjuk. De legalább az eredményt szaturáni már nem kell.