Linear work flow ja gamma helvetti

[Vilperi]

Löytäisin varmaan vastauksen tähän tästä threadista tai CGtalkista mutta olen laiska  Miksi monitorit on nonlineaarisia? Eikö olisi helpompaa jos kaikki monitorit olisi yksinkertaisesti lineaarisia niin gammojen kanssa ei tarttis pelleillä?

[xcx]

Itsekin luulin aina eiliseen asti, että gamma on vain brightnessin säätöä. Kuitenkin kun luin noita No:n laittamia dokkareita niin tajusin mitä varten se oikeasti on.

3d-softa rendaa kuvat linear spacessa eli se olettaa, että media (esim. monitori) josta lopputulosta katsellaan on täydellinen. Näin ei kuitenkaan ole. Monitorit eivät näytä tummusarvoja lineaarisen tasaisesti joten kuva on monitorilla tummempi kuin pitäisi ja detailia katoaa. Gamma korjaus siis vääntää gamma arvot sopiviksi monitorille (tai jollekin muulle laitteelle). Ilman gamma korjausta kuva näyttää periaatteessa värältä ja liian tummalta.
Ilman gamma korjausta pitää valoja pistää enemmän tai niiden voimakuutta pitää nostaa, koska tummat sävyt katovat. Tästä kuitekin seuraa, että valot polttaa värit helposti puhki, koska 3d softan laskut tehdään linear spacessa. Kerosen ja minun esimerkit näyttää todella selvästi miten gamma korjaus korjaa juuri nuo tummat scenet ja tuo kuvassa olevan detailin esille. Jos kuvan brightness arvoa vain nostaisi niin noin tummat kuvat saturoituisivat todella pahasti.
Kuitenkin tekstuurit on usein jo valmiiksi gamma korjattu, joten niiden kohdalla vanha gamma korjaus on ensin otettava pois jottei sitä tehdä niille kahdesti. Lisäksi kaikki operaatiot pitäisi tehdä gamma korjaamattomaan (linear space) kuvaa, jolloin työkalut tekevät sitä mitä niiden pitäisi tehdä. Lopuksi kaiken päälle se gamma korjaus.

[xcx]

Löytäisin varmaan vastauksen tähän tästä threadista tai CGtalkista mutta olen laiska  Miksi monitorit on nonlineaarisia? Eikö olisi helpompaa jos kaikki monitorit olisi yksinkertaisesti lineaarisia niin gammojen kanssa ei tarttis pelleillä?

Koska monitorit tai mikään oikean elämän vekotin eivät ole täydellisiä. Täydellisessä maailmassa monitorit olisivat lineaarisia. Ja vaikka varmaan voitaisiin jo tehdä tarkempia ruutuja niin halutaan varmaan pysyä jossain sovitussa standardissa. Joskaan en tiedä onko tähän olemassa mitään standardia.

[kerosene]

niinkuin joku artikkeli sanoi - kyse ei ole virheesta vaan tarkoituksellisesta piirteesta

tyypillinen kuvaformaatti on RGB 8 bittia per kanava eli kolmella varilla on 256 eri mahdollista arvoa. Paletti on suhteelisen rajallinen - koska ihmissilma erottaa tummuuserot tarkemmin vahemman kirkkaissa alueissa on skaala painotettu tumman paahan.
Nain ollen tyypillisen sRGB kuvan keskitumma harmaa ei olekaan 128,128,128 vaan 186,186,186.

[No]

MentalRay Cook book pitää näyttöjen nonlineaarisuutta tarkoituksellisena ja tämäkin on järkeenkäypää kerosene:n esimerkin perusteella. Tänään tässä lueskelen lisää tiedettä.

[xcx]

Ah! Olin aivan siinä uskossa, että kyse oli siitä ettei pikselin kirkkaus mene lineaarisesti CRT:n videosingnaalin voltin kanssa tekniikan rajoitusten takia.

[xcx]

Itseasiassa syy on kummassakin

[Mental Ray cookbook]
There are several reasons why imaging systems have such a thing as gamma at all. Some of them are due to the technology in recording and displaying images, e.g. photographic film has a non-linear response curve, and so does the electron gun of a CRT monitor: the brightness of a pixel is not linear to the voltage of the video signal. Also the fact that the human visual system is more sensitive to details in the dark than to details in the bright (the response curve of the human visual system is in fact logarithmic, Weber-Fechner law) is calling for a non-linear brightness encoding, especially if you have only a few bits to encode brightness. Modern TFT monitors do not have a physical gamma but they emulate the gamma characteristics to stay compatible with existing workflows and standards.
[/Mental Ray cookbook]

[fossa]

mitäs mieltä ootte tästä?

maxin helpistä:
Note: When using the Logarithmic Exposure Control, the need for gamma correction is largely replaced. You should use either gamma correction or the Logarithmic Exposure Control but not both.

Mä oon kas käsittäny että toi "tonemappaus" korvaan ton homman, sillä exposure settingeissä saa säätää midtonesia (eli eiks se oo teoriassa sama ku gamma) sen verran että kuvasta tulee kirkkaampi. Max2008:n photographic exposuresta en tiedä, mutta uskoisin että siinä on sama toiminto.

Mut mites sitte jos tota käyttää, pitääks silti noille tekstuureille tehä se gamman poisto?

[xcx]

Hyvä kysymys. Sanois näin mitään oikeastaan tietämättä (perstuntumalta) , että texturet pitäisi silti saada ensin lineaarisiksi.

[eetu]

parit urlit lisää
http://renderwonk.com/blog/index.php/archive/adventures-with-gamma-correct-rendering/
http://www.sjbrown.co.uk/?article=gamma

ei oo helppoo

eetu.

[fossa]

Ok. Mä käsitin nyt näin:

Logarithmic exposurea käyttäessä sieltä gamma lut paneelista laittaa perus gamman ykköseen, mutta molempiin input/output bitmap hommeliin molempiin esim. se 1,8 mitä ilmesesti suositellaan.
Ja sen gamman voi säätää käsin sieltä logaritmik exposuresta.

mr Photographic exposurea käytettäessä taas sieltä gamma lut paneelista se 1,8 myös siiheen perus gammaan ja se mr photographic ekptrorue osaa ottaa sen gamman huomioon

[tayotain]

Itse työskentelen lighwavella. Itse tipautan gamman textureista image editorissa pluginilla. sen jälkeen pompsautan rendatun kuvan gamman 2.2:teen. Toimii oikeen mukavasti. Siihen löyty vielä oikeen mukava colorpicker joka kääntää automaattisesti valitun värin lineaariseksi. tämä auttaa siihen että kun nostetaan gamma 2.2:teen niin punaisesta pallosta ei tule pinkkiä. eli tuo gammahan vaikuttaa keskisävyihin eniten.

Linkkiä hieman.
on laittikselle mutta toivottavasti on apuja. Pluginissa on se hyväpuoli että voi käyttää eri icc profiileja ja voi "esikatsella" miltä kuva näyttää esim. filmi-profiililla
http://www.lightwiki.com/SG_CCTools_-_For_Color_Management_and_Linear_Workflows

[Tonttu]

Tässäkin maksullisessa LW:n renderöijässä on nyt joku tommonen nopeuttajaplugari:
http://www.kraytracing.com/wiki/Kray_plugins#Quick_Linear_Workflow_plugin