Color-lateral damage

A JPEG kapcsán felmerülő veszteségmentes/veszteséges színtér konverzió mentén próbálunk meg kísérletezgetni. Vizsgáljuk, hogy a színtérváltásának lehet  e vesztesége, aztán a színprofil váltások és a színmélység csereberéje is sorra kerül.

Forrás. 

A színtérváltás valószínűleg rossz. Alapesetben készítünk egy RAW-ot, amihez AdobeCameraRAW-ban kamera profilt rendelünk. Ebből következik egy, optimális esetben veszteségmentes maszter-kép aRGB profillal (16 biten). Ezután, amennyiben netre szánjuk a képet, történik egy sRGB átalakítás. Mint már említettük, pl. RGB-ben nem lehet hatékonyan tömöríteni. Ezért van egy YCbCr átalakítás is, majd megnyitásnál újra vissza RGB-be. De konkrétan milyen veszteségekkel járhat ez? 

A legutolsó színmód váltást nem tudjuk konkrétan ellenőrizni, ugyanis a PS nem tud YCbCr módba alakítani, csak elvégzi a háttérben a JPEG kódolása során.  De mivel a JPEG amúgy is veszteséges, egy egyszerű mentéssel semmi nem fog kiderülni a színmód váltással okozott veszteségekről.

Lab módban próbáljuk tehát szimulálni a dolgot. A képet átkonvertáljuk, majd vissza, és egy differencies szűrővel az eredetire szűrjük. Érdemes egy kontrasztgörbét is nekitámasztani, aztán ha van latens különbség, akkor az is megjelenik íziben. Vagy easyben. Ilyen játékok következnek.

Lássuk az RGB - Lab - RGB konverziót. Kezdjük 16 biten.

A képernyőkép mutatja, hogy az eltérések csupán a sötét tónusok legeslegvégén (baloldalt egy vékony sávban) jelentkeznek. Ez az eltérés maga a konverzióból származó veszteség. Értéke 1-2%, nem észlelhető mindaddig, amíg nagyon durva kontrasztgörbével (gyakorlatilag falig tolva: input 4, output 255) fel nem erősítjük. 

A világos zöld színeket érinti a veszteség, ott is elszigetelten pixelcsoportokra (lásd a nagyított részletet), és leginkább csak a kék csatornára korlátozódik, egy kevés pirossal fűszerezve. Hát ez nagyon mutatja, hogy a Lab pont a zöld színekben bővebb, mint az RGB. A 8 bites kép viszont már igencsak szürreális. Szinte önmagában egy műalkotás. Érinti ez a teljes képet, égszínkéket, sötétzöldet, mindent. Itt már nem elszigetelt pixelcsoportokról beszélünk, valójában csak elszigetelt pixelek maradnak ki a veszteségből. Itt is dominánsan a kék csatorna veszít a legtöbbet, de azért van bőven a piros és zöld pixelben is veszteség.

Bár az átalakítás hatása a valóságban nem ennyire hangsúlyos, ugyanis erős kontrasztolással tettük egyáltalán láthatóvá, azért a jelenség létezik. És a tanulság is egyértelmű. Ha színtereket kell csereberélni, akkor csakis 16 bit.

Ha már így nekifogtunk, akkor az sRGB - adobeRGB átalakítást is leteszteljük. Oda-vissza. Értelmezze mindenki, ahogyan csak szeretné.

Azt is leellenőriztük, hogy önmagában a 16-8-16 bites átalakítások eltérése egy teljesen sztohasztikus zajt eredményezett, semmiféle relációt nem mutatva a kép elemeihez viszonyítva. Gyanítjuk, hogy a pixelek átszámolása során a kerekítések a hibások.

Körkérdés mindenkihez: De mi lehet a JPEG mentése során bekövetkező színtérváltásnál? A webdesignerdepot azt állítja, hogy a színtér-konverzió 16 millió bemeneti színből csupán 4 milliót képes visszahozni, egyszeri alkalommal fordul elő (nem okoz generációs veszteség-felhalmozódást- ezzel nem értünk egyet).
 Az RGB - YCbCr konverzió lényege itt olvasható. Az ImpulseAdventure a matematika felől közelíti meg a színtércsere veszteségeit, azt állítva, hogy pl. az Y kiszámolásában a szorzások részeredményeit egyenként kerekítik (gyakorlatilag trimmelik a törtrészt). Pl. egy R132 G132 B132 pixel esetén:

Y=0.299*132 + 0.587*132 + 0.114*132 = 39 + 77 + 15 Hogy valóban kerekíti e a JPEG algoritmus, erre nem találtunk választ, amennyiben igen, akkor az történik, hogy R= 129-132 pixelekre mind 39-et ad részeredménynek, vagyis 4 vörös tónus-luminanciát nem fog tudni megkülönböztetni a konverzió során. A zöldnél nincs kerekítési hiba, de a kék csatorna esetében 132-140 között mind 15-ös részeredmény fog születni, tehát 9 kék tónust fog egyetlen luminancia-számra leképezni. A visszaalakításnál gyakorlatilag a kék csatorna szenved(het)i el a legdurvább sávosodást, a zöld meg a legkevesebbet (a képletből ez értelemszerű). Konkrétan a fenti példa konvertálás után R131 G131 B131 lesz.
Ez azonban nincsen így. Ha igaz lenne, akkor egy R129 G132 B140 pixel JPEG-be mentése után visszanyitva R135 G134 B143 kellene legyen az eredmény. De nem az. Kipróbáltuk. Valószínűleg a számítások során végig lebegőpontosakat használ és akkor nincs szükség kerekítésre. Írtunk is a szerzőnek, egy hete nem válaszolt.
Konklúzió?
Ti mit gondoltok, illetve hogyan lehetne ezt kísérletileg megfogni?