Valóban jobban látunk kontrasztot, mint színeket?

A cím meglehetősen pongyola (fényesség vs színesség a téma), de mindjárt kiderül miről van szó. Már egy jó csomószor meghivatkoztam, hogy az emberi látás, meg a luma, meg a chroma, de semmit se nem hiszünk el senkinek, ezért legyen itt egy félperces, elég butácska, de szerintem meglehetősen szemléletes példa. Persze a PS nem tud direkt módon YCbCr-be konvertálni, tehát trükközünk picit. Nem én találtam ki, a netről nyaltam nektek.

Originál

A kiindulási képből Desaturate paranccsal létrehozzuk a Luminancia réteget, majd a kiindulási képet 25%-ra csökkentjük (Best for reduction). majd 400%-ra növeljük kétféleképpen. Egyik a Smooth (jobboldali), másik a Hard (baloldali) interpoláció. Ezeket visszahelyezzük a deszaturált rétegre, Color Blending mode beállítással. 

 Az előbbi módszer fordítottját végezzük el, az alapréteg most a színes eredeti lesz, a deszaturált réteg kap most 2x2-es subsamplinget, majd visszahelyezve a színes rétegre, Luminosity blending módot állítunk.  

A képeket 100%-ban nézzétek, ofkorsz, a jobb sarokban egy 200% nagyítást is kaptok. Asszem magukért beszélnek. Innentől nem kérdés, hogy van létjogosultsága a color subsamplingnek. 

Találtam egy ilyet is valami powerpointban (sajni nem tudom belinkelni, keressétek meg, mert jó):

Azért is sznájpoltam ide, mert nemcsak a luma-chroma kérdést világítja meg, hanem visszacsatolhatunk a Diszkrét koszinusz transzformációhoz is. Jól megfigyelhető, miért állították azt, és a nyomukban én is szajkóztam, hogy a látás a nagyfrekvenciás jelekre kevésbé érzékeny, mint az alacsonyabbakra. Na ezér. 

JPEG alapok 4 - Futamidő- és Huffman-kódolás

Előzménye a DCT kvantálása. Na, ebben a részben történik meg a tömörítés, ami önmagában veszteségmentes folyamat (a veszteség már a kvantálás során keletkezett).

A kvantált DCT

5. A kvantálás utáni mátrixból egymás után rendezzük frekvencia szerint az AC értékeket, aminek hatására a DC után először az alacsony, majd a magas frekvenciák lesznek egymás után fűzve. Gyakorlatilag egy kétdimenziós táblából egydimenziósat csinálunk. Ennek az a célja, hogy többnyire hasonló elemek (főleg a zérósok) nagy számban rendeződjenek egymás mellé. Emlékszünk, ezért nyírtuk ki a nagyfrekvenciás jeleket a tömbünk jobb alsó régiójában, hogy ez megtörténjen. Első érték tehát a DC (0,0 pozíció), jelen esetben a -26, ami a teljes blokk átlaga is egyben, azután az alacsony frekvenciák felől haladunk a magas frekvenciák felé, vagyis a jobb alsó sarok irányába. Így:
-26 -3 0 -3 -3 -6 2 4 1 -4 1 1 5 1 2 -1 1 -1 2 0 0 0 0 0 -1 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

A DC értéket amúgy az előző blokkhoz viszonyítva bonyolultabbul menthetik, arra alapozva, hogy a szomszédos blokkok átlagai közel esnek egymáshoz, inkább a kis méreten kódolható eltérést kódolják, mint a nagydinamikájú adatot, ebbe most nem megyünk bele.

Na innen kezdve aztán elég sokféleképpen magyaráz az internet. A futamhossz-kódolást (run-lenght-encode) többnyire szöveggel és karaktereinek kódolásával mutatják be, de volt aki nem átallotta almákkal és banánokkal. Na midegy, mi képpel dolgozunk. Azt a módszert vesszük át, amit a leghitelesebbnek ítéltünk meg (8 perc környékén tér rá erre Amir úr).

