【プログラム】Googleが新しい圧縮アルゴリズム「Zopfli」を発表　webが早くなるかも

Googleが今日（米国時間2/28）、オープンソースの新しい圧縮アルゴリズムZopfliをローンチした。
今の標準圧縮技術であるzlibライブラリに比べて5〜8%圧縮率が高いといわれ、また
解凍アルゴリズムは今のWebブラウザが現用しているもので間に合うため、Webサーバが
これを採用すれば、データの伝送速度が上がり、Webをやや速くすることができるだろう。

このアルゴリズムはチューリッヒ在住のGoogle社員Lode Vandevenneが20%プロジェクト＊
として作ったもので、Deflateアルゴリズムの実装だ。それはZIPやgzipが使っているアルゴリズムで、
画像ファイルのPNGにも使われている。出力（圧縮結果）はzlibと互換性があるが、
圧縮を行うアルゴリズムがzlibとは異なり、より効率的だ。
〔*: 20%プロジェクト, 会社の拘束時間の20%は好きなこと（研究開発）をしてよい、というGoogleの内規。〕

Vandevenneは今日の発表声明で、“この徹底的で容赦のない圧縮アルゴリズムは、
エントロピーモデルの反復と最短経路アルゴリズムを駆使し、可能なすべての
デフレート表現のグラフ中にビットコストの低い経路を見つける”、と述べている。

ただし、高い圧縮率の代償は長い圧縮時間だ（解凍時間は同じ）。Vandevenneはこう書いている:
“最大でzlibの2〜3倍のCPU時間を要するので、Webの静的コンテンツのように、
一度圧縮したらそれを今後何度でも使える、というアプリケーションに向いている”。

http://jp.techcrunch.com/archives/20130228google-launches-zopfli-compression/

zopでくれ

ああゼットンにやられたら迎えに来てくれるあの人か

一方Appleは2ch閲覧を禁止した

なぜネトウヨはうんこをウンタラカンタラ

ドイツ語くせえ名前つけんな

>>1の続き
なぜネトウヨがウンコを好んで食すのか
私なりに、真剣に考えてみた
一般の人々にも広く認識されている通り、
ネトウヨは一般人とは大きく乖離した常識と感覚を持った存在
ネトウヨは常に一般人とは逆のことを考えているのだ
つまり・・・
一般人が「美しい」と思うものを「汚らわしい」と思い、
一般人が「汚らわしい」と思うものを「美しい」と思っている
ということ …
＼＿＿＿＿＿＿＿＿＿＿ 　＿＿＿＿＿＿＿＿＿＿／
　　　　　　　　　　　　　　　　∨
　　　　　 　　　＿＿＿_…コピペ送信。
　　　　　　　／　　 　 　＼
　　　　 　／　　 _ノ 　ヽ､_＼　　　　今晩もまた糞コピペを
　　　　／　　 oﾟ⌒　　　⌒ﾟo＼　　貼るバイトが始まるお。
　　　　|　 　し 　 （__人__）　 　 |　＿＿＿＿＿＿＿_
　 　　 ＼　　 　　 ｀ ⌒´ 　 ,／　.| |　　　　　　　　　　|
　　　　ノ　　　　　　　　　　　＼　| |　　　　　　　　　　|
　 ／´ 　 　　　　　　　　　　　 　 | |　　　　　　　　　　|
　|　　　　ｌ 　 　 　 　 　 　　　　　| |　　　　　　　　　　|
　ヽ　　　 -一ー_~､⌒)^),-､　　　| |_＿＿＿＿＿＿__|
　　ヽ ＿＿＿＿,ノγ⌒ヽ)ニニ-￣　　　| |　　|

>>1
日本語でおｋ

googleどんどん使いづらくなる

閉鎖危機が来ても大丈夫だな

俺も会社の拘束時間の２０％はクソしてます

とりあえずtarでくれ

ぞふりー？

すげー

>>9
寝言は寝てから言おうな

ウルトラ兄弟の長男もグーグル帝国の軍門に下った

アルゴリズム体操を速くやるとぶつかるぞ

ラー

クソ重いサイトは弾くアルゴリズムのほうがいいと思う。

＞ ただし、高い圧縮率の代償は長い圧縮時間だ（解凍時間は同じ）。Vandevenneはこう書いている:
＞ “最大でzlibの2〜3倍のCPU時間を要するので、Webの静的コンテンツのように、
> 一度圧縮したらそれを今後何度でも使える、というアプリケーションに向いている”。

だめじゃん。普通によくあるパターン。

ただし圧縮されたデータを戻すのに最新のＣＰＵでも処理には３０日はかかる見込み

>>12
それ圧縮入ってないぞｗ

>>15
はい？

こんなことしていないで
早くAndroidの完成度をIOSまで近づけてくれよ…

いつまであんなストレスの貯まるOSにしとくきだ

zipと間違えやすいお

なんにでも手だしよる

いまどき圧縮できる静的コンテンツなんてどんだけあるんだよ……

＞解凍時間は同じ

> “最大でzlibの2〜3倍のCPU時間を要するので、Webの静的コンテンツのように、
> 一度圧縮したらそれを今後何度でも使える、というアプリケーションに向いている”。

静的ページって昔と比べてすごく減った気がするんだがな。

