Lebegőpontos? Francokat! Lebegőpontatlan!

A lebegőpontos számítás nem azért bonyolult és mellőzi az intuitív megjelenést, hogy csak az okos emberek tudjanak vele érvényesülni, hanem mert ez a számítógép architektúrákra van optimizálva (vagy fordítva). De nem is lehet annyira egyszerű dolog, hogyha emiatt már az Ariane 501-nek is sikerült lezuhanni (not enough space to reach the space) 96-ban (bad rocket science). Szóval ez nem olyan matek-tudás, mint pl. a legnagyobb kétjegyű prímszám ismerete, amivel még országot is lehet vezetni. 

A 32 bites kép sok mindent jelenthet, kontextusfüggő, hogy a 24 bites RGB + egy Alfa csatornát jelöl, vagy például a GIMP 32 bites integerjét, vagy micsodát. A Photoshop 32 bitese viszont, és ezt Chris Cox írta egy fórumban, lebegőpontos, egyszeres pontosságú ábrázolás. Nem könnyű felfejteni, hogy pontosan milyen lebegőpontos is lehet, amit a PS használ, de ha az egyik legelterjedtebb 32 bites lebegőpontosból indulunk ki, akkor irgalmatlanul hatalmas számot lehet így elkódolni. 38 darab nullát ha le tudsz képzelni. Na akkorát. Ennek viszont ára van, ugyanis nem minden számot tud ebből a sokszáz-decillióból pontosan elkódolni. Van amit igen, és van amit nem. IEEE754 calculator, ha ki akarod próbálni. Mondjuk adj össze lebegőpontosan, binárissá alakított számokat: 0,1+0,2. Na, mi jött ki? Látod? Ennyit se tud. Viszont ezt irtó gyorsan és nagyon sok tizedesjegyre, pontatlanul megcsinálja. Persze, azért a specifikáció szerint 7 tizedesig elég jól adja. (itt meg egy konverter az IEEE754-hez, itt meg egy magyarázó videó).

De mindebből mit látunk? A Photoshop 32 bites lebegőpontos megjelenítése az Info palettán csupán három tized pontosságú. Plusz egy tized pontosság nyerhető, ha a Color Picker ablakot használjuk. Ez tízezres nagyságrendben jeleníthetné meg a csatorna értékét, ami nem kevés, de a 16 bites kép 65.536, jaj bocsánat 32.768 felbontásához képest kicsit vérszegénynek tűnhet. 

A 32-bites Color Picker ablakban a 32-bites adatok 0.0000 és 20.0000 között vehetnek fel értéket négy tizedes pontossággal, ami 200 000 különálló érték csatornánként. Lenne. De hiába írunk be egy konkrét értéket, miután becsukjuk az ablakot és visszanyitjuk, más érték lesz benne, ami gyakorlatilag már a második tizedesben is eltér. Például ha beírod, hogy 20.0000 az ugyanannyi marad, de attól lefele 19.9037-ig minden érték 19.9037 lesz miután becsukod és újra nyitod a Color Pickert, a beírt 19.9036-ot meg 19.7662-nek jegyzi meg, szóval gyakorlatilag még az egy tizedes pontosság sincs meg ebben az ábrázolásban. Most nem állunk neki feltérképezni, ez miért van így.

Az Intensity csúszka 0 állásánál egy csatorna maximum 1.0000 értéket vehet fel, ez 255-nek felel meg a megszokott 8 bites tartományban. 

Minden-szín-kép (netről letölthető, ez csak egy screencapture ne ezt használd),
A minden-szín-képen mind a 16,777,216 szín megtalálható (minden pixel más színű)

Ezzel a képpel csicskáztatjuk meg a PS-t. Ebben minden egyes pixel más színű, amennyiben ezt 24 bites RGB-nek nézzük.  De hogyha 32 bitesre konvertáljuk, nyilván több szín nem lesz benne, de kevesebb se kellene. Márpedig kevesebb lesz. 

Baloldalt a kép 24 bites (RGB 8bites) négy alig eltérő sárga pixelének zöld csatornájának értéke a 8 bites Info palettán: 255 - 254-253 -252. Jobbra, ugyanennek a képnek 32 bites megjelenítésen már kicsit mást mutat ugyanezekre a pixelekre: 1.000 - 0.996 - 0.992 - 0.9888. 

Ha a képet áttesszük 32 bites lebegőpontosra, akkor ugyanezek a pixelek így fognak kinézni a 8 ás 32 bites Info palettán:

8 bites megjelenítésen 255-253-250-248, 32 bites ábrázolásban 1.000 - 0.991 - 0.982 - 0.973. Teljes káosz, és ami a legborzasztóbb, nem tudjuk ennek egyáltalán a profilokhoz van e köze, vagy micsodához. Becsületére legyen mondva, 32 bitből 8-ra visszaállítva megkapjuk a kiindulási képet, ebből arra gondolunk, hogy jól számol a motorháztető alatt, csak megjeleníteni nem képes a 32 bites ábrázolásban az Info palettán.

De próbálhatunk mást is, írj be egy (8)255-ös pirosat 0 Intensity mellett. (32)1.0000 értéke lesz. De ha ennek lehúzod az Intensityjét -20-ra, akkor (32)0.0000 lesz az értéke és (8)255 marad. Csukd le az ablakot és nyisd vissza. Az érték (32)0.0000, (8)191, és az Intensity -19.58. Jó mi? Ugyanezt +20 intensityvel, becsuk, kinyit, és az érték 20.0000 R191 mellett. Megpróbáltuk középértékekkel is, semmiféle logikát nem fedeztünk fel a dologban. 

Tehát, ha valami extrém felhasználási igény folytán pontosan akarjuk tudni, milyen értékeink vannak a 32 bites fileban, akkor érdemesebb GIMP-et használni. Felül a 16 és 32 bites egész-szám, alul pedig a 16 és 32 bites lebegőpontos infó palettája látszik.

A GIMP-ben ugyanis a csatornákat el lehet kódolni 8/16/32 biten egész számosan, de van 16/32/64 bites lebegőpontos is. További érdekesség hogy a 16 bit integer, az valóban annyi, és nem fele, mint a Photoshopban, és a lebegőpontosakat itt hat tizedesig mutatja (16 és 32 bites esetén is egyaránt). Igaz, hogy itt még annyira se tudunk töredék értékeket beállítani, mint Photoshopban, ugyanis a GIMP színkeverőjében 32 bites lebegőpontosan is csak 0-255 között tudunk értékeket megadni. 

Csináltunk egy tesztsorozatot is a PS 16-32 bites színmélységével. 

1. egy sRGB 16 bites képből 32 bitest mentettünk. Azt visszaállítottuk 16 bitesre Exp. 0 Gamma 1 értékkel, így az eredeti 16 bitessel nincs difference, vagyis a lebegőpontosba alakítás és visszaalakítás során a 16 bites kép tökéletesen megőrizte az értékeket, nem szenvedett el kerekítésből adódó hibákat.

2. ez akkor is így van, ha PS-ben, alul az exposure csúszkát elbabráljuk, tehát az a csúszka valóban csak a nézetet, a 32 bites tartomány megjelenítését befolyásolja, a kép adataira nincs hatással.

3. a 32 bitesre konvertált képnek Adjustmentben adunk +2EV értéket, ha a 16 bitesre (vissza)alakításnál -2EV-vel mentjük, akkor nem lesz különbség az eredeti 16 bitessel.

4. a gamma módosítgatásával visszamentéskor sehogy se sikerül korrigálni a +2EV értéket. (mindig különbség lesz az eredeti 16 bitessel összevillantva. 

5. legyen mondjuk egy színünk: G255, 0 intenzitással (középen). jobbra balra az intenzitásokat babráljuk -20 -15 -10 -5 -3 -2 -1  0  +1 +2 +3 +5 +10 +15 +20.  

Így néz ki a (lineáris) 32 bites módban (nyilván ez egy gammás 8 bites monitoron semmit sem jelent). 

És így néz ki mindenféle Exposure és Gamma állítgatással 8 bitesen:

Ezek pedig a mért adatok:

Tehát, jól látszik, hogy bár nem képes 32 biten megjeleníteni a különbségeket (erre van alul az exposure csúszkája), azért azok léteznek és bármilyen gammával bemappelhetőek 16 vagy 8 bitre. 

Szóval nem sikerült megérteni a PS32 bites módszerét, de megnyugodtunk, hogy azért végzi a dolgát. Nekünk meg nincs is rá szükségünk, mindaddig, amíg nem készítünk iszonyú nagy tónusátfogású HDR-eket.

Mondjuk olyat, amiben reflektorral szembe világítunk a kamerával és a mögötte, árnyékban levő felületeken is részletet szeretnénk. A tesztképeken egy 500 wattos izzós reflektort, illetve egy 20 wattos ledes reflektort használtunk. Sajnos a lencse becsillanásai jelentősen lerontják a reflektor mögötti sötét részek megjeleníthetőségét. Nyilván az izzószál és a fényképezőgép korlátai szabták meg az exponálás felső határát, 1/4000s, f/32, ISO100. Az EXIF-be nem íródik bele, így már nem vagyunk biztosak, hogy neutrál szürke filtert használtunk e, vagy ez így pont elég volt. Mindenesetre így a legfényesebb pixelek se csordultak túl. A záridőket felezve, sorozatot készítettünk 8 másodpercig. Ez 15EV-nyi lépés, ami több mint 20EV teljes átfogást tesz lehetővé. Nem valószínű, hogy a mindennapokban ilyennel találkozzunk, hacsak nem egy szénbányából fotózunk ki egy nyíláson, egy napsütötte gleccserre. 

A RAWokat PSben és ACRben fűztük össze HDR-nek. PS-ből lehet direkt 32 bites képet menteni (*.pbm, *,psd), de az ACR csak a 16 bites (lebegőpontos?) DNG-t ajánlja fel erre. Mindenesetre nekünk a DNG-ből ACR-ben a Highlights és Shadows csúszkákat tövig ki kellett húzni, amiből arra gyanakszunk, hogy ez a tónusátfogás már a rendszer határait súrolgatja.

Ha készítünk majd igazán nagy átfogású HDR képeket, akkor erre visszatérünk és mélyebben belemegyünk. De most be kell vallani, hogy eléggé lepattantunk a témáról.