(57)【要約】  本原理は、ピクチャブロックに属するピクチャデータに関連する構文要素を表すバイナリシンボルのシーケンスをコンテキスト適応型二進算術コード化／復号するための方法デバイスに関する。上記方法が、バイナリシンボルのシーケンスのうちの各バイナリシンボルに対し、ピクチャブロックのサイズ及びコード化予定のバイナリシンボルに従ってコンテキストを決定すること（１１０）と、上記決定されたコンテキストを考慮して上記バイナリシンボルを算術コード化／復号すること（１２０）とを含む方法において、上記コンテキストを決定すること（１１０）が、上記ピクチャブロックのサイズが２の累乗である際は、上記ピクチャブロックのサイズに従ってコンテキストを決定すること（９１０）と、上記ピクチャブロックのサイズが２の累乗ではない際は、上記ピクチャブロックのサイズのすぐ上の又は下のブロックサイズに従ってコンテキストを決定すること（９２０）であって、上記ブロックサイズが２の累乗に等しい、決定すること（９２０）とを含むことを特徴とする。
2019531026.tif 000002
【特許請求の範囲】
【請求項１】
ピクチャブロックに属するピクチャデータに関連する構文要素を表すバイナリシンボルのシーケンスをコンテキスト適応型二進算術コード化／復号するための方法であって、前記バイナリシンボルのシーケンスのうちの各バイナリシンボルに対し、
−  前記ピクチャブロックのサイズ及びコード化予定の前記バイナリシンボルに従ってコンテキストを決定すること（１１０）と、
−  前記決定されたコンテキストを考慮して前記バイナリシンボルを算術コード化／復号すること（１２０）と
を含む方法において、前記コンテキストを決定すること（１１０）が、
−  前記ピクチャブロックの前記サイズが２の累乗である際は、前記ピクチャブロックの前記サイズに従ってコンテキストを決定すること（９１０）と、
−  前記ピクチャブロックの前記サイズが２の累乗ではない際は、前記ピクチャブロックの前記サイズのすぐ上の又は下のブロックサイズに従ってコンテキストを決定すること（９２０）であって、前記ブロックサイズが２の累乗に等しい、決定すること（９２０）と
を含むことを特徴とする、方法。
【請求項２】
ピクチャブロックに属するピクチャデータに関連する構文要素を表すバイナリシンボルのシーケンスをコンテキスト適応型二進算術コード化／復号するためのデバイスであって、前記バイナリシンボルのシーケンスのうちの各バイナリシンボルに対し、
−  前記ピクチャブロックのサイズ及びコード化予定の前記バイナリシンボルに従ってコンテキストを決定するための手段と、
−  前記決定されたコンテキストを考慮して前記バイナリシンボルを算術コード化／復号するための手段と
を含むデバイスにおいて、前記コンテキストを決定することが、
−  前記ピクチャブロックの前記サイズが２の累乗である際は、前記ピクチャブロックの前記サイズに従ってコンテキストを決定することと、
−  前記ピクチャブロックの前記サイズが２の累乗ではない際は、前記ピクチャブロックの前記サイズのすぐ上の又は下のブロックサイズに従ってコンテキストを決定することであって、前記ブロックサイズが２の累乗に等しい、決定することと
を含むことを特徴とする、デバイス。
【請求項３】
ブロックサイズ又は前記ピクチャブロックの前記サイズが、前記ブロックの幅又は高さのいずれかである、請求項１に記載の方法又は請求項２に記載のデバイス。
【請求項４】
前記ピクチャブロックの前記サイズに従ってコンテキストを決定すること（１１０）が、
−  ２の累乗に等しい異なるピクチャブロックサイズに従って少なくとも１つのコンテキストセットを得ることであって、各コンテキストセットが、特定の２の累乗に等しいピクチャブロックサイズに対して得られる、得ることと、
−  画像ブロックの前記サイズが２の累乗かどうかチェックすることと、
−  前記ピクチャブロックの前記サイズが２の累乗である場合は、前記ピクチャブロックの前記サイズに従って、前記得られた少なくとも１つのコンテキストセットの中からコンテキストセットを選択することと、
−  そうでない場合は、前記画像ブロックの前記サイズのすぐ上の又は下のブロックサイズに従って、前記得られた少なくとも１つのコンテキストセットの中からコンテキストセットを選択することであって、前記ブロックサイズが２の累乗に等しい、選択することと、
−  前記バイナリシンボルのシーケンスのうちの前記バイナリシンボルのインデックスに従って、前記選択されたコンテキストセットの中からコンテキストを決定することと
を含む、請求項１若しくは３に記載の方法又は請求項２若しくは３に記載のデバイス。
【請求項５】
前記ピクチャブロックが走査順番に従って走査される際、ピクチャデータに関連する前記構文要素が、前記ピクチャブロックに属する最終有意係数の空間座標のうちの１つを表し、前記方法又は前記デバイスが、
−  前記最終有意係数の前記空間座標のうちの１つが属する少なくとも１つの区間インデックスのセットの中から、整数値の区間を識別する区間インデックスを選択するためのステップ又は手段、
−  前記選択された区間インデックスを二進化することによって前記バイナリシンボルのシーケンスを得るためのステップ又は手段（１００）
のそれぞれをさらに含み、
−  前記バイナリシンボルのシーケンスの各ビンがコード化される（１１０、９１０、９２０）、請求項４に記載の方法又はデバイス。
【請求項６】
前記方法が、前記最終有意係数の前記空間座標のうちの１つが前記区間インデックス及び前記オフセット値によって表されるロスレスであるように、前記選択された区間内のオフセット値を得ることをさらに含む、請求項５に記載の方法又はデバイス。
【請求項７】
前記ピクチャブロックが、少なくとも２つのピクチャサブブロックに分割され、ピクチャデータに関連する前記構文要素が、前記少なくとも２つのピクチャサブブロックのうちの１つの係数に関する有意係数フラグを表し、前記コンテキストを決定すること（１１０）が、
−  画像ブロックの前記サイズが２の累乗かどうかチェックすることと、
−  前記ピクチャブロックの前記サイズが２の累乗である場合は、前記ピクチャブロックの前記サイズに従って、ベースコンテキストインデックスを決定することと、
−  そうでない場合は、前記ピクチャブロックの前記サイズのすぐ上の又は下のブロックエリアサイズに従って、ベースコンテキストインデックスを決定することであって、前記ブロックエリアサイズが２の累乗に等しい、決定することと
を含み、
−  前記コンテキストインデックスが、前記ベースコンテキストインデックスを、近隣の係数の有意変換係数フラグから得られたコンテキスト増分に加えることによって決定される、請求項１若しくは３に記載の方法又は請求項２若しくは３に記載のデバイス。
【請求項８】
前記ピクチャブロック又はサブブロックの前記サイズが、前記ピクチャブロック又はサブブロックの幅及び／又は高さであり、前記方法が、２の累乗による整数値の積に等しいその高さ及び／又はその幅を有するピクチャブロック又はサブブロックを得ることであって、前記積が２の累乗ではない、得ることをさらに含む、請求項１、３〜７の何れか一項に記載の方法又は請求項２〜７の何れか一項に記載のデバイス。
【請求項９】
画像ブロックを得ることが、親ブロックを、２の累乗による前記整数値の積に等しいその高さ及び／又はその幅を有する２つのサブブロックに分割することを含む、請求項７に記載の方法又はデバイス。
【請求項１０】
請求項１、２〜９の何れか一項に記載の方法の命令に従って符号化されたピクチャデータに関連する構文要素を表すバイナリシンボルのシーケンスを有する非一時的な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
１．分野
本原理は、概して、ピクチャ／映像符号化に関する。具体的には、本原理の技術分野は、上記ピクチャデータの復号に必要な構文要素を表すバイナリシンボルのシーケンスのコンテキスト適応型二進算術コード化に関する。
【背景技術】
【０００２】
２．背景
本項目は、以下で説明及び／又は特許請求される本原理の様々な態様に関連し得る当技術分野の様々な態様を読者に紹介することを意図する。この論考は、本原理の様々な態様をより理解し易くするために背景情報を読者に提供する際に役立つと考えられている。それに従って、これらの説明は、これを踏まえて読み進めるべきであり、先行技術を容認するものとして読み進めるべきではないことを理解すべきである。
【０００３】
以下では、ピクチャデータは、例えば、ピクチャの画素値に関するすべての情報や、ピクチャを視覚化及び／又は復号するためのディスプレイ及び／又は他の任意のデバイスによって使用することができるすべての情報を指定する特定の映像フォーマットの１つ又はいくつかのサンプルアレイ（画素値）を含む。静止ピクチャ（又は映像のピクチャ）は、第１のサンプルアレイの形状の少なくとも１つの成分（通常、ルマ（又は輝度）成分）を含み、場合により、少なくとも１つの他のサンプルアレイの形状の少なくとも１つの他の成分（通常、色成分）を含む。或いは、同等に、同じ情報は、従来の３色ＲＧＢ表現など、１組のカラーサンプルアレイによって表すこともできる。
【０００４】
画素値は、Ｃ値のベクトルによって表すことができるピクチャデータであり、Ｃは、成分の数である。ベクトルの各値は、ビット数で表され、ビット数は、画素値の最大ダイナミックレンジを定義する。
【０００５】
一般的に言えば、ピクチャブロックは、ピクチャデータの要素又はピクチャデータに関する構文要素のセットを表す。例えば、ピクチャブロックは、ピクチャに属する画素のセットである。
【０００６】
映像コード化デバイスは、空間及び時間冗長性を利用することによってピクチャデータを圧縮することを試みることができる。例えば、映像エンコーダは、近隣のブロック（以前にコード化済みのブロック）に関してピクチャブロックをコード化することによって、空間冗長性を利用することができる。同様に、映像エンコーダは、以前にコード化済みのピクチャのデータに関してピクチャブロックをコード化することによって、時間冗長性を利用することができる。具体的には、映像エンコーダは、空間的な近隣のブロックのデータから又は以前にコード化済みのピクチャのデータから現在のピクチャブロックを予測することができる。次いで、映像エンコーダは、ピクチャブロックに対する実際の画素値とピクチャブロックに対する予測画素値との差として、ピクチャブロックに対する残差を計算することができる。それに従って、ピクチャブロックに対する残差は、画素（又は空間）領域におけるそれぞれの画素の差の値を含み得る。
【０００７】
次いで、映像エンコーダは、周波数領域における比較的小さな数値の変換済み係数への画素値のエネルギーの圧縮を行うための変換を残差の値に適用することができる。次いで、映像エンコーダは、変換済み係数を量子化し、量子化された変換済み係数を走査し、量子化された変換済み係数の二次元行列を、量子化された変換済み係数を含む一次元ベクトルに変換することができる。次いで、映像エンコーダは、走査済み係数をエントロピー符号化するためにエントロピーコード化プロセスを適用することができる。例示的なエントロピーコード化プロセスは、例えば、コンテキスト適応型可変長コード化（ＣＡＶＬＣ）、コンテキスト適応型二進算術コード化（ＣＡＢＡＣ）、構文ベースコンテキスト適応型二進算術コード化（ＳＢＡＣ）、確率区間区分エントロピー（ＰＩＰＥ）コード化又は他のエントロピー符号化方法を含み得る。
【０００８】
映像デコーダは、映像エンコーダによって実行される符号化技法とは一般的には逆の技法を実行することができる。一般的には逆であるが、映像デコーダは、いくつかの例では、映像エンコーダによって実行されるものと同様の技法を実行することができる。
【０００９】
また、映像エンコーダは、ピクチャデータの復号において映像デコーダによって使用するために、符号化済みのピクチャデータと関連付けられた構文要素をエントロピー符号化することができる。次いで、映像デコーダは、受信されたビットストリームに含まれる構文要素又は他のデータ（映像エンコーダに関して説明されたデータを含む）に依存することができる。
【００１０】
構文要素のいくつかの例によれば、「最終有意係数座標」は、ピクチャブロックと関連付けられた走査順番によるピクチャブロックにおける最終非ゼロ係数の空間位置をデコーダに提供する構文要素である。次いで、ピクチャブロックにおける最終有意係数のｘ座標をデコーダに提供するために、「最終有意係数ｘ座標」構文要素を符号化し、ピクチャブロックにおける最終有意係数のｙ座標をデコーダに提供するために、「最終有意係数ｙ座標」構文要素を符号化することができる。「有意係数フラグ」は、ピクチャブロックにおける量子化された変換済み係数がゼロに等しいか否かを示す別の構文要素である。
【００１１】
量子化された変換済み係数のレベルをエントロピーコード化する場合、映像コーダは、量子化された変換済み係数の各々のレベルをエントロピーコード化することができる。例えば、映像コーダは、非ゼロの量子化された変換済み係数の各々の絶対値を二進形式に変換することができる。このように、非ゼロの変換済み係数の各々は、例えば、１つ又は複数のビット又は「ビン」を含む単項コードを使用して、「二進化」することができる。また、量子化された変換済み係数の符号に対するビットも符号化することができる。
【００１２】
それに加えて、映像デコーダがピクチャデータを復号できるようにするために、多くの他の構文要素を含めることができる。例えば、Ｈ．２６４／ＭＰＥＧ−４  ＡＶＣ（“Advanced video coding for generic audiovisual Services”, SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS, Recommendation ITU-T H.264, Telecommunication Standardization Sector of ITU, February 2014）及び高効率映像コード化（ＨＥＶＣ）規格（ITU-T H.265 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (10/2014), SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS, Infrastructure of audiovisual services - Coding of moving video, High efficiency video coding, Recommendation ITU-T H.265）で説明されるように、構文要素は、動きベクトル残差、変換単位コード化フラグ、コード化グループコード化フラグ、量子化された変換済み係数の大きさ（１より大きい及び２より大きい）フラグ、ＳＡＯデータなどを表し得る。
【００１３】
映像コーダは、ピクチャブロックに対する量子化された変換済み係数又は構文要素（情報）に対応するかどうかにかかわらず、各バイナリシンボルに対する確率推定を使用して、ピクチャデータのブロックに対する各バイナリシンボル（又はビン）をエントロピーコード化することができる。確率推定は、所定の二進値（例えば、「０」又は「１」）を有するバイナリシンボルの尤度を示し得る。確率推定は、「コンテキスト」とも呼ばれる確率モデル内に含めることができる。次いで、映像コーダは、コード化予定のバイナリシンボルに対するコンテキスト（確率モデルを含む）を決定することができる。
【００１４】
構文要素を表すバイナリシンボルのシーケンスのうちのバイナリシンボルに対するコンテキストは、以前にコード化済みの近隣の構文要素の関連バイナリシンボルの値を含み得る。コンテキストは、コンテキストセットに属する場合があり、その場合、コンテキストは、上記コンテキストセット内の上記コンテキストを識別するコンテキストインデックスから得られる。
【００１５】
一例として、ピクチャブロックに属する量子化された変換済み係数に関する有意係数フラグに対するコンテキストは、上記ピクチャブロックのタイプ（例えば、ピクチャブロックサイズ、ルム又はクロマ要素）及びピクチャブロックと関連付けられた走査順番によるピクチャブロック内の上記量子化された変換済み係数の空間位置を含む。
【００１６】
別の例として、ピクチャブロックに対する二進化された残差変換係数の絶対値のバイナリシンボルに対するコンテキストは、絶対値を表す単項コードワード内のバイナリシンボルの空間位置及びピクチャブロックの以前にコード化済みの係数の値を含む。
【００１７】
他の例では、コード化済みブロックパターン（「ＣＢＰ」）を表すバイナリシンボルのシーケンスのうちのバイナリシンボルに対するコンテキストは、以前にコード化済みの近隣の構文要素（例えば、現在の構文要素の上側及び左側のもの）の関連バイナリシンボルの値を含む。
【００１８】
本原理は、上記の例に限定されず、例えば、Ｈ．２６４／ＭＰＥＧ−４  ＡＶＣ及び高効率映像コード化（ＨＥＶＣ）規格で定義されるものなどの任意の構文要素及びコンテキストまで拡張される。
【００１９】
いかなる事例においても、各コンテキストに対して異なる確率モデルが定義される。
【００２０】
バイナリシンボルをエントロピーコード化した後、最新の確率推定を反映させるために、コード化済みのバイナリシンボルの値に従って確率モデルを更新することができる。
【００２１】
ピクチャブロックと関連付けられたバイナリシンボルは、１つ又は複数のコード化「パス」においてコード化することができる。例えば、第１のパスの間、映像コーダは、有意係数フラグ及び最終有意係数座標をエントロピーコード化することができる。第２のパスの間、映像コーダは、量子化された変換済み係数レベルの第１のビンをエントロピーコード化することができる。映像コーダは、ピクチャブロックの量子化された変換済み係数と関連付けられたすべての情報がコード化されるまで、コード化パスの実行を続けることができる。
【００２２】
いくつかの例では、映像コーダは、コンテキスト適応型及び非コンテキスト適応型コード化の組合せを使用して、ピクチャブロックのビンをコード化することができる。例えば、１つ又は複数のパスに対し、映像コーダは、通常の算術コード化プロセスを迂回するか又は省略するためにバイパスモードを使用することができる。そのような例では、バイパスコード化済みのビンをコード化するために、固定等確率モデルを使用することができる。バイパスコード化済みのビンは、コンテキスト又は確率更新を含まない。
【００２３】
コンテキスト適応型コード化を実行する際、いくつかの例では、複数のフィードバックループに起因する比較的高い連続依存性が存在し得る。
【００２４】
例えば、バイナリシンボルをコード化するための特定の確率モデルを示すコンテキストは、以前にコード化済みのバイナリシンボル（例えば、以前にコード化済みの構文要素の関連バイナリシンボル）の値による影響を受ける場合がある。
【００２５】
それに加えて、バイナリシンボルをコード化するために使用される確率モデルは、以前にコード化済みのバイナリシンボルの値による影響を受ける場合もある。すなわち、確率モデルは、有限状態機械の状態として維持することができる。特定の状態の各々は、特有の確率値に相当し得る。確率モデルの更新に相当する次の状態は、現在のバイナリシンボル（例えば、現在コード化されているビン）の値に依存し得る。
【００２６】
それに加えて、上記で記述されるように、特定の確率モデルは、有限状態機械の状態として維持することができ、特定の状態の各々は、特有の確率値に相当し得る。確率モデルの更新に相当する次の状態は、現在のバイナリシンボルの値に依存し得る。状態更新と呼ぶことができるそのようなフィードバックループは、演算上のボトルネックを提示し得る。例えば、フィードバックループにおける依存性が原因で、スループットの増大が難しい場合がある。すなわち、あるバイナリシンボルは、以前のバイナリシンボルからの確率モデルが更新されるまで処理されない場合がある。いくつかの例では、同じコンテキストを高い頻度で連続的に（バイナリシンボルごとに）呼び出すことができる。
【００２７】
コンテキスト適応型二進算術コード化（ＣＡＢＡＣ）は、Ｈ．２６４／ＭＰＥＧ−４及びＨＥＶＣで使用されるエントロピー符号化の形態である。
【００２８】
ＣＡＢＡＣは、ロスレス圧縮技法であるが、ＣＡＢＡＣが使用される映像コード化規格は、典型的には、ロッシー圧縮用途のためのものである。
【発明の概要】
【００２９】
図１は、ＣＡＢＡＣで構文要素を符号化するための一般的なブロック図を示す。
【００３０】
基本的には、ＣＡＢＡＣは、３つの基本的なステップを含む。
【００３１】
ステップ１００では、バイナライザは、所定の非二進値構文要素をバイナリシンボルのシーケンス（ビンストリング）にマッピングする。二進値構文要素が与えられている際は、この初期のステップは、図１に示されるように、迂回される。
【００３２】
ビンストリングの現在のビンの各々に対し又は二進値構文要素の各々に対し、コード化モードに応じて、１つ又は複数の後続のステップが続く場合がある。
【００３３】
いわゆる通常のコード化モードでは、コンテキストモデル化ステップ１１０に続いて、通常のコード化ステップ１２０が行われる。
【００３４】
コンテキストモデル化ステップ１１０では、コンテキストモデラは、コード化予定のビン（通常、いくつかのコンテキストモデルのセットの中からコンテキストモデルを識別するコンテキストインデックス）に従ってコンテキストモデルを選択し、現在のビンがコード化されている時に、同期的にエンコーダ側とデコーダ側の両方で利用可能なコンテキスト情報（以前に符号化済みの構文要素又はコード化済みのバイナリシンボルなど）を考慮して、上記選択されたコンテキストモデルからコンテキストを決定する。次いで、決定されたコンテキストは、現在のビンが特有の値（例えば、「０」）を有する条件付き確率を得るために使用される。
【００３５】
次いで、通常のコード化ステップ１２０では、決定されたコンテキスト（条件付き確率）及び現在のビンの値ｓ（図１のビン値）は、上記決定されたコンテキストを考慮して現在のビンを算術コード化するエンジンに送られる。こうして、現在のビンのコード化済みの値が得られ、コンテキスト情報を更新するために使用される。これが、図１のコンテキストモデル更新フィードバックループである。コンテキスト情報を更新することは、ビンがコード化されている限り、各ビンに対してコンテキストを更新し、従って、ビンストリングの各ビンに対するコンテキストモデル化を徐々に改善できるようにすることを伴う。従って、ＣＡＢＡＣエンコーダは、通常の符号化済みのビンの各々の統計的挙動を徐々に学習する。
【００３６】
通常の符号化済みのビット（通常のコード化ステップ１２０の出力）は、出力ビットストリームに追加される。
【００３７】
或いは、いわゆるバイパスコード化モードは、図１のスイッチの右下のブランチによって示されるように、明示的に割り当てられた確率モデルを使用することなく、簡略化されたコード化エンジンによって符号化（及び復号）プロセス全体を加速させるようにビンをコード化するために選ばれる。バイパスモードは、単に、出力ビットストリームにビットを書き込み、そのように得られたビット値を現在のビンに割り当てるものである。このコード化モードは、単刀直入であり、従って、速いという利点を有する。このコード化モードは、典型的には効率的であり、従って、均一な統計的分布を有する（すなわち、「１」又は「０」に等しくなる確率が等しい）ビンに使用される。
【００３８】
図２は、バイナリシンボルのシーケンスがピクチャブロックに関する有意係数フラグを表す際のＣＡＢＡＣコード化の例を示す。
【００３９】
本原理は構文要素を表すバイナリシンボルのいかなるシーケンスにも適用されるため、これは、非限定的な例である。
【００４０】
図２の例では、有意係数フラグ（フラグは、ピクチャブロックの量子化された変換済み係数の各々と関連付けることができる）のブロックを表すピクチャブロック（ここでは、バイナリシンボルの）が表されている。量子化された変換済み係数が０に等しい場合は、このフラグは０に等しく、そうでない場合は、１に等しい）。このピクチャブロックは、特有の走査順番に従って走査される。例えば、点線によって示される走査順番は、ピクチャブロックの右下隅から始まり、ピクチャブロックの左上隅へと進む。バイナリシンボルｓをコード化すると想定すると、上記走査順番に従って、バイナリシンボルｓに対して以前にいくつかの候補コンテキストＣｉが定義され、各コンテキストＣｉは、候補コンテキストセットの中からコンテキストＣｉを識別したContValiというコンテキストインデックスと関連付けられる。
【００４１】
例えば、バイナリシンボルｓに対して、２つの以前にコード化済みの構文要素ｘ１及びｘ２（有意係数フラグ）から４つの候補コンテキストＣｉ（ｉ＝１、…４）が定義される。各コンテキストＣｉは、ｘ１及びｘ２の二進値に従って定義され、ContValiという特有のコンテキストインデックスは、コンテキストの各々に割り当てられる。
【００４２】
例として、図３に示されるように、コンテキストインデックスは、バイナリシンボルｓの特有の二進値を表すvalMPS（いわゆる、優勢確率シンボル（ＭＰＳ））というビットと、確率ｐを推測する対象となる確率ｐ’（又は状態）を表すpStateIdxというビット（例えば、７ビット）とを含む。
【００４３】
例によれば、コンテキストモデル化ステップ１１０では、ｘ１及びｘ２の値に従って、４つの候補コンテキストからコンテキストＣｓが選択され、ContValsという関連コンテキストインデックスがバイナリシンボルｓに割り当てられる。
【００４４】
通常のコード化段階１２０では、ContValsというインデックスを有する選択されたコンテキストのコンテキストモデルの更新は、図４に示されるプロセスに従って、バイナリシンボルｓがＭＰＳに等しいか否かに応じて行われる。
【００４５】
transIdxMPS（バイナリシンボルｓがＭＰＳである場合）及びtransIdxLPS（バイナリシンボルｓがＭＰＳではない場合、すなわち、劣勢確率シンボル（ＬＰＳ）である場合）の２つの表を通じてエボリューションが行われる。これらの表は、図５においてpStateIdxというエントリに対して提供されている。
【００４６】
この例に従い、バイナリシンボルｓがＭＰＳである確率ｐＭＰＳは、０から１２７まで、８ビットで線形量子化される。それは、
pMPS=(p’+64)/127=(pStateIdx+64)/127
によって、選択されたコンテキストインデックスから推測され、シンボルｓが１である確率ｐは、ＭＰＳの値に応じてｐＭＰＳから明白に推測される。
ＭＰＳ＝１の場合  p=pMPS
ＭＰＳ＝０の場合  p=1-pMPS
【００４７】
コンテキスト適応型コード化は、符号化済みのピクチャデータに関する異なる構文要素の統計に動的に従えるようにする強力なツールである。
【００４８】
従って、ピクチャデータ及び／又はピクチャデータに関する構文要素のエントロピーコード化のためのＣＡＢＡＣの使用により、それらの統計をモデル化するために、ＨＥＶＣ／Ｈ２６５の多くのコンテキスト（最大で数百）が広範囲にわたって使用されるようになった。
【００４９】
コンテキストインデックスを選択することは、多くの物事に依存し、従って、構文要素の統計を捕らえるために莫大な数のコンテキストを使用することはよくあることであり、従って、ＣＡＢＡＣの性能が最適化される。しかし、バイナリシンボルの１つ又は複数のシーケンスのすべてのバイナリシンボルを符号化するため、コンテキストはメモリに格納されるものであるため、コンテキストの数の増加は、メモリ及び処理の複雑性の観点から要件を増加する。それが、構文要素を符号化するためにＣＡＢＡＣを実装する映像デコーダの効率的なハードウェア実現可能性を保証するためにコンテキストの数の制限が重要である理由である。
【００５０】
従って、課題の１つは、コンテキストの数をそれほど増加することなく、ＣＡＢＡＣによって提供される圧縮能力を増大することで利益を得ることである。
【００５１】
図６は、図１の方法に従ってコード化されたビットを含む入力ビットストリームに与えられた構文要素のＣＡＢＡＣ復号を描写する一般的なブロック図を示す。入力ビットストリームは、ＨＥＶＣ仕様に準拠し得る。
【００５２】
復号の何れの時点においても、どの構文要素を次に復号すべきかをデコーダは知っていることが想定される。このことは、標準化されたビットストリーム構文及び復号プロセスにおいて完全に指定されている。その上、復号予定の現在の構文要素がどのように二進化されるか（すなわち、ビンストリングとして表され、各ビンは、「１」又は「０」に等しい）及び、各ビンを符号化するために使用されたコード化モードは何か（通常のコード化又はバイパスモード）も想定される。
【００５３】
これらの情報は、考慮される映像圧縮規格Ｈ．２６４又はＨＥＶＣにおいて完全に指定されている。
【００５４】
従って、ステップ６００では、パーサは、入力ビットストリームからコード化済みのビットを復号する（構文解析する）ことによって、一連のビットを得る。
【００５５】
復号予定の現在のコード化済みのビンの各々に対し、上記現在のコード化済みのビンをコード化するために使用されたコード化モードに応じて、１つ又は複数の後続のステップが続く場合がある。
【００５６】
現在のコード化済みのビンをコード化するためにバイパスコード化モードが使用された際は、バイパス復号ステップ６１０では、現在のコード化済みのビンの値は、現在のコード化済みのビンの復号済みの値である。
【００５７】
現在のコード化済みのビンをコード化するために通常のコード化モードが使用された際は、コンテキストモデル化ステップ１１０の後に通常の復号ステップ６２０が続く。
【００５８】
図１及び６のコンテキストモデル化ステップは、厳密には同じであり、図６の通常の復号ステップ６２０は、図１の通常のコード化ステップ１１０とかなり似ている。
【００５９】
通常の復号ステップ６２０では、現在のコード化済みのビンの復号済みの値は、コンテキストモデル化ステップ１１０によって与えられたコンテキストから得られる。上記コンテキスト（条件付き確率）及び現在のビットの値は、上記コンテキストを考慮して現在のビンを算術復号するエンジンに送られる。こうして、現在のビンの復号済みの値が得られ、コンテキスト情報を更新するために使用される。これが、図６のコンテキストモデル更新フィードバックループである。コンテキスト情報を更新することは、ビンが復号されている限り、各ビンに対してコンテキストを更新し、従って、各ビンに対するコンテキストモデル化を徐々に改善できるようにすることを伴う。従って、ＣＡＢＡＣデコーダは、現在のビンのオリジナルの値に等しい現在のコード化済みのビンの復号済みの値を徐々に得る（ロスレス圧縮）。
【００６０】
現在のビンの復号済みの値（バイパス復号ステップ６１０又は通常の復号ステップ６２０の出力）が得られる際、現在のビンの復号済みの値は、二進値構文要素又は非二進値構文要素に関するものである。これは、考慮される映像圧縮規格Ｈ．２６４又はＨＥＶＣによって指定することができる。次に、現在のビンの復号済みの値が二進値構文要素に関する場合は、ＣＡＢＡＣ復号は終了し、現在のビンの復号済みの値が非二進値構文要素に関する場合は、デコーダは、ビンの復号済みの値（ステップ６２０又は６１０の出力ビンストリング）から構文要素をどのように構築するかを知っている。
【００６１】
次いで、ステップ６３０では、変換器は、二進化（ステップ１００）とは逆のプロセスを適用することによって、上記出力ビンストリングを非二進値構文要素に変換する。
【００６２】
映像圧縮では、ピクチャ全体を単一のピクチャブロックとして符号化することは最適ではなく、コード化木の各葉を符号化する前にピクチャ全体をサブブロックに再帰的に分割することでコード化効率が増大することはよく知られている。
【００６３】
例えば、ＨＥＶＣ規格では、符号化予定のピクチャは、典型的には正方形の形状（６４×６４、１２８×１２８又は２５６×２５６画素）を有するコード化木単位（ＣＴＵ）に分割される。各ＣＴＵは、圧縮領域においてコード化木によって表される。コード化木は、ＣＴＵの再帰的分割を説明する。コード化木の各葉（コード化単位）は、四分木分割が使用される場合は、正方形の形状を有するが、葉のいくつかは、四分木プラス二分木（ＱＴＢＴ：Quad-tree Plus Binary Tree）分解が使用される際は、長方形の形状も有し得る。より正確に言えば、ＣＴＵのＱＴＢＴ分解は、二段階で構成される（最初に、ＣＴＵが四分木形式で分割され、次いで、各四分木葉を二進形式でさらに分割することができる）。このことは、図７の右側に示されており、実線は四分木分解相を表し、破線は四分木葉に空間的に埋め込まれた二進分解を表す。コード化単位の分割は、エンコーダ側でレート歪み最適化手順を通じて決定され、レート歪み最適化手順は、最小レート歪みコストでＣＴＵのＱＴＢＴ表現を決定するものである。
【００６４】
ＨＥＶＣ規格では、コード化単位のサイズ（すなわち、幅及び高さ）は常に２の累乗であり、典型的には４〜１２８である。
【００６５】
本発明人は、コード化木がピクチャの空間構造とよりうまく整合し、それにより、より均質的なコンテンツがコード化単位に提供されるため、ＱＴＢＴ分解における非対称分割モードを可能にすることにより、コード化効率が増大されることを見出した。
【００６６】
非対称分割モードは、整数値ｍの倍数に等しいサイズ（幅及び／又は高さ）のコード化単位を、ｍ・２ｎに等しいサイズ（幅及び／又は高さ）の２つのサブコード化単位に分割するものであり、ｎは、整数値であり、ｍは、ｍ・２ｎが２の累乗に等しくならないように選ばれた整数値である。
【００６７】
図８は、ｍが３に等しい際の４つの非対称分割モードの例を示す。それらの例は、単なる例示のために与えられており、５、７、．．．などの他のｍの値まで拡張することができる。ｍの倍数に等しいサイズ（幅ｗ及び／又は高さｈ）のコード化単位の符号化において非対称分割モードを導入することにより、上記非対称分割モードのうちの１つを通じて上記コード化単位を分割することができる。例えば、図８の非対称分割モードＨＯＲ＿ＵＰ（水平上側）に従って３の倍数に等しい幅ｗ及び高さｈのコード化単位を分割することにより、それぞれの長方形のサイズ
【数１】
2019531026.tif 000003
の２つのサブコード化単位がもたらされることになる。
【００６８】
非対称分割モードが使用される際は、いくつかのコード化単位は、ｍ・２ｎに等しいその幅及び／又はその高さを有する。次いで、２の累乗に等しいサイズのコード化単位の符号化用に最初に設計された通常のＨＥＶＣツールを、２の累乗に等しくないコード化単位のこれらの新しいサイズに適応させる必要がある。
【００６９】
本原理によって解決される問題の１つは、コード化設計の最小複雑性増大と共に良い圧縮効率（レート歪み性能）を提供するように、非対称コード化単位に含まれる量子化された変換済み係数をどのように効率的にエントロピー符号化／復号するかである。言い換えれば、課題の１つは、ＨＥＶＣエントロピー符号化（ＣＡＢＡＣ）によって使用されるコンテキストの数を増加することなく、非対称分割モードを使用することによって提供される圧縮能力の増大から利益を得ることである。
【００７０】
３．概要
以下は、本原理のいくつかの態様の基本的な理解を提供するために、本原理の簡単な概要を提示する。この概要は、本原理の広範な要約ではない。本原理の重要な又は必須の要素を特定することは意図しない。
【００７１】
以下の概要は、単に、以下で提供されるより詳細な説明の前置きとして、簡略化された形態で、本原理のいくつかの態様を提示する。
【００７２】
本原理は、ピクチャブロックに属するピクチャデータに関連する構文要素を表すバイナリシンボルのシーケンスをコンテキスト適応型二進算術コード化／復号するための方法を用いて、先行技術の欠点の少なくとも１つを改善することを目指す。上記方法は、バイナリシンボルのシーケンスのうちの各バイナリシンボルに対し、
−  ピクチャブロックのサイズ及びコード化予定のバイナリシンボルに従ってコンテキストを決定することと、
−  上記決定されたコンテキストを考慮して上記バイナリシンボルを算術コード化／復号することと
を含み、上記コンテキストを決定することが、
−  上記ピクチャブロックのサイズが２の累乗である際は、上記ピクチャブロックのサイズに従ってコンテキストを決定することと、
−  上記ピクチャブロックのサイズが２の累乗ではない際は、上記ピクチャブロックのサイズのすぐ上の又は下のブロックサイズに従ってコンテキストを決定することであって、上記ブロックサイズが２の累乗に等しい、決定することと
を含むことを特徴とする。
【００７３】
それらの態様の他の態様によれば、本原理は、上記の方法のステップを実行するためのデバイスと、このプログラムがコンピュータ上で実行される際に上記の方法のステップを実行するためのプログラムコード命令を含むコンピュータプログラム製品と、上記プログラムがコンピューティングデバイス上で実行される際に上記の方法のステップを実行するためのプログラムコードの命令を保持する非一時的な記憶媒体とに関する。
【００７４】
本原理の具体的な本質並びに本原理の他の目的、利点、特徴及び使用は、添付の図面と併せて取り入れられる例の以下の説明から明らかになるであろう。
【００７５】
４．図面の簡単な説明
図面では、本原理の例を示す。
【図面の簡単な説明】
【００７６】
【図１】ＣＡＢＡＣを使用して構文要素を符号化するための一般的なブロック図を示す。
【図２】バイナリシンボルのシーケンスが映像データのブロックに関する有意性マップを表す際のコンテキスト選択段階の例を示す。
【図３】コンテキストインデックスの例を示す。
【図４】コンテキストインデックスを更新するための一般的なブロック図を示す。
【図５】コンテキストインデックス更新に通常使用される周知の表を示す。
【図６】本原理の例による、バイナリシンボルのシーケンスのうちのバイナリシンボルｓをコンテキスト適応型二進算術復号するための方法を示す。
【図７】バイナリシンボルｓが、例えば、映像データのブロックに関する有意性マップの有意性フラグを表す際の、図６の方法の実施形態の例を示す。
【図８】ｍが３に等しい際の４つの非対称分割モードの例を示す。
【図９】本原理の例による、ピクチャブロックのサイズによるバイナリシンボルに対するいくつかのコンテキストのセットの中からのコンテキストの選択（ステップ１１０）を示すブロック図を示す。
【図１０】８×８  ＴＢの走査順番の例を示す。
【図１１】「最終有意係数座標」構文要素の二進化のために使用される表を示す。
【図１２】異なるＴＢサイズに従ってコンテキストインデックスのセットを与える表の例を示す。
【図１３】異なるＴＢサイズに従ってコンテキストインデックスのセットを与える表の例を示す。
【図１４】本原理の実施形態による、ctxIncrementというコンテキスト増分を演算する例を示す。
【図１５】本原理の例による、デバイスのアーキテクチャの例を示す。
【発明を実施するための形態】
【００７７】
同様の又は同じ要素は、同じ参照番号で参照される。
【００７８】
５．本原理の例の説明
本原理は、本原理の例が示される添付の図を参照して、以下でより完全に説明する。しかし、本原理は、多くの代替の形態で具体化することができ、本明細書に記載される例に限定されるものと解釈すべきではない。それに従って、本原理は、様々な変更形態及び代替の形態が可能であるが、その具体的な例は、図面では例として示され、本明細書で詳細に説明する。しかし、本原理を開示される特定の形態に限定するという意図は全くなく、それどころか、本開示は、請求項によって定義されるような本原理の精神及び範囲内に収まるすべての変更形態、均等形態及び代替の形態を包含することを理解すべきである。
【００７９】
本明細書で使用される専門用語は、特定の例について説明するためだけのものであり、本原理を制限することを意図しない。本明細書で使用される場合は、「a」、「an」及び「the」の単数形は、文脈で明確に示されない限り、複数形も含むことを意図する。「含む（「comprises」、「comprising」、「includes」及び／又は「including」）」という用語は、この明細書で使用される際は、記述される特徴、整数、ステップ、動作、要素及び／又はコンポーネントの存在を指定するが、１つ又は複数の他の特徴、整数、ステップ、動作、要素、コンポーネント及び／又はそれらのグループの存在又は追加を除外しないことがさらに理解されよう。その上、ある要素が別の要素に「応答する」又は「接続される」ものとして言及されている際は、その要素は、他の要素に直接応答する又は接続することも、介在要素を存在させることもできる。対照的に、ある要素が他の要素に「直接応答する」又は「直接接続される」ものとして言及されている際は、介在要素は存在しない。本明細書で使用される場合は、「及び／又は」という用語は、関連リストアイテムのうちの１つ又は複数のありとあらゆる組合せを含み、「／」と短縮することができる。
【００８０】
「第１の」、「第２の」などの用語は、本明細書において様々な要素を説明するために使用することができるが、これらの要素は、これらの用語によって制限されるべきではないことが理解されよう。これらの用語は、ある要素を別の要素と区別するためだけに使用される。例えば、本原理の教示から逸脱することなく、第１の要素は、第２の要素と呼ぶことができ、同様に、第２の要素は、第１の要素と呼ぶことができる。
【００８１】
図のいくつかは、通信の主要な方向を示すために通信経路上に矢印を含むが、通信は、描写される矢印とは反対の方向でも起こり得ることを理解されたい。
【００８２】
いくつかの例は、ブロック図及び動作上のフローチャートに関して説明され、各ブロックは、指定された論理機能を実装するための１つ又は複数の実行可能命令を含む、回路素子、モジュール又はコードの一部分を表す。また、他の実装形態では、ブロックで記述される機能は、記述される順番以外でも起こり得ることにも留意すべきである。例えば、実際には、関与する機能性に応じて、連続して示される２つのブロックを実質的に同時に実行することも、場合により、ブロックを逆の順番で実行することもできる。
【００８３】
本明細書における「例によれば」又は「例では」への言及は、例と関係して説明された特定の特徴、構造又は特性を本原理の少なくとも１つの実装形態に含めることができることを意味する。本明細書の様々な場所における「例によれば」又は「例では」という記載の出現は、必ずしもすべてが同じ例を指すとは限らず、別個の又は代替の例が必ずしも他の例の相互排他的なものであるとも限らない。
【００８４】
請求項で見られる参照番号は、単なる例示であり、請求項の範囲への制限効果はないものとする。
【００８５】
明示的に説明されてはいないが、本例及び変形形態は、いかなる組合せ又は副組合せでも採用することができる。
【００８６】
本原理は、コンテキストセットの中からコンテキストを選択するための戦略が符号化予定のピクチャブロックのサイズに依存するＣＡＢＡＣの修正バージョンを開示する。
【００８７】
図９は、本原理の例による、ピクチャブロックのサイズによるバイナリシンボルに対するいくつかのコンテキストのセットの中からのコンテキストの選択（ステップ１１０）を示すブロック図を示す。
【００８８】
ステップ９００では、モジュールは、ピクチャブロックのサイズ（幅及び高さ）が２の累乗であるか否かをチェックする。
【００８９】
「はい」の場合、すなわち、上記ピクチャブロックのサイズが２の累乗である際は、ステップ９１０において、セレクタＳＬ１は、上記ピクチャブロックのサイズに従ってコンテキストを決定する。
【００９０】
そうでない場合は、ステップ９２０において、セレクタＳＬ２は、上記ピクチャブロックのサイズのすぐ上の又は下のブロックサイズに従ってコンテキストを決定し、上記ブロックサイズは、２の累乗である。
【００９１】
これらの本原理は、不均一な統計的挙動を有するピクチャデータに関するいかなる種類のピクチャ要素又は構文要素も符号化するために適用することができる。
【００９２】
以下では、これらの本原理の実施形態は、ＨＥＶＣ規格（ITU-T H.265 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (10/2014), SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS, Infrastructure of audiovisual services - Coding of moving video, High efficiency video coding, Recommendation ITU-T H.265）と関連して説明するが、ピクチャデータ又は構文要素を符号化するためのエントロピーコード化を必要とする他のいかなる映像符号化／復号スキームまでも拡張することができる。
【００９３】
ＨＥＶＣ規格及び関連付けられた加入調査モデル（“Algorithm Description of Joint Exploration Test Model 3”, Document JVET-C1001_v3, Joint Video Exploration Team of ISO/IEC JTC1/SC29/WG11, 3rd meeting, 26 May - 1 June 2015, Geneva, CH）では、変換ブロック（ＴＢ）と呼ばれるピクチャブロックに属する量子化された変換済み係数は、通常、ＣＡＢＡＣを使用してエントロピーコード化される。ＴＢは、例えば、上記で説明されるような、得られたコード化木のコード化単位（葉）であり得るピクチャブロックである。
【００９４】
最初に、変換ブロックＴＢは、コード化グループ（ＣＧ）と呼ばれる量子化された変換済み係数のサブブロックに分割される。エントロピーコード化／復号は、いくつかの走査パスで構成され、いくつかの走査パスは、いくつかの可能な走査パターンの中から選択された走査パターンに従ってＴＢを走査する。
【００９５】
例として、図１０に示されるように、８×８  ＴＢは、４つの４×４コード化グループ（ＣＧ）に分割される。インター予測コード化単位の場合は、対角方向走査パターンが常に使用され、４×４及び８×８イントラ予測コード化単位の場合は、選択される走査パターンは、そのＣＵに対してアクティブなイントラ予測モードに依存する。
【００９６】
次いで、あるＴＢにわたる走査パスは、３つの走査順番（対角方向、水平方向、垂直方向）のうちの１つに従って各ＣＧを順次処理することを含み、各ＣＧ内の１６の量子化された変換済み係数は、考慮される走査順番に従って走査される。走査パスは、ＴＢ内の最終有意（非ゼロ）係数から始まり、ＣＧの左上隅に位置する量子化された変換済み係数（通常、ＣＧのエネルギーのほとんどを保持する）に至るまで、すべての量子化された変換済み係数を処理する。
【００９７】
従って、「最終有意係数ｘ座標」及び「最終有意係数ｙ座標」と呼ばれる２つの構文要素は、上記ＴＢと関連付けられた走査順番によるＴＢの最終の非ゼロの量子化された変換済み係数の空間位置（ｘ及びｙ座標）をデコーダに提供するために、各ＴＢに対するＨＥＶＣ準拠エンコーダの出力ビットストリームに追加される。
【００９８】
量子化された変換済み係数のエントロピーコード化は、最大で５つの走査パスを含み得、走査パスはそれぞれ、以下の構文要素の各々のコード化専用である。
・  significant-coeff-flag：これは、量子化された変換済み係数がゼロに等しいか否かを示すバイナリフラグである
・  coeff-abs-level-greater1-flag：これは、量子化された変換済み係数レベルの絶対値が１より大きいか否かを示すバイナリフラグである
・  coeff-abs-level-greater2-flag：これは、係数レベルの絶対値が２より大きいか否かを示す二進の量子化された変換済み係数である
・  coeff-sign-flag：これは、有意（非ゼロ）の量子化された変換済み係数の符号を示すバイナリフラグである
・  coeff-abs-level-remaining：この構文要素は、量子化された変換済み係数レベルの絶対値の残存値を表す（量子化された変換済み係数値が以前のパスにおいてコード化されたものより大きい場合）
【００９９】
上記の４つの第１のパスのサブセットを復号することによって係数の絶対値が分かった時点で、その絶対値に関して、残存パスにおけるその係数に対するさらなる構文要素のコード化は行われなくなる。符号コード化についても同じことが言え、coeff-sign-flagは、非ゼロ係数に対してのみ送信される。
【０１００】
すべての走査パスは、次のＣＧに行く前に、そのＣＧのすべての量子化された変換済み係数を再構成することができるまで、所定のＣＧに対してコード化される。
【０１０１】
ビットストリームからのＴＢの全体的な復号は、デコーダに以下の構文要素を提供する上記ビットストリームの構文解析を含む。
１．「最終有意座標」構文要素
２．ＴＢの最終有意係数を含むＣＧからＴＢの左上のＣＧまでの各連続ＣＧに対し、
ａ．ＨＥＶＣ規格ではcoded_sub_block_flagと呼ばれるＣＧ有意性フラグ
ｂ．考慮されるＣＧの量子化された変換済み係数の各々に対する有意係数フラグ。これは、ＨＥＶＣ規格ではsig_coeff_flagという構文要素に相当する
ｃ．考慮されるＣＧの非ゼロの量子化された変換済み係数に対し、
ｉ．coeff_abs_level_greater1_flag：このフラグは、現在の係数の絶対値が１より高いか否かを示す。そうでない場合は、絶対値、１に等しい場合
ｉｉ．coeff_abs_level_greater2_flag：このフラグは、現在の係数の絶対値が１より高いか否かを示す。そうでない場合は、絶対値、１に等しい場合
ｉｉｉ．coeff_sign_flag：これは、非ゼロ係数の符号を示す
ｉｖ．coeff_bas_level_remaining：これは、絶対値が２より高い係数の絶対値を符号化する
【０１０２】
本原理の以下の実施形態は、「最終有意係数座標」構文要素のコード化／復号及び「有意係数フラグ」構文要素のコード化／復号のみに焦点を置くが、その理由は、関連付けられた加入調査モデル（“Algorithm Description of Joint Exploration Test Model 3”, Document JVET-C1001_v3, Joint Video Exploration Team of ISO/IEC JTC1/SC29/WG11, 3rdmeeting, 26 May - 1 June 2015, Geneva, CH）において、それらのコード化／復号に使用されるコンテキストがＴＢのサイズに依存するためである。
【０１０３】
本原理の第１の実施形態によれば、図９の方法は、コード化グループＣＧに関する「最終有意係数座標」構文要素のコンテキストベース算術コード化／復号に対して適用される。
【０１０４】
「最終有意係数ｘ座標」構文要素は、ＴＢに属するＣＧに関するものであり、以下によって表されるロスレスである。
−  （Ｎ＋１）区間のセットの中から、コード化予定のｘ座標が含まれる整数値の区間を識別する区間インデックス（プレフィックス）（N=2×log2(T)-1であり、Ｔは、ＣＧにおける変換済み係数を得るために使用される変換のサイズ（すなわち、正方形ブロックの事例では、幅又は高さ）である）、及び、
−  上記区間インデックスによって伝えられた区間内の最終有意係数のｘ座標を決定するオフセット（サフィックス）
【０１０５】
方法は、上記区間インデックスによって識別された値の区間にｘ座標値が属するように上記区間インデックスを得て、「最終有意係数ｘ座標」値が上記プレフィックス及びサフィックスによって表されるロスレスであるように、識別された区間内の上記オフセットを得る。
【０１０６】
サフィックスは、図１１に示されるように、通常、例えば、ｂビット（b=max(0,[prefix/2]-1)）にわたる固定長コードを使用することによってバイパスモードでコード化される二進値構文要素である。コード化済みサフィックスは、出力ビットストリームに追加される。
【０１０７】
区間インデックスを表すプレフィックスは、本原理の例（ステップ１１０、１２０）に従ってコンテキストベース算術コード化された非二進値構文要素である。次いで、プレフィックスは、出力ビットストリームに追加される。
【０１０８】
「最終有意係数ｘ座標」（「最終有意係数ｙ座標」）構文要素を符号化する場合、最初に、ステップ１００（図１）において、バイナライザは、Ｔ＝３２の際、図１１によって示されるように、区間インデックスを切り捨て単項コードにマッピングする。１つの座標に対する切り捨て単項コード（コンテキストベースコード化済みのビンの数でもある）の最大長は、Ｔ＝４、８、１６、３２に対してそれぞれ、３、５、７、９である。実際に、例えば、Ｔが４に等しい場合は、最終有意係数ｘ座標は、０、１、２又は３に等しいものであり得る。これらの値はそれぞれ、切り捨て単項コード「０」、「１０」、「１１０」、「１１１０」によって識別される。従って、Ｔが４に等しい場合は、最大で３つのビンが必要である。その上、Ｔが８に等しい場合は、最大切り捨てコードワードは、「１１１１１０」である。最終有意係数ｘ座標は最大でも７であるため、デコーダは、「１」に等しい５つの連続ビンが復号された時点で、プレフィックスコードが「１１１１１０」であると推論することができる。これが、変換サイズが８である事例において、プレフィックスに対して、最大でも５つのビンを必要とする理由である。
【０１０９】
次に、ステップ９００（図９）において、ＴＢサイズが２の累乗であるかどうかをチェックする。少なくとも１つのコンテキストセットは、２の累乗に等しい異なるＴＢサイズに従って得られ、各コンテキストセットは、特定の２の累乗に等しいＴＢサイズに対して得られる。
【０１１０】
「はい」の場合は、ステップ９１０において、セレクタＳＬ１は、ＴＢサイズに従って、切り捨て単項コードの各ビンに対して、上記得られた少なくとも１つのコンテキストセットの中からコンテキストセットを選択する。
【０１１１】
「いいえ」の場合は、ステップ９２０において、選択ＳＬ２  ＳＬ１は、ＴＢサイズのすぐ上の又は下のブロックサイズに従って、切り捨て単項コードの各ビンに対して、上記得られた少なくとも１つのコンテキストセットの中からコンテキストセットを選択し、上記ブロックサイズは、２の累乗に等しい。
【０１１２】
最後に、「最終有意係数ｘ座標」構文要素を表す切り捨て単項コードの各ビンは、切り捨て単項コードにおけるビンのインデックスに従って、上記選択されたコンテキストセットの中から決定されたコンテキストを考慮して算術コード化される（ステップ１２０）。
【０１１３】
図１２は、異なるＴＢサイズに従ってコンテキストインデックスのセットを与える表の例を示す。図１２の表の「ビンインデックス」は、切り捨て単項コードにおけるコード化予定のビンのインデックスを識別することに留意されたい。
【０１１４】
この例によれば、ＴＢサイズが２の累乗である（すなわち、Ｔ＝２、４、８、１６又は３２）際は、コンテキストセットは、Ｔに従って得られる。例えば、Ｔ＝８の際、コンテキストインデックスのセット（３、３、３、４、４、５）が選択される。最終的に決定されるコンテキストインデックスは、切り捨て単項コードにおける現在のビンのインデックスに依存する。例えば、切り捨て単項コードにおけるランク２のビンが現在のビンである場合は、コンテキストインデックス４が考慮される。
【０１１５】
ＴＢサイズが２の累乗ではない（すなわち、Ｔ＝３、６、１２又は２４）際は、コンテキストセットは、ＴＢサイズのすぐ下のブロックサイズに従って選択される。
【０１１６】
例えば、ＴＢサイズが１２に等しい際は、８に等しいＴＢサイズに関するコンテキストインデックスのセットが選択される。決定されるコンテキストインデックスは、切り捨て単項コードの現在のビンのインデックスに依存する。例えば、切り捨て単項コードのランク２のビンが現在のビンである場合は、コンテキストインデックス４が考慮される。
【０１１７】
図１３は、異なるＴＢサイズに従ってコンテキストインデックスのセットを与える表の例を示す。図１３の表の「ビンインデックス」は、切り捨て単項コードにおけるコード化予定のビンのインデックスを識別することに留意されたい。
【０１１８】
この例によれば、ＴＢサイズが２の累乗である（すなわち、Ｔ＝２、４、８、１６又は３２）際は、コンテキストセットは、ＴＢサイズに従って選択される。例えば、Ｔ＝８の際、コンテキストインデックスのセット（３、３、３、４、４、５）が選択される。決定されるコンテキストインデックスは、切り捨て単項コードにおける現在のビンのインデックスに依存する。例えば、切り捨て単項コードのランク２のビンが現在のビンである場合は、コンテキストインデックス４が考慮される。
【０１１９】
ＴＢサイズが２の累乗ではない（すなわち、Ｔ＝３、６、１２又は２４）際は、コンテキストセットは、ＴＢサイズのすぐ上のブロックサイズに従って選択される。
【０１２０】
例えば、ＴＢサイズが１２に等しい際は、１６に等しいＴＢサイズに関するコンテキストインデックスのセットが選択される。決定されるコンテキストインデックスは、切り捨て単項コードの現在のビンのインデックスに依存する。例えば、切り捨て単項コードのランク２のビンが現在のビンである場合は、コンテキストインデックス７が考慮される。
【０１２１】
「最終有意係数ｘ座標」に関するプレフィックスをコード化する場合、本原理は、ｍ・２ｎ（２の累乗とは異なる）に等しい現在のＴＢサイズのすぐ上の又は下の、２の累乗であるＴＢサイズと関連付けられたコンテキストを再利用する。
【０１２２】
数学的に言えば、３・２ｎ（ｍ＝３）に等しいＴＢサイズ（幅又は高さ）の場合、ＴＢサイズ２ｎ＋１（図１２）又は２ｎ＋２（図１３）に関するコンテキストセットが使用される。
【０１２３】
従って、本原理は、２の累乗に等しくないサイズのピクチャブロックに対して新しいコンテキストを定義するよりむしろ、２の累乗に等しいサイズのピクチャブロックに対して既に使用されたコンテキストを再利用する（ＨＥＶＣ規格で又はＨＥＶＣ規格と関連付けられた加入調査モデルで定義されるように）。これにより、格納する及び取り扱うコンテキストの数の増加が避けられ、従って、２の累乗に等しくないサイズの変換ブロック（ＴＢ）の符号化／復号の複雑性の著しい増大が避けられる。
【０１２４】
実施形態によれば、「最終有意係数ｘ座標」構文要素に関するプレフィックスを符号化する切り捨て単項コードのビンに対するコンテキストは、以下の通り、ＴＢサイズに従って決定することができる（ステップ９１０又は９２０）。上記コンテキストは、少なくとも１つの以前に決定されたコンテキストセットの中から識別されたコンテキストセット自体の中からcurrCtxIdxというコンテキストインデックスによって識別される。
【０１２５】
最初に、ＴＢの幅からプレフィックスをコード化するために、「最終有意係数ｘ座標」に対して、baseCtxIdxというベースコンテキストインデックスが演算される。
【０１２６】
このベースコンテキストインデックスは、上記少なくとも１つの以前に決定されたコンテキストセットの中からコンテキストセットを識別する。
【０１２７】
ベースインデックスは、ピクチャのクロマ成分に対しては、組織的にゼロに設定することができ、ルマ成分に対しては、ＴＢの幅ｗの関数g_uiLastPrefixCtxとして計算することができる。
【数２】
2019531026.tif 000004
【０１２８】
次に、ctxIdx_shiftXというコンテキストシフト値を以下の通り計算することができる。
【数３】
2019531026.tif 000005
【０１２９】
或いは、
【数４】
2019531026.tif 000006
である。
【０１３０】
次に、プレフィックスのビンに対して、baseCtxIdxというベースコンテキストインデックスの関数として、currCtxIdxというコンテンツインデックスが決定され、切り捨て単項コードにおけるコード化予定の現在のビンのprefixBinIdxというインデックスに従って、ctxIdx_shiftXというコンテキストシフト値が決定される。
currCtxIdx=baseCtxIdx+(prefixBinIdx≫ctxIdx_shiftX)  （１）
プレフィックスの第１のビンに対するコンテキストインデックスは、baseCtxIdxというベースコンテキストインデックスに等しいものであり得ることに留意されたい。
【０１３１】
図６の実施形態によれば、「最終有意係数ｘ座標」（「最終有意係数ｙ座標」）構文要素は、以下の通り、入力ビットストリームから復号される。
【０１３２】
currCtxIdxというコンテキストインデックスは、以下の通り、方程式（１）によって演算される。ステップ１１０においてbaseCtxIdxというベースコンテキストインデックスが得られた時点で、デコーダは、入力ビットストリームから一連の復号済みのビンを生成する。復号予定の一連のビンの各ビンに対し、エンコーダ側（方程式１）と厳密に同じ方法で得られたベースコンテキストインデックスとコンテキスト増分値（prefixBinIdx≫ctxIdxshiftX）との総和として、currCtxIdxというコンテキストインデックスが演算される。そのように得られたcurrCtxIdxというコンテキストインデックスは、コンテキストモデル化ステップ１１０によって提供されるコンテキストモデルのインデックスに相当する。次いで、決定された識別子を有するコンテキストによって、復号予定の一連のビンの現在のビン値（１又は０）が算術復号される（図６のステップ６２０）。
【０１３３】
次いで、復号予定の一連のビンの「０」ビン値が復号されるか又は考慮されるＴＢサイズに対して「１」ビンの最大数に達した時点で、これは、一連の復号済みのビンが図１１の切り捨て単項二進化プレフィックスに相当することを意味する。次いで、デコーダは、バイパス復号予定のサフィックスビンの数ｂを知っており、それにより、上記復号済みプレフィックスによって伝えられた区間内の最終有意係数のｘ座標を決定するサフィックスが提供される。
【０１３４】
最後に、以下の通り、復号済みプレフィックス及びサフィックス値に基づいて、最終有意係数ｘ座標（以下の方程式では、lastと記述される）が再構成される。
prefix＞３の場合  last=2b(2+(prefix%2))+suffix
それ以外の場合  last=prefix
【０１３５】
「最終有意係数ｙ座標」構文要素に対するコンテキストインデックスは、同様の方法で、ＴＢサイズに従ってコンテキストセットの中から選択することができる。
【０１３６】
本原理の第２の実施形態によれば、図９の方法は、ＴＢに属するコード化グループＣＧに関する「有意係数フラグ」構文要素のコンテキストベース算術コード化／復号に対して適用される。
【０１３７】
「有意係数フラグ」は、ＣＧの量子化された変換済み係数に関する二進値構文要素である。
【０１３８】
第１に、以下の通り、ステップ１１０において、ctxOffsetというベースコンテキストオフセットが計算される。
ctxOffset=isChroma?0:indexOnTBSize  （２）
式中、indexOnTbSizeは、以下の通り演算された区間インデックスである。
indexOnTbSize=uiLog2BlockSize≦2?0:f(uiLog2BlockSize)  （３）
式中、uiLog2BlockSizeは、ＴＢのサイズ（エリア）に従って演算された値である。
【０１３９】
第２に、最終係数から最低周波数係数に向けてＣＧの量子化された変換済み係数の各々が考慮される。量子化された変換済み係数の各々に対し、ctxIncrementというコンテキスト増分を、indexOnTbSizeという上記区間インデックスによって伝えられた整数値の区間内の最終有意係数のｘ座標を決定するctxOffsetというベースコンテキストオフセットに加えることによって、その有意性をコード化するためのcurrCtxIdxというコンテキストインデックスが演算される。
【０１４０】
最後に、コンテキストインデックスと関連付けられたコンテキストを考慮して「有意係数フラグ」が算術コード化される（ステップ１２０）。
currCtxIdx=ctxOffset+ctxIncrement  （４）
【０１４１】
実施形態によれば、ctxIncrementというコンテキスト増分は、図１４に示されるように、以下の通り演算される。
【０１４２】
ctxIncrementというコンテキスト増分は、ローカルテンプレートによってカバーされた近隣の以前にコード化された量子化された変換済み係数の「有意係数フラグ」値の値に依存する。より具体的には、ctxIncrementというコンテキスト増分は、近隣の係数の有意フラグの総和に基づいて演算される。図１４は、そのようなテンプレートの例を示す。この例によれば、現在の量子化された変換済み係数（白い円によって表されている）と関連付けられたコンテキスト増分は、以下の通り計算される。
ctxIncrement=sigCoeffFlag(x+1,y)+sigCoeffFlag(x+2,y)+sigCoeffFlag(x,y+1)+sigCoeffFlag(x,y+2)+sigCoeffFlag(x+1,y+1)  （５）
【０１４３】
式中、ｘ及びｙは、考慮されるＴＢにおける現在の係数の座標であり、sigCoeffFlag(x,y)は、位置（ｘ，ｙ）における量子化された変換済み係数が非ゼロである場合は、１に等しく、そうでない場合は、０に等しい。ｘ０、ｘ３、ｘ１、ｘ４、ｘ２はそれぞれ、（ｘ＋１，ｙ）、（ｘ＋２，ｙ）、（ｘ，ｙ＋１）、（ｘ，ｙ＋２）、（ｘ＋１，ｙ＋１）のそれぞれの座標を有する近隣の係数であることに留意されたい。
【０１４４】
異なる周波数における量子化された変換済み係数の特性を捕らえるため、ＴＢは、最大で３つの領域に分割することができ、分割方法は、図１４に示されるように、ＴＢサイズにかかわらず固定される。コンテキストインデックスは、各領域に割り当てられる。
【０１４５】
本原理の第２の実施形態によれば、ステップ９００（図９）において、ＴＢの幅ｗ及び／又は高さｈが２の累乗であるかどうかをチェックする。
【０１４６】
「はい」の場合は、ステップ９１０において、セレクタＳＬ１は、ＴＢサイズに従って決定されたindexOnTbSizeというベースコンテキストインデックス自体に従ってコンテキストを決定する。
【０１４７】
「いいえ」の場合は、ステップ９２０において、セレクタＳＬ２は、ＴＢサイズのすぐ上の又は下のブロックサイズに従って決定されたindexOnTbSizeというベースコンテキストインデックス自体に従ってコンテキストを決定し、上記ブロックサイズは、２の累乗に等しい。
【０１４８】
実施形態によれば、indexOnTbSizeというベースコンテキストインデックスは、
【数５】
2019531026.tif 000007
によって得られ、式中、ｗ及びｈはそれぞれ、ＴＢの幅及び高さであり、ｆ（．）は、数学関数である。
【０１４９】
変形形態によれば、
【数６】
2019531026.tif 000008
である。
【０１５０】
indexOnTbSizeというベースコンテンツインデックスは、特定のＴＢエリアに関するコンテキストの特定のセットを識別する。これは、異なるエリアを有するＴＢの「有意係数フラグ」をコード化するために、コンテキストの分離されたセットを採用できることを意味する。
【０１５１】
ctxOffsetというコンテキストオフセットは、ルマ成分の場合は、上記ベースコンテキストインデックスに等しくてもよく、クロマ成分の場合は、０に等しい。
【０１５２】
図６の実施形態によれば、「最終有意フラグ」構文要素は、以下の通り、入力ストリームから復号される。
【０１５３】
最初に、少なくとも「有意係数フラグ」と関連付けられたコンテキストインデックスは、エンコーダのコンテキストモデル化ステップと同一のコンテキストモデル化ステップ１１０）から得られる。
【０１５４】
従って、コンテキストインデックスは、ctxOffsetというベースコンテキストオフセットとctxIndexIncrementというコンテキスト増分との総和として計算され、各々は、エンコーダ側と全く同じ方法で、方程式（４）及び（５）に従って計算される。
【０１５５】
次に、上記計算されたコンテキストインデックス及び入力ビットストリームのビットを有するコンテキストモデルを考慮すると、算術復号ステップ６２０は、現在復号されているＣＧの現在の係数と関連付けられた「有意係数フラグ」を表すビン値を復号することができる。
【０１５６】
図１〜１４では、モジュールは、区別可能な物理ユニットと関係があってもなくともよい機能ユニットである。例えば、これらのモジュール又はそれらのいくつかは、特有のコンポーネント又は回路にまとめることも、ソフトウェアの機能性に寄与することもできる。それに反して、いくつかのモジュールは、別個の物理的実体から潜在的に構成することができる。本原理に適合する装置は、純粋なハードウェアを使用して、例えば、ＡＳＩＣ、ＦＰＧＡ若しくはＶＬＳＩ（それぞれ、≪特定用途向け集積回路≫、≪フィールドプログラマブルゲートアレイ≫、≪超大規模集積≫）などの専用ハードウェアを使用して、或いは、デバイスに埋め込まれたいくつかの統合電子コンポーネントから、又は、ハードウェアコンポーネント及びソフトウェアコンポーネントの混合物から実装される。
【０１５７】
図１５は、図１〜１４に関連して説明される方法を実装するように構成することができるデバイス１５００の例示的なアーキテクチャを表す。
【０１５８】
デバイス１５００は、データ及びアドレスバス１５０１によってつながっている以下の要素、すなわち、
−  例えばＤＳＰ（又はデジタル信号プロセッサ）である、マイクロプロセッサ１５０２（又はＣＰＵ）、
−  ＲＯＭ（又は読み取り専用メモリ）１５０３、
−  ＲＡＭ（又はランダムアクセスメモリ）１５０４、
−  アプリケーションから送信用のデータを受信するためのＩ／Ｏインタフェース１５０５、及び、
−  バッテリ１５０６
を含む。
【０１５９】
例によれば、バッテリ１５０６は、デバイスの外部のものである。言及されるメモリの各々では、本明細書で使用される「レジスタ」という用語は、小容量のエリア（数ビット）又は非常に大きなエリア（例えば、全プログラム又は大量の受信若しくは復号データ）に対応し得る。ＲＯＭ  １５０３は、プログラム及びパラメータを少なくとも含む。ＲＯＭ  １５０３は、本原理による技法を実行するためのアルゴリズム及び命令を格納することができる。電源を入れると、ＣＰＵ  １５０２は、ＲＡＭにプログラムをアップロードし、対応する命令を実行する。
【０１６０】
ＲＡＭ  １５０４は、プログラム（ＣＰＵ  １５０２によって実行され、デバイス１５００の電源を入れた後にアップロードされる）をレジスタに含み、入力データをレジスタに含み、方法の異なる状態の中間データをレジスタに含み、方法の実行のために使用される他の変数をレジスタに含む。
【０１６１】
本明細書で説明される実装形態は、例えば、方法若しくはプロセス、装置、ソフトウェアプログラム、データストリーム、又は、信号で実装することができる。実装の単一の形態の文脈においてのみ論じられる（例えば、方法又はデバイスとしてのみ論じられる）場合であっても、論じられる特徴の実装形態は、他の形態（例えば、プログラム）でも実装することができる。装置は、例えば、適切なハードウェア、ソフトウェア及びファームウェアで実装することができる。方法は、例えば、コンピュータ、マイクロプロセッサ、集積回路又はプログラマブル論理デバイスを含む、例えば、一般に処理デバイスを指す装置（例えば、プロセッサなど）で実装することができる。また、プロセッサは、例えば、コンピュータ、携帯電話、ポータブル／携帯情報端末（「ＰＤＡ」）、及び、エンドユーザ間の情報の通信を容易にする他のデバイスなどの通信デバイスも含む。
【０１６２】
符号化又はエンコーダの例によれば、映像データのブロックＢｃ、構文要素又はバイナリシンボルのシーケンスは、供給源から得られる。例えば、供給源は、
−  ローカルメモリ（１５０３又は１５０４）（例えば、ビデオメモリ又はＲＡＭ（若しくはランダムアクセスメモリ）、フラッシュメモリ、ＲＯＭ（若しくは読み取り専用メモリ）、ハードディスク）、
−  記憶装置インタフェース（１５０５）（例えば、大容量記憶装置、ＲＡＭ、フラッシュメモリ、ＲＯＭ、光ディスク又は磁気サポートとのインタフェース）、
−  通信インタフェース（１５０５）（例えば、有線インタフェース（例えば、バスインタフェース、広域ネットワークインタフェース、ローカルエリアネットワークインタフェース）又は無線インタフェース（ＩＥＥＥ８０２．１１インタフェース若しくはBluetooth（登録商標）インタフェースなど））、及び、
−  ピクチャ捕捉回路（例えば、センサ、例えば、ＣＣＤ（若しくは電荷結合素子）又はＣＭＯＳ（若しくは相補型金属酸化膜半導体）など）
を含むセットに属する。
【０１６３】
復号又はデコーダの例によれば、復号済みデータは、送り先に送信される。具体的には、送り先は、
−  ローカルメモリ（１５０３又は１５０４）（例えば、ビデオメモリ又はＲＡＭ、フラッシュメモリ、ハードディスク）、
−  記憶装置インタフェース（１５０５）（例えば、大容量記憶装置、ＲＡＭ、フラッシュメモリ、ＲＯＭ、光ディスク又は磁気サポートとのインタフェース）、
−  通信インタフェース（１５０５）（例えば、有線インタフェース（例えば、バスインタフェース（例えば、ＵＳＢ（若しくはユニバーサルシリアルバス））、広域ネットワークインタフェース、ローカルエリアネットワークインタフェース、ＨＤＭＩ（登録商標）（高解像度マルチメディアインタフェース）インタフェース）又は無線インタフェース（ＩＥＥＥ８０２．１１インタフェース、WiFi（登録商標）若しくはBluetooth（登録商標）インタフェースなど））、
−  ディスプレイ
を含むセットに属する。
【０１６４】
符号化又はエンコーダの例によれば、ビットストリームは、送り先に送信される。例として、ビットストリームは、ローカル又はリモートメモリ（例えば、ビデオメモリ（１５０４）又はＲＡＭ（１５０４）、ハードディスク（１５０３））に格納される。変形形態では、ビットストリームは、記憶装置インタフェース（１５０５）（例えば、大容量記憶装置、フラッシュメモリ、ＲＯＭ、光ディスク又は磁気サポートとのインタフェース）に送られる、及び／又は、通信インタフェース（１５０５）（例えば、ポイントツーポイントリンク、通信バス、ポイントツーマルチポイントリンク又は放送ネットワークとのインタフェース）上で送信される。
【０１６５】
復号又はデコーダの例によれば、ビットストリームは、供給源から得られる。例示的には、ビットストリームは、ローカルメモリ（例えば、ビデオメモリ（１５０４）、ＲＡＭ（１５０４）、ＲＯＭ（１５０３）、フラッシュメモリ（１５０３）又はハードディスク（１５０３））から読み取られる。変形形態では、ビットストリームは、記憶装置インタフェース（１５０５）（例えば、大容量記憶装置、ＲＡＭ、ＲＯＭ、フラッシュメモリ、光ディスク又は磁気サポートとのインタフェース）から受信される、及び／又は、通信インタフェース（１５０５）（例えば、ポイントツーポイントリンク、バス、ポイントツーマルチポイントリンク又は放送ネットワークとのインタフェース）から受信される。
【０１６６】
例によれば、デバイス１５００は、図１〜１４に関連して説明される方法を実装するように構成され、
−  モバイルデバイス、
−  通信デバイス、
−  ゲームデバイス、
−  タブレット（又はタブレットコンピュータ）、
−  ラップトップ、
−  静止ピクチャカメラ、
−  ビデオカメラ、
−  符号化チップ、
−  静止ピクチャサーバ、
−  映像サーバ（例えば、放送サーバ、ビデオオンデマンドサーバ又はウェブサーバ）
−  セットトップボックス、
−  ＴＶセット、
−  ディスプレイ、及び、
−  復号チップ
を含むセットに属する。
【０１６７】
本明細書で説明される様々なプロセス及び特徴の実装形態は、様々な異なる機器又はアプリケーションで具体化することができる。そのような機器の例は、エンコーダ、デコーダ、デコーダからの出力を処理するポストプロセッサ、エンコーダに入力を提供するプリプロセッサ、ビデオコーダ、ビデオデコーダ、ビデオコーデック、ウェブサーバ、セットトップボックス、ラップトップ、パーソナルコンピュータ、携帯電話、ＰＤＡ、及び、ピクチャ若しくは映像を処理するための他の任意のデバイス、又は、他の通信デバイスを含む。明確であるべきだが、機器は、モバイルであり得、移動車両にインストールすることさえも可能である。
【０１６８】
それに加えて、方法は、プロセッサによって実行されている命令によって実装することができ、そのような命令（及び／又は実装形態によって生成されたデータ値）は、コンピュータ可読記憶媒体上に格納することができる。コンピュータ可読記憶媒体は、コンピュータ可読プログラム製品の形態を取ることができ、コンピュータ可読プログラム製品は、１つ又は複数のコンピュータ可読媒体において具体化され、その上で具体化されたコンピュータ可読プログラムコードを有し、コンピュータ可読プログラムコードは、コンピュータによって実行可能である。コンピュータ可読記憶媒体は、本明細書で使用される場合は、情報をその中に格納するための固有の能力及びそこからの情報の回収を提供するための固有の能力が与えられた非一時的な記憶媒体と見なされる。コンピュータ可読記憶媒体は、例えば、これらに限定されないが、電子、磁気、光、電磁、赤外線若しくは半導体システム、装置若しくはデバイス、又は、前述の適切な任意の組合せであり得る。当業者であれば容易に把握できるように、以下、すなわち、ポータブルコンピュータディスケット、ハードディスク、読み取り専用メモリ（ＲＯＭ）、消去型プログラム可能読み取り専用メモリ（ＥＰＲＯＭ若しくはフラッシュメモリ）、ポータブルコンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、光学記憶装置、磁気記憶装置、又は、前述の適切な任意の組合せは、本原理が当てはまるコンピュータ可読記憶媒体のより具体的な例を提供する一方で、単なる例示であり、網羅的なリストではないことを把握されたい。
【０１６９】
命令は、プロセッサ可読媒体上で有形に具体化されたアプリケーションプログラムを形成することができる。
【０１７０】
命令は、例えば、ハードウェア、ファームウェア、ソフトウェア又は組合せにおけるものであり得る。命令は、例えば、オペレーティングシステム、別個のアプリケーション又はその２つの組合せで見つけることができる。従って、プロセッサは、例えば、プロセスを実行するように構成されたデバイスと、プロセスを実行するための命令を有するプロセッサ可読媒体（記憶装置など）を含むデバイスとの両方として特徴付けることができる。さらに、プロセッサ可読媒体は、命令に加えて又は命令の代わりに、実装形態によって生成されたデータ値を格納することができる。
【０１７１】
当業者には明らかであるように、実装形態は、例えば、格納又は送信することができる、情報を伝えるようにフォーマットされた様々な信号を生成することができる。情報は、例えば、方法を実行するための命令、又は、説明される実装形態のうちの１つによって生成されたデータを含み得る。例えば、信号は、本原理の説明される例の構文を書き込む又は読み取るための規則をデータとして伝えるように、或いは、本原理の説明される例によって書き込まれた実際の構文・値をデータとして伝えるように、フォーマットすることができる。そのような信号は、例えば、電磁波として（例えば、スペクトルの高周波部分を使用して）又はベースバンド信号としてフォーマットすることができる。フォーマットすることは、例えば、データストリームを符号化すること、及び、符号化されたデータストリームで搬送波を変調することを含み得る。信号が伝える情報は、例えば、アナログ又はデジタル情報であり得る。信号は、知られているように、様々な異なる有線又は無線リンク上で送信することができる。信号は、プロセッサ可読媒体上に格納することができる。
【０１７２】
多くの実装形態について説明してきた。それにもかかわらず、様々な変更を行えることが理解されよう。例えば、他の実装形態を生成するために、異なる実装形態の要素を組み合わせることも、補足することも、変更することも、除去することもできる。それに加えて、当業者は、開示されるものの代わりに、他の構造及びプロセスを代用することができ、結果として得られる実装形態は、開示される実装形態と少なくとも実質的に同じ結果を達成するために、少なくとも実質的に同じ方法で、少なくとも実質的に同じ機能を実行することを理解するであろう。それに従って、これらの及び他の実装形態は、この出願によって企図される。
【図１】
2019531026.tif 000009
【図２】
2019531026.tif 000010
【図３】
2019531026.tif 000011
【図４】
2019531026.tif 000012
【図５】
2019531026.tif 000013
【図６】
2019531026.tif 000014
【図７】
2019531026.tif 000015
【図８】
2019531026.tif 000016
【図９】
2019531026.tif 000017
【図１０】
2019531026.tif 000018
【図１１】
2019531026.tif 000019
【図１２】
2019531026.tif 000020
【図１３】
2019531026.tif 000021
【図１４】
2019531026.tif 000022
【図１５】
2019531026.tif 000023
【国際調査報告】
2019531026.tif 000024
2019531026.tif 000025
2019531026.tif 000026