Zopfli: efektivnější komprese deflate (diskuse)

[Šangala]

Jsem v tom zamotán (nová knihovna OK, to je dobře, ale). Přes zlib jsem vždy použil jen zlib kompresi, a bzip má obvykle lepší kompresi a není (snad) o tolik pomalejší, takže v čem je to „zajímavé“ (, krom toho že máme další možnost) - proč jen porovnání oproti zlib?
PS: ještě jsem si to nedopřál, takže „První“ :).

[psonek]

Protoze tim vytvoris zip o 3..8% mensi? Aspon ja to tak chapu podle textu zpravicky, jeste jsem se na to nedival.

[psonek]

Aha no spis to bude delat lip zkomprimovane .gz soubory

[Luboš Doležel (Doli)]

Jestli to člověk strčí do .gz nebo .zip už je vcelku jedno.

[Luboš Doležel (Doli)]

Není žádná "zlib komprese", zlib implementuje deflate. A motivace je jasná: v HTTP se používá deflate, žádný bzip2...

[mimi.vx]

přesně tak. důležite je že to dokaže dekomprimovat jakoliv implementace deflate (zlib) -> všecny současné prohlížeče

[Šangala]

Jo táááák, „lepší“ knihovna na stejný typ/formát komprese, tak to mě nedocvaklo, právě proto, že 'DEFLATE' bylo pro mě doposud neznámé slovo a bral jsem to, že je to jiný typ komprese (stejná ignorace rozlišení z mé strany, jako pro jiné jsou obyvatelé Pandory Avataři a avatar je modrý ).

[tukan]

a prima implikace -> usetrime 3-8% toku dat.

[mimi.vx]

což při tocích které má např google dělá zajímavá čísla ..

[Radovan Garabík]

v HTTP se používá deflate, žádný bzip2...

$ wget --header='Accept-Encoding: bzip2' -S kassiopeia.juls.savba.sk/~garabik/ 

Resolving kassiopeia.juls.savba.sk... 147.213.138.13
Connecting to kassiopeia.juls.savba.sk|147.213.138.13|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.0 200 OK
  Vary: Accept-Encoding
  Content-Encoding: bzip2

[Luboš Doležel (Doli)]

Jasně, implementovat si tam můžeš klidně i vlastní algoritmus, ale otázkou je to, co podporuje většina klientů.

[Radovan Garabík]

ale otázkou je to, co podporuje většina klientů.

Otázkou je, čo podporuje Chrome (viď SPDY). Ja som robil nejaké porovnania bzip2 a deflate (lebo som ich implementoval do cgi skriptu), pre "normálnu stránku" bzip2 dosiahne menšiu veľkosť tak od 50KB vyššie. V mojom skripte je na to test, a ak browser podporuje oba, vráti sa mu podľa veľkosti výsledku.

Preto je pochopiteľné, že google radšej pracuje na vylepšení deflate - pre "malé" veľkosti súborov je to lepšie ako bzip2 (alebo lzma). Keby to bolo naopak, tak google začína hromadne podporovať bzip2.

[Radovan Garabík]

bleee.... s/SPDY/SDCH/ (ale platí to pre obe)

[ByCzech]

Chápu správně, že učetřím 3 až 8 % dat / datového toku, za cenu tak významného zpomalení komprese na straně serveru tak, že to co trvá komprimovat teď 1 sekundu, by trvalo stovky nebo tisíce sekund (2 až 3 řády). Není to překlep? Nebo má Google takovou přemíru výkonu, že se mu snížení datového toku o 3 až 8 % i za těchto podmínek vyplatí...

[chrono]

Statické súbory zbalia len raz a tam to dlhé komprimovanie nie je až taký problém.

[Luboš Doležel (Doli)]

Není to překlep, ale statická data komprimujete jen jednou...

[Grunt]

Spíš to pokazuje na to jak je ten koncept server-(web)klient (cloud?) dokonalé řešení. Chci říct, kdyby to byl případ klasického programu, tak se prostě nabinduje efektivnější algoritmus (BWT, LZMA, whatever), rozdistribuuje se balíčkovacím systémem aktualizovaná verze se závislostí na libku, přepne se algoritmus na straně serveru a může se na pivo. Takhle se pomalu musí přepisovat standardy aby se vůbec rozdistribuovalo něco efektivnějšího. A nebo to též možná ukazuje na to jaké jsou ceny za železo, když se vyplatí dělat takové psí kusy, které sežerou 100× víc procesorového času za cenu o 5% vyšší efektivity algoritmu a že se vůbec na to vyplatí najímat člověka, který se tím bude zabývat (zdaleka to není poprvé). Ale při traficu jaký má Google…z ekonomického pohledu asi bomba, z pohledu logického naprosto padlé na hlavu. Ještě že samotný OSS se nemusí řídit podle těchto stupidních ekonomických zákonů.

[ivan]

Gzip to je prece jenom LZ77 na tom se da jeste neco zlepsit? Tusine nekdo jak to delaji? LZ77 je docela primitivni algoritmus. PS: neni uz nahodou propadly patent na aritmeticke kodovani?

[David Ježek]

deflate myslím používají různé ty zmenšovače png jako pngout. že by další prostor pro zlepšení?

[chrono]

Asi ani nie, keďže aj s klasickou knižnicou je to dosť pomalé (pretože sa musí skúšať veľa rôznych kombinácií parametrov).

[David Ježek]

mě nevadí když to bude pomalejší, ale často používám pngout u nás na diit.cz, protože mnohdy ty soubory VÝRAZNĚ zmenší. kdyby to šlo ještě víc, budu rád. když jsem mohl komprimovat png s pngout na 1,8ghz duronu, když jsem v cdrku začínal, tak klidně můžu používat dnes jeho náročnější verzi se zopfli na 4core 3ghz+ stroji ;).

[Ovocníček]

Otázka je, jestli ty vylepšení zabírají na ten typ dat, co jsou v PNG souborech.

Mimochodem, mám pocit (IIRC), že 7zip také produkoval lepší kompresní poměr než klasický zip, nezkoušel někdo srovnat s touhle novotou?

[mmmmario]

Ano, deflate používá ZIP, PNG, PDF. Zajímalo by mě porovnání s KZIP od Kena Silvermana. Samozřejmě mi jde o výslednou velikost archivu, ne o rychlost komprese, protože Kenova implementace je pouze pro Win32 a ještě obfuscovaná. Jo, to je ten člověk co udělal engine Duke Nukem 3d a pngout.

[chrono]

Pokiaľ ide o kompresiu, Zopfli je trochu lepší ako KZIP, čas komprimovania je ale pri KZIP lepší (a KZIP je trochu lepší ako DeflOpt).

[trubicoid2]

a co advdef, advzip, advpng? http://advancemame.sourceforge.net/comp-readme.html

jinak na png se mi osvedcilo kombinovat nejdriv optipng -o7, pak pngout a pak advpng.

[Ovocníček]

Na obrázky co nemají úplně jednoduchý obsah (jednolité čáry, plochy) má stejně lepší výsledky JPEG-XR a hlavně JPEG 2000. Zkoušel jsem lossless Webp, ale už nevím, jestli to vůbec překonalo JPEG-XR (PNG myslím trošku jo, ale nevím jistě).

H.265 má profil pro kódování obrázků, tak třeba se to vyvrbí líp, za rok, dva.