Zopfli - új, nyílt forrású tömörítési algoritmus a Google-től

Szerszám

Lode Vandevenne, a Google tömörítési csapatának tagja tegnap bejelentette, hogy elérhetővé tettek egy új, általános célú adattömörítési library-t Zopfli néven. Az algoritmus egy svájci kenyérrecept után kapta nevét. Weboldala szerint a Zopfli nem egy sebességbajnok, körülbelül százszor lassabb tömörítésnél (kibontásánál nem) mint a zlib, viszont annál kb. 5 százalékkal jobban tömörít. A Google mérnökei nem találtak más zlib-kompatibilis tömörítőt, amely a Zopfli-nél jobban tömörített volna. A készítők szerint a Zopfli ideális olyan felhasználási területeken, ahol egyszer kell tömöríteni, majd az eredményt sokszor kell hálózaton keresztül átküldeni. A hordozhatóság érdekében C-ben íródott, licence Apache 2.0.

Részletek a bejelentésben.

( bognarpeter | 2013. 03. 02., szo – 10:02 )

Hát azért a Jan Sloot féle tömörítési eljáráshoz képest ez még mindig piskóta.

Itt:
http://en.wikipedia.org/wiki/Jan_Sloot

Egy teljes filmet 8KB-ra tudott tömöríteni. El akarta adni a technológiát a Philipsnek, azonban _sajnálatos módon_ egy nappal a találkozó előtt szívrohamot kapott.
A lényeget tartalmazó floppy is valahogy köddé vált...

Urban legend vagy kőkemény valóság?

Bár még nem próbáltam, de ezt szerintem én is megcsinálom. Amennyiben a film főleg állóképek ismételgetéséből áll, hangsávja nincs, és nem hosszabb mint kb 1 mega...
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Érdekes. Amit nem találtam, az valami infó a kitömörítőről. Mindenhol csak új tömörítő eljárásról meséltek és milyen kicsire tömörítette, de arról nem látok infót, hogy ki is tömörítették amit betömörítettek.

Régen, még a DOS-os időkben, adtak egy tömörítőt, hogy milyen fantasztikusan tömörít. Kipróbáltam, tényleg, kicsi lett a végeredmény. Gyanús volt. Megnéztem vajon ki tudja-e csomagolni. Meglepő, de igen. Ettől még gyanús maradt. Kipróbáltam másik állományon. Ugyanezt megtette, be- és kitömörítette rendben. Hm. Aztán kipróbáltam VC alól és az tűnt fel, hogy a szabad helyem nem nagyon változik, pedig hát ugye kellene tömörítés után. No ez már érdekesebb. A vége az lett, hogy valamilyen alkönyvtárba létrehozott egy rejtett állományt, ahova bepakolta az anyagot és létrehozott egy fal állományt ahova én mondtam, ami persze a kicsi állomány volt. Azóta kevésbé hiszek a csodákban. :-)

"Belépés díjtalan, kilépés bizonytalan."

Kérlek olvasd el a wikipédia cikket és mutasd meg, hol állítja vagy utal arra, hogy a történet igaz. Miután kaptál ilyesmit, ezeket még mindig meg kell magyarázd: "claimed to have developed", "despite the ostensible impossibility". Egyébként sajnos el kell ismerd, hogy a wikipédia egyszerűen és részrehajlás nélkül leír egy eseményt, anélkül, hogy bármilyen következtetést levonna.

Valamikor DOS alá volt egy kis demó-program, a nevére sajna már nem emlékszem, 2-3 kbyte lehetett az egész. 3D-s labirintusban való mászkálást mutatott be, 256 színű grafikája volt, full 3D, élethű térhatás, kőfalak. Ismétlődés nem volt benne. (kb fél óráig bámultam). Mindez egy akkoriban is mezeinek számító VGA kártyán, 486SX masinán futott akadásmentesen. A kőfal egy köve nem hiszem hogy elfért volna 2 kbyte-ban... Egy film 8 kByte-ban viszont túlzás...
Bár, ha az EGA-s Another nevű játék bevezető animációjára gondolok... ... :D
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Ne zavarjon, hogy azokat a labirintusokat nem taroltak, hanem generaltak. Az egesz 4/64K-s mufaj a demoscene erre a technikara epit: amit lehet, azt generaljak, mert mindig kevesebb, mint eltarolni.

(AFAIK, de majd akik muvelik is, megmondjak a tutit).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