A futáshossz-kódolás (RLE) lényege, hogy az egymást követő azonos értékeket pl. zérósok (más weboldalakon, videókban minden ismétlődő érték), ne fogyasszanak sok tárhelyet. Csökkentjük a redundanciát, de mi most csak a nullásokkal (azér' kvantáltunk, hogy jó sok legyen), olyan formában, hogy megadjuk a zérósok számát (r), majd az azokat követő AC érték tárolására szükséges bitek számát (s) - innen fogja tudni a kiolvasó program, hogy pontosan mit kell kiolvasni, mint AC adatot, majd magát a zérósokat követő AC értéket magát (c).

 [(r,s),c]

Tehát a sorunk elemein végighaladva:
-26 -3 0 -3 -3 -6 2 4 1 -4 1 1 5 1 2 -1 1 -1 2 0 0 0 0 0 -1 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

[(0,5),-26] - mivel a DC az első elem, ezért itt az r=0, és máris belefutottunk Amir Nagah videójában egy érdekességre. Ő azt állítja, hogy -26 elkódolható s=5 biten. Felmerült bennem, hogy a negatív előjellel meg mi van? Írtam is neki kérdés-kommentet, lám mit válaszol.
[(0,2),-3] - a második érték előtt sincs zérós, -3 meg Amir szerint 2 biten tárolható. Egyelőre ezzel tárhelyet pazarlunk, de nézzük a zöld zónát:
[(5,1),-1] - 5 zérós előzi meg a -1-et. Itt már 3 számmal írtunk le ötöt, de az igazán érdekes az a feketével kiemelt sor:
[(0,0)] -  ez az EOB jel, ha az r és az s is nullás, akkor innentől a blokk végéig mind zérós jön. Na itt történik a nagy redundanciacsökkentés és tömörítés. 

Amir a videójában azt állítja, hogy a JPEG-ben minden (r,s) párost egyetlen byte ír le, amiből a felső négy bit az r, az alsó négy bit az s. Amennyiben az r nem elég (a zérósok száma >15), több rövidebb futamhossz-kódolásból oldják meg. Az s értékére max. 11-et ír (15 helyett), ennek köze lehet a fent említett előjel-problémának a megoldásához (lássuk mit válaszol). 11 biten mellesleg 2047-ig kódolhatunk. Gyakorlatilag tehát az történik, hogy 15 nullást egyetlen byte kódolhat el. Az EOB byte meg bármennyi nullást.

Egy valós képen, ahol a 8*8-as blokkok homogének és nagyobb felületeken sem nagyon ütnek el egymástól (pl. a fél képen kék ég húzódik), egyes (r,s) párosok sokkal gyakrabban fognak előfordulni, mint mások. Tehát ha a  [(r,s),c] sorozatokat egymás után fűzzük (binárisan persze), akkor lesznek benne patternek, amelyek gyakran fordulnak elő, mások kevésbé. Ezeket érdemes helyettesíteni, a gyakoriakat rövidebb szimbólummal, a ritkábbakat hosszabbal, így további tárhely spórolható meg. 

Ezt csinálja a Huffman kódolás (ebből is többféle van), bár létezik JPEG-ben aritmetikai kódolás is, ami még nagyobb tömörítést eredményez, viszont macerásabb (talán a JP2000, de arra a körhintára nem kívánunk felülni). Lényege az, hogy az elkódolni kívánt elemeket statisztikai gyakoriságuk szerint rendezi, a kevésbé gyakori elemekhez rendel nagyobb címet, a gyakoriakat pedig kevés biten kódolja. A youtube tele van magyarázatokkal, ne spóroljátok meg. Én sem írnám le jobban. Ezt a tömörítést az interneten általában szövegkódolással illusztrálják, tegyünk így mi is, egy Eminem nótában pl. a fuck szó lenne a legrövidebben megcímezve, a hegeli dialektika pedig a leghosszabban (de lehet, hogy tévedek és ilyet egyszer se mondott ki). Tipikus programozói feladat. Azért egy képernyőképet ideszúrok magamnak emlékeztetőnek. Az a1, a2 stb. a kódolni kívánt elemek, pirossal az előfordulásuk gyakorisága jelenik meg. Sárga mezőben pedig az elkódolásukhoz szükséges bináris cím.

Az így keletkezett címeket egymás után írjuk. A legszebb ebben a trükkben az, hogy míg a szavakat szóközök jelzik, a morzéban meg pl. szünet vezeti be a következő jelet, itt a teljes hosszú bit-kolbászban nincs szükség elválasztó szimbólumokra az egyes jelek között, maga a kiolvasási rendszer garantálja a helyes visszakódolást:
például legyen ez a Huffman-kódolt bitstream: 010110101010011101001011101010110010101010
A fenti bináris fa segítségével sorban kiolvassuk. A színek jelzik, melyik szimbólumot melyik szakaszból vesszük: a1, a2, a3, a2, a2, a2, a1, a4, a1, a2, a1, és így tovább, egyszerűen nem lehet másképp kiolvasni.

Minden képnek saját bináris fája van, természetesen a visszafejtéshez a JPEG filenak tartalmaznia kell az adott adathalmaz visszafejtéséhez szükséges információkat. A Huffman-kódot is lehet tweakelni a haladóbbaknak, a jobb eredmény érdekében. Mi azonban csak tátjuk a szánkat, a JPEGsnoppal ilyesmiket találtunk Huffman kulcsszóra a tesztekhez használt képünkben:

Egy random JPEG Huffman eloszlása. A DC tábla nyilván jóval kevesebb információt (12) kódol, az AC meg 256-ot.

A táblázatok statisztikai eloszlásából jól látszik, hogy bár eredetileg minden egyes értékre 8 bit kellene, közel felüket 2 bitből meg lehet címezni. Bár van olyan ritkán előforduló adat, ami akár 16 bitet használ el, azért a nyereség elég látványos. A 0% értékek becsapósak, valamiért a JPEGsnoop nem tud egynél kisebb értékeket itt megjeleníteni. 

Mivel a százalék értékek nem pontosak, csak a nagyságrend számolható ki, a négy tábla összes adata megegyezik a 12 megapixeles kép összes pixeleinek a számával. Eben az esetben a DC táblázatban az látszik, hogy a leggyakoribb adatokat 3 biten kódolja, de találtunk olyan képet is, amiben már 1 biten. Gondolom ez azon múlik, milyen bináris fát sikerül létrehozni (levél-ág, vagy ág-ág szerkezet van a gyökér után).

A tömörítésben még van egy fontos tényező, a subsampling, de mivel azt nem mindig alkalmazzák, külön tárgyaljuk a következő részben. Nagyjából ennyi volt a JPEG elkódolása, megnyitáskor pedig ugyanezek a folyamatok fordítva játszódnak le. Ennyike. 

JPEG alapok 3 - kvantálás

Előzmények a RGB - YCbCr átalakítás, blokkosítás és a diszkrét koszinusz-transzformáció.

4. lépés a kvantálás. Itt történik meg a veszteség, a későbbi tömöríthetőséget előkészítendő. De nem maga a veszteség az, ami miatt kisebb lesz a file.

Az előbbi lépésben képzett 8x8-as DCT együtthatók kvantálása következik, a kvantálási mátrix segítségével.  A nagyfrekvenciás részletekből fog kidobni többet az eljárás (a DCT mátrix jobb alsó régiójából), az alacsonyakat (lassabban változó képi információkat) egyre kevésbé bántja (a DCT tábla bal felső régiója).

A kvantálás egy 8x8-as adat-mátrix szerint történik, amelyben minden egyes érték a DCT megfelelő együtthatóját fogja osztani, az eredményt meg felkerekítjük. A tábla (annak értékei) függ a mentés minőségi beállításától (is), ezen keresztül állítható be a veszteség mértéke. Eltérő a luminancia és a krominancia kvantálási mátrixa, hiszen a luminancia jeleit kevésbé tizedeli meg, mivel a szem érzékenyebb a kontrasztra mint a színváltozásokra.

Ezeket a wikiről fogdostuk össze. 

A kvantálási mátrixok létrehozására van ezerféle ajánlás (pl. IJG standard 0-99), abszolút nem mindegy a képek felhasználási területe. A kamerák és szoftverek kvantálási mátrixai finomhangoltak, ezért nehéz megfeleltetni őket egymással. Ebben nem segít a fileméretek összehasonlítása sem (pl. lásd később a PS 6-7-es tömörítési érték körüli érdekességet). A PS saját custom fix táblákat használ, nem az IJG standardot. Ezt csak pár képpel teszteltük és csakis a 12-es értéket - ott igaz a hír - logikus is, a többszöri újramentésnél ennek lehet értelme. Vannak alkalmazások, amelyek a mátrix kialakításakor figyelembe veszik a kép egészét, körülményeket, általában a kamerák saját szoftverei ilyenek (custom adaptive tables - on the fly computing). A Nikon D5000 például két ugyanolyan beállítással (ugyanolyan programautomatika) készített képeken is különféle táblázatokat használt. Pláne nem egységes két különböző típusú gép Fine beállítása. A kvantálási táblák annyira specifikusak is lehetnek, hogy forensic alkalmazások ebből tudják megtippelni, hogy volt e matatva egy kép, és ha igen, milyen szoftverekkel. Erre később visszatérünk.

A fenti ábrán jól látszik, hogy a kis DCT együtthatók, és/vagy nagy kvantálási osztók esetén nagyobb az esély, hogy 0 legyen a kerekítés eredménye. A kerekítés során elveszett információ a veszteség.  Minél jobb minőségű kódolást alkalmazunk (több 1-es áll a kvantálási mátrixban), annál több  DCT együttható értéke marad érintetlen, kevesebb veszteség lesz, viszont a kvantálás során kevesebb lesz a 0, amit tömöríteni lehetne, tehát nagyobb lesz a fileméret.

Leegyszerűsítve, a kvantálási mátrixban a nagyobb szám szarabb képet okoz, de nagyobb tömörítést.

Tehát a példában -415/16= -26, a -33/11= -3 lesz és így tovább. A kerekítésekben elég nagy veszteség tud keletkezni (ez amúgy is egy közepesen durva beállítás), viszont hatalmas 0-val töltött mezők jönnek létre, ami jól tömöríthető később. Visszaalakításnál pl.  a második elem -3*11 pontosan visszaadja a -33-at, de a -6*10 már nem lesz 58 többé. Sokkal durvább a veszteség ott, ahol 0 keletkezik a kvantálás után, hiszen ott az eredeti AC érték már egyáltalán nem állítható vissza. A DC értékét is érintheti a veszteség, ez pl. a 8*8-as blokk tónusában, colorshiftben mutatkozhat meg.
Amennyiben az összes AC értéke 0 lenne a kvantálás után, az egyben azt is jelentené, hogy a 8x8-as blokkunk tónusa (vagy színe, ha a chroma csatornáról beszélünk) kiátlagolódott, hiszen akkor csak a DC érték állítható vissza.

Összefoglalva: a kerekítés során elveszett információ tehát a veszteség. Ha a kvantálási táblában csupa 1-es állna, az azt jelentené, hogy nem történt veszteség (de igen, egy kevés  a lebegőpontosról átalakítás miatt is lenne), viszont a kevés 0 érték miatt tömöríteni se fog túl sokat az eljárás.

A legtöbb veszteség tehát ennél a lépésnél keletkezik a folyamatban, emiatt egy JPEG más eszközön (más kvantálási mátrix) történő egyszerű újramentése is újabb veszteséget fog okozni. Minden JPEG file hordozza magában a kvantálási mátrixot, amivel kvantálták, hiszen csak így lehet visszafejteni amikor megnyitjuk bármiben, ezért a JPEGsnoop-al ki is lehet nyerni belőle, hogy össze-vissza hasonlíthassuk:

A PS kvantálási mátrixai, 12-es és 0-ás tömörítési szintek esetén.  

Érdekes a fenti ábrán, hogy a legdurvább tömörítésnél (0 szint) sokkal nagyobb együtthatókkal operál az alacsonyabb frekvenciák (bal felső) felé, ami ellene mond annak az elvnek, hogy a nagyfrekvenciákat jobban ki lehet gyomlálni, míg a 12-es, jó minőségű kvantálás eredményező táblában pont fordítva, a magasabb frekvenciákra (jobb alsó) ad nagyobb együtthatót. Erről értekezhetnénk, ha lenne bárki, aki eddig elolvasta volna ezt a bejegyzést... Dzsida is ezt érezte.

"Körülnéztem: szerettem volna néhány

szót váltani jó, meghitt emberekkel,

de nyirkos éj volt és hideg sötét volt,

Péter aludt, János aludt, Jakab

aludt, Máté aludt és mind aludtak...

Kövér csöppek indultak homlokomról

s végigcsurogtak gyűrött arcomon."

JPEG alapok 2 blokkosítás és a diszkrét koszinusz-transzformáció

Előzmények a RGB - YCbCr átalakítás. Ebben a lépésben még sem veszteség, sem tömörítés nem történik. Sőt.

2. Következő lépés a keletkezett három új csatorna (Y/Cb/Cr) 8X8-as blokkokra történő szegmentálása (MCU - minimum coded unit) - ezek határainak elhelyezkedésén sok fog múlni, ideális lenne ha a kép X és Y irányban is osztható lenne 8 pixellel. Mivel a fényképezőgépek mind tudnak JPEG-et menteni, adta magát a kérdés, hamar csekkoltuk is, minden gépünk maximális felbontása felosztható 8x8 egész számú többszöröseire. Gondolom erre a gyártók figyelnek, ha nektek van olyan gépetek, ami nem ilyen, írjátok meg. A wiki szerint a 8x8-as bontás oka történelmi, az IC technológia ezt tette lehetővé, és mivel bevált, azóta is ez maradt. Máshol azzal magyarázzák, hogy a 16x16 túl komplex lenne. Amennyiben a képet már megfaragtuk és már nem osztható maradéktalanul nyolccal, a csonka (<8pixel) blokkokat kiegészíti (padding), hogy a műveleteket el tudja végezni, majd trimmeli, hogy te ne vedd észre a trükköt

3. DCT - diszkrét koszinusz transzformáció, na ez a rész eddig a legdurvább, pedig ha sikerül megérteni, akkor egyszerű. Mindenesetre nem azért diszkrét, mert kevesen értik és azok sem beszélnek róla. Tele van vele az internet.

Lényege, hogy az adatokat különböző frekvenciájú koszinusz hullámokkal írja le. OK, mindjárt találunk rajta fogást. Lássuk mit értünk a képen kis és nagyfrekvencia alatt.

A képen alacsony frekvencia (luminanciában vagy kromában) jellemzi azokat a területeket, ahol a változás lassan (nagyobb felületen) következik be (pl. egy világoskék ég degradéja a sötétebb felé), vagyis itt nagy a hullámhossz. Nagy frekvencia jellemzi viszont a finom részleteket, ahol a változás akár pixelről pixelre történik (pl. apró pixelméretű fűszálak, pixelméretű sakktábla), ez rövid hullámhossz. A nagy frekvenciás komponensek a zaj-szerű képződmények, kis frekvenciásak a blokkon átívelő képződmények.
Más megközelítésben a képi elemek szélei mentén nagyfrekvenciás (pl egy lapi széle), a homogén felületeken alacsony frekvenciás komponensek vannak (a lapi felülete, amennyiben nem durván textúrás, mert az szintén magas frekvencia lenne).

Azt olvastuk, hogy az emberi látás sajátossága, hogy a szélek érzékelése lerontja a veszteségből adódó hibák észlelését, sokkal feltűnőbbek, idegesítőbbek a veszteségek a homogén felületeken. Ezt lehet ha majd később ellenőrizzük, egyelőre elfogadjuk. Ha sikerül szétválogatni a kép (még mindig 8*8 pixelről van szó!) komponenseit frekvenciák szerint, akkor külön lehet kigyomlálni a nagy- és kisfrekvenciás összetevőket, a nagyokat sokkal jobban lehet ritkítani, az alacsonyabbakat kevésbé, az emberi szem érzékenységével és a vállalt veszteséggel összhangban.

Nagyobb és kisebb frekvenciás blokkok a kép különböző részeiről.

Mellesleg a hibrid képek is az emberi látásnak ezen a jellegzetességén alapulnak, egyik képnek az alacsony, másiknak a magas frekvenciájú komponenseit keverik össze, de hibrid képekről majd máskor lesz szó.

Lássuk gyakorlatban a fenti elméletet. A képlettel inkább nem fárasztom magunkat. Inkább sok-sok képernyőképpel fárasztom. Nekünk így sikerült megérteni a dolgot. Egy dimenzió mentén így lehet leírni hullámmal egyetlen pixelsort.

Forrás 

Forrás. Példaként egyetlen dimenzió mentén a képpontok ezzel a hullámmal írhatóak le jó közelítéssel. 

(A mélyebbre hatoló anyagok a neten mind megmagyarázzák, miért is nem Fourier transzformációt használunk, de mivel bennünk fel nem merült volna, hogy magunktól azt használjuk, ezért arra nem térünk ki).
A fenti két példa végtelenül leegyszerűsített, egyetlen pixelsort mutat, olyan szerencsés értékekkel amelyek egyetlen függvénnyel leírhatóak. A valós képeken bonyibb a helyzet, egyetlen függvénnyel általában nem írhatóak le teljesen, de több függvényt kombinálva kialakítható a megfelelő alakzat:

Forrás. Itt két függvénnyel (piros görbék) írja le a komplexebb fehér görbét.

A koszinusz függvény a képekre (és hangokra) nagyon jól alkalmazható, a valós (organikus) képek viszonylag kevés koszinusz függvénnyel leírhatóak. Egy nyolc pixeles sor legfeljebb 8 darab függvény kombinálásával. De nekünk 8*8 pixeles tömbünk van, tehát a transzformáció két dimenzió mentén történik (x és y tengely), tehát 64 lehetséges függvényünk van, ami a blokkot leírhatja.
Tehát 64 darab adat helyett  (amit egyenként 8 biten kódoltunk 0-255 lépésben), most lett 64 másik adatunk, amiket már  jóval több biten tárolunk (-1024-től 1023 szintek). Egyelőre nagyobb lett csak az adathalmaz, de majd később ez is megoldódik.

Az ábra engem sokáig megtévesztett, a 64 különféle függvény patterneit egymáson kell elképzelni, egymás hatását erősíteni illetve lerontani fogják, így jön ki a végleges 8*8 pixeles kép. Természetesen nem minden esetben használjuk az összeset. Amennyiben csak a bal felső pontunkhoz (DC) rendelünk értéket, az összes többi 63 mező (AC értékek) a mátrixban nullás, akkor a 8*8 pixelünk gyakorlatilag olyan tónusú lesz, mint a bal felső érték. Sima homogén tömb. Ha csak a bal felső és jobb szomszédja kap értéket, akkor egy vízszintes átmenet fog megjelenni a blokkunkon és így tovább.

Összegezve, a bal felső pont kitüntetett (DC) ez a tömbünknek az átlaga. A többi érték (AC) azt adja meg, hogy az adott függvény milyen mértékben (egyáltalán, kicsit, nagyon) vesz részt a blokk kialakításában. A wiki példája egy 8*8 pixeles A betűt ír le. Az alábbi táblázat pedig azt mutatja, hogy az A betű formáját melyik függvény milyen arányban írja le.

Forrás. A wiki példája egy DCT mátrixra, ami egy A betűt formáz.
Van ott mozgó-gif is,
nem lopom ide azt is, de nézzétek meg, szemléletes.

Ez azért jó, mert egy 8x8-as blokkban általában nincs nagy szórás, valós esetben a blokkokban egymáshoz elég közeli pixelértékek szoktak lenni (az AC értékek nem lesznek túl nagy számok, ez a későbbiekben jól jön).

Ugyanaz a képrészlet 0 illetve 12-es tömörítéssel.
Ilyen brutális kvantálás mellett az alapfüggvények elég jól kivehetőek annak ellenére, hogy
ez már itt RGB-ben van.

Ha minden forrást végigolvastál és néztél, és még mindig gondot okoz a lényeg megsejtése, akkor van ez a jó kis jávás eszköz, amivel vizualizálni lehet a DCT-t. A DCT -1024..+1023 között vehet fel értéket, a kép meg 0..255 között.

Fehér blokk esetén a DC is maximális, az AC-k viszont zérósok, a képen nincs semmilyen eltérés.

Fekete blokk esetén a DC is mnimális, az AC-k viszont zérósok, a képen nincs semmilyen eltérés.

A blokk egyetlen fekete pixelt tartalmaz, 1x0+63*255/64 = 98%.
A baloldalon tehát megjelent a blokk átlaga (2048-nak a 98%-a) = 984 (-1024-től)
Az alacsony frekvenciás értékek -44-től haladnak  a nagyok felé -2-ig (jobb alsó sarok)
(alig 2-3%változás van a teljes blokkon, a képen szinte egybefüggő szürkének látszik, de nem az). 

A DC a blokk tónusának átlaga, látszik, hogy x tengelyen nincs AC,
y tengelyen is leginkább az alacsony frekvencia  (második sötét pötty) dominál a lassú átmenet miatt

Itt az x tengelyen a nagyfrekvenciák dominánsak (főleg a jobboldali érték miatt), y tengelyen meg semmi történik.

Az előbbi pattern inverze. Itt is a jobboldali magas frekvenciás függvény dominál de ellenkező előjellel (jobboldali fehér) 

A DCT transzformáció oda-vissza, a leírások szerint nem okoz veszteséget, annyira nem látjuk át, hogy ezt cáfoljuk. Igazán kockáknak az internet tele van programkódokkal, mi ennél jobban nem akarunk belemenni. Különben is 17 éve programoztunk utoljára, miért pont most kezdenénk újra.

JPEG alapok 1 - RGB - YCbCr átalakítás.

Az utóbbi időben lépten-nyomon beleszaladunk a JPEG meg nem értésébe. Akár metaadatok, akár fileba rejtett tartalom a téma. Úgy tűnik, addig nem bírom elengedni ezt, amíg a végére nem járunk, ha csak felületesen is.
Csak akkor érdemes tovább olvasnod ezt a sorozatot, hogyha te sem tudod, miért van a PhotoShopban 13 szintre mappelve a JPEG tömörítés 0-100% helyett, ha azt gondoltad a 6-os érték kisebb és gyengébb filet eredményez, mint a 7-es, nem tudod, mi történik, hogyha többször újramentesz egy JPEG-et, ha 12-es szintre mented a képeidet, függetlenül attól, hogy gőzöd sincs milyen tömörítéssel dolgozik a kamerád, mondván az a legbesztesebb, meg ilyenek. Hanem ne. De tényleg. Elég kocka lesz. Még én se értem. És nem kívánok sérvet kapni a szakkifejezések magyarításával sem. Tudjátok, 2-3 ember olvassa úgyis.

RGB csatornák

YCbCr csatornák

1. Első lépés RGB-ből YCbCr színtérbe történő konverzió. Ez a fényességérték és színkülönbség értékek szétválasztását jelenti, hogy külön lehessen őket tömöríteni, a luminanciát kevésbé, a krominanciát jobban (ez még külön subsamplinget is kaphat) -  ez a folyamat az emberi színlátás és kontrasztlátás közötti különbséget aknázza ki, vagyis hogy érzékenyebb a luminancia, de kevésbé a színek változására.
Ezért lehet például a színcsatornákat subsamlingelni.
Azon kívül az emberi látás a nagyfrekvenciás jelekre kevésbé érzékeny, mint az alacsonyakra Ezt szintén ki lehet használni a DCT átalakítással és a kvantálással).
Tehát egy luminancia csatornára, egy kék-sárga, illetve egy piros-zöld csatornára robbantják az RGB képet. A PhotoShop nem tud YCbCr színtérbe váltani (vagyis de, amikor a JPEG-et bergeti, de ahhoz nem férünk hozzá), a JPEGsnoop képernyőképei mutatják kb. miről van szó. Aki játszani akar a konverzióval, annak itt egy online eszköz, menthet vele YCBCR kiterjesztésű mamutfilet (de semmiben sem fogja tudni megnyitani). Kísérletezhet a wiki képleteivel is, nekünk sajnos nem sikerült kitalálni, pontosan hogyan is működik a képlet (sokféle szabvány, mindenhol mást mondanak stb.), de legalább az vigasztalt, hogy sokan elakadtak itt.
Egyetlen követhető képletet találtunk, mondjuk pont azon az oldalon, ahonnan a JPEGsnoop is származik, na ez legalább konzisztens önmagával, pár színre ki is számoltuk:

