Ha már próbáltál is írni JPEG enkódert, akkor láthatod, hogy a standard JPEG enkódolás és dekódolás 8 bites RGB csatornákkal dolgozik. Ellenben a legjobb minőségű JPEG kép is már azért eleve információvesztést jelent egy nyers RGB képhez képest, mert (mint ahogy az általad linkelt MSDN oldal is egyből írja) a chrominance csatornák szerint a kép felbontását megfelezi. Tehát ha van egy 200x200-as képed, akkor a krominancia csatornák szerint csak 100x100-as adatokkal dolgozik az algoritmus.
Mert ugye az RGB színhármasok teréből egy transzformációval átteszi a képet az Y Cb Cr térbe, ahol az Y sík úgymond a szürkeárnyalatok, és a két krominancia sík elkódolja a színekhez szükséges informácót. De csak fele akkora felbontással. Amúgy ezt tényleg nehéz észrevenni, bár color bleeding jelenséget okozhat.
Fontos, hogy a fele akkora felbontás itt nem a színmélység felbontást jelenti, hanem maga a kép dimenzióit (pl 640x480). Ha ettől a felezéstől eltekintünk, akkor a DCT transzformáció még megőrzi a 8+8+8 bitnyi adatot pixelenként (csak itt ugye átkerülünk frekvencia térbe, mind1). De megőrzi, feltéve ha olyan a DCT implementáció, hogy a kerekítési hibák nem akkumulálódnak úgy, hogy nagyon pici eltérések jelentkeznek. Pl egy sin/cos táblázatokkal és integer aritmetikával megsegített algoritmus baromi gyors tud lenni, ellenben véthet kerekítési hibákat. Ezeket amúgy még nem látnánk. Egy pontosabb floating point aritmetika még ugyanazt visszaadná egy inverz DCT után. Maga a DCT még mindig nem tömörít, csak az Y Cb Cr adathalmazt átkonvertálja/transzformálja frekvencia térbe.
Az "igazi" tömörítés ezután következik. A kutatási eredmények, táblázatok, statisztikák és heurisztikák alapján bizonyos jelentéktelen frekvenciákat elhagy az adatokból. Ezek kicsi energiával jelen levő vagy másféle okból elhanyagolt frekvenciák. Itt szabályozod igazán a csúszkával a JPEG tömörítésnél, hogy mennyire durván erőltesse ezt a frekvencia elhagyást. Minél erősebb a tömörítés, annál többet hagy el. Az elhagyás azt jelenti, hogy az ottani frekvencia amplitúdóját/energiáját 0-nak tekinti, kinullázza. Ha sok nulla van, és ezek nagy része csoportba is tömörül, akkor azt RLE (run-length encoding) illetve Huffmann technikákkal jobban letömöríthetjük. Igazándiból nem csakúgy eresztik rá az LRE-t meg a Huffmant a 8x8-as blokknyi adatokra (ja, a DCT-s és attól kezdve a dolgokat a 8x8-as blokkokon művelik), hanem egyrészt egy zig-zag bejárási úton veszik a blokkon belül a pixeleket (és nem sor/oszlop irányban), ezáltal a 0-k jobban összecsoportosulnak a 64 bájtnyi adatban. Illetve itt is használnak még táblázatokat bizonyos bitmintákra (vagy azt csak az MP3-ban, mind1).
A visszakódolás ennek az inverze, kikódolják a Huffmant, reverse zigzag irányban előállítják a 8x8-as blokkokat, akkor amilyen frekvenciákat elnyomtunk az ugye már elveszett, visszaadni nem tudjuk itt, itt történik az adatvesztés, aztán rányomunk egy inverz DCT-t. Ekkor Y Cb Cr térben vagyunk, áttranszformáljuk RGB-be meg figyelembe vesszük a krominancia dimenzió felezést.
A blokkosodási effektus (blocking) amiatt van, hogy elvettünk bizonyos frekvenciákat. Szintén ez okozza a ringing effektust (ezt nem tudom hogy mondják magyarul: amikor egy homogén háttéren levő vonal mákossá válik a JPEG miatt). Még véletlenül se amiatt hogy a JPEG kevesebb vagy több RGB bitet kezelne. Ezek az effektusok amiatt vannak, hogy elvettünk frekvenciákat a transzformáció során és ez így bosszulja meg magát.
Fontosnak tartom leszögezni, hogy én a JPEG alap működéséről beszéltem, a szabvány elég bő vannak változatok, hogy a JPEG2000 meg hasonlókról még nem is beszéljek. Ott nem tudom, hogy vannak-e esetleg 8 bitnél mélyebb színcsatornák.
Amúgy az MP3 (MPEG 1 Layer3) tömörítés hasonló kaptafa: ott is áttesszük a hangot (monduk 514 bájtnyi raw mintát) időtarzományból freki tartományba, ott az elnyomási effektus és egyéb heurisztikák alapján elhanyagolunk frekiket, aztán tömörítjük.
Ennyit akartam mondani, hosszú lett.
Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz
