Peripheral drift - hányós képek 2

Biztosan ismeritek Akiyoshi Kitaoka úr munkásságát. Na... legalább a forgó kígyókat biztosan. Ha mégsem, akkor érdemes chipset és kólát hozni, hányósabbak esetleg egy törülközőt is leteríthetnek. Ez az illúzió a luminancia érzékelésében rejlik, ugyanis a sötét illetve világosabb részek feldolgozásában időeltolódás van. Emiatt a sötét irányából a világos felé látszanak elmozogni az elemek.
A tudomány, nekünk negyveneseknek meglehetősen friss, a kilencvenes években kezdtek vele komolyabban foglalkozni. A nyúroszájenszbe nem kívánunk belenyalni, a linkeken sok érdekes dolgot lehet olvasni, mi csak megpróbáltunk néhány képet lemásolni, apró módosítgatásokkal tesztelni, jobb, vagy rosszabb lenne az optikai varázs, ha kicserélünk elemeket, ill. színeket.
A képeket eredetiben érdemesebb figyelni, bár kicsiben is simán kialakulhat az örvénylő mozgás. Leginkább amíg a szöveget olvasod, mert a perifériás látást bizgetik. Némely ábra egészen furcsa dolgokat produkál ha megszkrollozod az oldalt.
Ha valaki szeretne tovább játszani velük, szóljon és elküldöm a Corel állományt. 

A harsány színek segítik az illúzió kialakulását. A fenti képeken úgy tűnik leginkább az eredetileg használt színek (a klasszikus tekergő kígyók alkotásból) működnek a legjobban. De a középső is izeg rendesen.

Ez az ábra (a klasszikus csónakillúzió) azt bizonyítja, hogy az illúzió kialakulásának nem elengedhetetlen feltétele a komplementer színek  használata, és nem fontos az erős kontraszt sem. A jobboldali ábra kicsivel több akklimatizációs időt kíván, az apró ellentétes irányban elmozgó elemek megnehezítik a hatás kialakulását.

 Komplementer színekben kevés babszemmel is működik a dolog...

... a sok apró elem itt kifejezetten segíti az örvénylés illúzióját, a komplementer színek itt sem fontosak. Ezek az ábrák kifejezetten jól reagálnak a függőleges szkrollozásra is.

A hullámzás illúzióját többféleképpen elérhetjük, az elemek torzítása és elforgatása is alkalmas erre.

Itt sem fontosak a színek. A fekete-fehér vonalak kontrasztja végzi a dolog oroszlánrészét.

Ez az ábra inkább térélményt ad, de olykor meg is moccan.

 Paralaxis élményt nyújtanak ezek az ábrák...

... többféle színkombinációban, réssel egyaránt működnek. Erősen gyanús nekünk, hogy ennek a hatásnak valami köze van a sztereogramok működéséhez is.

 A klaszikus őszi színkavalkádos variációi.

Egyetlen állandó ezekben, a fekete-fehér kontraszt, a színek és illesztések variálása nem zavarja meg az élményt.

A fentiek alapján egy újabb formakísérlet.

Azért az megnyugtatott, hogy Akiyoshi Kitaoka úr munkái sem mind működtek egyformán tökéletesen. 

Itt találtok témakörökre lebontott optikai érdekességeket:

http://brainden.com/eye-illusions.htm

http://www.michaelbach.de/ot/index.html     

Fotó forensic. Analizáljunk képeket...

Egy szanaszéjjel fotosoppolt kép error level analízise 

... nem pont úgy, hogy gumikesztyű, vazelin és benyúlunk a JPEG hátsó traktusába, de már majdnem. A képekbe rejtett tartalomról olvasgatva újra sikerült felmikrózzunk egy régebb jegelt témát, a képelemzést, mint forenszik csudajót. Ami azonkívül, hogy irtó tudományos dolog (tehát érdekes), alkalmas (lehet) arra is, hogy kiderítsük, klónozták e a füstöt a bombázás utáni felvételeken, avagy az afgán lányos pofa hogyan retusált ki oszlopokat a képeiről. Na jó, ezek pont ránézésre is egyértelműek voltak, de itt találtok többet is.

Ha testépítő hasonlatot kellene előrántani, akkor a photoshop lenne a fotógráfia szteroidja. Egyrészt elsöprő fölényt biztosít a naturál SOOC hangyabikáival szemben, átláthatatlanná teszi ennek a művészeti ágnak az egységes értékelését, másrészt lerombolja a (főleg dokumentum/divat) fotós erkölcsi tartását, és ami a legdurvább, lerontja a laikusok bizalmát a fotográfiában.