Forrás: innen A Cb és Cr csatornák értékei -128...+127 között lehetnek, tehát az eredményeihez +128 dukál,
hogy a PS-ben mért értékekkel meg lehessen feleltetni. 

Hogy minden színt ne kelljen kiszámolni és legalább az alapszínek leképezésével képben legyünk, csináltunk egy ilyen színskálát a JPEGsnoop segítségével (már amennyiben az etalonnak számít). Ha ti tudtok tutibb képletet, vagy konvertert, írjátok meg.

Fenti két sor RGB, alatta Y, alatta Cb és Cr

Ami világosan látszik, hogy a fehér szín (R0G0B0) esetén Y=0 (és nem 16 ahogyan állítják pár helyen). A Cb és Cr = 128. A fekete szín (R255G255B255) Y értéke szintén 255, a Cb és Cr pedig szintén 128. Tehát a fekete-fehér árnyalatokat csak a luminancia (Y) képezi le, a színcsatornákon pedig a 128-as középértéktől nincs eltérés.

A piros (R255G0B0) luminanciája 76, a zöldé (R0G255B0) 149, a kék (R0G0B255) pedig 29 (hogy miért ennyi, volt már róla szó). A Cred csatornán a piros szín a red tengely irányába tér el -128-al (lesz fehér), a Cblue csatornán pedig a kék szín lesz -128, vagyis fehér. A többi szín betagolódása a tengelyre már bonyibb, egyelőre elég ennyi.