utánanéztem: 1 bázispárnak, (továbbiakban akár bit-nek is nevezhetjük) 4 állapota van: AT, GC, TA, CG. 4 állapot, binárisan 2 biten ábrázolható. Tehát a binárisan ábrázolt bitek számát még szorozhatjuk 2-vel... vagyis 1.6 GB...
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Idézet a Nagy Ateista Könyvből (ingyen elérhető a MEK-ből):

"Az emberi kromoszómaszerelvény mintegy egymilliárd bázispárt tartalmaz, ez azonban nagyrészt repetitív, azaz bizonyos szakaszai sok példányban vannak jelen. Ezeket nem kellett a szelekciónak újólag előállítani, mert egyszerűen megkettőződhettek. A létrehozandó emberi DNS tehát mintegy százmillió bázispárt jelent."

Egy bázis 4 fajta lehet, eképp 1 bázis 2 biten kódolható, azaz százmillió bázispár, az 2*2*100 millió bit. De mert egy bázis eleve meghatározza mindig, mi lehet az ő párja, ezokból ennek csak a felét kel letárolni, azaz csak 200 millió bitet. Ez 25 millió bájt. Ez 24414 K. Ez 23.8 megabájt. Egyáltalán nem sok. Messze van az 1 gigától is, ez egyetlen átlagos zeneszám hossza flac-ban, vagy 4 zeneszám mp3-ban. És erre mondják azt egyesek hogy ez nem alakulhatott ki 4 MILLIÁRD év alatt az evolúció során?!
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

,,Egy bázis 4 fajta lehet, eképp 1 bázis 2 biten kódolható, azaz százmillió bázispár, az 2*2*100 millió bit. De mert egy bázis eleve meghatározza mindig, mi lehet az ő párja, ezokból ennek csak a felét kel letárolni, azaz csak 200 millió bitet."

Százmillió bázispár négyféle lehetséges bázispár esettel 4*100 000 000 variáció, és nem a fele.
Vagy inkább: százmillió félbázispár négyféle lehetséges félbázispár esettel 400 000 000 variáció, a másik ág nem tárol információt. ( Annál is inkább, mert tároláskor csak egyetlen spirál van, amikor éppen használja a DNS-t másol sebtiben még egy ágat )

Puppy linux felhasználó

Fenet!
"Százmillió bázispár négyféle lehetséges bázispár esettel 4*100 000 000 variáció"
Nem annyi, hanem 4^100 000 000 variacio. Ami 2^200 000 000, ami pontosan 200 000 000 bit, mert mind a 200 000 000 bit ketfele (a masik bittol fuggetlen) allapotban lehet, ahogy a 100 000 000 bazispar is egymastol fuggetlen 4 allapotban.

400000000 variacio sokkal rovidebben leirhato. log(400000000)/log(2) felfele kerekitve. Kb. 29 bit, ugye 32 biten mar 4 milliard variacio van.

--
akkor most free tibet vagy delete tibet a jó?? - falu

Nem teljesen, egy idoben divott egy egyszerusitett, dct/idct-re epulo eljaras ami kivagott nehany felesleges frekvenciat a hang illetve kep mintakbol, igy a vegso tomoritesnel kisebb lett a koceraj. Btw, upx legfeljebb demok eseten volt hasznalva a szar hatasfoka miatt. 4k-nal crinkler, 64k-nal kkrunchy (paq7 ftw) a meno.

---
pontscho / fresh!mindworkz

A holland wikipedia jocskan bovebb, de tobbet ott se tudnak.

Het boek De broncode van Eric Smit bevat diverse aanwijzingen van Jan Sloot over hoe zijn coderingssysteem in elkaar zat. Zo vertelde hij dat zijn systeem niet opgebouwd was op het huidige binaire systeem, maar er wel compatibel mee was.

Vagyis "nem digitalis elven mukodott, pusztan azzal kompatibilis".

Ettol fuggetlenul tokmindegy, hogy mi volt, most mar nincs. Ez mar az osszeeskuves-elmeletek zuros talajara vezet.

( KoGa v | 2013. 03. 02., szo – 15:30 )

Az elnevezes pedig onnan jott hogy a fejleszto kiflit evett kodolas kozben :)

( saxus | 2013. 03. 02., szo – 16:41 )

