Kezdjük ott, hogy a PNG egy veszteségmentes fileformátum. Tehát, amikor mentésnél a fileméretet beállítjuk, akkor gyakorlatilag nem dobunk ki semmit, hanem csak az összetömörítésbe fektetett melót állítgatjuk be, vagyis azt, hogy mennyi időt monyoljon el vele például a Photoshop. És hát azt tapasztaljuk, hogy egy 1000px széles kép esetén a legkisebb fileméret mentése simán 5-10 másodperc is lehet a nagy méret szinte szempillantásnyi mentéséhez képest. Azonban képtartalomtól függően a legkisebb méretre betömörített kép még nagyobb is lehet, mint a gyorsan nagy méretre tömörített. De ha kisebb is, akkor nem számottevően, semmiképp sem annyival, hogy megérje az extra ráfordított időt.
A baloldali kép large mentése 714kb, míg a lassú small size mentése 805kb, tehát még nagyobb is több mint 10 százalékkal. A jobboldali képen picit jobb a helyzet, a large 664kb, míg a small csak 629kb.
Úgy tűnik a problémával más már találkozott, mi nem is futottunk volna bele, hogyha nem hajlítgatni szerettük volna hexeditorban ezeket a filetípusokat. Mert ugye másra a PNG nem túlságosan alkalmas. Állítólag akkor a leghatékonyabb, ha nagy egybefüggő, azonos felületek vannak. Na mindegy.
Hexeditorban (találomra) ugyanazt a 2 byteot cseréltük le a baloldali kevésbé- és a jobboldali jobban tömörített fileokban, az eredmény ennyire eltérő. Érdekes, hogy a jobban tömörített filet kevésbé bántotta a csere, pedig pont ott vártunk volna nagyobb roncsolást.
Itt is a baloldali a kevésbé tömörített, a jobboldali a jobban, szintén két byteot cseréltünk, nyilván nem ugyanannyi előfordulást talál a két eltérően tömörített fileban. Azt is észrevettük, hogy a legelső byteokat nem szereti, ha lecseréljük, sőt a legelejét érdemes kerülni, mert semmi sem fogja megnyitani ezeket a mókolt png-ket, gynítom, hogy a fejlécre érzékeny.
Apropó, a Win10 képnézegetője sokkal jobban elboldogul az így megrontott képekkel, mint az Irfan, pedig a glithelt képeket leginkább Irfannal bontattuk ki, a PS túl kákabélű az ilyen filokhoz. A PNG Hex-hergelésében több fantáziát nem találunk, annyira képfüggő (mennyire részletes a kép) és annyira szerencsefüggő (milyen bytokat cserélünk éppen le), hogy nem akarjuk folytatni a dolgot.
Ez egy érdekes cikk, ami a PNG különféle filteringjeit támadja, sajnos a Processing kódot nem sikerült sehol sem megtalálni. A filteringeket viszont egy PNG Analyzer nevű progi (nekünk megvan, de már a franc se tudja honnét szereztük) meg tudja mutatni, de beavatkozni abban sem lehet.
Nézzük, milyen glitchelő eszközöket találtunk még a neten.
Imageglitcher, ez fogad sokféle fileormátumot, de ez szerintünk csak egy effektus (glitch-alike), egy szűrő, nem igazi adathajlítgatás, mert minden filetípusra hasonló eredményt ad. Effektusnak jó, de mi igazit szeretnénk.
Találtunk még egy
Processinges egyszerű glitchelőkódot, ez is hajlandó elfogadni JPEGet és PNG-t is (TIFFre kifagyott), de tök ugyanazt az effektet adta mindkét filetípusra, szóval ez sem több, mint effekt. Nem ástuk bele magunkat a kódba, de gyaníthatóan a kibontott képet túrja szét, nem babrál a tömörítésekkel. Ha már Processing, akkor
inkább ennek kellene egy esélyt adni.
Futottak még a
Photomosh és a
Glitcyimage, szerüntünk ez sem képes a filespecifikus adathajlításokra, de látványos effektek.
És találtunk
egy ígéretesnek tűnő nyomot, sajnos a cucc Rubyban van és annyira nem akarjuk most megtanulni a Rubyt. De ha már kifogytunk az ötletekből, százplusz évesen, akkor talán elővesszük ezt is. (
Ruby library itt)