ERI Developer's BBS
  新規投稿 ┃ ツリー表示 ┃ 一覧表示 ┃ トピック表示 ┃ 検索 ┃ 設定 ┃ ホーム  
35 / 57 ツリー ←次へ | 前へ→

う〜〜〜〜ん(悩) L.Entis 02/6/5(水) 23:35
┗ う〜〜〜〜ん2(笑) KAZ 02/6/6(木) 23:02
 ┗ Re:う〜〜〜〜ん2(笑) L.Entis 02/6/6(木) 23:49
  ┗ Re:う〜〜〜〜ん2(笑) KAZ 02/6/8(土) 9:50
   ┗ Re:う〜〜〜〜ん2(笑) L.Entis 02/6/8(土) 15:27
    ┗ Re:う〜〜〜〜ん2(笑) KAZ 02/6/8(土) 20:40
     ┗ Re:う〜〜〜〜ん2(笑) L.Entis 02/6/9(日) 22:56
      ┗ MMX KAZ 02/6/10(月) 7:55
       ┗ ありました KAZ 02/6/10(月) 8:04

う〜〜〜〜ん(悩)
 L.Entis  - 02/6/5(水) 23:35 -

引用なし
パスワード
   いま、ERISA 符号として、最大、直前4つのシンボルを利用した統計モデルを使った、16ビットの精度を持つ算術符号をテスト中なのですが、なんだか、圧縮率がいまいちです。
ERINA に使っている1次ハフマンと比較すると、ほぼ間違いなく(期待通り)圧縮率はよいのですが、どうにも、普通の規則性のあるデータだと LZH よりも圧縮率が劣ってしまう…。
統計モデルの更新の仕方を変えるだけでかなり圧縮率が変わるのですが、とりあえずバグらしきものは修正したし…。4次PPMの圧縮率としてはこんなものなのでしょうか??
PPMのやり方そのものもまずいのかもしれませんが、4次とかだとパターンデータではLZHなどに負けてしまうものなのでしょうか??
<Mozilla/4.75 [ja] (Windows NT 5.0; U)@tokyo-fa2-82.kcom.ne.jp>

う〜〜〜〜ん2(笑)
 KAZ  - 02/6/6(木) 23:02 -

引用なし
パスワード
   「データ圧縮ハンドブック」は統計モデルのかなりのテクニックがかいてありますが、それらは全てやってもLZHに負けると?う〜む謎。

ずっとPCMを可逆圧縮考えてますが…Monkey's Audioクラスにはほど遠いです。
8ビット22.1Khz1チャネルのWAVEのサイズは5158KB
可逆mioで4699KB
Monkey's Audioで4321KB
自作1次PPMで4494KB(次数を増やすと圧縮率が低下する)
猿はすごいです!どんなアルゴリズムやら、公式サイトにいっても猿とのインターフェースのソースは公開しているものの圧縮部分のコードは公開していないです。
しかもエンコードが相当早い!PPM使っているとは思えないですね。単純なアルゴリズムなんだとは思いますが、公式サイトの解説みても一般的なことしか書いていないし…
<Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)@M067164.ppp.dion.ne.jp>

Re:う〜〜〜〜ん2(笑)
 L.Entis  - 02/6/6(木) 23:49 -

引用なし
パスワード
   ▼KAZさん:
>「データ圧縮ハンドブック」は統計モデルのかなりのテクニックがかいてありますが、それらは全てやってもLZHに負けると?う〜む謎。

まあ、速度とかパフォーマンスにかなり重点を置いていますので(ある程度無視するんじゃなかったのか?)、最高のものとはいえないでしょう。
とりあえず、現時点でのスペックは、

16ビットの算術符号であること(高速化のため)<かなり高速と思われます
最大約3MBのワークを必要とする(大抵そんなには使わないけど)
圧縮率が、ERINA でつかっている1次ハフマンより1〜2割良い。

こんなところです。
もちろん、ERISA が最大のターゲットとしているデータだと LZH よりもだいぶ圧縮率はいいです。
ちなみに、まったくのエントロピー符号のみ(差分処理などを行わない)での比較をすると、ERISA と ERINA では以下のようなサイズの差があります。(性能評価のページにある画像です)

photo.bmp : 1407 KB
ERINA : 1143 KB
ERISA : 1047 KB

scape.bmp : 901 KB
ERINA : 619 KB
ERISA : 470 KB

eri.bmp : 698 KB
ERINA : 361 KB
ERISA : 257 KB

PPMの統計モデルのツリーの構成を、パターンデータに特化してあげれば、パターンデータでは圧縮率が上がるのですが、マルチメディア系のデータだと圧縮率が伸び悩むので、とりあえずこんなんでいこうかと…(汗)
<Mozilla/4.75 [ja] (Windows NT 5.0; U)@tokyo-fa1-226.kcom.ne.jp>

Re:う〜〜〜〜ん2(笑)
 KAZ  - 02/6/8(土) 9:50 -

引用なし
パスワード
   >16ビットの算術符号であること(高速化のため)<かなり高速と思われます
Pentium系は普通32ビット単位が効率的だと思うので32ビット算術符号とスピード変わらない気がしますが、自分では試してないですがどうでしょうか?
<Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)@R203198.ppp.dion.ne.jp>

Re:う〜〜〜〜ん2(笑)
 L.Entis  - 02/6/8(土) 15:27 -

引用なし
パスワード
   ▼KAZさん:
>>16ビットの算術符号であること(高速化のため)<かなり高速と思われます
>Pentium系は普通32ビット単位が効率的だと思うので32ビット算術符号とスピード変わらない気がしますが、自分では試してないですがどうでしょうか?

演算制度の関係で高速化できるんですよ、16ビットだと。
それに、MMX も使えますしね。
<Mozilla/4.75 [ja] (Windows NT 5.0; U)@tokyo-fa2-214.kcom.ne.jp>

Re:う〜〜〜〜ん2(笑)
 KAZ  - 02/6/8(土) 20:40 -

引用なし
パスワード
   >演算制度の関係で高速化できるんですよ、16ビットだと。
>それに、MMX も使えますしね。
もしかして32ビット変数でRangeCoderって8ビット単位で出力できますが、このとき精度は32-8で24ビット。
これの出力を16ビットで行えば32-16で精度は16ビット。ってことですか?
<Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)@R217040.ppp.dion.ne.jp>

Re:う〜〜〜〜ん2(笑)
 L.Entis  - 02/6/9(日) 22:56 -

引用なし
パスワード
   ▼KAZさん:
>もしかして32ビット変数でRangeCoderって8ビット単位で出力できますが、このとき精度は32-8で24ビット。
>これの出力を16ビットで行えば32-16で精度は16ビット。ってことですか?

いえ、演算制度が16ビットの算術符号と言う意味です。
出力(入力)は32ビット単位です。
<Mozilla/4.75 [ja] (Windows NT 5.0; U)@tokyo-fa2-250.kcom.ne.jp>

MMX
 KAZ  - 02/6/10(月) 7:55 -

引用なし
パスワード
   32ビット出力。それは早そうですね。
算術符号でMMXを応用するにはどうすればよいのでしょうか?
そもそもMMXはおおざっぱな機能しかわからないものですから、具体的にどのような命令セットがあるか知りたいです。
通常の86命令に関してはpdfファイルダウンロードしたのでいいのですが、MMX,SSE,SSE2などはないものでしょうか?
<Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)@U108128.ppp.dion.ne.jp>

ありました
 KAZ  - 02/6/10(月) 8:04 -

引用なし
パスワード
   >通常の86命令に関してはpdfファイルダウンロードしたのでいいのですが、MMX,SSE,SSE2などはないものでしょうか?
ダウンロードしたpdfに含まれていました。しかしとてもムズカシイかき方をしていて大変そうです。
符号化、復号化に応用できそうな応用できそうな機能があったら教えてくださいね。
<Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)@U108128.ppp.dion.ne.jp>

  新規投稿 ┃ ツリー表示 ┃ 一覧表示 ┃ トピック表示 ┃ 検索 ┃ 設定 ┃ ホーム  
35 / 57 ツリー ←次へ | 前へ→
ページ:  ┃  記事番号:
7920 C-BOARD v3.02 is not Free?