A lovat egy másik képből retusáltuk ide.
FotoForensic ELA

Alkalmi amatőr fotósként mindig megütközve figyeljük, mekkora hisztériát vált ki egy-egy manipulált fotó leleplezése a hírközlő médiában. Ugyanakkor, mivel minket nem kötnek pályázatok szigorú előírásai, nem bukhatunk meg fotós pisiteszten, lazán szétfotosoppoljuk a képeinket. Csak egy kis vibrance, csak egy kis szelektív szűrő, hiszen ezt terepen is megtehettem volna egy degradé-, vagy polárszűrővel, vagy ezt pont így fotózhattam volna egy jobb/drágább géppel, hát nem e mindegy, hogy a terepen téptem le a fűszálat, vagy PS-ban? Pedig látjuk, hogy egy sportoló is ugyanezt mondhatná. Ha jobb lenne a genetikám, ha heti négy edzéssel több lenne, pont ilyen jó lehetnék, mint a cuccal. Ugyanakkor ez mégsem igaz. Kiszedni egy fotógépből az IR-cut szűrőt, érezzük, hogy mégsem ugyanaz, mint megbuherálni egy Forma1-es autót (bár tudjuk, hogy a motorsport kábé annyira sport, mint a sakk, vagy a pingpong, vagy a foci. Na jó, akkor mondjuk CameraRawban állítani -2 fényértéket, nem pont olyan, mint villanybiciklivel indulni a Giron. Teljesen más dimenzió. Jól érthető tehát, hogy adott esetben, egy kilőtt rakéta torkolattüze, semmilyen dimenzió mentén nem analóg egy fűszál retusával. 

De akkor is Ansel Adams a fotográfia Schwarzeneggere.

Az előbbi lovas kép. Forensically Beta

Szerintünk eléggé abszurd elvárni egy fotóstól, mint ahogyan a kész fotó szemlélőjétől is, hogy ne legyen számára az alkotás egy projekciós felület. Ebben a bejegyzésben nem kívánunk a témában jobban elmerülni, van elég körhinta, amin éppen rajta ülünk, egyetlen, relatíve kis seggel. Persze a hozzászólásokban nyomathatjátok a véleményeteket.

A teljesség igénye nélkül, tehát ezeket tekintjük leginkább manipulált képeknek:
- kontextusából kiragadott, hamisan feliratozott kép, ami akkor is manipulált, ha amúgy SOOC (pl. a Natgeoban múzeumi leltári számmal ellátott elefánt-agyarakkal menetelő vadorzók képe). Ennek felderítése leginkább social engeneering szkilleket feltételez.
- aztán a retusált képek, legyen annak célja politikai propaganda, marketing, vagy a skizoid összeesküvéselmélet-gyártók bizonyítékgyára. Itt már jól használhatóak a számítógépes elemzések.
- a "csak" kicsinosított képek esetén már határzónába értünk, sok pályázat szereti, ha a beavatkozások felső korlátját a limitek közé szorított technika képezi és nem az alkotók fantáziája.

A manipulált képekre általában jellemző a "one more thing" - azaz, egy apró csalás megtalálása után joggal feltételezhető, hogy akad még a képen turpisság bőven. Ez megkönnyíti a felderítést, hiszen több irányból utol lehet érni a sánta kutyát. Természetesen a nyomozati fotográfia nem csak ezekkel foglalkozik, a képek elemzése, boncolása (image autopsy) arra is alkalmas, hogy bűneseteket tárjanak fel. 

Adnan úr elhíresedett cucca. Szerintetek a szoftver megtalálta az ordas retust rajta?

Az image forensic, avagy nyomozati képelemzés egy külön szakma, most csak megnyaljuk a témát, Há' minek akkor a 4 év egyetem, ha ez csak így működne, hogy egy blogposztban megírjuk a tuttit, mi? 

A forensicoskodás a formátum analízisével kezdődik - első ráközelítés, hogyan keletkezhetett a kép, hogyan került hozzánk, mit állítanak róla, miben volt utoljára elmentve, van e más változata pl. interneten, stb. A meta analízisére tökéletes egy ExifTools, egy hexeditor, vagy akár a JpegSnoop, amelyekről mind volt szó az Utazásokban. Akkor is maradnak infromációnyomok egy állományban, hogyha direkt törölték a metaadatokat. Bár önmagában az EXIF törlése is gyanúra adhat okot. A Double Quantization Effect Fingerprint analízise és a PCA (Principal component analysis), Vawelet transformation - ezek mind annyira komplex témakörök, hogy talán majd visszatérünk rájuk.
A forenszik analízis ellenségei a kis felbontás, durva (és többszörös) tömörítések, médiumváltások (pl nyomtatva visszaszkennelve). Mi azonban saját fotókkal, kövér felbontásban próbáltuk ki a módszereket. 

Két online eszközt tesztelgettünk, szinte zéró sikerrel. Az egyik Jonas Wagner eszköze, a másik pedig a Hacker Factor eszköze, ahol nagyon jó tutoriálok, meg forensic játékok is vannak. Olvasgassátok, próbálgassátok, mert jó móka.

Az egyik jól bevált módszer a retusálások, és bármilyen beavatkozások felderítésére az ELA (Error Level Analysis), de ugyanakkor ehhez (is) nagyon sok gyakorlat kell. Főleg idegen képi elem jelenlétét ígéri megtalálni, pl. más tömörítésű képrészleteket, szelektív szűrőket. klónozott elemeket, stb. 

A jobboldali képre klónoztunk egy újabb amanitát. 

A két online ELA eszköz így mutatja a feliratot.

Általában a legutolsó mentésre érzékenyebb, kijátszható durva tömörítéssel, de a gyakorlatban mi nem boldogultunk vele. A fenti képekről ugyanis fűszálakat is eltávolítottunk, aki megmondja, hogy honnan, van egy kicsisöre (természetesen igazi, tiltott Heineken).

A lovat egy teljesen más géppel készített fotóból retusáltuk az Omu-csúcsra.

A klónozott ló szerintetek lebukna egy szakember előtt? Én ebből az ábrából nem tudnám megállapítani, hogy valóban volt e ló 2500 méteren, a Bucsecsben.

Copy/Move Forgery and Clone Detection. Na ez aztán egy olyan eszköz, ami végképp kiborított. 

Bár a baloldali képen a leklónozott amanitát sikerült (?) észlelnie, a jobboldali képen olyan részleteket jelölt meg klónozottnak, amelyek egyáltalán nem voltak megmatatva. A legmeglepőbb egy mobillal készült kép volt.

A mimosa fotójával, csak a Jóisten tudja mit művelt az Assus, de mi semmit se retusáltunk a képen, mégis számtalan gyanús elemet jelölt meg az eszköz.

A JpegSnoop sajnos csak akkor alkalmas megállapítani a beavatkozást egy fotón, amennyiben az állítás az, hogy a kép SOOC (straight out of camera). Ezt könnyen cáfolhatja, viszont más beavatkozások között nem képes különbséget tenni.

A fenti képernyőképeken egy eredeti JPEG, JPEGSnoop analízise látható. A baloldali capture a kamera által mentett Exiffel, a jobboldali pedig törölt metaadatokkal. Mivel a D5000-et nem ismeri a JPEGSnoop, ezért nem jelenti ki, hogy egyértelműen eredeti a kép, bár a metaadatok arra engedik következtetni. Viszont törölt metaadatok esetén már egyértelműen szerkesztettnek jelöli, pedig csak a metaadatokat szerkesztettük (töröltük).

PS-ben újramentett kép. Full metaadatokkal, illetve törölt metaadatokkal. Érdekes, hogy törölt metaadat esetén elveszíti a Nikon adatokat, a PS Image Resource Blokkokat, de az APP13-ból még így is ki tudja olvasni, hogy PS-ben volt mentve. Ugyanez a helyzet, ha nemcsak újramentjük, de szerkesztjük is a képet.

Az IrfanView mentését is elég jól megsaccolja. Mellesleg a JpegSnoop adatbázisa bővíthető, tehát egy törölt metaadatú fileról megtanítható neki, hogy eredetinek lássa, de persze egy szkeptikus ellenőr ezt nem fogja beszopni, saját újratelepített programmal egyből kiderül a turpisság.

Összefoglalva: nem is frusztrál nagyon, hogy pár nap alatt sem sikerült, még banális retusokat sem észrevenni pl. az Error Level térképeken. Ha odatennének, hogy az ultrahangos radarképről mondjuk meg, fiú vagy leány az a pixelzaj, ami előttünk van, az sem menne elsőre, nem igaz?

A fenti linekeken kívül ezt, meg ezt a tanulmányt is elolvashatjátok. Izgi. 

JPEG összefoglaló 7

A minap abbahagyott gondolatsort folytatjuk.

4. Melyik a jobb, vagy ugyanolyan a Save as 12-es szint és a Save for Web 100%? Ez se egy érvényes kérdés, mert aki ennyire szőrszálhasogató, az mentsen TIFF-et LZW tömörítéssel, az Isten szerelmére. De nem egyformák. A JPEGSnoop szerint 3 század százalék eltérés van a kettő között. Borzi. Tehát a Save for Web 100% a legbesztesebb, 98,39-es minőség faktorral, míg a Save As 12, 98,36-os faktorral alig rosszabb a kroma csatornákon. A luminancia csatornákon is 6 századnyi csupán az eltérés. A Nikon D5000 Fine beállítás a kroma csatornán ugyanolyan jó (de nem azonos kvantálású + ne feledjük a subsamplinget se) mint a Save for Webb 100%, luminancia csatornája viszont csak 98,02-es. 

5. Miért van a PS-ban 13 tömörítési szint? És a PS alapesetben miért csak a 10-es értéket ajánlja fel? Sajnos hivatalosnak tűnő válaszokat nem találtunk, tehát anekdotikusnak kell tekintenünk őket. A 11-12-es értékek állítólag a fejlesztés korából maradtak benne, bármit is jelentsen ez. A PS szerint a kiváló minőséget már a 10-es garantálja. Mint a 4-es pontból láttuk, ez egyáltalán nincs így. Úgy tűnik, hogy az Adobe sem veszi komolyan a JPEG-et. Nincs mese, a JPEG mintha csak végfelhasználásra lenne szánva. Ha így tekintünk erre a formátumra, akkor már a 8-as minőség is tökéletesen megfelel internetre. A 12-es érték ára nagyjából dupla fileméret (a 10-eshez képest - lásd alább).

Lehet találgatni, melyik a 10-es és melyik a 12-es. 

6. Mi történik a PS-ban a 6-os illetve a 7-es beállítások között?

Valószínű, hogy nektek se tűnt föl eddig, hogy a 6-7-es értékeknél Photoshopban valami gubanc van. Pedig az internet tele van magyarázatokkal. Ha eddig ezeket az értékeket használtad, akkor érdemes megfigyelni azt a jelenséget, hogy az elvárttal ellentétben a 7-es értékkel, a 6-oshoz viszonyítva, nem nagyobb lesz a fileméret, hanem kisebb (lásd alább az ábrán). A képminőség sem lesz egyértelműen jobb, inkább másképp lesz szarabb.

Megkattintva nézd, 300% nagyítás. Balról és fentről 0-12 JPG tömörítés PS-ban.

 A PS 13 értékének hatása a fileméretre. Érdemes figyelni a 6-7 értékekre,

illetve a 11-12 értékekre.

Gyakorlatilag 0-6 szintek között a kroma subsampling 2x2 (negyedére csökken a CrCb felbontása), míg a 7-12 között a kroma subsampling:  1x1. Emiatt 7-esnél nagyobb ugrás lenne tapasztalható a fileméretben, ezt mérséklendő, itt nagyobb kvantálási értékeket alkalmaznak. Képe válogatja, hogy ezzel a trükkel mennyire sikerül a fileméretet a 6-os és 8-as fileméretei közé szorítani. A mi példánkban nem sikerült. 6-os értékkel 1536 kbyte, 7-es értékkel pedig 1532 kbyte lett az eredmény. Alább a 6-os és 7-es kvantálási táblái:

Mivel a luminancia tábláját is jól megtömöríti (a 6-os tömörítéshez képest), simán előfordulhat, hogy gyengébb képet kapunk a jobb beállítás mellett, nagyobb színfelbontással.

+ Bónuszprogram. A JPEGmini szolgáltatása. 

Többet vártam tőle, abból ahogyan feldicsérték valamelyik blogon. Sajnos csak JPEG képeket fogad, adta magát a kísérlet, hogy sorra odaadjuk neki a 0-12 értéken tömörített fájlokat, lám mit kezd velük. Ezeket azután fileméret szerint megfeleltettük a PS-ban tömörített állományokkal. Nagyjából egy értékkel tömörítette be jobban, tehát a 12-esből a mini kb. 10-11 közöttinek megfelelő méretűt produkált. A 10-esből 9-est, 6-osból meg 5-öst. A képeket összevillogtatva (400%) a mérettel nagyjából arányos volt a minőség is, bár a 12-10-es tömörítéseknél megoszlott a véleményünk, volt aki a nagyobb mini képet tartotta jobbnak, én pedig inkább a picivel kisebb PS képet. A különbség egyáltalán nem mérvadó. Mindenesetre kijelenthető, hogy a JPEG mini nem csodaszer, nyugodtan hanyagolhatjátok. 

Melyik formátum mekkora fileméretet okoz?

Az  Utazások egészen parányi blog ahhoz, hogy nagy kísérleteket lefolytassunk. A következő cuccot is sok-sok képpel kelletett volna megcsinálni és különböző fotó-témák szerint statisztikákat felállítani, hogy egy precíz eredményt kapjunk. De mi most egyetlen képpel csináljuk meg. Van rajta jó nagy ég, szikla, meg fák, tipikus hegyi tájkép. Ilyenből készítünk a legtöbbet, szóval az, amit ebből megállapítunk, jó lesz nekünk az elkövetkezőkre.

Minden formátumnál a maximálisan elérhető minőséget állítottuk be, akár a gyorsaság rovására is. A lassú mentés leginkább a tömörített TIFF-ekre (főleg a ZIP), JP2000-re illetve a PNG-re volt jellemző.

8 bites formátumok

16 bites formátumok

8 biten egyértelműen a SOOC-hívők járnak a legjobban tárhely szempontjából. A D5000 color subsamplinget is használ, és sokkal durvábban tömörít, mint a PS maximum minősége. 

Továbbá az derül ki, hogy még mindig a legjobb megoldás a nyers file tárolása. Leginkább DNG formátumban. (gyanítjuk, hogy a demosaic előtti állapot miatt harmadannyi adatot tárol, illetve JPEG previewt sem tartalmaz). Mivel open-source, remélhetőleg 10-15 év múlva sem ér majd meglepetés minket, bár azért annyira nem bíznék meg benne, mint a JPEG-ben.

Van egy olyan tévhit, hogy a DNG kevesebb, vagy másabb, mint az eredeti RAW. Tesztjeink ezt nem támasztották alá, a NEF, illetve DNG, Camera RAW-ból nyitva, difference összhatásra semmilyen különbséget nem mutat ki.

Amennyiben PS-ban piszkálni kell a képet, a JP2000 veszteségmentes tömörítése adja a legkisebb méretet, de 16 biten ez így is majdnem ötszöröse a DNG-nek. 8 bitesen csupán másfélszerese. Egy TIFF-el összehasonlítva semmilyen különbség nem mutatható ki, tehát teljesen veszteségmentesnek tekinthető. Sajnos a JP2000-nek nem sikerült annyira elterjedni, mint a JPEG-nek. Pl. a blogger sem fogad JPF-et.

Ha rétegeink is vannak, akkor 8 biten a TIFF LZV a jobb, 16 biten viszont vállalhatatlanul elrontottak valamit, mert kiemelkedően rosszabb, mint a nem tömörített változat. A TIFF ZIP jó megoldásnak tűnik, kevés kép esetén nem zavaró a lassúsága, viszont nincs nagyon elterjedve, nem minden szoftver lesz képes megpiszkálni. Na így.

Ringasd el magad - hánytató képek

Bár az internet nagyobb hájpjai nem kímélnek minket sem, azért számunkra is létezik újdonság, a fejrázogatós optikai illúzió például eddig elkerült. Elkészíteni viszont egyszerű, egy fekete-fehér (függőleges) rács alá kell behelyezni a megjelenítendő fekete-fehér ábrát, de csak 10-20% átlátszósággal, éppen csak, hogy ne lehessen észrevenni fejrázogatás nélkül. 

A fekete-fehér vonalak fejrázogatás közben aztán szépen szürkévé olvadnak és felsejlik az alárejtett ábra is. Kipróbáltuk a fekete vonalakba rejtve is, de úgy nem működött. Viszont fehér-szürke rácsokkal is jó. És nem feltétlenül kell rázogatni a fejet, kellő nagy távolságból szemlélve, szintén felsejlik a rejtett kép. De működik például piros-cián párosban is. 

Érdemes már az elején eldönteni a végleges méretet, mert rosszul viseli a skálázást, ugyanis az élek kontrasztosak kell legyenek, a közök meg egyformák. Érdemes figyelembe venni a megjelenítő monitor felbontását/méretét is, mert pl. egy sűrűbb felbontású monitoron anélkül is összeolvadnak a komplementer vonalak, hogy rázogatnánk a fejünket. Például a félhádés monitoron szerkesztett képek a kétkás monitoron teljesen használhatatlanok. Ha tehát már fejrázogatás nélkül is látsz valamit a csíkokban, akkor érdemes egészen közel menni a monitorhoz.
Pulsz egy másik érdekesség, ha 30 másodpercig bámulod a csíkokat mereven, majd lenézel a billentyűzetre, az is jó tud lenni :)
Na, ezzel is el lehet cseszni egy délutánt. 

JPEG APP Markerek - egyszerű (tökéletlen) csináld-magad vízjel

Amelyben kicsit felmelegítjük a sztegano és watermark témát kifejezetten a JPEG-ről tanultakat felhasználva. Amúgy közben találtunk egy régi könyvet, amiben mindenféle fileokban és mindenféle módokon  dugdosnak el titkos tartalmakat. Ide linkelem. 

Minden JPEG két marker, a 0xFFD8 és 0xFFD9 között helyezkedik el. Ezek a StartOfImage illetve EndOfImage speciális markerek, ugyanis nem következik utánuk adat.

Mivel a 0xFFD9 után a szoftverek már nem értelmezik a képet, ezért adja magát a lehetőség, hogy ide is rejthetünk tartalmat (hasonlóképpen, mint azt a BMP esetén már csináltuk). Gyakorlatilag a JPEG után szúrjuk be a cuccot.

Természetesen Szilágyit dugtuk el a file végén

Sajni, ezzel az a probléma, hogy újramentve PS-ben, törlődik minden, ami a  0xFFD9 marker után áll. Tehát nem bírja a szerkesztést. Kipróbáltuk, hátha a bele rejtett szöveg utáni  újabb 0xFFD9 megoldja a problémát, de nem. És persze nem lepett meg, hogy a Facebook se hagyta nyitva ezt a kiskaput. De a Google például igen (a BMP módszer pl. náluk nem működött). Később találtunk egy cikket, ahol egy JPEG-be rejtett ZIP állományt találnak meg azzal a módszerrel, hogy simán rákeresnek az EOI markerre. Na jó, köszi, ezek után semmibe nem kerül egy robottal figyeltetni hány EOI van egy JPEG-ben. Ennél valamivel combosabb megoldás kellene, ha legalább a Facebook beszopná, lehetne használni watermarknak (steganora semmiképp, még kriptálva is csak a szomszéd ellen), de így nem éri meg monyolni vele. 

