JP2014236264A

JP2014236264A - 画像処理装置、画像処理方法及びプログラム

Info

Publication number: JP2014236264A
Application number: JP2013114947A
Authority: JP
Inventors: 寿治土屋; Toshiharu Tsuchiya
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2013-05-31
Filing date: 2013-05-31
Publication date: 2014-12-15
Also published as: WO2014192244A1; US20180124403A1; US9894360B2; CN110035291A; CN105247864A; US20150381980A1; CN105247864B; US10432933B2

Abstract

【課題】全ての分割パターンについて網羅的にコストの比較を実行しようとすると、処理の負荷が多大となり、エンコーダの処理性能又は電力消費に悪影響が生じる。ブロック分割の深さを柔軟に設定することのできる仕組みを実現する画像処理装置を提供する。
【解決手段】画像処理装置は、符号化される画像のブロックを再帰的に分割することにより形成される符号化単位を、前記ブロックに設定する設定部と、前記設定部におけるブロック分割の深さを、リソース効率に関するモードに従って制御する制御部と、を備える。
【選択図】図４

Description

本開示は、画像処理装置、画像処理方法及びプログラムに関する。

現在、Ｈ．２６４／ＡＶＣよりも符号化効率をさらに向上することを目的として、ＩＴＵ−ＴとＩＳＯ／ＩＥＣとの共同の標準化団体であるＪＣＴＶＣ（Joint Collaboration Team-Video Coding）により、ＨＥＶＣ（High Efficiency Video Coding）と呼ばれる画像符号化方式の標準化が進められている。

ＭＰＥＧ２又はＨ．２６４／ＡＶＣなどの旧来の画像符号化方式では、符号化処理は、マクロブロックと呼ばれる処理単位で実行される。マクロブロックは、１６×１６画素の均一なサイズを有するブロックである。これに対し、ＨＥＶＣでは、符号化処理は、符号化単位（ＣＵ：Coding Unit）と呼ばれる処理単位で実行される。ＣＵは、最大符号化単位（ＬＣＵ：Largest Coding Unit）を再帰的に分割することにより形成される、可変的なサイズを有するブロックである。利用可能なＣＵの最大サイズは、６４×６４画素である。利用可能なＣＵの最小サイズは、８×８画素である。可変的なサイズを有するＣＵが採用される結果、ＨＥＶＣでは、画像の内容に応じて画質及び符号化効率を適応的に調整することが可能である。どの深さまでＬＣＵを分割するか（即ち、どのサイズのＣＵを使用するか）は、典型的には、符号化効率を左右するコストの比較に基づいて決定される。

特開２００８−０７８９６９号公報

しかしながら、考え得る全ての分割パターンについて網羅的にコストの比較を実行しようとすると、処理の負荷が多大となり、エンコーダの処理性能又は電力消費に悪影響が生じる。

従って、ブロック分割の深さを柔軟に設定することのできる仕組みが実現されることが望ましい。

本開示によれば、符号化される画像のブロックを再帰的に分割することにより形成される符号化単位を、前記ブロックに設定する設定部と、前記設定部におけるブロック分割の深さを、リソース効率に関するモードに従って制御する制御部と、を備える画像処理装置が提供される。

また、本開示によれば、符号化される画像のブロックを再帰的に分割することにより形成される符号化単位を、前記ブロックに設定することと、前記ブロックに前記符号化単位を設定する際のブロック分割の深さを、リソース効率に関するモードに従って制御することと、を含む画像処理方法が提供される。

また、本開示によれば、画像処理装置を制御するコンピュータを、符号化される画像のブロックを再帰的に分割することにより形成される符号化単位を、前記ブロックに設定する設定部と、前記設定部におけるブロック分割の深さを、リソース効率に関するモードに従って制御する制御部と、として機能させるためのプログラムが提供される。

本開示に係る技術によれば、ブロック分割の深さを柔軟に設定することが可能となる。

ＨＥＶＣにおける再帰的なブロック分割の一例について説明するための説明図である。エンコーダにおけるブロック分割の判定について説明するための説明図である。分割判定の処理シーケンスの一例について説明するための第１の説明図である。分割判定の処理シーケンスの一例について説明するための第２の説明図である。第１の実施形態に係る画像符号化装置の概略的な構成を示すブロック図である。ブロック分割部の詳細な構成の第１の例を示すブロック図である。ブロック分割部の詳細な構成の第２の例を示すブロック図である。ブロック分割部の詳細な構成の第３の例を示すブロック図である。動作モードをユーザに指定させるためのユーザインタフェースの第１の例を示す説明図である。動作モードをユーザに指定させるためのユーザインタフェースの第２の例を示す説明図である。並列処理における動作モードとリソース効率との間の関係の第１の例を示す説明図である。並列処理における動作モードとリソース効率との間の関係の第２の例を示す説明図である。直列処理における動作モードとリソース効率との間の関係の第１の例を示す説明図である。直列処理における動作モードとリソース効率との間の関係の第２の例を示す説明図である。符号化処理の高速化について説明するための説明図である。ブロック分割処理の概略的な流れの一例を示すフローチャートである。モード判定処理の詳細な流れの第１の例を示すフローチャートである。モード判定処理の詳細な流れの第２の例を示すフローチャートである。モード判定処理の詳細な流れの第３の例を示すフローチャートである。モード判定処理の詳細な流れの第４の例を示すフローチャートである。通常モードでのブロック設定処理の詳細な流れの一例を示すフローチャートである。リソース節約モードでのブロック設定処理の詳細な流れの第１の例を示すフローチャートである。リソース節約モードでのブロック設定処理の詳細な流れの第２の例を示すフローチャートである。リソース節約モードでのブロック設定処理の詳細な流れの第３の例を示すフローチャートである。リソース節約モードでのブロック設定処理の詳細な流れの第４の例を示すフローチャートである。リソース節約モードでＬＣＵサイズが調整される場合のブロックのスキャン順序について説明するための説明図である。第２の実施形態に係る画像符号化装置の概略的な構成を示すブロック図である。イントラ／インター判定制御処理の詳細な流れの一例を示すフローチャートである。イントラ／インター判定の処理シーケンスの一例について説明するための説明図である。マージ判定制御処理の詳細な流れの一例を示すフローチャートである。変換単位制御処理の詳細な流れの一例を示すフローチャートである。携帯電話機の概略的な構成の一例を示すブロック図である。記録再生装置の概略的な構成の一例を示すブロック図である。撮像装置の概略的な構成の一例を示すブロック図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

また、以下の順序で説明を行う。
１．再帰的なブロック分割
１−１．ブロック分割の例
１−２．ブロック分割に関連するシンタックス
１−３．ブロック分割の処理シーケンス
２．第１の実施形態
２−１．全体的な構成
２−２．ブロック分割部の詳細な構成
２−３．動作モードとリソース効率との間の関係
２−４．処理の流れ
３．第２の実施形態
３−１．全体的な構成
３−２．イントラ／インター判定の制御
３−３．マージ判定の制御
３−４．変換単位の設定の制御
４．応用例
５．まとめ

＜１．再帰的なブロック分割＞
［１−１．ブロック分割の例］
ＨＥＶＣでは、符号化される画像に１つ以上の最大符号化単位（ＬＣＵ）が設定され、ＬＣＵを再帰的に分割することにより１つ以上の符号化単位（ＣＵ）が設定される。このＣＵが、ＨＥＶＣにおける符号化処理の処理単位である。ＭＰＥＧ２又はＨ．２６４／ＡＶＣなどの旧来の画像符号化方式におけるマクロブロックのサイズが１６×１６画素で固定されているのに対して、ＣＵのサイズは可変的である。ＣＵのサイズのとり得る範囲は、ＳＣＵ（Smallest Coding Unit）サイズ及びＬＣＵサイズにより規定される。ＨＥＶＣの仕様上、ＳＣＵサイズの最小値は８×８画素、ＬＣＵサイズの最大値は６４×６４画素であるため、利用可能なＣＵのサイズの範囲は、最も広いケースで８×８画素〜６４×６４画素である。

ＬＣＵを再帰的に分割することにより形成されるツリー状のブロック構造は、四分木（Quad-Tree）構造と呼ばれる。ＣＵは、四分木のリーフに相当する。図１は、ＨＥＶＣにおける再帰的なブロック分割の一例について説明するための説明図である。図１の左には、人物の顔が映っている画像ＩＭ０１が示されている。画像ＩＭ０１は、水平方向にＵ個、垂直方向にＶ個、即ちＵ×Ｖ個のＬＣＵを有する。各ＬＣＵは、ＳＣＵサイズを下回らない範囲で、１つ以上のＣＵに再帰的に分割される。図１の右には、一例として、テクスチャ境界（人物の頭と背景との間の境界）が横切るＬＣＵ０が複数のＣＵに分割される様子が拡大して示されている。テクスチャ境界の近傍領域では、分割を繰り返すことでより小さいＣＵが設定され、それ以外の領域では、分割の回数をより少なくすることでより大きいＣＵが設定されている。例えば、ＬＣＵ０のサイズが６４×６４画素であるとすると、ＣＵ０１のサイズは３２×３２画素、ＣＵ０２のサイズは１６×１６画素、ＣＵ０３のサイズは８×８画素である。繰り返される分割の回数は、分割の深さ（depth）とも呼ばれる。ＬＣＵサイズが６４×６４画素の場合、分割の深さがゼロであればＣＵサイズは６４×６４画素、分割の深さが１であればＣＵサイズは３２×３２画素、分割の深さが２であればＣＵサイズは１６×１６画素、分割の深さが３であればＣＵサイズは８×８画素である。ＬＣＵサイズが３２×３２画素の場合、分割の深さがゼロであればＣＵサイズは３２×３２画素、分割の深さが１であればＣＵサイズは１６×１６画素、分割の深さが２であればＣＵサイズは８×８画素である。さらに、図示していないものの、各ＣＵは、それぞれ直交変換の処理単位となる１つ以上のＴＵ（変換単位：Transform Unit）に分割され得る。また、各ＣＵは、それぞれイントラ予測又はインター予測の処理単位となる１つ以上のＰＵ（予測単位：Prediction Unit）に分割され得る。このような再帰的なブロック分割によれば、画像の内容に応じてブロックサイズを変化させることにより、復号される画像の画質及び符号化効率を柔軟に調整することができる。

［１−２．ブロック分割に関連するシンタックス］
画像にどういったサイズのＬＣＵを配置し、各ＬＣＵをどのようにＣＵに分割するかは、エンコーダにおいて決定される。エンコーダは、決定したQuad-Tree構造をデコーダが再現することを可能とするためのパラメータを、符号化される画像のストリームに多重化する。Quad-Tree構造を特定するためのパラメータとして、ＨＥＶＣ仕様ドラフト１０（Benjamin Bross, Woo-Jin Han, Gary J. Sullivan, Jens-Rainer Ohm, Gary J. Sullivan, Ye-Kui Wang, Thomas Wiegand, “High Efficiency Video Coding (HEVC) text specification draft 10 (for FDIS & Consent)”， JCTVC-L1003_v4, 2013年1月14-23日）では、次の３つのパラメータが定義されている：
−log2_min_luma_coding_block_size_minus3
−log2_diff_max_min_luma_coding_block_size
−split_cu_flag

“log2_min_luma_coding_block_size_minus3”は、（輝度成分の）ＳＣＵサイズを（２を底とするその対数から３を減算した値によって）指定するパラメータである。例えば、当該パラメータがゼロに等しければ、ＳＣＵサイズは８×８画素である。“log2_diff_max_min_luma_coding_block_size”は、ＳＣＵサイズとＬＣＵサイズとの間の（対数での）差分を指定するパラメータである。例えば、ＳＣＵサイズが８×８画素であって当該パラメータが３に等しければ、ＬＣＵサイズは６４×６４画素である。これらパラメータを用いて指定されるサイズを有するＬＣＵが、画像にラスタ状に配置される。“split_cu_flag”は、ＬＣＵ又はＬＣＵから分割されるＣＵの各々を分割するかを指定するフラグ（以下、分割フラグという）であり、分割の深さに依存して再帰的に生成される。あるＬＣＵ又はＣＵに関連付けられる分割フラグがゼロを示す場合、当該ＬＣＵ又は当該ＣＵはそれ以上分割されない。あるＬＣＵ又はＣＵに関連付けられる分割フラグが１を示す場合、当該ＬＣＵ又は当該ＣＵは半分のサイズの４つのＣＵへ分割される。“log2_min_luma_coding_block_size_minus3”及び“log2_diff_max_min_luma_coding_block_size”はシーケンスパラメータセット（ＳＰＳ）に含まれる一方、split_cu_flagのセットは各スライスのセグメントデータに含まれる。

［１−３．分割判定の処理シーケンス］
デコーダは、上述したパラメータを参照することにより、ＬＣＵを再帰的に分割してQuad-Tree構造を再現する。一方、エンコーダは、発生すると想定される符号量に依存するコストの比較に基づいて、ＬＣＵ又はＣＵをより小さいＣＵへ分割するか否かを決定する。実際には、この処理は、ＨＭリファレンスソフトウェアにおいて実装されているように、サイズの小さい方から順にコストの計算及び分割の判定を積み上げていく方式で行われ得る。

図２は、エンコーダにおけるブロック分割の判定について説明するための説明図である。図２の例では、ＬＣＵサイズは６４×６４画素、ＳＣＵサイズは８×８画素である。図中の左端に示した４つのブロックＢ３０、Ｂ３１、Ｂ３２及びＢ３３は、ＳＣＵサイズに等しいサイズを有する候補ＣＵである。ブロックＢ２０は、ＳＣＵサイズの２倍のサイズを有する候補ＣＵである。エンコーダは、まず、４つのブロックＢ３０、Ｂ３１、Ｂ３２及びＢ３３、並びにブロックＢ２０についてそれぞれコストを計算し、ブロックＢ３０、Ｂ３１、Ｂ３２及びＢ３３のコストの合計と、ブロックＢ２０のコストとを比較する（処理Ｐ１）。そして、前者のコストがより低い場合には、ブロックＢ２０をブロックＢ３０、Ｂ３１、Ｂ３２及びＢ３３へ分割することが決定される。一方、後者のコストがより低い場合には、ブロックＢ２０を分割しないことが決定される。さらに、４つのブロックＢ２０、Ｂ２１、Ｂ２２及びＢ２３について分割の判定が終了すると、エンコーダは、ブロックＢ１０についてコストを計算し、ブロックＢ２０、Ｂ２１、Ｂ２２及びＢ２３のコストの合計と、ブロックＢ１０のコストとを比較する（処理Ｐ２）。そして、前者のコストがより低い場合には、ブロックＢ１０をブロックＢ２０、Ｂ２１、Ｂ２２及びＢ２３へ分割することが決定される。一方、後者のコストがより低い場合には、ブロックＢ１０を分割しないことが決定される。さらに、４つのブロックＢ１０、Ｂ１１、Ｂ１２及びＢ１３について分割の判定が終了すると、エンコーダは、ブロックＢ００についてコストを計算し、ブロックＢ１０、Ｂ１１、Ｂ１２及びＢ１３のコストの合計と、ブロックＢ００のコストとを比較する（処理Ｐ３）。そして、前者のコストがより低い場合には、ブロックＢ００をブロックＢ１０、Ｂ１１、Ｂ１２及びＢ１３へ分割することが決定される。一方、後者のコストがより低い場合には、ブロックＢ００を分割しないことが決定される。候補ＣＵのサイズがＬＣＵサイズに達した場合には、より大きいサイズについてのコストの計算及び比較は行われない。分割フラグ（split_cu_flag）は、このような分割の判定の結果を、ゼロ（分割せず）又は１（分割する）という値で示す。

図３Ａ及び図３Ｂは、分割判定の処理シーケンスの一例について説明するための説明図である。図３Ａには、説明のために使用されるブロックのラベルが示されている。６４×６４画素のＣＵはＬＣＵ内で１つのみ存在し、当該ＣＵは“６４×６４（０）”とラベリングされる。３２×３２画素のＣＵはＬＣＵ内で４つ存在し、それらＣＵは左上、右上、左下、右下の順に“３２×３２（０）”〜“３２×３２（３）”とラベリングされる。１６×１６画素のＣＵはＬＣＵ内で１６個存在し、それらＣＵは図中に示した順序で“１６×１６（０）”〜“１６×１６（１５）”とラベリングされる。８×８画素のＣＵはＬＣＵ内で６４個存在し、それらＣＵは図中に示した順序で“８×８（０）”〜“８×８（６３）”とラベリングされる。図３Ｂには、これらＣＵについてのコスト計算処理及び分割判定（コスト比較）処理の順序の一例が概略的に示されている。コスト計算処理は“Ｃｏｓｔ［Ｘ］”と表現され、分割判定処理は“Ｃｏｍｐａｒｅ［Ｘ］”と表現されている。Ｘは対象ブロックのラベルである。なお、実際には、いくつかの処理は並列的に行われてもよい。図３Ｂに示したように、最も多いケースでは、６４＋１６＋４＋１＝８５回のコスト計算処理、及び１６＋４＋１＝２１回の分割判定処理が実行されることになる。

しかし、図３Ｂに例示したように網羅的にコストの計算及び比較を実行しようとすると、処理の負荷が多大となり、エンコーダのリソース効率が低下する。例えば、バッテリー駆動されるモバイル機器では、過剰な負荷がバッテリー寿命を短くさせるであろう。十分なプロセッサ性能又はメモリ容量を有しない機器では、過剰な負荷が処理の正常な進行を妨げかねない。また、機器が十分なプロセッサ性能及びメモリ容量を有する場合であっても、処理量が多ければ符号化処理に長い時間が掛かる。そこで、次節より説明する実施形態において、処理の負荷を適切に制御することを可能とするために、通常の動作モードに加えて、新たな動作モードが提供される。新たな動作モードでは、処理対象とされる分割の深さを制限することにより、エンコーダのリソースが効率的に利用され、処理の負荷が軽減される。なお、本明細書では、便宜的に、通常の動作モードを「通常モード」、リソースが効率的に利用される動作モードを「リソース節約モード」という。

＜２．第１の実施形態＞
［２−１．全体的な構成］
図４は、第１の実施形態に係る画像符号化装置１０の概略的な構成を示すブロック図である。図４を参照すると、画像符号化装置１０は、並び替えバッファ１１、減算部１３、直交変換部１４、量子化部１５、可逆符号化部１６、蓄積バッファ１７、レート制御部１８、逆量子化部２１、逆直交変換部２２、加算部２３、ループフィルタ２４、フレームメモリ２５、選択部２６及び２７、イントラ予測部３０、インター予測部３５並びにブロック分割部４０を備える。

並び替えバッファ１１は、一連の画像データに含まれる画像を並び替える。並び替えバッファ１１は、符号化処理に係るＧＯＰ（Group of Pictures）構造に応じて画像を並び替えた後、並び替え後の画像データを減算部１３、イントラ予測部３０、インター予測部３５及びブロック分割部４０へ出力する。

減算部１３には、並び替えバッファ１１から入力される画像データ、及び後に説明するイントラ予測部３０又はインター予測部３５から入力される予測画像データが供給される。減算部１３は、並び替えバッファ１１から入力される画像データと予測画像データとの差分である予測誤差データを算出し、算出した予測誤差データを直交変換部１４へ出力する。

直交変換部１４は、減算部１３から入力される予測誤差データについて直交変換を行う。直交変換部１４により実行される直交変換は、例えば、離散コサイン変換（Discrete Cosine Transform：ＤＣＴ）又はカルーネン・レーベ変換などであってよい。直交変換は、ＣＵを分割することにより形成されるＴＵ（変換単位）の各々について実行される。ＴＵのサイズは、４×４画素、８×８画素、１６×１６画素及び３２×３２画素から適応的に選択される。直交変換部１４は、直交変換処理により取得される変換係数データを量子化部１５へ出力する。

量子化部１５には、直交変換部１４から入力される変換係数データ、及び後に説明するレート制御部１８からのレート制御信号が供給される。量子化部１５は、レート制御信号に従って決定される量子化ステップで変換係数データを量子化する。量子化部１５は、量子化後の変換係数データ（以下、量子化データという）を可逆符号化部１６及び逆量子化部２１へ出力する。

可逆符号化部１６は、量子化部１５から入力される量子化データについて可逆符号化処理を行うことにより、符号化ストリームを生成する。また、可逆符号化部１６は、デコーダにより参照される様々なパラメータを符号化して、符号化されたパラメータを符号化ストリームのヘッダ領域に挿入する。可逆符号化部１６により符号化されるパラメータは、Quad-Tree構造を特定する上述したパラメータ、並びに後に説明するイントラ予測に関する情報及びインター予測に関する情報を含み得る。そして、可逆符号化部１６は、生成した符号化ストリームを蓄積バッファ１７へ出力する。

蓄積バッファ１７は、可逆符号化部１６から入力される符号化ストリームを半導体メモリなどの記憶媒体を用いて一時的に蓄積する。そして、蓄積バッファ１７は、蓄積した符号化ストリームを、伝送路の帯域に応じたレートで、図示しない伝送部（例えば、通信インタフェース又は周辺機器との接続インタフェースなど）へ出力する。

レート制御部１８は、蓄積バッファ１７の空き容量を監視する。そして、レート制御部１８は、蓄積バッファ１７の空き容量に応じてレート制御信号を生成し、生成したレート制御信号を量子化部１５へ出力する。例えば、レート制御部１８は、蓄積バッファ１７の空き容量が少ない時には、量子化データのビットレートを低下させるためのレート制御信号を生成する。また、例えば、レート制御部１８は、蓄積バッファ１７の空き容量が十分大きい時には、量子化データのビットレートを高めるためのレート制御信号を生成する。

逆量子化部２１、逆直交変換部２２及び加算部２３は、ローカルデコーダを構成する。逆量子化部２１は、量子化部１５により使用されたものと同じ量子化ステップで量子化データを逆量子化し、変換係数データを復元する。そして、逆量子化部２１は、復元した変換係数データを逆直交変換部２２へ出力する。

逆直交変換部２２は、逆量子化部２１から入力される変換係数データについて逆直交変換処理を行うことにより、予測誤差データを復元する。直交変換と同様、逆直交変換は、ＴＵごとに実行される。そして、逆直交変換部２２は、復元した予測誤差データを加算部２３へ出力する。

加算部２３は、逆直交変換部２２から入力される復元された予測誤差データとイントラ予測部３０又はインター予測部３５から入力される予測画像データとを加算することにより、復号画像データ（リコンストラクト画像）を生成する。そして、加算部２３は、生成した復号画像データをループフィルタ２４及びフレームメモリ２５へ出力する。

ループフィルタ２４は、画質の向上を目的とする、デブロックフィルタ（ＤＦ）、サンプル適応オフセット（ＳＡＯ）フィルタ及び適応ループフィルタ（ＡＬＦ）などのフィルタ群を含む。ループフィルタ２４は、加算部２３から入力される復号画像データをフィルタリングし、フィルタリング後の復号画像データをフレームメモリ２５へ出力する。

フレームメモリ２５は、加算部２３から入力されるフィルタリング前の復号画像データ、及びループフィルタ２４から入力されるフィルタリング後の復号画像データを記憶媒体を用いて記憶する。

選択部２６は、イントラ予測のために使用されるフィルタリング前の復号画像データをフレームメモリ２５から読み出し、読み出した復号画像データを参照画像データとしてイントラ予測部３０に供給する。また、選択部２６は、インター予測のために使用されるフィルタリング後の復号画像データをフレームメモリ２５から読み出し、読み出した復号画像データを参照画像データとしてインター予測部３５に供給する。

選択部２７は、イントラ予測モードにおいて、イントラ予測部３０から出力されるイントラ予測の結果としての予測画像データを減算部１３へ出力すると共に、イントラ予測に関する情報を可逆符号化部１６へ出力する。また、選択部２７は、インター予測モードにおいて、インター予測部３５から出力されるインター予測の結果としての予測画像データを減算部１３へ出力すると共に、インター予測に関する情報を可逆符号化部１６へ出力する。選択部２７は、イントラ予測モードとインター予測モードとを、コストの大きさに応じて切り替える。

イントラ予測部３０は、原画像データ及び復号画像データに基づいて、ＣＵを分割することにより形成されるＰＵ（予測単位）ごとにイントラ予測処理を行う。例えば、イントラ予測部３０は、予測モードセット内の各候補モードによる予測結果を所定のコスト関数を用いて評価する。次に、イントラ予測部３０は、コストが最小となる予測モード、即ち圧縮率が最も高くなる予測モードを、最適な予測モードとして選択する。また、イントラ予測部３０は、当該最適な予測モードに従って予測画像データを生成する。そして、イントラ予測部３０は、選択した最適な予測モードを表す予測モード情報を含むイントラ予測に関する情報、コスト、及び予測画像データを、選択部２７へ出力する。

インター予測部３５は、原画像データ及び復号画像データに基づいて、ＣＵを分割することにより形成されるＰＵごとにインター予測処理を行う。例えば、インター予測部３５は、予測モードセット内の各候補モードによる予測結果を所定のコスト関数を用いて評価する。次に、インター予測部３５は、コストが最小となる予測モード、即ち圧縮率が最も高くなる予測モードを、最適な予測モードとして選択する。また、インター予測部３５は、当該最適な予測モードに従って予測画像データを生成する。そして、インター予測部３５は、選択した最適な予測モードを表す予測モード情報と動き情報とを含むインター予測に関する情報、コスト、及び予測画像データを、選択部２７へ出力する。

ブロック分割部４０は、画像内に設定されるＬＣＵの各々に、ＣＵのQuad-Tree構造を設定する。より具体的には、ブロック分割部４０は、画像にラスタ状にＬＣＵを配置する。さらに、ブロック分割部４０は、各ＬＣＵを複数の候補ＣＵに分割する。そして、ブロック分割部４０は、図２を用いて説明したように、あるサイズの４つの候補ＣＵ及び倍のサイズの候補ＣＵについてコストを計算する。そして、４つの候補ＣＵのコストの合計と倍のサイズの候補ＣＵのコストとを比較し、倍のサイズの候補ＣＵを分割するかを判定する。ブロック分割部４０は、このようなコスト計算及び分割判定を、ＳＣＵサイズからＬＣＵサイズに向けてコストを積み上げつつ実行し、符号化効率を最適化するＣＵのQuad-Tree構造を各ＬＣＵに設定する。また、本実施形態において、ブロック分割部４０は、リソース効率に関する動作モードに従って、上述した処理におけるブロック分割の深さを制御する。動作モードの選択肢は少なくとも２種類提供され、第１の動作モードは通常モード、第２の動作モードはリソース節約モードである。リソース節約モードでは、コスト計算及び分割判定の対象となるＣＵサイズの範囲が、通常モードと比較して狭い範囲に制限される。なお、ＣＵサイズの制限レベルの異なる、複数のリソース節約モードが提供されてもよい。

［２−２．ブロック分割部の詳細な構成］
本項では、ブロック分割部４０の詳細な構成のいくつかの例を説明する。

（１）第１の構成例
図５Ａは、ブロック分割部４０の詳細な構成の第１の例を示すブロック図である。図５Ａを参照すると、ブロック分割部４０は、モード制御部４１及びブロック設定部４７を備える。モード制御部４１及びブロック設定部４７は、例えば、ＣＰＵ（Central Processing Unit）又はＤＳＰ（Digital Signal Processor）などのプロセッサにより実行されるプログラムモジュールであってよい。

モード制御部４１は、リソース効率に関する動作モードを判定し、判定したモードに従ってブロック設定部４７におけるブロック分割の深さを制御する。いかなる数の動作モードの候補が、モード制御部４１により選択可能であってもよい。動作モードの候補は、例えば、上述した通常モード及びリソース節約モードを含む。通常モードが選択される場合、モード制御部４１は、ブロック分割の深さを制限せず、ＣＵの利用可能な様々なサイズを活用して、画像が高い画質で復号されることを可能とする。一方、リソース節約モードは、通常モードと比較してリソース効率が優先されるべきことを示す。リソース節約モードが選択される場合、モード制御部４１は、ブロック設定部４７におけるブロック分割の深さを制限する。

一例として、リソース効率は、バッテリーの利用効率を意味してもよい。この場合、リソース節約モードでは、画質よりもバッテリー消費の低減が優先される。モード制御部４１は、例えば、画像符号化装置１０に電力を供給するバッテリーの残量をモニタリングし、バッテリー残量が閾値を下回る場合に、動作モードをリソース節約モードに自動的に設定してもよい。バッテリー残量が閾値を下回らない場合には、動作モードは、通常モードに設定され得る。その代わりに、モード制御部４１は、例えば、画像符号化装置１０が外部電源に接続されていない（即ち、バッテリーにより駆動されている）場合に、動作モードをリソース節約モードに自動的に設定してもよい。画像符号化装置１０が外部電源に接続されている場合には、動作モードは、通常モードに設定され得る。また、モード制御部４１は、これら２つの基準を組合せてもよい。例えば、画像符号化装置１０が外部電源に接続されておらず且つバッテリー残量が閾値を下回る場合に、リソース節約モードが設定されてもよい。

他の例として、リソース効率は、プロセッサ、メモリ又は論理回路などの処理リソースの利用効率を意味してもよい。この場合、リソース節約モードでは、処理リソースを効率的に利用することが優先される。そして、例えば発生する余剰の処理リソースを用いて、高フレームレート化が実現されてもよい。その代わりに、後続する処理を前倒して実行することにより、符号化処理が高速化されてもよい。

モード制御部４１は、ユーザ入力により指定される動作モードを設定してもよい。ユーザ入力は、装置に設けられるタッチパネル、ボタン、スイッチ、ダイヤル又は音声入力インタフェースなどのユーザインタフェースを介して取得され得る。図６Ａ及び図６Ｂは、動作モードをユーザに指定させるためのユーザインタフェースの例をそれぞれ示している。図６Ａの第１の例において、動作モード指定ウィンドウＷ１は、タッチパネルに表示され得るウィンドウである。動作モード指定ウィンドウＷ１は、スライダＳＤ１を含む。ユーザは、スライダＳＤ１を左右へドラッグすることにより、３つの動作モードのうちの１つを指定することができる。スライダＳＤ１が左端に位置する場合、リソース効率モードが選択され、例えばバッテリー消費の低減が優先され得る。スライダＳＤ１が右端に位置する場合、通常モードが選択され、画質が優先され得る。スライダＳＤ１が中央に位置する場合、中間的な動作モードが選択され得る。図６Ｂの第２の例において、動作モード指定ウィンドウＷ２は、画面に表示され得るウィンドウである。動作モード指定ウィンドウＷ２は、チェックボックスＣＢ１を含む。ユーザは、チェックボックスＣＢ１にリストアップされた候補のいずれかを指定することにより、２つの動作モードのうちの１つを指定することができる。例えば、上の候補が指定された場合、リソース効率モードの一種である高速モードが選択され、符号化処理の高速化のためにブロック分割の深さが制限される。下の候補が指定された場合、通常モードが選択され、処理速度よりも画質が優先され得る。なお、図６Ａ及び図６Ｂに示したように動作モードをユーザに指定させる代わりに、分割の深さの制限値をユーザに指定させるユーザインタフェースが提供されてもよい。

また別の例として、モード制御部４１は、画像を撮像する装置の動きが速い場合に、動作モードをリソース節約モードに自動的に設定してもよい。例えば、モード制御部４１は、カメラに併設されるセンサ（例えば、加速度センサ又はジャイロセンサなど）の出力に基づくカメラの動きを表す指標（加速度、速度又は角速度など）をモニタリングし、当該指標が閾値を上回る場合に、動作モードをリソース節約モードに設定し得る。一般的に、カメラの動きが速い場合には、予測符号化の精度の低下に起因して、高い画質を維持することは困難である。また、ユーザの視覚特性は、画角が高速に変化している最中の画質の劣化をあまり感知しない傾向を有する。従って、カメラの動きが速い状況下でリソース節約モードを自動的に設定して、画質の維持よりもリソースの効率的な利用を優先することが有益である。

ブロック設定部４７は、１つ以上のＬＣＵの各々に、当該ＬＣＵを再帰的に分割することにより形成されるQuad-Tree構造を有する１つ以上のＣＵを設定する。上述したように、ＣＵの利用可能なサイズの範囲は、ＳＣＵサイズ及びＬＣＵサイズによって定義される。ブロック設定部４７は、候補ＣＵごとに、原画像データ、並びにイントラ予測及びインター予測の予測結果などの入力情報をコスト関数に入力することにより、コストを計算する。そして、ブロック設定部４７は、候補ＣＵと当該候補ＣＵに対応するより小さい４つのＣＵとの間でコストを比較することにより、当該候補ＣＵを分割するかを判定する。ブロック設定部４７は、このようなコスト計算及び分割判定をＳＣＵサイズからＬＣＵサイズに向かう順序で繰り返し実行し、その結果として導かれるＣＵのQuad-Tree構造を各ＬＣＵに設定する。

ブロック設定部４７は、各ＬＣＵに設定したQuad-Tree構造を特定するためのパラメータを生成する。ブロック設定部４７により生成されるパラメータは、ＳＣＵサイズ及びＬＣＵサイズを特定するパラメータに加えて、ブロック分割の深さを特定する分割フラグのセットを含む。分割フラグは、再帰的に指定される。即ち、あるブロックが４つのＣＵに分割されると、その分割を指定する分割フラグが生成された上で、さらに当該４つのＣＵの各々を分割するかを示す分割フラグが生成される。ブロック設定部４７により生成されるこれらパラメータは、可逆符号化部１６により符号化される。

ブロック設定部４７におけるブロック分割の深さは、上述したように、モード制御部４１により、リソース効率に関する動作モードに従って制御される。一例として、モード制御部４１は、リソース節約モードにおいて、複数の利用可能なサイズのうちより小さいサイズをＣＵが有しないように、ブロック設定部４７におけるブロック分割の深さを制限してもよい。この場合、深いレイヤでのブロック分割が抑制される。深いレイヤでのブロック分割を抑制する第１の手法は、モード制御部４１が、ＳＣＵサイズと等しいサイズを有するＣＵについてのコスト計算及びコスト比較をブロック設定部４７にスキップさせることである。ＳＣＵサイズの倍のサイズを有するＣＵについての分割フラグは、いずれもゼロ（分割せず）を示す。第１の手法によれば、ＳＣＵサイズの設定を維持したままで、即ちＳＰＳを更新することなく、分割の深さを変化させることができる。ＳＣＵサイズよりも大きいサイズを有するＣＵについてのコスト計算及びコスト比較がさらにスキップされてもよい。深いレイヤでのブロック分割を抑制する第２の手法は、モード制御部４１が、ＳＣＵサイズの値を調整し、通常モードよりも引き上げることである。第２の手法によれば、Quad-Tree構造を特定するために要する分割フラグの数を削減することができる。また、ＳＰＳが再定義される結果として、どのタイミングで動作モードが通常モードとリソース節約モードとの間で切り替わったかをユーザが容易に知ることができる。

他の例として、モード制御部４１は、リソース節約モードにおいて、複数の利用可能なサイズのうちより大きいサイズをＣＵが有しないように、ブロック設定部４７におけるブロック分割の深さを制限してもよい。この場合、浅いレイヤにおいてブロック分割が強制される。浅いレイヤにおいてブロック分割を強制する第１の手法は、モード制御部４１が、ＬＣＵサイズと等しいサイズを有するＣＵについてのコスト計算及びコスト比較をブロック設定部４７にスキップさせることである。ＬＣＵサイズと等しいサイズを有するＣＵについての分割フラグは、いずれも１（分割する）を示す。第１の手法によれば、ＬＣＵサイズの設定を維持したままで、即ちＳＰＳを更新することなく、分割の深さを変化させることができる。ＬＣＵサイズよりも小さいサイズを有するＣＵについてのコスト計算及びコスト比較がさらにスキップされてもよい。浅いレイヤにおいてブロック分割を強制する第２の手法は、モード制御部４１が、ＬＣＵサイズの値を調整し、通常モードよりも引き下げることである。第２の手法によれば、Quad-Tree構造を特定するために要する分割フラグの数を削減することができる。また、ＳＰＳが再定義される結果として、どのタイミングで動作モードが通常モードとリソース節約モードとの間で切り替わったかをユーザが容易に知ることができる。なお、ＬＣＵサイズが変化する場合、画像内のブロックのスキャン順序が変化する。

（２）第２の構成例
図５Ｂは、ブロック分割部４０の詳細な構成の第２の例を示すブロック図である。図５Ｂを参照すると、第２の例においても、ブロック分割部４０は、モード制御部４１及びブロック設定部４７を備える。モード制御部４１及びブロック設定部４７は、第１の構成例において説明したものと同等の機能をそれぞれ有する。但し、第２の構成例において、各部は、論理的なプログラムモジュールとして実現されるのではなく、専用の論理回路として実現される。

モード制御部４１は、モード判定部４３及びクロック生成部４５を含む。ブロック設定部４７は、８×８計算部４９ａ、１６×１６計算部４９ｂ、３２×３２計算部４９ｃ、６４×４６計算部４９ｄ、及び比較部５１を含む。８×８計算部４９ａ、１６×１６計算部４９ｂ、３２×３２計算部４９ｃ、６４×４６計算部４９ｄは、並列的に、クロック生成部４５と比較部５１との間に接続される

モード判定部４３は、リソース効率に関する動作モードを判定する。モード判定部４３は、通常モードとリソース節約モードとの間で、ユーザインタフェースを介するユーザ入力に従って動作モードを切り替えてもよく、又は自動的に動作モードを切り替えてもよい。例えば、モード判定部４３は、ユーザ入力に従って、バッテリー消費の低減、高フレームレート化又は高速化のために、動作モードをリソース節約モードに設定してもよい。また、モード判定部４３は、バッテリー残量が閾値を下回る場合、又は画像符号化装置１０が外部電源に接続されていない場合に、バッテリー消費の低減のために、動作モードをリソース節約モードに設定してもよい。また、モード判定部４３は、画像を撮像する装置の動きが速い場合に、動作モードをリソース節約モードに設定してもよい。

クロック生成部４５は、クロック信号を生成し、生成したクロック信号を８×８計算部４９ａ、１６×１６計算部４９ｂ、３２×３２計算部４９ｃ及び６４×４６計算部４９ｄへ提供する。８×８計算部４９ａ、１６×１６計算部４９ｂ、３２×３２計算部４９ｃ及び６４×４６計算部４９ｄは、クロック生成部４５から提供されるクロック信号を用いて、それぞれ対応するサイズを有する候補ＣＵについてのコスト計算を実行する。通常モードにおいて、ＳＣＵサイズが８×８画素、ＬＣＵサイズが６４×６４画素であれば、クロック生成部４５は、８×８計算部４９ａ、１６×１６計算部４９ｂ、３２×３２計算部４９ｃ及び６４×４６計算部４９ｄの全てへクロック信号を提供する。リソース節約モードにおいて、深いレイヤでのブロック分割が抑制される場合、クロック生成部４５は、８×８計算部４９ａへのクロック信号の提供を停止する。クロック生成部４５は、複数の計算部（例えば、８×８計算部４９ａ及び１６×１６計算部４９ｂ）へのクロック信号の提供を停止してもよい。リソース節約モードにおいて、浅いレイヤのブロック分割が強制される場合、クロック生成部４５は、６４×６４計算部４９ａへのクロック信号の提供を停止する。クロック生成部４５は、複数の計算部（例えば、３２×３２計算部４９ｃ及び６４×６４計算部４９ｄ）へのクロック信号の提供を停止してもよい。クロック生成部４５は、ＳＣＵサイズよりも小さいサイズに対応する計算部には、クロック信号を提供しない。同様に、クロック生成部４５は、ＬＣＵサイズよりも大きいサイズに対応する計算部には、クロック信号を提供しない。

８×８計算部４９ａは、クロック生成部４５から提供されるクロック信号を用いて、８×８画素のサイズを有する候補ＣＵについて、コスト計算を実行する。そして、８×８計算部４９ａは、計算したコストを比較部５１へ出力する。１６×１６計算部４９ｂは、クロック生成部４５から提供されるクロック信号を用いて、１６×１６画素のサイズを有する候補ＣＵについて、コスト計算を実行する。そして、１６×１６計算部４９ｂは、計算したコストを比較部５１へ出力する。３２×３２計算部４９ｃは、クロック生成部４５から提供されるクロック信号を用いて、３２×３２画素のサイズを有する候補ＣＵについて、コスト計算を実行する。そして、３２×３２計算部４９ｃは、計算したコストを比較部５１へ出力する。６４×６４計算部４９ｄは、クロック生成部４５から提供されるクロック信号を用いて、６４×６４画素のサイズを有する候補ＣＵについて、コスト計算を実行する。そして、６４×６４６計算部４９ｄは、計算したコストを比較部５１へ出力する。

比較部５１は、あるサイズの候補ＣＵと当該候補ＣＵに対応するより小さい４つのＣＵとの間で、計算されたコストを比較することにより、当該候補ＣＵを分割するかを判定する。比較部５１は、ＳＣＵサイズからＬＣＵサイズに向かう順序で、こうした分割判定を繰り返し実行する。あるサイズについてクロック信号の提供が停止されコスト計算がスキップされた場合には、比較部５１は、当該サイズに関連する分割判定をスキップする。そして、比較部５１は、一連の分割判定の結果として導かれる各ＬＣＵのQuad-Tree構造を特定するためのパラメータを生成し、生成したパラメータを可逆符号化部１６へ出力する。

（３）第３の構成例
図５Ｃは、ブロック分割部４０の詳細な構成の第３の例を示すブロック図である。図５Ｃを参照すると、第３の例においても、ブロック分割部４０は、モード制御部４１及びブロック設定部４７を備える。モード制御部４１及びブロック設定部４７は、第１の構成例において説明したものと同等の機能をそれぞれ有する。但し、第３の構成例において、各部は、論理的なプログラムモジュールとして実現されるのではなく、専用の論理回路として実現される。

モード制御部４１は、モード判定部４４及びクロック生成部４６を含む。ブロック設定部４７は、コスト計算部５０、及び比較部５２を含む。第２の構成例と異なり、第３の構成例において、コスト計算部５０は、一連の候補ＣＵについてコスト計算処理を直列的に実行する。

モード判定部４４は、リソース効率に関する動作モードを判定する。モード判定部４４は、通常モードとリソース節約モードとの間で、ユーザインタフェースを介するユーザ入力に従って動作モードを切り替えてもよく、又は自動的に動作モードを切り替えてもよい。例えば、モード判定部４４は、ユーザ入力に従って、バッテリー消費の低減、高フレームレート化又は高速化のために、動作モードをリソース節約モードに設定してもよい。また、モード判定部４４は、バッテリー残量が閾値を下回る場合、又は画像符号化装置１０が外部電源に接続されていない場合に、バッテリー消費の低減のために、動作モードをリソース節約モードに設定してもよい。また、モード判定部４４は、画像を撮像する装置の動きが速い場合に、動作モードをリソース節約モードに設定してもよい。

クロック生成部４６は、クロック信号を生成し、生成したクロック信号をコスト計算部５０へ提供する。コスト計算部５０は、クロック生成部４６から提供されるクロック信号を用いて、一連の候補ＣＵの各々についてのコスト計算を実行する。バッテリー消費の低減のためにリソース節約モードが設定された場合、クロック生成部４６は、スキップされるコスト計算が実行されるはずであった期間において、クロック信号の提供を一時的に停止してもよい。高速化のためにリソース節約モードが設定された場合、クロック生成部４６からコスト計算部５０へのクロック信号の提供は停止されず、いくつかの候補ＣＵについてコスト計算がスキップされる結果としてブロック分割はより早く終了する。高フレームレート化のためにリソース節約モードが設定された場合にも、クロック生成部４６からコスト計算部５０へのクロック信号の提供は停止されず、一部の候補ＣＵについてコスト計算をスキップすることにより発生する余剰の処理リソースが高フレームレート化のために使用される。

コスト計算部５０は、クロック生成部４６から提供されるクロック信号を用いて、様々なサイズを有する候補ＣＵについて、コスト計算を実行する。そして、コスト計算部５０は、計算したコストを比較部５２へ順次出力する。

比較部５２は、あるサイズの候補ＣＵと当該候補ＣＵに対応するより小さい４つのＣＵとの間で、計算されたコストを比較することにより、当該候補ＣＵを分割するかを判定する。比較部５２は、ＳＣＵサイズからＬＣＵサイズに向かう順序で、こうした分割判定を繰り返し実行する。あるサイズについてコスト計算がスキップされた場合には、比較部５２は、当該サイズに関連する分割判定をスキップする。そして、比較部５２は、一連の分割判定の結果として導かれる各ＬＣＵのQuad-Tree構造を特定するためのパラメータを生成し、生成したパラメータを可逆符号化部１６へ出力する。

［２−３．動作モードとリソース効率との間の関係］
（１）並列処理−第１の例
図７Ａは、並列処理における動作モードとリソース効率との間の関係の第１の例を示す説明図である。図中の水平方向は時間軸に対応し、中空の太線枠は実行されるコスト計算を、中実の太線枠は実行される分割判定処理を、点線枠はスキップされる処理を示している。

図７Ａの上段に示された処理のシーケンスは、動作モードＭ１１におけるシーケンスを例示しており、動作モードＭ１１は通常モードである。通常モードにおいて、８×８画素、１６×１６画素、３２×３２画素及び６４×６４画素の候補ＣＵについてのコスト計算が並列的に実行され得る。１６×１６画素の１つの候補ＣＵについてコスト計算が終了すると、当該候補ＣＵについて分割判定が実行される。３２×３２画素の１つの候補ＣＵについてコスト計算が終了すると、当該候補ＣＵについて分割判定が実行される。６４×６４画素の１つの候補ＣＵについてコスト計算が終了すると、当該候補ＣＵについて分割判定が実行される。

図７Ａの中段に示された処理のシーケンスは、動作モードＭ１２におけるシーケンスを例示しており、動作モードＭ１２はリソース節約モードである。このリソース節約モードにおいて、１６×１６画素、３２×３２画素及び６４×６４画素の候補ＣＵについてのコスト計算が並列的に実行される一方で、８×８画素の候補ＣＵについてのコスト計算はスキップされる。１６×１６画素の候補ＣＵについての分割判定もまたスキップされる。それにより、バッテリーの消費量又はその他のリソースの使用量が低減される。

図７Ａの下段に示された処理のシーケンスは、動作モードＭ１３におけるシーケンスを例示しており、動作モードＭ１３はより強いリソース節約モードである。このリソース節約モードにおいて、３２×３２画素及び６４×６４画素の候補ＣＵについてのコスト計算が並列的に実行される一方で、８×８画素及び１６×１６画素の候補ＣＵについてのコスト計算はスキップされる。１６×１６画素及び３２×３２画素の候補ＣＵについての分割判定もまたスキップされる。それにより、バッテリーの消費量又はその他のリソースの使用量は、一層低減される。

（２）並列処理−第２の例
図７Ｂは、並列処理における動作モードとリソース効率との間の関係の第２の例を示す説明図である。

図７Ｂの上段に示された処理のシーケンスは、動作モードＭ２１におけるシーケンスを例示しており、動作モードＭ２１は通常モードである。動作モードＭ２１におけるシーケンスは、図７Ａの上段に示した動作モードＭ１１のシーケンスと実質的に等しい。

図７Ｂの中段に示された処理のシーケンスは、動作モードＭ２２におけるシーケンスを例示しており、動作モードＭ２２はリソース節約モードである。このリソース節約モードにおいて、８×８画素、１６×１６画素及び３２×３２画素の候補ＣＵについてのコスト計算が並列的に実行される一方で、６４×６４画素の候補ＣＵについてのコスト計算はスキップされる。６４×６４画素の候補ＣＵについての分割判定もまたスキップされる。それにより、バッテリーの消費量又はその他のリソースの使用量が低減される。

図７Ｂの下段に示された処理のシーケンスは、動作モードＭ２３におけるシーケンスを例示しており、動作モードＭ２３はより強いリソース節約モードである。このリソース節約モードにおいて、８×８画素及び１６×１６画素の候補ＣＵについてのコスト計算が並列的に実行される一方で、３２×３２画素及び６４×６４画素の候補ＣＵについてのコスト計算はスキップされる。３２×３２画素及び６４×６４画素の候補ＣＵについての分割判定もまたスキップされる。それにより、バッテリーの消費量又はその他のリソースの使用量は、一層低減される。

（３）直列処理−第１の例
図８Ａは、直列処理における動作モードとリソース効率との間の関係の第１の例を示す説明図である。

図８Ａの上段に示された処理のシーケンスは、動作モードＭ３１におけるシーケンスを例示しており、動作モードＭ３１は通常モードである。通常モードにおいて、８×８画素の４つの候補ＣＵ及び対応する１６×１６画素の候補ＣＵについてコスト計算が終了すると、当該１６×１６画素の候補ＣＵについて分割判定が実行される。また、１６×１６画素の４つの候補ＣＵについて分割判定が終了すると、対応する３２×３２画素の候補ＣＵについてコスト計算及び分割判定が実行される。また、３２×３２画素の４つの候補ＣＵについて分割判定が終了すると、対応する６４×６４画素の候補ＣＵについてコスト計算及び分割判定が実行される。

図８Ａの中段に示された処理のシーケンスは、動作モードＭ３２におけるシーケンスを例示しており、動作モードＭ３２はリソース節約モードである。このリソース節約モードにおいて、８×８画素の候補ＣＵについてのコスト計算、及び１６×１６画素の候補ＣＵについての分割判定がスキップされる。それにより、バッテリーの消費量又はその他のリソースの使用量が低減される。

図８Ａの下段に示された処理のシーケンスは、動作モードＭ３３におけるシーケンスを例示しており、動作モードＭ３３はより強いリソース節約モードである。このリソース節約モードにおいて、８×８画素及び１６×１６画素の候補ＣＵについてのコスト計算はスキップされる。１６×１６画素及び３２×３２画素の候補ＣＵについての分割判定もまたスキップされる。それにより、バッテリーの消費量又はその他のリソースの使用量は、一層低減される。

（４）直列処理−第２の例
図８Ｂは、直列処理における動作モードとリソース効率との間の関係の第２の例を示す説明図である。

図８Ｂの上段に示された処理のシーケンスは、動作モードＭ４１におけるシーケンスを例示しており、動作モードＭ４１は通常モードである。動作モードＭ４１におけるシーケンスは、図８Ａの上段に示した動作モードＭ３１のシーケンスと実質的に等しい。

図８Ｂの中段に示された処理のシーケンスは、動作モードＭ４２におけるシーケンスを例示しており、動作モードＭ４２はリソース節約モードである。このリソース節約モードにおいて、６４×６４画素の候補ＣＵについてのコスト計算及び分割判定がスキップされる。それにより、バッテリーの消費量又はその他のリソースの使用量が低減される。

図８Ｂの下段に示された処理のシーケンスは、動作モードＭ４３におけるシーケンスを例示しており、動作モードＭ４３はより強いリソース節約モードである。このリソース節約モードにおいて、３２×３２画素及び６４×６４画素の候補ＣＵについてのコスト計算はスキップされる。３２×３２画素及び６４×６４画素の候補ＣＵについての分割判定もまたスキップされる。それにより、バッテリーの消費量又はその他のリソースの使用量は、一層低減される。

（５）高フレームレート化及び高速化
図７Ａ〜図８Ｂに示した例では、点線枠で示された処理がスキップされる結果として、余剰のリソースが発生する。スキップのタイミングで何も処理が実行されなければ、バッテリー消費の時間平均は低減される。その代わりに、発生した余剰のリソースを用いて追加的なフレームの符号化処理を実行することにより、高フレームレート化が実現されてもよい。一例として、通常モードにおいて６０ｆｐｓ（frames per second）のフレームレートが提供されるのに対して、リソース節約モードにおいて１２０ｆｐｓの高いフレームレートが提供されてもよい。

また、ある処理がスキップされる場合に、後続する処理のタイミングを早めることにより、符号化処理の高速化が実現されてもよい。図９は、符号化処理の高速化について説明するための説明図である。図９の上段に示された処理のシーケンスは、動作モードＭ５１におけるシーケンスを例示しており、動作モードＭ５１は通常モードである。動作モードＭ５１におけるシーケンスは、図８Ａの上段に示した動作モードＭ３１のシーケンスと実質的に等しい。図９の下段に示された処理のシーケンスは、動作モードＭ５２におけるシーケンスを例示しており、動作モードＭ５２はリソース節約モードである。このリソース節約モードにおいて、８×８画素の候補ＣＵについてのコスト計算、及び１６×１６画素の候補ＣＵについての分割判定がスキップされる。そして、図中の点線矢印で示されているように、スキップされる処理に後続する処理は、前倒して実行される。その結果、動作モードＭ５２において、ブロック分割に要する処理時間を短縮し、符号化処理を高速化させることができる。

［２−４．処理の流れ］
（１）概略的な流れ
図１０は、ブロック分割部４０により実行されるブロック分割処理の概略的な流れの一例を示すフローチャートである。ブロック分割部４０は、図１０に示したブロック分割処理を、映像を構成する一連の画像の各々について実行する。

図１０を参照すると、まず、ブロック分割部４０のモード制御部４１は、後述するモード判定処理を実行する（ステップＳ１０）。その結果、通常モード及びリソース節約モードを含む複数の候補から選択される動作モードが、ブロック分割部４０に設定される。

その後の処理は、画像にラスタ状に配置されるＬＣＵの各々について繰り返される。各繰り返しにおいて、ブロック設定部４７は、まず、処理対象のＬＣＵである注目ＬＣＵを決定する（ステップＳ２０）。ＬＣＵは、典型的には、ラスタスキャンの順序で処理対象となる。

そして、ブロック分割処理はその時点の動作モードに依存して分岐する（ステップＳ２５）。動作モードが通常モードである場合、ブロック設定部４７は、注目ＬＣＵについて通常モードのブロック設定処理を実行する（ステップＳ３０）。動作モードがリソース節約モードである場合、ブロック設定部４７は、注目ＬＣＵについてリソース節約モードのブロック設定処理を実行する（ステップＳ５０）。なお、図示された例に限定されず、ブロック分割処理は３種類以上の動作モードに対応する処理に分岐してもよい。

注目ＬＣＵについてブロック設定処理が終了すると、ブロック設定部４７は、画像内に未処理のＬＣＵが残っているかを判定する（ステップＳ９０）。そして、未処理のＬＣＵが残っている場合には、処理はステップＳ２０へ戻り、次のＬＣＵが新たな注目ＬＣＵとなる。未処理のＬＣＵが残っていない場合には、当該画像についてのブロック分割処理は終了する。

（２）モード判定処理
図１１Ａは、モード判定処理の詳細な流れの第１の例を示すフローチャートである。第１の例において、まず、モード制御部４１は、ユーザインタフェースを介して取得されるユーザ入力を識別する（ステップＳ１１）。ここでのユーザインタフェースは、図６Ａ及び図６Ｂに例示したようなＧＵＩ（Graphical User Interface）であってもよい。また、簡易なボタン若しくはスイッチなどの物理的なＵＩ又は音声ＵＩが使用されてもよい。そして、モード制御部４１は、識別したユーザ入力に対応する動作モードを、ブロック分割部４０に設定する。なお、図示された例に限定されず、３つ以上の候補から動作モードが選択されてもよい。

図１１Ｂは、モード判定処理の詳細な流れの第２の例を示すフローチャートである。第２の例において、まず、モード制御部４１は、バッテリー残量をモニタリングする（ステップＳ１２）。そして、モード制御部４１は、その時点のバッテリー残量が所定の閾値を上回るかを判定する（ステップＳ１５）。バッテリー残量が閾値を上回る場合、モード制御部４１は、動作モードとして通常モードを設定する（ステップＳ１９ａ）。一方、バッテリー残量が閾値を上回らない場合、モード制御部４１は、動作モードとしてリソース節約モードを設定する（ステップＳ１９ｂ）。なお、図示された例に限定されず、２つ以上の閾値を用いて３つ以上の候補から動作モードが選択されてもよい。

図１１Ｃは、モード判定処理の詳細な流れの第３の例を示すフローチャートである。第３の例において、まず、モード制御部４１は、外部電源への接続を判定する（ステップＳ１３）。そして、モード制御部４１は、その時点で画像符号化装置１０が外部電源に接続されている場合（ステップＳ１６）、動作モードとして通常モードを設定する（ステップＳ１９ａ）。一方、画像符号化装置１０が外部電源に接続されていない場合、モード制御部４１は、動作モードとしてリソース節約モードを設定する（ステップＳ１９ｂ）。

図１１Ｄは、モード判定処理の詳細な流れの第４の例を示すフローチャートである。第４の例において、まず、モード制御部４１は、カメラの動きをモニタリングする（ステップＳ１４）。そして、モード制御部４１は、カメラの動きが速いか否かを、例えばカメラの動きを表す指標を閾値と比較することにより判定する（ステップＳ１７）。カメラの動きが速くないと判定された場合、モード制御部４１は、動作モードとして通常モードを設定する（ステップＳ１９ａ）。一方、カメラの動きが速いと判定された場合、モード制御部４１は、動作モードとしてリソース節約モードを設定する（ステップＳ１９ｂ）。なお、図示された例に限定されず、２つ以上の閾値を用いて３つ以上の候補から動作モードが選択されてもよい。

（３）通常モードでのブロック設定処理
図１２は、通常モードでのブロック設定処理の詳細な流れの一例を示すフローチャートである。図１２に示したブロック設定処理は、注目ＬＣＵの各々について実行される。

図１２を参照すると、まず、ブロック設定部４７は、注目ＬＣＵ内のＮ×Ｎ画素の４つのＣＵについてコストを計算する（ステップＳ３１）。ここでのＮは、ＳＣＵサイズに等しい。次に、ブロック設定部４７は、当該４つのＣＵに対応する２Ｎ×２Ｎ画素の１つのＣＵについてコストを計算する（ステップＳ３２）。次に、ブロック設定部４７は、ステップＳ３１において計算したコストの合計とステップＳ３２において計算したコストとを比較することにより、２Ｎ×２Ｎ画素のＣＵを分割するかを判定する（ステップＳ３３）。例えば、前者のコストがより低い場合には、ブロック設定部４７は、２Ｎ×２Ｎ画素のＣＵを分割することを決定する。一方、後者のコストがより低い場合には、ブロック設定部４７は、２Ｎ×２Ｎ画素のＣＵを分割しないことを決定する。

次に、ブロック設定部４７は、当該２Ｎ×２Ｎ画素のＣＵがＬＣＵに等しいかを判定する（ステップＳ３４）。当該２Ｎ×２Ｎ画素のＣＵがＬＣＵに等しい場合には、図１２に示したブロック設定処理は終了する。一方、そうでない場合には、処理はステップＳ３５へ進む。

ステップＳ３５において、ブロック設定部４７は、２Ｎ×２Ｎ画素の４つのＣＵについて分割判定が終了したかを判定する（ステップＳ３５）。ここで、２Ｎ×２Ｎ画素の４つのＣＵについて分割判定が終了していない場合には、処理はステップＳ３１へ戻り、次の２Ｎ×２Ｎ画素のＣＵについての分割判定のための処理が実行される。

２Ｎ×２Ｎ画素の４つのＣＵについて分割判定が終了した場合、ブロック設定部４７は、当該４つのＣＵに対応する４Ｎ×４Ｎ画素の１つのＣＵについてコストを計算する（ステップＳ３６）。次に、ブロック設定部４７は、２Ｎ×２Ｎ画素の４つのＣＵのコストの合計とステップＳ３６において計算したコストとを比較することにより、４Ｎ×４Ｎ画素のＣＵを分割するかを判定する（ステップＳ３７）。例えば、前者のコストがより低い場合には、ブロック設定部４７は、４Ｎ×４Ｎ画素のＣＵを分割することを決定する。一方、後者のコストがより低い場合には、ブロック設定部４７は、４Ｎ×４Ｎ画素のＣＵを分割しないことを決定する。

次に、ブロック設定部４７は、当該４Ｎ×４Ｎ画素のＣＵがＬＣＵに等しいかを判定する（ステップＳ３８）。当該４Ｎ×４Ｎ画素のＣＵがＬＣＵに等しい場合には、図１２に示したブロック設定処理は終了する。一方、そうでない場合には、処理はステップＳ３９へ進む。

ステップＳ３９において、ブロック設定部４７は、４Ｎ×４Ｎ画素の４つのＣＵについて分割判定が終了したかを判定する（ステップＳ３９）。ここで、４Ｎ×４Ｎ画素の４つのＣＵについて分割判定が終了していない場合には、処理はステップＳ３１へ戻り、次の４Ｎ×４Ｎ画素のＣＵ（及びより小さいＣＵ）についての分割判定のための処理が実行される。

４Ｎ×４Ｎ画素の４つのＣＵについて分割判定が終了した場合、ブロック設定部４７は、当該４つのＣＵに対応する８Ｎ×８Ｎ画素の１つのＣＵについてコストを計算する（ステップＳ４０）。次に、ブロック設定部４７は、４Ｎ×４Ｎ画素の４つのＣＵのコストの合計とステップＳ４０において計算したコストとを比較することにより、８Ｎ×８Ｎ画素のＣＵを分割するかを判定する（ステップＳ４１）。例えば、前者のコストがより低い場合には、ブロック設定部４７は、８Ｎ×８Ｎ画素のＣＵを分割することを決定する。一方、後者のコストがより低い場合には、ブロック設定部４７は、８Ｎ×８Ｎ画素のＣＵを分割しないことを決定する。ＳＣＵサイズ及びＬＣＵサイズの制約から、８Ｎ×８Ｎ画素のＣＵはＬＣＵに等しいため、８Ｎ×８Ｎ画素のＣＵについて分割判定が終了すると、図１２に示したブロック設定処理は終了する。

（４）リソース節約モードでのブロック設定処理−第１の例
図１３Ａは、リソース節約モードでのブロック設定処理の詳細な流れの第１の例を示すフローチャートである。第１の例では、利用可能なサイズのうち最も小さいサイズをＣＵが有しないように、ブロック分割の深さが制限される。ＳＣＵサイズの設定は、動作モードによらず維持される。

図１３Ａを参照すると、まず、ブロック設定部４７は、注目ＬＣＵ内のＮ×Ｎ画素の４つのＣＵについてコスト計算をスキップする（ステップＳ５１ａ）。ここでのＮは、ＳＣＵサイズに等しい。次に、ブロック設定部４７は、当該４つのＣＵに対応する２Ｎ×２Ｎ画素の１つのＣＵについてコストを計算する（ステップＳ５２）。次に、ブロック設定部４７は、２Ｎ×２Ｎ画素のＣＵについての分割判定をスキップし、当該２Ｎ×２Ｎ画素のＣＵを分割しないことを示す分割フラグを生成する（ステップＳ５３ａ）。

次に、ブロック設定部４７は、当該２Ｎ×２Ｎ画素のＣＵがＬＣＵに等しいかを判定する（ステップＳ５４ａ）。当該２Ｎ×２Ｎ画素のＣＵがＬＣＵに等しい場合には、図１３Ａに示したブロック設定処理は終了する。一方、そうでない場合には、処理はステップＳ５５ａへ進む。

ステップＳ５５ａにおいて、ブロック設定部４７は、２Ｎ×２Ｎ画素の４つのＣＵについて分割フラグの生成が終了したかを判定する（ステップＳ５５ａ）。ここで、分割フラグの生成が終了していない場合には、処理はステップＳ５１ａへ戻る。

２Ｎ×２Ｎ画素の４つのＣＵについて分割フラグの生成が終了した場合、ブロック設定部４７は、当該４つのＣＵに対応する４Ｎ×４Ｎ画素の１つのＣＵについてコストを計算する（ステップＳ５６ａ）。次に、ブロック設定部４７は、２Ｎ×２Ｎ画素の４つのＣＵのコストの合計とステップＳ５６ａにおいて計算したコストとを比較することにより、４Ｎ×４Ｎ画素のＣＵを分割するかを判定し、判定結果に対応する分割フラグを生成する（ステップＳ５７ａ）。

次に、ブロック設定部４７は、当該４Ｎ×４Ｎ画素のＣＵがＬＣＵに等しいかを判定する（ステップＳ５８）。当該４Ｎ×４Ｎ画素のＣＵがＬＣＵに等しい場合には、図１３Ａに示したブロック設定処理は終了する。一方、そうでない場合には、処理はステップＳ５９へ進む。

ステップＳ５９において、ブロック設定部４７は、４Ｎ×４Ｎ画素の４つのＣＵについて分割判定が終了したかを判定する（ステップＳ５９）。ここで、４Ｎ×４Ｎ画素の４つのＣＵについて分割判定が終了していない場合には、処理はステップＳ５１へ戻り、次の４Ｎ×４Ｎ画素のＣＵについての分割判定のための処理が実行される。

４Ｎ×４Ｎ画素の４つのＣＵについて分割判定が終了した場合、ブロック設定部４７は、当該４つのＣＵに対応する８Ｎ×８Ｎ画素の１つのＣＵについてコストを計算する（ステップＳ６０ａ）。次に、ブロック設定部４７は、４Ｎ×４Ｎ画素の４つのＣＵのコストの合計とステップＳ６０ａにおいて計算したコストとを比較することにより、８Ｎ×８Ｎ画素のＣＵを分割するかを判定し、判定結果に対応する分割フラグを生成する（ステップＳ６１ａ）。８Ｎ×８Ｎ画素のＣＵについて分割判定が終了すると、図１３Ａに示したブロック設定処理は終了する。

（５）リソース節約モードでのブロック設定処理−第２の例
図１３Ｂは、リソース節約モードでのブロック設定処理の詳細な流れの第２の例を示すフローチャートである。第２の例では、利用可能なサイズのうち最も小さいサイズをＣＵが有しないように、ブロック分割の深さが制限される。ＳＣＵサイズは、通常モードの２倍の値に再設定される。

図１３Ｂを参照すると、まず、モード制御部４１は、ＳＣＵサイズをＮ×Ｎ画素からＭ×Ｍ画素（Ｍ＝２Ｎ）に更新する（ステップＳ７０ａ）

次に、ブロック設定部４７は、注目ＬＣＵ内のＭ×Ｍ画素の４つのＣＵについてコストを計算する（ステップＳ７１ａ）。次に、ブロック設定部４７は、当該４つのＣＵに対応する２Ｍ×２Ｍ画素の１つのＣＵについてコストを計算する（ステップＳ７２）。次に、ブロック設定部４７は、ステップＳ７１ａにおいて計算したコストの合計とステップＳ７２において計算したコストとを比較することにより、２Ｍ×２Ｍ画素のＣＵを分割するかを判定し、判定結果に対応する分割フラグを生成する（ステップＳ７３ａ）。

次に、ブロック設定部４７は、当該２Ｍ×２Ｍ画素のＣＵがＬＣＵに等しいかを判定する（ステップＳ７４ａ）。当該２Ｍ×２Ｍ画素のＣＵがＬＣＵに等しい場合には、図１３Ｂに示したブロック設定処理は終了する。一方、そうでない場合には、処理はステップＳ７５へ進む。

ステップＳ７５において、ブロック設定部４７は、２Ｍ×２Ｍ画素の４つのＣＵについて分割判定が終了したかを判定する（ステップＳ７５ａ）。ここで、２Ｍ×２Ｍ画素の４つのＣＵについて分割判定が終了していない場合には、処理はステップＳ７１ａへ戻る。

２Ｍ×２Ｍ画素の４つのＣＵについて分割判定が終了した場合、ブロック設定部４７は、当該４つのＣＵに対応する４Ｍ×４Ｍ画素の１つのＣＵについてコストを計算する（ステップＳ７６）。次に、ブロック設定部４７は、２Ｍ×２Ｍ画素の４つのＣＵのコストの合計とステップＳ７６において計算したコストとを比較することにより、４Ｍ×４Ｍ画素のＣＵを分割するかを判定し、判定結果に対応する分割フラグを生成する（ステップＳ７７）。４Ｍ×４Ｍ画素のＣＵについて分割判定が終了すると、図１３Ｂに示したブロック設定処理は終了する。

図１３Ａ及び図１３Ｂに示した２つの例では、上述したように、深いレイヤでのブロック分割が抑制される。例えば、８×８画素のＣＵへのブロック分割が抑制される場合、図３Ｂに示したコスト計算処理及び分割判定処理のうち、６４回のコスト計算処理（Ｃｏｓｔ［８×８（０）］〜Ｃｏｓｔ［８×８（６３）］）及び１６回の分割判定処理（Ｃｏｍｐａｒｅ［１６×１６（０）］〜Ｃｏｍｐａｒｅ［１６×１６（１５）］）をスキップすることができる。また、例えば、１６×１６画素のＣＵへのブロック分割が抑制される場合、さらに１６回のコスト計算処理（Ｃｏｓｔ［１６×１６（０）］〜Ｃｏｓｔ［１６×１６（１５）］）及び４回の分割判定処理（Ｃｏｍｐａｒｅ［３２×３２（０）］〜Ｃｏｍｐａｒｅ［３２×３２（３）］）をスキップすることができる。

（６）リソース節約モードでのブロック設定処理−第３の例
図１３Ｃは、リソース節約モードでのブロック設定処理の詳細な流れの第３の例を示すフローチャートである。第３の例では、利用可能なサイズのうち最も大きいサイズをＣＵが有しないように、ブロック分割の深さが制限される。ＬＣＵサイズの設定は、動作モードによらず維持される。

図１３Ｃを参照すると、まず、ブロック設定部４７は、注目ＬＣＵ内のＮ×Ｎ画素の４つのＣＵについてコストを計算する（ステップＳ５１ｂ）。ここでのＮは、ＳＣＵサイズに等しい。次に、ブロック設定部４７は、当該４つのＣＵに対応する２Ｎ×２Ｎ画素の１つのＣＵについてコストを計算する（ステップＳ５２）。次に、ブロック設定部４７は、ステップＳ５１ｂにおいて計算したコストの合計とステップＳ５２において計算したコストとを比較することにより、２Ｎ×２Ｎ画素のＣＵを分割するかを判定し、判定結果に対応する分割フラグを生成する（ステップＳ５３ｂ）。

次に、ブロック設定部４７は、２Ｎ×２Ｎ画素の４つのＣＵについて分割判定が終了したかを判定する（ステップＳ５４ｂ）。ここで、分割判定が終了していない場合には、処理はステップＳ５１ｂへ戻る。２Ｎ×２Ｎ画素の４つのＣＵについて分割判定が終了した場合、ブロック設定部４７は、さらに、当該４つのＣＵに対応する４Ｎ×４Ｎ画素のＣＵがＬＣＵに等しいかを判定する（ステップＳ５５ｂ）。当該４Ｎ×４Ｎ画素のＣＵがＬＣＵに等しい場合には、処理はステップＳ５６ｂへ進む。一方、そうでない場合には、処理はステップＳ５５ａへ進む。

ステップＳ５６ａにおいて、ブロック設定部４７は、４Ｎ×４Ｎ画素の１つのＣＵについてコストを計算する（ステップＳ５６ａ）。次に、ブロック設定部４７は、２Ｎ×２Ｎ画素の４つのＣＵのコストの合計とステップＳ５６ａにおいて計算したコストとを比較することにより、４Ｎ×４Ｎ画素のＣＵを分割するかを判定し、判定結果に対応する分割フラグを生成する（ステップＳ５７ａ）。そして、処理はステップＳ５９へ進む。

一方、ステップＳ５６ｂにおいて、ブロック設定部４７は、ＬＣＵに等しい４Ｎ×４Ｎ画素のＣＵについてコスト計算をスキップする（ステップＳ５６ｂ）。次に、ブロック設定部４７は、４Ｎ×４Ｎ画素のＣＵを分割することを決定し、当該ＣＵを分割することを示す分割フラグを生成する（ステップＳ５７ｂ）。

ステップＳ５９において、ブロック設定部４７は、４Ｎ×４Ｎ画素の４つのＣＵについて分割判定が終了したかを判定する（ステップＳ５９）。ここで、４Ｎ×４Ｎ画素の４つのＣＵについて分割判定が終了していない場合には、処理はステップＳ５１ｂへ戻り、次の４Ｎ×４Ｎ画素のＣＵ（及びより小さいＣＵ）についての分割判定のための処理が実行される。

４Ｎ×４Ｎ画素の４つのＣＵについて分割判定が終了した後、ブロック設定部４７は、当該４つのＣＵに対応する８Ｎ×８Ｎ画素のＣＵについてコスト計算をスキップする（ステップＳ６０ｂ）。次に、ブロック設定部４７は、８Ｎ×８Ｎ画素のＣＵを分割することを決定し、当該ＣＵを分割することを示す分割フラグを生成する（ステップＳ６１ｂ）。
ステップＳ５７ｂ又はステップＳ６１ｂにおいて、ＬＣＵに等しいＣＵについての分割フラグの生成が終了すると、図１３Ｃに示したブロック設定処理は終了する。

（７）リソース節約モードでのブロック設定処理−第４の例
図１３Ｄは、リソース節約モードでのブロック設定処理の詳細な流れの第４の例を示すフローチャートである。第４の例では、利用可能なサイズのうち最も大きいサイズをＣＵが有しないように、ブロック分割の深さが制限される。ＬＣＵサイズは、通常モードの半分の値に再設定される。

図１３Ｄを参照すると、まず、モード制御部４１は、ＬＣＵサイズをＬ×Ｌ画素からＫ×Ｋ画素（Ｋ＝Ｌ／２）に更新する（ステップＳ７０ｂ）。

次に、ブロック設定部４７は、注目ＬＣＵ内のＮ×Ｎ画素の４つのＣＵについてコストを計算する（ステップＳ７１ｂ）。ここでのＮは、ＳＣＵサイズに等しい。次に、ブロック設定部４７は、当該４つのＣＵに対応する２Ｎ×２Ｎ画素の１つのＣＵについてコストを計算する（ステップＳ７２）。次に、ブロック設定部４７は、ステップＳ７１ｂにおいて計算したコストの合計とステップＳ７２において計算したコストとを比較することにより、２Ｎ×２Ｎ画素のＣＵを分割するかを判定し、判定結果に対応する分割フラグを生成する（ステップＳ７３ｂ）。

次に、ブロック設定部４７は、当該２Ｎ×２Ｎ画素のＣＵがＫ×Ｋ画素のＬＣＵに等しいかを判定する（ステップＳ７４ｂ）。当該２Ｎ×２Ｎ画素のＣＵがＬＣＵに等しい場合には、図１３Ｄに示したブロック設定処理は終了する。一方、そうでない場合には、処理はステップＳ７５へ進む。

ステップＳ７５において、ブロック設定部４７は、２Ｎ×２Ｎ画素の４つのＣＵについて分割判定が終了したかを判定する（ステップＳ７５）。ここで、分割判定が終了していない場合には、処理はステップＳ７１ｂへ戻る。２Ｎ×２Ｎ画素の４つのＣＵについて分割判定が終了した場合、処理はステップＳ７６へ進む。

ステップＳ７６において、ブロック設定部４７は、４Ｎ×４Ｎ画素の１つのＣＵについてコストを計算する（ステップＳ７６）。次に、ブロック設定部４７は、２Ｎ×２Ｎ画素の４つのＣＵのコストの合計とステップＳ７６において計算したコストとを比較することにより、４Ｎ×４Ｎ画素のＣＵを分割するかを判定し、判定結果に対応する分割フラグを生成する（ステップＳ７７）。このようにしてＬＣＵに等しいＣＵについての分割フラグの生成が終了すると、図１３Ｄに示したブロック設定処理は終了する。

図１３Ｃに示した第３の例では、上述したように、浅いレイヤにおいてブロック分割が強制される。例えば、６４×６４画素のＣＵから３２×３２画素のＣＵへのブロック分割が強制される場合、図３Ｂに示したコスト計算処理及び分割判定処理のうち、多くの処理リソースを要するコスト計算処理Ｃｏｓｔ［６４×６４（０）］及び分割判定処理Ｃｏｍｐａｒｅ［６４×６４（０）］をスキップすることができる。また、例えば、１６×１６画素のＣＵへのブロック分割が強制される場合、さらに４回のコスト計算処理（Ｃｏｓｔ［３２×３２（０）］〜Ｃｏｓｔ［３２×３２（３）］）及び４回の分割判定処理（Ｃｏｍｐａｒｅ［３２×３２（０）］〜Ｃｏｍｐａｒｅ［３２×３２（３）］）をスキップすることができる。

図１３Ｄに示した第４の例においても、同様にコスト計算処理及び分割判定処理をスキップすることができる。但し、この例ではＬＣＵサイズが引き下げられるため、画像内のブロックのスキャン順序が通常モードとリソース節約モードとで異なる。図１４は、リソース節約モードでＬＣＵサイズが引き下げられる場合のブロックのスキャン順序を、図３Ａとの対比において説明するための説明図である。図３Ａの例では、６４×６４画素のＬＣＵ内でブロックがスキャンされるため、例えばブロック８×８（３１）の次にスキャンされるブロック８×８（３２）は、ブロック８×８（３１）の下の行の左端に位置する。一方、図１４の例では、３２×３２画素のＬＣＵ内でブロックがスキャンされるため、ブロック８×８（３１）の次にスキャンされるブロック８×８（３２）は、ブロック８×８（３１）の右の列の上端に位置する。同様に、図３Ａの例では、ブロック１６×１６（７）の次にスキャンされるブロック１６×１６（８）は、ブロック１６×１６（７）の下の行の左端に位置する。一方、図１４の例では、ブロック１６×１６（７）の次にスキャンされるブロック１６×１６（８）は、ブロック１６×１６（７）の右の列の上端に位置する。

＜３．第２の実施形態＞
第１の実施形態では、リソース効率に関する動作モードに従ってＬＣＵからＣＵへのブロック分割の深さを制御することについて説明した。本節で説明する第２の実施形態では、ブロック分割の深さの制御に加えて、リソース効率に関する動作モードをさらに活用することにより、エンコーダの処理の負荷を一層低減することを目指す。

［３−１．全体的な構成］
図１５は、第２の実施形態に係る画像符号化装置６０の概略的な構成を示すブロック図である。図１５を参照すると、画像符号化装置６０は、並び替えバッファ１１、減算部１３、直交変換部１４、量子化部１５、可逆符号化部１６、蓄積バッファ１７、レート制御部１８、逆量子化部２１、逆直交変換部２２、加算部２３、ループフィルタ２４、フレームメモリ２５、選択部２６及び２７、イントラ予測部３０、インター予測部３５並びにブロック分割部９０を備える。

ブロック分割部９０は、第１の実施形態に係るブロック分割部４０と同様の機能を有し、画像内に設定されるＬＣＵの各々に、ＣＵのQuad-Tree構造を設定する。ブロック分割部９０は、画像にラスタ状にＬＣＵを配置し、さらに各ＬＣＵを複数のＣＵに分割する。本実施形態においても、ブロック分割部９０は、リソース効率に関する動作モードに従って、ブロック分割の深さを制御する。さらに、本実施形態において、ブロック分割部９０は、リソース効率に関する動作モードに従って、選択部２７によるイントラ予測又はインター予測の選択、インター予測部３５によるマージ判定、及び直交変換部１４によるＴＵの設定、のうち少なくとも１つを制御する。

［３−２．イントラ／インター判定の制御］
例えば、選択部２７は、ＬＣＵ内の１つ以上のＣＵの各々について、イントラ予測のコストとインター予測のコストとを比較することにより、イントラ予測及びインター予測のいずれかを選択する。ブロック分割部９０は、通常モードにおいて、選択部２７にＣＵごとにイントラ予測及びインター予測のいずれを選択すべきかを判定させる。一方、ブロック分割部９０は、リソース節約モードにおいて、選択部２７にＬＣＵ内のＣＵの全てについて共通的に、イントラ予測及びインター予測のいずれを選択すべきかを判定させる。ブロック分割部９０は、例えば、ＬＣＵ内で最初にスキャンされるＣＵ（典型的には、左上のＣＵ）についての判定結果を、残りのＣＵに共通的に適用させてもよい。

図１６は、イントラ／インター判定制御処理の詳細な流れの一例を示すフローチャートである。図１６を参照すると、ブロック分割部９０は、まず、図１１Ａ〜図１１Ｄを用いて説明したモード判定処理を実行する（ステップＳ１０）。そして、イントラ／インター判定制御処理は、判定された動作モードに依存して分岐する（ステップＳ１１５）。動作モードが通常モードである場合、ブロック分割部９０は、ＣＵごとに選択部２７にイントラ予測又はインター予測を選択させる（ステップＳ１２０ａ）。動作モードがリソース節約モードである場合、ブロック分割部９０は、ＬＣＵ内の全てのＣＵについて共通的に、選択部２７にイントラ予測又はインター予測を選択させる（ステップＳ１２０ｂ）。

図１７は、イントラ／インター判定の処理シーケンスの一例について説明するための説明図である。ここでは、選択部２７により実行されるイントラ／インター判定処理が“Ｉｎｔｒａ／Ｉｎｔｅｒ［Ｘ］”と表現され、Ｘは図３Ａに示した対象ブロックのラベルである。図１７に示したように、ＳＣＵサイズが８×８画素、ＬＣＵサイズが６４×６４画素である場合、選択部２７は、通常モードにおいて、８×８画素のＣＵについての６４回のイントラ／インター判定、１６×１６画素のＣＵについての１６回のイントラ／インター判定、３２×３２画素のＣＵについての４回のイントラ／インター判定、及び６４×６４画素のＣＵについての１回のイントラ／インター判定を実行する。これに対し、リソース節約モードでは、より少ない回数（例えば１回）のイントラ／インター判定のみが実行され得る。一例として、選択部２７は、８×８画素のレイヤでイントラ／インター判定Ｐ１１のみを実行し、その結果を残りの全てのＣＵに適用してもよい。また、選択部２７は、１６×１６画素のレイヤでイントラ／インター判定Ｐ１２のみを実行し、その結果を残りの全てのＣＵに適用してもよい。また、選択部２７は、３２×３２画素のレイヤでイントラ／インター判定Ｐ１３のみを実行し、その結果を残りの全てのＣＵに適用してもよい。また、選択部２７は、６４×６４画素のレイヤでイントラ／インター判定Ｐ１４のみを実行してもよい。それにより、イントラ／インター判定のために必要とされるリソースの量が低減され、リソースを効率的に利用することができる。

［３−３．マージ判定の制御］
また、ＨＥＶＣでは、インター予測のための１つのツールとして、マージモードが導入される。インター予測部３５は、ＣＵ内の１つ以上のＰＵの各々について、インター予測処理の中で、当該ＰＵを他のＰＵとマージするかを判定する。複数のＰＵがマージされる場合、それらＰＵについては１セットの動き情報のみが符号化されるため、動き情報に要する符号量を削減することができる。ブロック分割部９０は、通常モードにおいて、インター予測部３５に、ＰＵごとに当該ＰＵを他のＰＵとマージするかを判定させる。一方、ブロック分割部９０は、リソース節約モードにおいて、各ＣＵ内の１つ以上のＰＵの全てをマージするか以外のマージ判定を、インター予測部３５にスキップさせる。ブロック分割部９０は、さらに、ＬＣＵ内のＰＵの全てをマージするか以外のマージ判定をインター予測部３５にスキップさせてもよい。

図１８は、マージ判定制御処理の詳細な流れの一例を示すフローチャートである。図１８を参照すると、ブロック分割部９０は、まず、図１１Ａ〜図１１Ｄを用いて説明したモード判定処理を実行する（ステップＳ１０）。そして、マージ判定制御処理は、判定された動作モードに依存して分岐する（ステップＳ１１５）。動作モードが通常モードである場合、ブロック分割部９０は、ＰＵごとにインター予測部３５にマージ判定を実行させる（ステップＳ１３０ａ）。動作モードがリソース節約モードである場合、ブロック分割部９０は、ＣＵ（又はＬＣＵ）内の全てのＰＵをマージするか否かのみのマージ判定を、インター予測部３５に実行させる（ステップＳ１３０ｂ）。

［３−４．変換単位の設定の制御］
また、ＨＥＶＣでは、ＴＵサイズとして、４×４画素〜３２×３２画素の４種類のサイズが利用可能である。直交変換部１４は、ＣＵを分割することにより形成される１つ以上のＴＵの各々について、予測誤差データについて直交変換を実行する。より小さいＴＵサイズが利用される場合、高い画質が達成され得る一方で、変換係数データにより多くのＤＣ成分が含まれることになるため、リソースの利用効率は低下し得る。そこで、ブロック分割部９０は、通常モードにおいてＴＵサイズの選択を制限しない一方、リソース節約モードにおいて、ＴＵが利用可能なサイズのうちより小さいサイズ（例えば、４×４画素、又は４×４画素及び８×８画素）を有しないように直交変換部１４におけるＴＵサイズの選択を制御する。

図１９は、変換単位制御処理の詳細な流れの一例を示すフローチャートである。図１９を参照すると、ブロック分割部９０は、まず、図１１Ａ〜図１１Ｄを用いて説明したモード判定処理を実行する（ステップＳ１０）。そして、変換単位制御処理は、判定された動作モードに依存して分岐する（ステップＳ１１５）。動作モードが通常モードである場合、ブロック分割部９０は、全てのＴＵサイズの候補から最適なＴＵサイズを直交変換部１４に選択させる（ステップＳ１４０ａ）。動作モードがリソース節約モードである場合、ブロック分割部９０は、例えばＴＵサイズの候補を４×４画素を除外するように制限し、制限されたＴＵサイズの候補から最適なＴＵサイズを直交変換部１４に選択させる（ステップＳ１４０ｂ）。

＜４．応用例＞
上述した実施形態は、衛星回線、ケーブルＴＶ回線、インターネット、若しくはセルラー通信ネットワークなどを用いて映像の符号化ストリームを送信する送信装置、又は映像の符号化ストリームを光ディスク、磁気ディスク若しくはフラッシュメモリなどの媒体に記録する記録装置、といった様々な電子機器に応用され得る。以下、３つの応用例について説明する。

（１）第１の応用例
図２０は、上述した実施形態を適用した携帯電話機の概略的な構成の一例を示している。携帯電話機９２０は、アンテナ９２１、通信部９２２、音声コーデック９２３、スピーカ９２４、マイクロホン９２５、カメラ部９２６、画像処理部９２７、多重分離部９２８、記録再生部９２９、表示部９３０、制御部９３１、操作部９３２、センサ部９３３、バス９３４及びバッテリー９３５を備える。

アンテナ９２１は、通信部９２２に接続される。スピーカ９２４及びマイクロホン９２５は、音声コーデック９２３に接続される。操作部９３２は、制御部９３１に接続される。バス９３４は、通信部９２２、音声コーデック９２３、カメラ部９２６、画像処理部９２７、多重分離部９２８、記録再生部９２９、表示部９３０、制御部９３１及びセンサ部９３３を相互に接続する。

携帯電話機９２０は、音声通話モード、データ通信モード、撮影モード及びテレビ電話モードを含む様々な動作モードで、音声信号の送受信、電子メール又は画像データの送受信、画像の撮像、及びデータの記録などの動作を行う。

音声通話モードにおいて、マイクロホン９２５により生成されるアナログ音声信号は、音声コーデック９２３に供給される。音声コーデック９２３は、アナログ音声信号を音声データへ変換し、変換された音声データをＡ／Ｄ変換し圧縮する。そして、音声コーデック９２３は、圧縮後の音声データを通信部９２２へ出力する。通信部９２２は、音声データを符号化及び変調し、送信信号を生成する。そして、通信部９２２は、生成した送信信号をアンテナ９２１を介して基地局（図示せず）へ送信する。また、通信部９２２は、アンテナ９２１を介して受信される無線信号を増幅し及び周波数変換し、受信信号を取得する。そして、通信部９２２は、受信信号を復調及び復号して音声データを生成し、生成した音声データを音声コーデック９２３へ出力する。音声コーデック９２３は、音声データを伸張し及びＤ／Ａ変換し、アナログ音声信号を生成する。そして、音声コーデック９２３は、生成した音声信号をスピーカ９２４に供給して音声を出力させる。

また、データ通信モードにおいて、例えば、制御部９３１は、操作部９３２を介するユーザによる操作に応じて、電子メールを構成する文字データを生成する。また、制御部９３１は、文字を表示部９３０に表示させる。また、制御部９３１は、操作部９３２を介するユーザからの送信指示に応じて電子メールデータを生成し、生成した電子メールデータを通信部９２２へ出力する。通信部９２２は、電子メールデータを符号化及び変調し、送信信号を生成する。そして、通信部９２２は、生成した送信信号をアンテナ９２１を介して基地局（図示せず）へ送信する。また、通信部９２２は、アンテナ９２１を介して受信される無線信号を増幅し及び周波数変換し、受信信号を取得する。そして、通信部９２２は、受信信号を復調及び復号して電子メールデータを復元し、復元した電子メールデータを制御部９３１へ出力する。制御部９３１は、表示部９３０に電子メールの内容を表示させると共に、電子メールデータを記録再生部９２９の記憶媒体に記憶させる。

記録再生部９２９は、読み書き可能な任意の記憶媒体を有する。例えば、記憶媒体は、ＲＡＭ又はフラッシュメモリなどの内蔵型の記憶媒体であってもよく、ハードディスク、磁気ディスク、光磁気ディスク、光ディスク、ＵＳＢメモリ、又はメモリカードなどの外部装着型の記憶媒体であってもよい。

また、撮影モードにおいて、例えば、カメラ部９２６は、被写体を撮像して画像データを生成し、生成した画像データを画像処理部９２７へ出力する。画像処理部９２７は、カメラ部９２６から入力される画像データを符号化し、符号化ストリームを記録再生部９２９の記憶媒体に記憶させる。

また、テレビ電話モードにおいて、例えば、多重分離部９２８は、画像処理部９２７により符号化された映像ストリームと、音声コーデック９２３から入力される音声ストリームとを多重化し、多重化したストリームを通信部９２２へ出力する。通信部９２２は、ストリームを符号化及び変調し、送信信号を生成する。そして、通信部９２２は、生成した送信信号をアンテナ９２１を介して基地局（図示せず）へ送信する。また、通信部９２２は、アンテナ９２１を介して受信される無線信号を増幅し及び周波数変換し、受信信号を取得する。これら送信信号及び受信信号には、符号化ビットストリームが含まれ得る。そして、通信部９２２は、受信信号を復調及び復号してストリームを復元し、復元したストリームを多重分離部９２８へ出力する。多重分離部９２８は、入力されるストリームから映像ストリーム及び音声ストリームを分離し、映像ストリームを画像処理部９２７、音声ストリームを音声コーデック９２３へ出力する。画像処理部９２７は、映像ストリームを復号し、映像データを生成する。映像データは、表示部９３０に供給され、表示部９３０により一連の画像が表示される。音声コーデック９２３は、音声ストリームを伸張し及びＤ／Ａ変換し、アナログ音声信号を生成する。そして、音声コーデック９２３は、生成した音声信号をスピーカ９２４に供給して音声を出力させる。

センサ部９３３は、加速度センサ及びジャイロセンサなどのセンサ群を含み、携帯電話機９２０の動きを表す指標を出力する。バッテリー９３５は、図中では省略されている電力供給ラインを介して、通信部９２２、音声コーデック９２３、カメラ部９２６、画像処理部９２７、多重分離部９２８、記録再生部９２９、表示部９３０、制御部９３１及びセンサ部９３３に電力を供給する。

このように構成された携帯電話機９２０において、画像処理部９２７は、上述した実施形態に係る画像符号化装置１０又は６０の機能を有する。それにより、携帯電話機９２０において、リソース効率に関する動作モードに従って画像処理部９２７におけるブロック分割の深さを柔軟に制御し、携帯電話機９２０のリソースを効率的に利用することが可能となる。

（２）第２の応用例
図２１は、上述した実施形態を適用した記録再生装置の概略的な構成の一例を示している。記録再生装置９４０は、例えば、受信した放送番組の音声データ及び映像データを符号化して記録媒体に記録する。また、記録再生装置９４０は、例えば、他の装置から取得される音声データ及び映像データを符号化して記録媒体に記録してもよい。また、記録再生装置９４０は、例えば、ユーザの指示に応じて、記録媒体に記録されているデータをモニタ及びスピーカ上で再生する。このとき、記録再生装置９４０は、音声データ及び映像データを復号する。

記録再生装置９４０は、チューナ９４１、外部インタフェース９４２、エンコーダ９４３、ＨＤＤ（Hard Disk Drive）９４４、ディスクドライブ９４５、セレクタ９４６、デコーダ９４７、ＯＳＤ（On-Screen Display）９４８、制御部９４９、及びユーザインタフェース９５０を備える。

チューナ９４１は、アンテナ（図示せず）を介して受信される放送信号から所望のチャンネルの信号を抽出し、抽出した信号を復調する。そして、チューナ９４１は、復調により得られた符号化ビットストリームをセレクタ９４６へ出力する。即ち、チューナ９４１は、記録再生装置９４０における伝送手段としての役割を有する。

外部インタフェース９４２は、記録再生装置９４０と外部機器又はネットワークとを接続するためのインタフェースである。外部インタフェース９４２は、例えば、ＩＥＥＥ１３９４インタフェース、ネットワークインタフェース、ＵＳＢインタフェース、又はフラッシュメモリインタフェースなどであってよい。例えば、外部インタフェース９４２を介して受信される映像データ及び音声データは、エンコーダ９４３へ入力される。即ち、外部インタフェース９４２は、記録再生装置９４０における伝送手段としての役割を有する。

エンコーダ９４３は、外部インタフェース９４２から入力される映像データ及び音声データが符号化されていない場合に、映像データ及び音声データを符号化する。そして、エンコーダ９４３は、符号化ビットストリームをセレクタ９４６へ出力する。

ＨＤＤ９４４は、映像及び音声などのコンテンツデータが圧縮された符号化ビットストリーム、各種プログラム及びその他のデータを内部のハードディスクに記録する。また、ＨＤＤ９４４は、映像及び音声の再生時に、これらデータをハードディスクから読み出す。

ディスクドライブ９４５は、装着されている記録媒体へのデータの記録及び読み出しを行う。ディスクドライブ９４５に装着される記録媒体は、例えばＤＶＤディスク（ＤＶＤ−Ｖｉｄｅｏ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等）又はＢｌｕ−ｒａｙ（登録商標）ディスクなどであってよい。

セレクタ９４６は、映像及び音声の記録時には、チューナ９４１又はエンコーダ９４３から入力される符号化ビットストリームを選択し、選択した符号化ビットストリームをＨＤＤ９４４又はディスクドライブ９４５へ出力する。また、セレクタ９４６は、映像及び音声の再生時には、ＨＤＤ９４４又はディスクドライブ９４５から入力される符号化ビットストリームをデコーダ９４７へ出力する。

デコーダ９４７は、符号化ビットストリームを復号し、映像データ及び音声データを生成する。そして、デコーダ９４７は、生成した映像データをＯＳＤ９４８へ出力する。また、デコーダ９０４は、生成した音声データを外部のスピーカへ出力する。

ＯＳＤ９４８は、デコーダ９４７から入力される映像データを再生し、映像を表示する。また、ＯＳＤ９４８は、表示する映像に、例えばメニュー、ボタン又はカーソルなどのＧＵＩの画像を重畳してもよい。

制御部９４９は、ＣＰＵなどのプロセッサ、並びにＲＡＭ及びＲＯＭなどのメモリを有する。メモリは、ＣＰＵにより実行されるプログラム、及びプログラムデータなどを記憶する。メモリにより記憶されるプログラムは、例えば、記録再生装置９４０の起動時にＣＰＵにより読み込まれ、実行される。ＣＰＵは、プログラムを実行することにより、例えばユーザインタフェース９５０から入力される操作信号に応じて、記録再生装置９４０の動作を制御する。

ユーザインタフェース９５０は、制御部９４９と接続される。ユーザインタフェース９５０は、例えば、ユーザが記録再生装置９４０を操作するためのボタン及びスイッチ、並びに遠隔制御信号の受信部などを有する。ユーザインタフェース９５０は、これら構成要素を介してユーザによる操作を検出して操作信号を生成し、生成した操作信号を制御部９４９へ出力する。

このように構成された記録再生装置９４０において、エンコーダ９４３は、上述した実施形態に係る画像符号化装置１０又は６０の機能を有する。それにより、記録再生装置９４０において、リソース効率に関する動作モードに従ってエンコーダ９４３におけるブロック分割の深さを柔軟に制御し、記録再生装置９４０のリソースを効率的に利用することが可能となる。

（３）第３の応用例
図２２は、上述した実施形態を適用した撮像装置の概略的な構成の一例を示している。撮像装置９６０は、被写体を撮像して画像を生成し、画像データを符号化して記録媒体に記録する。

撮像装置９６０は、光学ブロック９６１、撮像部９６２、信号処理部９６３、画像処理部９６４、表示部９６５、外部インタフェース９６６、メモリ９６７、メディアドライブ９６８、ＯＳＤ９６９、制御部９７０、ユーザインタフェース９７１、センサ９７２、バス９７３及びバッテリー９７４を備える。

光学ブロック９６１は、撮像部９６２に接続される。撮像部９６２は、信号処理部９６３に接続される。表示部９６５は、画像処理部９６４に接続される。ユーザインタフェース９７１は、制御部９７０に接続される。バス９７３は、画像処理部９６４、外部インタフェース９６６、メモリ９６７、メディアドライブ９６８、ＯＳＤ９６９、制御部９７０及びセンサ９７２を相互に接続する。

光学ブロック９６１は、フォーカスレンズ及び絞り機構などを有する。光学ブロック９６１は、被写体の光学像を撮像部９６２の撮像面に結像させる。撮像部９６２は、ＣＣＤ又はＣＭＯＳなどのイメージセンサを有し、撮像面に結像した光学像を光電変換によって電気信号としての画像信号に変換する。そして、撮像部９６２は、画像信号を信号処理部９６３へ出力する。

信号処理部９６３は、撮像部９６２から入力される画像信号に対してニー補正、ガンマ補正、色補正などの種々のカメラ信号処理を行う。信号処理部９６３は、カメラ信号処理後の画像データを画像処理部９６４へ出力する。

画像処理部９６４は、信号処理部９６３から入力される画像データを符号化し、符号化データを生成する。そして、画像処理部９６４は、生成した符号化データを外部インタフェース９６６又はメディアドライブ９６８へ出力する。また、画像処理部９６４は、外部インタフェース９６６又はメディアドライブ９６８から入力される符号化データを復号し、画像データを生成する。そして、画像処理部９６４は、生成した画像データを表示部９６５へ出力する。また、画像処理部９６４は、信号処理部９６３から入力される画像データを表示部９６５へ出力して画像を表示させてもよい。また、画像処理部９６４は、ＯＳＤ９６９から取得される表示用データを、表示部９６５へ出力する画像に重畳してもよい。

ＯＳＤ９６９は、例えばメニュー、ボタン又はカーソルなどのＧＵＩの画像を生成して、生成した画像を画像処理部９６４へ出力する。

外部インタフェース９６６は、例えばＵＳＢ入出力端子として構成される。外部インタフェース９６６は、例えば、画像の印刷時に、撮像装置９６０とプリンタとを接続する。また、外部インタフェース９６６には、必要に応じてドライブが接続される。ドライブには、例えば、磁気ディスク又は光ディスクなどのリムーバブルメディアが装着され、リムーバブルメディアから読み出されるプログラムが、撮像装置９６０にインストールされ得る。さらに、外部インタフェース９６６は、ＬＡＮ又はインターネットなどのネットワークに接続されるネットワークインタフェースとして構成されてもよい。即ち、外部インタフェース９６６は、撮像装置９６０における伝送手段としての役割を有する。

メディアドライブ９６８に装着される記録媒体は、例えば、磁気ディスク、光磁気ディスク、光ディスク、又は半導体メモリなどの、読み書き可能な任意のリムーバブルメディアであってよい。また、メディアドライブ９６８に記録媒体が固定的に装着され、例えば、内蔵型ハードディスクドライブ又はＳＳＤ（Solid State Drive）のような非可搬性の記憶部が構成されてもよい。

制御部９７０は、ＣＰＵなどのプロセッサ、並びにＲＡＭ及びＲＯＭなどのメモリを有する。メモリは、ＣＰＵにより実行されるプログラム、及びプログラムデータなどを記憶する。メモリにより記憶されるプログラムは、例えば、撮像装置９６０の起動時にＣＰＵにより読み込まれ、実行される。ＣＰＵは、プログラムを実行することにより、例えばユーザインタフェース９７１から入力される操作信号に応じて、撮像装置９６０の動作を制御する。

ユーザインタフェース９７１は、制御部９７０と接続される。ユーザインタフェース９７１は、例えば、ユーザが撮像装置９６０を操作するためのボタン及びスイッチなどを有する。ユーザインタフェース９７１は、これら構成要素を介してユーザによる操作を検出して操作信号を生成し、生成した操作信号を制御部９７０へ出力する。

センサ９７２は、加速度センサ及びジャイロセンサなどのセンサ群を含み、撮像装置９６０の動きを表す指標を出力する。バッテリー９７４は、図中では省略されている電力供給ラインを介して、撮像部９６２、信号処理部９６３、画像処理部９６４、表示部９６５、メディアドライブ９６８、ＯＳＤ９６９、制御部９７０及びセンサ９７２に電力を供給する。

このように構成された撮像装置９６０において、画像処理部９６４は、上述した実施形態に係る画像符号化装置１０又は６０の機能を有する。それにより、撮像装置９６０において、リソース効率に関する動作モードに従って画像処理部９６４におけるブロック分割の深さを柔軟に制御し、撮像装置９６０のリソースを効率的に利用することが可能となる。

＜５．まとめ＞
ここまで、図１〜図２２を用いて、本開示に係る技術の実施形態について詳細に説明した。上述した実施形態によれば、符号化される画像のブロックを再帰的に分割することにより符号化単位が形成される画像符号化方式において、符号化単位を設定する際のブロック分割の深さが、リソース効率に関するモードに従って制御される。従って、例えば画質を優先すべき状況においては、最適なブロック分割を決定するために十分なリソースを確保する一方で、リソース効率を優先すべき状況においてはブロック分割の深さを制限してリソースを節約することができる。例えば、ブロック分割の深さが制限される場合、バッテリー消費が低減され、余剰のリソースを使用して高フレームレート化が実現され、又は符号化処理が高速化され得る。

ある実施例においては、複数の利用可能なサイズのうち、より小さいサイズを符号化単位が有しないように、ブロック分割の深さが制限される。この場合、ブロック分割の決定に要する処理の多くを省略し、リソースの使用量を効果的に削減することができる。また、ある実施例においては、複数の利用可能なサイズのうち、より大きいサイズを符号化単位が有しないように、ブロック分割の深さが制限される。この場合、リソースの使用量を削減しつつも、小さいＣＵを使用して画像の細かいテクスチャを復号時に再現する余地を残すことができる。

ある実施例においては、ＬＣＵサイズ又はＳＣＵサイズの値を調整することにより、ブロック分割の深さが制限される。この場合、Quad-Tree構造を特定するために要する分割フラグの数が削減されるため、符号化効率を高めることができる。また、ある実施例においては、ＬＣＵサイズ又はＳＣＵサイズの値が調整される代わりに、符号化単位の所定のサイズについてコストの比較をスキップすることにより、ブロック分割の深さが制限される。この場合、ＳＰＳを更新することなく、分割の深さを自在に変化させることができる。

なお、本明細書において説明した各装置による一連の制御処理は、ソフトウェア、ハードウェア、及びソフトウェアとハードウェアとの組合せのいずれを用いて実現されてもよい。ソフトウェアを構成するプログラムは、例えば、各装置の内部又は外部に設けられる記憶媒体（非一時的な媒体：non-transitory media）に予め格納される。そして、各プログラムは、例えば、実行時にＲＡＭ（Random Access Memory）に読み込まれ、ＣＰＵなどのプロセッサにより実行される。

本明細書に記述したＣＵ、ＰＵ及びＴＵとの用語は、ＨＥＶＣにおいて、個々のブロックに関連付られるシンタックスをも含む論理的な単位を意味する。画像の一部分としての個々のブロックのみに着目する場合、これらは、ＣＢ（Coding Block）、ＰＢ（Prediction Block）及びＴＢ（Transform Block）との用語にそれぞれ置き換えられてもよい。ＣＢは、ＣＴＢ（Coding Tree Block）を四分木（Quad-Tree）状に階層的に分割することにより形成される。１つの四分木の全体がＣＴＢに相当し、ＣＴＢに対応する論理的な単位はＣＴＵ（Coding Tree Unit）と呼ばれる。

また、本明細書では、ブロック分割に関する情報が、符号化ストリームのヘッダに多重化されて、符号化側から復号側へ伝送される例について主に説明した。しかしながら、これら情報を伝送する手法はかかる例に限定されない。例えば、これら情報は、符号化ビットストリームに多重化されることなく、符号化ビットストリームと関連付けられた別個のデータとして伝送され又は記録されてもよい。ここで、「関連付ける」という用語は、ビットストリームに含まれる画像（スライス若しくはブロックなど、画像の一部であってもよい）と当該画像に対応する情報とを復号時にリンクさせ得るようにすることを意味する。即ち、情報は、画像（又はビットストリーム）とは別の伝送路上で伝送されてもよい。また、情報は、画像（又はビットストリーム）とは別の記録媒体（又は同一の記録媒体の別の記録エリア）に記録されてもよい。さらに、情報と画像（又はビットストリーム）とは、例えば、複数フレーム、１フレーム、又はフレーム内の一部分などの任意の単位で互いに関連付けられてよい。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

なお、以下のような構成も本開示の技術的範囲に属する。
（１）
符号化される画像のブロックを再帰的に分割することにより形成される符号化単位を、前記ブロックに設定する設定部と、
前記設定部におけるブロック分割の深さを、リソース効率に関するモードに従って制御する制御部と、
を備える画像処理装置。
（２）
前記制御部は、前記モードがリソース効率を優先すべきことを示す場合に、前記ブロック分割の前記深さを制限する、前記（１）に記載の画像処理装置。
（３）
前記制御部は、複数の利用可能なサイズのうちより小さいサイズを前記符号化単位が有しないように、前記ブロック分割の前記深さを制限する、前記（２）に記載の画像処理装置。
（４）
前記制御部は、複数の利用可能なサイズのうちより大きいサイズを前記符号化単位が有しないように、前記ブロック分割の前記深さを制限する、前記（２）に記載の画像処理装置。
（５）
前記符号化単位の利用可能なサイズの範囲は、ＳＣＵ（Smallest Coding Unit）サイズ及びＬＣＵ（Largest Coding Unit）サイズによって定義され、
前記制御部は、前記ＬＣＵサイズ又は前記ＳＣＵサイズの値を調整することにより、前記ブロック分割の前記深さを制限する、
前記（３）又は前記（４）に記載の画像処理装置。
（６）
前記ブロック分割の前記深さは、分割フラグを再帰的に指定することにより特定され、
前記設定部は、前記分割フラグの値をコストの比較に基づいて決定し、
前記制御部は、前記符号化単位の所定のサイズについて前記設定部に前記コストの比較をスキップさせることにより、前記ブロック分割の前記深さを制限する、
前記（３）又は前記（４）に記載の画像処理装置。
（７）
前記リソース効率は、バッテリーの利用効率を含む、前記（１）〜（６）のいずれか１項に記載の画像処理装置。
（８）
前記制御部は、バッテリー残量が閾値を下回る場合、又は前記画像処理装置が外部電源に接続されていない場合に、画質よりもバッテリーの利用効率を優先すべきことを示すように前記モードを自動的に設定する、前記（７）に記載の画像処理装置。
（９）
前記リソース効率は、処理リソースの利用効率を含み、
前記制御部は、前記モードが画質よりも処理リソースの利用効率を優先すべきことを示す場合に、高フレームレート化又は高速化のために前記ブロック分割の前記深さを制限する、
前記（１）〜（６）のいずれか１項に記載の画像処理装置。
（１０）
前記制御部は、ユーザインタフェースを介してユーザ入力を取得することにより、前記モードを設定する、前記（１）〜（９）のいずれか１項に記載の画像処理装置。
（１１）
前記制御部は、前記画像を撮像する装置の動きが速い場合に、リソース効率を優先すべきことを示すように前記モードを自動的に設定する、前記（１）〜（６）のいずれか１項に記載の画像処理装置。
（１２）
前記画像処理装置は、前記ブロック内の１つ以上の符号化単位の各々について、イントラ予測及びインター予測のいずれかを選択する選択部、をさらに備え、
前記制御部は、前記モードがリソース効率を優先すべきことを示す場合に、前記ブロック内の前記１つ以上の符号化単位の全てについて共通的な予測モードを前記選択部に選択させる、
前記（１）〜（１１）のいずれか１項に記載の画像処理装置。
（１３）
前記画像処理装置は、前記符号化単位内の１つ以上の予測単位の各々について、当該予測単位を他の予測単位とマージするかを判定するインター予測部、をさらに備え、
前記制御部は、前記モードがリソース効率を優先すべきことを示す場合に、前記１つ以上の予測単位の全てをマージするか以外のマージ判定を、前記インター予測部にスキップさせる、
前記（１）〜（１２）のいずれか１項に記載の画像処理装置。
（１４）
前記画像処理装置は、前記符号化単位を分割することにより形成される１つ以上の変換単位の各々について、前記画像の予測誤差データを直交変換する変換部、をさらに備え
前記制御部は、前記モードがリソース効率を優先すべきことを示す場合に、複数の利用可能なサイズのうちより小さいサイズを前記変換単位が有しないように、前記変換部を制御する、
前記（１）〜（１３）のいずれか１項に記載の画像処理装置。
（１５）
符号化される画像のブロックを再帰的に分割することにより形成される符号化単位を、前記ブロックに設定することと、
前記ブロックに前記符号化単位を設定する際のブロック分割の深さを、リソース効率に関するモードに従って制御することと、
を含む画像処理方法。
（１６）
画像処理装置を制御するコンピュータを、
符号化される画像のブロックを再帰的に分割することにより形成される符号化単位を、前記ブロックに設定する設定部と、
前記設定部におけるブロック分割の深さを、リソース効率に関するモードに従って制御する制御部と、
として機能させるためのプログラム。

１０，６０画像処理装置（画像符号化装置）
１４直交変換部
２７選択部
３５インター予測部
４１モード制御部
４７ブロック設定部

Claims

符号化される画像のブロックを再帰的に分割することにより形成される符号化単位を、前記ブロックに設定する設定部と、
前記設定部におけるブロック分割の深さを、リソース効率に関するモードに従って制御する制御部と、
を備える画像処理装置。
前記制御部は、前記モードがリソース効率を優先すべきことを示す場合に、前記ブロック分割の前記深さを制限する、請求項１に記載の画像処理装置。
前記制御部は、複数の利用可能なサイズのうちより小さいサイズを前記符号化単位が有しないように、前記ブロック分割の前記深さを制限する、請求項２に記載の画像処理装置。
前記制御部は、複数の利用可能なサイズのうちより大きいサイズを前記符号化単位が有しないように、前記ブロック分割の前記深さを制限する、請求項２に記載の画像処理装置。
前記符号化単位の利用可能なサイズの範囲は、ＳＣＵ（Smallest Coding Unit）サイズ及びＬＣＵ（Largest Coding Unit）サイズによって定義され、
前記制御部は、前記ＬＣＵサイズ又は前記ＳＣＵサイズの値を調整することにより、前記ブロック分割の前記深さを制限する、
請求項３に記載の画像処理装置。
前記ブロック分割の前記深さは、分割フラグを再帰的に指定することにより特定され、
前記設定部は、前記分割フラグの値をコストの比較に基づいて決定し、
前記制御部は、前記符号化単位の所定のサイズについて前記設定部に前記コストの比較をスキップさせることにより、前記ブロック分割の前記深さを制限する、
請求項３に記載の画像処理装置。
前記リソース効率は、バッテリーの利用効率を含む、請求項１に記載の画像処理装置。
前記制御部は、バッテリー残量が閾値を下回る場合、又は前記画像処理装置が外部電源に接続されていない場合に、画質よりもバッテリーの利用効率を優先すべきことを示すように前記モードを自動的に設定する、請求項７に記載の画像処理装置。
前記リソース効率は、処理リソースの利用効率を含み、
前記制御部は、前記モードが画質よりも処理リソースの利用効率を優先すべきことを示す場合に、高フレームレート化又は高速化のために前記ブロック分割の前記深さを制限する、
請求項１に記載の画像処理装置。
前記制御部は、ユーザインタフェースを介してユーザ入力を取得することにより、前記モードを設定する、請求項１に記載の画像処理装置。
前記制御部は、前記画像を撮像する装置の動きが速い場合に、リソース効率を優先すべきことを示すように前記モードを自動的に設定する、請求項１に記載の画像処理装置。
前記画像処理装置は、前記ブロック内の１つ以上の符号化単位の各々について、イントラ予測及びインター予測のいずれかを選択する選択部、をさらに備え、
前記制御部は、前記モードがリソース効率を優先すべきことを示す場合に、前記ブロック内の前記１つ以上の符号化単位の全てについて共通的な予測モードを前記選択部に選択させる、
請求項１に記載の画像処理装置。
前記画像処理装置は、前記符号化単位内の１つ以上の予測単位の各々について、当該予測単位を他の予測単位とマージするかを判定するインター予測部、をさらに備え、
前記制御部は、前記モードがリソース効率を優先すべきことを示す場合に、前記１つ以上の予測単位の全てをマージするか以外のマージ判定を、前記インター予測部にスキップさせる、
請求項１に記載の画像処理装置。
前記画像処理装置は、前記符号化単位を分割することにより形成される１つ以上の変換単位の各々について、前記画像の予測誤差データを直交変換する変換部、をさらに備え
前記制御部は、前記モードがリソース効率を優先すべきことを示す場合に、複数の利用可能なサイズのうちより小さいサイズを前記変換単位が有しないように、前記変換部を制御する、
請求項１に記載の画像処理装置。
符号化される画像のブロックを再帰的に分割することにより形成される符号化単位を、前記ブロックに設定することと、
前記ブロックに前記符号化単位を設定する際のブロック分割の深さを、リソース効率に関するモードに従って制御することと、
を含む画像処理方法。
画像処理装置を制御するコンピュータを、
符号化される画像のブロックを再帰的に分割することにより形成される符号化単位を、前記ブロックに設定する設定部と、
前記設定部におけるブロック分割の深さを、リソース効率に関するモードに従って制御する制御部と、
として機能させるためのプログラム。