JP2017507590A5 - - Google Patents
Download PDFInfo
- Publication number
- JP2017507590A5 JP2017507590A5 JP2016549759A JP2016549759A JP2017507590A5 JP 2017507590 A5 JP2017507590 A5 JP 2017507590A5 JP 2016549759 A JP2016549759 A JP 2016549759A JP 2016549759 A JP2016549759 A JP 2016549759A JP 2017507590 A5 JP2017507590 A5 JP 2017507590A5
- Authority
- JP
- Japan
- Prior art keywords
- data
- decoder
- tables
- code
- index
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000000875 corresponding Effects 0.000 description 56
- 230000005540 biological transmission Effects 0.000 description 31
- 238000007906 compression Methods 0.000 description 24
- 238000000034 method Methods 0.000 description 12
- 238000004891 communication Methods 0.000 description 11
- 238000006243 chemical reaction Methods 0.000 description 10
- 230000001131 transforming Effects 0.000 description 8
- 238000004590 computer program Methods 0.000 description 6
- 238000004422 calculation algorithm Methods 0.000 description 5
- 230000005236 sound signal Effects 0.000 description 5
- 230000001172 regenerating Effects 0.000 description 4
- 238000000844 transformation Methods 0.000 description 3
- 230000003044 adaptive Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000000605 extraction Methods 0.000 description 2
- 238000009877 rendering Methods 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000002596 correlated Effects 0.000 description 1
- 238000002716 delivery method Methods 0.000 description 1
- 238000005265 energy consumption Methods 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 239000003365 glass fiber Substances 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000006011 modification reaction Methods 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000000153 supplemental Effects 0.000 description 1
- 230000000576 supplementary Effects 0.000 description 1
- 230000001702 transmitter Effects 0.000 description 1
Description
本開示は、入力データの符号化方法に関し、それに対応する符号化データを生成するものである。また本開示は、前述の符号化データの復号方法に関し、それに対応する復号出力データを生成するものでもある。さらにまた、本開示は、前述の方法を実装するように動作可能なエンコーダとデコーダにも関連する。さらに加えて、本開示は、非一時的コンピュータ可読記憶媒体を含むコンピュータプログラム製品であって、非一時的コンピュータ可読記憶媒体はコンピュータ可読命令を含み、コンピュータ可読命令は、前述の方法を実行する処理ハードウェアを備える計算デバイスによって実行可能である、コンピュータプログラム製品にも関連する。
概要としては、図1に示すように、入力データD1を符号化してそれに対応する符号化出力データE2を生成する既知の符号化方法は、入力データD1に対する1つ又は複数の変換Tの適用を伴い、それに対応する変換済み符号化出力データE2を生成する。ここで、変換済み符号化出力データE2は、それに関連付けられる符号テーブルデータCの情報を有し、その情報は、採用される1つ又は複数の変換Tを規定する1つ又は複数の符号テーブルを指し示す。符号化変換データE2と符号テーブルデータC情報をまとめて符号化出力データE2と呼ぶ。符号化出力データE2は通常、データキャリア、データ通信ネットワークの何れか又は両方を介して1つ又は複数のデコーダに伝送される。デコーダは、1つ又は複数の逆変換T−1を適用し、符号化出力データE2を復号してそれに対応する復号データD3を生成するように動作可能である。通常、符号化出力データE2は、例えば符号化出力データE2を伝送するときに通信ネットワークの容量負荷を減らすために、入力データD1よりも圧縮されていることが望ましい。また、符号化出力データE2が実質的に可逆方式で圧縮され、復号データD3が入力データD1に含まれる情報を正確に再現したものであることも望まれる。入力データD1に対して符号化出力データE2で実現可能なデータ圧縮は、符号テーブルデータC情報が符号化変換データE2と比べてかなりの大きさである場合、即ち、符号テーブルデータC情報が符号化変換データE2において大幅なデータオーバヘッドに相当する場合は非効率になる可能性がある。
入力データD1を符号化して符号化出力データE2を生成する既知の方法が幾つか存在する。例えば、既知のハフマン符号化(Huffman encoding)又は他の可変長符号化(VLC encoding)方法は、様々な種類のデータの圧縮で度々採用される。また、算術符号化(Arithmetic coding)やレンジ符号化(Range coding)も入力データ圧縮によく採用されてきているが、次のような状況ではかなり非効率である:
(i)入力データD1に関する頻度テーブルが、入力データD1を符号化してそれに対応する符号化出力データE2を生成するように動作可能なエンコーダには未知であり、その符号化出力データE2を復号するように動作可能なデコーダに対しても未知である場合;
(ii)入力データ量が比較的小さい場合。例えば、入力データD1が小さいデータセグメント又はデータチャンクで伝送され、データセグメント又はデータチャンクの各々がそれぞれに対応する頻度テーブルを伴っている場合。
(i)入力データD1に関する頻度テーブルが、入力データD1を符号化してそれに対応する符号化出力データE2を生成するように動作可能なエンコーダには未知であり、その符号化出力データE2を復号するように動作可能なデコーダに対しても未知である場合;
(ii)入力データ量が比較的小さい場合。例えば、入力データD1が小さいデータセグメント又はデータチャンクで伝送され、データセグメント又はデータチャンクの各々がそれぞれに対応する頻度テーブルを伴っている場合。
前述のように、こうした非効率性は、多量のデータ空間を使う1つ又は複数の頻度テーブルを送出することに起因する。例えば、頻度テーブルがデコーダにローカルな形で格納されていて、可能な頻度テーブルのリストから比較的少数の識別パラメータを用いて選択することが不可能な場合に起こりうる。また、そうしたリストから適切な頻度テーブルを探すことは、適切な符号テーブルを探すことよりも確実ではないこともある。符号化対象入力データD1が局所的に変化することも度々あり、例えば、通信ネットワークに対して空間ローカルのデータ規格に適合させるために、入力データがその通信ネットワークで伝送中に変換されることもある。
シンボルから派生した符号化データコンテンツの伝送に関連して、符号テーブル又は頻度テーブルの送出に利用可能な既知の方法も存在する。こうした既知の方法の多くは、シンボルに関するハフマンツリー又は頻度の直接送出を利用する。しかし、こうした既知の方法は十分満足のいくものではない。こうした方法では、エンコーダからそれに対応するデコーダに送出すべき情報が相当量必要となるためである。また、符号テーブルのシンボル長を送出する方法も知られており、例えば既知のインテルIPPライブラリは、本願出願時においては非推奨であるが、いわゆる「HuffLenCodeTablePacK」によって符号テーブルを圧縮し、「HuffLenCodeTableUnpack」によって復号して元に戻す方法が採用されている。しかし、この方法でも十分ではなく、符号化処理中でもデータサイズが増大することがある。この方法は更に、256種のシンボルが在り、0から255の全シンボルがゼロでないコードワード長を持つ必要がある。ハフマン符号化技術等で生成されるプレフィックスコードに対して現在利用可能な送出機構の中では、符号テーブルを送出する方法が最も効率がよいことは明白である。エンコーダからそれに対応するデコーダにハフマンツリーが送出される場合、エンコーダから生成されたコードシンボルは、エンコーダとデコーダにおいて常に同じである。頻度テーブルのみが送出される場合、ハフマンツリーが必要であると仮定すると、頻度テーブルから実際のハフマンツリーを生成するアルゴリズムは、デコーダが適切にシンボルを復号できるように、エンコーダとデコーダで同一のアルゴリズムが使用されなくてはならない。符号テーブルのシンボル長が送出される場合、シンボル長から頻度テーブルに変換する方法もまた、デコーダが適切にシンボルを復号できるように、エンコーダとデコーダで同一の方法が必要である。一方、算術符号化とレンジ符号化では、エンコーダからデコーダにシンボル長を伝送することは出現頻度の送出方法として実用的ではない。これらの符号化方法は、単にコードシンボル長の伝送によって有効に機能するよりも、より正確な頻度テーブルをサポートするために設計されているためである。コードシンボル長自体は算術符号化でもレンジ符号化でも使用することはできるが、後続データに対して後からテーブル適応更新が実行されなければ、これらの符号化方法にはハフマン符号化等と比べてあまり有益ではない。しかし、ハフマン符号化とは対照的にレンジ符号化又は算術符号化では、出現確率を示す情報の送出でより最適化された符号化結果が得られる。シンボルの出現確率は、シンボルの出現頻度をシンボル出現頻度の和、即ちシンボル数で割って算出することができる。こうした確率の送出は、スケール確率値を用いることで有益に行われる。スケール確率値は、元のシンボル出現確率値に特定の整数を掛け、近似整数値に丸めて算出することができる。この特定の整数として2の累乗、即ち2n とするのが有益である。ここで、nは整数である。こうしたスケール確率の和は整数であり、乗数の値と同じになるように均される。別の方法で非ゼロスケール確率値を割り当てることができないシンボルに対して、エスケープコードシンボルの生成が有用である。このことは、エスケープシンボルを必要するこれらのシンボルが、選択された乗数値で存在しうるものよりも確率が低いことを意味する。また、二つの別々の機構を用いてエスケープコードを使わずにスケール確率を計算することもできる。乗数値を大きくして新しい確率値を算出することもできる。利用可能なシンボルの確率値を0から1に更新することもできる。この確率値更新では、この確率値の上昇が他のシンボルの確率値を下げることによって補償されなくてはならない。これは、確率の和を乗数値と完全に一致させるように行われる。この処理では確率値は最大限に最適化されないが、エスケープシンボルは不要であり、場合によっては最適な符号化方法となりうる。シンボル長又は確率値は、可変長符号化を採用する方法において使用可能な頻度テーブルの概算を規定する。ここで、可変長符号化には、例えばハフマン符号化やレンジ符号化、算術符号化、その他の可変長符号化が含まれる。当然ながら、スケール確率テーブルは、必要であればシンボル出現頻度の概算として直接使用されてもよく、使用前にはシンボル長が最初にシンボル出現頻度の概算として変換されなくてはならない。データ符号化とテーブル送出におけるシンボル長から頻度テーブルへの変換はこの後で詳述する。
多数の公知かつ実用的なデータ符号化方法には、最適化された符号テーブルが全く利用されていない。つまり、こうした方法は、データを符号化して符号化データを生成するのに固定の符号テーブルを利用し、その後の符号化データの復号でも固定符号テーブルを使用している。ただし、送出されたシンボルに基づく適応方法で符号テーブルが更新されることもある。ある既知の方法では、エンコーダでデータを符号化し、それに対応してデコーダで符号化データを復号するために、別々の符号テーブルあるいは頻度テーブルの組が利用されることもある。この場合、選択された符号テーブルや確率テーブル、頻度テーブルを規定するインデクスがエンコーダからデコーダへの情報として送出される。画像の輝度/色差チャネル、インター/イントラブロック、異種データに対して別々のテーブルを用いる方法も存在するが、こうした別々のテーブルは非効率な仕方で伝送される。例えば、次のインターネットウェブサイト(ウィキペディア)を参照されたい:http://en.wikipedia.org/wiki/Huffman_coding。ハフマンベースの方法を用いる場合、伸張時にはハフマンツリーを再構成しなくてはならない。文字の出現頻度が比較的予測可能であるような最も単純な場合では、ツリーは再構成し易く、各圧縮サイクルで統計的に調節することも可能である。したがって、圧縮率の少なくとも一部だけ犠牲にすることで、毎回ツリーを再利用することができる。あるいは、ハフマンツリーの情報がアプリオリに、即ち予め送られていなくてはならない。
圧縮データ出力列に符号化されるシンボルに関連する出現頻度数を先頭に追加する単純なアプローチには、圧縮データの量を実際に少なくとも数キロバイト(kB)まで増加させる欠点があり、そうした単純なアプローチが実際に用いられることは殆ど無い。データがカノニカル符号化(canonical encoding)で圧縮される場合、圧縮モデルは丁度B2Bビットの情報で正確に再構成することができる。ここで、Bは1シンボル当りのビット数で、例えば8ビットであれば2kBを必要とする。
もう一つの方法は、単純に圧縮出力列に対してビット毎にハフマンツリーを先頭に追加するというものである。例えば、値0が親ノード、値1が葉ノードを表わすと仮定すると、葉ノードが現れたら必ず、ツリー構築ルーチンは、この特定の葉ノードの文字値を決定するため単純に次の8ビットを読み取る。こうした処理は最後の葉ノードに到達するまで再帰的に継続し、最終葉ノードに到達すると、デコーダ等でハフマンツリーが忠実に再構成される。こうした方法を用いることで生じるデータオーバヘッドは、8ビットのアルファベットを仮定した場合、概ね2から320バイトの範囲になる。
次に、既知のデータ符号化方法及びそれに対応する符号化データの復号方法を更に明らかにするために、ハフマン復号の概要を説明する。当然ながら、ハフマン復号以外にも、例えばレンジ復号や算術復号等、他の方法が利用されてもよい。データファイルの圧縮を開始する前に、エンコーダの圧縮器は、圧縮を実行するときに用いるコードを決定しなくてはならない。
ハフマン復号を採用する場合、エンコーダは、符号化出力データを生成するために、シンボルを含む所定の対応するデータファイルを圧縮し始める前に、この所定データを表現するために使用すべきコードを決定しなくてはならない。このコードは、所定のデータファイルにあるシンボルの確率、即ち出現頻度に基づいていると都合がよい。しかし、シンボルの出現頻度、確率、シンボル長は、例えばサイド情報、即ち補足情報として符号化出力データに記録されなくてはならない。こうして、任意のハフマンデコーダが符号化出力データを復号してそれに対応する復号データを生成することができるようになる。シンボルの出現頻度又はシンボル長は、整数であると都合がよい。また確率であれば、スケールした整数として表現可能である。補足情報に含まれるこうした整数は通常、符号化出力データに対して僅か数百バイト程度を追加するだけである。また、符号化出力データに可変長コード自体を書き込むことも可能であるが、コードが互いに異なるサイズを持つことになるため、状況によっては厄介になる可能性もある。あるいは、符号化出力データにハフマンツリーを書き込むことも可能である。しかしこの場合、所定のデータにおけるシンボルの出現頻度を単に伝送するときよりも多くのデータを伝送しなくてはならない。
デコーダは動作時に、デコーダが受け取った復号対象の符号化圧縮ファイルの先頭が何であるかという情報の提供を受けなくてはならない。デコーダは、符号化圧縮ファイルの先頭等、ファイルから抽出されたデータからハフマンツリーの文字を構築するように動作可能である。デコーダでハフマンツリーが構成された後、デコーダは、そのハフマンツリーを復号ツリーとして使用してファイルの残り部分を復号することができる。デコーダは、次のステップを含む比較的単純な復号アルゴリズムを採用する:
(a)ハフマンツリーの根から開始し、ハフマンツリーを用いて復号されるべき符号化出力データの最初のビットを読み取る;
(b)最初のビットが「1」であればハフマンツリーの上位エッジを辿り、最初のビットが「0」であればハフマンツリーの下位エッジを辿る;
(c)符号化出力データの2番目のビットを読み取り、ハフマンツリーの「葉」に向かってステップ(b)と同様の仕方で2番目のビットを使用する。ハフマンツリーの「葉」に到達すると、元の非圧縮シンボルが見つけられることになり、これは通常、関連するASCIIコードであり、このコードがデコーダから出力される;
(d)符号化出力データの復号が完了するまで、ステップ(b)と(c)が繰り返される。
(a)ハフマンツリーの根から開始し、ハフマンツリーを用いて復号されるべき符号化出力データの最初のビットを読み取る;
(b)最初のビットが「1」であればハフマンツリーの上位エッジを辿り、最初のビットが「0」であればハフマンツリーの下位エッジを辿る;
(c)符号化出力データの2番目のビットを読み取り、ハフマンツリーの「葉」に向かってステップ(b)と同様の仕方で2番目のビットを使用する。ハフマンツリーの「葉」に到達すると、元の非圧縮シンボルが見つけられることになり、これは通常、関連するASCIIコードであり、このコードがデコーダから出力される;
(d)符号化出力データの復号が完了するまで、ステップ(b)と(c)が繰り返される。
符号化列のデータサイズがデータ列の生成に用いられる符号テーブルのそれと比べて大きい場合には、現在既知のハフマン符号化を採用するのが有益である。また、符号テーブルがエンコーダとそれに対応するデコーダの両方で事前に規定される場合でも、現在のこうしたハフマン符号化を採用するのが有益である。したがって、前述したハフマン符号化及び復号方法等、データを符号化及び復号する既知のアプローチに関してこれまでに記述した制限に対処するために、代替となる符号化方法が必要とされている。
本発明は、データ(D1)を符号化してそれに対応する符号化データ(E2)を生成する改良方法を提供しようとするものである。
また本発明は、データを符号化する前述の改良方法を用いるように動作可能である改良型エンコーダを提供しようとするものである。
本発明は、符号化データ(E2)を復号してそれに対応する復号データ(D3)を生成する改良方法を提供しようとするものでもある。
本発明は、前述の符号化データ(E2)を復号してそれに対応する復号データ(D3)を生成する改良型デコーダを提供しようとするものでもある。
第1の態様によれば、入力データ(D1)をエンコーダで符号化してそれに対応する符号化データ(E2)を生成する方法が提供される。本方法は:
(a)前記入力データ(D1)に存在するシンボルを解析し、該入力データ(D1)を1つ又は複数のデータチャンクに分割及び/又は変換することと;
(b)前記1つ又は複数のデータチャンクに存在する前記シンボルに対して、1つ又は複数の符号テーブル、1つ又は複数の頻度テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルのうち少なくとも1つを、前記シンボルの出現の関数として生成することと;
(c)各データチャンクにおけるシンボルを、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブルのうち少なくとも1つにおけるエントリに関連付ける1つ又は複数のインデクスセットを計算することと;
(d)各データチャンクにおけるシンボルを関連付ける前記1つ又は複数のインデクスセットの情報を、前記1つ又は複数の頻度テーブル、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブルのうち少なくとも1つと共に、前記符号化データ(E2)に含めることと;
(e)前記1つ又は複数の頻度テーブル、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の符号確率テーブルのうちの少なくとも1つを用いて前記シンボルを圧縮し、前記符号化データ(E2)に含めることと;
を含む。
(a)前記入力データ(D1)に存在するシンボルを解析し、該入力データ(D1)を1つ又は複数のデータチャンクに分割及び/又は変換することと;
(b)前記1つ又は複数のデータチャンクに存在する前記シンボルに対して、1つ又は複数の符号テーブル、1つ又は複数の頻度テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルのうち少なくとも1つを、前記シンボルの出現の関数として生成することと;
(c)各データチャンクにおけるシンボルを、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブルのうち少なくとも1つにおけるエントリに関連付ける1つ又は複数のインデクスセットを計算することと;
(d)各データチャンクにおけるシンボルを関連付ける前記1つ又は複数のインデクスセットの情報を、前記1つ又は複数の頻度テーブル、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブルのうち少なくとも1つと共に、前記符号化データ(E2)に含めることと;
(e)前記1つ又は複数の頻度テーブル、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の符号確率テーブルのうちの少なくとも1つを用いて前記シンボルを圧縮し、前記符号化データ(E2)に含めることと;
を含む。
本発明は入力データ(D1)を1つ又は複数のデータチャンクに小分けにする、即ち分割することと、入力データ(D1)にあるシンボルを圧縮することの何れか又は両方を伴う。それによって本発明は、入力データ(D1)が、例えばインデクスとそれが参照する1つ又は複数の関連するテーブルを用いて、各データチャンク又は圧縮シンボルに最適な仕方で効率よく符号化されようになるという優位性を持つ。
本方法は、1つ又は複数のテーブルの少なくとも1つが後で再利用できるように保存可能な仕方で、1つ又は複数のテーブルの少なくとも1つを送出することを含んでもよい。
前述のこうした小分け、即ち分割には、入力データ(D1)のサブ分割が含まれてもよい。
前述(a)では通常、分割が行われるが、データを新たなデータチャンクに分割せず、利用可能なデータチャンクを最適な符号テーブルで圧縮のみを行うこともできる。また、元のデータを分割する代わりに、例えば、最大効率で圧縮可能な1つ又は複数のデータチャンクが得られる1つ又は複数の変換によって、新たなデータが生成されてもよい。本開示に従って実装されたエンコーダは、様々なデータチャンクの生成に使用することができる。したがって当然のことながら、本方法は、別々の時間スロットで行われるチャンキングでデータを符号化するように動作可能なビデオコーデックやオーディオコーデックに適している。フレーム又はセクション毎にデータチャンクは異なり、本開示に従う1つ又は複数の方法を実装するエンコーダを用いて、こうしたデータを更に1つ又は複数のデータチャンクに分割することもできる。こうしたデータチャンクは全て、同一フレームやその前のフレーム等で既に送出されている任意のテーブルを再利用することができる。
本発明の実施形態により、符号テーブル又は頻度テーブルの効率的な送出が可能になる。これにより、テーブルの送出、保存の何れか又は両方に必要なデータ通信・データ保存のオーバヘッドを減らすことができる。また、個々のデータチャンクに最適化された符号テーブルを利用することで、より小さいデータチャンクの符号化も可能となる。こうして、更に高い圧縮効率の実現が可能となり、データ保存容量、伝送帯域幅、エネルギー消費を削減することができる。
データの様々な部分の出現頻度は、通常互いに異なるものであり、それに関連するデータエントロピーもそれぞれ異なる。このため、データを複数の部分、即ちデータチャンクに分割することが有益となる。こうした部分に対して、その部分に関するデータの本質、データの種類、データの内容の何れか又は全てに応じて、別々の符号テーブルを使用するのが有益である。ここでデータの「本質」とは、そのデータの1つ又は複数の特性、パラメータの何れか又は両方を意味する。本発明は、所定の大きなデータファイルをより効率的に小さな部分、即ちデータチャンクに分割可能な方法であって、そうしたデータチャンクに対する符号テーブル又は頻度テーブルの送出も最適化されるという関連した利益ももたらされる方法を提供する。大規模データファイルの分割により、データエントロピーの修正も伴うことから、実質的な利益がもたらされ、伝送対象である符号化データの量を大幅に削減することができる。1つ又は複数のデータチャンクにおけるデータ値も、前述のようにして分割することができる。こうしたデータ値の小分け、即ち分割の実装は、例えばMSB(最上位ビット)とLSB(最下位ビット)を互いに分離することによって可能となる。データ値がデータ値チャンクに分割される数が2を超えることもある。
前述した本発明の方法は、復号データ(D3)を生成するステップ(d)において、1つ又は複数のデータ圧縮アルゴリズムを適用することを含んでもよい。本方法では更に、1つ又は複数のデータ圧縮アルゴリズムは、ハフマン符号化、VLC、エントロピー符号化、算術符号化、レンジ符号化の少なくとも1つを含む。ただし、これらに限定されない。
本方法は、入力データ(D1)を複数のデータチャンクに分割することと、その複数のデータチャンクを実質的に同時に処理する並列プロセッサアーキテクチャを用いることを含んでもよい。
本方法は、一緒に結合された複数のデータ値に基づいて、1つ又は複数のインデクスセットを生成することを含んでもよい。本方法では更に、このインデクスは、R、G、Bの画素値又はY、U、Vの画素値を含む1つ又は複数のRGB画素又はYUV画素から算出されてもよい。
本方法は更に、データチャンクが符号化データ(E2)に含まれる場合、そのデータチャンクに対して達成可能なデータ圧縮率に応じて、データチャンクを符号化データ(E2)に集める際にデータチャンクの非符号化又は符号化を動的に切り換えることを含んでもよい。
本方法は、シンボルが「符号テーブル変更」又は「データ終了」に関連するかを示す少なくとも1ビットの終了ビットを符号化データ(E2)に含めることを含んでもよい。
本方法は、所定のデータチャンクに存在する1つ又は複数のシンボルを参照するために必要十分なインデクスから、実質的にその所定のデータチャンクを生成することを含んでもよい。
送出された符号テーブルは、例えばハフマン符号化を用いて圧縮されてもよく、こうした符号テーブル圧縮方法が、それ特有の関連する1つ又は複数の符号テーブルと共に提供されてもよい。
第2の態様によれば、入力データ(D1)を符号化してそれに対応する符号化データ(E2)を生成するエンコーダが提供される。本エンコーダは:
(a)前記入力データ(D1)を1つ又は複数のデータチャンクに分割及び/又は変換するために、該入力データ(D1)に存在するシンボルを解析する解析器と;
(b)前記1つ又は複数のデータチャンクに存在する前記シンボルに対して、1つ又は複数の符号テーブル、1つ又は複数の頻度テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルのうち少なくとも1つを、前記シンボルの出現の関数として生成する生成器と;
(c)各データチャンクにおけるシンボルを、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブルのうち少なくとも1つにおけるエントリに関連付ける1つ又は複数のインデクスセットを計算する計算エンジンと;
(d)各データチャンクにおけるシンボルを関連付ける前記1つ又は複数のインデクスセットの情報を、前記1つ又は複数の頻度テーブル、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブルのうち少なくとも1つと共に、前記符号化データ(E2)に含めるデータアセンブラと;
(e)前記1つ又は複数の頻度テーブル、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の符号確率テーブルのうちの少なくとも1つを用いて前記シンボルを圧縮し、前記符号化データ(E2)に含める圧縮器と;
を備える。
(a)前記入力データ(D1)を1つ又は複数のデータチャンクに分割及び/又は変換するために、該入力データ(D1)に存在するシンボルを解析する解析器と;
(b)前記1つ又は複数のデータチャンクに存在する前記シンボルに対して、1つ又は複数の符号テーブル、1つ又は複数の頻度テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルのうち少なくとも1つを、前記シンボルの出現の関数として生成する生成器と;
(c)各データチャンクにおけるシンボルを、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブルのうち少なくとも1つにおけるエントリに関連付ける1つ又は複数のインデクスセットを計算する計算エンジンと;
(d)各データチャンクにおけるシンボルを関連付ける前記1つ又は複数のインデクスセットの情報を、前記1つ又は複数の頻度テーブル、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブルのうち少なくとも1つと共に、前記符号化データ(E2)に含めるデータアセンブラと;
(e)前記1つ又は複数の頻度テーブル、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の符号確率テーブルのうちの少なくとも1つを用いて前記シンボルを圧縮し、前記符号化データ(E2)に含める圧縮器と;
を備える。
こうした小分け、即ち分割には、入力データ(D1)のサブ分割が含まれてもよい。
前述(a)では通常、分割が行われるが、データを新たなデータチャンクに分割せず、利用可能なデータチャンクを最適な符号テーブルで圧縮のみを行うこともできる。また、元のデータを分割する代わりに、例えば、最大効率で圧縮可能な1つ又は複数のデータチャンクが得られる1つ又は複数の変換によって、新たなデータが生成されてもよい。本開示に従って実装されたエンコーダは、様々なデータチャンクの生成に使用することができる。したがって当然のことながら、本方法は、別々の時間スロットで行われるチャンキングでデータを符号化するビデオコーデックやオーディオコーデックに適している。フレーム又はセクション毎にデータチャンクは異なり、本開示に従う方法を実装するエンコーダを用いて、こうしたデータを更に1つ又は複数のデータチャンクに分割することもできる。こうしたデータチャンクは全て、同一フレームやその前のフレーム等で既に送出されている任意のテーブルを再利用することができる。
本エンコーダは、符号化データ(E2)を生成するために、データアセンブラにおいて1つ又は複数のデータ圧縮アルゴリズムを適用するように動作可能でもよい。本エンコーダでは更に、1つ又は複数のデータ圧縮アルゴリズムは、ハフマン符号化、VLC、エントロピー符号化、算術符号化、レンジ符号化の少なくとも1つを含んでもよい。
本エンコーダは、入力データ(D1)を複数のデータチャンクに分割し、その複数のデータチャンクを実質的に同時に処理する並列プロセッサアーキテクチャを用いるように動作可能でもよい。
本エンコーダにおいて生成器は、一緒に結合された複数のデータ値に基づいて、1つ又は複数のインデクスセットを生成するように動作可能でもよい。本エンコーダでは更に、このインデクスは、R、G、Bの画素値又はY、U、Vの画素値を含む1つ又は複数のRGB画素又はYUV画素から算出されてもよい。本エンコーダは更に、データチャンクが符号化データ(E2)に含まれる場合、そのデータチャンクに対して達成可能なデータ圧縮率に応じて、データチャンクを符号化データ(E2)に集める際にデータチャンクの非符号化又は符号化を動的に切り換えるように動作可能でもよい。
本エンコーダは、シンボルが「符号テーブル変更」又は「データ終了」に関連するかを示す少なくとも1ビットの終了ビットを符号化データ(E2)に含めることを含むように動作可能でもよい。
本エンコーダにおいて生成器は、所定のデータチャンクに存在する1つ又は複数のシンボルを参照するために必要十分なインデクスから、実質的にその所定のデータチャンクを生成するように動作可能でもよい。
送出された符号テーブルは、例えばハフマン符号化を用いて圧縮されてもよく、こうした圧縮方法が、それ特有の1つ又は複数の関連する符号テーブルを必要とする場合もある。
送出された符号テーブルは、同一フレームやその前のフレーム等で再利用されてもよい。すなわち、データチャンクの符号化は、このデータフレーム又はその前のデータフレームにおける他のデータチャンクに対して、それ以前に送出された任意の符号テーブルを再利用することができる。
本エンコーダを実装する場合、テーブル送出のための最適な実装が、例えば符号化データにおいて有益に採用されてもよい。あるいは、例えば1つ又は複数のデータベース、1つ又は複数のプロキシデータベースのような、テーブルがアクセス可能な場所を示す1つ又は複数の識別コードを符号化データに含めることによって行われてもよい。
より効率的なデータの符号化、符号化データの送出、符号化データの復号を提供するために、前述のような送出・参照テーブルが、例えばそのテーブルのインデクスが送出されている場合、後で使用する等の用途で保存されてもよい。こうしたアプローチは、本開示に従って、例えばエンコーダからそれに対応するデコーダに伝送すべきデータの量を削減することができる。
第3の態様によれば、非一時的コンピュータ可読記憶媒体を含むコンピュータプログラム製品であって、非一時的コンピュータ可読記憶媒体はコンピュータ可読命令を含み、コンピュータ可読命令は、第1の態様に従う方法を実行する処理ハードウェアを備える計算デバイスによって実行可能である、コンピュータプログラム製品が提供される。
第4の態様によれば、第2の態様に従うエンコーダによって生成された符号化データ(E2)を復号する方法が提供される。このエンコーダによって生成された符号化データ(E2)を復号し、それに対応する復号データ(D3)を生成する、デコーダで行われる前記方法は:
(i)前記符号化データ(E2)を受け取り、1つ又は複数の頻度テーブル、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルのうちの少なくとも1つと、前記1つ又は複数の頻度テーブル、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の符号確率テーブルのうちの前記少なくとも1つを示す情報と共に、1つ又は複数のインデクスセットの情報を前記符号化データから抽出することと;
(ii)前記1つ又は複数のインデクスセットから、1つ又は複数のデータチャンクの圧縮シンボルに関連する、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブル、の少なくとも1つを計算することと;
(iii)前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブルのうち少なくとも1つからの情報を用いて、前記圧縮シンボルから、前記1つ又は複数のデータチャンクを再生成することと;
(iv)前記復号データ(D3)を生成するために、前記1つ又は複数のデータチャンクを結合及び/又は変換すること
を含む。
(i)前記符号化データ(E2)を受け取り、1つ又は複数の頻度テーブル、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルのうちの少なくとも1つと、前記1つ又は複数の頻度テーブル、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の符号確率テーブルのうちの前記少なくとも1つを示す情報と共に、1つ又は複数のインデクスセットの情報を前記符号化データから抽出することと;
(ii)前記1つ又は複数のインデクスセットから、1つ又は複数のデータチャンクの圧縮シンボルに関連する、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブル、の少なくとも1つを計算することと;
(iii)前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブルのうち少なくとも1つからの情報を用いて、前記圧縮シンボルから、前記1つ又は複数のデータチャンクを再生成することと;
(iv)前記復号データ(D3)を生成するために、前記1つ又は複数のデータチャンクを結合及び/又は変換すること
を含む。
本方法は、対応するトランスコードデータ(D4)を生成するために復号データ(D3)をトランスコードすること、及び/又は、符号化データ(E2)からそれに対応するトランスコードデータ(D4)を生成することを含んでもよい。
本方法は、1つ又は複数のテーブルの少なくとも1つが後で再利用できるように保存可能な仕方で、1つ又は複数のテーブルの少なくとも1つを受け取ることを含んでもよい。
本方法は、復号データ(D3)を生成するステップ(iv)において、1つ又は複数のデータ伸張アルゴリズムを適用することを含んでもよい。本方法では更に、1つ又は複数のデータ伸張アルゴリズムは、ハフマン復号、VLC復号、エントロピー復号、算術復号、レンジ復号の少なくとも1つを含んでもよい。
本方法は、復号データ(D3)を生成するために、1つ又は複数のデータチャンクのうち複数を実質的に同時に処理する並列プロセッサアーキテクチャを用いることによって、その複数のデータチャンクを結合することを含んでもよい。
本方法は、一緒に結合された複数のデータ値に基づいて、1つ又は複数のインデクスセットを生成することを含んでもよい。本方法では更に、このインデクスは、R、G、Bの画素値又はY、U、Vの画素値を含む1つ又は複数のRGB画素から算出されてもよい。本方法は更に、データチャンクが符号化データ(E2)に含まれる場合、そのデータチャンクに対して達成可能なデータ伸長率に応じて、符号化データ(E2)における1つ又は複数のデータチャンクの非符号化生成又は符号化生成を動的に切り換えることを含んでもよい。
本方法では、デコーダは、シンボルが符号化データ(E2)から、「符号テーブル変更」又は「データ終了」に関連するかを示す終了ビットを少なくとも1つ抽出するよう動作可能でもよい。
本方法は、所定のデータチャンクに存在する1つ又は複数のシンボルを参照するために必要十分なインデクスから、実質的にその所定のデータチャンクを生成することを含んでもよい。
本方法は、符号化データ(E2)に含まれる1つ又は複数の符号テーブルを伸張することを含んでもよい。本方法は更に、ハフマン復号を用いて1つ又は複数の符号テーブルを伸張することを含んでもよい。本方法では更に、1つ又は複数の符号テーブルの伸張は、1つ又は複数の補助符号テーブルを用いてもよい。
本方法は、次の送信データを復号するために、1つ又は複数の符号テーブルをデコーダで使用可能にする仕方で1つ又は複数の符号テーブルを受け取ることを含んでもよい。
本方法は、1つ又は複数の符号テーブルがアクセスされ易い場所を示す1つ又は複数の識別コードを、1つ又は複数のデータベースと1つ又は複数のプロキシデータベースの何れか又は両方を介して、符号化データ(E2)から抽出することを含んでもよい。
本方法は、次の種類のデータ:録音音声信号、録画ビデオ信号、静止画像、テキストデータ、感震データ、センサ信号データ、アナログ−デジタル変換(ADC)データ、生体信号データ、カレンダーデータ、経済データ、数学的データ、二進数データの1つ又は複数を復号することを含んでもよい。
本方法は、複数のデータソースから符号化データ(E2)を受け取り、符号化データ(E2)を再生成するために、ソースから提供されたデータを結合することを含んでもよい。
第5の態様によれば、非一時的コンピュータ可読記憶媒体を含むコンピュータプログラム製品であって、非一時的コンピュータ可読記憶媒体はコンピュータ可読命令を含み、コンピュータ可読命令は、第4の態様に従う方法を実行する処理ハードウェアを備える計算デバイスによって実行可能である、コンピュータプログラム製品が提供される。
第6の態様によれば、第2の態様に従うエンコーダによって生成された符号化データ(E2)を復号するデコーダが提供される。このエンコーダによって生成された符号化データ(E2)を復号し、それに対応する復号データ(D3)を生成する前記デコーダは:
(i)前記符号化データ(E2)を受け取り、1つ又は複数の頻度テーブル、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルのうちの少なくとも1つと、、前記1つ又は複数の頻度テーブル、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の符号確率テーブルのうちの前記少なくとも1つを示す情報と共に、1つ又は複数のインデクスセットの情報を前記符号化データから抽出することと;
(ii)前記1つ又は複数のインデクスセットから、1つ又は複数のデータチャンクの圧縮シンボルに関連する、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブル、の少なくとも1つを計算することと;
(iii)前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブルのうち少なくとも1つからの情報を用いて、前記圧縮シンボルから、前記1つ又は複数のデータチャンクを再生成することと;
(iv)前記復号データ(D3)を生成するために、前記1つ又は複数のデータチャンクを結合及び/又は変換すること
を実行するように動作可能である。
(i)前記符号化データ(E2)を受け取り、1つ又は複数の頻度テーブル、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルのうちの少なくとも1つと、、前記1つ又は複数の頻度テーブル、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の符号確率テーブルのうちの前記少なくとも1つを示す情報と共に、1つ又は複数のインデクスセットの情報を前記符号化データから抽出することと;
(ii)前記1つ又は複数のインデクスセットから、1つ又は複数のデータチャンクの圧縮シンボルに関連する、前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブル、の少なくとも1つを計算することと;
(iii)前記1つ又は複数の符号テーブル、前記1つ又は複数のコードワード長テーブル、前記1つ又は複数の確率テーブルのうち少なくとも1つからの情報を用いて、前記圧縮シンボルから、前記1つ又は複数のデータチャンクを再生成することと;
(iv)前記復号データ(D3)を生成するために、前記1つ又は複数のデータチャンクを結合及び/又は変換すること
を実行するように動作可能である。
本デコーダは更に、対応するトランスコードデータ(D4)を生成するために復号データ(D3)をトランスコードするトランスコーダ、及び/又は、符号化データ(E2)からそれに対応するトランスコードデータ(D4)を生成することを含んでもよい。
本デコーダは、1つ又は複数のテーブルの少なくとも1つが後で再利用できるように保存可能な仕方で、1つ又は複数のテーブルの少なくとも1つを受け取るように動作可能でもよい。
本デコーダは、復号データ(D3)を生成する(iv)において、1つ又は複数のデータ伸張アルゴリズムを適用するように動作可能でもよい。本デコーダでは更に、1つ又は複数のデータ伸張アルゴリズムは、ハフマン復号、VLC復号、エントロピー復号、算術復号、レンジ復号の少なくとも1つを含んでもよい。
本デコーダは、復号データ(D3)を生成するために、1つ又は複数のデータチャンクのうち複数を実質的に同時に処理する並列プロセッサアーキテクチャを用いることによって、その複数のデータチャンクを結合するように動作可能でもよい。
本デコーダは、一緒に結合された複数のデータ値に基づいて、1つ又は複数のインデクスセットを生成するように動作可能でもよい。本デコーダでは更に、このインデクスは、R、G、Bの画素値又はY、U、Vの画素値を含む1つ又は複数のRGB画素から算出されてもよい。本デコーダは更に、データチャンクが符号化データ(E2)に含まれる場合、そのデータチャンクに対して達成可能なデータ伸長率に応じて、符号化データ(E2)における1つ又は複数のデータチャンクの非符号化生成又は符号化生成を動的に切り換えるように動作可能でもよい。
本デコーダは、シンボルが符号化データ(E2)から、「符号テーブル変更」又は「データ終了」に関連するかを示す終了ビットを少なくとも1つ抽出するよう動作可能でもよい。
本デコーダは、所定のデータチャンクに存在する1つ又は複数のシンボルを参照するために必要十分なインデクスから、実質的にその所定のデータチャンクを生成するように動作可能でもよい。
本デコーダは、符号化データ(E2)に含まれる1つ又は複数の符号テーブルを伸張するように動作可能でもよい。本デコーダは更に、ハフマン復号を用いて1つ又は複数の符号テーブルを伸張するように動作可能でもよい。本デコーダでは更に、1つ又は複数の符号テーブルの伸張は、1つ又は複数の補助符号テーブルを用いてもよい。
本デコーダは、次の送信データを復号するために、1つ又は複数の符号テーブルをデコーダ(60)で使用可能にする仕方で1つ又は複数の符号テーブルを受け取るように動作可能でもよい。
本デコーダは、1つ又は複数の符号テーブルがアクセスされ易い場所を示す1つ又は複数の識別コードを、1つ又は複数のデータベースと1つ又は複数のプロキシデータベースの何れか又は両方を介して、符号化データ(E2)から抽出するように動作可能でもよい。
デコーダは、次の種類のデータ:録音音声信号、録画ビデオ信号、静止画像、テキストデータ、感震データ、センサ信号データ、アナログ−デジタル変換(ADC)データ、生体信号データ、カレンダーデータ、経済データ、数学的データ、二進数データの1つ又は複数を復号するように動作可能でもよい。
本デコーダは、複数のデータソースから符号化データ(E2)を受け取り、符号化データ(E2)を再生成するために、ソースから提供されたデータを結合するように動作可能でもよい。
第7の態様によれば、入力データ(D1)を符号化してそれに対応する符号化データ(E2)を生成する、第2の態様に従うエンコーダを少なくとも1つと、その符号化データ(E2)を復号してそれに対応する復号データ(D3)を生成する、少なくとも1つのデコーダを備える、コーデックが提供される。
本コーデックは、少なくとも1つのエンコーダ及び少なくとも1つのデコーダが互いに空間的に離隔され、データ通信ネットワークを介して互いに接続されるように実装されてもよい。本コーデックは更に、データ通信ネットワークがピアツーピアネットワーク方式で構成されるように実装されてもよい。本コーデックは、そのエンコーダ及びデコーダがそれらを通じたデータ処理に関して対称であるように実装されてもよい。換言すれば、エンコーダで実行される処理関数は、デコーダにおいてそれに対応する逆関数として、デコーダでは逆の順序で実行されるものが実装される。
本発明の構成は、添付の特許請求の範囲に定義される本発明の範囲を逸脱しない限りにおいて、様々に組合せ可能であることを理解されたい。
以下、本開示の実施形態を、一例として次の図面を参照しながら説明する。
データを符号化及び復号する既知のエンコーダ及び既知のデコーダを描いた図である。
本開示の実施形態に従うデータ符号化方法を示す図である。
本開示に従うエンコーダ及びデコーダ、合わせてコーデックと呼ぶものの実施形態を示す図である。
本開示に従うエンコーダ及びデコーダ、合わせてコーデックと呼ぶものの別の実施形態であって、デコーダの復号データD3がトランスコードされてトランスコードデータD4を生成する実施形態を示す図である。 添付図面において下線の引かれた番号は、その番号が位置するアイテムやその番号が隣接するアイテムを表わすために使用される。番号に下線が無く矢印を伴って書かれている場合、その番号は矢印が示す汎用アイテムを特定するのに使用される。
本開示は概括すると、例えばエンコーダ、デコーダ、コーデック、関連する動作方法に関する。また、本開示の実施形態は、既知の方法と比べ符号テーブルや頻度テーブル、コードワード長テーブル、出現確率テーブルの送出を改善する動作も可能にする。さらに、本開示の実施形態は、1つ又は複数のハフマンツリーの送出において送出に用いるビット数を少なくする仕方で送出することができる。それによって、特に、1つ又は複数のテーブルを付随する符号化データの量が比較的少ないときに、データ符号化中のデータ圧縮率を高めることができる。符号テーブルや頻度テーブル、コードワード長テーブル、確率テーブルは、多種多様なエントロピー符号化法に必要である。こうした符号化法には、例えばハフマン符号化、算術符号化、レンジ符号化のような可変長符号化(VLC)があるが、これらに限定されない。送信機等のエンコーダと受信機等のデコーダの両方において、以下で記述される方法を採用することが有益である。
以降で開示する実施形態は、保存及び伝送されるデータの量が時代の経過に伴って急速に増えている状況に関連する。こうしたデータの保存及び伝送は、相当量の記憶容量や伝送帯域幅、そしてエネルギーを消費する。こうした状況におけるデータの殆どは、録音音声信号、録画ビデオ信号、静止画像、テキストデータ、感震データ、センサ信号データ、アナログ−デジタル変換(ADC)データ、生体信号データ、カレンダーデータ、経済データ、数学的データ、二進数データ等であるが、これらに限定されない。本開示の実施形態は、前述の全ての種類のデータと、それ以外の種類のデータに対して符号化データ量を減らすように動作可能である。それによって、符号テーブルや頻度テーブル、コードワード長テーブル、確率テーブルの効率的送出を可能にし、データのエントロピー、即ちデータサイズを効率的に減らせる、より小さいデータチャンクの使用を可能にする。
また、データチャンクは小さい程、並列処理で効率的に処理され速く結果を出力することができる。こうした並列化は現在のマイクロプロセッサのアーキテクチャでは一般的であり、特に、データプロセッサアレイ、RISC(縮小命令セットコンピュータ)プロセッサの高速構成等、将来のマイクロプロセッサ構成においても共通である。
所定の符号化方法に対して、対応する符号テーブルが含む情報は、ビット等で表わされるコードワード長、コードワードを再現するコード、コードワードのインデクスを示す。符号テーブルは、コードワード長から生成することもできる。コードワードのインデクスは、コードワードで符号化される元のシンボルに対応する値を表わす。同様に、頻度テーブルには、シンボルの出現頻度とそのシンボルのインデクスが含まれる。シンボルのインデクスは、そのインデクスで符号化される元のシンボルの値を表わす。頻度テーブルは確率テーブルに変換することができ、この確率テーブルを頻度テーブルの概算として使用することもできる。頻度テーブルとコードワード長とは相互に変換可能である。
前述のテーブルの何れかが送出される場合、そうした送出において非常に重要なパラメータの一つはテーブルの最大インデクスである。テーブルの最大インデクスは、送出されたテーブルにおいて、同じく入力データにおいて利用可能な相異なるシンボルが何種類あるか、あるいは最大何種類ありうるかを表わしている。例として、次のデータが与えられたとする:
4, 3, 0, 1, 0, 4, 3, 4。
4, 3, 0, 1, 0, 4, 3, 4。
この場合、実際の最大インデクスは4、最小インデクスは0であり、このデータに存在する相異なるシンボルは最大で5種類(最大インデクス−最小インデクス+1=4-0+1)ということになる。実際にデータに存在する異なるシンボルは4種類(0, 1, 3, 4)しかないため、テーブルは、可能な相異なるシンボルの数である「4」ではなく、最大インデクス、即ち利用可能な相異なるシンボルの数としての「3」を用いて送出されてもよい。テーブルの最大インデクス値として値3が用いられる場合、各テーブルインデクスに対してどのシンボルが用いられるのかという情報を送出するために、他の機構が必要になることもある。
シンボルが順番に並んでいる場合、実際の最大インデクス(4)と可用性ビットが送出されてもよい。この実施例の場合、11011が送出される。こうして送出される情報は、テーブルインデクス0が、それをインデクスとしてマークされるシンボル0に等しくなるように対応付けされ、関連するシンボルの対は(0, 0)になる。同様に、残りのインデクスとシンボルの対は(1, 1)、(2, 3)、(3, 4)である。こうしたインデクス・シンボル対を、別のテーブルインデクスとして用いられるインデクスを直接定義するために使用し、テーブルの最大インデクスである「3」を送出することもできる。これは、例えば送出されるテーブルの中のシンボルがその出現頻度に基づいて格納される場合、非常に価値のある方法である。
例えば前述の例では、インデクス・シンボル対は、例えば(0, 4)、(1, 0)、 (2, 3)、(3, 1)である。場合によっては、使用されるインデクス・シンボル対が予め定義され、別の時点で、この使用されるインデクス・シンボル対のテーブルのインデクスが送出される。また別の異なる状況では、このインデクス・シンボル対が符号化データ(E2)と共に送出される。さらに別の異なる状況では、デコーダ60は、既知の場所から使用されるインデクス・シンボル対を読み出すように動作可能である。また別の異なる状況では、デコーダ60は、符号化データ(E2)と共に送出された情報に対応する場所から、使用されるインデクス・シンボル対を読み出すように動作可能である。
状況によっては、テーブルが対称性を活用して送出されると見積もれるという有利な点もある。対称性を利用することによって、使用されている符号テーブルを、必要となるテーブル全体を送出するときよりも小さいデータサイズで送出することができる。これは、符号テーブルがコード長、出現確率、出現頻度の何れかに基づいているか否かに拘らず可能である。また、エンコーダ50及びデコーダ60の両方で対称なテーブルを用いる場合、それに含まれる要素、即ちシンボルが少ないほど高速で生成することができる。対称性を利用することでテーブルの部分最適化が可能になるが、送出されるテーブルのデータサイズの増加節約分は、とりわけ送信対象データの量がかなり少ない場合、全体での損失と相殺することになる。
前述の最後の実施例では、テーブルの送出に対称性が利用されてもよい。これは、シンボル値「0」は「1」よりも確率が高く、それに対応して、シンボル値「4」は「3」よりも確率が高いためである。また、シンボル値「0」と「4」の確率は互いに近く、それに対応して、シンボル値「1」と「3」の確率も互いに近い。しかし、値「2」はこのデータには全く出現しない。それ故、データが検査される向きとは無関係に最小の確率値になる。
対称性が利用される場合、符号テーブルは常に、対称的に対応する要素の出現数の和に基づいて生成することができる。この場合、シンボル値「0」と「4」の出現数は合わせて5であり、それに対応して、シンボル値「1」と「3」の出現数は合わせて3である。要素「2」はこのデータには全く出現しないので、それ自身のシンボルを与える必要は無い。ただし状況によっては、要素「2」にも同様にシンボルが生成されてもよい。この場合、対称性を利用するなら、このシンボルが右手系テーブルと左手系テーブルの両方に含まれることになる。
こうして、この範囲に対する出現数が5, 3, (0)であるようにして、レンジ符号テーブルが生成されてもよい。使用されているレンジテーブルはシンボル0から4に対して5, 3, 0, 3, 5であり、最適な出現頻度ベースのレンジテーブルでは当然ながら3, 2, 0, 1 , 2である。前述の対称性に基づく最適な実装では、出現頻度として2つの値を送信、即ち送出する必要があるが、一方で、レンジテーブルを用いる場合では出現頻度として4つの値の送出が必要になる。
対称性に基づく同様の着想が、ハフマン符号化等の他の符号化法と共に用いられてもよい。この場合、対称性に基づくテーブルは、例えば、左手系の値がコード「0」を受け取り、右手系の値がコード「1」を受け取るテーブルになる。したがって、ハフマンコードワードは例えば01や00となり、10や11は存在しない。あるいは、値「2」が将来存在できる選択肢も保持したい場合、コードワードは01, 001, 000/100, 101, 11となる。この実装において原理的には、送信/送出するのに2つのコード長(1と1)だけでもよく、あるいは3つのコード長(1、2、2)でもよい。テーブルが対称性を利用していることが分かっている場合には、使用されているテーブルはデコーダ60で完全に復元することができる。こうした利点は、テーブルが長くなる程、より一層明確になってくる。
当然ながら、テーブルが対称性を利用しているか否かに関する情報が事前に分かっていてもよく、そうでなければ、最適テーブル又は定義済みテーブルが使用中であるかに関する情報や、前のテーブルから動的に生成されたテーブルであるかに関する情報が、同様の仕方で送信/送出されてもよい。テーブルが対称性を利用しているか否かに関する情報の送出は、使用されているテーブルのインデクスをデコーダ60に送信することによって実行される。
例えば:
(i)テーブルインデクス「0」は、そのテーブル全体が送信/送出されることを意味する;
(ii)テーブルインデクス「1」は、そのテーブルが対称的でその半分のみが送出されることを意味する;
(iii)テーブルインデクス2から63までは、定義済みテーブルが使用されていることを意味する;
(iv)テーブルインデクス64から127までは、以前に送出・格納された動的テーブルが使用されていることを意味する。
(i)テーブルインデクス「0」は、そのテーブル全体が送信/送出されることを意味する;
(ii)テーブルインデクス「1」は、そのテーブルが対称的でその半分のみが送出されることを意味する;
(iii)テーブルインデクス2から63までは、定義済みテーブルが使用されていることを意味する;
(iv)テーブルインデクス64から127までは、以前に送出・格納された動的テーブルが使用されていることを意味する。
当然ながら、対称テーブルが定義済みテーブルや動的格納済みテーブルとして利用されてもよい。
また、例えばODelta符号化を用いて又は用いずに、様々な符号化方法が使用されてもよい。ODelta符号化は、データの値0・1の列への差動符号化と、計数ラップアラウンド(counting wraparound)の採用を含んでいる。さらに、こうした様々な符号化方法を利用する場合、使用されているテーブルのテーブルインデクスと一緒に利用することが有益であり、符号化前にODelta法がデータに適用されたか否かを示したり、それに対応してデコーダ60では復号後にその逆変換を行わなくてはならないか否かを示したりしてもよい。
このような場合、例えばテーブルインデクスは、ODelta法が使用されていたことを示す値128decが追加される以外はこれまでと同じである。 この追加が行われなかったならば、ODelta法は符号化前のデータに適用されなかったことになる。当然ながら、テーブルインデクス値に他の値を追加することもできる。しかし基本的なことであるが、符号化データに付随するテーブルインデクスは、使用されているテーブルの種類、そのテーブルインデクスと共に伝送/送出される追加データの種類を表わしている。
次に図2と図3Aを参照する。図には、入力データD1を符号化してそれに対応する符号化出力データE2を生成する方法のステップが示され、この方法のステップは概括して参照番号10で示されている。この方法は、次の1つ又は複数のステップを採用してもよいが、これらに限定されない:1つ又は複数の頻度テーブル25を生成するステップ20;1つ又は複数の符号テーブル35を生成するステップ30;最適符号化法を選択するために入力データD1を解析するステップ40。こうした入力データD1を符号化する方法を実装する場合、入力データD1にある1つ又は複数のシンボルをそれに対応するインデクスに変換する利用可能な機構が存在しなくてはならない。例えば、複数のインデクスの中のある特定のインデクスは、例えば画素配列画像における画素値に等しい。インデクスが画素配列画像にある画素値から最小画素値を引いた差に等しくてもよい。こうした状況では、本方法は符号化出力データE2で最小画素値を送出する必要がある。すなわち、最小画素値は、方法10又はその逆の方法を用いてエンコーダ50からそれに対応するデコーダ60に何らかの形で送出されなくてはならない。これが送出されないと、デコーダ60は所定のシンボルブロックからそのインデクスを用いてそれに対応する元の値に復号することができなくなる。インデクスは複数の情報から生成されてもよい。例えば1つ又は複数の離散コサイン変換(DCT)を介する場合、AC係数の絶対値を含む個別のAC係数、AC係数の符号、非ゼロAC/DC係数とその前の非ゼロAC/DC係数との間にあるゼロAC係数の実行、現在のAC係数及び最後の非ゼロAC係数に関する情報を表わす標示フラグ等から生成することができる。インデクスは、統合される複数の画素値に基づく生成の影響も受けやすい。こうした画素値には、例えば8ビットのR、G、Bの各画素値を含む24ビットRGB画素や、2つの5ビットY画素値を含む10ビット値がある。
次に、図3Bを参照する。デコーダ60において対応するトランスコードデータD4を生成するためにデータD3をトランスコードする動作が、トランスコーダ70を介して実装される。これは、例えば次のようなマルチキャストを行う状況において実装される:
(i)複数のデバイスであって、各デバイスは符号化データE2を受け取るデコーダ60をホストする;
(ii)複数のデバイスのうち少なくとも一部は互いに異なり、ディスプレイスクリーンレイアウト、解像度、アスペクト比、ディスプレイスクリーンドライバのバッファ容量等、関連する相異なる出力フォーマットを有する。
(i)複数のデバイスであって、各デバイスは符号化データE2を受け取るデコーダ60をホストする;
(ii)複数のデバイスのうち少なくとも一部は互いに異なり、ディスプレイスクリーンレイアウト、解像度、アスペクト比、ディスプレイスクリーンドライバのバッファ容量等、関連する相異なる出力フォーマットを有する。
データD3の変換符号化は、デバイスのハードウェア層及び対応ソフトウェア層の何れか又は両方によって互換性のある仕方で処理可能な、対応するデータD4を生成するために必要とされる。ここでデバイスは、例えばスマートフォンや専門の科学装置、テレビ受像機、ハイファイ装置、ビデオ会議装置等の計算ハードウェアに基づいてもよい。トランスコーダ70は、ソフトウェア、ASIC等の専用データ処理ハードウェアの何れか又は両方で実装される。
後述するように、方法10を実装する場合、1つ又は複数のシンボル値を1つ又は複数の対応するインデクスに変換するステップが必ず含まれなくてはならない。このステップ又はその逆ステップは、デコーダ60に伝送されるか、あるいはエンコーダ50とデコーダ60の両方に予め設定されていなくてはならない。こうしたやり取りを実現する最も単純なアプローチは、所定のシンボル値とそれに対応するインデクス値との間の直接的な関係を用いることである。例えば、インデクス値がそれに対応する画素値に等しくてもよく、あるいは、S=符号フラグ、V=10ビット係数値、R=6ビット非ゼロ実行値、L=最終フラグとして、例えば次のように表現される数に等しくてもよい:
S V V V V V V V V V V R R R R R R L。
S V V V V V V V V V V R R R R R R L。
幾つかの理由により、こうした直接関係を常に利用できるとは限らない。例えば、直接関係が用いられるときには、次の状況の何れかがありうる:
(a)データやインデクス、出現頻度、出現確率、シンボル長の符号化又は復号は不可能又は非効率である;
(b)相異なるインデクスの数が膨大である;
(c)全てのシンボルが利用可能な出現頻度を持つわけではなく、このため、アルゴリズムによっては、こうしたシンボルに対するコードを生成することができない。
(a)データやインデクス、出現頻度、出現確率、シンボル長の符号化又は復号は不可能又は非効率である;
(b)相異なるインデクスの数が膨大である;
(c)全てのシンボルが利用可能な出現頻度を持つわけではなく、このため、アルゴリズムによっては、こうしたシンボルに対するコードを生成することができない。
こうした(a)から(c)の問題の一部は、エスケープコードを用いて、又は全シンボルに対する頻度情報を生成する論理を用いて少なくとも部分的に解決することができる。シンボルをインデクスに変換する他のアプローチを用いるのが有益であることも非常に多い。特定のアプローチは、利用可能なシンボルに用いられるインデクスを特定するルックアップテーブル(LUT)の確保を必ず伴う。ここで、エスケープコードは、符号テーブルのサイズを小さくするのに非常に有益である。このLUTはエンコーダ50とデコーダ60で利用可能でなくてはならない。あるいは、エンコーダ50からデコーダ60へ、又はその逆で送出されなくてはならない。高圧縮を実現するためにより適した符号化法が要求される場合、利用可能なLUTのインデクスに基づいて選択可能な複数のテーブルを利用することが有益である。しかしこれは、場合によっては実用的ではない。それは、出現頻度又はコードワード長の組合せは膨大で、データメモリに全ての相異なるテーブルを格納する意味は無く、こうしたLUTの送出でも、エンコーダ50とデコーダ60の間で多量のデータをやり取りしなくてはならないからである。したがって、本開示に従う方法10は、シンボルからインデクスへの適切な変換を1つ又は複数用いることによって、出現頻度やコードワード長、出現確率をエンコーダ50からデコーダ60へ伝送する効率を向上させることができる。符号化法が、頻度情報として提供されるより正確な情報を利用できない場合、頻度の代わりにコードワード長を用いるのが常に有益である。例えば、VLC符号化法は頻度情報を利用できないが、算術符号化、レンジ符号化であれば、頻度や確率の情報を利用することができる。
次に、本開示の実施形態の一例を詳述する。ここでは符号化にコードワード長が用いられているが、それに対応する実施形態において頻度情報や確率情報を用いるものも実現可能である。
符号化データE2として図2を参照する。符号化データは、例えば符号化データ列であって、値0から19までの20種類のシンボルを格納しうるデータ値を含む。現データ列では、このうち最小値が2、最大値が19の8種類のデータ値のみが実際に利用可能である。後述するように、こうした最小値と最大値は、テーブル送出の省力化を実現するために別々に送出されてもよい。それに対応する頻度は合計が148で、コードワード長は最小長が1、最大長が6、シンボルのインデクスは、例えば以下の表1に基づいている。これらのシンボルを圧縮しない場合、ビット列の搬送には148*5ビット=740ビットが必要だと決められる。
表1に示されるような符号化形態では、適切な頻度テーブル又は符号テーブルが利用可能でない場合、例えば、エンコーダ50とデコーダ60で参照用インデクスが予め定義されるか特定可能であり、必要なコードワード、即ちコードとコード長をエンコーダ50からデコーダ60へ送信するのに利用可能な方法も複数存在する。
第1の例示的方法は、データの出現頻度を修正してそれに対応する符号テーブルを生成する。ここで、最も確率の低い(最低確率)シンボル、即ち最も長いコードワードには追加ビットが割り当てられ、データの中で利用できない全てのシンボルには、符号化に影響を及ぼさないような長いコードワード長が割り当てられる。こうして、この方法により、エンコーダ50とデコーダ60は相互に類似する頻度テーブルとハフマンツリーを生成することができる。ここでは、12種類のシンボルが無いため、こうした出現頻度の修正は、例えば元の出現頻度に12を掛けておき、実際の出現頻度値を持たない、即ち頻度値がゼロである全てのシンボルに対する頻度値を1に設定することによって実装することができる。利用可能な頻度値を持つ全シンボルに対する修正後頻度値は、例えば、表1の頻度2という欄の記載のようになる。これらの新たな頻度に基づいて、全20種類のシンボルに対するコードワード長は次のように生成される:
11, 11, 4, 11, 6, 11, 11, 1, 11, 7, 11, 11, 2, 4, 5, 10, 10, 10, 10, 4。
11, 11, 4, 11, 6, 11, 11, 1, 11, 7, 11, 11, 2, 4, 5, 10, 10, 10, 10, 4。
このような符号テーブルを用いると、エンコーダ50からデコーダ60に符号化シンボルを送出するのに必要なビット数は(7*4 + 2*6 + 81*1 + 1 *7 + 35*2 + 9*4 + 5*5 + 8*4 =)291ビットである。正しいデータ符号化とそれに次ぐデータ復号のためには、エンコーダ50とデコーダ60は同じ出現頻度を使用しなくてはならない。このような出現頻度は、前述の新しいコードワード長に基づいて生成することができ、出現頻度を持つシンボルに対する結果は、「頻度3」という欄の記載のようになる。この結果は2(maxbitlen - bitlen)で表わされる。ここで、"maxbitlen"は「最大ビット長(maximum bit length)」の略であり、"bitten"は「ビット長(bit length)」の略である。他のシンボルには頻度として2(bitlen = 10)又は1(bitlen = 11)が割り当てられる。
この第1の方法により、全ての可能なシンボル、即ち前述の例では20種のシンボルを含む符号テーブルを生成することができる。これは、他の同種のデータに対して同じ符号テーブルを使用する場合に有益である。この種のワード長は、追加情報を用いずに任意の圧縮法で圧縮することができる。そのため、可能性のあるあらゆる状況において、符号テーブルをエンコーダ50からデコーダ60へ容易に送出することができる。例えば、この符号テーブルは非圧縮では1コードワード長当り4ビットを要し、全コードワード長では、20コードワード長 * 4ビット/コードワード長=80ビットとなる。
この第1の例示的方法では、全ての最低確率シンボルに対して1ビットだけ使用するため、最適ハフマンコードと比べると非効率である。さらに、コードワード長、即ち符号テーブルを圧縮してエンコーダ50からデコーダ60へ送出するためのビット数も必要である。全ての可能なシンボル数である数20も送出されてもよく、あるいは、デコーダ60が既知でもよい。
次に、本発明の別の実施形態を示す第2の例示的方法について述べる。第2の方法は、利用可能なシンボル、即ち、出現頻度値が0よりも大きいシンボルに対してのみコードワード長を生成する。(表1を参照して)インデクス2は、ハフマン符号テーブルの生成に用いられるインデクスであり、インデクス1はエンコーダ50からデコーダ60へ送出されなくてはならないインデクスであって、シンボル値そのものである。このように生成されたコードワード長は、(表1を参照すると)「コードワード長(CWLen)」という欄の記載のようになる。このような符号テーブルを用いると、符号化シンボルを送出するのに必要なビット数は(7*4 + 2*6 + 81*1 + 1 *6 + 35*2 + 9*4 + 5*5 + 8*4 =)290ビットである。こうしたコードワード長に基づいて、エンコーダ50とデコーダ60は、表1の「頻度1」という欄の記載のような頻度を生成するように動作可能である。
この種の符号テーブルを送出する第1の方法は、コードワード長とそのコードワードのインデクスを次の数のペアとして送出する:
(2, 4), (4, 6), (7, 1), (9, 6), (12, 2), (13, 4), (14, 5), (19, 4)。
(2, 4), (4, 6), (7, 1), (9, 6), (12, 2), (13, 4), (14, 5), (19, 4)。
ここで、ペアは括弧を用いて表記される。
こうした送出方法はインデクスに5ビット、コードワード長に3ビットを必要とするため、ペアには8ビットを要し、全ペアでは8 * 8ビット=64ビットとなる。
こうしたインデクスはデルタ符号化を行うことができ、ペアは次のようになる:
(2, 4), (2, 6), (3, 1), (2, 6), (3, 2), (1 , 4), (1 , 5), (5, 4)。
(2, 4), (2, 6), (3, 1), (2, 6), (3, 2), (1 , 4), (1 , 5), (5, 4)。
こうして当然のことながら、インデクスに必要なビット数は3ビットのみとなり、コードワード長の3ビットと合わせてペアに必要なビット数は6ビット、符号テーブルの搬送に必要なビット数は8 * 6ビット=48ビットとなる。
こうしたインデクスとコードワード長の値が分離されていることによって、統合された8ビット又は6ビットの値と比べて改善された圧縮を実現し易いデータ列を持てるようになり、有益である。ここで、データ列は:
2, 4, 7, 9, 12, 13, 14, 19
及び
4, 6, 1, 6, 2, 4, 5, 4
であり、合計8 * 5ビット+8 * 3ビット=64ビットである。
第1列のインデクスはデルタ符号化され、
2, 2, 3, 2, 3, 1, 1, 5
及び
4, 6, 1, 6, 2, 4, 5, 4
であり、合計8 * 3ビット+8 * 3ビット=48ビットである。
これは、可能性のあるシンボルの種類が多いが、データには相異なるシンボルの種類が少ししか含まれていない場合には最もよい、即ち最適な送出方法である。
2, 4, 7, 9, 12, 13, 14, 19
及び
4, 6, 1, 6, 2, 4, 5, 4
であり、合計8 * 5ビット+8 * 3ビット=64ビットである。
第1列のインデクスはデルタ符号化され、
2, 2, 3, 2, 3, 1, 1, 5
及び
4, 6, 1, 6, 2, 4, 5, 4
であり、合計8 * 3ビット+8 * 3ビット=48ビットである。
これは、可能性のあるシンボルの種類が多いが、データには相異なるシンボルの種類が少ししか含まれていない場合には最もよい、即ち最適な送出方法である。
こうした前述のデータ列は全て、動作時にエンコーダ50からデコーダ60へ圧縮して送出することができる。本開示のこの方法は最適ハフマン符号化と比べて非効率な点は無いが、この方法でも未だ、インデクスとコードワード長に関する情報を含むこうしたデータ列を送出するのに相当なビット数を消費する。利用可能なシンボル数である値8も送出されなくてはならない。さもなければ、復号対象ペア値の数をデコーダ60が符号テーブルに確定できないためである。この場合、可能な全シンボル数である数20は、エンコーダ50とデコーダ60の間で送出不要である。
前述の方法によっては、特に、エンコーダ50で入力データD1に対して望ましい符号化を行ってそれに対応する符号化データE2を生成し、デコーダ60でこの逆の動作を実現するために、組み合わせて利用しやすいものである。また、こうした解決方法の全てが、例えば第2の方法と同様の仕方で、利用可能なシンボルにのみハフマン符号を生成してもよい。さらに、こうしたデータ長から生成される頻度テーブルが(表1の)頻度1という欄の記載のようでもよい。
第1の方法と比べると、第2の方法は、コードワード長が利用可能でない場合にはそれを0に設定することができる。しかしそれでも、こうした情報をエンコーダ50からデコーダ60へ送出しなくてはならない。これは、実際のコードワード長は決して0にはならないという事実から生じうることである。これにより、次のようなワード長のデータ列:
0, 0, 4, 0, 6, 0, 0, 1, 0, 6, 0, 0, 2, 4, 5, 0, 0, 0, 0, 4
では、どのコードワード長についても元々3ビットしか必要でないので、合計すると20 * 3ビット=60ビットとなる。
0, 0, 4, 0, 6, 0, 0, 1, 0, 6, 0, 0, 2, 4, 5, 0, 0, 0, 0, 4
では、どのコードワード長についても元々3ビットしか必要でないので、合計すると20 * 3ビット=60ビットとなる。
この種のワード長は、追加情報を用いずに任意の圧縮法で圧縮することができる。そのため、可能性のあるあらゆる状況において、符号テーブルをエンコーダ50からデコーダ60へ容易に送出することができる。また、このデータは値が0である数を頻繁に含むため、例えばVLCやRLEを用いて容易に圧縮できる。可能な全シンボル数である数20がエンコーダ50からデコーダ60へ送出されてもよく、デコーダ60が既知であってもよい。
別の実施形態では、どのデータが利用可能なシンボルでどのデータがそうでないかを特定するビットを使用する。2つのデータ列が生成される場合、第1のデータ列が含むビットと第2のデータ列が含むコードワード長は、それぞれ次のようになる:
0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 1, 1, 0, 0, 0, 0, 1
及び
4, 6, 1, 6, 2, 4, 5, 4。
この場合、各シンボルに対して1ビット、利用可能なコードワード長に対して3ビットを必要とするため、合計では20 * 1ビット+8 * 3ビット=44ビットとなる。これは通常、最もよい、即ち最適な送出方法である。
0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 1, 1, 0, 0, 0, 0, 1
及び
4, 6, 1, 6, 2, 4, 5, 4。
この場合、各シンボルに対して1ビット、利用可能なコードワード長に対して3ビットを必要とするため、合計では20 * 1ビット+8 * 3ビット=44ビットとなる。これは通常、最もよい、即ち最適な送出方法である。
こうしたデータ列は更に、EM(entropy modifier)VLCを利用して圧縮可能である。前述のように、可能な全シンボル数である数20がエンコーダ50かとコーダ60の間で送出されてもよく、既知としてデコーダ60に与えられてもよい。また、利用可能なシンボル数である数8は、値が1であるビットから計算できるため、エンコーダ50とコーダ60の間で送出される必要はない。
本開示に従う前述した全ての方法について、エンコーダ50とデコーダ60は、前述の例では20であった、使用されうる相異なるシンボルの数や、同じく前述の例では8であった、利用可能な相異なるシンボルの数に関する情報を処理しなくてはならない。こうした値、即ち相異なるシンボルの数がデコーダ60で利用できない場合は、デコーダ60に送出されなくてはならない。あるいは、利用可能なデータ値が含まれる範囲を特定する少量の追加情報を送信することによって、送出されるテーブルに含まれるデータの一部を節約してもよい。例えば、データ値が含まれる範囲を特定する値2(最小値)と19(最大値)を送出することも可能である。この実施例では、こうした送出で節約できるビット数よりも多くのビット数を使うことも度々あるが、例えば、8ビット画素が60から200までの値しか含まない場合は、エンコーダ50からデコーダ60へ伝送されるビット数を大幅に節約できる。こうした範囲の送出によって、最小値未満又は最大値を超える、使用されない全てのビット又は値をエンコーダ50からデコーダ60へ送出する必要がなくなる。また当然ながら、こうした範囲がエンコーダ50からデコーダ60へ送出される場合、インデクス値がデルタ符号化を用いて又は用いずに送信されなかった状況においては、最初と最後のインデクス値の送出は不要である。さらにこれは、最後の実施例における最初と最後の1ビットについても同様に適用できる。最小値と最大値の送出は、他の方法を用いる場合でも同様に利用することができる。このような方法としては、例えば英国特許出願第1303661.1号(出願日2013年3月1日、出願人はGurulogic Microsystems Oy)に開示されたODelta符号化があり、以下、参照によって本願に包含されるものとする。最小値と最大値を送出する最大の利点は、エントロピーを修正してエントロピー符号化を実装する全ての方法が同一情報を使用し、その情報が一度だけ送出される場合に発揮される。
前述の方法は選択的に使用されてもよい。例えば、所定のデータチャンクであって、例えばエンコーダ50からデコーダ60へ伝送すべきデータ全体から分割されたデータチャンクの中で符号化対象シンボルの数に応じて、選択的に使用されてもよい。したがって、前述において明らかにされた方法は、利用可能な相異なるシンボルの数、それらの内、実際に使用されるシンボルの数、最小確率のシンボルの頻度、利用可能なシンボルのインデクスが可能なシンボルを通じて分配される仕方に応じて選択される。
表1に示されたシンボルに関するスケール確率は、その頻度値に基づいて計算することもできる。シンボル数は例えば148である。この実施例におけるスケール確率は、2つの相異なる確率乗数、即ち256と32を用いて算出され、有益である。最初のシンボルについては、確率乗数256を用いると、スケール確率はRound(256 * 7/148)=12として算出される。ここで、「Round」は整数値に切り上げる関数である。乗数256で算出される全てのスケール確率は次のようになる:
12, 3, 140, 2, 61, 16, 9, 14。
スケール確率値の合計が257と256を超えているが、これは1ずつ減らしていくと有益である。こうした減算は、実際の符号化への影響を最小限にするよう実装されるのが有益である。例えばこの場合、最小値である値2を値1に減らしたり、最小の切り上げ値である値9を値8に減らしたりしてもよい。これにより、レンジ符号化又は算術符号化に対して、乗数256でスケールした確率値は次のようになる:
12, 3, 140, 1, 61, 16, 9, 14(合計256=確率乗数)。
(乗数256による)スケール確率の送出は次のように行われる:
0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 1, 1, 0, 0, 0, 0, 1
及び
12, 3, 140, 1, 61, 16, 9, 14。
確率乗数の値が32の場合、スケール確率値は次のようになる:
2, 0, 18, 0, 8, 2, 1, 2。
そして、合計値が等しくなるようにすると、次のようになる:
1, 0, 18, 0, 8, 2, 1, 2。
12, 3, 140, 2, 61, 16, 9, 14。
スケール確率値の合計が257と256を超えているが、これは1ずつ減らしていくと有益である。こうした減算は、実際の符号化への影響を最小限にするよう実装されるのが有益である。例えばこの場合、最小値である値2を値1に減らしたり、最小の切り上げ値である値9を値8に減らしたりしてもよい。これにより、レンジ符号化又は算術符号化に対して、乗数256でスケールした確率値は次のようになる:
12, 3, 140, 1, 61, 16, 9, 14(合計256=確率乗数)。
(乗数256による)スケール確率の送出は次のように行われる:
0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 1, 1, 0, 0, 0, 0, 1
及び
12, 3, 140, 1, 61, 16, 9, 14。
確率乗数の値が32の場合、スケール確率値は次のようになる:
2, 0, 18, 0, 8, 2, 1, 2。
そして、合計値が等しくなるようにすると、次のようになる:
1, 0, 18, 0, 8, 2, 1, 2。
なお、当然のことながら、スケール確率値が0と算出されることもある。これは、こうした値が例えばエスケープシンボルを用いて送出されなくてはならないことを意味する。エスケープシンボルに対するスケール確率も算出される必要があるが、その値は1未満でなくてもよい。この場合、Round (32 * (2 + 1) / 148) = 1であるから、値1が割り当てられる。したがって、このエスケープシンボル("escape")も他のシンボル群に追加されなくてはならず、新しいシンボルセットは次のようになる:"escape", 2, 7, 12, 13, 14, 及び19。こうした新しいシンボル群には、0から6の範囲でインデクスを割り当てるのが有益である。レンジ符号化又は算術符号化に関して、新しいシンボル群に対するスケール確率は、エスケープシンボルの確率が1つ又は複数の他のシンボルよりも小さい場合、次のようになる:
1 及び 1, 18, 8, 2, 1, 1 (合計32=確率乗数)。
(乗数32とエスケープシンボルを用いる)スケール確率の送出は次のように行われる:
0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 1, 1, 0, 0, 0, 0, 1
及び
1, 1, 18, 8, 2, 1, 1。
当然のことながら、最初のシンボルはエスケープシンボルであり、ビットは他のシンボル値を特定している。
1 及び 1, 18, 8, 2, 1, 1 (合計32=確率乗数)。
(乗数32とエスケープシンボルを用いる)スケール確率の送出は次のように行われる:
0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 1, 1, 0, 0, 0, 0, 1
及び
1, 1, 18, 8, 2, 1, 1。
当然のことながら、最初のシンボルはエスケープシンボルであり、ビットは他のシンボル値を特定している。
前述のように、エスケープシンボルが定義されると、このテーブルは後でより使い易くすることができる。それは、このデータに現れなかったシンボルについても、それらが後でデータに現れるならば、エスケープシンボルを用いて送出することができるからである。
レンジ符号化でエスケープシンボルを使用することは、別の特許出願において開示されている。この出願は、英国特許出願第1403038.1号、出願日2014年2月20日、出願人Gurulogic Microsystems Oy、発明の名称「エンコーダ、デコーダ及びその方法(Encoder, decoder and method)」であり、以下、参照によって本願に包含されるものとする。
前述の表1に関する説明のように、データD1がエンコーダ50で符号化され、次いでデコーダ60で復号される場合、送出されるテーブルに代わって定義済みテーブルやインデクスで示されるテーブルを使用することもできる。これは、使用されるコード、頻度、確率、コード長の各種テーブルがエンコーダ50とデコーダ60には既知であること、あるいは、こうしたテーブルが別の限定的なテーブル群から選択されて、エンコーダ50が選択したものをデコーダ60へ送出することを意味する。定義済みテーブルは、デコーダ60でローカルに利用可能でもよい。
送出されたパラメータであって、例えばテーブルのインデクス、テーブルの最大インデクスの何れか又は両方に基づいて、そのテーブルを予め格納することもできる。あるいはテーブルが、初期化機能に実装されたアルゴリズムや、予め格納済みのテーブルにあるアルゴリズムで生成されてもよい。こうしたテーブルの作成あるいは生成は、例えばテーブルのインデクス、テーブルの最大インデクス、テーブルの最小インデクスの何れか又は全てといった送出パラメータに基づいてもよい。予め格納済みのテーブルの代わりに、データD1を符号化して符号化データE2を生成する前に送出されたテーブルを使用してもよい。
例えば、VLC符号化が用いられる場合、コード長は通常、相異なるテーブルインデクスに対して事前に格納され、こうしたコード長の値に基づき、テーブル全体又はテーブル値の一部のみを用いて符号テーブルを生成することができる。この使用される部分は、送出されたテーブルパラメータやテーブルインデクスに基づいて定義されてもよい。同様に、レンジ符号化が用いられる場合、出現確率テーブルは通常、テーブルの形態とテーブル長に基づいて生成される。テーブル形態は、例えばテーブルインデクスを用いて送出されたということを指し、テーブル長は、例えばテーブルの最大インデクスが送出されたことを指す。
次に、本開示の別の例示的方法について述べる。この方法は、個別のエスケープシンボルを用いなくても効率的なコード送出を可能にし、かつ、現在の所定のデータチャンクと、シンボル頻度が僅かに異なる将来のデータチャンクに関しても、全シンボルの効率的符号化を可能にする。この別の方法は、全シンボル、即ち利用可能な値を持つシンボルだけでなく利用可能な値を持たないシンボルを含めた全てにスケール確率として少なくとも1つの値を割り当てるように実装されてもよい。スケール確率値が1ならば可用性ビットは0に等しく、他のスケール確率値ならば可用性ビットは1に等しい。スケール確率値は、可用性ビットが1に等しいシンボルのみについて送出される必要がある。この方法の詳細は、Gurulogic Microsystems Oyが出願した英国特許出願第1403038.1号に記載されており、以下、参照によって本願に包含されるものとする。ただし、前述の実施例におけるテーブル送出は次のようになる:
0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0
及び
10, 4(合計18*1 + 10 + 4 =32=確率乗数)。
0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0
及び
10, 4(合計18*1 + 10 + 4 =32=確率乗数)。
このように、この実施例は、データのエントロピーを符号化するハフマン符号化で実現されるものよりもむしろ、レンジ符号化にかなり近い性能を生み出すような有益な状況を示している。こうした解決方法は、符号確率テーブルを非常に効率的に送出することができる。他の種類のデータや他の種類の確率乗数値を用いても、この解決方法は、あらゆる状況において採用されうる最良、即ち最適な符号化方法であることが明白である。こうした理由で、符号テーブルの送出について、より詳細に述べている。
エンコーダ50とデコーダ60は、静的に又は動的に更新可能な仕方で全てのテーブルを格納することができる。こうしたやり方はエンコーダ50とデコーダ60の両方で利用されるべきものである。テーブルが格納されれば、そのテーブルは、それに対応する格納済みテーブルを一意に特定するインデクスを用いて、エンコーダ50からデコーダ60へ送信されるデータにおいて有益に特定される。こうしたテーブルのインデキシングは、エンコーダ50からデコーダ60へ符号テーブルを送出するのに必要な送信データと比べてオーバヘッドデータを大幅に節約できる可能性がある。
予め格納済みのテーブルを用いる例は、例えば次の実施例で理解することができる。送出テーブルについて、前述の実施例で示した最後の確率テーブル、即ち、1, 1, 1, 1, 1, 1, 1, 10, 1, 1, 1, 1, 4, 1, 1, 1, 1, 1, 1, 1は、再利用目的で追加されるように選択される。この目的のため、テーブルには例えば「17」というインデクス値が割り当てられる。そして、符号化対象である新しいデータチャンクが必要であり、それは、表2に示されるようなシンボル値と頻度を有する。
レンジ符号化における全ての利用可能な確率テーブルは、表2から評価することができる。その結果、レンジ符号化を用いてこの新しいデータをエンコーダ50からデコーダ60へ送出するために使用されるべき最良の確率テーブルとして、テーブル17の選択が最も確からしい。少なくとも、理想的なエントロピー符号化の結果に関してテーブル17が生成する追加データよりも、新しい確率テーブルの送出の方が多くのデータを必要とすることは容易に理解できる。したがって、新しいより最適化された確率テーブルの送出を求める代わりに、テーブル17又は他の確率テーブルを再利用することができる。テーブルが再利用される場合、そのインデクスである17がエンコーダ50からデコーダ60へ送出され、次いでレンジ符号化値がエンコーダ50からデコーダ60へ送出される。テーブルを再利用できない場合、始めに新しいテーブル送出を規定する値として例えば0や次の利用可能なテーブルのインデクスがエンコーダ50からデコーダ60へ送出され、次にテーブルがエンコーダ50からデコーダ60へ送出される。またその次に、レンジ符号化値をエンコーダ50からデコーダ60へ送出することもできる。符号化シンボルは通常、レンジ符号化データ等の前に送出されなくてはならないが、それによって、デコーダ60でデータを適切に復号することができる。
既に使用中の符号テーブルを修正し、その修正箇所のみを送信して、新しい符号テーブルを得るようにしてもよい。さらに、送出/受取後に送出済み符号テーブルが適応的に使用されてもよい。
エンコーダ50とデコーダ60は、同種のデータであって、現在欠落しているシンボルがあるかもしれないデータにおいて、後で使用されうる他のシンボルの符号化も可能にする類似の完全テーブルを作成するように動作可能でもよい。こうしたテーブルは、新しい符号テーブルインデクスを持って格納されてもよい。テーブルは、不完全及び完全という両方の種類を格納することができる。また、元のテーブルのみを格納してもよい。次のときに完全な特性が必要である場合は、エンコーダ50からデコーダ60への伝送において別々にインデキシングされてもよい。完全テーブルを格納する解決方法の方が好ましいのは、決定を単純化して、必要とされるテーブルが充足しているか否かを示す追加標示の送出を不要にするからである。テーブルの充足は、全ての値を含むテーブルが、例えば4から1までの降順になっている頻度で充足されるように実装されてもよい。それによって、次のシンボルには比較的短いシンボルが割り当てられ、最後のシンボルには比較的長いシンボルが割り当てられる。こうしたアプローチを採用することによって、シンボルの順序は、将来のデータ列における利用可能なシンボルの順序に対応する。
前述の実施例において、コードワード長の送出とスケール確率の送出は有益に利用される。ただし、同様の技術をハフマン符号化や算術符号化、レンジ符号化で必要な頻度値の送出のために用いることもできる。採用すべき最良の符号化方法は、符号テーブルやコードワード長、確率テーブル、頻度テーブルの送出に必要なオーバヘッド情報に符号化データが追加される場合、最小限のビットを使用する。これによって、例えば、データの小部分、即ちデータチャンクに含まれるデータの性質、種類の何れか又は両方に対して具体的に最適化された符号化方法を用いて、このデータの小部分をエンコーダ50からデコーダ60へ送ることができる。こうした理由で、頻度値が少なくとも限られた範囲で量子化される場合に、算術符号化とレンジ符号化による最良の結果が得られる。それによって、頻度テーブルは、ほぼ正確な値を示しつつも厳密なテーブルよりも明らかに少ないビット数で送出可能であり、例えばエントロピー符号化を用いる場合、シンボルの符号化に関する最適性が僅かに減るだけで済む。さらに、スケール確率テーブルの送出によって、非常に効率がよくほぼ最適なレンジ符号化及び算術符号化の実装が可能になる。
エンコーダ50からデコーダ60へ伝送すべきデータが少量しかない場合、通常、実質的に如何なる符号化形態も用いずに通信する方がよい。しかし、データ量が増加する場合、ほぼ正確なコードワード長でハフマン符号化を用いるのが有益である。エンコーダ50からデコーダ60へ伝送すべきデータ量は増加しているため、使用する符号テーブルが正確であるほど、それに応じて得られる利益も大きくなる。また、算術符号化又はレンジ符号化が行われるデータが相当量ある場合、採用するエントロピー符号化の効率がよい程、最良の符号化結果が得られる。それによって、符号化の際、符号テーブルの送出よりも頻度又は確率の送出の方が、必要なビット数の点で有益となる。確率テーブルや頻度テーブル、コードワード長、符号テーブルのインデクスの送出は常に似通っていて、所定のインデクスが使用される場合、利用可能な最良テーブルを有する方法によって、最良の圧縮性能を実現することができる。使用される符号化方法の選択がデータやデータ量に基づいて定まらなければ、その選択もエンコーダ50からデコーダ60へ送出されなくてはならない。
エンコーダ50とデコーダ60を一体にしてコーデック100が形成される。実践的な状況では、1つのエンコーダ50と1つ又は複数のデコーダ60があってもよい。例えば、エンコーダ50が符号化データE2を生成し、それが、例えば無線、光ファイバ等の通信ネットワークを介して広範囲に亘る多数のデコーダ60にブロードキャスト、即ち「マルチキャスト」される。また、例えばピアツーピアデータ通信ネットワークでは、このピアツーピアネットワーク内で接続される複数のエンコーダ50からデコーダ60に与えられる符号化データE2が、複数の符号化データチャンクで別々に与えられ、デコーダ60で一緒に集められるという状況も生じる。こうした構成は、符号化データE2の特定部分がより局在的にデコーダ60に与えられ、こうしたピアツーピアネットワークの実装に利用される長距離データ通信ネットワークのデータ負荷を軽減でき、有益である。エンコーダ50とデコーダ60は、専用のデジタルハードウェアに容易に実装することができる。あるいは、非一時的データ記憶媒体に保存された1つ又は複数のソフトウェア製品を実行可能なコンピュータハードウェアに実装されてもよく、これらの組合せでもよい。エンコーダ50とデコーダ60は、以下に限定されないが、音声録音・再生装置、ビデオ録画・再生装置、パーソナルコンピュータ、スマートフォン、デジタルカメラ、ビデオカメラ、テレビ受像機、インターネット端末、科学装置、監視・セキュリティシステム、地上監視機能用に構成された衛星、地震感知システムで利用可能である。
本開示の実施形態は、例えば符号テーブルや頻度テーブル、確率テーブル、コードワード長等、テーブルのより効率的な送出を可能にする。それによって、優れた形でデータをより小さいデータチャンクに分割でき、例えば、そうしたデータチャンクを最適な仕方で個別に符号化することができる。さらに、テーブルはエントロピー符号化法を用いて符号化されてもよい。こうした小さいデータチャンクにはそれに対応する符号テーブルや頻度テーブル、確率テーブル、コードワード長が必要になることもある。これは、こうした様々なテーブルが利用可能である場合には、相異なるデータチャンクに対して所定のテーブルのインデクスのみを送出するだけでよいため有益である。そうでないと、新しいテーブルをデコーダ60に送出しなくてはならなくなる。所定のテーブルが送出される場合、そのテーブル固有の参照インデクスで後から利用できるように、例えばデコーダ60のデータメモリにテーブルを格納するのが有益である。
本開示の例示的実施形態では、全てのデータブロックは個別のデータブロックとして送出される。データブロックは、類似データ群に属するデータブロックの数を示す補助情報を伴って送出される。しかし、こうしたデータブロックのやり取りは通常、採用される符号化方法、シンボル数、使用される符号テーブルや頻度テーブル又は確率テーブルに関する識別情報を全データブロックに対して送出する必要があるため、極めて非効率である。加えて、類似データ群に属するデータブロックの数も、エンコーダ50からデコーダ60へ送出されなくてはならない。
符号テーブルには、それぞれに対応する意味を有する1つ又は複数の追加シンボルの挿入が有益に行われてもよい。通常、大きい符号テーブルでは、「エスケープ(escape)」シンボルが特有のコードワードを持つことが有益である。さらに、JPEGのDCT係数に用いられる符号テーブルには、「係数終了(end of coefficients)」シンボルに対する特有のコードワードが利用可能であることが有益である。これは、こうした方法がデコーダ60には既知であって、例えば、「符号テーブル変更(change of code table)」や「データ終了(end of data)」、また必要であれば「エスケープ」に使用可能な新しい符号シンボルを追加することによって、その方法が極めて効率のよい仕方で利用できることを意味する。こうした追加シンボルは、それが使用される度にその頻度が1となるように生成することができる。利用可能なテーブルが使用される場合、最長コードワードを有するシンボルの1つでコードを分割するように、対応する識別情報がシンボルとして追加される。例えば、現在のデータチャンクの後に新しいデータチャンクがあってデータが残っている場合、エンコーダ50は、「データ終了」シンボルではなく「符号テーブル変更」シンボルを使うのが有益である。この「符号テーブル変更」シンボルが送出されると、その後に新しい符号テーブルのインデクスが送出される。この新しい符号テーブルを規定するインデクス値は、例えば、利用可能なテーブルが存在しないときも使用され、利用可能なテーブルが既に存在する場合は1からテーブル数までの値が用いられる。この新しい符号テーブルに対するインデクスは、そのデータに対して利用可能又は適切な全てのテーブルを表わすのに必要なビット数を使って表わされる値を有してもよい。新しい符号テーブルのインデクスとして値0が送出された場合、エンコーダ50からデコーダ60に提供されるデータ列に次のシンボルが符号化される前に、符号テーブルの送出が必要とされる。それ以外の場合は、新しい符号テーブルを特定するインデクスの後、この新しい符号テーブルで新しいシンボルを即座に符号化することができる。最後のデータチャンクが符号化されて最後のデータ値がデコーダ60へ送出されると、エンコーダ50は、「データ終了」シンボルを送出する。この場合、「データ終了」シンボルのみが有効で、「符号テーブル変更」シンボルは使用されない。「データ終了」シンボルが送出されると、それ以降データの送出を継続する必要はない。この「データ終了」シンボルを用いることで、各データチャンクに対してデータ値の数の送出は不要になる。さらに、相異なるデータチャンクに対しては使用される符号テーブルや頻度テーブル、確率テーブル、コードワード長のみが変更されるため、符号化方法をデコーダ60へ送出する必要も無い。したがって、エンコーダ50からデコーダ60へ送信されるオーバヘッドデータの総量は、データの符号化とそれに続く復号の最中に符号テーブルが変更される場合には相当小さくなる。シンボルが「符号テーブル変更」や「データ終了」に関連する場合、1ビットの終了ビットの検出が必要である。あるいは、頻度1の2つのシンボルを符号テーブルに生成することも可能である。
場合によっては、データ値の量や符号化データの量を送信したり、データ、データ量、使用される符号化方法、デコーダ60及びエンコーダ50の実装に応じて「データ終了」シンボルを使用したりすることも有益である。さらに、エンコーダ50とデコーダ60の何れか又は両方でデータを処理するときに並列化を採用することも有益である。これは即ち、符号化データが送出され、デコーダ60が別々のプロセッサ、処理、スレッドに対してデータを容易に分割できることである。復号対象データ値の量に関する情報の送出に最適なアプローチには、通常様々なものが存在するが、こうした場合においても、どのアプローチを選択したかについては送出不要である。ただし、最適な選択が複数利用可能である場合、エンコーダ50は、特定の方法を選択し、その最適な選択に対応する決定をデコーダ60へ送出する。
前述から当然のことながら、例えば図3Aに示すように、データD1とデータD3が実質的に互いに類似するものである場合、デコーダ60は、エンコーダ50で実行される符号化機能の逆変換を実質的に実装している。しかし
例えば符号化データE2を複数の相異なるデバイスにマルチキャストする等といった種々の状況では、データD3をトランスコードしてそれに対応するトランスコードデータD4を生成するトランスコーダ70の利用を必要とする。トランスコードデータD4は、図3Bに示すように、デコーダ60と関連するトランスコーダ70をホストする所定のデバイスに対応している。デコーダ60とトランスコーダ70の両方とも、コンピュータハードウェアを用いて実装されてもよく、あるいは、トランスコーダ70が、ハードウェアドングルのような専用のトランコードハードウェアに実装されてもよい。本開示の実施形態は、データに対する可逆又は非可逆の符号化及び復号を提供するように構成されることに関する。デコーダ60は、例えば、データ(D1)のレンダリングに必要なものとは異なるディスプレイデバイスにデータを提供するエンコードを実行可能でもよい。このような場合、コーデック100を通じて処理されるデータは、元のフォーマットに復号することはできない。その代わり、符号化データE2は、例えば、他のフォーマットに直接変換され、スクリーン等にレンダリングされたり、ファイルに保存されたりする。こうしたトランスコードの実施例の一つは、データD1が元々YUVフォーマットで、圧縮されてレシーバに送信される。レシーバはこのデータをブロック毎に復元し、色変換を行い、完全解像度を持つYUV画像を再構成せず、スクリーンへのレンダリングに適したRGB画像にスケールする。
例えば符号化データE2を複数の相異なるデバイスにマルチキャストする等といった種々の状況では、データD3をトランスコードしてそれに対応するトランスコードデータD4を生成するトランスコーダ70の利用を必要とする。トランスコードデータD4は、図3Bに示すように、デコーダ60と関連するトランスコーダ70をホストする所定のデバイスに対応している。デコーダ60とトランスコーダ70の両方とも、コンピュータハードウェアを用いて実装されてもよく、あるいは、トランスコーダ70が、ハードウェアドングルのような専用のトランコードハードウェアに実装されてもよい。本開示の実施形態は、データに対する可逆又は非可逆の符号化及び復号を提供するように構成されることに関する。デコーダ60は、例えば、データ(D1)のレンダリングに必要なものとは異なるディスプレイデバイスにデータを提供するエンコードを実行可能でもよい。このような場合、コーデック100を通じて処理されるデータは、元のフォーマットに復号することはできない。その代わり、符号化データE2は、例えば、他のフォーマットに直接変換され、スクリーン等にレンダリングされたり、ファイルに保存されたりする。こうしたトランスコードの実施例の一つは、データD1が元々YUVフォーマットで、圧縮されてレシーバに送信される。レシーバはこのデータをブロック毎に復元し、色変換を行い、完全解像度を持つYUV画像を再構成せず、スクリーンへのレンダリングに適したRGB画像にスケールする。
デコーダ60は、エンコーダ50が生成した符号化データ(E2)を復号し、それに対応する復号データ(D3)を生成する方法の利用が可能である。本方法は次のステップを含む:
(i)符号化データ(E2)を受け取り、1つ又は複数の頻度テーブル、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルの何れか又は全て、及び/又は、これら1つ又は複数のテーブルを示す情報と共に、1つ又は複数のインデクスセットを符号化データから抽出すること;
(ii)1つ又は複数のインデクスセットから、1つ又は複数のデータチャンクにおいて対応するシンボル、及び/又は、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルの何れか又は全てにおいてエントリの圧縮シンボルを計算すること;
(iii)前記シンボルから、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルの何れか又は全てからの情報を用いて、1つ又は複数のデータチャンクを再生成すること;
(iv)復号データ(D3)を生成するために、1つ又は複数のデータチャンクを結合及び/又は変換する。
(i)符号化データ(E2)を受け取り、1つ又は複数の頻度テーブル、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルの何れか又は全て、及び/又は、これら1つ又は複数のテーブルを示す情報と共に、1つ又は複数のインデクスセットを符号化データから抽出すること;
(ii)1つ又は複数のインデクスセットから、1つ又は複数のデータチャンクにおいて対応するシンボル、及び/又は、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルの何れか又は全てにおいてエントリの圧縮シンボルを計算すること;
(iii)前記シンボルから、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルの何れか又は全てからの情報を用いて、1つ又は複数のデータチャンクを再生成すること;
(iv)復号データ(D3)を生成するために、1つ又は複数のデータチャンクを結合及び/又は変換する。
本方法は、1つ又は複数のテーブルの少なくとも1つが後で再利用できるように保存可能な仕方で、1つ又は複数のテーブルの少なくとも1つを受け取ることを含んでもよい。
本方法は、復号データ(D3)を生成するステップ(iv)において、1つ又は複数のデータ伸張アルゴリズムを適用することを含んでもよい。本方法では更に、1つ又は複数のデータ伸張アルゴリズムは、ハフマン復号、VLC復号、エントロピー復号、算術復号、レンジ復号の少なくとも1つを含んでもよい。
本方法は、復号データ(D3)を生成するために、1つ又は複数のデータチャンクのうち複数を実質的に同時に処理する並列プロセッサアーキテクチャを用いることによって、その複数のデータチャンクを結合することを含んでもよい。
本方法は、一緒に結合された複数のデータ値に基づいて、1つ又は複数のインデクスセットを生成することを含んでもよい。本方法では更に、このインデクスは、R、G、Bの画素値又はY、U、Vの画素値を含む1つ又は複数のRGB画素から算出されてもよい。本方法は更に、データチャンクが符号化データ(E2)に含まれる場合、そのデータチャンクに対して達成可能なデータ伸長率に応じて、符号化データ(E2)における1つ又は複数のデータチャンクの非符号化生成又は符号化生成を動的に切り換えることを含んでもよい。
本方法では、デコーダ60は、シンボルが符号化データ(E2)から、「符号テーブル変更」又は「データ終了」に関連するかを示す終了ビットを少なくとも1つ抽出するよう動作可能でもよい。
本方法は、所定のデータチャンクに存在する1つ又は複数のシンボルを参照するために必要十分なインデクスから、実質的にその所定のデータチャンクを生成することを含んでもよい。
本方法は、符号化データ(E2)に含まれる1つ又は複数の符号テーブルを伸張することを含んでもよい。本方法は更に、ハフマン復号を用いて1つ又は複数の符号テーブルを伸張することを含んでもよい。本方法では更に、1つ又は複数の符号テーブルの伸張は、1つ又は複数の補助符号テーブルを用いてもよい。
本方法は、次の送信データを復号するために、1つ又は複数の符号テーブルをデコーダ(60)で使用可能にする仕方で1つ又は複数の符号テーブルを受け取ることを含んでもよい。
本方法は、1つ又は複数の符号テーブルがアクセスされ易い場所を示す1つ又は複数の識別コードを、1つ又は複数のデータベースと1つ又は複数のプロキシデータベースの何れか又は両方を介して、符号化データ(E2)から抽出することを含んでもよい。
本方法は、次の種類のデータ:録音音声信号、録画ビデオ信号、静止画像、テキストデータ、感震データ、センサ信号データ、アナログ−デジタル変換(ADC)データ、生体信号データ、カレンダーデータ、経済データ、数学的データ、二進数データの1つ又は複数を復号することを含んでもよい。
本方法は、複数のデータソースから符号化データ(E2)を受け取り、符号化データ(E2)を再生成するために、ソースから提供されたデータを結合することを含んでもよい。
デコーダ60は、復号データ(D3)を生成するために符号化データ(E2)を復号する前述の方法を実装するように動作可能であり、エンコーダ50が生成した符号化データ(E2)を復号するデコーダ60が提供される。デコーダ60は、
(i)符号化データ(E2)を受け取り、1つ又は複数の頻度テーブル、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルの何れか又は全て、及び/又は、これら1つ又は複数のテーブルを示す情報と共に、1つ又は複数のインデクスセットを符号化データから抽出すること;
(ii)1つ又は複数のインデクスセットから、1つ又は複数のデータチャンクにおいて対応するシンボル、及び/又は、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルの何れか又は全てにおいてエントリの圧縮シンボルを計算すること;
(iii)前記シンボルから、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルの何れか又は全てからの情報を用いて、1つ又は複数のデータチャンクを再生成すること;
(iv)復号データ(D3)を生成するために、1つ又は複数のデータチャンクを結合及び/又は変換すること
を実行するように動作可能である。
(i)符号化データ(E2)を受け取り、1つ又は複数の頻度テーブル、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルの何れか又は全て、及び/又は、これら1つ又は複数のテーブルを示す情報と共に、1つ又は複数のインデクスセットを符号化データから抽出すること;
(ii)1つ又は複数のインデクスセットから、1つ又は複数のデータチャンクにおいて対応するシンボル、及び/又は、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルの何れか又は全てにおいてエントリの圧縮シンボルを計算すること;
(iii)前記シンボルから、1つ又は複数の符号テーブル、1つ又は複数のコードワード長テーブル、1つ又は複数の確率テーブルの何れか又は全てからの情報を用いて、1つ又は複数のデータチャンクを再生成すること;
(iv)復号データ(D3)を生成するために、1つ又は複数のデータチャンクを結合及び/又は変換すること
を実行するように動作可能である。
デコーダ60は更に、対応するトランスコードデータ(D4)を生成するために復号データ(D3)をトランスコードするトランスコーダ70、及び/又は、符号化データ(E2)からそれに対応するトランスコードデータ(D4)を生成することを含んでもよい。
デコーダ60は、1つ又は複数のテーブルの少なくとも1つが後で再利用できるように保存可能な仕方で、1つ又は複数のテーブルの少なくとも1つを受け取るように動作可能でもよい。
デコーダ60は、復号データ(D3)を生成するステップ(iv)において、1つ又は複数のデータ伸張アルゴリズムを適用するように動作可能でもよい。デコーダ60では更に、1つ又は複数のデータ伸張アルゴリズムは、ハフマン復号、VLC復号、エントロピー復号、算術復号、レンジ復号の少なくとも1つを含んでもよい。
デコーダ60は、復号データ(D3)を生成するために、1つ又は複数のデータチャンクのうち複数を実質的に同時に処理する並列プロセッサアーキテクチャを用いることによって、その複数のデータチャンクを結合するように動作可能でもよい。
デコーダ60は、一緒に結合された複数のデータ値に基づいて、1つ又は複数のインデクスセットを生成するように動作可能でもよい。デコーダ60では更に、このインデクスは、R、G、Bの画素値又はY、U、Vの画素値を含む1つ又は複数のRGB画素から算出されてもよい。デコーダ60は更に、データチャンクが符号化データ(E2)に含まれる場合、そのデータチャンクに対して達成可能なデータ伸長率に応じて、符号化データ(E2)における1つ又は複数のデータチャンクの非符号化生成又は符号化生成を動的に切り換えるように動作可能でもよい。
デコーダ60は、シンボルが符号化データ(E2)から、「符号テーブル変更」又は「データ終了」に関連するかを示す終了ビットを少なくとも1つ抽出するよう動作可能でもよい。
デコーダ60は、所定のデータチャンクに存在する1つ又は複数のシンボルを参照するために必要十分なインデクスから、実質的にその所定のデータチャンクを生成するように動作可能でもよい。
デコーダ60は、符号化データ(E2)に含まれる1つ又は複数の符号テーブルを伸張するように動作可能でもよい。デコーダ60は更に、ハフマン復号を用いて1つ又は複数の符号テーブルを伸張するように動作可能でもよい。デコーダ60では更に、1つ又は複数の符号テーブルの伸張は、1つ又は複数の補助符号テーブルを用いてもよい。
デコーダ60は、次の送信データを復号するために、1つ又は複数の符号テーブルをデコーダ(60)で使用可能にする仕方で1つ又は複数の符号テーブルを受け取るように動作可能でもよい。
デコーダ60は、1つ又は複数の符号テーブルがアクセスされ易い場所を示す1つ又は複数の識別コードを、1つ又は複数のデータベースと1つ又は複数のプロキシデータベースの何れか又は両方を介して、符号化データ(E2)から抽出するように動作可能でもよい。
デコーダ60は、次の種類のデータ:録音音声信号、録画ビデオ信号、静止画像、テキストデータ、感震データ、センサ信号データ、アナログ−デジタル変換(ADC)データ、生体信号データ、カレンダーデータ、経済データ、数学的データ、二進数データの1つ又は複数を復号するように動作可能でもよい。
デコーダ60は、複数のデータソースから符号化データ(E2)を受け取り、符号化データ(E2)を再生成するために、ソースから提供されたデータを結合するように動作可能でもよい。例えば、エンコーダ50からデコーダ60へ符号化データ(E2)を送るピアツーピアデータ通信ネットワークに複数のソースが含まれている。
前述した本発明の実施形態への修正は、添付の特許請求の範囲に定義される発明の範囲を逸脱しない限りにおいて可能である。本発明の記述と特許請求の範囲で用いられる「含む」,「備える」,「包含する」,「構成される」,「有する」,「存在する」等の表現は、包括的構成であると解釈されることを意図しており、明示的に記載されていないアイテムや部品,構成要素も含まれうることを意図している。単数表現もまた、複数に関連するものと解釈されるべきものである。添付の特許請求の範囲における括弧内の数字は、請求項の理解を助けることを意図したものであり、これらの請求項によって定義される発明の範囲を限定するように解釈されるべきではない。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB1403039.9 | 2014-02-20 | ||
GB1403039.9A GB2523348B (en) | 2014-02-20 | 2014-02-20 | Encoder, decoder and method |
PCT/EP2015/025008 WO2015124324A1 (en) | 2014-02-20 | 2015-02-20 | Methods and devices for source-coding and decoding of data involving symbol compression |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2017507590A JP2017507590A (ja) | 2017-03-16 |
JP2017507590A5 true JP2017507590A5 (ja) | 2017-06-22 |
JP6195997B2 JP6195997B2 (ja) | 2017-09-13 |
Family
ID=50482549
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016549759A Active JP6195997B2 (ja) | 2014-02-20 | 2015-02-20 | シンボル圧縮を伴うデータのソース符号化・復号方法及び装置 |
Country Status (8)
Country | Link |
---|---|
US (1) | US9729169B2 (ja) |
EP (1) | EP3108584B1 (ja) |
JP (1) | JP6195997B2 (ja) |
KR (1) | KR101737294B1 (ja) |
CN (1) | CN106170921B (ja) |
GB (1) | GB2523348B (ja) |
RU (1) | RU2682009C2 (ja) |
WO (1) | WO2015124324A1 (ja) |
Families Citing this family (58)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2539239B (en) | 2015-06-10 | 2017-10-04 | Gurulogic Microsystems Oy | Encoders, decoders and methods utilizing mode symbols |
GB2542707B (en) | 2015-07-03 | 2020-02-12 | Sisp Tech Ltd | Data processing method and apparatus |
US10063892B2 (en) * | 2015-12-10 | 2018-08-28 | Adobe Systems Incorporated | Residual entropy compression for cloud-based video applications |
US10264262B2 (en) * | 2016-02-29 | 2019-04-16 | Adobe Inc. | Codebook generation for cloud-based video applications |
JP6805580B2 (ja) * | 2016-06-30 | 2020-12-23 | 住友電気工業株式会社 | 通信機、通信システムおよび通信プログラム |
WO2018007809A1 (en) | 2016-07-04 | 2018-01-11 | Sisp Technologies Ltd | Data processing method and apparatus |
US10511858B2 (en) * | 2016-07-13 | 2019-12-17 | Ati Technologies Ulc | Bit packing for delta color compression |
US10601443B1 (en) * | 2016-08-24 | 2020-03-24 | Arrowhead Center, Inc. | Protocol for lightweight and provable secure communication for constrained devices |
US9712830B1 (en) * | 2016-09-15 | 2017-07-18 | Dropbox, Inc. | Techniques for image recompression |
KR101923161B1 (ko) * | 2017-01-11 | 2018-11-28 | 울산과학기술원 | 동기화 기반 인코딩을 이용한 데이터 송수신 장치 및 그 방법 |
US10361712B2 (en) * | 2017-03-14 | 2019-07-23 | International Business Machines Corporation | Non-binary context mixing compressor/decompressor |
US10897269B2 (en) | 2017-09-14 | 2021-01-19 | Apple Inc. | Hierarchical point cloud compression |
US10861196B2 (en) | 2017-09-14 | 2020-12-08 | Apple Inc. | Point cloud compression |
US11818401B2 (en) | 2017-09-14 | 2023-11-14 | Apple Inc. | Point cloud geometry compression using octrees and binary arithmetic encoding with adaptive look-up tables |
US10909725B2 (en) | 2017-09-18 | 2021-02-02 | Apple Inc. | Point cloud compression |
US11113845B2 (en) | 2017-09-18 | 2021-09-07 | Apple Inc. | Point cloud compression using non-cubic projections and masks |
US11120363B2 (en) | 2017-10-19 | 2021-09-14 | Adobe Inc. | Latency mitigation for encoding data |
US11086843B2 (en) | 2017-10-19 | 2021-08-10 | Adobe Inc. | Embedding codebooks for resource optimization |
US10942914B2 (en) | 2017-10-19 | 2021-03-09 | Adobe Inc. | Latency optimization for digital asset compression |
US10607373B2 (en) | 2017-11-22 | 2020-03-31 | Apple Inc. | Point cloud compression with closed-loop color conversion |
CN111684812B (zh) * | 2017-12-06 | 2023-12-22 | V-诺瓦国际有限公司 | 解码经编码二维数据流的方法及解码器 |
US11044495B1 (en) | 2018-02-13 | 2021-06-22 | Cyborg Inc. | Systems and methods for variable length codeword based data encoding and decoding using dynamic memory allocation |
US10593257B2 (en) * | 2018-03-15 | 2020-03-17 | Samsung Display Co., Ltd. | Stress profile compression |
US10909726B2 (en) | 2018-04-10 | 2021-02-02 | Apple Inc. | Point cloud compression |
US11010928B2 (en) | 2018-04-10 | 2021-05-18 | Apple Inc. | Adaptive distance based point cloud compression |
US10939129B2 (en) | 2018-04-10 | 2021-03-02 | Apple Inc. | Point cloud compression |
US10909727B2 (en) | 2018-04-10 | 2021-02-02 | Apple Inc. | Hierarchical point cloud compression with smoothing |
US11017566B1 (en) | 2018-07-02 | 2021-05-25 | Apple Inc. | Point cloud compression with adaptive filtering |
US11202098B2 (en) | 2018-07-05 | 2021-12-14 | Apple Inc. | Point cloud compression with multi-resolution video encoding |
US11012713B2 (en) | 2018-07-12 | 2021-05-18 | Apple Inc. | Bit stream structure for compressed point cloud data |
US11367224B2 (en) | 2018-10-02 | 2022-06-21 | Apple Inc. | Occupancy map block-to-patch information compression |
US10491240B1 (en) * | 2019-01-17 | 2019-11-26 | Cyborg Inc. | Systems and methods for variable length codeword based, hybrid data encoding and decoding using dynamic memory allocation |
US10687062B1 (en) * | 2019-02-22 | 2020-06-16 | Google Llc | Compression across multiple images |
WO2020194292A1 (en) | 2019-03-25 | 2020-10-01 | Ariel Scientific Innovations Ltd. | Systems and methods of data compression |
US11057564B2 (en) | 2019-03-28 | 2021-07-06 | Apple Inc. | Multiple layer flexure for supporting a moving image sensor |
US11711544B2 (en) | 2019-07-02 | 2023-07-25 | Apple Inc. | Point cloud compression with supplemental information messages |
US11627314B2 (en) | 2019-09-27 | 2023-04-11 | Apple Inc. | Video-based point cloud compression with non-normative smoothing |
US11562507B2 (en) | 2019-09-27 | 2023-01-24 | Apple Inc. | Point cloud compression using video encoding with time consistent patches |
WO2021063559A1 (en) * | 2019-09-30 | 2021-04-08 | Interdigital Vc Holdings France, Sas | Systems and methods for encoding a deep neural network |
US11398833B2 (en) | 2019-10-02 | 2022-07-26 | Apple Inc. | Low-latency encoding using a bypass sub-stream and an entropy encoded sub-stream |
US11538196B2 (en) | 2019-10-02 | 2022-12-27 | Apple Inc. | Predictive coding for point cloud compression |
US11895307B2 (en) | 2019-10-04 | 2024-02-06 | Apple Inc. | Block-based predictive coding for point cloud compression |
CN112866181B (zh) * | 2019-11-28 | 2023-05-26 | 上海商汤智能科技有限公司 | 数据解码装置、加速器、以及片上*** |
EP4082119A4 (en) * | 2019-12-23 | 2024-02-21 | Ariel Scientific Innovations Ltd. | DATA COMPRESSION SYSTEMS AND METHODS |
US11798196B2 (en) | 2020-01-08 | 2023-10-24 | Apple Inc. | Video-based point cloud compression with predicted patches |
US11625866B2 (en) | 2020-01-09 | 2023-04-11 | Apple Inc. | Geometry encoding using octrees and predictive trees |
US11373276B2 (en) * | 2020-01-09 | 2022-06-28 | Tencent America LLC | Techniques and apparatus for alphabet-partition coding of transform coefficients for point cloud compression |
US11615557B2 (en) | 2020-06-24 | 2023-03-28 | Apple Inc. | Point cloud compression using octrees with slicing |
US11620768B2 (en) | 2020-06-24 | 2023-04-04 | Apple Inc. | Point cloud geometry compression using octrees with multiple scan orders |
US11296720B2 (en) * | 2020-08-24 | 2022-04-05 | Innogrit Technologies Co., Ltd. | Data compression using reduced numbers of occurrences |
US11184023B1 (en) * | 2020-08-24 | 2021-11-23 | Innogrit Technologies Co., Ltd. | Hardware friendly data compression |
US11115049B1 (en) * | 2020-08-24 | 2021-09-07 | Innogrit Technologies Co., Ltd. | Hardware friendly data decompression |
CN112580297B (zh) * | 2020-12-28 | 2023-04-18 | 芯华章科技股份有限公司 | 一种编解码数据的方法、电子设备及存储介质 |
US11948338B1 (en) | 2021-03-29 | 2024-04-02 | Apple Inc. | 3D volumetric content encoding using 2D videos and simplified 3D meshes |
CN113242264B (zh) * | 2021-07-09 | 2021-09-24 | 中国人民解放军国防科技大学 | 一种对大容量数据进行压缩存储的方法和*** |
WO2023236128A1 (en) * | 2022-06-09 | 2023-12-14 | Huawei Technologies Co., Ltd. | Apparatus and methods for source coding and channel coding of low entropy signals |
US20240097703A1 (en) * | 2022-09-20 | 2024-03-21 | Hong Kong Applied Science and Technology Research Institute Company Limited | Hardware Implementation of Frequency Table Generation for Asymmetric-Numeral-System-Based Data Compression |
CN116582889B (zh) * | 2023-07-14 | 2023-11-21 | 武汉能钠智能装备技术股份有限公司四川省成都市分公司 | 一种高吞吐量数据传输及存储方法、电子设备及存储介质 |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5838266A (en) * | 1990-12-12 | 1998-11-17 | Universal Video Communications Corp. | Data processing apparatus and method using data compression |
JPH05241774A (ja) * | 1992-02-26 | 1993-09-21 | Seiko Epson Corp | 符号化器 |
BR9702155A (pt) * | 1996-03-15 | 1999-07-20 | Philips Electronics Nv | Processo de codificar blocos de sinais de informação e aparelho para formar blocos de sinal de informação codificados |
JPH09284568A (ja) * | 1996-04-16 | 1997-10-31 | Matsushita Electric Ind Co Ltd | 画像圧縮方法 |
JP3688064B2 (ja) * | 1996-08-06 | 2005-08-24 | 松下電器産業株式会社 | 画像圧縮方法及び画像圧縮装置 |
JP2001111843A (ja) * | 1999-10-06 | 2001-04-20 | Canon Inc | 画像読取装置、情報処理装置、画像読取システム及び情報処理方法 |
US6573847B1 (en) * | 2002-01-08 | 2003-06-03 | Intel Corporation | Multi-table mapping for huffman code decoding |
US7494563B2 (en) | 2002-10-07 | 2009-02-24 | Georgia-Pacific Consumer Products Lp | Fabric creped absorbent sheet with variable local basis weight |
US8599925B2 (en) * | 2005-08-12 | 2013-12-03 | Microsoft Corporation | Efficient coding and decoding of transform blocks |
TWI378654B (en) * | 2009-02-04 | 2012-12-01 | Novatek Microelectronics Corp | Adaptive canonical huffman decoder and method thereof and video decoder |
CN101808248B (zh) * | 2009-02-13 | 2012-01-11 | 联咏科技股份有限公司 | 可适应性范式哈夫曼解码器及其方法与图像解码器 |
CN101848387A (zh) * | 2010-03-19 | 2010-09-29 | 西安电子科技大学 | 基于jpeg2000标准的算术编码概率区间值确定方法 |
US20110249754A1 (en) * | 2010-04-12 | 2011-10-13 | Qualcomm Incorporated | Variable length coding of coded block pattern (cbp) in video compression |
US8755620B2 (en) * | 2011-01-12 | 2014-06-17 | Panasonic Corporation | Image coding method, image decoding method, image coding apparatus, image decoding apparatus, and image coding and decoding apparatus for performing arithmetic coding and/or arithmetic decoding |
US8933829B2 (en) * | 2013-09-23 | 2015-01-13 | International Business Machines Corporation | Data compression using dictionary encoding |
-
2014
- 2014-02-20 GB GB1403039.9A patent/GB2523348B/en active Active
-
2015
- 2015-02-20 US US15/119,365 patent/US9729169B2/en active Active
- 2015-02-20 JP JP2016549759A patent/JP6195997B2/ja active Active
- 2015-02-20 RU RU2016130092A patent/RU2682009C2/ru active
- 2015-02-20 CN CN201580009593.0A patent/CN106170921B/zh active Active
- 2015-02-20 WO PCT/EP2015/025008 patent/WO2015124324A1/en active Application Filing
- 2015-02-20 EP EP15705916.3A patent/EP3108584B1/en active Active
- 2015-02-20 KR KR1020167022772A patent/KR101737294B1/ko active IP Right Grant
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6195997B2 (ja) | シンボル圧縮を伴うデータのソース符号化・復号方法及び装置 | |
JP2017507590A5 (ja) | ||
TWI658702B (zh) | 資料編碼及解碼 | |
RU2417518C2 (ru) | Эффективное кодирование и декодирование блоков преобразования | |
US8810439B1 (en) | Encoder, decoder and method | |
JP6681383B2 (ja) | エンコーダ、デコーダ、および方法 | |
US8933826B2 (en) | Encoder apparatus, decoder apparatus and method | |
WO2016202470A1 (en) | Encoder, decoder and method employing palette utilization and compression | |
KR102393743B1 (ko) | 모드 심볼들을 사용하는 인코더, 디코더 및 방법 | |
WO2014131528A1 (en) | Encoder apparatus, decoder apparatus and method | |
GB2539486B (en) | Encoder, decoder and method employing palette compression | |
JP3781012B2 (ja) | 画像データ圧縮方法、画像データ伸長方法、および画像データ伸長回路 | |
GB2523744A (en) | Encoder apparatus, decoder apparatus and method |