サイトトップへ
OSASK.NET
  サイトトップへ       新掲示板(閉鎖済)   Wiki(凍結済)   旧掲示板(廃止済)   ニュース(廃止済)  
2: 2004-06-11 (金) 04:44:40 ソース 3: 2004-06-11 (金) 04:44:40 ソース
Line 5: Line 5:
* 補助バッファ * 補助バッファ
-いきさつと原理 -いきさつと原理
---tek1/tek2がBMPなどの圧縮に際して思いがけずよい傾向を示しました。それで非常に気をよくして、JPEGに勝てる方法はないものかと(もちろんあるわけないのですが)あれこれ考えていたら、以前ディスクイメージ圧縮の際にFATの部分が圧縮しにくそうで、これをどうにかしたいと考えていて、なかなか面白そうなアイデアを持っていたのを思い出しました。+--tek1/tek2がBMPの圧縮に際して思いがけずよい傾向を示しました。それで非常に気をよくして、JPEGに勝てる方法はないものかと(もちろんあるわけないのですが)あれこれ考えていたら、以前ディスクイメージ圧縮の際にFATの部分が圧縮しにくそうで、これをどうにかしたいと考えていて、なかなか面白そうなアイデアを持っていたのを思い出しました。
--たとえばFAT16では 03 00 04 00 05 00 06 00 07 00 08 00 ... みたいな部分がよく出てきます。これをもっと一般的に考えると、2バイトの整数が0x0000~0xFFFFまであって0000からFFFFまで順番に並んだ128KBのデータ(もしくはそれに類するもの)を圧縮できるかということです。 --たとえばFAT16では 03 00 04 00 05 00 06 00 07 00 08 00 ... みたいな部分がよく出てきます。これをもっと一般的に考えると、2バイトの整数が0x0000~0xFFFFまであって0000からFFFFまで順番に並んだ128KBのデータ(もしくはそれに類するもの)を圧縮できるかということです。
---この128KBにおいては、00~FFまでのすべてのバイトの出現率は等しく、また2バイト以上の繰り返し構造は皆無で、まさにtek1/tek2が1バイトも縮められないタイプのデータです。まあtek2では、符号寿命を512に設定してやれば、上位バイト部分に短い符号を割り振って(1bitとか)16bitを9(下位)+1(上位)=10bitにして7割程度には圧縮できるかもしれません。しかしこれでも所詮は7割です。人間が見れば明らかに圧縮できそうな感じのデータなのに、たったの3割しか減らせていないわけです。+--この128KBにおいては、00~FFまでのすべてのバイトの出現比率は等しく、また2バイト以上の繰り返し構造は皆無で、まさにtek1/tek2が1バイトも縮められないタイプのデータです。まあtek2では、符号寿命を512に設定してやれば、上位バイト部分に短い符号を割り振って(1bitとか)16bitを9(下位)+1(上位)=10bitにして7割程度には圧縮できるかもしれません。しかしこれでも所詮は7割です。人間が見れば明らかに圧縮できそうな感じのデータなのに、たったの3割しか減らせていないわけです。
--補助バッファを使った圧縮では、まずこのデータ列を次のように解析します。 --補助バッファを使った圧縮では、まずこのデータ列を次のように解析します。
 00 00 01 00 02 00 03 00 04 00 05 00 06 00 07 00  00 00 01 00 02 00 03 00 04 00 05 00 06 00 07 00
Line 19: Line 19:
 02 30 00 [02 20 00 02 20 00 02 20 00 ...]  02 30 00 [02 20 00 02 20 00 02 20 00 ...]
--24bitカラーのBMPの場合も、3バイト前の差分にすればx方向のグラデーションに対して小さな差分値がたくさん得られるでしょう(もしくはFFやFEなどの大きな差分値)。xのドット数の3倍の前の差分にすれば、y方向のグラデーションにも対応できます。 --24bitカラーのBMPの場合も、3バイト前の差分にすればx方向のグラデーションに対して小さな差分値がたくさん得られるでしょう(もしくはFFやFEなどの大きな差分値)。xのドット数の3倍の前の差分にすれば、y方向のグラデーションにも対応できます。
---tek2では差分値に対しても出現頻度にあわせてビット長を調節します(本データと差分値とでは統計上別々に扱われ、符号寿命も独立に存在する)。これによりグラデーションが非線形でスライド辞書法による恩恵がなくても結構小さくできることが予想されます。そんなわけでもしかしたら、WAVファイルに適用したときはADPCMに近い圧縮率にはなるかもしれません。tek1やtek3では残念ながらこのような効果は一切期待できません。+--tek2では差分値に対しても出現頻度にあわせてビット長を調節します(本データと差分値とでは統計上別々に扱われ、符号寿命も独立に存在する)。これによりグラデーションが非線形でスライド辞書法による恩恵がなくても結構小さくできることが''予想''されます。そんなわけで''もしかしたら''、WAVファイルに適用したときはADPCMに近い圧縮率にはなるかもしれません。tek1やtek3では残念ながらこのような効果は一切期待できません。
---ということでせいぜいADPCMレベルであって、結局不可逆圧縮のMP3やJPEGに追いつける見込みがないことに変わりはない。見分けられない、聞き分けられないレベルの劣化すらないということだけがせいぜいのなぐさめ。 ---ということでせいぜいADPCMレベルであって、結局不可逆圧縮のMP3やJPEGに追いつける見込みがないことに変わりはない。見分けられない、聞き分けられないレベルの劣化すらないということだけがせいぜいのなぐさめ。
--本質的にはスライド辞書法のままなので、展開速度はほとんど変わりません。しかし補助バッファの分だけ(補助バッファをスライド辞書で参照する分だけ)追加のメモリが必要です。 --本質的にはスライド辞書法のままなので、展開速度はほとんど変わりません。しかし補助バッファの分だけ(補助バッファをスライド辞書で参照する分だけ)追加のメモリが必要です。

トップ   差分 バックアップ 複製 名前変更 リロード印刷に適した表示   ページ新規作成 全ページ一覧 単語検索 最新ページの一覧   ヘルプ
新着

目次
メンバー一覧


最新の20件
2016-10-01 2016-09-08
  • @MenuBar.
2016-09-07 2016-09-04 2016-08-15 2015-09-23 2014-07-30 2014-07-04 2014-02-04 2013-10-26 2013-06-21 2013-06-17 2013-06-15 2013-04-02 2013-02-09 2013-02-04 2012-12-25 2012-12-01 2012-05-28 2012-03-31

トピック一覧
一般用コメント最新
新掲示板lina
2016/9/5 20:58
SandBoxゲスト
2016/9/4 12:01
RecentDeletedlina
2015/6/2 19:29
Old-OSASK-MLlina
2014/6/29 9:14
hideyosi/メールhideyosi
2014/1/6 20:17
hideyosi/募集中lina
2013/11/8 19:56

このサイトは川合秀実から委託を受けて、OSASKコミュニティによって管理・運営されています。