Azt is olvastuk, hogy a képlet szerint a csatornák pixeleinek értékei összefüggnek (az Y értékén keresztül), ezért csak bizonyos értékeket (kombinációt) vehetnek fel, amennyiben tetszőleges értéket adnánk, előfordulhatna, hogy az a szín kívül esne az RGB színterén, ennek most nem járunk utána, meg úgyse tudunk belepiszkálni ezekbe az értékekbe.

Az YCbCr-ről nem találtam, hogy hány byteon tárolja az infókat, de a fileméret alapján ugyancsak 24 bit (3x8) lehet. Mindenesetre 256 szintet tud a képletek szerint. Ebből arra következtetünk, hogy a színtér konverziója is veszteséggel jár, ha pár színre kiszámoljátok az értékeket tutti beleszaladtok pár felkerekítésbe, a visszaalakításnál meg gondolom szintén vár pár kerekítés. Gondoltam a fent meglinkelt konverterrel készített YCbCr filet visszakonvertálom TIFF-nek és egymásra szűröm (difference), hátha látszik a kerekítésből származó különbség, de a majom konverter a saját maga által készített filet nem tudja visszaalakítani. Ciki.

* UPDATE - találtunk egy sokkal egyszerűbb képletsort RGB-ből YCbCr-be és vissza alakításra.
Y = 0.299 R + 0.587 G + 0.114 B
Cb = - 0.1687 R - 0.3313 G + 0.5 B + 128
Cr = 0.5 R - 0.4187 G - 0.0813 B + 128

