8: 2009-11-17 (火) 12:07:37  |
現: 2024-01-08 (月) 12:59:03 ゲスト |
| - | * [[tek1]]の続き | + | TITLE:x |
| | + | * [[tek1]]の続き [#l23f9928] |
| | -ここでは全体像に影響しない、より些末なことを書く | | -ここでは全体像に影響しない、より些末なことを書く |
| | | | |
| - | * 符号寿命 | + | * 符号寿命 [#g7ccc83d] |
| | -まず最初は以下の符号寿命が初期値として設定されている。 | | -まず最初は以下の符号寿命が初期値として設定されている。 |
| | --符号寿命A：2048 | | --符号寿命A：2048 |
| | 1111101 : 直前の寿命の1/32倍（端数切捨て） | | 1111101 : 直前の寿命の1/32倍（端数切捨て） |
| | | | |
| - | * UC0符号パラメータの動的補正 | + | * UC0符号パラメータの動的補正 [#e1746eac] |
| - | *** 概念 | + | *** 概念 [#a6735e9a] |
| | -UC0は0以上の整数をエンコードできる符号で、そのためにパラメータテーブルがある。このテーブルがたとえば [ 0, 4, 8, 10, 12 ] の場合、符号長は当然次のようになる。 | | -UC0は0以上の整数をエンコードできる符号で、そのためにパラメータテーブルがある。このテーブルがたとえば [ 0, 4, 8, 10, 12 ] の場合、符号長は当然次のようになる。 |
| | --0：1bit (1+0) | | --0：1bit (1+0) |
| | -そうであれば、このテーブルを一時的にちょっと細工して、 [ 0, 4, 8 ] にしてしまおう、というのが動的補正である。これだと17-272で1bitの得がある。 | | -そうであれば、このテーブルを一時的にちょっと細工して、 [ 0, 4, 8 ] にしてしまおう、というのが動的補正である。これだと17-272で1bitの得がある。 |
| | -そしてさらに、59までしかないのなら、ここに8bitを割り当てるのも合理的ではないだろう。ということで、さらに補正して [ 0, 4, 6 ] にしてしまう。17-80で2bit得する（さっきのを含めると3bitの得）。 | | -そしてさらに、59までしかないのなら、ここに8bitを割り当てるのも合理的ではないだろう。ということで、さらに補正して [ 0, 4, 6 ] にしてしまう。17-80で2bit得する（さっきのを含めると3bitの得）。 |
| - | *** 実装 | + | *** 実装 [#p740d5f8] |
| | -当然実装に際しては、エンコード側とデコード側とで同じ最大値を予測していないと、食い違いが生じてデコードできなくなる。ということでそれを説明する。 | | -当然実装に際しては、エンコード側とデコード側とで同じ最大値を予測していないと、食い違いが生じてデコードできなくなる。ということでそれを説明する。 |
| | --byの値のときは、残りデコードバイト長-1が最大値（-1するのは、そもそもbyがUC0の値を+1して利用しているため） | | --byの値のときは、残りデコードバイト長-1が最大値（-1するのは、そもそもbyがUC0の値を+1して利用しているため） |
| | --dsでは、これとは逆にブロックのデコードとともに最大値が大きくなっていくという性質がある。したがって現在の修正UC0パラメータで表現可能な最大値を控えておき、これよりも予測最大値が大きくなったら再構成を行えばよい。 | | --dsでは、これとは逆にブロックのデコードとともに最大値が大きくなっていくという性質がある。したがって現在の修正UC0パラメータで表現可能な最大値を控えておき、これよりも予測最大値が大きくなったら再構成を行えばよい。 |
| | | | |
| - | * UC0符号パラメータのフォーマット | + | * UC0符号パラメータのフォーマット [#jec768c6] |
| - | *** 基本 | + | *** 基本 [#s4c2098e] |
| | -ここは結構ややこしい。ブロックサイズが最大8MBなので、UC0でエンコードされる数字も最大で8M程度までありうるが、これはつまりパラメータテーブルの各要素を単純に並べて最後にターミネータをつけるような方法だと、1要素あたり5bitを要し、 [ 0, 4, 8, 10, 12 ] なら30bitも要してしまうことになる。これは4バイト近くであり、こんなものをそのまま使うわけにはいかない。 | | -ここは結構ややこしい。ブロックサイズが最大8MBなので、UC0でエンコードされる数字も最大で8M程度までありうるが、これはつまりパラメータテーブルの各要素を単純に並べて最後にターミネータをつけるような方法だと、1要素あたり5bitを要し、 [ 0, 4, 8, 10, 12 ] なら30bitも要してしまうことになる。これは4バイト近くであり、こんなものをそのまま使うわけにはいかない。 |
| | --短くエンコードできれば、パラメータ切り替えのオーバヘッドが減り、寿命を短く設定できるようになり、つまりそのときそのときでの最適なパラメータを使う機会が増え、結果的に圧縮率が上がるというわけである。 | | --短くエンコードできれば、パラメータ切り替えのオーバヘッドが減り、寿命を短く設定できるようになり、つまりそのときそのときでの最適なパラメータを使う機会が増え、結果的に圧縮率が上がるというわけである。 |
| | --ここに示す方法では [ 0, 4, 8, 10, 12 ] を19bitで表現できる（1101010001000010010）。 | | --ここに示す方法では [ 0, 4, 8, 10, 12 ] を19bitで表現できる（1101010001000010010）。 |
| | --30→19ではたいした事はないと思うかもしれないが、 [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 ] も19bitになるので（1111111111111010010）、ここの複雑さに失望しないでほしい（まあtek1の中で一番複雑だというだけで、本質的にはそんなに複雑ではないのだが。Cのソースで50行ほど）。これは70→19に匹敵する。 | | --30→19ではたいした事はないと思うかもしれないが、 [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 ] も19bitになるので（1111111111111010010）、ここの複雑さに失望しないでほしい（まあtek1の中で一番複雑だというだけで、本質的にはそんなに複雑ではないのだが。Cのソースで50行ほど）。これは70→19に匹敵する。 |
| - | *** モードヘッダ | + | *** モードヘッダ [#g6b770f7] |
| | -最初はモードヘッダである。上記の例だと最初の0010の4bitがこれに相当。 | | -最初はモードヘッダである。上記の例だと最初の0010の4bitがこれに相当。 |
| | --（ここでも下位を右側に書くために、ストリームを右から左へ記述していることに注意） | | --（ここでも下位を右側に書くために、ストリームを右から左へ記述していることに注意） |
| | ---ちょうど上記でモードビットを外して最初に000をつけた形式になっている | | ---ちょうど上記でモードビットを外して最初に000をつけた形式になっている |
| | | | |
| - | *** 本体 | + | *** 本体 [#d42de4c9] |
| | -基本的な考えとしては、パラメータ値そのものではなく、前の項から次の項を求めるための差分をエンコードしていく感じになる | | -基本的な考えとしては、パラメータ値そのものではなく、前の項から次の項を求めるための差分をエンコードしていく感じになる |
| | --大雑把な傾向として、パラメータ列の値はその前後の値に近くなるため | | --大雑把な傾向として、パラメータ列の値はその前後の値に近くなるため |
| | ---前の項が0だった場合、符号ビットが1だった時点でもう打ち切る | | ---前の項が0だった場合、符号ビットが1だった時点でもう打ち切る |
| | | | |
| - | *** フッタ | + | *** フッタ [#rb3607ca] |
| | -特定の条件でのみフッタが存在する | | -特定の条件でのみフッタが存在する |
| | --モード0かモード1で、パラメータの数が2つ以上で、さらに最後のパラメータが0ではないとき | | --モード0かモード1で、パラメータの数が2つ以上で、さらに最後のパラメータが0ではないとき |
| | --差し引く前の最後のパラメータが10だとしたら、当然"0"の数は10より多いことはありえないので、"0"が10個続いたら"1"は省略されているとみなして1ビット節約する | | --差し引く前の最後のパラメータが10だとしたら、当然"0"の数は10より多いことはありえないので、"0"が10個続いたら"1"は省略されているとみなして1ビット節約する |
| | | | |
| - | *** デフォルトパラメータ | + | *** デフォルトパラメータ [#v1d01645] |
| | -これだけの圧縮をしてパラメータを短くまとめても、それでも対tek0では小さいファイルで負ける | | -これだけの圧縮をしてパラメータを短くまとめても、それでも対tek0では小さいファイルで負ける |
| | --なぜならtek0はパラメータが固定されており、圧縮ファイル内に書かなくていい分だけ有利だからである | | --なぜならtek0はパラメータが固定されており、圧縮ファイル内に書かなくていい分だけ有利だからである |
| | ---つまり1～4 | | ---つまり1～4 |
| | | | |
| - | * 最低保証値 | + | * 最低保証値 [#s3301330] |
| | -tek1は非常にスケーラブルな形式であり、展開ルーチン側の負担は小さくないと思うので、ここで一つ基準を設ける。 | | -tek1は非常にスケーラブルな形式であり、展開ルーチン側の負担は小さくないと思うので、ここで一つ基準を設ける。 |
| | --これは汎用の場合の最低値規定であって、対象データが限定される場合はこの限りではない。 | | --これは汎用の場合の最低値規定であって、対象データが限定される場合はこの限りではない。 |
| | -tek1hについては、レベル0のみ（＝tek1hのノンサポート）であってもよいが、できればレベル2くらいまでのサポートがあるほうが好ましい。 | | -tek1hについては、レベル0のみ（＝tek1hのノンサポート）であってもよいが、できればレベル2くらいまでのサポートがあるほうが好ましい。 |
| | | | |
| - | * tek1h | + | * tek1h [#nbec98dc] |
| | | | |
| | | | |
| | | | |
| - | * こめんと欄 | + | * こめんと欄 [#lc851bdc] |
| | #comment | | #comment |