Általában a JPEG többi markerei így néznek ki:

0xFF+Marker Number(1 byte)+Data size(2 bytes)+Data(n bytes)

0xFFE0-0xFFEF, vagyis az Application Markerek (összesen 16) nem szükségesek a JPEG kikódolására, ide írhatnak a szoftverek. Például az EXIF-et (amire remélem majd egyszer visszatérünk), ami történetesen az APP1(0xFFE1) markert használja. Az EXIF tagokról ez is érdekes olvasmány. Mindenesetre az EXIF-et nem tartjuk érdemesnek titkolt vízjel elhelyezésére, ugyanis könnyen törölhető. EXIF-ben érdemes ugyan copyright infókat tárolni, mivel még a Facebook is megtartja, de ha titkosat akarunk, akkor nem ez a megoldás.

Az 0xFFEC  marker, vagyis az APP12 "Ducky" marker elárulja, hogy a képünk Save for Web 60% beállítással volt mentve:

A marker utáni két byte: 0x0011 - 17 byte adatot jelent, de ebbe a Data Size is beleértendő, tehát még 15 byte adatnak jut hely a következő markerig (0xFFE1). Ebből a 0x003C jelenti a 60%-os tömörítést, amit a PS olt bele a fileba, ha Save for Web parancsot használunk.
Ha viszont Save as-t használtunk akkor az 0xFFED markerben (APP13) a 0x0406 Photoshop IRB resource pont (JPEG quality-t jelöli) után írja be a mentési minőséget. A 0x0008 az 12-es mentési minőséget jelenti. Részletesebben, itt arról, hogy milyen érték mit jelent.