R = Y + 1.402 (Cr-128)
G = Y - 0.34414 (Cb-128) - 0.71414 (Cr-128)
B = Y + 1.772 (Cb-128)

A következő lépések később, még nem értem a végére én se. A többi cucc még durvább lesz :)

Nyald ki a seggem Ceauşescu!* - költészet és kényszer

Nem az első eset, hogy közszolgálatot vállal az Utazások. Az van ugyanis, hogy az alábbi verset sehol sem találja az internet. Ezen most segítünk. Emlékszem '86-ban, anyám izgalmára, ahogy hazajött munkából és mutatta az újságot, meg lelkünkre kötötte, hogy ezt soha senkinek nem szabad elmondani, de né, összeolvasva az első betűket a versben, hú ez valami hihetetlen rákendroll. Jocónak köszönjétek, hogy megőrizte a HUNGARIAN HUMAN RIGHTS FOUNDATION pdf-jét. 

Amúgy, az az urban legend keringett, hogy az eset után a költőt elütötte véletlenül egy autó, de erre semmiféle bizonyítékot nem találtunk, csak arra volt utalás, hogy pofozgatták a vers miatt egy darabig a szekuritátén. Nem tudom ő mit gondolt, végül megérte e, ha valaki tud valamit, írja meg a hozzászólásokban.

Ímé tehát Murgu Pál akrosztichonja, ahogyan az a Hargitában megjelent 1986. január 26-án. 

Jövőnk Hitével

       Nicolae Ceausescu
      elvtárs tiszteletére

Januárban fölragyog

kibontakozóban a jövő e tájon,

ölti hajnalok fényességét,

létrelobban milliók hitében,

testesül majd földnek tavaszában,

érik gyümölccsé gazdag őszében.

Szilárdul bennünk is a tettek vágya,

ereinkben munkál a tűz,

testvéri összefogásban erősödünk,

él mibennünk a Jövő, újjászületik

sorsunkat örökre összefogja.

Köszönt ma Embert, köztünk az Elsőt

éltető szívünk minden dobbanása

nyílik lelkünkből a szeretet

száll a hála vallomása;

ez a mi jövőnk, januárban ragyogó

remény halhatatlan szavaival:

Románia, Ceausescu, pártos hitünk!

                                       Murgu Pál

* Mire is utaltunk a címben?

A nevem Pix. Grim Pix. - szteganográfia vs marking vs kriptográfia

"Maradj fölöslegesnek,

a titkokat ne lesd meg.

S ezt az emberiséget,

hisz ember vagy, ne vesd meg."
 J.A.

A világ túlontúl érdekes és a megismerés valóban olyan, mint a lufi, mentől nagyobbra fújod, annál nagyobb felületen érintkezik a nemtudással, tehát még több érdekes dolog tárul fel, mihelyt egy új dologgal foglalkozni kezdünk.

Mostanra világossá vált, hogy a szteganográfia nem alkalmas a képek tulajdonosi megjelölésére (watermarking). Markingnál kevés információt kell redundánsan (átméretezhetőség, vághatóság miatt) a képbe oltani, nem cél viszont rejtjelezni, csupán az élvezhetőség határán belül kell tartani a keletkezett zajt. A szteganográfia pedig a feltűnés kerülésére, a nagy adatátviteli kapacitásra gyúr, a kriptográfia plusz biztonságot adhat ugyan, de ellene is dolgozik, gyanús patterneket hoz létre a fájlokban, amire reagálhatnak a robotzsaruk. Érdemes megnézni John Ortiz előadását, hogy átfogó képet kapjunk erről a világról.

Hull a hó. Fú' a szél.,
Dimitrij Lénáról mesél.

Szteganográfia esetén az az elsődleges célunk, hogy a carrier úgy legyen jelen a kommunikációban, hogy ne ébresszen gyanút. Pl. ha nehézvízgyártási terveket osztanál meg, akkor érdemesebb egy AdamSandler szitkomba kódolva torrenteztetni, mint például az Anarchist cookbookban. Az messze nem elég, hogy szemmel, vagy füllel nem észlelhető a turpisság, a sötét oldal droidokat használ ellened. Ha már felkeltetted a gyanút, akkor a másodlagos cél már a tartalom védelme (tagadhatóság, kriptáltság). A sötét oldal nézőpontjából az elsődleges cél érzékelni a titkos tartalmat, amennyiben lehet megfejteni, ha meg nem sikerül, akkor megsemmisíteni. A felderítésre rengeteg lehetőség van, elvileg csak az erőforrások szabhatnak határt (pl. jelszó bruteforce), meg az, hogy milyen messzire hajlandók elmenni érte (csak bebörtönöznek, vagy egyenként törik el a csontjaidat - ez lenne a social bruteforce?). A felderítésben sokat segít, ha már gyanús vagy, ha hozzáférnek a számítógépedhez (milyen programokat használhattál a titkosításnál), ha megszerezhető az eredeti carrier fotó (sose használj netről lopott képet), vagy a gépeddel készített más fotók (az összehasonlítás sokat elárul a hozzáértőknek), ezekkel is jelentősen le lehet rövidíteni az eljárást. Statisztikai analízisekkel is lehet bombázni a carriert, ezek a módszerek majd előkerülnek az Utazásokban, amikor a képek retusáltságának vizsgálatával foglalkozunk majd.

Silent Eye gyorstalpaló

Bár mi a képekhez értünk inkább, titkot rejteni érdemesebb hang, illetve videó fájlokban, ahogyan az Al kaida is teszi, bár állítólag orosz kémhálózat is bukott már képi sztegano-kommunikációval. Az azért kijelenthető, hogy a bukást általában a social részben elkövetett baklövések okozzák (pl. sose tarts a gépeden gyerekpornót merényletek terveivel beoltva).

A SilentEye ebben a témakörben az egyik legtöbbször meghivatkozott program. Az ábra szerint a Least Significant Bitben rejti el az üzenetet. Nem tudom ezzel az ábrával mi volt a céljuk, de, hogy nem a JPG kódolásáról szól, az fix. Na mindegy, az elvet nagyjából körülírja. Ebbe most nem mélyedünk el, az alsó helyiérték elvileg nem okoz ekkora látható minőségvesztést, sajnos a tapasztalat azt mutatja, hogy itt még valami csúnyán közrejátszik, mert bizony de.

Ebben az 1600px széles képben rejtettük el Fodor Ákos Titok című haikuját (kb 150 karakter). A kép homogén felületein zaj formájában (egereld meg az alábbi rollovert) jelent meg a vers. 5-ös Luminance interval érték mellett is (40 a maximum) ekkora ormótlan foltok keletkeznek a képen.

Viszont emiatt jól bírja a kép újratömörítését, kár, hogy egyáltalán nem viseli az újraméretezést illetve a cropot. Ez nagyjából kizárja, hogy facebookon illetve olyan oldalakon használjuk, amelyek átméretezik a képeket.

Ez is egy ok, amiért a facebook teljesen szétzsigereli a feltöltött fotókat. A program még tud fileokat is beágyazni, meg plusz biztonsági opcióként kriptálni is az elrejtett adatokat (ez a funkció nálunk lefagyasztotta a programot). 

Na mindegy elég komolytalan cucc, nem kell ide semmiféle statisztikai steganalízis, ordít a fotóról, hogy valamit elrejtettek benne. És akkor már csak idő kérdése addig pofozni a feladót, vagy a címzettet, amíg az sírva szavalja el a beledugott Fodor Ákos verset.