　　　　　　　　 |:;:;:;:;:;:;:;:;:;:;:;:;:;:i;:;:;:;:;:;:;:;:;:;:;:;:;|
　　 　 　 　 　 |;:;:_:;:_:;:_:;:_;:;_:;:l:;_;:_:;:_:;:_:;:_;:_;|
　　　　　　　　|＿＿＿＿＿_|＿＿＿＿＿|
　　　　　　　　|　三|　　＿ 　 　 ＿　　 |三 !
　　　　　　　　|　三|　 三ｼ　　　ヾ三　 |三 |
　　　　　　　　|　三′　 .._　　　　 _,,..　 i三 | 　　
　　　　　　　　ト､ﾆ|　<でiﾝヽ　 ;'i"ｨでiﾝ |三.|
　　　　　　　　', iヽ!　 ､　‐' /　 !､　ーシ |ｼ,ｲ　　
　　　　　　　　 i,ヽﾘ　　　　,' :　 !.　　　　 |ｆ ﾉ　　　　
　　　　　　　　　ヾ!　　　　i ,､　,..､ヽ　　　lノ
　　　　　　　　　　|　　　　　 _　_　　　 ｲ l
　　　　　　　 　 　 l　　　 ,ｨﾁ‐-‐ヽ　　i /、 　なにそれ
　　　　　　 　 　 　 ﾞi､　　 ゝ､二ﾌ′ ﾉ/'"＼
　　　　　 　 　 　 　 | ＼　　ｰ一 ／ /　　 _,ﾝ'ﾞ＼
　　　　　　　　　　,ィ|､　 ＼　　　　 /_,､-'" _,.-''´ ｀丶､＿_
　　　　　　 ＿, イ　 | ヽ＿ 二＝''"　_,. -''´　　"""""´´　 ｀`ｰ

　　　　　　　　　 　 　 　 l三｀ｰ ､_;:;:;:;:;:;:j;:;:;:;:;:;:_;:;:;_;:��-三三三三三l
　　　　　　　　　　　 　　 l三　 r＝ﾐ''‐--‐';二,_￣　 　 ,三三三彡彡l_　　　この感じ・・・・
　　　　　　　　　　　　　　lﾐ′　 ￣　　　　ー-'"　　　 '＝ミﾆ彡彡/‐､ヽ
　　　　　 　 　 　 　 　 　 l;l　 ,_-‐ 、　　　 __,,.. - ､ 　 　 　 彡彡彳､.//　　zopか・・・・
＿＿＿＿＿＿＿∧,､＿‖　`之ヽ､, i　l´ _,ｨ辷ｧ-､、　　　彡彡'r ノ/＿ ＿_＿＿＿_
￣￣￣￣￣￣￣'`'`￣　1 　 　￣ﾌ/ｌ　l::. ヽこ~￣　　　　 彡彳~´/ ￣￣￣￣￣￣
　　　　　　　　　　 　 　 　 ヽ　　　´　:l　.l:::.　　　　　　　　　彡ｨ-‐'′
　　　　　　　　　　　　　　　 ゝ、　　/ :.　 :r-､　　　　　　　　彡′
　　　　　　　　　　　　　 ／ ｨ:ﾍ　　｀ヽ:__,ｨ='´　　　　　　　　彡;ヽ､
　　　　　　　　　 _,,..-‐'7　/:::::::ヽ　　　_: :_　　　 ヽ　　　 　 ｨ´.}::ヽ ヽ、
　　　　　　_,-‐'´　　　 {　 ヽ:::::::::ﾍ ｀'ｰ=＝=ｰ--　'　　　／ﾉ /::::::ﾍ, ヽｰ､

まあ静的コンテンツでなくてもこれが当たり前になるんだろうよ。
要はIT土方の帰宅時間が遅くなるってだけの話だよ。

>“最大でzlibの2〜3倍のCPU時間を要するので

結局、遅くなるのか ?

pngでおk

ゾッフリ

SSDで早くなった分全部持っていきそうだなｗ

いくら新しいものを作ってもノーフリーランチ定理があるからなぁ

bzip2より凄いの？

障害発生時の切り分けがメンドイ

>>12
わかっtar

動画をzipとかで圧縮してうｐする意味がよくわかん
元々圧縮し尽されてるデータだから容量なんてほとんど変わらんだろうに

>>33
俺もそう思ったｗ

>>24
そら適当な物で金を稼ぐほうが効率がいいからなー
完成度を上げて客を喜ばせる理由がない

5〜8%　ｗｗ

gzip、zip、zlib、pngで使われているdeflateアルゴリズムで
ちょっと圧縮率を高くするアルゴリズム

Webブラウザ、圧縮展開ソフト、画像表示ソフトなど、展開するソフトは
今までのものをそのまま使える

圧縮にかかる時間は2〜3桁多くなるが、5%〜8%小さくできる
こういうといいことがなさそうだけど、Webで送信する静的なテキストを
このアルゴリズムで事前に圧縮しておいたり、PNG画像を作るときに使うと
トータルの送信データ量を減らせる

7zip脂肪確定？

　　　|ｮ ､ ,_;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;:;;;;;;;;;;;;;;;;;;;;;;;ノ|
　　　ｮ;;;;;;;;;丶､ ;;; __;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;_,,: ィ";;_|
　　_)｀`' ‐､;;;;;;;;;;;;;;;｀ ` '' ー -- ‐ '' ";;;;;;;;;,:ィ彡
　　>';;,, 　 　｀`' ‐ｮ ､ ,_ ;;;;;;;;;;;;;;;;;;;;;;;;;;; , - '">了
　_く彡川fﾞノ'ノﾉ_ノノ　 ｀ ` '' ｰ -‐ '"　八ﾐ､､;.)
　 ヽ.:.:.:.:.:..::..:彡／　　く三)、{_,ﾉ (三ｼ　ヾ`~;.;.;）
　 ヽ.:.:.:.:.:.;=､彡 　, -−-_,, _,ｨ ､_,,ｨ,.-−､};f }
　 く .:.:.:.:.:!ﾊ.Yイ　 ､,ィ或tｭ､ﾞ:ミ　{,'ィt或 l:l,/
　　 ):.:.:.:.:|.Y }: :! 　｀ヽ 二ノ　　　ﾄ ` ‐''"l:l:f　　　逆に考えるのじゃ
　 　 ） :.: ﾄ､リ: :!　　　　　 ,r'､ 　 ヽ 　 　 ﾘ_）
　　 ｛ .:.: ｌ　｛: : }　　　　 ,/ﾞｰ､　 ,r'ヽ　　 l　　　　「zop画像がないなら自分で貼ればいい」
　　　 ヽ !　　ﾞi'''　 　　,ノ　 　 `'"　 丶.　,'
　 　 ,/´{　　ﾐ ﾞl　　　′ ,, ｨrｪェzｭ､,_ 〉/　　　　そう考えるのじゃ
　　,r{ 　 ＼ ﾐ　ヽ　　　ヘヾ'zｪｪｪッ',//
__ノ 　ヽ 　　＼　 丶　、　` ｰ--‐ '/ノ
　　 　 　＼ 　　＼ 丶、　　　 　 ,.ｲ!|ヽ｀ヽ、
　　 　 　 　 ＼ 　　＼ヽ ` ー‐;オ/ |ｌ　ト､　｀'ｰ-､__
　 　 　 　 　 　 ＼　　｀'ｰ-､　　/／　/:.:.}　 　　 　 ｀'ｰ､_
　　　　　　　 　 ｀､＼　　　／⌒ヽ　 /!:.:.|
　　　　　　　　　　｀､ ＼ /ヽLｆ___ハ/　　{
　　　　　　　　　　　　　 ′ /　! ヽ

そのまえにさあ、
<html>の言語、作り直そうぜ。
あれ、俺最初にホームページ自力で作ったときに、
なんて、不便な言語だと思った。
よくわからんけどcssとかjava スクリプトとかもまとめて、
みんなで話し合ってバージョン２作ろうぜ。
ついでに
アドレスバーにhttp://なんて意味不明な記号いれるのもやめようぜ

エントロピーモデル？w

>>23
おやすみ

>>41
虎フック軽減が無駄とか言いなさんなｗ　この部分が軽くなればネットワーク全体が速くなるんだから

日本企業で拘束時間+20％は無給で会社のために働かなくてはならないのに

> Webの静的コンテンツ
新悪の帝国的には、一番不要じゃろ＾＾
まぁ、gzipも充分速いと思えるがの〜。
それより一割近く速いッちゅ〜のは、大したモンじゃの〜。

Googleの技術って信用できるの？
圧縮するたびにファイルがGoogleのサーバに送信されるんじゃないの？

　　　　　　　　　　　　　　　　　　　　 ／j
　　　　　　　　　　　　　　　　　　　／__/　‘，
　　　　　　　　　　　　　　　　　 ／／　 ヽ　 ', 、
　　　　　　　　　 　 　 　 　 　 /／　　　　‘　 ! ヽ　　　　　　　　　　　　　…わかった　この話はやめよう
　　　　　　　　　　　　　　　　/ｲ　　　　　　 ', l　 ’
　　　　　　　　　　　　　　　iヘﾍ,　　　　　　 l |　　’
　　　　　　　　　　　　　　　| ｎﾍﾍ　_　 　 　 | |　　 l　　　　　　　　　　　 ハイ！！　やめやめ
　　　　　　　　　　　　　　　| l_| | |　ゝ￣`ヽ | |〈￣ﾉ
　　　　　　　　　　　　　　　ゝｿﾉﾉ 　 `ー‐'　l !　¨/
　　　　　　　　　　　 ｎ/7./7　∧　　　 　 　 j/　/　　　　　iヽiヽｎ
　　　 　 　 　 　 　 ｜! |///7/:::ゝ　　　ｒ=＝=ｵ　 　 　 　 |　!　| |/~7
　　　　 　 　 　 　 i~| | | ,'　'/:::::::::::ゝ、　l_こ./ヾ.． 　 　 ｎl　l　.|｜/
　　　　 　 　 　 　 | | | | l　{':j`i::::::::::::::::`ーｒ ' 　 　 　 　 |｜ー---{
　 　 　 　 　 　 　 | '"￣￣iﾉ .l::::::::::::::::::::::∧　　　　　　 |　ゝ　　　 ',
　　　　　 , 一 ｒ‐‐l　　　γ　/、::::::::::::::::::::::::〉ー=　___　 ﾍ　 ヽ　　　}
　　　　／ o　 |!:::::}　　　　 / o` ー ､::::::::::::i　o　,':::::::{`ヽ ﾍ　 　 　ﾉ
　　　/ o　 　 ﾉ:::::∧　　　/ヽ　　o　 ヽ::::::::|　o　i::::::::ヽ、　/　　　/
　　 /　　　 ノ::::::/　　　 /::::::::ヽ　　o 　ヽ:::|　o　{::::::::::::::Υ　　　/

構わんｌｈｚであげろ(aa略

>>50
今のgoogle使いづらくない？
このZopfliてのはどうか知らんが

“この徹底的で容赦のない圧縮アルゴリズムは、
エントロピーモデルの反復と最短経路アルゴリズムを駆使し、可能なすべての
デフレート表現のグラフ中にビットコストの低い経路を見つける”

こういう普段使わない英単語を並べればカッコイイと思ってるの？オナニー野郎は

launchって、ローンチっても読むんだな。

あ、圧縮率やのに『速い』て＾＾；
また、ボケても〜た (´；ω；`)

>>1
あ、面倒くさいから別にzipで良いよ

zipよりあきらかに軽いとか圧縮率で10%以上高いとかなら考えるけどｗ

発表声明がなんかかっこいい事はわかった

こんなgoogleライブラリを使われたらアナライズやら遠隔操作やら仕込まれてgoogleのやりたい放題になるぞ

使えねえ。負荷が高いのは普及しない。
CABファイルと同じこと。
多少、容量的に無駄があっても、ロード時間と大差ない程度の時間で圧縮できるのがいい。

入力中にプルダウンで候補が出るかどうか、
入力中に自動的に検索するかどうかは、
クッキーじゃなくてクエリーで指定できるようにしてくれ。
うざくてはしかたない。

その前にGoogleはスマホに
Google設定って変なアプリ消せるようにしろ！
気持ち悪くて困る

次はzepあたりか

この方が良い。



SnappyはGoogleが公開したオープンソースの圧縮ライブラリ。
圧縮率はイマイチだけど圧縮・伸長の速度は速い、Hadoopと相性良い。
ベンチマークを見た限りでは、圧縮率や速度はLZOと割と似た感じの数値になることが多い。

日本語文字列を圧縮してみる
サンプルファイルはTwitterから収集した日本語Tweet　843万件（941MB）。

所要時間は下記のようになった。実行したマシンのCPUはAthlonII X4 640。
形式　　所要時間　　サイズ
Snapp　　8.00秒　　　611MB
Gzip　　93.49秒　　401MB
BZip2　　666.66秒　　275MB

SnappyCodecでは圧縮にかかった時間は僅か8秒。速い。
試しにcpコマンドで元ファイルをそのままコピーしてみたところ、8.9秒かかった。つまり、圧縮した方がコピーするだけより速かった。
http://www.mwsoft.jp/programming/hadoop/snappy_memo.html

Googleは肝心の検索機能がおざなりなんだよ
books.goole.comとかPDFサイトとかヘタクソな日本語OCRかけた文章みたいでクラクラする

Googleここ最近の功績
Google ChromeのシェアがFirefox追い越す。
次世代HTTPに組み込まれる予定のSPDYの開発・普及。
コスパ最強のNexus7。
モバイルOSのWindowsであるAndroid。
C言語を拡張したプログラミング言語Google Go。
>>1これ

よっしゃ、わしが新しい圧縮プログラム考案したろ。
その名もyfx。
すべての数列は、y=f(x)の公式で表すことができることからその名がついた。
メリットは、圧縮サイズがめちゃ小さい。解凍は従来通り。
デメリットは、圧縮に時間がかかる。
滅多に使用しないギガバイトファイルの保管向け。
なんと1GBが100MBに！！

>>72
ジャストシステムに謝れ。

圧縮アルゴリズムが新しいのに
展開するのは互換性ありって不思議だな

展開にGZと互換性があるのはかなりの利点だな。後から読んで気づいた。
GZの高圧縮版として認識でき、実際にそうして使える。

例えるなら布団圧縮袋みたいなものだな。
圧縮率を高くしようとするとダイソンみたいな吸引力の高い掃除機が必要となってしまう。
圧縮した布団を戻すときは普通の手順で大丈夫。

zipとrarがここまで延命するとは思ってなかった。あとJPEGも

>>72
7zならbmp画像1GBが10MB以下になるよ

無慈悲な圧縮アルゴリズムか。
zipは火の海だな。

>>74
zipの一部やpng、gzipで使われる圧縮方式のdeflateはパラメータで
圧縮率と圧縮速度のトレードオフを調節できる
たいていの圧縮ソフトやPNG画像を保存できるソフトにはそういうオプションがあるじゃん

今回Googleが発表したアルゴリズムは圧縮率を突き詰めたもの

よく似たものに、圧縮率がやや高いZIPを作る圧縮ソフトkzip、PNG最適化ソフトpngoutってのが
あるんだけど、これはクローズドソースでアルゴリズムはナイショになってる

>>74
「この文章のこことここが同じだから繰り返しって書けばよくね？」ってのが圧縮だから
「こことここ」を見つけるのに時間をかけてもいいなら圧縮率はよくなる

Zopらんど

静的コンテンツにしか使えないんじゃ価値が相当下がっちゃうなあ

スパムメール業者を撲滅すればいいのさ

俺、すごい圧縮アルゴリズムを考えた。

・データを2進数にする。
・2進数化したデータのビットは必ず0と1のどちらかなので、0が何個続くか、1が何個続くかという形でデータを再構成する。
　(例) 0000 0000 → 0が8個連続する → 0 000 1000 (最上位のビットは　0 もしくは 1。残り7ビットで同一データの連続数を表現（最大128)

戻すときは上記と逆の手順で戻す。

Ｚｉｐで十分です

２０％研究のほうが驚いた
日本じゃ仕事１２０％だしな

人間が考えられるコンテンツなんかたかが知れてるんだから
通し番号ふっていってクラウドから落とせばいいんじゃないかとかいうのあったな

マイナーな圧縮形態だとRKなんてのがあったな
時間のかかり方が半端じゃなかった

>>83
目的に合わせて使い分けるしかないね
このスレでも名前が出てるlzoってのは圧縮・展開が速い代わりに圧縮率はソコソコ
一般的なWebブラウザは対応していないからHTTPでは使われないけど、VPNなんかで
使われてる

Webの動的コンテンツは今までどおりのアルゴリズムを使ったリアルタイムdeflate圧縮
静的コンテンツはZopfliで固めておいた高圧縮なdeflate圧縮とか
nginxには静的なコンテンツを.gzで用意しておけるモジュールがあるので、Zopfliが
即活用できるそうだ

ぞぷふり

漫画ゲームにでも出てきそうな専門用語言われてもなにがなんだか

>>77
zipやrarはディレクトリ構造も保存できるのとパスワードかけられるのが特徴
JPEGは1677万色の画像を非可逆ながらPNGよりも圧縮できるのが大きい

今更圧縮技術なんて、、、、もう、充分だろ。ZIPで十分だよ。

ちまちま圧縮するより、力技でそのまま送れよ　
もっとパワーを追求した方がいい

＞2〜3倍
正しく訳すこともできないバカ記者

>>92
JPEGは非可逆、PNGは可逆。
そりゃ非可逆の方が圧縮率高いに決まってる。削ってるんだから。

＞“この徹底的で容赦のない圧縮アルゴリズムは、
＞エントロピーモデルの反復と最短経路アルゴリズムを駆使し、可能なすべての
＞デフレート表現のグラフ中にビットコストの低い経路を見つける”

何言ってるのかぜんぜんわからんｗｗ

元のデータを生成するための計算式を作り出すアルゴリズムができれば
シャノン理論すら越えられる究極の圧縮プログラムが完成するはずなんだが

googleマップの建物に勝手に説明表示されるようになってから著しく動き遅くなってるぞ

y = f(h,s)
h=MD5ハッシュ値
s=ファイルサイズ
１分以内に元のファイルを作るプログラム作ってくれ。

Zopでくれ

>>1
> 〔*: 20%プロジェクト, 会社の拘束時間の20%は好きなこと（研究開発）をしてよい、というGoogleの内規。〕

経営の視野狭窄を見抜いている、頭良いなgoogleは。

Accept-Encoding: zopfli,gzip,deflate

それよりもっとエロ動画を探しやすくしろ

圧縮アーカイバとフィルタの違いがわかってないコメが多いね。

性的コンテンツなんていやらしい///

未だに会社でLZH使うじじいが居て困ってる。

3 to eight 8 more densely
が
5?8%圧縮率が高い
と訳され
two to three orders of magnitude more than zlib at maximum quality
が
最大でzlibの2?3倍のCPU時間を要するので
などと訳される不思議

プロジェクトページにだって"This compressor takes more time (~100x slower),"と書いてあるし
リンク先のPDF読めばどこが2,3倍だボケとなること間違いなし
http://zopfli.googlecode.com/files/Data_compression_using_Zopfli.pdf#page=3

>>20
だよねー　バックアップで圧縮するのなんて、どうせ解凍することのほうが圧倒的に少ないんだからさ
解凍時間長くていいから圧縮時間を短くしてほしいわな。

>>48
えっとどこに突っ込もうか　HTMLはすでにバージョン5だろｗ

>>85
011010010110100を圧縮してみてくれ　はよ

ちなみにあなたのそれはbmpのRLE圧縮

余計な画像とかフラッシュとかないだけで、
普通に早くなるんだけど？

０１０１・・・の一対一対応に込められた情報の量を
圧縮できる限界ってあるんですか？
つか、なければ困るはず・・・定理か何かがあるのかな。

DeepFreezer使ったり、らるち〜使ったり

>>109
サーバーに置いとく分には、軽いほうが転送・負荷が軽く済む。
クライアント・ユーザー側としては、既存のgzipと同じに展開できる。

いっそBSDソケットに圧縮アルゴリズム実装すれば良いのに

ヒープ領域で可変長データを扱うバッファ領域を確保する時に無駄なく使いたいんだけど、いい方法ないかな。

> two to three orders of magnitude more than zlib at maximum quality

2倍3倍どころじゃねーじゃん。

ヒープメモリなんて固定長のデータを集まりなんだから
頻繁にサイズ加減するリソースの方が勿体ない。

>>109
ここのスレを開くとgzipで転送される事がわかる。

クライアントの送信
GET /test/read.cgi/newsplus/1362141467/l50 HTTP/1.1
Accept: */*
Accept-Language: ja
Accept-Encoding: gzip, deflate
サーバーレスポンス
HTTP/1.1 200 OK
Date: Fri, 01 Mar 2013 16:41:21 GMT
Server: Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/0.9.8q PHP/5.3.8 mod_antiloris/0.4
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 7397
Connection: close
Content-Type: text/html


クライアント⇒サーバのリクエストヘッダでは Accept-Encoding: でブラウザ側が利用可能な圧縮形式を提示できます。
対してサーバ⇒クライアントのレスポンスヘッダでは Content-Encoding: でデータ本文の圧縮形式を通知できる。
http://www.kawa.net/works/perl/contenc/gzip-test.html

GPUかCPUに圧縮アルゴリズム用拡張命令実装しろよ

>>20
GCAかよw

　　::|　　　　　　　　　　　jj;;;
　　::|　　　　　　　　　 /|/人
　　::|　　　　　　　　N'　| | |
　　::|　　　　　　　l`!　　| | |
　　::|　　　　　　i`' / | | | |
　　::|　　　　　　|γ⌒ヾ　 l｀ヽ、
　　::|　 　 　 　 |::ヽ::. 　 ￣ 　 |
　　::|　　　　 　lヽ、 ､,,, )(､,,, ﾉ|＼ヾ
　　::|　　 　 　ﾉl:::､`(･)'�Wﾞ(･)´l 　|
　　::|　　 　 ﾉ 　ﾄ:. ,-‐'／iヽｰ-ｲ 　|　　　　　＜　　某社が対抗してBerdanの開発を
　　::|　　　　ﾉ;;ゝ_.／ 　　 | ＼ﾉ／　ヾ　　
　　::|　　　l;　ﾉﾄ､_ ヾ 　＼l／_,ｲﾉﾉﾄ､ヾ
　　::|　　　ヽ　 l ノ ＼ ヽiノ/ | l　 l 　ノ
　　::|　　　 　ヽ__ノ＼　 ＼｣／ ﾉヽ__ノ
　　::|-､,-､,- -‐´、　　ヽ　 　i ／ 　　`,ｰ- ､,-､
　　::|_ノ　　､＿　　 　 `ｰ┴'　　　 ＿, 　　ゝ、
　　::|　　　　ニ ￣｀　　ノ 　　ヽ　´￣ニニﾆ　ヽ

それよりいろんな機能をOFFに出来る様にしてくれ
勝手にリスト作ったりして、遅くてかなわん

グーグルの思想からすると、すべての情報をすべての端末にストレージすれば通信は検索だけになるからみんなハッピーといずれなる

>>1
だけどこのアルゴリズムを使うにはライセンスフィーを払わないと
駄目なんでしょう？

>>52
Googleのすごいとこだな
こういうのがあるから、新しい斬新なものも生まれてくるんだろうな

>>113
データは圧縮の効率が上がる毎に何の規則性も無いノイズに近付いて行って､完全に無規則なノイズになってしまったらそれ以上は可逆圧縮はできない｡

5%小さくなるのね・・・うんどうでもいいかな

bzip2のほうがよくね？

テキストベースで送受信してブラウザで処理しているうちは
どうしても無駄が生じるよ

>>126
ユニシスががめてるうちにPNGやFlashに取って代わられたGIFを思い出した

少しでも速くなるかと期待して
毎日デフラグするような無駄な努力ですね

良いの?

全世界のトラヒックが数％短縮されると考えれば
どえらいことですよ

>>1
＞Vandevenneは今日の発表声明で、“この徹底的で容赦のない圧縮アルゴリズムは、
＞エントロピーモデルの反復と最短経路アルゴリズムを駆使し、可能なすべての
＞デフレート表現のグラフ中にビットコストの低い経路を見つける”、と述べている。


日本語でおｋ

PNGの圧縮率向上が捗るな
と思ったらフィルタの最適化のほうが効果が高かった

２０年は遅いな

>>20
LDAPが採用するんじゃないの

5-8%の圧縮率を稼ぐ為に2-3倍のCPU時間使うんだろ？
それって元が取れてるのかなぁ

例えばさ、1%の圧縮率を稼ぐ為に10000倍の処理時間がかかるとしたら、
実用的じゃないよね。
それと同じ話なきがする。

元の大きさの1/2, 1/3になるから2-3倍のCPU時間使うんなら納得だが。

>>139
2〜3倍じゃないよ、2〜3桁
元を取れるのは人気サイトでアクセス数が多く滅多に更新しないデータ

重くなるソフト作ってユーザーにストレスを与え、信者にステマさせて最新ハードウェアを売ろう

>>１３９
ボトルネックがトラフィックにあってｃｐｕがあまってるんならアリでしょ

大き目のソフトのネット販売には良いかもね
サーバー負荷減らせる
ほかの用途は少なそう

Zopfliでくれ

Googleが開発したものって流行らなかったことの方が多いからなあ。
マップとかアースとかメールとかは数少ない成功例。

一般人には使われていても、それに気付かんじゃろ

　　,彡ニ三三三三三三三ﾆ=ヾ;:;:;:;:;:;;:;:;:;:;:;:;:;:;:;:;:;:i;:;:;:i'
　 ,彡ニ三三三三ニ三三ニﾆ;〃ヾ､;:;:;:;:;:;::;:;::;:::;:/;:;:/
　,彡彡,'',ﾆ=ﾐﾐミ三三三三ニﾆ彡　 ｀ﾞﾞ''ｰ-､;:;／;;:;/
　',彡'/ r' ﾉヽヾミ三三三三三彡'　　　_,,,,,,､ヽ;:;ｨ''|　　ＺＩＰ・・・
　 彡'|.|（‐'''"　'iﾐﾆニ三彡"´￣　　　　 ｀ﾞﾞｰ'　　;;;:|　　　　ＺＩＰ・・・
.　 彡i､ヾ　('　 ヾミﾆ三'　 　 　 　 　 __,,､　....ﾉ 　 /
　　彡ゝ ｀'' "　 |ミﾐﾐ' 　　　　　　　 　　 ,;'´　,,　 ｧ'　　ＺＩＰ・・・
　　 '彳｀ー‐i　 |ﾐﾐﾐ'　 　 　 　 　 ｀ﾞﾆｼ'　　 |､ﾆ'　　　　　ＺＩＰ・・・
　--､/ 　 　i　 |ミﾐ 　 　 　　　　.,,r‐''"　　　| ﾉ
　く'ﾉ　　 　:i 　ミﾐ 　 　 　　　　´　　.,　'　　 |'　　　　　ＺＩＰ・・・
　､＼ 　 　 .l　 ヾ 　 　 　 　 　　　.ﾉ（_,,､. 　 |　　　　　　　ＺＩＰ・・・
　:＼ヽ,　　 ヽ　　　　　　　　　 ／　　 ｀t‐一'
　::::ヽ ヽ　　　｀::.　　 　 　 ,; ' 　　　　　.:i　　　　　　　　ＺＩＰ・・・
　:::::::ﾍ ヽ　　　 ｀::. 　 　 　 　''"⌒ﾞ''一ﾉ　　　　　　　　　　ＺＩＰ・・・
　::::::::::ﾍ.ヽ　　　　ヽ､ 　 　 　 ｀ ー'ｰﾉ
　::::::::::::::ヽﾍ　　　　　｀ｰ┬‐一;;''""´
　＼､:::::::::ヽヽ　　　　　 /::ﾍ ）　｀ﾞ'ｰ､_
　〃｀ﾞｰ､;;;;＼＼　　　/i:::::::丿　' , ' , '｀ﾞヽ､

　 ,,彡ニ三三三三三三三ﾆ=ヾ;:;:;:;:;:;;:;:;:;:;:;:;:;:;:;:;:;:i;:;:;:i　　>>1.┏┓　┏━━━┓
　 ,彡ニ三三三三ニ三三ニﾆ;〃ヾ､;:;:;:;:;:;::;:;::;:::;:/;:;:/　　　　 ┃┃　┃　 　 　 ┃
　,彡彡,'',ﾆ=ﾐﾐミ三三三三ニﾆ彡　 ｀ﾞﾞ''ｰ-､;:;:;:;/;:;/'　　　　　┃┃　┗━━┓┃
　',彡'/ r' ﾉヽヾミ三三三三三彡'　　　_,,,,,,､ヽ;:;ｨ''|'　 　 　 　 ┃┃　　 ┏━┛┃
　 彡'|.|（‐'''"　'iﾐﾆニ三彡"´￣　　　　 ｀ﾞﾞｰ'　　;;;:|　　　　 　 ┃┃　　 ┃┏━┛
.　 彡i､ヾ　('　 ヾミﾆ三'　 　 　 　 　 __,,､　....ﾉ 　 /　　　　　　┗┛　　 ┗┛
　　彡ゝ ｀'' "　 |ミﾐﾐ' 　　　　　　‐'"ひi,;'´　 ,ｨ;;ｧ'　　　　　 　 ┏┓ 　　┏┓
　　 '彳｀ー‐i　 |ﾐﾐﾐ'　 　 　 　 　 ｀ﾞｰｼ'　　 |､ﾆ' 　 　 　 　 　 ┗┛　　 ┗┛
　--､/ 　 　i　 |ミﾐ 　 　 　　　　.,,r‐''"　　　| ﾉ
　く'ﾉ　　 　:i 　ミﾐ 　 　 　　　　´　　.,　'　　 |'
　､＼ 　 　 .l　 ヾ 　 　 　 　 　　　.ﾉ（_,,､. 　 |
　:＼ヽ,　　 ヽ　　　　　　　　　 ／　　 ｀t‐一'
　::::ヽ ヽ　　　｀::.　　 　 　 ,; ' 　　　　　.:i
　:::::::ﾍ ヽ　　　 ｀::. 　 　 　 　''"⌒ﾞ''一ﾉ
　::::::::::ﾍ.ヽ　　　　ヽ､ 　 　 　 ｀ ー'ｰﾉ
　::::::::::::::ヽﾍ　　　　　｀ｰ┬‐一;;''""´
　＼､:::::::::ヽヽ　　　　　 /::ﾍ ）　｀ﾞ'ｰ､_
　〃｀ﾞｰ､;;;;＼＼　　　/i:::::::丿　' , ' , '｀ﾞヽ､

>>115
>>120
ごめんなさい、>>109は
そういう用途はいくらでも似たようなのがあるので
別のベクトルで新しい圧縮を作ってほしいよねー。
例えばバックアップ用途にこんな圧縮→伸長は時間かかってもいいので
圧縮が短時間でできるのがあったりしたらいいねー、、、ってはなしです。

でも今考えてみたらバックアップを伸張するのは緊急時が多いから
やっぱりそこで時間かかったらだめだよｗｗｗｗということにきがついた

5%でも減らせたら、2ch掲示板などは、マシン台数削減できて月額出費が浮く。
もしくは、新規レンタルの時期を遅らせられる。

>>27
圧縮できる性的コンテンツなら…

2chだとピークで2600Mbpsの転送量がある。
100Mbpsのサーバーだと少なくとも26台必要。
5%カットできれば、転送量は2470Mbpsで一台マシンを減らせる。



http://traffic.maido3.com/VLpv/rTU0/h1Od/day.png
http://traffic.maido3.com/VLpv/rTU0/h1Od/


100Mbps完全帯域保証！転送量無制限！
ハイブリッドTigerサーバー月額\198,000
http://www.maido3.com/server/hybrid-tiger/
http://server.maido3.com/index.html

>>9
禿げ同

>>152
今2chはサーバー1台だったと思うけど
ちなみにニコ動は10Gbps級サーバーを束にしてたはず

＞最大でzlibの2〜3倍のCPU時間を要する
うむ〜

>>103
Content-Encoding: deflate

>>154
ここみてみ

レンタルサーバー maido3.com ２ちゃんねるの転送量
http://server.maido3.com/pie/

キーワード：zopでくれ

2 名前：名無しさん＠１３周年[] 投稿日：2013/03/01(金) 21:38:34.95 ID:oi9e1wsP0
zopでくれ

101 名前：名無しさん＠１３周年[] 投稿日：2013/03/01(金) 23:54:20.50 ID:gZ2B/t6v0
Zopでくれ



抽出レス数：2

gca形式で十分

>>77
jpeg2000がちーっとも普及しなかったことが笑える

＞エントロピーモデルの反復と最短経路アルゴリズムを駆使し、可能なすべての
＞デフレート表現のグラフ中にビットコストの低い経路を見つける”、と述べている。
これってつまり、
「元データを圧縮したらこういうビット列になります」の逆に
「伸長したら元データと同じになる複数の圧縮表現の中から最短の物を見付ける」
という理解でいいのかな。

>>160
マイクロソフトが乗り気でなかったことが致命的

なるほど、まったくわからん

圧縮ソフトの設定で圧縮度最高で処理みたいなのがよくあるけど
超絶に遅くなる割にサイズはあまり変わらないので使ったことがない

> 出力（圧縮結果）はzlibと互換性があるが、

ここがミソだな。zopで圧縮してもzlibで解凍できるのは大きい。
とりあえず仕事で使うファイルをrarで送ってくるやつは氏ねばいいと思う。

圧縮するにはインターネット接続が必要で、何か情報送るんでしょう？

普段7-Zip/GZip2/XZを使う機会が多いから正直今一だな
実際にビルドしてみたけど --i1000 なんてどう見ても実用度外視のネタオプションとしか思えない

>>167
GZIPのふつうの展開ルーチンが使える。
ブラウザなどが新規にバージョンアップしないくて良い。

>>152
なにげにバカにならないな
圧縮時間が２〜３桁増えたとしても、一度圧縮すれば再度圧縮はほぼ起きないわけだし
>>165
rarなら損失補償って意味があるからマシじゃん
いまだにlzhを使ってくるバカが多数いるぜ

Yahoo!検索を使用 ttp://www.yahoo.co.jp/
http://infoseek.co.jp/ http://leafbank.jp/
http://search.osaifu.com/ http://pc.moppy.jp/search/
http://www.nifty.com/search/
Google検索を使用 ttp://www.google.co.jp/
http://green.goo.ne.jp/ http://search.biglobe.ne.jp/
NAVER検索を使用 ttp://www.naver.jp/
http://www.livedoor.com/
Bing http://www.bing.com/

2chのスレ検索 http://find.2ch.net/ http://h.ula.cc/dance/ http://h.ula.cc/daishi/

>徹底的で容赦のない
ﾁｮﾝﾁｭﾝくせえ言い方だな

rarのリカバリほど無駄なものは無いな。
あれに助けられたことは一度も無いわ。

そもそも普通のPCでリカバリが必要になるエラーなんてそう起こらないし、
起こるとすればメディアの破損だが、たかだか10%程度の冗長じゃどうにもならんし。

徹底的で容赦のないって訳は面白すぎるだろ

Win7でZIPに固めるとパスワードがかけられず、
しかもWS2008で解凍しようとするとアクセス権限がないとか
わけのわからないエラーになる

死ね！！！！！！！！！

事前に圧縮しておくのなら7zipとかでいい
似たような技術だと思うし

ブラウザで展開できないだろ阿呆

さっさと2chでも採用しろよ

>>172
フロッピーのころは役に立ったぞ。
あと、SSDでも役に立つことがあると思われる。

.mag

論文ネタにはなるけど、実用面は微妙だな。
GO言語とかもどうなった？

7zipだけは、無い。
無断でコンテクスチョに入り込んだり、動作野良杉。
まぁ、アーカイバはrar一択じゃの〜。

そりゃ圧縮効率を１０％上げるとか、非常に有意義なのはわかるけど、
それ以上に広告のフラッシュやら動画やらで転送量やデーター量を
馬鹿食いしてる現状も何とかしてほしいわ。

昔のパソ通のころ、トップページに馬鹿でかいフルカラー画像張り込んでた
サイトにイライラさせられてたのを思い出す。

エプソンのプリンタを既に持っててサポセンのフォームにアクセスしただけなのに
Ads by Googleでエプソンのバナー広告が出るとか意味不明
そんなシステムで広告主から広告料を取るなよ

どういうことだか誰が説明しろ

googleが作ったのなんて怖くて使えません

>>184
今はブラウザでサーバにアクセスがあったら、そのときに圧縮して転送するって方法があるのだけど、
それにはこの方法は有効じゃなくて、あらかじめ圧縮しておいたものを提供するというときに
有効ってこと。

関連ツールでPNGの最適化楽しい

Content-Encodingが7zやxzに使われてるlzmaに対応すればWebの高速化に結構貢献すると思う

>>114
yz1形式懐かしいな
あんまり流行らなかったよね

ほぅうｗ

どんなに速くなっても
それ以上に余計なもの付けて遅くするだろ

最近全然使わなくなったGoogle

検索語をダブルクォーテーションで括らないと勝手にあいまい検索して不要なサイトがヒットする

>>188
しないだろ。lzma遅すぎ。