Az 1980-as években a Microsoft kifejlesztett egy eszköz-agnosztikus képmegjelenítési megoldást a bitképekhez: A BMP fájlformátumot.¹ Akik korábban a Microsoft Paintet használták, élvezhették az egyszerű vonalakból és színkitöltésekből előállított gigantikus fájlméretet.
A BMP-fájlformátum lényege, hogy minden képponthoz színértéket rendelnek. Ha tehát van egy 480×360-as bittérképem, amely 16 millió színt (24 bit) támogat, A bittérkép mérete végül valahol 4 MB-tól északra lesz.
Ez persze nem ideális, ha több, jó minőségű képet szeretnénk megjeleníteni. Ezért fel kell tenni a kérdést. “Van-e mód a bittérképes ábrázolás optimalizálására úgy, hogy a kép vizuális integritása megmaradjon, de kevesebb erőforrás felhasználásával?”
A válasz igen. Kiderült, hogy a legtöbb esetben a felhasználókat inkább a képek mint vizuális segédanyagok érdeklik, mintsem az alaposság. Tegyük fel például, hogy kapok egy képet a Golden Gate hídról az alábbiak szerint:
Míg tudom, hogy a tényleges híd személyesen látva sokkal nagyobb részletességgel bír, amit itt látok, az is elég jó a céloknak. Tehát a legtöbb ember valójában hajlandó lemondani a vizuális integritásról a sebességért, amíg a kompromisszum elfogadható. Például, ha a szubjektív vizuális minőség romlása 1%, de a felhasználó 90%-os helymegtakarítást élvezhet, az a legtöbb esetben üdvözlendő üzlet.
A bitképek tömörítésének egyik legfontosabb szempontja tehát a vizuális megkülönböztethetetlenség optimalizálása. Vagyis a kép bizonyos elemeinek eltávolítása, ahol a szabad szem nem képes azonosítani a különbséget. Ezt nevezzük veszteséges tömörítésnek, ami a legtöbb tömörítési módot jelenti, amit az online képeken a videostreamingben látunk. Így működnek a H.264, HEVC, HEIF és JPEG kodekek.
A többi képtípus, például a PNG veszteségmentes tömörítést alkalmaz. Ennek lényege, hogy megőrizzük az eredeti kép teljes vizuális integritását, de kevesebb bájtot fogyasztunk ugyanannak a dolognak az ábrázolásához. Vannak azonban más fájlformátumok is, például a WebP, amelyek mind a veszteséges, mind a veszteségmentes tömörítést támogatják. Miért akarjuk veszteségmentesen tömöríteni a dolgokat? A fentiekhez hasonlóan ez is azon alapul, hogy mit szeretnénk elérni a képpel. Például az alkalmazásokban az ikonok általában PNG formátumban vannak (és újabban vektorgrafikus formátumban).
A veszteségmentes képtömörítés nagyobb fájlméretből áll, szemben a veszteséges tömörítéssel. Ennek oka elsősorban az, hogy az előbbi tömörítésére kevesebb lehetőség van, mint az utóbbira. E blog céljaira a veszteséges tömörítésről fogunk beszélni.
A JPEG tömörítés általános lépéseit a mai napig a videotömörítésben végzik. Az évek során az algoritmus fejlődött, de az általános fogalmak ugyanazok maradtak.
1. LÉPÉS. Színtérkonverzió
A képkonverzió a nyers RGB képformátum Chroma (r és b) és Luminance (Y) értékekké való átalakításával kezdődik. Ennek lényege, hogy a szemünk érzékenyebb a fényerősség változásaira, mint a színekre. Ennélfogva ténylegesen képesek vagyunk a kép színtartományának lekicsinyítésére anélkül, hogy ez észrevehetően befolyásolná a kép vizuális minőségét. Ez az alábbiakban ismertetett Chroma Subsampling segítségével történik.
2. LÉPÉS. Chroma Subsampling
Sok játékos emlékezhet arra, hogy az almintavételezés a lehetséges gombok között van, amelyeket a játékélmény optimalizálása érdekében állíthatnak. Az alapötlet az, hogy minél több almintavételezést alkalmazunk, annál gyorsabb a játékteljesítmény. Ez azért van így, mert a játéknak kevesebb színtartományra van szüksége a rendereléshez.
A szín alatti mintavételezést J:a:b-vel jelöljük, ahol J a mintavételezendő pixelek száma, a a a felső sor pixeleit, b pedig az alsó sor pixeleit jelöli.
A 4:4:4 esetében ez azt jelenti, hogy egy 4×2 képpontban az első sorban (a) 4 színnek kell lennie, és a második sorban is. A 4:2:2 esetében ez azt jelenti, hogy egy 4×2 képpontban az első sornak két színnel kell reprezentálnia, és a második sornak is. A 4:2:0 esetében ez azt jelenti, hogy egy 4×2 képpontban az első sort két színnek kell ábrázolnia, és a második sor átmásolja az első sorban lévőket.
Amint látható, a chroma-alulmintavételezéssel akár 75%-kal is csökkenthető a színtartomány.
3. LÉPÉS. Diszkrét koszinusz transzformáció
A JPEG tömörítés az eredeti kép 8×8 pixeles darabokra történő felszeletelésével történik. Ebben a lépésben a 8×8 darabhoz az alább látható jelek alapján rendeljük hozzá az együtthatókat.
Az ötlet itt az, hogy ahogy az emberi szem a DCT-referencia bal felső részétől a jobb alsó rész felé halad, annál nehezebb azt érzékelni. Tehát általában az történik, hogy az együtthatók hozzárendelésekor a bal felső rész nagyon magas értéket kap, és ez csökken, ahogy átlósan haladunk lefelé.
Így nézhet ki a dolog numerikus formátumban:
4. LÉPÉS. Kvantálás
A DCT alkalmazása után a következő lépés a kvantálás. Itt egy kvantálási táblázatot alkalmaznak a kapott DCT-értékekre. A táblázat tömörítési algoritmusonként eltérő, és egyes szoftverek lehetővé teszik a felhasználó számára, hogy beállítsa a kívánt kvantálás mértékét. Az alábbiakban egy szabványos táblázatot mutatunk be:
Figyeljük meg, hogy a számjegyek egyre magasabbak, ahogy haladunk a bal felsőtől a jobb alsó felé. Ez szándékos. A kvantálás lényege, hogy a DCT-ből származó adatokat a kvantálási táblázattal felosztjuk. Ez az a pont, ahol a tömörített kép sokat veszít az adataiból. Mivel a jobb alsó számok magasak, a legtöbb értéke az osztás után végül nullává válik. Így nézhet ki:
5. LÉPÉS 5. Entrópia kódolás Huffman-kódolással
A Huffman-kódolás a tömörítés utolsó lépése. A következőképpen működik.
Tegyük fel, hogy egy számtartományt bitek segítségével akarok ábrázolni. Ráadásul úgy akarom ábrázolni őket, hogy az ábrázoláshoz a lehető legkevesebb bitet használjam fel. Ez úgy történhet, hogy a nagymértékben ismétlődő számok alacsonyabb biteket kapnak. Ha például a nulla sokat reprezentálódik, akkor általában alacsonyabb biteket rendelnék hozzá. A Huffman-kódolás alaposabb magyarázata itt található.
Az ötlet itt az, hogy kevesebb bitet használunk egy hosszabb értékkészlet ábrázolásához. A Huffman-kódolás egy veszteségmentes tömörítési algoritmus, amelyet szöveges fájlok tömörítésénél is használnak. Ezzel akár az eredeti méret 50%-át is megtakaríthatjuk.
Mi következik?
A tömörítés csupán az egyenlet egyik része. Amikor a képet renderelni kell, meg kell fordítani a tömörítési folyamatot, mielőtt a képet a képernyőn megjeleníthetnénk.
A JPEG nagyjából 90%-kal kisebb, mint bittérképes megfelelője. A mai napig ez még mindig a legnépszerűbb képtömörítési formátum. Az újabb algoritmusok, például a HEIF (2013) és az AVIF (2018) növeli a tömörítési algoritmushoz felhasználható pixelek körét.²
A JPEG népszerűsége ellenére az újabb formátumok jobb tömörítést biztosítanak. A WebP például általában körülbelül 70%-kal kisebb, mint a JPEG, mégis képes megőrizni a kép vizuális integritását. Ezért a Google (a WebP-t kifejlesztő vállalat) arra ösztönzi a fejlesztőket, hogy a képeiket JPEG-ről WebP-re kódolják át. A WebP támogatása azonban még mindig kisebb, mint a JPEG-é. Ebből adódóan mindkét formátumot támogatni kell.”
¹ “A BMP fájlformátum”. Előkészítés. Hozzáférés: 2019. április 19. https://www.prepressure.com/library/file-formats/bmp.
² A Netflix 2018-ban tette közzé az első AVIF-képkészletet. E bejegyzés időpontjában a képek még mindig elérhetőek itt. Az olyan vállalatok, mint a Firefox és a Microsoft hamarosan támogatni fogják ezt a képet a szoftverkínálatukban.