【2ch】圧縮アルゴリズム【オリジナル】
■ このスレッドは過去ログ倉庫に格納されています
0001１
NGNG中途半端に圧縮されて拡張子が.2ch
0002デフォルトの名無しさん
NGNG0003デフォルトの名無しさん
NGNGGPL以外は認めない！
0004デフォルトの名無しさん
NGNG0005デフォルトの名無しさん
NGNG0006デフォルトの名無しさん
NGNG0007１
NGNGなるほど。ﾖｻｹﾞ
作ります。じゃなくて作りませんか？にした理由は
プログラムを始めたばかりで一人では無理そうだったからです。
みなさんで協力していけたらいい物ができるのではないかと。
0008デフォルトの名無しさん
NGNG0009１
NGNGクラスでは出来る方ですけど。
構造体やポインタなんて全然まだで、配列ができる程度です。
0010デフォルトの名無しさん
NGNG0011デフォルトの名無しさん
NGNG>>1は習作として作ってみれ。
0012１
NGNG0013デフォルトの名無しさん
NGNG0014デフォルトの名無しさん
NGNG未知のＡＡ５個くらいに対して、一番いい圧縮結果を出したソフトが優勝。
0015デフォルトの名無しさん
NGNG0016デフォルトの名無しさん
NGNG0017デフォルトの名無しさん
NGNGうん
0018デフォルトの名無しさん
NGNGAA固有の特徴が見つかるとナイスってことだよね？
0019デフォルトの名無しさん
NGNG使われやすい文字が限られてるとかじゃないかな。
0020デフォルトの名無しさん
NGNGとにかく所有するテーブルが鍵になるのでは？
0021デフォルトの名無しさん
NGNG0022デフォルトの名無しさん
NGNGそのAAと対象AAとの差分を圧縮した結果をつなげる。
0023デフォルトの名無しさん
NGNGあるいは差分を圧縮せずにつなげて全体を圧縮。
0024デフォルトの名無しさん
NGNG0025デフォルトの名無しさん
NGNGgzip なんか、全然圧縮率良くないじゃないか。
LHAよりも悪いんだぞ。
bzip はそれらよりももっと良いし。
0026デフォルトの名無しさん
NGNGAA専用だったらさ、MP3みたく多少劣化しても元絵が判別できればOKということに
すれば、かなり圧縮できたりしないかな？
0027デフォルトの名無しさん
NGNG似た文字は置き換えちゃうとか？
0028デフォルトの名無しさん
NGNG0029デフォルトの名無しさん
NGNGAA職人が泣くぞ。
0031デフォルトの名無しさん
NGNGピクセル単位で命懸けてるAA職人に失礼かと。
0033デフォルトの名無しさん
NGNG>>32
うん。俺職人じゃないけど、モナ板住人なんで。
0034デフォルトの名無しさん
NGNG0035デフォルトの名無しさん
NGNGそれは圧縮とは言わない。
0036デフォルトの名無しさん
NGNGお馬 さん
0037デフォルトの名無しさん
NGNGhttp://pc3.2ch.net/test/read.cgi/tech/1028570486
0038デフォルトの名無しさん
NGNGまで圧縮できないか？
0039デフォルトの名無しさん
NGNGtech/1028570486までは逝ける。
1028570486はlong intで表現できるからtech(4byte)。
tech等はテーブルを持ってindexは1byteで表現しちまおう。
よって、このスレは5byteで表現できる。
0040デフォルトの名無しさん
NGNG0041デフォルトの名無しさん
NGNG0042デフォルトの名無しさん
NGNGこれで、少なくとも 2ch に存在するAAなら7byteで表現化農家
0043デフォルトの名無しさん
NGNG0044デフォルトの名無しさん
NGNG0045デフォルトの名無しさん
NGNGオススメあったら教えて。
馬鹿でもなんとなくわかる本希望で
0046デフォルトの名無しさん
NGNGCマガの先月（7月）号
0047デフォルトの名無しさん
NGNG素直にデータ圧縮ハンドブック読んでおくのがいいかと。
0048デフォルトの名無しさん
NGNG英語でも良いなら
Kluwer Academic Publishers "Compression and coding algorithms"
がおすすめ。
日本語は参考になる本が少ないからな〜
データ圧縮ハンドブック と C MAGAZINE 以外には、
文書データ圧縮アルゴリズム入門くらいしかないが、絶版だし。
そもそも、圧縮自体が研究が進みすぎて下火になっているという罠。
画像圧縮の方は盛んだけどな。
何か画期的な圧縮法を>>45が発明することを期待する。
0049デフォルトの名無しさん
NGNG0050デフォルトの名無しさん
NGNG0051デフォルトの名無しさん
NGNGその方が、圧縮率が悪くなりそうだよ。
基本パターンやカッコなどの対応をあらかじめ学習しておくのがAA向きか。
0052デフォルトの名無しさん
NGNG0053デフォルトの名無しさん
NGNG小さいサイズのAAなら職人技が光るけど、
大きいサイズだとツールを使ったものも多いよね。
0054開発者 ◆GODLHAg2
NGNG0055デフォルトの名無しさん
NGNG0056デフォルトの名無しさん
NGNGああ特許の件で何も影響力が無かったカスか、まあいらっしゃい
0057デフォルトの名無しさん
NGNGいっそのことマイナーな圧縮アルゴリズム使ってみないか？
おれはBPEぐらいしか知らんが。
0058デフォルトの名無しさん
NGNG0059デフォルトの名無しさん
NGNG0060デフォルトの名無しさん
NGNGかなり圧縮できそう。
006158
NGNGJPEG圧縮ﾌﾟﾙグラムを作ろうとしたがやはり無理か。
006458
NGNG鬱出汁脳。
0065デフォルトの名無しさん
NGNG([ISOと圧縮対象ファイル]の[同じデータ]を探してISOのデータアドレスをアーカイブに書く)
回答時はネットに接続して、ISO参照の部分だけISOから抜き取って解凍。
DQNだと思われなら無視なされて結構です。
0066デフォルトの名無しさん
NGNGなに言ってんだかさっぱりだけど
恒常性の無いデータなんか
使いモンにならんぞなモシ
0067デフォルトの名無しさん
NGNGDQN
どうせなら辞書鯖用意して巨大共通辞書ファイル置くってのはどうか。
0068デフォルトの名無しさん
NGNGそのISOファイルへのポインタが消費するバイト数 ＞
ISOファイルを利用することによって節約できるバイト数
になる予感。
006967
NGNG･巨大鯖
･クライアント
･高速回線
ユーザがファイル圧縮を選択するとファイル内容が巨大鯖に転送されます。
……書いてて面倒くさくなってきたので続きはTHComp参照。
案外実現できそうな気がしない？
0070デフォルトの名無しさん
NGNG昔導き出された結論はこうだ・・・
「インデックスのサイズが圧縮元のサイズと同じになる」
0071デフォルトの名無しさん
NGNG１８GBに収まるってのがあった
この辞書を各クライアントが持つってのはどうかな？
当時は夢の容量だったから、だからどうしたレベルだったけど今ならいけそうだね
0072デフォルトの名無しさん
NGNG0073デフォルトの名無しさん
NGNGBPEって特許からむのかな。
Cマガの記事は読んでないのでよく知らないけど、
セクションサイズを可変にするのはダメ？
255種類のByteが出現するまで読み込んで、
その中で最も多いペアを出現していない残りの１種類のByteに置き換える。
セクションのデリミタとしてもう1Byte予約しておかないとダメか。
007457
NGNG俺もCマガの記事は読んだこと無いけどBPEの作者は特許取らない
ような事を言ってたらしいよ。
たしかBPEでは200種のByteが出てくるまで読みこんで(これを１ブロックとする)
その中から最多頻度のペアから順次残りの56種に割り当てて
圧縮していって圧縮が効かなくなるか256種使いきるまでやって
ペア表(軽く圧縮)・ブロックサイズ・圧縮データの組を順次出力してたと思う。
BPEが実際に使われた例は1しか知らないな。(除自作プログラム)
0075デフォルトの名無しさん
NGNGなるほど。そもそもブロックサイズは固定じゃなかったのか。
適当に前処理すれば圧縮率上がりそうな感じするね。
007657
NGNGブロックソーティング→ランレングス圧縮→BPE(Byte Pair Encoding)
※ランレングス圧縮を間にはさむのは、ブロックソートすると同値の連続が多くなり、
それをそのままBPEするとその連続の個所で無駄にペアが消費されるから。
でも本当に圧縮率が上がるかどうかは不明(汗
0077デフォルトの名無しさん
NGNGそれをやるなら普通に BWT→MTF→BPE なのかな。
BPEってもっと効率の良いブロックサイズを決定する方法がある気がする。
007857
NGNG>RLE→BPE は太るよね。
あ、RLEでビット単位の操作が入るようなのだとBPEは効きにくくなるな。
テキスト専用の圧縮にするなら0x00を長さ表示の開始コードに割り当てれば
実際の圧縮の場合は問題無いかも。
#それとも、まだ勘違いしてる？
>それをやるなら普通に BWT→MTF→BPE なのかな。
あと、ここ↓の2.14.15をみるとBWT→MTFよりMTF→BWTの方がいいみたい。
http://www.ingnet.or.jp/~kojif/mu/comp/bwt.htm
>BPEってもっと効率の良いブロックサイズを決定する方法がある気がする。
このへんは良い方法思いつかないな。
以前自分で作った(拾ったコードを改変した)やつではデフォルトのパラメータ使ってたし。
0079デフォルトの名無しさん
NGNGBWT→RLEの時点で、前後のByte同士の関連は無くなってると思っただけです。
> あと、ここ↓の2.14.15をみるとBWT→MTFよりMTF→BWTの方がいいみたい。
「２．１４．５ メモ」のこと？
そこに書いてある“MWT”ってのは何なのかわかんないけど、
BWT→MTFよりMTF→BWTの方がいいという意味では無いと思いますよ。
そこに書いてあるのは、BWT後のデータを効率よく圧縮する方法として、
まずMTFで0（ゼロ）を増やしてからZero-Runをかけると良いってな意味かと。
0080デフォルトの名無しさん
NGNG0081デフォルトの名無しさん
NGNG現在、世界中のサーバに格納されているテキスト文書を
URIの形をインデックスの表現とすると考える。
このURIリストを圧縮することで、世界中の文書を圧縮できたと仮定する
これは、実際は間違いだが、下限値を記述することにはなる。
4億のサーバがあると仮定。各サーバが10文書持つと仮定。
URIの長さがIPアドレスの長さ4byteの2倍程度に圧縮できると仮定。
4億×10×8 = 29.8 GByte
結論： 18GBではとても無理だ！
0082デフォルトの名無しさん
NGNGまあ10年前なら18GBを楽に割りそう
ネット環境の発達が文書量のインフレを加速してますな
0083デフォルトの名無しさん
NGNGMTFかけただけならサイズは増えないだろ。
■ このスレッドは過去ログ倉庫に格納されています