Ezt most a Google viccnek szanta vagy komolyan is gondolta? Amikor ott az LZMA, amely 17-20%-okkal raver a zlibre es azert nem "szazszor lassabb" hanem ugy masfel-ketszerese?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( sigellef | 2013. 03. 02., szo – 20:37 )

"[g|b]zip -9"-re ráver 8-13%-ot... ezt lazán megcsinálja az xz... néha még akkor is, ha csak -4-gyel paraméterezzük :D
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Tömörített adatforgalom http-n keresztül. A böngészők is, a webserverek is tudják használni a zlib-et, amit a gzip is használ, csak nem fájlba/fájlból, hanem streamből/streambe dolgoznak. Miért ne tehetnék meg ezt a liblzma-val? Lehet, hogy a zopfli is liblzma alapú valami lenne?
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

semennyire... viszont a tar erre is fel van készítve, ha "z" kapcsoló helyett "J" kapcsolót használunk, akkor tar.xz lesz az eredmény. Namármost, ha a tar tudja használni, akkor elvileg használhatná mind a webserver, mind a kliensoldal.
Lehet, hogy az lzma-t és a zlib-et rakták össze valahogy, és az lett a zopfli :D
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Vagy trollkodsz, vagy szövegértési nehézségeid vannak. Van az 1999-ben kiadott RFC 2616 (becenevén HTTP1.1) amit ha jól emlékszem az IE 5.0.1 -ben és a Netscape Navigator 4.5-ben kezdtek el támogatni. Ez definiálta azt leegyszerűsítve, hogy a zlib-et kell a böngészőnek használnia, ezt azóta tudja is az összes.

A kiadott algoritmusban az a nagyszerű, hogy a kapott eredmény továbbra is kibontható zlibbel. Ha tehát a nagy site-ok (google, fb stb.) elkezdik használni ezt a statikus tartalom tömörítéséhez, úgy az internet forgalma csökken pár százalékot (vagy a kihasználható sávszélesség nő pár százalékot, nézőpont kérdése) anélkül, hogy kliens oldalon bármit módosítani kellene, vagy egyáltalán észrevennék a változást. Akár holnaptól.

Ellenben ha egy újfajta tömörítő algoritmust akar valaki használni, akkor:
- rá kell vennie az összes iparági szereplőt, hogy támogassa mind kliens mind szerver oldalon
- meg kell várnia, hogy elterjedjen (ne felejtsük, hogy IE6-ok még vannak)
Szóval lehet használni, mondjuk 10 év múlva.

Esetleg megtehetik, amit annyi mindennel webes teruleten: a draft-okat implementaljak, aztan bekuldik, hogy egyszer majd szabvany legyen belole.

Pl: Chrome(-ium), FF bevezeti, hogy az x-accept-encoding-ba bekeruljon az XZ/7zip/LZMA/amit epp jonak latnak, es persze implementaljak, hogy ilyen streameket is tudjon fogadni.
A webservereknek is adnak ilyen tamogatast, es ha a bongeszo meg tudja enni, akkor ezzel tomoritik, ha nem, akkor marad a korabbi vagy a tomoritetlen valtozat. Ha a webserver nem ismeri, szinten nem gond, a visszafele kompatibilitas nem serul (ahogy pl. egy beagyazott eszkoz webes configfelulete sem feltetlenul tamogatja mondjuk a gzipet).

Aztan ha kelloen elterjed, es minden nagyobb bongeszo es webserver tamogatja, akkor idovel rateszik a hivatalos pecsetet.

--
akkor most free tibet vagy delete tibet a jó?? - falu

Ez nem bongeszocucc, hanem tomoritesi metodus. Problema csak akkro van, ha valaki fogyatek modjara kezeli (illetve problema altalaban akkor van). Kivetelesen ez a resze eleg egyertelmu a szabvanyban: bongeszo megkuldi mit fogad el, a szerver vagy ugy kudli, vagy tomoritve.

Akinek ennek lekezelese problemat okoz, a kerulje el a szamitogepet jo messzire.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ezzel nem nagyon kellene vacakolni, mert a nagy http szerver fejlesztők beteszik és onnan kezdve opciónálisan lehet használni. Pl. ha az nginx vagy az apache httpd elkezdi támogatni és van olyan böngésző, ami szintén támogatja, akkor tudnak kommunikálni egy hatékonyabb tömörítéssel. Ez utána mind a szerveroldali programok (php, java stb), mind a böngészőbe épített vackok (js) számára átlátszó.