Na jó, egy másik ötletünk az volt, hogy keressünk egy olyan markert, amit nem listáz az EXIFTOOLS sem, ahova írhatnánk saját infókat. Mivel az APP12 (Ducky marker) a SaveForWeb esetén kap értéket, nem is volt jelen a kiindulási fileban. 

Az 0xFFED elé szúrtuk be tehát, 0xFFEC címen (APP12) 0x000E hosszon (12byte), azt, hogy "krikszkraksz". Az ExifTools nem mutatja ki, de sajnos ez is törölhető a full metaadat törléssel. A Photoshop még úgy is felülírja mentéskor, hogyha nem a Save for Web parancsot használjuk. Ezután az APP14 marker tűnt jó választásnak, mivel tartalmazhat olyan információkat, amelyek érinthetik a kép megjelenítését. Ezért az ExifTools sem törli, legalábbis egy fórum szerint, ahol maga Phil Harvey írja ezt. 

Sajnos de. Azóta megváltozhatott a dolog. Valahogyan csak visszaállítja az eredeti értéket. A PS meg pláne minden mentésnél átírja.
Ugyanez volt az APP7-11 esetén is, pedig itt kifejezetten olyan markerek vannak, amiket nem a PS használ. De törli az ide rejtett információkat a Facebook is. Szóval az APP markerek úgy tűnik egyáltalán nem jó megoldás szteganográfiára.