Cserébe az OpenPuff kicsit többet ígér. Itt alap a kriptálás. Még csali-payloadot is lehet bele rejteni, látszik, hogy ezek már nem kispályások. Tehát amikor a hárombetűsök nagy fekete autója megáll a ház előtt és szólnak, hogy érted jöttünk elvtárs, nem ellened, akkor megspórolhatsz magadnak egy herevasalást és már pár lightos tasli után bevallhatod a csali-jelszót, amitől hoppácska, előkerülnek a latexes képeid piros pingponglabdával a szádban. Inkább nézzenek buzinak, mint anarchistának, ugyebár. Sakkor még ők kérnek elnézést, s a államhatalom megdöntési terveid továbbra is rejtve maradhatnak. Na, látom én már nem kapok beutazási engedélyt az Államokba.

Nevetel, pedig böribe lehet kerülni, ha nem adod ki a titkosítási jelszavaidat rendőri felszólításra. Ha nem bizonyítható, hogy rejtett tartalom van a képedben, akkor ezt meg lehet úszni. Egyszerre több (sok) carrier-fileba is rejthetjük a cuccot, azok sorrendjét is szempontnak állíthatjuk a visszafejtéshez. Ha mondjuk elárultad már a három jelszót, de már elfogytak a letéphető körmeid, vagy mégis sikerül végül ráharapni a ciánkapszulára, akkor majd vakarhatják a fejüket mondjuk 100 darab kép, vagy a Szomszédok-összes sorba permutálgatásával. Pláne, ha nem mindenikbe teszel rejtett tartalmat, azzal végkép letesztelheted, hogy áll a kombinatorika oktatás a rendőrakadémián.

Ezenkívül még pár érdekes praktikát alkalmaz, amivel igyekszik kijátszani a felderítő programokat, érdemes elolvasni a használatit. Persze nem biztos, hogy nem veszik észre, hogy bibi van a képeiddel. Ezért érdemes olyan jelszavakat használni, amit nem lehet bruteforce-olni könnyedén. Na mindegy is, a baloldali 1600 pixeles képben a J.A. Tiszta szívvel versét rejtettük el, és csalitartalomnak pedig a TNT Titkos üzenet refrénjét, csak hogy az előbbi szcenárióhoz stílusban hűek maradjunk (hát kettejük közül nem a TNT az anarchista, az fix). Nem csinálok ebből rollovert, szemre nem látszik  a képen, hogy rejtve van benne valami. A jelszavakat nem árulom el, ha visszafejtitek, akkor szóljatok az OpenPuffnak is. Sajnos nem bírja az újratömörítést és a cropot sem, tehát facebookon nem küldhető továbbra sem.
A hárombetűsök is tudják ezt, így a facebook sávszélességet spórolt magának, viszont gyanítom a Flickr-re és hasonlókra külön odafigyelnek a sötét oldal drodjai.

Az OpenPuff alkalmas szöveges marking belekódolására is a képbe, ami lehet pl. egy digitális vízjel alternatíva. Sajnos ez sem bírja az újratömörítést, skálázást, vágást.

Szóval ez a program eddig a legszimpibb, csak most kellene egy bátor ember, aki végignézi a sourcot (amúgy open), hogy nem e küld minden rejtjelezésnél egy üzenetet is pl. az NSA-nak, mert az milyen, hogy lelépsz a boltba csirkefarhátért, de már Guantanamon eszed meg papírtasakkal a fejeden?

A sötét oldalnak tehát megvannak az eszközei a rejtett tartalmak felderítésére. És mivel ők szervezetek, hisz nem emberek. megvethetik az emberiséget. Robotkutyáikat ránk szabadítják. Pl. árulkodó a zajeloszlás jellege, az LSB cikk-cakkos görbéje, a DCT histogramm is beszédes lehet. JPG esetén a blokkosodás, BMP esetén a fuzziness buktathat le, akkor is, ha az szemmel nem látható.

Szóval nem biztos, hogy jó ötlet első szerelmes verseidet, bármilyen ciki rímek is legyenek benne, ilyen formán őrizni a felhőben, mert lehet, ha holnap már úgy fog bemutatkozni az új bejárónőd, hogy - A nevem néni. Mari néni.

Pléhszemű TinEye és a rövidlátó GoogleImage - avagy #reverse image search bullshit

Lopott képkergetéssel már foglalkoztunk az Utazásokban. Akkor saját képeinket nem sikerült megtalálni, lássuk mi változott az elmúlt hat esztendőben. Aki unja végigolvasni, annak itt a rövid összefoglaló: semmi változott. Viszont ha érdekel, hogyan sikerül Grimpixnek felidegesedni a végire, akkor olvassátok tovább. A képek keresztül-kasul lopkodásának erkölcsi vonzata nem kifejezetten a témánk, de a hozzászólásokban erről is lehet majd szó. Úgyse ír témába vágó kommentet a kutya se.

A témaindító természetesen a Digimarc azon szolgáltatása, hogy levadássza a védett képeinket az interneten. Persze erre nem fizettünk elő, mert kis blog vagyunk, alig 10-15 állandó olvasóval (a kocka cikkeket max. 2-3 ember olvassa velem együtt), lássuk tehát, milyen lehetőségeink vannak még. 

Az Image rights pontosan ezt ígéri. Levadássza a lopott képeinket, segít jól kisemmizni a tolvajt, aztán a kártérítésben is segít osztozni. Két fotót töltöttünk fel, ami tuttibiztosan megvan az interneten. Még nem szóltak, hogy megtalálták volna. Frissítünk, amint változik valami. 

Gyakorlatilag Grimpixnek alig vannak fotói az interneten a Flickr és a Blogger kivételével. Amiről meg nem tudunk, nem fáj, hogy egy igazi classicust idézzünk pontatlanul. A továbbiakban is kizárólag olyan képeket kerestünk, amiről tudom, hogy több éve fent vannak az interneten, tehát lett volna ideje a robotoknak beindexelni, ha a sok robotkodás közben éppen réaértek volna. És nem vártam el, hogy a facebookon is keressenek, de azért lecsekkoltam. Nem találnak. Nem tudom van e köze hozzá a Facebook robots.txt tartalmának:

# Notice: Crawling Facebook is prohibited unless you have express written
# permission. See: http://www.facebook.com/apps/site_scraping_tos_terms.php 
... és itt csomó tiltás következik névreszólóan a robot uraknak.

A robots.txt egy újabb érdekes téma lenne, esetleg visszatérünk erre, Grimpix robots.txt-je jóval liberálisabb.

Az egyik tesztképünk Budai Péter kollégánknál található meg, meghivatkozva, ahogy kell. A bakancsos kép a Fotótanúban, szintén meghivatkozva és az Utazásokban is, ahonnan ered. A Pléhkrisztus-kép pedig megvan az Utazásokban és felhasználta (hivatkozás nélkül illegálban) az MNA honlapja is, a jövőnk.info, ami azóta megszűnt. Beszédes perspektíva, mi? Persze ezen is csak egy ilyen dekadens ballibsi tud viccelni, mint Grimpix. Na mindegy, erről a képről  screencapture se lesz, mert semelyik nem találta meg sehol. 

A TinEye nem hasonlókat keres, hanem ugyanazt. Bevallottan a kép ujjlenyomatát vadásszák, nem a metaadatokat. Változatokat is fel tud kutatni, crop, resize, meg minden. Sajnos mi ezt nem tudtuk megfigyelni, ami vagy azt jelenti, hogy tökéletlen a robotjuk, vagy azt, hogy a világ leindexelt pármilliárd képében sem vagyunk benne, ami elég ciki. Ezzel szemben a Google, Bing  és társai (más megközelítés miatt) hasonló képeket is felajánl. 

Érdekességek:

- a bakancsos képet a gugli csak és kizárólag a Fotótanú oldalon hajlandó megtalálni, pedig egyértelműen az Utazásokból volt letöltve. Gondoltam letöltöm az Utazásokról is, hátha a keresett file nevét is beleszámítja a keresésbe, de akkor is csak a Fotótanún levőt találja. Ezek után konkrétan az Utazásokból jobbklikkeltem ki a képet (van erre Chrome plugin, használjátok egészséggel). Hát úgyse.
És az micsoda, hogy "fa"? Mi az, hogy fa? Milyen fa, bazmeg? Ez volt a legjobb tipped? Normális? Ezen a képen még egy fogpiszkáló sincs, de legalább jó gyors találat volt: 0,64mp.  

- a retyis képet mindkét kereső megtalálta a retyis oldalon (máshol nem tudok róla, hogy lenne), nem tudni, hogy ez Péter kollégánk érdeme (ha olvasod, várom az ötletedet), vagy véletlen. Ugyanis a TinEye semmilyen más képemet nem tudta beindexelni sehonnan.  Próbahipotézisem, hogy a zéró marketinget használó oldalak (Utazások) ejtve vannak a keresésben.

-azért a guglinak sikerül elkápráztatni is olykor. Egyrészt képes volt végre megtalálni a képemet a saját portáján (!), másrészt ezennel felismerte a helyszínt is. 

Persze nemcsak ezeket a keresőket próbáltuk ki. Az Imageraider konkrétan semmit talált. A Bing is se. A Yandex dettó. Csak tudnám mi a jóistent csinálnak az orosz robotok az Utazásokon, mi? És nem ketten-hárman jönnek, hanem több mint tizenötezren. Mi ez, fesztivál robotoknak? Ruszki robotok, haza! Hogy a jó durva anódját az összesnek. Az amerikai robotok meg tizenkilencezren, hogy a rozsdatemető plazmavágója fényeskedjen nekik is, örökkétig. A Baidu töketlenkedésein ezután már meg sem lepődtünk. Az meg külön sértés, hogy a hasonló képtalálatok között sokkal jobb fotók vannak, mint az enyémek. Persze ha a reverse image search-re rákeresel, akkor csupa sikertörténetet fogsz találni a neten. Pedig jelenleg úgy fest, hogy ezek a technológiák nem érnek egy kalap $#@®┬. Vagyis de. Pont annyit.

Digimarc® - egy vízjel alternatíva?

Ha ezt letöltöd, elvileg a 123456789 számsort
kellene tudnod kiolvasni a  képből. 

De gustibus non est disputandum. - mondja az okosság, és már meg sem lepődünk rajta, hogy ez is mekkora érvénytelen közhely (mint a latin mondások zöme). A kép keresztül-kasul feliratozása ízlés dolga. Hogy kölcsönöz e (ez a kifejezés is milyenmár) professzionális jelleget a műnek, van e olyan vízjel, ami minden képre illik, megvitathatjuk a hozzászólásokban, itt pusztán a szerzői jog védelmi funkcióira szorítkozunk. Amit szeretnénk: a kép az interneten keringve, átdolgozva is hordozza az eredet-azonosításhoz szükséges információkat. Ezek az információk lehetőleg automatikusan is kereshetőek legyenek az internet hozzáférhető részén. 
Egyértelmű, hogy a képre ráírni valami érdekes betűtípussal, hogy énegó photography, az nem vízjel, de a köznyelvben azért mégis. Lopás ellen nem véd, retusálható, levágható. Ezt meg lehet nehezíteni sok apró részlet használatával lehetőleg nehezen retusálható helyeken, azonban ezzel arányosan romlik a mű élvezeti értéke. Tehát a továbbiakban ezzel nem foglalkozunk, ez a fajta aláírás annyira komoly, mint amit Dexter és Dee dee művelnek, amikor minden tulajdonukat felcímkézik míg végül Dexter homlokára is Dee dee címke kerül (s2e7).

Az ábra egy négyszeresen  nagyított részlet,
 100%-ban nézzed. Bal oldala digimarc nélküli,
 jobb oldalán észlelhető a digimarc zaj.

A vízjel témakörnek már nekiszaladtunk, úgy hat esztendeje. Akkor elterelődött a téma és a színkódolásnál nem jutottunk tovább. Viszont már akkor is felmerült a Photoshopba implementált Digimarc® technológia lehetősége. A gyakorlatban inkább egy vízjel és automatikus képkereső (pl. TinEye) kombójára hasonlít. A digimarc egy azonosítót kódol bele a képbe (főleg chroma) zaj formájában, a fejlesztők szerint elég redundánsan ahhoz, hogy az a kép átméretezése, újratömörítése, nyomtatása után is visszaolvasható legyen. 99 dollár 3000 fotóra. Ebben úgy tűnik nincs nyomkövetés, azt csak az enterprise csomag tudja drágábbért. Szerencsére a demó adatokkal el tudjuk végezni a teszteket, hogy nektek már ne kelljen. 

A legtartósabb (legészrevehetőbb zajt is okozó) kódolást választva 400% nagyításnál elég jól észlelhető egy zöldes-bíbor zajminta. Ebből gyanítjuk, hogy a LAB a/b csatornáiba firkálja bele a cuccot. Ezt ellenőriztük úgy, hogy LAB konverzió után az egyes csatornákat homogén szürkével töltöttük ki. A Lightness csatorna sérülése nem okozott jelromlást. Az a csatorna módosítása alig rontotta a jelet, a b csatorna módosítása valamivel jobban. Mindkét chroma csatorna homogén színnel kitöltése olvashatatlanná tette a digimarcot. Az a és b csatornák blurolása (a kép élvezhetőségének határán belül) viszont csak rontotta, de nem nyírta ki a jelet.

1. nyomtatás 

- egyszerű offset papírra jó minőségben kinyomtatva, majd visszafotózva teljesen elveszett a jel.

- a nyomtatott képet a digimarc telefonos saját applikációja sem ismerte fel. IPhone dettó. Annyira nem érdekelt a dolog, hogy igazi fotópapírral illetve fotóeljárással is teszteljük, gyanús, hogy ott se járnánk sikerrel, pedig elvileg ezt ígérik a Digimarc-nál. Próbálta valaki?

2. monitor
- monitorról sem sikerült az applikációnak meglátni a digimarc-kódot, többféle távolságból és nagyításban próbáltuk. 

- screencapture segítségével. 66,6 százalékos nézet esetén, a Photoshop pluginnak már sikerült kiolvasnia az információt az eredeti kép negyedéből is. Kisebb nagyításoknál azonban nem.
Érdekességek:
- a black/white szűrő után rengeteget romlott a jelminőség, gondoltuk, ha ezt kombináljuk átméretezéssel, ami szintén jelromlást okoz, akkor esetleg el is fog veszni teljesen. Meglepetésünkre, a két beavatkozást kombinálva jobb lett a jelminőség, mint csak külön a BW szűrő után.
- RGB to LAB, majd rögtön LAB to RGB konverziók után gyengébb lett a jel. LAB módban egyáltalán nem ismerte fel a jelet. RGB to CMYK esetén viszont erősebb lett a jel, mint RGB-ben alapból volt.

A facebook durva képbeavatkozásaival kapcsolatosan a fejlesztők bár óvatosan fogalmaznak,  mégis kicsit bizakodóak, nekünk nem sikerült facebookról visszatöltött képen olvasni a digimarc jelet. Szóval bár a publikus weben ígérik a képeink nyomon követését, a valóságban ebből a keresésből kizuhan a facebook, vagy legalábbis az ottani képek jelentős része. A bloggerből visszatöltött képen viszont nem sérült meg a digimarc. Még egy ok, hogy bár a blogműfaj halott, facebookon NE posztoljunk képeket.

Mindent összevetve, bár a médiumváltás utáni ellenőrzésre (is) van kifejlesztve, pont a nyomtatás utáni felismerésében bukott meg. Továbbá nem oldja meg a facebook problémát sem, ugyanúgy elvesz a digimarc is, mint pl. a ledörzsölt metaadatok. Ilyen szempontból  a metaadatot használni értelmesebb, mivel a Creator es Copyright notes mezők jelenleg még használhatóak, de mivel a facebookról van szó, ez semmit nem mond el arról, hogy jövőben is ugyanígy marad e.

Tehát kutatunk tovább más megoldások után. Egyéb ötlet?

Titok 1 - Szteganográfia bitmapre

Ok-ok, már az ókorban ugye... Disclaimer: a bejegyzésben a kriptográfria és a steganográfia  össze fognak olykor mosódni. Kéretik a helyükön értelmezni. 

Bizalmas információt sokfelé el lehet rejteni egy hírvivőn, pl. lenyeletni a futárral, lám Henri Charrière, a Pillangó is retikülnek használta a végbelét. Vagy simán csak bemagoltatni a futárral valami hülye archaikus szöveget. Hérodotoszék korában kifejezetten ráérősek lehettek, ugyanis a rabszolga fejére tetováltatták az üzenetet, majd figyelték, hogy nő(l) a haja. A modern korban sokkal gyorsabban lehet titkot továbbítani és az a trükk, hogy a hírvivő fileokat sokkal nehezebb vallatni, nem elég hozzá a hóhéri brutalitás, kell némi intelligencia is. 

A láthatatlan tintás módszert például minden gyermek ismeri. Mi leginkább citromlevet használtunk, bár nem tudom honnét szereztünk, mert akkoriban még kenyeret is csak bonra lehetett venni, pláne nem lehetett kapni fluoreszkáló festékeket, amit azóta a bankszektor is használ. Spéci előhívóra reagáló titkos tintáink sem voltak, cserébe saját írásjeleket használtunk Hatalmas Összeesküvéseink leplezésére, de ez többnyire megbukott azon, hogy beavatott elvtársaink lusták voltak megtanulni az írásjeleket. 

Aztán van olyan titkosítás is, amit álprüdériából kifejezetten motivátorként használnak. Felhívás a megfejtésre. A szöveges szteganográfia amúgy is egy jó móka, s ha már meghivatkoztuk az imént Lúcia pogány farának recsegős bumbummját, ímé itt egy másik Janus-versbe kódolt titkos üzenet a szóközökbe kódolva, bocsesz a béna tördelésért, de átalakítva nem működne a dolog:

ISMÉT ORSOLYA MINDZSÓJÁRÓL      

Mint amilyen magasan nyúlik föl az

égbe Olympus,  

 kétszer olyan mélység nyílik öledben  

elém.  

Ekkora barlangot nem ugatna be       

Cerberus, és nem  

foghatná be kilenc ággal a Styx vize

sem.       

Váltani testvérét nem húzná semmi ki

Castort,

s Alcidest sem erő, s ének a Tráciait.

Hogyha a Főisten, ki felülről szórja a    

három-       

csúcsú s cyklopsok-verte tüzes    

nyilakat,       

ismeri ezt a lyukat, nyilván a  

gigászokat ebbe  

szórja, ahogy Coeust és Iapetust is  

ide.

És ha Apolló ismeri már, Tityust ide

zárja:  

újra-növő máját tépje a saskeselyű.  

Plutó is szivesen látná itt annak az  

ötven-    

torkú kígyónak tátogató fejeit.  

Ám, ha az összes szörny itt  

egybeszaladna is, órjás

mindzsód félig sem lenne velük,

kicsikém.

Na jó, ez így nem fair, adok hozzá kicsikanalat is. Úgyse fejtitek meg. Ugyanitt a spam-mimikri is egy csodálatos ötlet.

Ha neten utánanézel a képekben elrejthető információknak, nyilván a legbanálisabból találsz a legtöbbet. Könnyen belátható, hogy egy lossless képállományban helyezhető el legegyszerűbben a tartalom, ugyanakkor ezek a módszerek a legkevésbé alkalmasak megtéveszteni a gyanakvókat. Mindenesetre, mivel a JPEG fileformátum szerkezetébe már egyszer beletörött Grimpix bicskája, azért megnéztük, miről is szól egy mezei BMP. Készítettünk tehát egy 2x2 pixeles bitmappet és a BMP wiki szócikk alapján dekonstruáltuk annak tartalmát hexeditorral. Nem egy nagy cucc, az ábra mutatja mire lehet számítani egy ilyen állományban.

Ha a színezés nem tenné egyértelművé melyik byte mit kódol, akkor a wiki alapján értelmezhető.

A legprimitívebb módszer, hogy simán a file végére odaírjuk, amit szeretnénk. A képnéző szoftvereket nem fogja zavarni, hogy a kódolt fileméret nem egyezik a valóságossal, simán megjeleníti a képet, hexeditorban pedig feltárul az üzenetünk is.
Az fenti amanitás képet letöltve még az exiftool sem fogja jelezni, hogy üzenetet rejtettünk el benne. Viszont megmutatom mi látszik hexeditorban a file végén, mert úgyse fogjátok magatoktól megnézni, az fix, * UPDATE ráadásul a google a fenti BMP-met úgy átalakította JPG-nek mint a pinty.

Gyakorlatilag még hexeditor sem szükséges, a szöveg hozzáadása elvégezhető command promptból is a copy /b parancs segítségével. Nem nagy varázslat. Ha csak Kovács Jánosnénak kell ezt elküldeni, úgy, hogy Kovács János ne vegye észre az idillt, akkor mondjuk megteszi, bár azért a szöveget nem ártana még rejtjelezni is valamivel, de egy felszarvazásnál komolyabb konspirációra azért már ne nagyon használjátok. Meg aztán ki olyan hülye, hogy manapság BMP-ben küldözgeti a cicis cicás képeket, vagy a szelfiket, mi?

Egy másik érdekes BMP módszer, aminek a megtekintését senkinek sem spórolnám meg, mert segítheti a layerek összhatásának megértését, azon alapul, hogy az elrejtendő tartalmat Index módban néhány (pl. 8) színre redukálja, majd ezen végzett zsonglőrködéssel eléri, hogy gyakorlatilag egyszínűnek tűnjön a kép, de azért mégis őrizze a 8 tónust. Pl. osztja tízzel mind a 8 index-szín RGB értékeit, ettől nettó feketének tűnik a payload, de egy-két bit eltérés mégis megmarad a tónusok között.

Az oldalsó ábrán tehát a legfölső kép a carrier, az alatta levő a payload, amit Grimpixet ábrázolja és preparáltuk 8 színre.

Ezután a payloadot a carrierre tesszük layerként és Difference összhatást alkalmazunk. A bökkenő az, és erre nem tér ki a videóban a kolléga, viszont látszik, hogy olyan példafotókat választott amelyekkel jól működik a módszere, hogy kontrasztos payload esetén, kevesebb átvihető tónussal kell megelégedni, illetve kevés részletet, nagy homogén felületeket tartalmazó carrier nem használható. Jól megfigyelhető Grimpix szeme a harmadik képen, ahogyan átfigyel a narancssárga párán.

Bár a képen észrevehető, hogy valami trükk van vele, a visszafejtés csak az eredeti carrier birtokában (kulcs) lehetséges, ugyancsak a Difference összhatás alkalmazásával. A visszakapott majdnem fekete payloadot ezután Auto Contrasttal, vagy Levels segítségével lehet ismét értékelhetővé rugdosni.

Ám a visszakódolásnál is lehet gubanc, ugyanis amennyiben a carrier hasonló tónusokat tartalmazott mint a payload, ott a visszaállítás hiányos lehet, ez történt a legalsó képen, Grimpix fotója sérült a templom megegyező tónusa miatt.

Bár a módszer érdekes, tekintve, hogy csak BMP-re működik, illetve a fent említett nehézségek miatt, ugyancsak használhatatlan. A téma folytatódik a combosabb JPG-re is működő szteganográfiával, addigis bárki hozzáfűzheti mondandóját, mert mi is csak most mélyedünk el a témában.