Egy kis újabb csemege a bitpornó kedvelőinek :-)
Nem tudom, hányan ismeritek a Quite OK Image képformátumot. A lényege, hogy eszeveszettül faék egyszerű, mégis egész jó tömörítési rátát képes produkálni (a honlapja mondjuk hazudik, speciálisan kézzel összeválogatott képen demózza). Viszont volt benne pár dolog, ami mindig is zavart (például hogy nem képes transzparens képeket tömöríteni), ezért feltúrbóztam kicsit:
Fícsörök:
- ugyanúgy egyetlen függőség nélküli fejlécfájl, mint az elődje (kb. 200 SLoC a kicsomagoló-becsomagoló együtt)
- ugyanúgy MIT licenszű, Szabad és Nyílt Forráskódú
- azonban ez sokkal gyorsabb, pláne nagy képek esetén
- ráadásul sokkal jobban tömörít (különösen anti-aliasolt képeket)
A sebességnövekedés amiatt van, hogy mutatókat és switch/case-t használ bájttömbindexek és if/else blokkok helyett, egyébként ugyanaz a logika, nincs benne semmi trükk. A jobb tömörítési rátát pedig úgy éri el, hogy okosabban osztja ki a biteket, a legtöbb utasítás ugyanaz, de a futásidejű tömörítésre van egy hosszabb futamot is tárolni képes opció, a differencál utasításoknál van egy olyan, ami alfát és nagyobb tartományt képes leírni, a teljes csatornát tároló utasítás pedig csak a megváltozott csatornákat tárolja az összes helyett. Röviden.
- 295 megtekintés
Hozzászólások
Szuper! Megneztem az algoritmust, de ez leginkabb csak rajzokra jo (ahol sok pixel pont ugyanolyan szinu), foto jellegu kepeknel szerintem ez nagyobb lesz mint BMP-ben :)
A PNG-ben vannak filterek amik differencialnak akar az elozo pixel sorhoz is, es az eredmenyt huffman kodolja, az se kozeliti a jpeget, de azert az fotoknal is hatasos valamennyire.
En 20 eve jpeg-bol csinaltam egy sajat egyszerusitett verziot ami YUV helyet RGB-t tarolt, gyorsan lehetett parsolni (huffman/idct megvolt de a jpeg-fele markereket es egyeb bonyolitast kihagytam teljesen) es tamogatott alpha-t is, megpedig ugy hogy blokkonkent (8x8 pixel) tarolta 1 biten hogy van-e atlatszosag/alpha, a 0=nem (RGB volt tarolva csak) es ha 1=igen akkor a kovetkezo biten hogy teljesen atlatszo-e a blokk (ilyenkor nem is tarolt mast) vagy csak reszben, akkor RGBA data jott. igy a dekoder tudta optimalizalni blokkonkent a blendinget, csak a reszben atlatszoknal kellett a hatterrel mixelnie, kulonben vagy siman felulirta a hattaret vagy beken hagyta teljes egeszeben. mivel a blokkok max 5-10%-a volt reszben atlatszo ezzel sok cpu idot nyertunk. meg azzal is hogy a hatternel nem kellett semmit dekodolni meg blendelni/irni, csak atugrani.
- A hozzászóláshoz be kell jelentkezni
de ez leginkabb csak rajzokra jo (ahol sok pixel pont ugyanolyan szinu)
Nem. Valóban van benne run-length encoding is, de a lényegi tömörítést a LUMA és RGBA csatorna differenciál kódolás adja.
foto jellegu kepeknel szerintem ez nagyobb lesz mint BMP-ben :)
Faszt. Ott van a klasszikus Lena példakép, fotó jellegű, felére tömörítette: 256K helyett csak 137K. De tény, hogy fotó jellegű képeknél QOI 1.0 szintjén van, elsősorban transzparens hátterű, anti-aliasolt képekhez lett kitalálva. Azoknál közel PNG szinten van a törmörítési rátája, ugyanakkor milliószor gyorsabb kicsomagolni annál. De a képtől is függ, a Kurisu példakép például kissebb QOI-ben, mint PNG-ben.
A PNG-ben vannak filterek amik differencialnak akar az elozo pixel sorhoz is, es az eredmenyt huffman kodolja, az se kozeliti a jpeget, de azert az fotoknal is hatasos valamennyire.
A PNG sem remekelt sokkal jobban Lénán, az a 256K-ból 109K-t csinált, de cserébe nagyságrendekkel tovább tart kicsomagolni (mármint SOKKAL), pont a Huffman és a filterek miatt és nem is írod meg 100 SLoC-ból.
igy a dekoder tudta optimalizalni blokkonkent a blendinget
Már bocs, de ennek semmi értelme. Mégis melyik kódban kell a dekódernek blendingelnie??? A legtöbb szoftverben ezek teljesen külön rétegben vannak (dekóder a fájlekezésnél, blending meg a view rétegben fordulhat elő), egyetlen közös kódsoruk sincs.
Csak hogy tisztázzuk: az eredeti QOI codec Dominic Szablewski találmánya, az én hozzájárulásom a QOI 2.0-ával csak annyi, hogy ez képes anti-aliasolt képeket is jól tömöríteni. Ha megnézed az eredeti QOI specifikációt (1 oldal csak), akkor láthatod, hogy az egyetlen utasítás, amivel alfa csatorna értéket lehet váltani, az bizony 5 bájtos. Nem véletlen, hogy a QOI honlapján lévő tesztképek között egyetlen egy transzparens sincs... Na ez nekem nagyon nem tetszett, mivel a legtöbb ikon az biza transzparens hátterű, alfa átmenetekkel az ábrák szélén, és ezeken csúnyán elvérzik az eredeti QOI. Csak ezért írtam meg a QOI 2.0-át, hogy az ilyen képeket is kezelje. A nem transzparens, fotó jellegű képeknél a tömörítési arány kb. azonos az eredeti QOI tömörítési arányával.
- A hozzászóláshoz be kell jelentkezni