Az a gyanúnk, hogy jól ki van találva ez a JPEG szabvány és eléggé le vannak zárva benne a kiskapuk. Korábban kellene kelni ahhoz, hogy meghekkeljük. 

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? 

JPEG összefoglaló 6 - A generációs veszteség újramentések esetén

A JPEG-ről mindenki tudni véli a tuttit. Ugye kocsmában is feszt ez megy, vagy politika, vagy foci, de leginkább a JPEG. De vajon az előző posztok alapján mernénk e fogadni egy láda sörben, a következő állításokkal kapcsolatban? A kérdéseket kiemeltem, továbbolvasás előtt lehet tippelgetni. 

A JPEG mentés poszterizációt okoz. A jobboldali hisztogram egy durván veszteséges JPEGmentés eredménye.

1. A Nikon D5000 Fine JPEG (bármilyen gép, bármilyen minőségbeállítása) megfeleltethető e a Photoshop JPEG beállításaival? 
A kérdés  azért  jogos, mert létezik a mítosz, hogy ugyanazzal a kvantálási mátrixszal mentve, nem romlik a képminőség (lásd a 3. pontot is). Nem megfeleltethető. A PS mindig ugyanazokat a kvantálási mátrixokat használja, míg a fényképezőgépek minden képet elemeznek, és annak megfelelő táblákat hoznak létre (custom adaptive - nem jártunk utána, hogyan csinálja). Nem lehet sem a Nikon, sem a PS kvantálási tábláihoz hozzápiszkálni kívülről. Megnézni szerencsére lehet ( JPEGsnoop). Az értékei egymás mellé rendezve:

Jól látszik, hogy a PS12  alacsonyabb,

a PS11 viszont magasabb értékekkel operál, mint a D5000 FINE saját táblája

A fileméret szintén azt bizonyítja, hogy a Nikon Fine beállítása (ebben a konkrét esetben) valahol a PS 11-12 értékei között van félúton.

1.1. De legalább a Photoshop Save As... illetve Save for Web beállításai egymással megfeleltethetőek e? Nem. Az internet tele van megfeleltetési táblázatokkal, a kétfajta mentés között, ennek gyakorlati hasznát nem látjuk, mert az alkalmazott kvantálási táblázatok szerint, pontosan úgysem fedik egymást a beállítások. Viszont nem igaz az, amit valahol olvastunk, hogy pl. a Save for Web... 90-100% megegyezik a Save As... 12-es értékével és így tovább lefele. Még a 99% és a 100% is külön kvantálást használ (a 63 kvantálási tényezőből 3 eltér).

2. Ha nem változik a blokkméret (nem volt vágva a kép), és a blokk tartalma (semmilyen színbeavakozás nem történt), ugyanazzal a kvantálási táblázattal újra- meg újramentve, akkumulálódik e a generációs veszteség? A kérdés azért jogos, mert a kvantálás felel leginkább a veszteségért. Másrészt meg elvi, mert minek menteni egy képet, ha semmit csinálunk vele.

A válasz érdekes. A High beállításoknál minden mentéssel nő a veszteség. A Low beállítások felé haladva viszont egyre kevésbé romlik a kép az újramentések során (lásd alább). 

Az alábbi képen csak újramentés történt, semmilyen más beavatkozás nem volt. Az ábrákon a 00 generáció a legelső JPEG mentést jelenti, az original pedig a veszteségmentes eredetit.

PS 10 és 12 beállítás hatása 25 újramentésen keresztül

A 25 mentés során szinte nem volt látható veszteség a magasabb frekvenciás részeken, viszont az alacsony frekvenciás részek igencsak sávosodtak. Magyarul, a sziklát, ágakat szemmel láthatóan nem bántotta a huszonötszörös újratömörítés, az ég viszont szétesett már a 10. mentésnél. Ami ellentmond a kvantálásnál tanultakkal, hogy kifejezetten a nagyfrekvenciás részleteket tizedelik. Vagy nem mond ellent annak, hogy a látásunk megengedőbb a nagyfrekvenciás zónák veszteségével szemben, ezért csak az alacsony frekvenciás részeken észleljük a hibákat. Ezért most vizualizáljuk, pontosan miket érint a veszteség.

