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

 ( trey | 2013. március 2., szombat - 9:49 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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?

Kérlek mondd, hogy viccelsz.
----
India delenda est.
Hülye pelikán

8 kilobájtban pont elfér egy torrent :)

--

XDDDDDDD
Made my day!

Egyrészt a 2 byteos tömörítés jut eszembe, másrészt azt nem tudjuk, hogy mekkora volt az a film. :)

köh-köh

Chuck Norris letömöríti a wikipediát 1 byte-ra.

És ez még semmi.

Ki is tudja tömöríteni, veszteségmentesen.

Chuck Norris egy veszteségesen tömörített állományt is veszteségmentesen tömörít ki. :)

ROTFL :D

Ja, meg Csák Norrisz (tudod, Csák Máté öccse) tud a zárt zippből zipp-zárat is csinálni.

McGivernek még gép sem kell hozzá ;)

Csak egy gémkapocs. :-P

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/#

Az hardware-es megoldas volt, es kell hozza egy orokmozgo, egy fluxuskondenzator, egy vegtelen-valoszinutlenseg hajtomu, meg egy Egely-kerek. Innentol a komponensek osszekotese mar trivialis.

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

És a végtelen-valószínűtlenség hajtóműhöz egy kiflivég. (Kiflivég? Kezdem érteni a Zopfli nevet...)
- - - - - - -
A buszállomás az a hely, ahol a buszok állnak, a taxiállomás az a hely ahol a taxik állnak, az íróasztalomon viszont van egy munkaállomás....

É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."

Heheh, erre én is emlékszem. Konkrétan a DOS könyvtárba pakolta a cuccokat.

Ugyanezt manapság NTFS-en el lehet végezni a datastreamekkel, és amíg NTFS-ek között másolgatod, még észrevétlenül működni is fog. Csak valamiért nem fog elférni annyi cucc a meghajtódon.
----
India delenda est.
Hülye pelikán

A kitömörítőről azért nem találtál infót, mert a meglévő zlib (gzip) algoritmus kitömörítője működik. Ez a szép benne, hogy úgy tud ~5% sávszélességet spórolni, hogy a kliens oldalon nem kell változtatni semmit.

Köszi, de én a videótömörítő kitömörítőjére gondoltam. :-)


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

Ha akár egy 5 perces filmet is 8k-ra tudott volna tömöríteni, az nagyjából azt jelenti, hogy egy frame-et
8k / 24 (frame) * 60 (sec) * 5 (perc) =
kb. 1 byte-ra tudott volna tömöríteni. Ez a csodálatos a wikipédiában.

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™

Hány kbyte egy emberi DNS? Mert ilyen alapon a természet egy embert simán letömörít akkorára, csak a kitömörítés lassú kicsit - 9 hónap, és kell hozzá egy speciális célhardver! :)

nomeg a DNS-nél 1 bit-nek nem 2 állapota van.
Elektronikailag is simán megoldható lenne a három állapotú bit is... nem [0,1], hanem mondjuk [-,0,+].
fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

"Elektronikailag is simán megoldható lenne a három állapotú bit is... nem [0,1], hanem mondjuk [-,0,+]."

http://en.wikipedia.org/wiki/Modulation#Digital_modulation_methods :)

Tegyuk hozza, elektronikaban sincs olyan, hogy 0 meg 1, hanem adott feszultseg ertek[tartomanyokhoz, mert azert ingadoznak ezek picit] rendelunk 0-at meg 1-et.

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

analóg hardver

nem találom most a pontos adatokat (eltérő a női és a férfi adatmennyiség), de nagyjából 3,2 milliárd bázispár, ami 6.4 milliárd bit, ami 0,8 GB.

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.

Ez a része kimaradt?
"de nagyjából 3,2 milliárd bázispár, ami 6.4 milliárd bit, ami 0,8 GB."
----
India delenda est.
Hülye pelikán

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

Nekem a kkrieger nevű 96 kbyte méretű 3d-s játék jutott erről eszembe.

istenem, mennyire fogalom nélkül vannak egyesek.
azokat a demókat, játékokat úgy készítették, hogy a textúrákat, pályákat, stb., algoritmusokkal, függvényekkel generálták.
semmiféle tömörítéshez nincs közük.
(maximum a végső exe -t becsomagolták upx -szel)

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 kivágandó fölösleget mi alapján állapították meg? Meghallgatták, megnézték 80 fajta "kivágással" és abból kerestek egy optimálisat, ami még jó minőségű és kicsi? Vagy létezik erre valami matematikai képlet?


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

Ezek itthon jobbara a jol bevalt MTH metodika alapjan kerultek kiszamolasra.

---
pontscho / fresh!mindworkz

Köszi. Ez az MTH a "multi-texton histogram"? Nem ismerem a rövidítést, de keresés alapján ez tűnt relevánsnak.


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

Dehogy. Magyar Tudomanyos Has modszer. :)

---
pontscho / fresh!mindworkz

Ah, értem! :-)


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

Matematikailag is képtelenség. Egyébként lehetságe sközeé hasonló
Íme:
https://www.youtube.com/watch?v=LMiZQEP1MAQ Ez így még egy kb sincs, és egy teljes film van "bele tömörítve".

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

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

Idézet:
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.

Valaki mesélte, hogy Jan Sloot úgy tűnt el, hogy egy vízhajtású autóval karambolozott...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Vagy Szlovákiába utazott és politikus lett belőle.
(bocs, gyenge poén volt)

A címet meglátva rögtön gondoltam, hogy valami délnémet dologra utal az elnevezés. :)

--
Ingyenes Ubuntu One tárhely:
https://one.ubuntu.com/referrals/referee/170278/

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

a zopfli nem kifli, hanem fonott kalacs ;)

+1

Lasd: [zopf] [zopfli]

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™

A fenti cikkben valóban nem olvasható a motivációs háttér, annak megismeréséhez legalább egyet kattintani kell.
--
zsebHUP-ot használok!

"It is a compression-only library; existing software can decompress the data. Zopfli is bit-stream compatible with compression used in gzip, Zip, PNG, HTTP requests, and others."


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

Mond azt hogy flame bait volt :)

https://bugzilla.mozilla.org/show_bug.cgi?id=366559 meg az FF sem tamogatja, de bug mar van rola. Hogy all a tobbi bongeszo ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Majd ha az LZMA kepes lesz ZLib-kompatibilisen tomoriteni, akkor lesz ertelme errol beszelgetni. A fenti megoldasban az a jo, hogy nem kell a kitomorito oldalt lecserelni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

write-only?
mar vagy 20-an mondtak el ezt.

"[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.

xz-t nem beszélnek a böngészők, gzip-et igen. Ennek a toolnak az a lényege, hogy a meglévő infrastruktúrát használóknál javítson a hely- és hálóforgalom igényen.

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.

TudNAK es tudJAK kozott csak egy betu a kulonbseg - es megis tobbmillio felhasznalot jelent.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

es az xz mennyire kompatibilis a meglevo zlib dekodolokkal?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

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

Nem jo, igy is annyi sz@r bongeszocuccot kell tamogatni, nem kell meg egy, koszi. Kuldjek be az XZ/LZMA-t szabvanynak, ha elfogadjak, majd tamogatjuk szerver oldalrol.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

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ó.

Csinaltam par merest, gondoltam ide is beteszem, megis tobben olvassak, mint strygg blogjat:
http://hup.hu/node/122851?comments_per_page=9999#comment-1582041

--
I can calculate the movement of the stars, but not the madness of men. -Sir Isaac Newton