特許 6612920 ビデオ符号化（ｃｏｄｉｎｇ）のパレット予測器シグナリング方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6612920

(24)【登録日】2019年11月8日

(45)【発行日】2019年11月27日

(54)【発明の名称】ビデオ符号化（ｃｏｄｉｎｇ）のパレット予測器シグナリング方法

(51)【国際特許分類】

   H04N 19/70 20140101AFI20191118BHJP

   H04N 19/93 20140101ALI20191118BHJP

【ＦＩ】

   H04N19/70

   H04N19/93

【請求項の数】7

【全頁数】39

(21)【出願番号】特願2018-78968(P2018-78968)

(22)【出願日】2018年4月17日

(62)【分割の表示】特願2016-574156(P2016-574156)の分割

【原出願日】2015年6月19日

(65)【公開番号】特開2018-142973(P2018-142973A)

(43)【公開日】2018年9月13日

【審査請求日】2018年4月17日

(31)【優先権主張番号】62/014,959

(32)【優先日】2014年6月20日

(33)【優先権主張国】US

(31)【優先権主張番号】62/086,319

(32)【優先日】2014年12月2日

(33)【優先権主張国】US

(31)【優先権主張番号】62/108,165

(32)【優先日】2015年1月27日

(33)【優先権主張国】US

(31)【優先権主張番号】62/109,830

(32)【優先日】2015年1月30日

(33)【優先権主張国】US

(31)【優先権主張番号】62/109,836

(32)【優先日】2015年1月30日

(33)【優先権主張国】US

(31)【優先権主張番号】62/111,140

(32)【優先日】2015年2月3日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】516251901

【氏名又は名称】寰發股▲ふん▼有限公司

【氏名又は名称原語表記】ＨＦＩ Ｉｎｎｏｖａｔｉｏｎ Ｉｎｃ．

(74)【代理人】

【識別番号】110000486

【氏名又は名称】とこしえ特許業務法人

(72)【発明者】

【氏名】チャン，ツーデァ

(72)【発明者】

【氏名】キム，ジュンスン

(72)【発明者】

【氏名】スン，ユーチェン

(72)【発明者】

【氏名】ライ，ブォリン

(72)【発明者】

【氏名】チェン，チン−イェ

(72)【発明者】

【氏名】イン ジン

(72)【発明者】

【氏名】リウ，シャン

【審査官】 岩井 健二

(56)【参考文献】

【文献】 国際公開第２０１５／１７９８１０（ＷＯ，Ａ１）

【文献】 国際公開第２０１５／００６７２４（ＷＯ，Ａ２）

【文献】 国際公開第２０１４／１６５７８４（ＷＯ，Ａ１）

【文献】 Xun Guo,et al.，AHG8: Major-color-based screen content coding，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，15th Meeting: Geneva, CH，２０１３年１０月，JCTVC-O0182-v1，pp.1-7

【文献】 L.Guo et al.，RCE4: Results of Test 2 on Palette Mode for Screen Content Coding，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，16th Meeting: San Jose, US，２０１４年 １月，JCTVC-P0198，pp.1-3

【文献】 C. Gisquet, G. Laroche and P. Onno，AhG10: palette index coding，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，17th Meeting: Valencia, ES，２０１４年 ３月，JCTVC-Q0064，pp.1-3

【文献】 Jie Zhao et al.，Non-CE6: Simplified palette size coding，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，19th Meeting: Strasbourg, FR，２０１４年１０月，JCTVC-S0134，pp.1-5

【文献】 Wei Wang et al.，Non-CE6: 2-D Index Map Coding of Palette Mode in HEVC SCC，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，19th Meeting: Strasbourg, FR，２０１４年１０月，JCTVC-S0151_r1，pp.1-4

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ １９／００ − １９／９８

(57)【特許請求の範囲】

【請求項1】

ビデオ符号化システムにおけるパレット符号化を用いたビデオデータの一ブロックの符号化方法であって、
現在のブロックに関連する入力データを受信する工程と、
現在のパレット表を前記現在のブロックに決定する工程と、
パレット予測器を決定して、前記現在のパレット表を符号化する工程と、
前記パレット予測器中でメジャーカラーを再利用する前記現在のパレット表中の第１数量のメジャーカラーを表す再利用されるメジャーカラーサイズ、前記パレット予測器により予測されない前記現在のパレット表で第２数量のメジャーカラーを表す新しいメジャーカラーサイズ、および、前記現在のブロック中に存在する第３数量のメジャーカラーを表す総メジャーカラーサイズのいずれか一つ、あるいは、これらのサイズの組み合わせに対応するパレット関連サイズを決定する工程と、
前記パレット関連サイズを二値化して、Ｋ階級の Exp-Golomb コード、ユーナリ及びＫ階級の Exp-Golomb コード、あるいは、トランケーテッドユーナリ及びＫ階級の Exp-Golomb コードにしたがって、二値化パレット関連サイズを生成する工程と、および、
エントロピー符号化を、前記二値化パレット関連サイズに適用して、符号化パレット関連サイズを生成する工程とを含み、
前記パレット関連サイズは前記再利用されるメジャーカラーサイズに対応する場合には、Ｎ再利用フラグに対応するＮビットを符号化し、前記現在のパレット表中のメジャーカラー数量を減少させ、Ｎは正の整数であることを特徴とする方法。

【請求項2】

前記Ｋは、０、１、２、あるいは、３に対応することを特徴とする請求項１に記載の方法。

【請求項3】

前記トランケーテッドユーナリコードの２値の最大数は、 １、２、あるいは、３に対応することを特徴とする請求項１に記載の方法。

【請求項4】

前記二値化パレット関連サイズの２値の一部は、コンテキスト適応符号化を用いて符号化されることを特徴とする請求項１に記載の方法。

【請求項5】

前記パレット関連サイズを二値化して、前記二値化パレット関連サイズを生成する前記工程は、最大可能パレットサイズにしたがって適応的に実行されることを特徴とする請求項１に記載の方法。

【請求項6】

ビデオ符号化システムにおけるパレット符号化を用いて符号化されるビデオデータの一ブロックの復号方法であって、
現在のブロックの圧縮データを含む入力符号化ビットストリームを受信する工程と、
前記入力符号化ビットストリームから、現在のパレット表の二値化パレット関連サイズをリカバーする工程と、
Ｋ階級の Exp-Golomb コード、ユーナリ及びＫ階級の Exp-Golomb コード、あるいは、トランケーテッドユーナリ及びＫ階級の Exp-Golomb コードを、前記二値化パレット関連サイズに適用することにより、パレット関連サイズをリカバーし、前記パレット関連サイズが、パレット予測器でメジャーカラーを再利用する前記現在のパレット表中の第１数量のメジャーカラーを表す再利用されるメジャーカラーサイズ、前記パレット予測器により予測されない前記現在のパレット表中で第２数量のメジャーカラーを表す新しいメジャーカラーサイズ、および、前記現在のブロック中に存在する第三数量のメジャーカラーを表す総メジャーカラーサイズの一つ、あるいは、組み合わせに対応する工程と、
前記パレット予測器、および、前記パレット関連サイズを含むパレット情報にしたがって、前記現在のブロックの前記現在のパレット表をリカバーする工程と、
前記パレット関連サイズは前記再利用されるメジャーカラーサイズに対応する場合には、Ｎ再利用フラグに対応するＮビットを復号化し、前記現在のパレット表中のメジャーカラー数量を減少させ、Ｎは正の整数であることを特徴とする方法。

【請求項7】

前記Ｋは、０、１、２、あるいは、３に対応することを特徴とする請求項６に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

この出願は、２０１４年６月２０日に出願された米国特許仮出願番号６２/０１４９５９、２０１４年１２月２日に出願された米国特許仮出願番号６２/０８６３１９、２０１５年１月２７日に出願された６２/１０８１６５、２０１５年１月３０日に出願された米国特許仮出願番号６２/１０９８３０、２０１５年１月３０日に出願された米国特許仮出願番号６２/１０９８３６、および、２０１５年２月３日に出願された米国特許仮出願番号６２/１１１１４０から優先権を主張し、米国特許仮出願は引用によって本願に援用される。

【0002】

本発明は、ビデオデータのパレット符号化に関するものである。特に、本発明は、パレットサイズシグナリングで符号化効率を改善し、最大符号化ユニットサイズを制限して、システムの複雑性を減少させ、 ランタイプの簡単なコンテキスト適応符号化、および、パレット符号化における簡単な冗長性除去を含む各種技術に関するものである。

【背景技術】

【0003】

高効率ビデオコーディング (ＨＥＶＣ)は、近年発展している新しい符号化基準である。高効率ビデオコーディング (ＨＥＶＣ)システムにおいて、H.264/AVCの固定サイズのマクロブロックは、符号化ユニット (ＣＵ)という名のフレキシブルブロックにより代替される。ＣＵ中の画素は、同じ符号化パラメータを共有して、符号化効率を改善する。ＣＵは、ＨＥＶＣにおいて、符号化ツリーユニット(ＣＴＵ)とも称される最大ＣＵ (ＬＣＵ)から始まる。符号化ユニットの概念に加え、予測ユニット (ＰＵ)の概念もＨＥＶＣに導入される。一旦、ＣＵ階層ツリーの分割が行われると、各リーフＣＵは、予測タイプとＰＵ分割にしたがって、さらに、一つ以上の予測ユニット(ＰＵ)に分割される。スクリーンコンテンツ向け符号化のいくつかの符号化ツールが発展している。 本発明に関連するこれらのツールは、以下のように簡潔に概説される。

【0004】