PS10 esetén a különbségek (veszteségek) a 0-12. illetve a 0-25. mentések között.

Jól látható, egy PS10-es beállítás mellett, hogy csakis korlátozott területeken megy végbe a rohamos romlás, míg más zónák (fekete részek) a 25. mentés után sem mutatnak eltérést a kiindulási képtől. 

Adja magát a kérdés, hogy mi történik alacsonyabb minőségbeállításnál. Hát ez:

Hát, szemre szinte nem lehet megállapítani a 25 generáció közötti különbséget. Az ég mindkettőn elég szederjes. Ami nem is meglepő, ha a különbségtérképet figyeljük:

Úgy tűnik, PS0 JPEG mentésnél nagyjából tökmindegy, hogy hányszor mentünk újra egy képet. A minőségromlás az első veszteséges mentéskor megtörténik (a 00 generációval), még van egy kis különbség a 0-1 generációk között, utána gyakorlatilag a kép változatlan marad, újramenthető kismilliószor, viszont ami kifejezetten érdekes, hogy a fileméret növekszik minden újramentéssel, mi azt gyanítjuk, a Huffman-kódolás miatt van ez.

Látható tehát, hogy Photoshopban a Maximumtól a Low irányában a sorozatos újramentések egyre kevésbé érintik a képminőséget. Viszont kritikus pont a legelső JPEG megszületése valamilyen veszteségmentes formából. Eddig az itt elveszített adatokat nem firtattuk. Most az eredetivel vetjük össze az első veszteséges mentést.

A fenti különbségtérkép jól mutatja, hogy PS0 beállításnál a legelső mentésnél jóval nagyobb a veszteség, mint PS12-nél.

Viszont az is világos, hogy a 0 beállítás egyetlen mentés alatt többet elveszít a képből, mint a 12-es beállításból 25 mentés. Plusz még az is kiderült, hogy a minőségibb beállítások (sorozatos újramentésnél) hajlamosabbak a homogén felületeket rombolni, míg az alacsony minőségű tömörítések inkább a részleteket rombolják,  a homogén felületeket kevésbé. Pl. 25 újramentés után a JPEG12 ege rosszabbul fog kinézni, mint a JPEG0 beállításé (akárhány mentés után, mivel ott az első pár mentés a releváns csak).

3. Érdemes e nagyobb minőségűre újramenteni egy JPEG-et a kevesebb veszteség érdekében, vagy inkább ugyanannál a beállításnál érdemesebb maradni? Úgy gondoljuk, hogy JPEG mentésnél minőségjavulás sohasem fordulhat elő újramentés során, ezért a minőségvesztés lecsökkentésére játszhatunk csupán. A kérdés szintén elméleti, ugyanis a valóságban ez leginkább úgy fordulhat elő, hogy a fényképezőgép készít egy nagyjából PS10-11-nek megfelelő tömörítést, ezt Photoshopban szerkesztés után meg PS12-nek mentjük el, remélve, hogy ezzel teszünk a legjobbat a képnek. Mint az első pontban kiderült nem merül fel, hogy pontosan ugyanolyat tudjunk menteni, mivel PSben nem enged személyreszabott kvantálási tényezőket. Amennyiben egy előzőleg is PS-ben mentett képpel van dolgunk, amit nem maximumon mentettek, akkor az alábbi a helyzet. 100%-ban nézzétek.

JPEG10-ből JPEG10

JPEG10-ből JPEG12

Az első különbségtérkép JPG10-ből JPG10-nek visszamentve, a második pedig JPG10-ből JPG12-nek mentve. Míg az első esetben inkább a homogén felületeken és izolált foltokban van elég durva veszteség, a felfele mentésnél szinte a teljes képre kiterjedő a rombolás apróbb, de szétszórtabb formában. Ebből sajnos nem tudjuk még kijelenteni, hogy melyik megoldás jobb vagy rosszabb, ugyanis a különbségtérkép csak azt árulja el, hol történt változás, de ennek szubjektív hatásáról semmit állít. A 2. pont tanulságai alapján viszont alacsonyabb minőségbeállításnál célszerűbb ugyanarra a beállításra visszamenteni, hiszen láttuk, hogy pár mentés után ott már nincs negatív hatása az újramentéseknek.

A fenti esetek, mint említettük, csupán elméleti jelentőségűek, a következő bejegyzésben azt is firtatjuk, mi van akkor, hogyha a mentések között olyan beavatkozások történnek, amelyek felvetik az újrablokkosítást, esetleg a tónusok változását (más DCT táblák keletkeznek).