パレット符号化
ＨＥＶＣ範囲拡張(RExt)の発展において、いくつかの提案が開示されて、パレット-ベースの符号化に取り組んでいる。たとえば、パレット予測と共有技術が、JCTVC-N0247 (Guo et al.,“RCE3: Results of Test 3.1 on Palette Mode for Screen Content Coding”, Joint Collaborative Team on ビデオ符号化 (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 14th Meeting: Vienna, AT, 25 July - 2 Aug. 2013 Document: JCTVC-N0247)、および、JCTVC-O0218 (Guo et al., “Evaluation of Palette Mode Coding on HM-12.0+RExt-4.1”, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 15th Meeting: Geneva, CH, 23 Oct. - 1 Nov. 2013, Document: JCTVC-O0218)で開示されている。JCTVC-N0247 とJCTVC-O0218において、各カラーコンポーネントのパレットが構成および送信される。その左側隣接ＣＵから、パレットが予測 (あるいはシェア)されて、ビットレートを減少させる。その後、所定ブロック中の全画素は、それらのパレットインデックスを用いて符号化される。JCTVC-N0247による符号化プロセスの例は以下のように示される。

【0005】

1.パレットの送信:カラーインデックステーブル(パレット表とも称される)がまず送信され、次に、パレットエレメンツ(すなわち、カラー値)が送信される。
2. 画素値の送信: ＣＵ中の画素が、ラスター走査順序で符号化される。 一つ以上の画素の各群において、まず、ランベースモードのフラグが送信されて、 “コピーインデックスモード”あるいは“コピー上方モード（copy above mode）”が用いられるかどうか示す。
2.1 “コピーインデックスモード”:コピーインデックスモードにおいて、run 値を示す“palette_run”(たとえば、Ｍ)に従って、パレットインデックスがまずシグナリングされる。この開示において、用語 palette_run は、pixel_runとも称される。ラン値は、Ｍサンプルの総数がすべて、コピーインデックスモードを用いて符号化されることを示す。ビットストリームでシグナリングされるのと同じパレットインデックスを有するので、それ以上の情報は、現在の位置および続くＭ個の位置に送信される必要がない。パレットインデックス (たとえば、i) は、さらに、全部で３個のカラーコンポーネントによりシェアされ、YUV カラースペースのケースにおいて、再構成された画素値が、(Y, U, V) = (paletteY[i], paletteU[i], paletteV[i])であることを意味する。
2.2 “コピー上方モード”:コピー上方モードにおいて、一値 “copy_run” (たとえば、Ｎ)が送信されて、以下のＮ個の位置 (現在のものを含む)に示され、パレットインデックスは、ロウ上方中の対応するパレットインデックスと同じである。
3. 剰余の送信:ステージ２で送信されるパレットインデックスが画素値に転換されるとともに、画素値に戻されて、予測として用いられる。剰余情報は、ＨＥＶＣ剰余コーディングを用いて送信され、且つ、再構成の予測に加えられる。

【0006】

この開示において、 “コピーインデックスモード”と“コピー上方モード” 両方は、パレットインデックス符号化に用いるコピーモードと称される。一方、以下の記述において、パレットモードは、パレット符号化モードとも称される。

【0007】

JCTVC-N0247において、各コンポーネントのパレットが再構成および送信される。パレットは、その左側隣接ＣＵから予測(シェア)されて、ビットレートを減少させる。JCTVC-O0218において、パレット中の各素子は三重項であり、３個のカラーコンポーネンツの特定の組み合わせを示す。さらに、ＣＵを横切るパレットの予測符号化が除去される。

【0008】

JCTVC-O0218 に類似する別のパレット符号化技術も開示される。左側ＣＵから全体のパレット表を予測することに代わって、パレット中の個別のパレットカラーエントリーは、上方ＣＵ、あるいは、左側ＣＵ中の正確な対応パレットカラーエントリーから予測される。
JCTVC-O0182 (Guo et al., “AHG8: Major-color-based screen content coding”, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 15th Meeting: Geneva, CH, 23 Oct. - 1 Nov. 2013, Document: JCTVC-O0182)で開示されるように、画素パレットインデックス値の送信において、予測符号化方法がインデックスに適用される。 三つのタイプのラインモード、すなわち、水平モード、垂直モード、および、通常モードが用いられて、各インデックスラインを符号化する。水平モードにおいて、同じライン中の全インデックスは同じ値を有する。値が上方画素ラインの第１画素と同じ場合、ラインモードシグナリングビットだけが送信される。そうでなければ、インデックス値も送信される。垂直モードにおいて、現在のインデックスラインが上方インデックスラインと同じであることを示す。これにより、ラインモードシグナリングビットだけが送信される。通常モードにおいて、ライン中のインデックスは個別に予測される。各インデックス位置において、左、あるいは、上方の隣接が予測器として用いられ、予測符号がデコーダに送信される。

【0009】

さらに、画素は、JCTVC-O0182にしたがって、メジャーカラー画素 (パレットカラーを指すパレットインデックスを有する)とエスケープ画素に分類される。メジャーカラー画素において、デコーダ側で、メジャーカラーインデックス (すなわち、パレットインデックス)とパレット表にしたがって、画素値が再構成される。エスケープ画素において、画素値が、さらに、ビットストリームでシグナリングされる。

【0010】

パレット表シグナリング
スクリーンコンテンツ向け符号化 (SCC)基準の参照ソフトウェア、 SCM-2.0 (Joshi et al., Screen content coding test model 2 (SCM 2), Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 18th Meeting: Sapporo, JP, July 2014, Document No.: JCTVC-R1014)において、改善パレットスキームは、JCTVC-R0348 (Onno, et al., Suggested combined software and text for run-based palette mode, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 18th Meeting: Sapporo, JP, July 2014, Document No.: JCTVC-R0348)により整合される。前のパレット符号化ＣＵのパレット表は、現在のパレット表符号化の予測器（predictor）として用いられる。パレット表符号化において、現在のパレット表は、前の符号化パレット表 (パレット予測器:palette predictor)中のどのパレットカラーが再利用されるかを選択することにより、あるいは、新しいパレットカラーを送信することによりシグナリングされる。現在のパレットのサイズは、予測パレット (すなわち、numPredPreviousPalette)のサイズプラス送信されるパレット(すなわち、num_signalled_palette_entries)のサイズとして設定される。予測パレットは、前の再構成されるパレット符号化ＣＵから導出されるパレットである。現在のＣＵをパレットモードとして符号化するとき、予測パレットを用いて予測されないそれらのパレットカラーが、直接、ビットストリーム (すなわち、シグナリングされたエントリー)中で送信される。

【0011】

パレット更新の例が以下で示される。この例において、現在のＣＵは、６に等しいパレットサイズを有するパレットモードで符号化される。６個のメジャーカラーのうち３個はパレット予測器 (numPredPreviousPalette = 3)から予測され、残りの３個は、ビットストリームにより直接送信される。送信される３個のカラーは、以下の例の構文を用いてシグナリングされる。

【0012】

num_signalled_palette_entries = 3
for( cIdx = 0; cIdx < 3; cIdx++ ) // signal colors for different components
for( i = 0; i < num_signalled_palette_entries; i++ )
palette_entries[ cIdx ][ numPredPreviousPalette + i ]

【0013】

この例において、パレットサイズは６なので、０から５のパレットインデックスが用いられて、パレットカラー表中のメジャーカラーエントリーを示す。３個の予測パレットカラーは、インデックス０から２で示される。したがって、三つの新しいパレットエントリーが、３から５のインデックスに送信される。

【0014】

SCM-2.0において、波状並列処理 (ＷＰＰ)が適用されない場合、パレット予測器表は、各スライスの開始、あるいは、各タイルの開始で初期化(リセット)される。ＷＰＰが適用される場合、最後の符号化パレット表は、各スライスの開始、あるいは、各タイルの開始で初期化(リセット)されるだけでなく、各ＣＴＵロウの開始でも、初期化(リセット)される。

【0015】

波状並列処理 (ＷＰＰ)
ＨＥＶＣにおいて、ＷＰＰがサポートされ、符号化ツリーユニット(ＣＴＵ)の各ロウは、複数の符号化、あるいは、復号スレッドにより、サブストリームと並行して処理される。符号化効率の低下を制限するため、処理順序の波面パターンは、空間隣接における依存関係が変化しないように確保する。一方、各ＣＴＵロウの開始で、ＣＡＢＡＣ状態は、上方ＣＴＵロウで、同期点のＣＡＢＡＣ状態に基づいて初期化される。たとえば、図１に示されるように、同期点は、上方ＣＴＵロウからの第２ＣＴＵの最後のＣＵで、並列処理がＣＴＵロウに適用される。さらに、この例において、各現在のＣＴＵのパレット符号化 (図１の“X”)が、その左、左上、上方、および、真上のＣＴＵに基づくと仮定する。頂部ＣＴＵロウにおいて、パレット処理は、左側ＣＴＵだけに基づく。さらに、ＣＡＢＡＣエンジンは、各ＣＴＵロウ（row）の終わりでフラッシュされるとともに、バイトアラインメントは、各サブストリーム終わりで強制される。ＷＰＰサブストリームのエントリーポーンは、波面を含むスライスのスライスヘッダーで、バイトオフセットとしてシグナリングされる。

【0016】

図１において、各ブロックは一ＣＴＵを代表するとともに、一ピクチャ中に４個のＣＴＵロウがある。各ＣＴＵロウは、符号化、あるいは、復号スレッドにより独立して処理される波面サブストリームを形成する。“X”符号は、複数のスレッドの処理における現在のＣＴＵを示す。現在のＣＴＵは、真上のＣＴＵに依存するので、現在のＣＴＵの処理は、真上のＣＴＵの完了を待たなくてはならない。これにより、隣接ＣＴＵロウの２個の処理スレッド間に２個のＣＴＵ遅延があるので、データ依存 (たとえば、空間画素と動きベクトル(MVs)) が防止される。このほか、上方ＣＴＵロウの第２ＣＴＵが処理された後、各ＣＴＵロウの第１ＣＴＵのＣＡＢＡＣ状態は、得られる状態で初期化される。たとえば、上方ＣＴＵロウの第２ＣＴＵ中の最後のＣＵ ( “p2”により示される)が処理された後、第２ＣＴＵロウ中の第１ＣＴＵの第１ＣＵ ( “p1”により示される)が初期化される。依存は、“p1”から “p2”を指し示す曲線矢印線により示される。各ＣＴＵロウの第１ＣＴＵに対する同様の依存が曲線矢印により示される。これは、各ＣＴＵロウにスライス初期化状態を用いるよりも、ＣＴＵの第１カラムに沿ってより速い学習の可能性を可能にする。上方ＣＴＵロウの第２ＣＴＵは、常に、現在のＣＴＵロウに利用できるので、並列処理がこの波面構造を用いて達成される。各現在のＣＴＵにおいて、処理は左側ＣＴＵに基づく。これにより、左側ＣＴＵの最後のＣＵが処理されるまで待たなければならない。図１に示されるように、現在のＣＴＵ中の第１ＣＵ( “p3”により示される)は、左側ＣＴＵの最後のＣＵ ( “p4”により示される)の終了をまたなければならない。また、依存は、“p3”から“p4”を指し示す曲線矢印線により示される。左側ＣＴＵに対する同様の依存は、処理されるＣＴＵ( “X”により示される)の曲線矢印により示される。

【0017】

Intra ブロックコピー
Intra-ブロックコピー (IntraBC)という名の新しいIntra 符号化モードが用いられる。元は AHG8でBudagaviにより提案されたIntraBC 技術: Video coding using Intra motion compensation, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 13th Meeting: Incheon, KR, 18-26 Apr. 2013, Document: JCTVC-M0350 (以下、 JCTVC-M0350)。JCTVC-M0350による例が図２に示され、現在の符号化ユニット (ＣＵ、２１０)は Intra MC (motion compensation)を用いて符号化される。予測ブロック (２２０)は、現在のＣＵと変位ベクトル (２１２)から配置される。この例において、検索領域が、現在のＣＴＵ (符号化ツリーユニット)、左側ＣＴＵ、および、左側-左側ＣＴＵに制限される。予測ブロックは、すでに再構成されている領域から得られる。その後、変位ベクトル (すなわち、ＭＶ)、および、現在のＣＵの剰余が符号化される。ＨＥＶＣは、ＣＴＵとＣＵブロック構造を基本単位として、ビデオデータを符号化することは周知のとおりである。各ピクチャはＣＴＵに分割され、各ＣＴＵが、ＣＵに分割される。予測位相期間中、各ＣＵは、予測ユニット (PUs)と称される複数のブロックに分割されて、予測プロセスを実行する。予測残余が各ＣＵに形成された後、各ＣＵに関連する剰余が、変換ユニット(TUs)と称される複数のブロックに分割されて、変換(たとえば、離散余弦変換 (DCT))を適用する。

【0018】

JCTVC-M0350において、Intra MC は、少なくとも以下の領域中のInter 予測に用いられる動き補償と異なる:
・ Inter 予測が2-D 動き推定を用いる間、ＭＶが、Intra MC (すなわち、水平、あるいは、垂直)の1-D に制限される。ＭＶは、Intra コピー予測のブロックベクトル(BVs)とも称される。
・ Inter 予測が指数-Golombを用いる間、二値化は、Intra MCの固定長さである。
・ Intra MC は新しい構文要素を導入して、 ＭＶが水平か垂直化シグナリングする。

【0019】

JCTVC-M0350に基づいて、いくつかの修正は、 Non-RCE3で、Pang, et alにより開示される: Intra Motion Compensation with 2-D MVs, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 14th Meeting: Vienna, AT, 25 July - 2 Aug. 2013, Document: JCTVC-N0256 (以下、JCTVC- N0256)。まず、Intra MC が拡張されて、2-D MVをサポートするので、両ＭＶコンポーネンツが同時に非ゼロになる。これは、本来のアプローチよりさらなるフレキシブル性をIntra MC に提供し、ＭＶが、水平、あるいは、垂直に正確に制限される。

【0020】

JCTVC-N0256において、二個のＭＶ符号化方法が開示される:
・ 方法１- 動きベクトル予測. 左側、あるいは、上方ＭＶがＭＶ予測器として選択されるとともに、得られた動きベクトル差異 (ＭＶＤ)が符号化される。フラグが用いられて、ＭＶＤがゼロであるかどうか示す。ＭＶＤがゼロでないとき、3rd orderの指数-Golomb コードが用いられて、ＭＶＤの残りの絶対値を符号化する。別のフラグが用いられて、サインを符号化する。
・ 方法２:動きベクトル予測なし ＭＶは、ＨＥＶＣにおいて、ＭＶＤに用いられる指数-Golomb コードを用いて符号化される。

【0021】

JCTVC-N0256 で開示される別の差異は、2-D Intra MC が、さらに、パイプラインに優しいアプローチと結合されることである:
1.補間フィルターが用いられない
2. ＭＶ検索領域が制限される。二ケースが開示される:
a. 検索領域が、現在のＣＴＵと左側ＣＴＵである、あるいは、
b. 検索領域が、現在のＣＴＵと左側ＣＴＵの最右の４カラムサンプルである。

【0022】

JCTVC-N0256で提案される方法において、2-D Intra MC、補間フィルターの除去、および、現在のＣＴＵと左側ＣＴＵへの検索領域制限はすでに、新バージョンのドラフト標準中で採用されている。JCTVC-N0256 に対応するＣＵレベル構文が、 High Efficiency Video Coding (ＨＥＶＣ) Range Extension text specification: Draft 4 (RExt Draft 4)(Flynn, et al., Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 14th Meeting: Vienna, AT, 25 July - 2 Aug. 2013, Document: JCTVC-N1005)に組み込まれている。

【0023】

さらに、フルフレームのIntraBC が、 JCTVC-Q0031 (Draft text of screen content coding technology proposal by Qualcomm, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 17th Meeting: Valencia, ES, 27 March - 4 April 2014, Document: JCTVC-Q0031)とJCTVC-Q0035 (Description of screen content coding technology proposal by Microsoft, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 17th Meeting: Valencia, ES, 27 March - 4 April 2014, Document: JCTVC-Q0035)で開示されている。フルフレームの IntraBC は、検索領域制限を除去して、 IntraBCの符号化効率をさらに改善する。これにより、再構成されるブロックすべては、現在のＣＵにより引用され、現在のＣＵと全ての前の符号化ＣＵ間にデータ依存を発生させる。フルフレームの IntraBC は、本来の IntraBCより優れているが、データ依存は、復号プロセス期間に並列処理を使用するのを防止し、特に、ＨＥＶＣ中で、タイルプロセス、あるいは、波面並列処理(ＷＰＰ)を可能にする。

【0024】

パレットインデックスマップ走査順序
SCM-2.0 パレットモード符号化において、図３に示されるように、トラバーススキャンが、インデックスマップ符号化に用いられる。図３は、８×８ブロックのトラバーススキャンを示す。トラバーススキャンにおいて、スキャニング順序が水平であるとき、偶数ロウのスキャンは左から右、奇数ロウのスキャンは右から左である。トラバーススキャンは、さらに、垂直方向に適用され、スキャンは、偶数カラムにおいて上から下で、奇数カラムにおいて下から上である。トラバーススキャンは、パレットモードにおいて、全ブロックサイズに適用される。さらに、符号化効率を改善する、あるいは、パレットモードで生成される構文要素の複雑性を減少させる方法を開発させることが望まれる。

【発明の概要】

【発明が解決しようとする課題】

【0025】

符号化効率を改善する、あるいは、ビデオ符号化システムで生成されるパレット符号化に関連する構文の複雑性を低下させる方法が開示される。

【課題を解決するための手段】

【0026】

本発明の実施態様によると、現在のブロックサイズはpre-definedblock サイズと照合される。現在のブロックサイズがpre-definedblock サイズより大きい場合、現在の符号化モードは、パレット符号化モードを除く第一符号化群から選択される。現在のブロックサイズが、pre-definedblock サイズ以下である場合、現在の符号化モードは、パレット符号化モードを含む第２符号化群から選択される。その後、現在のブロックは、選択される現在の符号化モードにしたがって符号化（encode）、あるいは、復号(decode)される。pre-definedblockサイズは、３２×３２、あるいは、最大変換ユニットサイズに対応する。現在のブロックサイズがpre-definedblock サイズより大きい場合、パレットモードフラグはゼロであると推定されて、パレット符号化モードが、現在の符号化ユニットに用いられないことを示す。明示的に送信される代わりに、パレットモードフラグもゼロに制限されて、パレット符号化モードが現在の符号化ユニットに用いられないことを示す。一実施態様において、パレットモードフラグが、パレット符号化モードが現在の符号化ユニットに用いられるとともに、現在の符号化ユニットがpre-definedblock サイズより大きいことを示す場合、現在の符号化ユニットが、サイズがpre-definedblock サイズに等しい複数のブロックに分割され、各ブロックが、パレット符号化モードにより符号化される。各ブロックは、個別のパレット符号化構文を用いる。

【0027】

さらに別の実施態様によると、Ｋ階級の Exp-Golomb コードを含む一コードを用いて、パレット関連サイズがさらに効率的に符号化される。パレット関連サイズは、パレット予測でメジャーカラーを再利用する現在のパレット表中の第一数量のメジャーカラーを表す再利用されるメジャーカラーサイズ、パレット予測器により予測されない現在のパレット表中の第２数量のメジャーカラーを表す新しいメジャーカラーサイズ、あるいは、現在のブロック中に現れる第３数量のメジャーカラーを表す総メジャーカラーサイズに対応する。パレット関連サイズは、再利用されるメジャーカラーサイズ、新しいメジャーカラーサイズ、および、総メジャーカラーサイズの組み合わせに対応する。一 Ｋ階級の Exp-Golomb コード、一Ｋ階級の Exp-Golomb コードプラス一ユーナリコード、あるいは、一Ｋ階級の Exp-Golomb コードプラス一トランケーテッドユーナリコードにしたがって、パレット関連サイズが二値化されて、二値化パレット関連サイズを生成する。その後、エントロピー符号化が二値化パレット関連サイズに適用されて、符号化パレット関連サイズを生成する。Ｋは、０、１、２、あるいは、３に対応する。一トランケーテッドユーナリコードのビットの最大数は、１、２、あるいは、３に対応する。二値化パレット関連サイズの２値の一部は、コンテキスト適応符号化を用いて符号化される。パレット関連サイズが再利用されるメジャーカラーサイズに対応する場合、第１Ｎ再利用フラグに対応する第一Ｎビットが符号化されて、現在のパレット中のメジャーカラーの第１数量を減少させ、Ｎは正の整数である。さらに、パレット関連サイズを二値化して、二値化パレット関連サイズを生成するのは、最大可能パレットサイズにしたがって、適応的に実行される。デコーダ側の類似プロセスも開示される。

【0028】

さらに別の実施態様によると、単一コンテキストを有するコンテキスト適応符号化が用いられて、パレットランタイプを符号化する。現在の画素がコピーモードで符号化される場合、現在の画素のパレットランタイプが決定され、パレットランタイプは、コピー上方モード、あるいは、コピーインデックスモードに対応する。その後、単一コンテキストを有し、且つ、現在の画素上方に位置する任意の前に符号化された画素に関連する任意の前に符号化されたパレットランタイプに依存がないコンテキスト適応エントロピー符号化を用いて、パレットランタイプが符号化される。デコーダ側の類似プロセスも開示される。

【0029】

さらに別の実施態様によると、冗長インデックス除去は、スキャニング順序で、前の画素に対応するコピーモードに基づいて、適応的に実行される。前の画素がコピーインデックスモードである場合、前の画素インデックスに対応する冗長インデックスが、パレットセットから除去されて、更新されるパレットセットを形成する。前の画素がコピー上方モードである場合、冗長インデックス除去が省略されるとともに、パレットセットは、更新されるパレットセットとして用いられ、冗長性除去がない。更新されるパレットセットにしたがって、現在の画素の現在のインデックスが符号化、あるいは、復号される。

【図面の簡単な説明】

【0030】

【図1】４個の符号化ツリーユニット (CTU)ロウを有する波状並列処理 (ＷＰＰ)を示す図である。

【図2】スクリーンコンテンツ向け符号化 (SCC)のIntraブロックコピー (IntraBC) 符号化モードを示す図である。

【図3】８×８ブロックの水平トラバーススキャンを示し、偶数ロウのスキャンは左から右、奇数ロウのスキャンは右から左である。

【図4】コピー上方モードの例を示す図で、連続画素のインデックスは、上方ロウ中に位置する画素のインデックスからコピーされる。

【図5】コピー上方モードの例を示す図で、連続画素のインデックスだけでなく、画素値も、上方ロウ中に位置する画素からコピーされる。

【図6】符号化ユニット (ＣＵ)を横切る画素をコピーするコピー上方モードの例を示す図で、特定インデックス値 (すなわち、Ｎ)を割り当てて、インデックス値が、符号化ユニット (ＣＵ)を横切ってコピーされることを示す。

【図7】パディングインデックス0と対応する画素値により、符号化ユニット (ＣＵ)を横切る画素をコピーするコピー上方モードの例を示す図である。

【図8】特別インデックスＮと画素値Ｘをパディングすることによる符号化ユニット (ＣＵ)を横切る画素をコピーするコピー上方モードの例を示す図である。

【図9A】インデックス Iabove が、隣接符号化ユニット中で上方画素から直接コピーされる例を示す図である。

【図9B】Iaboveが、上方画素からコピーされる例を示す図で、上方画素のインデックスが、隣接符号化ユニット中で、上方画素から順にコピーされる。

【図10】６４×６４ブロックの水平トラバーススキャンを示す図で、偶数ロウのスキャンは左から右、および、奇数ロウのスキャンは右から左である。

【図11A】矢印の太ジグザグ線により示される左上、左下、右上、および、右下に対応する４個の３２×３２ブロックを横切るスキャニング順序の例を示す図である。

【図11B】４個の３２×３２ブロックを横切る図１１Ａに対応する完成したスキャンパターンを示す図である。

【図12A】矢印の太ジグザグ線により示される左上、右上、左下、および、右下に対応する４個の３２×３２ブロックを横切るスキャニング順序の例を示す図である。

【図12B】４個の３２×３２ブロックを横切る図１２Ａに対応する完成したスキャンパターンを示す図である。

【図13A】走査順序、および、図１１Ｂの走査順序の幾何学的位置に基づいた上方サンプル位置導出の例を示す図である。

【図13B】走査順序、および、図１２Ｂの走査順序の幾何学的位置に基づいた上方サンプル位置導出の例を示す図である。

【図14A】４個の３２×３２ブロックを横切る垂直-第一走査順序の例を示す図である。

【図14B】４個の３２×３２ブロックを横切る垂直-第一走査順序、および、各３２×３２ブロックの垂直ラスター走査の例を示す図である。

【図15A】４個の３２×３２ブロックを横切る水平-第一走査順序の例を示す図である。

【図15B】４個の３２×３２ブロックを横切る水平-第一走査順序、および、各３２×３２ブロックの水平ラスター走査の例を示す図である。

【図16】本発明の一実施態様による構文設計を組み込んだ構文解析のフローチャートである。

【図17】本発明の一実施態様による各ラインの第一インデックス符号化の例を示す図である。

【図18】本発明の一実施態様による構文設計を組み込んだ構文解析の別の例のフローチャートである。

【図19A】シグナリングインデックス自身を代替し、フラグを使用して、インデックスと上方が相同であることを示す図で、フラグが、画素上方からのインデックス “３”を示す。

【図19B】シグナリングインデックス自身を代替し、フラグを使用して、インデックスが上方と相同であること示す図で、フラグが、 画素上方からのインデックス “１” であることを示す。

【図20】本発明の一実施態様による構文設計を組み込んだ構文解析のさらに別の例のフローチャートである。

【図21】本発明の一実施態様による任意のコピーモードの例を示す図である。

【発明を実施するための形態】

【0031】

本発明は、以下で、パレット符号化に関連するいくつかの態様を対象にする。

【0032】

パレットサイズシグナリング
JCTVC-O0218において、エンコーダは、まず、再利用フラグを符号化して、再利用されるパレット予測器中のメジャーカラーの数量を示す。その後、新しいメジャーカラーサイズが符号化されて、新しいメジャーカラーの数量がシグナリングされることを示す。新しいメジャーカラーサイズの数量は、ユーナリコード、あるいは、トランケーテッドユーナリコードを用いて符号化される。JCTVC-O0182において、総メジャーカラーサイズの数量は、固定長さコードを用いて符号化される。

【0033】

しかし、本発明の一実施態様によると、ユーナリコード、トランケーテッドユーナリコード、および、固定長さコードの二値化方法は十分ではない。これにより、Ｋ階級の Exp-Golomb コード、トランケーテッドＫ階級の Exp-Golomb コード、ユーナリコードプラスＫ階級の Exp-Golomb コード、あるいは、トランケーテッドユーナリコードプラスＫ階級の Exp-Golomb コードが、パレット関連サイズ、たとえば、新しいメジャーカラーサイズの数量、パレット予測器中で再利用されるメジャーカラーサイズの数量、総メジャーカラーサイズ、あるいは、それらの任意の組み合わせの二値化に用いられる。
たとえば、表１に示されるように、二値化は、最大長さが３ビットのトランケーテッドユーナリ (ＴＵ)コードプラス３に等しいＫ(すなわち、EG-3 コード)のＫ階級の Exp-Golomb コードを用いる。

【0034】

【表1】

【0035】

本発明の実施態様によると、表１の例において、Ｋは３に等しく、Ｋは、０、１、２、３、あるいは、４である。一方、本発明の実施態様によると、ＴＵコードの最大長さは、１、２、あるいは、３である。二値化パレット関連サイズの２値の一部は、コンテキストで符号化される。たとえば、最初の三つの二値がコンテキストにより符号化される。メジャーカラーサイズの数量はＭで分割されて符号化する。たとえば、メジャーカラーサイズが１７、Ｍが４である場合、符号化サイズは、天井(17/4) = 5、天井() は、天井関数(ceiling function)に対応する。

【0036】

予測器中のいくつかの再利用フラグは、常に、直接符号化される。たとえば、第１ Ｎ 再利用フラグに対応する第１ Ｎ (たとえば、４)ビットは、ラン長さ符号化に代わって、直接符号化される。これにより、再利用フラグの数量が減少する。 二値化コード名は、最大可能サイズにしたがって、適応的に変化する。たとえば、最大サイズが３である場合、ＴＵコードのためには３ビットで十分である。この場合、EG-K コードは必要なく、且つ、 EG-K 部分は省略される。

【0037】

上方画素、あるいは、隣接ＣＵ画素 (NCPs)からの予測
SCM 2.0において、図４に示されるように、画素が、copy_run 構文によりシグナリングされるとき、上方画素のインデックス値をコピーして、インデックス値を用いる。再構成される画素値は、表２に示されるように、パレットから導出される。

【0038】

【表2】

【0039】

本発明の一実施態様によると、画素が、copy_run 構文をシグナリングすることにより符号化されるとき、図５に示されるように、画素は、上方画素の画素インデックスだけでなく、上方画素の画素値もコピーする。デコーダは、パレットを参照せずに、コピーされる画素値からcopy_run モードの画素を再構成することができる。

【0040】

本発明の別の実施態様によると、特別な符号(たとえば、“A”)は、構文解析段階で、copy_run (copy above)によりカバーされる全位置に割り当てられる。その後、再構成段階で、デコーダが“A”に直面しても、上方から画素値をコピーする。

【0041】

また、index_run の画素値は、関連インデックスなしで、直接シグナリングされる。この場合、パレット表とパレット表に関連する別の情報は、符号化される必要がない。

【0042】

上方画素が、別のＣＵからＣＵ境界を横切る場合、本発明による実施態様は、特別インデックスを、Ｎと表記される隣接ＣＵ画素(NCP)に割り当てる。図６に示されるように、一画素が copy_run 構文によりシグナリングされるとき、画素上方の画素インデックス (N)だけでなく、画素上方の画素値もコピーする。特別値Ｎは、全ての可能なインデックス値 (たとえば、最大インデックス値 + 1)と異なる値である。

【0043】

予測が左側ＮＣＰから来る場合、類似方法が適用され、この場合のＮＣＰは、左側ＮＣＰである。

【0044】

ＮＣＰのパディングインデックスと画素値
上方ＣＵが無効である場合、デコーダは、所定の、あるいは、導出された値の上方ＮＣＰのインデックスと画素値を置換する。置換方法は、インデックスのコピー (たとえば、図４)、値のコピー、および、インデックスと値のコピー両方(たとえば、図５)の場合にも適用される。

【0045】

デコーダ側の本発明の一実施態様を説明する例が図７に示され、上方ＮＣＰのインデックスと画素値は、すべて、０に等しく、且つ、それぞれ、エントリー中のパレットカラーは、それぞれ、０である。

【0046】

デコーダ側の本発明の一実施態様を説明する別の例が図８に示され、上方ＮＣＰのインデックスと画素値はＮに等しく、且つ、所定の、あるいは、導出された画素値 X は、それぞれ、図８に示される。画素値 X は、YUV フォーマットの(127, 0, 0)あるいは(128, 0, 0) 、YUV フォーマットの(127, 127, 127) あるいは (128, 128, 128)である。

【0047】

一実施態様において、エンコーダ、および、デコーダは、上方インデックスを最も頻繁に発生するインデックスで置換するとともに、画素値を対応する画素値に置換することができる。

【0048】

冗長インデックス除去
SCM 2.0において、前のラン (すなわち、前の画素に適用されるコピーモード) がコピー上方ラン（copy above run）である場合、現在の画素が、新しいインデックスランの第１画素であるとき、現在の画素 (P_c)は、上方画素 (P_a)のインデックスと同一インデックスを有することができない。そうでなければ、現在の画素は前のランに統合される。この場合、冗長性除去により、現在の画素のインデックス(I_c)が符号化される。上方画素 (P_a) のインデックスはI_above と称され、前の画素 (たとえば、左側画素 P_left)のインデックスはI_left と称される。前の画素は、スキャン方向に基づいて、右(水平走査)、上方、あるいは、下方画素(垂直走査)になる。上方画素は、スキャニング方向に基づいて、現在の画素上方のロウ、あるいは、現在の画素の左側のカラムになる。

【0049】

本発明の一実施態様によると、ラインバッファ要求を減少させるため、前の画素 (たとえば、左側画素 P_left)が、コピー上方モードを用いて符号化されるとともに、I_above が水平走査で上方ＣＵから、あるいは、垂直走査で左側ＣＵからである場合、冗長インデックス除去が無効になり、上方画素のインデックスを保存、および、アクセスする必要がない。つまり、前の画素が、コピーインデックスモードを用いて符号化される場合のみ、前の画素インデックスに対応する冗長インデックスがパレットセットから除去されて、更新されるパレットセットを形成して、現在の画素のインデックスを符号化、あるいは、復号する。図９Ａは、 I_above が、隣接ＣＵから直接コピーされる場合を説明する。図９Ｂは、I_above が上方画素からコピーされる場合を説明し、上方画素のインデックスは、順に、隣接ＣＵからコピーされる。

【0050】

一実施態様において、P_left がコピー上方モードで符号化されるとともに、現在の画素が、現在のＣＵの第一Ｎロウにあるとき、冗長性除去が無効になる。
別の実施態様において、 P_left がコピー上方モードで符号化されるとき、インデックス冗長性除去は、全インデックスに対して無効になる。

【0051】

さらに別の実施態様によると、冗長インデックス除去は、P_left.のモードにかかわらず、全インデックスに対して無効になる。

【0052】

一実施態様において、I_above がＮに等しい場合(NCPsから)、P_left がコピー上方モードで符号化されるとき、冗長インデックス除去が無効になる。

【0053】

６４×６４パレット符号化ブロックのサブブロックスキャン
SCM-2.0 パレットモードにおいて、トラバーススキャニングが、６４×６４ブロックを含む全ブロックサイズに適用される。６４×６４ブロックのトラバーススキャンは図１０で示される。

【0054】

ＨＥＶＣにおいて、符号化ユニット (ＣＵ)は６４×６４の大きさであるのに対し、最大処理ユニットは３２×３２である。これは、最大変換ユニット (ＴＵ)が３２×３２で、且つ、Intra あるいは Inter モードで符号化される６４×６４ＣＵが、構文解析係数と再構成のために、４個の３２×３２ブロックに分割されるからである。ＨＥＶＣ復号のために、６４×６４バッファを使用する必要がない。

【0055】

しかし、SCM-2.0 パレットモード符号化において、６４×６４トラバーススキャンが用いられ、エンコーダ、および、デコーダにとっては、６４×６４バッファを必要とする。これにより、エンコーダ、および、デコーダは、６４×６４ブロックを処理することができる処理ユニットの処理能力に適合する必要がある。よって、実行コストと複雑性を増加させる。

【0056】

本発明の一実施態様において、図１１Ａと図１１Ｂ、および、図１２Ａと図１２Ｂに示されるように、６４×６４トラバーススキャンが、４個の３２×３２トラバーススキャンに分割される。一実施態様によると、６４×６４ブロックは、４個の３２×３２ブロックに分割され、４個の３２×３２ブロックを横切る二個の異なるスキャンパターンが、それぞれ、図１１Ａと図１２Ａ に示される。図１１Ａにおいて、４個の３２×３２ブロックを横切るスキャニング順序は、矢印の太ジグザグ線により示されるように、左上、左下、右上、そして、右下である。図１２Ａにおいて、４個の３２×３２ブロックを横切るスキャニング順序は、矢印の太ジグザグ線により示されるように、左上、右上、左下、そして、右下である。各３２×３２ブロックに対し、３２×３２トラバーススキャンが適用される。図１１Ｂは、完成したスキャンパターンが、４個の３２×３２ブロックを横切る図１１Ａに対応することを示す。図１２Ｂは、完成したスキャンパターンが、４個の３２×３２ブロックを横切る図１２Ａに対応することを示す。この走査順序において、６４×６４パレットＣＵが４個の３２×３２ブロックとして扱われるとともに、処理ユニットが３２×３２に等しいサイズに適合する。これにより、３２×３２バッファ、および、いくつかのラインバッファだけが要求される。

【0057】

copy_above_run モードにおいて、上方サンプル位置は、走査順序位置、あるいは、幾何学的位置から導出される。上方サンプル位置が、走査順序から導出される場合、上方サンプルのスキャンインデックスは、現在のスキャンインデックスマイナス３２に等しい。たとえば、現在の画素Ａにおいて、上方サンプル位置が、走査順序から導出される場合、その上方サンプル位置は画素Ｂである。図１３ＡとＢに示されるように、上方サンプル位置が、幾何学的位置から導出される場合、その上方サンプル位置は画素Ｃであり、図１３Ａは図１１Ｂの走査順序に対応し、図１３Ｂは図１２Ｂの走査順序に対応する。さらに、混合サンプル位置導出が適用される。たとえば、右上の３２×３２ブロックの第一ロウにおいて、走査順序位置導出を用いて、その上方画素を探し、別のロウは、幾何学導出を用いることができる。

【0058】

現在のサンプルにおいて、上方サンプルが可用でない場合、 copy_above_run モード ( “コピー上方モード”とも称される) は適用できない。たとえば、上方サンプル位置が幾何学的位置から導出される場合、右上３２×３２ブロックの第一ロウのパレット予測モードは、copy_above_run モードにならない。

【0059】

パレットランの最大数は制限される。さらに、前の符号化パレットランモードが copy_above_run であるとともに、上方サンプルが可用ではないとき、冗長インデックス除去は適用されない。図１３Ｂは、この場合の例を説明する。画素Ｄの最後の符号化パレットランモードがcopy_above_run で、且つ、 run が画素Ｅから始まる場合、copy_above_run は、画素Ｆで終了しなければならない。画素Ｅのパレットランの最大数は (scan_order_F - scan_order_E)である。画素Ｄのパレットランモードは、インデックスランモードのはずである。画素Ｄにおいて、その上方サンプルのインデックスが可用ではないので、冗長インデックス除去は適用されない。

【0060】

サブブロックのサイズは、最大変換ユニット (ＴＵ)サイズで揃えられる。各サブブロッは独立している。

【0061】

非-トラバーススキャンの６４×６４パレット符号化ブロックのサブブロックスキャン
トラバーススキャンにおける上述のサブブロックスキャン、および、パレット予測導出も、ラスター走査に適用される。ラスター走査が用いられる場合、６４×６４ブロックは、さらに、４個の３２×３２ブロックに分割される。図１１Ａ-Ｂ、図１２Ａ-Ｂ、および、図１３Ａ-Ｂ中の各３２×３２ブロック内の走査順序は、ラスター走査に変化する。４個の３２×３２ブロックを横切る走査順序は、まず、図１４Ａに示されるように、垂直であるか、あるいは、図１５Ａで示されるように、水平である。図１４Ｂにおいて、垂直ラスター走査は各サブブロック中に適用され、図１５Ｂにおいて、水平ラスター走査は各サブブロック中に適用される。

【0062】

パレット符号化に用いられる６４×６４ＣＵの推定されたパレットモードフラグ、あるいは、強制ＣＵ分割
ブロックスキャニング順序の不規則構造を回避するため、パレット符号化は、所定ブロックサイズより大きいサイズのＣＵに対して省略される。一実施態様において、所定ブロックサイズは３２×３２である。したがって、６４×６４ＣＵにおいて、palette_mode_flag は、シグナリングなしで、０として導出される。表３は構文表で、注記(3-1)の条件 (nCbS != 64)に示されるように、構文 palette_mode_flag[x0][y0] がブロックサイズ６４×６４に対して省略される。

【0063】

【表3】

【0064】

別の実施態様において、ＣＵサイズが６４×６４に等しく、且つ、palette_mode_flag が１であるとき、現在のＣＵは、４個の３２×３２パレット符号化ブロックに分割される。各ブロックは、パレット符号化のその個別の構文を用いる。

【0065】

さらに別の実施態様によると、エンコーダ制約が強制されるので、ＣＵサイズが６４×６４に等しい場合、palette_mode_flag が０に制限される (すなわち、パレットモードオフ)。

【0066】

パレット符号化の推定される palette_mode_flag
SCM 2.0 パレットモードにおいて、トラバーススキャンが、６４×６４ブロックを含む全ブロックサイズに適用される。６４×６４ブロックのトラバーススキャンは図１０に示される。

【0067】

ブロックスキャニング順序の不規則構造を回避するため、パレット符号化ＣＵのサイズが、最大ＴＵサイズより大きいとき、パレット符号化が省略される。ＣＵサイズが、最大ＴＵサイズより大きい場合、シグナリングなしで、palette_mode_flag が０として導出される。表４は構文表で、注記 (4-1)中の条件 (log2CbSize <= MaxTbLog2SizeY)に示されるように、構文 palette_mode_flag[x0][y0] が、最大ＴＵサイズより大きいＣＵサイズに対して省略される。

【0068】

【表4】

【0069】

別の実施態様において、ＣＵサイズが最大ＴＵサイズより大きい場合、エンコーダ制約が強制されるので、palette_mode_flag が０に制限される (すなわち、パレットモードオフ)。

【0070】

サイズが所定ブロックサイズより大きくない任意のＣＵ (たとえば、最大ＴＵサイズ、あるいは、３２×３２)において、パレット符号化モードにより符号化される場合、この開示で記述される技術(たとえば、パレットサイズシグナリング、最大符号化ユニットサイズの制限、ランタイプの簡単なコンテキスト適応符号化、および、パレット符号化における簡単な冗長性除去)が適用される。

【0071】

run_typeのコンテキスト
本発明の別の実施態様は、run_type 符号化のコンテキストに取り組む。たとえば、表５に示されるように、run_type ( “パレットランタイプ”とも称される)は、一固定コンテキストにより符号化される。この場合、一コンテキストだけが用いられるとともに、コンテキストは何にも基づかない。

【0072】

【表5】

【0073】

別の実施態様において、run_type は、表６に示されるように画素上方の run_type に対応する一構文を用いてコンテキスト符号化され、２値インデックス 0は、コンテキスト適応符号化を用いて符号化され、別の２値インデックスはされない。run_typeに二個の可能な値 (すなわち、二個のコンテキスト)があり、一コンテキストモデルが２個のrun_type値それぞれに用いられる。

【0074】

【表6】

【0075】

ＨＥＶＣ標準において、符号化ツリーユニット (ＣＴＢ)中のブロックは、z-スキャンパターンにしたがって処理されて、ブロック中の四分木分割ＣＴＢと適合する。画素(xNbA, yNbA)は、現在の画素上方の画素を示す。可変のavailable A は、画素 (xNbA, yNbA)が現在のＣＴＢ中に含まれることを示す。表７は、palette_run_type_flag のctxInc を決定する例の条件を示す。condA が、上方画素のランタイプが０であることを示すとき、ctxInc は０である。(xNbA, yNbA)が現在のＣＴＢ中に含まれないとき、ctxInc は０である。

【0076】

【表7】

【0077】

上方画素の位置(xNbA,yNbA)は、(x0, y0)で、現在の画素の (xA,yA)に等しくなるように設定される:

【0078】

走査順序が水平であるとき、xA = x0, yA = y0-1 である。
別の実施態様において、走査順序が垂直であるとき、xA = x0-1, yA = y0で、run_type は、表８に示されるように、前の画素の run_type に対応する一構文を用いて、コンテキスト符号化され、２値インデックス 0は、コンテキスト適応符号化を用いて符号化され、別の２値インデックスはされない。さらに、run_typeに二個の可能な値 (すなわち、二個のコンテキスト)があり、一コンテキストモデルが、二個の run_type 値のそれぞれに用いられる。

【0079】

【表8】

【0080】

前の画素の位置(xNbB,yNbB)は、(x0, y0)で、現在の画素の (xB,yB)に等しくなるように設定される:
走査順序が水平トラバースであるとき、xB = x0-1, yB = y0 で、y0は偶数であり、
走査順序が水平トラバースであるとき、xB = x0+1, yB = y0で、y0 は奇数であり、
走査順序が垂直トラバースであるとき、xB = x0, yB = y0-1で、x0は偶数であり、および、
走査順序が垂直トラバースであるとき、xB = x0, yB = y0+1 で、x0は偶数である。
走査順序がトラバースではない場合、位置 ( xB, yB )は以下にしたがって決定される:
走査順序が水平であるとき、xB = x0-1, yB = y0 で、および、
走査順序が垂直であるとき、xB = x0, yB = y0-1 である。

【0081】

可変 available B は、画素(xNbB, yNbB)が現在のＣＴＢ中に含まれることを示す。表９は、ctxInc がpalette_run_type_flagに決定される例の条件を説明する。condLが、前の画素のランタイプが０であることを示すとき、ctxInc は０である。(xNbB, yNbB)が現在のＣＴＢ中に含まれないとき、ctxInc は０である。

【0082】

【表9】

【0083】

IntraBCの時間的マージング候補
ＨＥＶＣ Merge モードにおいて、時間的マージング候補は、Merge 候補の一つとして用いられる。時間的マージング候補導出において、List_0中の現在のピクチャの標的リファレンス画像がまず指定される。現在のピクチャの標的リファレンス画像は、List_0中で、リファレンス画像インデックス (ref_Idx)が０に等しい画素である。その後、配列されたＰＵの動きベクトルが縮小拡大によって、時間的マージング候補を導出する。時間的マージング候補のref_Idx はゼロに等しくなるように設定される。B-sliceにおいて、一つは、リファレンス画像リスト 0 、もうひとつは、リファレンス画像リスト 1である二個の動きベクトルが得られるとともに、結合されて、双予測 Merge 候補を作る。

【0084】

しかし、時間的マージング候補導出において、現在のピクチャの標的リファレンス画像、あるいは、配列されたピクチャのリファレンス画像が、長期 リファレンスフレームである場合、ＭＶスケーリングが無効になる。これらの二ピクチャのひとつだけが長期リファレンスフレームである場合、時間的マージング候補は無効であると指定される。

【0085】

一実施態様において、IntraBC 設計において、再構成される現在のピクチャは、現在のピクチャのリファレンス画像のひとつとして用いられる。この再構成現在のピクチャが、リファレンスフレームリスト中に挿入され、たとえば、最後のリファレンス画像が List_0に挿入される。これにより、IntraBC モードは、Inter モードのひとつとして扱われる。しかし、リファレンス画像は、この再構成される現在のピクチャに示される。IntraBC ブロックのブロックベクトル (BV)は、この再構成される現在のピクチャに指示されるＭＶとして扱われる。このようなIntraBC 設計において、再構成される現在のピクチャは、長期リファレンス画像として表示される。

【0086】

上述の IntraBC 設計において、配列されたブロックがIntraBC モードで符号化される場合、配列されたブロックのリファレンス画像が長期ピクチャであるので、ＢＶは、時間的マージング候補の導出に用いられない。現在のピクチャのリファレンス画像が短期ピクチャである場合、時間的マージング候補は可用でない。ＢＶは、時間的マージング候補導出を用いて導出されないことを意味する。

【0087】

上述の問題を解決するため、本発明による一実施態様は、ＢＶが時間的マージング候補導出に用いられるようにする。時間的マージング候補導出において、配列されたブロックのＭＶがＢＶである場合、ＢＶは時間的マージング候補として用いられる。現在の再構成ピクチャが現在のリファレンスフレームリストに存在する場合、時間的マージング候補を用いることができる。時間的マージング候補のリファレンス画像インデックスref_Idx は、現在の再構成ピクチャを指すリファレンス画像インデックスに等しくなるように設定される。
たとえば、List_0 MVの時間的マージング候補導出期間中、現在の再構成ピクチャが List_0 に挿入される場合、および、配列されたＰＵのＭＶがＢＶである場合、ＢＶは、この時間的マージング候補のList_0 MV として用いられ、ref_Idxは、現在の再構成ピクチャを指すリファレンス画像インデックスに等しくなるように設定される。

【0088】

パレットインデックスのライン-制限ラン符号化
パイプライン具体化をよりよく促進するため、本発明の一実施態様は、ライン-制限ラン符号化をパレットインデックスに使用し、四方法 (モード)を有して、パレットインデックスのラインを符号化する:
・Line copy_index: ライン中の全画素は同一パレットインデックスを有する。
・Line copy_above: ラインの全インデックスがライン上方からコピーされる。
・Line fraction copy_index: ラインのインデックスは、index_runだけを用いて符号化される。各ランは、特定インデックスの繰り返しである。最後のランは、ラインの最後で終了する。
・Line fraction mixture: ラインのインデックスは、index_run と copy_aboveを用いて符号化される。各ランは、特定インデックス (copy_index) の繰り返し、あるいは、上方ライン(copy_above)からの連続インデックスのコピーである。最後のランは、ラインの最後で終了する。

【0089】

４つの方法のそれぞれにおいて、ランは、通常、ラインの終わりで終了して、パイプライン具体化を達成する。これは、さらに、トラバーススキャンを用いる必要性を排除する。
以下で、本発明の一実施態様を組み込んだシグナリングライン-制限ラン符号化の例が記述される。

【0090】

例１. この例において、構文設計は、まず、それが、 “line copy_above” モードであるかどうか判断する。そうでない場合、さらに、構文要素は、単一ラン (line copy_index)、あるいは、複数のラン (line fraction)モードを決定する。表１０は、構文設計を要約する。

【0091】

【表10】

【0092】

“line copy_above mode” と “line copy_index” モード両方において、ラン長さがブロック幅 (あるいは、スキャンが垂直である場合は高さ)に等しいので、パレットランはシグナリングされる必要がない。

【0093】

“line fraction modes”において、最後のランは、ラインの終わりで終了しなければならないので、その長さは、特別な “run-to-the-end” 構文設計により、あるいは、number_of_run_in_lineをシグナリングにより効果的に符号化される。これにより、最後のランのラン長さが省略される。

【0094】

図１６は、上述の構文設計を組み込んだ構文解析のフローチャートである。 図１６に示されるように、工程１６１０において、Run_type_line がチェックされる。ランタイプが Copy_indexである場合、プロセスは工程１６２０に進み、ランタイプがCopy_aboveである場合、工程１６３０が実行される。工程１６２０において、Full_line_flag が確認されて、それが真(true)がどうか判断する。それが真である場合(すなわち、 “Yes”)、工程１６４０において、インデックスが構文解析され、必要であれば、工程１６５０において、Escape_values が更に解析される。Full_line_flag が真ではない場合(すなわち、 “No”)、工程１６６０が実行され、構文Run_type_fractionを確認する。Run_type_fractionがCopy_aboveである場合、工程１６９０が実行される。Run_type_fractionがCopy_indexである場合、工程１６７０が実行され、インデックスが構文解析される。工程１６７０の後、工程１６８０において、ランが構文解析される。ランが構文解析された後、必要であれば、工程１６９０において、Escape_values が解析される。

【0095】

上述の実施態様は“Line fraction copy_index” と “Line fraction mixture”の区別がつかない。シグナリング 所定ライン中の各ランの開始で、Run_type_fraction を簡潔にシグナリングすることにより、２つの状況を可能にする。

【0096】

例２. この例において、まず、構文設計は、それが、“line copy_above” モードであるか判断する。そうでない場合、さらに、構文要素は、単一ラン (line copy_index)、あるいは、複数のラン (line fraction)モードか判断する。表１１は、構文設計を要約する。

【0097】

【表11】

【0098】

例１と比較して、フラグ Copy_index_only が用いられて、Line fraction copy_indexを示し、それらがすべてcopy_index ランであるので、ラン上のループは、ランタイプをシグナリングする必要がない。

【0099】

“line fraction modes”において、最後のランは、ラインの終わりで終了しなければならないので、その長さは、特別な “run-to-the-end” 構文設計により、シグナリング number_of_run_in_lineをシグナリングすることにより効果的に符号化される。最後のランのラン長さが省略される。

【0100】

その他の二値化例. ４モードの二値化シグナリングのさらに多くの例が表１２Ａ〜Ｊで説明され、可変長さ二値化は表１２Ａ〜Ｉで説明され、固定長さ二値化が表１２Ｊで説明される。

【0101】

【表12A】

【表12B】

【表12C】

【表12D】

【表12E】

【表12F】

【表12G】

【表12H】

【表12I】

【表12J】

【0102】

コンテキスト符号化の例.
上述の二値化の例の各２値は、バイパス、あるいは、レギュラーコンテキストモードを用いて符号化される。コンテキスト符号化は、前のモード、ライン上方のモード、あるいは、両方に基づく。コンテキスト符号化の場合、Run_type_line と Run_type_fraction は、同じコンテキストをシェアするか、あるいは、異なるコンテキストを用いることができる。

【0103】

ライン中の最後のランの符号化
各ライン中の最後のランは、ラインの最後で終了しなければならないので、その長さは、特別な “run-to-the-end” 構文設計によって、効果的に符号化される。たとえば、特定のコードは、パレット二値化表で、run-to-the-end コードとして割り当てられる。別の例において、ライン中のラン数に対応する構文 number_of_run_in_line がシグナリングされる。ライン中のラン上のループを構文解析するとき、最後のランのラン長さが省略される。さらに別の実施態様によると、構文 last_run フラグが各ランにシグナリングされる。このフラグが１のとき、ランはシグナリングされる必要がない。

【0104】

ランの符号化
本発明は、特定の二値化方法に制限されて、ランを符号化する。その他のラン符号化方法、たとえば、トランケーテッドユーナリ、あるいは、トランケーテッドバイナリが用いられて、ランを二値化する。

【0105】

ランは、ブロック幅 (あるいは、高さ)より短くなるように制限されるラン長さの“Line fraction” モードにだけ必要であるので、固定長さ符号化も用いられる。

【0106】

ランの所定の二値化において、各２値は、バイパス、あるいは、レギュラーコンテキストモードで符号化される。

【0107】

各ラインの第一インデックスの符号化
各ラインにおいて、現在のラインが、全ライン、あるいは、部分的ラインとして符号化されたことをシグナリング後、ラインのインデックスがシグナリングされる。インデックスが上方と同じ場合、インデックス自身に代わって、一フラグがシグナリングされる。図１７に示される例において、全インデックス３のラインにおいて、インデックス‘３’ がシグナリングされる。さらに、インデックスが上方画素 (１７１０)と同じであることを示すフラグがシグナリングされる。

【0108】

図１８は、上述の構文設計を組み込んだ構文解析のフローチャートである。図１８のフローチャートは、Full_line_flag が真であることを除いて、図１６と同じである。この場合、Copy_index_from_above が真であるかどうかに関する追加テストが工程１８１０で行われる。結果が “Yes”である場合、工程１８３０が実行されて、必要であれば、Escape_values が解析される。結果が “No”である場合、工程１８２０が実行され、インデックスが構文解析される。工程１８２０の後、必要であれば、工程１８３０において、Escape_values が解析される。

【0109】

現在のラインがフルラインとして符号化されない場合、フラグが用いられて、シグナリングインデックス自身に代わって、インデックスが上方と同じであることを示す。二個の例が図１９Ａと図１９Ｂで示され、フラグは、画素上方 (１９１０)からのインデックス “３”が図１９Ａ中で用いられ、画素上方 (１９２０)からのインデックス “１” が図１９Ｂ中で用いられることを示す。

【0110】

図２０は、上述の構文設計を組み込んだ構文解析のフローチャートである。追加工程(２０１０)が、工程１６６０と工程１６７０の間に含まれることを除いて、図２０は図１８と同じである。工程２０１０において、Copy_index_from_above が真であるかテストされる。結果が “Yes”である場合、必要であれば、工程１６９０において、Escape_values が解析される。結果が “No”である場合、工程１６７０において、インデックスが構文解析される。

【0111】

全体のロウラン
符号化効率を改善するために、カラーインデックス符号化において、一実施態様は、全体ロウに対応する適合長さの符号化を開示する。この場合、row_run_flagがシグナリングされる。表１３Ａは、本発明の一実施態様によるrow_run_lengthのシグナリングの二値化を示す図である。row_run_flag=1である場合、このラインはロウランで、コピーは、コピー位置からロウの終了までである。row_run_flag=0である場合、長さ構文は、さらに、以下の row_run_flagにシグナリングされる。

【0112】

全体ロウランの上述の実施態様は、コピー上方、コピー左側、コピー別方向、遷移コピー、任意のコピー、あるいは、それらの組み合わせに適用される。たとえば、上方全体ロウラン技術(above entire row run technique)は、コピー上方、あるいは、コピー左側モードに適用され、遷移コピー、あるいは、任意コピーに適用されない。表１３Ｂと表１３Ｃは、本発明の一実施態様による row_run_lengthのシグナリングの二値化の二例を説明する。

【0113】

【表13A】

【0114】

【表13B】

【0115】

【表13C】

【0116】

上記の例は、異なるパレット予測モードの全体ロウランを説明する。これらの例は、全ての可能な二値化とパレット予測モードの総記を意味するものではない。

【0117】

任意位置コピー
上方コピーと左側コピーで、コード インデックスマップを符号化する以外に、本発明の一実施態様は、任意の位置コピーモードを含み、その他の位置からインデックス長さをコピーするのを促進する。

【0118】

遷移コピーは、ＨＥＶＣにおいて、スクリーンコンテンツ向け符号化に開発される符号化モードである。遷移コピーと異なり、現在の画素の任意のコピーモードは左側画素により決定されない。エンコーダは、前に符号化されるカラーインデックスで検索して、現在のカラーインデックスと適合するカラーインデックスを見つける。距離は、これらの二個のカラーインデックス位置間の距離である。長さは、特定距離で、画素と同じカラーインデックスを有する画素の数量にしたがって導出される。距離と長さのペアは、最長長さ、あるいは、別のレート歪最適化 (RDO) 決断により決定される。

【0119】

任意のコピーの使用を示すため、追加構文要素が加えられる。任意のコピーモードが用いられる場合、構文要素arbitrary_copy_run_distance と arbitrary_copy_run_length (たとえば、n)が解析されて、以下の n サンプルインデックスが、arbitrary_copy_run_distanceにより特定される位置から直接コピーされる。図２１は、任意のコピーモードの例を示す図である。現在の画素 (２１１０)を符号化するとき、エンコーダは、前の符号化画素で検索される。図２１において、長さが３と６の二個の適合ペアが、現在のパターン (２１４０)を有する楕円２１２０と２１３０により示される。適合ペアの位置は、各ブロックベクトル(２１５０と２１６０)により識別される。エンコーダは、RDO 決定、あるいは、最長長さにしたがって、一つが選択される。

【0120】

arbitrary_copy_run_distance は、一ベクトル、あるいは、二個の別々の１Ｄスカラー値としてシグナリングされる。

【0121】

ＴＵベースのパレット符号化
パレット符号化のインデックスマップ符号化も各ＴＵに適用される。パレット自身の情報はＣＵ中の全ＴＵによりシェアされる。最大ＴＵスプリット深さは、Nに固定され、たとえば、max_transform_hierarchy_depth_intra-1である。

【0122】

ＴＵスプリット深さは、大きいＣＵのN (たとえば、１)、たとえば、６４×６４ＣＵとして固定され、小さいＣＵの N-1 (たとえば、０)、たとえば、３２×３２、１６×１６、および、８×８として固定される。

【0123】

上の記述が提示されて、当業者に、特定のアプリケーションとその要求のコンテキストに記述される通り、本発明を行うことができる。当業者なら、記述された具体例への各種修正が理解でき、ここで定義される一般原則は別の実施例にも応用できる。

【0124】

サブサンプルカラーインデックスマップ符号化
JCTVC-O0218 と JCTVC-O0182において、水平ラスター走査が、カラーインデックスマップ符号化に用いられる。本発明の一実施態様において、サブサンプルインデックスマップが符号化され、その後、インデックスマップのその他の部分が符号化される、あるいは、直接充填される。たとえば、偶数のサンプルロウ、あるいは、偶数のサンプルカラムが、元のパレットカラーインデックスマップ符号化を用いてまず符号化される。残余サンプルにおいて、補間が提供されて、サンプルを充填する。あるいは、構文は、残余サンプルロウ、あるいは、カラムにシグナリングされる。たとえば、各ロウにおいて、予測モードがシグナリングされる。予測モードは、垂直モード、水平モード、補間モード、および、通常の符号化モードを含む。補間モードにおいて、サンプルは、隣接画素を用いて補間される。

【0125】

ＣＵ-レベルフラグがシグナリングされて、サブサンプルカラーインデックスマップがＣＵに用いられるかどうか示す。PPS/SPS/スライスヘッダー中のフラグがシグナリングされて、このツールをオン／オフにする。

【0126】

単一パレットインデックスＣＵのラン符号化
SCM 2.0において、ＣＵが一つの可能なパレットインデックスだけを含む場合、palette_transpose_flag とラン符号化が省略される。二ケースにおいて発生する:
Case １:一パレットカラーを有し、エスケープインデックスがないＣＵ
Case ２:パレットカラーがなく、一エスケープインデックスを有するＣＵ

【0127】

しかし、ＣＵを横切るコピー画素がパレット符号化に用いられるとき、現在のパレットＣＵが、一インデックスだけを有するけれども、ＣＵ中のいくつかの画素が交差するＣＵからコピーされ、且つ、現在のパレットにより表示されない、あるいは、Escapeである可能性がある。このようなケースを可能にするため、palette_transpose_flag とラン符号化は、適応的に、一つの可能な一インデックスだけを含むＣＵにシグナリングされる。たとえば、Case 1において、ＣＵが一パレットカラーを有し、エスケープインデックスを有さないとき、palette_transpose_flagのシグナリング、および／または、ラン符号化が有効になる。palette_transpose_flag が省略される場合、オンかオフであると推定される。Case 2において、ＣＵがパレットカラーを有さず、一エスケープインデックスを有するとき、palette_transpose_flagのシグナリング、および/または、ラン符号化が有効になる。palette_transpose_flag が省略される場合、オンかオフであると推定される。

【0128】

別の実施態様によると、palette_transpose_flagを無効にする任意の組み合わせ、および、Case 1, Case 2あるいは両ケース中のラン符号化が適用される。

【0129】

Ｎより小さいパレットサイズのオフセット符号化
一実施態様において、一般化コピー上方モードが用いられるとき、一般化コピー上方モードのオフセットがパレットサイズにより推定される。パレットサイズがＮより小さく、且つ、インデックスモードがコピー上方モードであるとき、オフセットがＭ(たとえば、M = 1)であると推定され、エンコーダ、および、デコーダは、コピー上方モードのオフセットをシグナリングする必要がない。パレットサイズがＮより大きいとき、コピー上方複数ロウが用いられる。

【0130】

一実施態様において、エンコーダ、および、デコーダは、通常、コピー上方モードのオフセットをシグナリングする。

【0131】

パレット構文を用いて、予測絞り込み情報を符号化する
パレット符号化方法が、別の剰余符号化方法として用いられる (たとえば、予測絞り込み情報を符号化する)。ＨＥＶＣにおいて、Intra あるいは Inter 予測の後、剰余がシグナリングされて、予測器を改善する。本発明の一実施態様において、ＨＥＶＣ中、剰余符号化構文を使用するのに代わって、パレット符号化構文が用いられて、予測絞り込み情報 (すなわち、剰余)をシグナリングする。この実施態様による例は以下のように記述される:

【0132】

例１.エンコーダがパレット構文を用いて、予測絞り込み情報を符号化するとき、エンコーダは、パレットを用いて、剰余信号を符号化する。つまり、デコーダがパレットインデックスを復号するとともに、パレットインデックスに対応するパレット中の値を得る。値は剰余値であるとともに、用いられて、予測を改善する。特別インデックスは、０に等しい剰余に保留される。たとえば、保留されたインデックスは、０か１である。

【0133】

例２.エンコーダがパレット構文を用いて、予測絞り込み情報を符号化するとき、エンコーダはパレットを用いて、元の画素値を符号化するが、特別インデックスを保留して、予測に等しい再構成画素を示す。デコーダがパレット構文を復号するとき、画素のインデックスが０である場合、再構成される画素値は(Intra あるいは Inter)予測に等しい。そうでなければ、再構成される画素値は、インデックスに対応するパレット中の色に等しい。

【0134】

たとえば、保留されたインデックスは０か１である。新しいパレット構文の後か前に、ＨＥＶＣ剰余構文がシグナリングされる。つまり、一つはＨＥＶＣ剰余符号化、もうひとつは、新しいパレット符号化の二段階の予測絞り込みがある。

【0135】

最後の符号化ＢＶのリセット
SCM 2.0において、最後の符号化ＢＶが、ＢＶ符号化に用いられるＢＶ予測器 (ＢＶＰ)導出に用いられる。最後の符号化ＢＶは各ＣＴＵの(0, 0)にリセットされる。

【0136】

本発明の一実施態様によると、リセットメカニズムが修正されて、(0, 0)に代わって、各ＣＴＵの最後の符号化ＢＶを所定値に設定する。所定値は、(-8, 0), (-16, 0), (-32, 0), (-64, 0), (0,-8), (0, -16), (0, -32), (0, -64)である。

【0137】

２個の最後の符号化ＢＶにリセットが必要な場合、所定のＢＶペアは、{(-64, 0), (-32, 0)}, {(-32, 0), (-64, 0)}, {(-128, 0), (-64, 0)}, {(-64, 0), (-128, 0)}, {(-32, 0), (-16, 0)}, {(-16, 0), (-32, 0)}, {(-16, 0), (-8, 0)}, {(-8, 0), (-16, 0)}, {(-32, 0), (-8, 0)}あるいは{(-8, 0), (-32, 0)}である。

【0138】

提案される方法により、ＢＶ予測導出が簡単になる。最後の符号化ＢＶの有効性の確認(すなわち、最後の符号化ＢＶが(0,0)に等しいかどうか確認する)が省略される。この実施態様によるリセットメカニズムの例は以下のように記述される:

【0139】

例１. 現在のブロックが、現在のＣＴＵで、第一符号化 IntraBC PU であるとき、最後の符号化ＢＶが(-2w, 0)と (-w, 0)にリセットされ、w は、ＰＵ幅、あるいは、ＰＵ高さである。

【0140】

例２.最後の符号化ＢＶは、各ＣＴＵの開始で、所定値にリセットされ、これらの所定値は、CTU_widthあるいは CTU_heightに関連する。たとえば、所定値は、(-CTU_width, 0)、(-(CTU_width>>1), 0)、(-(CTU_width>>2), 0)、(-(CTU_width>>3), 0)になる。最小／最大値制限はこれらの所定値に適用される。たとえば、各コンポーネントの最大値は -8より大きくならない。これにより、所定値は、 (max(-8, -CTU_width)), 0)、(max(-8, -(CTU_width>>1)), 0)、 (max(-8, -(CTU_width>>2)), 0)、(max(-8, -(CTU_width>>3)), 0)になる。

【0141】

例３.最後の符号化ＢＶは、各ＣＴＵの開始で、所定値にリセットされ、これらの所定値は、min_CU_width あるいは min_CU_heightに関連する。たとえば、所定値は、(-min_CU_width), 0)、(-2*min_CU_width), 0)、(-3*min_CU_width, 0)、(-4*min_CU_width, 0)、(-8*min_CU_width, 0)になる。最小／最大値制限がこれらの所定値に適用される。たとえば、各コンポーネントの最小値は、-64より大きくならない。これにより、所定値は、(min(-64, -min_CU_width)), 0)、(min(-64, -2*min_CU_width)), 0)、(min(-64, -3*min_CU_width)), 0)、(min(-64, -4*min_CU_width)), 0)、(min(-64, -8*min_CU_width)), 0)になる。

【0142】

２個の最後の符号化ＢＶはリセットの必要がある場合、所定のＢＶペアは、{(-min_CU_width), 0)、(-2*min_CU_width), 0)}, {(-2*min_CU_width), 0)、(-min_CU_width), 0)}, {(-2*min_CU_width), 0), (-4*min_CU_width), 0)}あるいは{(-4*min_CU_width), 0), (-2*min_CU_width), 0)}である。

【0143】

上述の実施態様によると、最後の符号化ＢＶリセットが簡単になる。現在のＣＴＵ中で、現在のブロックが、第一 IntraBC 符号化ブロックであるかどうかを検出する必要がない。
上述の本発明の具体例は、各種ハードウェア、ソフトウェアコード、または、それらの組み合わせで実行される。たとえば、本発明の具体例は、画像圧縮チップに整合される回路、または、画像圧縮ソフトウェアに整合されるプログラムコードで、上述の処理を実行する。本発明の具体例は、デジタルシグナルプロセッサ（ＤＳＰ）で実行されるプログラムコードで、上述の処理を実行する。本発明は、さらに、コンピュータプロセッサ、デジタルシグナルプロセッサ、マイクロプロセッサ、または、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）により実行される複数の機能を含む。これらのプロセッサは、本発明により具体化される特定の方法を定義する機械読み取り可能ソフトウェアコード、または、ファームウェアコードを実行することにより、本発明による特定のタスクを実行するように設定される。ソフトウェアコード、または、ファームウェアコードは、異なるプログラミング言語、および、異なるフォーマット、または、スタイルで開発される。ソフトウェアコードは、さらに、異なるターゲットプラットフォームにコンパイルされる。しかし、本発明によるタスクを実行するソフトウェアコードの異なるコードフォーマット、スタイル、および、言語、および、設定コードのその他の手段は、本発明の精神を逸脱しない。

【0144】

本発明では好ましい実施例を前述の通り開示したが、これらは決して本発明に限定するものではなく、当該技術を熟知する者なら誰でも、本発明の思想を脱しない範囲内で各種の変形を加えることができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9A】

【図9B】

【図10】

【図11A】

【図11B】

【図12A】

【図12B】

【図13A】

【図13B】

【図14A】

【図14B】

【図15A】

【図15B】

【図16】

【図17】

【図18】

【図19A】

【図19B】

【図20】

【図21】