JP7383128B2 - 画像処理装置 - Google Patents

Description

本開示はデータ処理技術に関し、特に画像処理装置およびサーバに関する。

クラウドゲームにおいては、サーバにてゲームアプリケーションが実行され、ゲームシーン画像が描画される。サーバは、描画したゲームシーン画像を、ネットワークを介してクライアント端末に提供する。クライアント端末は、サーバから提供されたゲームシーン画像を表示させる。

サーバから提供されるゲームシーン画像は、有限ネットワーク帯域にて送信するために、非可逆圧縮符号化による映像クオリティの劣化や、解像度の引き下げが起きえる。また、クライアント端末が備えるディスプレイの解像度や対応色空間が、サーバから提供されたゲームシーン画像の解像度や色空間よりも高度な場合がある。このような場合、ユーザが視聴するゲームシーン画像のクオリティを引き上げるために、クライアント端末が超解像処理を実行することが考えられる。

従来の手法では超解像処理に長い時間を要しており、ユーザがクラウドゲームをリアルタイムでプレイすることが困難になる可能性がある。

本開示はこうした課題に鑑みてなされたものであり、１つの目的は、超解像を低遅延で処理する技術を提供することにある。

上記課題を解決するために、本開示のある態様の画像処理装置は、動画像のデータを１フレームより小さい部分画像単位で取得する取得部と、取得部により取得された部分画像を単位として超解像処理を実行する超解像処理部と、超解像処理部により超解像処理がなされた部分画像を順次表示部に出力する表示制御部と、を備える。

本開示の別の態様は、サーバである。このサーバは、アプリケーションの動画像をフレーム単位で生成する画像生成部と、画像生成部により生成された画像を１フレームより小さい部分画像の単位で圧縮符号化する圧縮符号化部と、圧縮符号化された部分画像を、部分画像を単位として超解像処理を実行するクライアント端末に送信する送信部と、を備える。

なお、以上の構成要素の任意の組合せ、本開示の表現を、システム、コンピュータプログラム、コンピュータプログラムを記録した記録媒体などの間で変換したものもまた、本開示の態様として有効である。

本開示によれば、超解像を低遅延で処理することができる。

第１実施例の情報処理システムの構成を示すブロック図である。 第１実施例の情報処理システムの構成を示すブロック図である。 図２の超解像処理部の詳細な構成を示すブロック図である。 シーン解析処理を低遅延化する方法を模式的に示す図である。 機械学習ベースの超解像処理を模式的に示す図である。 深層学習ベースの超解像処理を模式的に示す図である。 部分画像単位のパイプライン処理の概念図である。 部分画像単位のパイプライン処理の概念図である。 ゲームアプリケーションが保持するシーン情報の例を示す図である。 シーン解析の例を示す図である。 ＣＵユニット割当情報の例を示す図である。 シーン解析手法の例を示す図である。 シーン解析手法の例を示す図である。 シーン解析手法の例を示す図である。 第２実施例のゲームコンソールの構成を示すブロック図である。 第２実施例のゲームコンソールの構成を示すブロック図である。 第２実施例のゲームコンソールの構成を示すブロック図である。 第３実施例のゲームコンソールの構成を示すブロック図である。 第４実施例のゲームコンソールの構成を示すブロック図である。 ビデオタイミング例を示す図である。 第４実施例のゲームコンソールの構成を示すブロック図である。

＜背景と課題＞
クラウドゲームで超解像を処理する背景と課題を説明する。超解像処理（Super Resolution, Video quality enhancement）とは、画像の高精細度化や、高周波成分の復元または再構築を含む画像処理である。

クラウドゲームにおいては、サーバにてゲームアプリケーションが実行され、ゲームシーン画像が描画される。ゲームシーン画像は、ネットワークを介して、クライアント端末に提供される。ユーザはクライアント端末を介してゲームシーンを視聴し、ゲームに対する入力を行う。ユーザの入力に関するデータは、ネットワークを介してサーバに転送され、ゲームアプリケーションの進行に反映される。
この一連の処理に時間がかかると、クライアント端末へのゲームシーン画像の到着が遅れ、ユーザはリアルタイムでのゲームプレイが困難になる。そのため、処理系全体の低遅延化が求められる。

また、ゲームシーン画像は、例えば、ＦＨＤ（Full HD）画像（１９２０×１０８０画素)の６０ｆｐｓ（frames per second）や、４Ｋ画像（３８４０×２１６０画素）の６０ｆｐｓ等のビデオ映像である。ゲームシーン画像を有限ネットワーク帯域（例えば１０Ｍｂｐｓや３０Ｍｂｐｓ）で送信するには圧縮符号化が必要となる。

ここで、有限ネットワーク帯域にて送信するために、ゲームシーン画像には、非可逆圧縮符号化による映像クオリティの劣化や、解像度の引き下げ（ダウンスケーリング）が起き得る。また、クライアント端末が備える表示ディスプレイの解像度や対応色空間が、サーバから送信されたゲームシーン画像の解像度や色空間よりも高度な場合がある。そのため、ユーザが視聴するゲームシーン画像のクオリティ引き上げのために、ゲームシーン画像が提供されたクライアント端末で超解像処理を実行することが考えられる。

超解像処理では、画像に映る内容を判別または推定するシーン解析の結果に基づいて、当該画像に対して解像度の引き上げ処理（アップスケーリング）やフィルタ処理、復元・再構築処理等が実行される。前述の通り、処理系全体の低遅延化が求められるなかで、追加で発生する処理時間を最小化する必要がある。しかし、従来の超解像処理手法では、これらの処理において１フレーム以上の遅延が発生する。また、超解像処理に先立つシーン解析処理において、あらゆる映像条件に対応してシーンを判別することには限界があり、また、解析能力を引き上げようとすると、高度な処理が必要となって処理遅延が増加してしまうジレンマもある。

本開示では、このような背景と課題を鑑みて、クラウドゲームにおいて、低遅延で超解像処理を実現させる技術と、クラウドゲームにおいて、シーン情報に基づいた超解像処理を実現させる技術を提案する。

本開示にて提案する、クラウドゲームにおいて超解像を処理する方法を説明する。
＜第１の解決手法：クラウドゲームにおいて超解像を低遅延で処理する方法Ａ＞
（１）超解像処理部が、部分画像（以下「スライス」とも呼ぶ。）単位で処理し、表示制御部へ、同様もしくはより小粒度で処理結果を出力する。
（２）ビデオ圧縮符号化部・復号伸長部が、部分画像（スライス）単位で処理し、伸長結果の画像を部分画像（スライス）単位で出力する場合において、後続処理である超解像処理部が、同じ部分画像（スライス）単位で処理し、表示制御部へ、同様もしくはより小粒度で処理結果を出力する。
（３）超解像処理部が、ビデオ圧縮符号化の処理における基本単位と一致させた、基本単位もしくは整数倍の単位で処理を実行する。

（４）超解像処理部が、自ら行うシーン解析において、部分画像（スライス）単位で処理する。
（５）超解像処理部が、部分画像（スライス）単位で処理する。前段のビデオ復号伸長部と超解像処理部との間に、部分画像単位でデータを保持するメモリを設ける。後段の表示制御部と超解像処理部との間に、部分画像単位でデータを保持するメモリを設ける。超解像処理部は、ビデオ復号伸長部との間、および、表示制御部との間で、部分画像単位でフロー制御を実行する。
（６）超解像処理部が、シーン解析もしくはシーン情報統合処理、画像解像度の引き上げ処理（アップスケーリング）、画像フィルタ処理、画像の復元・再構築処理等を実行する場合に、それら個々の処理を部分画像単位で実行する。超解像処理部の内部処理における単位粒度を、整数倍すると、部分画像単位となるようにする。

（７）超解像処理部が、超解像処理において深層学習を用いる場合に、複数の推論処理部を持たせて随時切替利用可能とする。これにより、シーン解析結果に基づいて異なる深層学習モデル（学習結果を保持するデータベース）を推論処理部へ動的に適用する必要がある場合において、設定初期化に要する時間を隠蔽することができる。
（８）シーン解析において、入力画像をピラミッドスケーリングを用いて複数通りの低解像度に変換し、低解像度画像から順にシーン解析を実行する。
（９）シーン解析において、入力画像の離散的な位置からオリジナル解像度でサンプリングした小領域でシーン解析を実行する。
（１０）ゲームアプリケーションから取得したシーン種別に基づいて、超解像処理の簡易化または未実行を選択する。

＜第２の解決手法：クラウドゲームにおいて超解像を低遅延で処理する方法Ｂ＞
この解決手法は、クラウドゲームにおいてシーン情報に基づいて超解像を処理する方法でもある。
（１）超解像処理部は、シーン情報を、ヒントとして前段処理から取得し、超解像処理で利用する。
（２）クライアント端末における超解像処理で利用するシーン情報を、サーバにおいて予め取得し、クライアント端末へ送信する。
（３）クライアント端末における超解像処理で利用するシーン情報を、サーバにおいて圧縮符号化と並行して取得し、クライアント端末へ送信する。

（４）クライアント端末における超解像処理で利用するシーン情報を、サーバにおいて圧縮符号化と並行して解析し、クライアント端末へ送信する。
（５）クライアント端末における超解像処理で利用するシーン情報を、サーバにおいてゲームアプリケーションから取得し、クライアント端末へ送信する。
（６）クライアント端末における超解像処理で利用するシーン情報を、サーバにおける圧縮符号化で用いたシーン解析結果から取得し、クライアント端末へ送信する。

（７）クライアント端末における超解像処理で利用するシーン情報を、復号伸長部が使用する圧縮符号化処理の構成結果から取得する。
（８）クライアント端末の超解像処理部は、サーバまたは復号伸長部から取得した、シーン情報を用いて超解像処理を実行する。
（９）クライアント端末の超解像処理部は、サーバまたは復号伸長部から取得した、シーン情報を用いることで、自ら行うシーン解析を省略もしくは簡易化する。

＜第１実施例＞
図１は、実施例の情報処理システム１０の構成を示すブロック図である。情報処理システム１０は、サーバ１２とクライアント端末１４を備える。サーバ１２は、アプリケーション（実施例ではゲームアプリケーション）を実行する情報処理装置である。クライアント端末１４は、サーバ１２で実行されたアプリケーションの画像（例えばゲームシーン画像）を表示する画像処理装置（情報処理装置とも言え、例えば据置型ゲーム機）である。サーバ１２とクライアント端末１４は、ＬＡＮ・ＷＡＮ・インターネット等を含む通信網を介して接続される。

サーバ１２は、内容決定部２０、画像生成部２２、バッファ２４（レンダリングバッファおよびフレームバッファ）、圧縮符号化部２８、シーン解析部Ｂ２６、シーン情報取得部３２、パケット化部３４、通信部３６を備える。圧縮符号化部２８は、シーン解析部Ａ３０を含む。クライアント端末１４は、通信部４０、データ取得部４２、復号伸長部４４、超解像処理部４８、表示制御部５４、表示パネル５６を備える。復号伸長部４４は、符号化方法取得部４６を含む。超解像処理部４８は、シーン解析部Ｃ５０とシーン情報統合部５２を含む。

本開示のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵ・メモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

図１の各機能ブロックの処理を説明する。サーバ１２の内容決定部２０は、主にＣＰＵにより実現され、ゲームアプリケーションを実行して、描画すべき内容を決定する。サーバ１２の画像生成部２２は、主にＧＰＵにより実現され、内容決定部２０によるゲームアプリケーションの処理結果（例えば描画すべき内容に関するデータ）に基づいて、ゲームアプリケーションの動画像のフレームを描画する（言い換えれば生成する）。画像生成部２２は、描画結果のフレームをバッファ２４（フレームバッファ）に格納する。なお、サーバ１２のバッファ２４（レンダリングバッファ）は、画像生成部２２による描画処理の途中結果等を記憶する。

サーバ１２の圧縮符号化部２８は、バッファ２４（フレームバッファ）に格納された画像（フレーム）のデータを、１フレームより小さい部分画像の単位で圧縮符号化する。圧縮符号化部２８は、非可逆圧縮を行ってもよい。部分画像は、フレームの画像平面を所定サイズに分割してなる各領域の画像である。すなわち部分画像は、例えば画像平面を横方向、縦方向、縦横双方向、または斜め方向に設定した境界線で分割してなる、各領域の画像である。圧縮符号化部２８は内部においてＩフレームとＰフレームを生成してもよく、上記の１フレームより小さい部分画像は、Ｉフレームの部分画像であってもよく、Ｐフレームの部分画像であってもよい。圧縮符号化部２８は、圧縮符号化後の部分画像のデータをパケット化部３４へ出力する。

圧縮符号化部２８のシーン解析部Ａ３０は、圧縮符号化のために元来行うシーン解析処理を実行する。例えば、シーン解析部Ａ３０は、シーン解析処理を実行して、イントラ解析結果（平面類似性）、インター解析結果（動きベクトル）、ＣＵ（Coding Unit）割り当て検討結果、シーンセグメンテーション結果を得る。シーン解析部Ａ３０によるシーン解析処理の結果は、圧縮符号化済みのデータを参照するだけでは判らない解析結果を含む。なお、実施例のシーン解析処理の結果は、解析対象の画像（実施例では部分画像）を特定可能な解析対象の画像の識別情報を含んでもよい。以下のシーン解析結果およびシーン情報も同様である。

サーバ１２のシーン解析部Ｂ２６は、バッファ２４（フレームバッファ）に格納された画像（フレーム）のデータを参照して、超解像処理が元来必要とするシーン解析処理を実行する。シーン解析部Ｂ２６は、圧縮符号化部２８による圧縮符号化処理と並行にシーン解析処理を実行することで、処理時間を隠蔽する。また、シーン解析部Ｂ２６は、シーン解析処理において、バッファ２４（フレームバッファ）に格納されたゲームアプリケーションの描画内容も超解像処理のヒントとして得る。

また、シーン解析部Ｂ２６は、シーン解析処理において、バッファ２４（フレームバッファ）に格納されたゲームアプリケーション以外のアプリケーションやＯＳの描画内容も超解像処理のヒントとしてさらに取得してもよい。超解像処理のヒントは、例えば、ゲームアプリケーションやＯＳが描画するメニューＵＩや字幕等が、どのような種別の画像であるか、どのような形状であるか、どのような画像座標位置に描画されているかといった情報である。この情報には、アプリケーションのメインコンテンツ（ゲームの場合、キャラクタ等）の画像に対して、メニューＵＩや字幕等の付加的なコンテンツの画像が合成（オーバレイ）された画像についての情報であり、付加的なコンテンツが、どのような画像座標位置に、どのような透明度で、メインコンテンツの画像に対して合成されるかを示すα（アルファ）値に関する情報（テーブル等）が含まれてもよい。

サーバ１２のシーン情報取得部３２は、シーン解析部Ａ３０によるシーン解析処理の結果と、シーン解析部Ｂ２６によるシーン解析処理の結果を取得する。また、シーン情報取得部３２は、内容決定部２０から、ゲームアプリケーションに関して描画対象のシーン内容を示す情報を取得する。シーン内容を示す情報は、例えば、３Ｄオブジェクトの配置状態や、利用テクスチャ特性、シーンセグメンテーション情報を含んでもよい。シーン情報取得部３２は、シーン解析部Ａ３０によるシーン解析処理の結果と、シーン解析部Ｂ２６によるシーン解析処理の結果と、内容決定部２０から得られたシーン内容を示す情報とを含むシーン情報（以下「第１シーン情報」とも呼ぶ。）をパケット化部３４へ出力する。

サーバ１２のパケット化部３４は、圧縮符号化部２８から出力された圧縮符号化後の部分画像のデータと、シーン情報取得部３２から出力された第１シーン情報とをパケット化し、通信部３６へ出力する。サーバ１２の通信部３６は、パケット化部３４から出力されたパケットデータを、通信網を介してクライアント端末１４へ送信する。サーバ１２のパケット化部３４と通信部３６は、クライアント端末１４へデータを送信する送信部とも言える。

クライアント端末１４の通信部４０は、サーバ１２から送信されたパケットデータを、通信網を介して受信する。クライアント端末１４のデータ取得部４２は、通信部４０により受信されたパケットデータをもとに、圧縮符号化された部分画像のデータと、第１シーン情報とを取得（再構築）する。データ取得部４２は、圧縮符号化された部分画像のデータを復号伸長部４４へ出力し、第１シーン情報をシーン情報統合部５２へ出力する。

クライアント端末１４の復号伸長部４４は、圧縮符号化された部分画像のデータに対する復号伸長処理を実行して、元の部分画像を得る。復号伸長部４４は、復号伸長後の部分画像を超解像処理部４８へ出力する。復号伸長部４４の符号化方法取得部４６は、圧縮符号化された部分画像のデータに含まれるシーン情報（以下「第２シーン情報」とも呼ぶ。）を得る。言い換えれば、符号化方法取得部４６は、復号伸長処理において使用するサーバ１２における圧縮符号化処理の構成を示す情報（構成結果とも言える）から、復号伸長対象の部分画像に関する第２シーン情報を取得する。第２シーン情報は、フレーム種別（Ｉフレーム、Ｐフレーム等の種別）、量子化パラメータ（ＱＰ）値、動きベクトル、ＣＵ割り当て情報を含む。符号化方法取得部４６は、第２シーン情報をシーン情報統合部５２へ出力する。

クライアント端末１４の超解像処理部４８は、復号伸長部４４から入力された部分画像に対する超解像処理（例えば高解像度化および高画質化）を実行する。超解像処理部４８は、ＣＰＵおよび／またはＧＰＵが、超解像処理のロジックが実装されたコンピュータプログラムを実行することにより実現されてもよい。

超解像処理部４８のシーン解析部Ｃ５０は、公知技術を用いて超解像処理の前段処理としてのシーン解析処理を実行する。具体的には、シーン解析部Ｃ５０は、圧縮符号化および／または解像度引き下げによって劣化した部分画像を分析する。シーン解析部Ｃ５０は、サーバ１２のシーン解析部Ｂ２６と同等のシーン解析処理をさらに実行してもよい。シーン解析部Ｃ５０は、シーン解析処理の結果を第３シーン情報としてシーン情報統合部５２へ出力する。

シーン情報統合部５２は、特定の部分画像の特徴を示す複数種類のシーン情報を統合する。具体的には、シーン情報統合部５２は、データ取得部４２から入力された第１シーン情報と、符号化方法取得部４６から入力された第２シーン情報と、シーン解析部Ｃ５０から入力された第３シーン情報を、各シーン情報に含まれる画像の識別情報をもとに統合することにより、上記特定の部分画像のシーン情報（統合されたシーン情報）を取得する。なお、第１シーン情報、第２シーン情報、第３シーン情報のうちいずれかが欠けてもよく、シーン情報統合部５２は、第１シーン情報、第２シーン情報、第３シーン情報のうち入力されたシーン情報を統合してもよい。超解像処理部４８は、入力された部分画像に対する超解像処理を、シーン情報統合部５２により統合された当該部分画像に対応するシーン情報に基づいて実行する。超解像処理の具体例は後述する。

クライアント端末１４の表示制御部５４は、超解像処理部４８により超解像処理がなされた複数の部分画像を表示パネル５６に順次出力して表示させる。

このように、クライアント端末１４のデータ取得部４２は、表示パネル５６に表示させるべき動画像のデータを１フレームより小さい部分画像単位で取得する。クライアント端末１４の超解像処理部４８は、データ取得部４２により取得された部分画像を単位として超解像処理を実行する。クライアント端末１４の表示制御部５４は、超解像処理部４８により超解像処理がなされた部分画像を順次表示パネル５６に出力する。実施例のクライアント端末１４によると、超解像処理の遅延を抑制することができる。

また、クライアント端末１４の超解像処理部４８は、入力された画像に対して、当該画像の特徴を示すシーン情報をもとに超解像処理を実行する。クライアント端末１４の表示制御部５４は、超解像処理部４８により超解像処理がなされた画像を表示パネル５６に出力する。上記のシーン情報は、超解像処理の対象となる画像に対する超解像処理が行われるまでの前段処理において、予め取得されたものである（例えば第１シーン情報～第３シーン情報）。実施例のクライアント端末１４によると、あらかじめどのようなシーンであるか把握することにより、超解像処理部の処理時間を抑制しながら、そのシーンに最も適した超解像処理を選択実行することが可能となり、高画質化を図りながら、超解像処理の遅延を抑制することができる。

また、サーバ１２の画像生成部２２は、アプリケーションの動画像をフレーム単位で生成する。サーバ１２の圧縮符号化部２８は、画像生成部２２により生成された画像（例えばゲームシーン画像）を１フレームより小さい部分画像の単位で圧縮符号化する。サーバ１２の送信部（例えばパケット化部３４および通信部３６）は、圧縮符号化された部分画像を、部分画像を単位として超解像処理を実行するクライアント端末１４に送信する。実施例のサーバ１２によると、クライアント端末１４における超解像処理の遅延を抑制することができる。

また、サーバ１２の画像生成部２２は、アプリケーションの画像を生成する。サーバ１２のシーン情報取得部３２は、画像生成部により生成された画像の特徴を示すシーン情報（例えば第１シーン情報）を取得する。サーバ１２の送信部は、画像のデータとシーン情報とをクライアント端末１４に送信することにより、上記画像に対する超解像処理を上記シーン情報に基づいてクライアント端末１４に実行させる。実施例のサーバ１２によると、クライアント端末１４において効率的な超解像処理が可能となり、クライアント端末１４における超解像処理の遅延を抑制することができる。

図２も、実施例の情報処理システム１０の構成を示すブロック図である。図２の情報処理システム１０の機能ブロックのうち、図１の情報処理システム１０の機能ブロックと同一の機能ブロックには同一の符号を付している。

図２のサーバ１２の描画制御部６０は、図１の内容決定部２０に対応する。図２のサーバ１２の画像描画部６２は、図１の画像生成部２２に対応する。図２のサーバ１２のフレームバッファ６４は、図１のバッファ２４に対応する。図２のサーバ１２のビデオエンコーダ６６は、図１の圧縮符号化部２８に対応する。図２のサーバ１２のビデオストリーム制御部６８は、図１のパケット化部３４に対応する。図２のサーバ１２の入出力Ｉ／Ｆ７０は、図１の通信部３６に対応する。

サーバ１２は、部分画像記憶部７２と制御部７４をさらに備える。部分画像記憶部７２は、ビデオエンコーダ６６から出力された、圧縮符号化後の部分画像のデータを記憶する。制御部７４は、ＣＰＵにより実現されてもよく、各機能ブロックにおける処理の開始と終了を制御し、また機能ブロック間での処理の同期を制御し、また機能ブロック間でのデータの送受信を制御する（フロー制御）。

図２のクライアント端末１４の入出力Ｉ／Ｆ８０は、図１の通信部４０およびデータ取得部４２に対応する。図２のクライアント端末１４のビデオデコーダ８２は、図１の復号伸長部４４に対応する。図２のクライアント端末１４のディスプレイコントローラ８４は、図１の表示制御部５４に対応する。図２のクライアント端末１４のディスプレイ８６は、図１の表示パネル５６に対応する。

クライアント端末１４は、部分画像記憶部８８、部分画像記憶部９０、部分画像記憶部９２、制御部９４をさらに備える。部分画像記憶部８８は、入出力Ｉ／Ｆ８０により取得された（言い換えればサーバ１２から送信された）部分画像のデータを記憶する。部分画像記憶部９０は、ビデオデコーダ８２による復号伸長後の部分画像のデータを記憶する。部分画像記憶部９２は、超解像処理部４８による超解像処理後の部分画像のデータを記憶する。制御部９４は、各機能ブロックにおける処理の開始と終了を制御し、また機能ブロック間での処理の同期を制御し、また機能ブロック間でのデータの送受信を制御する（フロー制御）。

図２には不図示だが、クライアント端末１４は、画像処理部をさらに備えてもよい。画像処理部は、部分画像記憶部９０または部分画像記憶部９２に記憶された部分画像に関する（１）複数のプレーンの合成処理、（２）色空間の変換処理、（３）解像度変換処理のうち少なくとも１つを実行してもよい。

図３は、図２の超解像処理部４８の詳細な構成を示すブロック図である。超解像処理部４８は、シーン解析部Ｃ５０、シーン情報統合部５２、解像度変換部１００、部分画像記憶部１０２、超解像画像生成部１０４、超解像処理制御部１１０を備える。

超解像処理制御部１１０は、超解像処理部４８内の他の機能ブロックに対して制御信号を送信し、同期制御やタイミング制御、フロー制御を実施する。解像度変換部１００は、ビデオデコーダ８２から出力された復号伸張化後の部分画像の解像度を変換する。具体的には、解像度変換部１００は、補間等の公知の手法により部分画像を高解像度化し、高解像度化した部分画像を部分画像記憶部１０２に格納する。超解像画像生成部１０４は、部分画像記憶部１０２に記憶された部分画像を読み出し、読み出した部分画像に対してフィルタ処理や、画像の復元・再構築処理を実行することにより、部分画像を高画質化する。

超解像画像生成部１０４は、モデル保持部１０６とＤＮＮ（Deep Neural Network）アクセラレータ１０８を含む。モデル保持部１０６は、超解像処理のためのモデルであり、図６に関連して後述する深層学習により生成されたモデルを記憶する。モデルは、例えば、超解像処理（例えば、画像フィルタ処理、画像の復元・再構築処理等）のアルゴリズムが実装された計算式、関数であってもよい。

ＤＮＮアクセラレータ１０８は、解像度変換部１００により高解像度化された部分画像を部分画像記憶部１０２から読み出し、読み出した部分画像を、モデル保持部１０６に記憶されたモデルに基づいて高画質化する。ＤＮＮアクセラレータ１０８は、高画質化した部分画像を部分画像記憶部９２に出力する。

変形例として、モデル保持部１０６は、図５に関連して後述する機械学習により生成されたモデルを記憶してもよい。また、解像度変換部１００は、第１シーン情報、第２シーン情報、シーン解析部Ｃ５０からの第３シーン情報の少なくとも１つを参照して解像度変換処理を実行してもよい。また、解像度変換部１００は、超解像画像生成部１０４の後段に設けられてもよく、すなわち、解像度変換部１００は、超解像画像生成部１０４により高画質化された部分画像を高解像度化してもよい。また、超解像処理部４８は、解像度変換部１００を含まない構成であってもよく、すなわち、解像度変換処理を実行しない構成であってもよい。また、超解像処理部４８は、解像度変換部１００を含まず、超解像画像生成部１０４が、部分画像の高画質化と解像度変換処理とを同時に実行する構成であってもよい。

図４は、シーン解析処理を低遅延化する方法を模式的に示す。図３等に関連して説明したように、超解像処理部４８は、シーン解析処理、シーン情報統合処理、画像解像度の引き上げ処理（アップスケーリング）、画像フィルタ処理、画像の復元・再構築処理等の内部処理を実行する。図４の（１）に示すように、超解像処理部４８は、これら個々の内部処理を部分画像単位で実行する。超解像処理部４８の内部処理における単位粒度は、整数倍すると部分画像単位となるように構成されることが望ましい。図４では、内部処理における単位粒度を点線の四角（以下「解析単位粒度」とも呼ぶ。）で示している。

また、図４の（２）に示すように、超解像処理部４８は、シーン解析（シーン解析部Ｃ５０）において、入力画像をピラミッドスケーリングを用いて複数通りの低解像度部分画像に変換する。そして、超解像処理部４８は、解像度が相対的に低い部分画像から解像度が相対的に高い部分画像の順にシーン解析処理を実行する。

超解像処理部４８（シーン解析部Ｃ５０）は、複数通りの解像度の部分画像それぞれに対するシーン解析結果を、解像度が異なる全ての部分画像の解析終了を待たず、順次、シーン情報統合部５２へ出力する。これにより、超解像画像生成部１０４は、超解像画像の生成処理をいち早く開始できるようになる。超解像画像の生成に必要十分なシーン解析結果が得られた場合、超解像画像生成部１０４は、そのことをシーン解析部Ｃ５０へ通知する。この通知を受けたシーン解析部Ｃ５０は、高解像度の部分画像に対するシーン解析処理を打ち切り、言い換えれば、処理途中であっても終了する。なお、超解像画像生成部１０４が超解像画像の生成処理を開始した後も、シーン解析部Ｃ５０は、より高解像度の部分画像に対するシーン解析処理を継続してもよく、その解析結果を超解像画像生成部１０４へ補充提供してもよい。

また、図４の（３）に示すように、超解像処理部４８（シーン解析部Ｃ５０）は、シーン解析において、入力画像の離散的な位置からオリジナル解像度でサンプリングした小領域（例えば解析単位粒度の領域）の画像を複数個抽出する。この抽出処理は以下の方針で実行されてもよい。すなわち、離散的な「解析単位粒度の領域」の割り当てにおいて、以下の（ａ）～（ｄ）の方針のうち少なくとも１つを採用してもよい。（ａ）後述の図１１に示すように、ＣＵ割当情報を使って、１ＣＵにつき、１つの解析単位粒度の領域を割り当てること。

（ｂ）後述の図１０に示すシーン解析に関するスコア算出ルールに基づいて、入力画像の複数領域それぞれのスコアを算出する場合、有限個数の「解析単位粒度の領域」の割り当てにおいて、高スコアである画像領域に対して「解析単位粒度の領域」を重点的に割り当てること。（ｃ）後述の図１３に示すシーン解析に関するスコア算出ルール（人肌推定処理）に基づいて、入力画像の複数領域それぞれのスコアを算出する場合、有限個数の「解析単位粒度の領域」の割り当てにおいて、高スコアである画像領域に対して「解析単位粒度の領域」を重点的に割り当てること。（ｂ）（ｃ）では、例えば、相対的に高スコアである画像領域に対して、相対的に低スコアの画像領域より優先して解析単位粒度の領域を割り当ててもよい。また、スコアが高い画像領域ほど優先して解析単位粒度の領域を割り当ててもよい。重点的に割り当てること、または優先的に割り当てることは、相対的に多くの個数の「解析単位粒度の領域」を割り当てることであってもよい。

（ｄ）Ｉフレームにおいては、部分画像あたりの「解析単位粒度の領域」の割り当て総数を引き上げること。割り当て総数を引き上げることは、割り当て総数をその初期値より大きくすることでもよく、Ｉフレーム以外のフレームに対する割り当て総数より大きくすることでもよい。例えば、超解像処理部４８（シーン解析部Ｃ５０）は、入力された部分画像がＩフレームの場合、入力された部分画像がＩフレーム以外である場合より、部分画像全体での解析単位粒度の領域の割当数を多くしてもよい。超解像処理部４８（シーン解析部Ｃ５０）は、抽出した複数個の小領域の画像のみでシーン解析を実行する。図４の（１）～（３）に示す構成によると、シーン解析の負荷が低減され、また、処理時間を抑制することもできる。

図５は、機械学習ベースの超解像処理を模式的に示す。ソース画像１２２は、超解像処理前の画像であり、解像度と画質が相対的に低い画像（実施例では部分画像）である。高画質画像１２８は、超解像処理後の画像であり、解像度と画質が相対的に低い画像（実施例では部分画像）である。モデル保持部１２０は、図３のモデル保持部１０６に対応する。モデル保持部１２０は、例えば、オフラインでの機械学習により作成されたモデルを記憶する。

オフラインでの機械学習とその学習により作成されるモデルは、以下の（ａ）～（ｅ）の特徴のうち少なくとも１つを有してもよい。（ａ）オフライン、かつ、事前に、学習を実行する。（ｂ）学習においては、教師データとして、「超解像処理結果が目指すべき画質の高精細画像」、「その高精細画像におけるシーン解析結果」を利用する。（ｃ）学習および推論（すなわち機械学習プロセッサや深層学習プロセッサを用いた高画質画像の生成）において、「シーン解析結果」も入力する。これにより、ソース画像のみを入力する場合に比べて、モデルの学習収束性を高め、モデルの精度を高め、モデルの肥大化や推論処理時間の増加を抑制し、より的確な超解像処理が可能となる。（ｄ）特に、第１シーン情報と第２シーン情報を、シーン解析に用いて、そのシーン解析結果である特徴量を超解像処理の学習および推論に用いる。これにより、非可逆圧縮符号化による映像クオリティの劣化や、解像度の引き下げ、色空間の縮小等が生じる前の画質を再現可能になる。（ｅ）シーン解析結果の代わりに、シーン情報そのものを、学習および推論に入力することで同様の効果を目指してもよい。

シーン解析部１２４は、図１のシーン解析部Ａ３０、シーン解析部Ｂ２６、シーン解析部Ｃ５０およびシーン情報統合部５２に対応する。シーン解析部１２４は、ソース画像１２２の特徴量を計算し、その特徴量をもとに、従来の超解像よりも大きなローカルサブブロックを複数のカテゴリ（例えば数千のカテゴリ）のいずれかに分類してもよい。例えば、シーン解析部１２４は、ソース画像１２２（それに映るコンテンツ）を、空、雲、顔、砂漠、または機械構造に分類してもよい。上記の特徴量は、画像圧縮に伴う好ましくない副作用（ノイズ等）を検出するための特徴量を含んでもよい。

機械学習プロセッサ１２６は、図３のＤＮＮアクセラレータ１０８に対応する。機械学習プロセッサ１２６は、シーン解析部１２４によるシーン解析の結果をもとに、画像の変換処理や再構成処理を実行する。機械学習プロセッサ１２６は、アンチエイリアス、シャープネス、ノイズ除去、コントラスト強化のための各種フィルタ処理と解像度変換を実行してもよい。機械学習プロセッサ１２６は、各種フィルタ、変換、再構成のためのパラメータを、分類されたサブブロック領域ごとに変更してもよい。

処理粒度は、オブジェクトを検出するフレームであってもよく、フレームより小さい部分画像であってもよい。また、人または機械学習により予め作成されたアルゴリズムとパラメータの組が用意されてよく、機械学習プロセッサ１２６は、シーン解析結果に適合するアルゴリズムとパラメータの組を選択してもよい。いくつかのアルゴリズムは、動きベクトル検出と３次元デジタルノイズリダクション（３ＤＮＲ）のための時間的アプローチを用いるものであってもよい。

図６は、深層学習ベースの超解像処理を模式的に示す。モデル保持部１３０は、図３のモデル保持部１０６に対応する。モデル保持部１３０は、例えば、オフラインでの深層学習により作成されたＤＮＮのモデルを記憶する。オフラインでの深層学習とその学習により作成されるＤＮＮのモデルは、図５に関連して説明した、オフラインでの機械学習とその学習により作成されるモデルの特徴（ａ）～（ｅ）のうち少なくとも１つを有してもよい。

シーン解析部１３２は、図１のシーン解析部Ａ３０、シーン解析部Ｂ２６、シーン解析部Ｃ５０およびシーン情報統合部５２に対応する。シーン解析部１３２は、ソース画像１２２の特徴量を計算し、その特徴量をもとに、ローカルサブブロックを複数のカテゴリ（例えば数千のカテゴリ）のいずれかに分類してもよい。例えば、シーン解析部１３２は、ソース画像１２２（それに映るコンテンツ）を、空、雲、顔、砂漠、または機械構造に分類してもよい。上記の特徴量は、画像圧縮に伴う好ましくない副作用（ノイズ等）を検出するための特徴量を含んでもよい。

深層学習推論プロセッサ１３４は、図３のＤＮＮアクセラレータ１０８に対応する。深層学習推論プロセッサ１３４は、シーン解析部１３２によるシーン解析の結果をもとに、画像の変換処理や再構成処理を実行する。深層学習推論プロセッサ１３４は、典型的には、シーンの分類と画像の変換・再構成のためのＤＮＮモデルを使用する。変形例として、深層学習推論プロセッサ１３４は、ＤＮＮモデルと、別のアルゴリズム（例えば人間ベースのシーン解析アルゴリズムや超解像アルゴリズム）とを組み合わせて使用してもよい。深層学習推論プロセッサ１３４は、アンチエイリアス、シャープネス、ノイズ除去、コントラスト強化のための各種フィルタ処理を実行してもよい。深層学習推論プロセッサ１３４は、各種フィルタ、変換、再構成のためのパラメータを、分類されたサブブロック領域ごとに変更してもよい。

学習済のＤＮＮモデルは、浮動小数点ベースで学習されている場合でも、整数ベースの推論アクセラレータ用に最適化される。処理粒度は、オブジェクトを検出するフレームであってもよく、フレームより小さい部分画像であってもよい。いくつかのアルゴリズムは、動きベクトル検出と３ＤＮＲのための時間的アプローチを用いるものであってもよい。

超解像処理の実施方法についてさらに説明する。
超解像処理部４８の超解像画像生成部１０４は、部分画像に対する超解像処理を、その部分画像に対応するシーン情報をもとに実行する。超解像処理部４８の超解像画像生成部１０４は、画像領域（すなわち部分画像に映る内容）に応じて、画像の高精細化を行う処理を動的に切り替えるためにシーン情報を利用する。以下、超解像画像生成部１０４による処理の事例を説明する。

（事例１）
処理対象の画像領域が、絵としてフラットで変化が少ない内容（例えば、雲一つない青空の絵や、舗装が痛んでいない綺麗な道路の路面を遠くから俯瞰した絵）であるとき、超解像画像生成部１０４は、シャープネス系の画像変換処理の実行量を必要最低限とする。言い換えれば、超解像画像生成部１０４は、シャープネス系の画像変換処理の実行量を、画像領域が絵としてフラットで変化が少ない内容でないときよりも少なくする。画像領域が絵としてフラットで変化が少ない内容である場合、シャープネス系処理の効果が大きい。そのため、人工的なフィルタ処理結果が目立ちやすく、言い換えれば、人工的なフィルタ処理による逆効果が目立ちやすいからである。

（事例２）
処理対象の画像領域が、絵として高密度で断続的な変化をもつ内容（例えば、森を遠くから俯瞰した絵）であるとき、超解像画像生成部１０４は、シャープネス系の画像変換処理を積極的に行う。言い換えれば、超解像画像生成部１０４は、シャープネス系の画像変換処理の実行量を、画像領域が絵として高密度で断続的な変化をもつ内容でないときよりも増加させる。画像領域が絵として高密度で断続的な変化をもつ内容である場合、シャープネス系処理の効果が表れにくいうえ、人工的なフィルタ処理による逆効果が目立ちにくいからである。

（事例３）
処理対象の画像領域が、絵としてはっきりとした線や点などをもつ内容（例えば、輪郭がはっきりしている複雑な形状の人工的な物体や文字）であるとき、超解像画像生成部１０４は、シャープネス系の画像変換処理を抑制する。超解像画像生成部１０４は、シャープネス系の画像変換処理をスキップしてもよい。画像領域が絵としてはっきりとした線や点などをもつ内容である場合、シャープネス系処理の効果が弱く、人工的なフィルタ処理による逆効果が非常に目立ちやすいからである。このような画像領域においては、超解像画像生成部１０４は、線や点の種類に応じた専用の輪郭補正処理を行うことが好ましい。

（事例４）
処理対象の画像領域が、大きな移動量で動く物体（例えば車両等）をもつとき、人の動体視力を鑑みると、物体表面領域の高精細化処理を行うメリットが低い場合がある。しかし、物体の端に画像圧縮起因の輪郭破綻系ノイズが含まれていると、人は認識しやすい。そのため、超解像画像生成部１０４は、処理対象の画像領域に輪郭破綻系ノイズを検出した場合、輪郭破綻系ノイズに特化した画像変換処理を実行する。

（事例５）
人は、画像に映る人物の、肌の色合いや顔の表情を認識する能力が高い。そのため、超解像画像生成部１０４は、処理対象の画像領域が人物を含むことを検出した場合、人物に特化した画像変換処理（フィルタ処理）を実行する。

上記の複数の事例に記載したような、判定ルールと、それに対して行うフィルタ処理や変換処理の組を多数定義してもよい。これらの組は、テーブル、データベース、モデルとして実装されてもよい。そして、これらの組に対して様々な入力条件を与え、フィルタ処理や変換処理の結果を学習し、また最適化してもよい。その結果、シーン情報と入力画像内容に基づいて、超解像画像の生成内容が切り替わる処理系を実現できる。

なお、超解像画像生成部１０４は、シーン情報（第１～第３シーン情報）のみに基づいて、実行する画像変換内容（フィルタ処理や変換処理の内容）を決定してもよい。また、超解像画像生成部１０４は、シーン情報と入力画像（部分画像）に基づいて、実行する画像変換内容を決定してもよい。いずれの方法を採るかに応じて、テーブル、データベース、またはモデルを変更してもよい。

図３に戻り、超解像処理部４８による超解像処理をさらに説明する。シーン情報統合部５２は、シーン解析単位粒度（例えば図４に示した解析単位粒度）毎のシーン情報を、超解像画像生成部１０４に出力する。シーン情報統合部５２は、過去フレームまたは過去部分画像におけるシーン情報を蓄積し、最新のフレームまたは最新の部分画像におけるシーン情報を構築する際に参照してもよい。超解像画像生成部１０４は、シーン解析単位粒度と同じ粒度で処理を進めてもよく、それ以外の粒度で処理を進めてもよい。

超解像画像生成部１０４は、シーン情報に基づいて、モデル保持部１０６に記憶された複数のモデルの中で、利用するモデルを切り替えてもよい。また、超解像画像生成部１０４は、モデルの切替時間を隠蔽するために、（１）複数のモデルを予めモデル保持部１０６にロードしてもよく、（２）複数のＤＮＮアクセラレータを起動してもよく、（３）予めロードしたモデルと、予め起動したＤＮＮアクセラレータの少なくとも一方を動的に切り替えてもよい。超解像画像生成部１０４が利用するモデルは、予め、様々な条件のシーン情報と入力画像に対応できるように学習および構築されてもよい。これにより、シーン情報に応じたモデル切替を抑制し、またはモデル切替時間を抑制してもよい。超解像処理制御部１１０は、シーン情報（シーン解析結果）と、対となる画像（部分画像）とを紐づけるために、識別子などを使ってもよい。

図７は、部分画像単位のパイプライン処理の概念図である。上述の通り、サーバ１２は、動画像のフレーム１４０を所定または可変のレートで生成する。図示の例では、フレーム１４０は、左右に二等分した領域に左目用、右目用の画像をそれぞれ表した構成を有するが、サーバで生成する画像の構成をこれに限る趣旨ではない。

上述の通り、サーバ１２は、フレーム１４０を部分画像ごとに圧縮符号化する。図７では画像平面を水平方向に５分割し、部分画像１４２ａ、１４２ｂ、１４２ｃ、１４２ｄ、１４２ｅとしている。図７では、部分画像１４２ａ、１４２ｂ、１４２ｃ、１４２ｄ、１４２ｅはこの順で次々に圧縮符号化され、矢印に示すようにクライアント端末１４へ順次伝送され表示される。すなわち最上段の部分画像１４２ａに対し、圧縮符号化、送信、復号伸張、表示パネル５６への出力といった処理が施されている間に、その下の部分画像１４２ｂ、さらに下の部分画像１４２ｃ、というように順次部分画像が伝送され表示される。これにより、画像の描画から表示までに必要な各種処理を並列に実施でき、転送時間が介在しても最低限の遅延で表示を進捗させることができる。

図８も、部分画像単位のパイプライン処理の概念図である。同図は、本出願人による過去の出願（特願２０１９－２１３５３６）の図６を引用したものである。同図は、サーバ１２における画像生成から、クライアント端末１４における画像表示までの処理タイミングを示している。図８には不図示だが、本実施例のクライアント端末１４では、復号伸長処理と表示処理との間に、超解像処理部の処理時間が追加される。一方、復号伸長部４４の符号化方法取得部４６の処理時間は、この処理を復号伸長処理のバックグラウンド処理として実行することで隠蔽することができる。サーバ１２においても、シーン解析部Ａ３０、シーン解析部Ｂ２６、シーン情報取得部３２の処理時間は、これらの処理を圧縮符号化部２８による圧縮符号化処理のバックグラウンドで実行することで隠蔽することができる。また、データ取得部４２からシーン情報統合部５２へシーン情報を出力する処理も、復号伸長部４４による復号伸長処理のバックグラウンド処理として実行できる。

図９は、ゲームアプリケーションが保持するシーン情報の例を示す。ゲームアプリケーション（言い換えればゲームアプリケーションを実行する内容決定部２０および画像生成部２２）は、フレームを描画する過程において、内部データとして、（１）各オブジェクトの色情報、（２）各オブジェクトの動きベクトル情報、（３）オブジェクト配置に関する奥行き情報、（４）各オブジェクトの反射てかり強度情報を生成する。ゲームアプリケーションを実行する内容決定部２０および画像生成部２２は、これらの内部データをバッファ２４（レンダリングバッファ）に格納する。シーン解析部Ａ３０およびシーン解析部Ｂ２６は、バッファ２４（レンダリングバッファ）に格納された上記（１）～（４）のデータをシーン情報として取得してもよい。本明細書における「てかり」は、「ハイライト」とも呼ばれる。なお、図９に示すようなアプリケーションが持つ描画内部データは、アプリケーションが最終描画結果を生成する前から存在するデータであり、アプリケーションが最終描画結果を生成する際に参照されるデータである。

また、実施例の情報処理システム１０では、超解像処理の前に、上記（１）～（４）のデータを参照してシーン解析（例えばシーンセグメンテーション等）を予め実行する。これにより、処理遅延の削減や、シーン解析精度の向上を実現する。なお、図９に示す例では、例えば、手前にある動きが激しい物体の位置や、光が当たっている物体の位置、暗所で画像がつぶれている位置（物体の識別が困難な位置）等のシーン情報も得られる。

図１０は、シーン解析の例を示す。サーバ１２のシーン解析部Ａ３０、シーン解析部Ｂ２６、クライアント端末１４のシーン解析部Ｃ５０のうち少なくとも１つは、特願２０１９－１７９４３９および特願２０１９－１７９４４０に記載されたパラメータ群とスコア算出ルールを用いて、シーン解析を実行してもよい。図１０は、特願２０１９－１７９４３９の図２７～図３１を示している。

シーン解析（例えばゲーム描画内容の判定）に用いるパラメータは、以下の項目の少なくとも１つを含んでもよい。（１）オプティカル・フローの量（例えば、どの方向に画素が動いているか、および画素領域が動く速さ）。（２）エンコードＭｏｔｉｏｎ Ｅｓｔｉｍａｔｉｏｎ（ＭＥ）の量（例えば、どの方向に矩形領域が動いているか、および矩形領域が動く速さ）。（３）エンコードＣＵ割当の粒度（例えば、ＣＵの大きさ）。（４）シーン切り替えか否か（例えば、エンコードＩフレームを挿入する場所か否か）。

（５）画面を占める画像テクスチャ種類（エッジ領域、フラット領域、またはＨｉｇｈ Ｄｅｎｓｉｔｙ／Ｄｅｔａｉｌ／Ｃｒｏｗｄ領域等）。このテクスチャ種類は、３Ｄ描画に用いているテクスチャ種類ではなく、描画結果の２次元画像に分布するテクスチャ種類である。（６）ハリス・コーナー特徴点やエッジの量（例えば、特徴点やエッジがある座標、およびエッジ強度等）。（７）深度データ（例えば、各画素の奥行き情報、または３ＤゲームにおけるＺ値等。（８）オブジェクト量（例えば、椅子や車といった物体の量や、物体が画面に占める大きさ）。（９）３Ｄ描画にて用いているＭｉｐｍａｐテクスチャの各レベルの使用量。

（１０）３Ｄ描画にて用いているＬＯＤ（Level of Detail）。（１１）テッセレーションの各レベルの使用量。（１２）文字や記号の量。（１３）描画シーン種類。この種類は、例えば、メニュー、設定、ローディング画面、主観視線描画、俯瞰視線描画、２次元ドット絵ゲーム、３次元描画ゲーム、ファースト・パーソン・シューティングゲーム、レースゲーム、スポーツゲーム、アクションゲーム、シミュレーションゲーム、アドベンチャー・ノベルゲームのいずれかであってもよい。

また、スコア算出ルールは、特願２０１９－１７９４３９および特願２０１９－１７９４４０に記載されたように、例えば、（１）画像上の像の大きさに基づくスコア算出ルール、（２）オブジェクトの細かさに基づくスコア算出ルール、（３）コントラスト、ダイナミックレンジに基づくスコア算出ルール、（４）像の動きに基づくスコア算出ルール、（５）テクスチャの種類に基づくスコア算出ルールのいずれかであってもよい。また、スコア算出ルールは、（６）解像度重視のスコア算出ルール、（７）フレームレート重視のスコア算出ルール、（８）量子化パラメータ（ＱＰ）値重視のスコア算出ルールであってもよい。サーバ１２のシーン解析部Ａ３０、シーン解析部Ｂ２６、クライアント端末１４のシーン解析部Ｃ５０のうち少なくとも１つは、超解像処理部４８の内部処理における単位領域毎または部分画像毎にスコアを算出してもよい。

さらにまた、サーバ１２のシーン解析部Ａ３０、シーン解析部Ｂ２６、クライアント端末１４のシーン解析部Ｃ５０のうち少なくとも１つは、特願２０１９－０３７９０７と同様のパラメータを用いてシーン解析を実行してもよい。このパラメータは、入力ビデオ画像（例えば部分画像）から得られる特徴量と、入力ビデオ画像の圧縮符号化時（例えばＡＶＣ／ＨＥＶＣエンコーダ）に得られる特徴量の少なくとも一方を含んでもよい。

入力ビデオ画像から得られる特徴量は、以下の（１）～（５）の少なくとも１つを含んでもよい。（１）画像のテクスチャ種類（エッジ領域、フラット領域、またはＨｉｇｈ Ｄｅｎｓｉｔｙ／Ｄｅｔａｉｌ／Ｃｒｏｗｄ領域等）。（２）ハリス・コーナー特徴点やエッジの量（例えば、特徴点やエッジがある座標、およびエッジ強度等）。（３）オプティカル・フロー（例えば、どの方向に矩形領域が動いているか、および矩形領域が動く速さ）。（４）深度データ（例えば、各画素の奥行き情報）。（５）画像認識により物体を検出した結果（例えば、椅子や車がある座標領域の情報）。

入力ビデオ画像の圧縮符号化時に得られる特徴量は、以下の（１）～（６）の少なくとも１つを含んでもよい。（１）Ｍｏｔｉｏｎ Ｅｓｔｉｍａｔｉｏｎ（ＭＥ）情報（例えば、どの方向に矩形領域が動いているか、および矩形領域が動く速さ）。（２）ＣＵ割当情報（例えば、ＣＵの大きさ）。（３）Ｒｅｓｉｏｎ ｏｆ Ｉｎｔｅｒｅｓｔ（ＲＯＩ）領域の情報。ＲＯＩ領域は、注目領域または関心領域とも呼ばれ、例えば、高画質化のため高ビットレートを割り当てた画像領域である。（４）使用した量子化パラメータ（ＱＰ）の情報。（５）シーン切替であるか否か。（６）キーフレーム（例えば、Ｉフレーム）であるか否か。

図１１は、ＣＵ割当情報の例を示す。同図のＣＵ割当情報は、色の変化が大きい領域ほど小さい符号化単位ブロックが割り当てられたことを示している。例えば、シーン解析部Ａ３０は、ＣＵ割当情報をもとに色の変化が大きい領域を検出してもよく、シーン情報取得部３２は、色の変化が大きい領域を示す第１シーン情報を生成してもよい。クライアント端末１４の超解像処理部４８は、部分画像の第１シーン情報が示す当該部分画像の色の変化が大きい領域に基づいて超解像処理を実行してもよい。

図１２は、シーン解析手法の例を示す。同図は、シーンセグメンテーションによって画像に映るオブジェクトの種類を抽出することを示している。例えば、サーバ１２のシーン解析部Ａ３０、シーン解析部Ｂ２６、クライアント端末１４のシーン解析部Ｃ５０のうち少なくとも１つは、公知のテンプレートマッチング等の手法により、図１２の画像１４４を、空、樹木、車、建物、道路、車線等の領域に分類してもよい。

図１３も、シーン解析手法の例を示す。サーバ１２のシーン解析部Ａ３０、シーン解析部Ｂ２６、クライアント端末１４のシーン解析部Ｃ５０のうち少なくとも１つは、公知の人肌領域推定処理を実行して画像の特徴量を抽出してもよい。図１３の網掛けで示す領域は、人肌として推定された領域を示している。人肌領域推定処理は、入力画像内の複数領域それぞれのスコアを算出してもよい。人肌領域推定処理におけるスコア算出ルールは、人肌として推定された領域に対して、人肌として推定されなかった領域より高いスコアを割り当てるものであってもよい。

図１４も、シーン解析手法の例を示す。図１４は、ビデオ圧縮ノイズを検出する例を示している。サーバ１２のシーン解析部Ａ３０、シーン解析部Ｂ２６、クライアント端末１４のシーン解析部Ｃ５０のうち少なくとも１つは、画像からビデオ圧縮ノイズを検出し、ビデオ圧縮ノイズを画像の特徴量として抽出してもよい。同図の出典は、“Local estimation of video compression artifacts” 2011 IEEE International Conference on Consumer Electronics (ICCE)、である。

超解像画像生成部１０４は、図１４に示したようなアーティファクト（ａｒｔｉｆａｃｔ）強度を参照してもよい。アーティファクト強度は、圧縮アーティファクトの強度と言え、非可逆圧縮の適用によって引き起こされた画像劣化（画像の歪み等）の度合いを示すデータである。超解像画像生成部１０４は、超解像処理において、ノイズによる画像劣化が激しい領域については、機械学習結果に基づき、平滑フィルタの強度をあげてもよい。例えば、超解像画像生成部１０４は、アーティファクト強度が予め定められた閾値未満の領域に対して第１の強度の平滑化処理を実行し、アーティファクト強度が上記閾値未満の領域に対して、第１の強度より強い第２の強度の平滑化処理を実行してもよい。また、超解像画像生成部１０４は、アーティファクト強度が強い領域ほど、強い平滑化処理を実行してもよい。

超解像処理において判断材料とするシーン情報の例を説明する。サーバ１２のシーン解析部Ａ３０、シーン解析部Ｂ２６、クライアント端末１４の符号化方法取得部４６、シーン解析部Ｃ５０のうち少なくとも１つは、（１）ユーザ・インタラクション重視のシーンであるか否かを示すシーン情報、（２）シーンの内容または画像の種類を示すシーン情報、（３）現在の描画手法を示すシーン情報の少なくとも１つを取得してもよい。クライアント端末１４の超解像処理部４８は、これら（１）～（３）のシーン情報の少なくとも１つを用いて超解像処理を実行してもよい。

（１）のシーン情報は、以下の情報の少なくとも１つを含んでもよい。
（１－１）描画内容が、ユーザー操作の入力を必要としないムービーシーン（プリ・レンダリング）やローディング待ち、またはセットアップ待ちであることを示す情報。
（１－２）描画内容が、ユーザー操作の入力を必要とするゲームプレイシーン（リアルタイム・レンダリング）であることを示す情報。
（１－３）描画内容が、ユーザー操作の入力を必要とするゲームプレイシーンであったとき、ユーザー入力をサンプリングしている頻度を示す情報。
（１－４）描画内容が、ユーザー操作の入力を必要とするゲームプレイシーンであったとき、ゲーム種別（カテゴリ等）を示す情報。例えば、ドライブゲーム、シューティングゲーム、アクション格闘ゲーム、ストラテジーゲーム、シミュレーションゲーム等。

（２）のシーン情報は、以下の情報の少なくとも１つを含んでもよい。
（２－１）ＧＵＩシーン（例えばメニューシーン）であること、ゲームシーンであること、または他のビデオストリーム・アプリケーションであることを示す情報。
（２－２）カメラ撮影自然画像であること、ＣＧ（Computer Graphics）画像であること、またはアニメ系画像であることを示す情報。

（３）のシーン情報は、描画時のオリジナル設定、および、圧縮符号化・転送における設定に関するシーン情報とも言える。
（３）のシーン情報は、以下の情報の少なくとも１つを含んでもよい。
（３－１）描画解像度、フレームレート、および描画ビットカラー深度。
（３－２）レンダリング手法に関する情報。例えば、レイトレーシング利用しているか。レイトレーシング手法を適用している画像領域や物体配置。フォグ処理を使用有無と使用領域。バンプマッピングの使用有無と使用領域。反射処理の使用有無と使用領域。Ｍｏｔｉｏｎ Ｂｌｕｒ効果（物体をぼやかす処理）の使用有無と使用領域。
（３－３）レンダリングにおけるテクスチャフィルタリング処理内容、またはテクスチャ圧縮手法。

（３－４）非可逆フレームバッファ圧縮を用いている場合の圧縮手法。
（３－５）描画アンチエイリアシング手法。例えば、フィルタ構成、フィルタタップ数、フィルタ係数、画像における輪郭や微細模様に特化した処理の有無。
（３－６）解像度変換を行う場合の解像度変換手法。例えば、フィルタ構成、フィルタタップ数、フィルタ係数、画像における輪郭や微細模様に特化した処理の有無。
（３－７）描画ダイナミックレンジ、ＨＤＲ（High-Dynamic-range Rendering）プロファイル、またはトーンマッピング手法。例えば、ＧＰＵ描画において、浮動小数点演算結果からフレームバッファ出力へ落とし込むときの丸め込みなどを含むマッピング手法、または計算手法。また例えば、元々描画処理過程において持っていたダイナミックレンジの情報と、フレームバッファ出力におけるダイナミックレンジの情報。

（３－８）描画のディザリング手法の情報。
（３－９）利用している圧縮符号化の手法の情報。例えば、マクロブロック割当方法。スライス割当方法。係数。デノイズフィルタ種別係数。インター圧縮（フレーム間圧縮）を用いているかの情報。圧縮規格（例えばＡＶＣ、ＨＥＶＣ、ＶＰ９、ＡＶ１、ＤＳＣ等）の情報。可逆または不可逆かの情報。ビット深度。量子化パラメータ（ＱＰ）。レート制御手法。ターゲットビットレート。ＩＤＲ方式とＧＤＲ方式のいずれであるかを示す情報。

一部既述したように、超解像処理部４８は、ゲームアプリケーションから取得されたシーン情報であって、超解像処理に至るまでのサーバ１２またはクライアント端末１４における前段処理で取得されたシーン情報に基づいて、超解像処理の簡易化または未実行を選択してもよい。超解像処理部４８は、シーン情報に基づいて、超解像処理による高画質化と、低遅延性のいずれを重視するかを判定してもよい。

＜第２実施例＞
以下、第２実施例について、第１実施例と相違する構成を中心に説明し、共通する構成の説明は適宜省略する。第２実施例の構成要素のうち第１実施例の構成要素と同一または対応する構成要素には同じ符号を付している。第２実施例の構成は、第１実施例および変形例の構成と任意の組合せが可能であることはもちろんである。

第２実施例は、画像の表示を制御する情報処理装置（第２実施例ではゲームコンソール）が、画像の生成も行う点で第１実施例と異なる。第２実施例のゲームコンソールは、第１実施例のクライアント端末１４に対応するが、第１実施例のクライアント端末１４とは異なり、画像の生成、画像の超解像処理、超解像画像の表示制御を単体で実行する。なお、第２実施例以降の技術思想は、ゲームコンソールに制限されず、画像を処理する種々の情報処理装置に適用できる。

図１５は、第２実施例のゲームコンソール２００の構成を示すブロック図である。ゲームコンソール２００は、内容決定部２０、画像生成部２２、バッファ２４、シーン解析部Ｂ２６、シーン情報取得部３２、超解像処理部４８、表示制御部５４、表示パネル５６を備える。超解像処理部４８は、シーン解析部Ｃ５０とシーン情報統合部５２を含む。ゲームコンソール２００は、第１実施例のサーバ１２とクライアント端末１４が備えた機能のうち、圧縮符号化および復号伸長に関連する機能は備えない。図１５に示す各機能ブロックの詳細は説明済みであるため、再度の説明を省略する。

図１６と図１７も、第２実施例のゲームコンソール２００の構成を示すブロック図である。図１６は、前段の処理に関する機能ブロックを示し、図１７は、図１６に続く処理に関する機能ブロックを示している。

図１６に示すように、第２実施例のゲームコンソール２００は、ＣＰＵ２０１、ＧＰＵ２０２、ＤＲＡＭ（Dynamic Random Access Memory）２０４、超解像処理部４８を備える。超解像処理部４８は、シーン解析部Ｃ５０、ＳＲＡＭ（Static Random Access Memory）２０６、アダプティブ解像度変換部２０８、学習パラメータテーブル２１０、超解像画像生成部１０４、モデル保持部１０６を含む。本明細書のブロック図に示すＤＲＡＭ、ＳＲＡＭの配置は論理的なものであり、物理的なＤＲＡＭ、ＳＲＡＭの個数に制限はない。例えば、ブロック図の複数のＤＲＡＭ、ＳＲＡＭは、物理的には同一のＤＲＡＭ、ＳＲＡＭにより実現されてもよい。

ＤＲＡＭ２０４は、ゲームアプリケーションの画像に関する各種データを記憶する。ＤＲＡＭ２０４は、第１実施例のバッファ２４および部分画像記憶部９０に対応する。具体的には、ＤＲＡＭ２０４は、フレーム２２０、メタ情報２２２、他画面データ２２４、過去フレーム２２６を記憶する。フレーム２２０は、実行中のゲームアプリケーションにより生成された画像データであり、言い換えれば、ゲームコンテンツの映像データである。ＧＰＵ２０２は、第１実施例の画像生成部２２および画像描画部６２に対応する。ＧＰＵ２０２は、フレーム２２０を生成し、フレーム２２０をＤＲＡＭ２０４に格納する。

メタ情報２２２は、第１実施例のシーン解析部Ｂ２６による解析結果としてのシーン情報（例えばフレーム２２０の描画内容を示す情報）を含み、また、第１実施例の内容決定部２０から得られるシーン情報（例えば３Ｄオブジェクトの配置状態や、利用テクスチャ特性、シーンセグメンテーション情報）を含む。メタ情報２２２は、ＣＰＵ２０１（内容決定部２０）とＧＰＵ２０２の一方または両方で生成されてもよい。サーバがない場合、メタ情報２２２は、ゲームコンソール２００のＣＰＵ２０１（内容決定部２０）やシーン解析部Ｂ２６から得られた、第１シーン情報を含んでもよい。

他画面データ２２４は、ゲームコンソール２００におけるゲームアプリケーション以外の画像データである。他画面データ２２４は、（ａ）ゲームコンソール２００のシーン解析部Ｂ２６から得られた第１シーン情報、（ｂ）ゲームコンソール２００の画像生成部２２が生成した、図９の描画内部データや第１シーン情報、および、（ｃ）後述のＵＩプレーン２３６等を含んでもよい。他画面データ２２４は、これら（ａ）～（ｃ）の総称である。

過去フレーム２２６は、実行中のゲームアプリケーションの過去表示された画像のデータである。過去フレーム２２６は、断続的に生成され続けるフレーム２２０における過去に生成された超解像処理前のフレーム２２０であってもよく、もしくは、超解像処理後にディスプレイインタフェース２４８から出力したデータを図示しないデータパスでＤＲＡＭに書き戻したフレームであってもよい。

ＤＲＡＭ２０４のメタ情報２２２、他画面データ２２４、過去フレーム２２６のそれぞれは、スライス単位に超解像処理部４８へ入力される。図示しないが、他画面データ２２４と過去フレーム２２６は、シーン解析部Ｃ５０やアダプティブ解像度変換部２０８に入力されてもよい。シーン解析部Ｃ５０やアダプティブ解像度変換部２０８に入力された他画面データ２２４と過去フレーム２２６に基づいて、追加データとしての画像特徴情報２２８、Ｙスライス２３０、ＵＶスライス２３２、メタ情報２２２がＳＲＡＭ２０６に生成されてもよい。ＳＲＡＭ２０６に生成されたこれらの追加データは、必要に応じて超解像画像生成部１０４に追加入力されてもよい。

シーン解析部Ｃ５０は、オプショナルな機能ブロックであり、ＤＲＡＭ２０４に記憶されたメタ情報２２２を参照し、公知技術を用いて超解像処理の前段処理としてのシーン解析処理を実行する。シーン解析部Ｃ５０は、第１実施例のシーン解析部Ｂ２６と同等のシーン解析処理を実行してもよい。シーン解析部Ｃ５０は、シーン解析結果（シーン情報）をアダプティブ解像度変換部２０８に渡すとともに、シーン解析結果（シーン情報）を画像特徴情報２２８としてＳＲＡＭ２０６に格納する。なお、第２実施例のシーン情報は、圧縮符号化および復号伸長に関連する内容が除外される以外、第１実施例のシーン情報と同様の内容を含んでもよい。

ＳＲＡＭ２０６は、第１実施例の部分画像記憶部１０２に対応する。ＳＲＡＭ２０６は、画像特徴情報２２８を記憶し、Ｙスライス２３０、ＵＶスライス２３２、メタ情報２２２をさらに記憶する。メタ情報２２２は、ＤＲＡＭ２０４から転送される。メタ情報２２２には、シーン解析部Ｃ５０から得られた第３シーン情報が追加されてもよい。Ｙスライス２３０とＵＶスライス２３２は、フレーム２２０の部分画像であるスライス（実施例ではＹＵＶ形式）に関するデータである。Ｙスライス２３０は、スライスのＹ成分のデータである。ＵＶスライス２３２は、スライスのＵＶ成分のデータである。Ｙ成分は、輝度成分または輝度信号と言える。ＵＶ成分は、色差成分と言え、輝度信号と青色成分の差（Ｕ）と、輝度信号と赤色成分の差（Ｖ）とを含む。ＵＶ成分は、色相成分および彩度成分と言うこともできる。

学習パラメータテーブル２１０は、スライスの内容を複数のカテゴリの中のいずれかに分類するために参照されるパラメータであり、機械学習により作成されたパラメータを保持するテーブルである。

アダプティブ解像度変換部２０８は、第１実施例の解像度変換部１００に対応し、ＤＲＡＭ２０４に記憶されたフレーム２２０のデータをスライス単位で読み出し、読み出したスライスに対するアダプティブ解像度変換を実行する。アダプティブ解像度変換は、第１実施例の解像度変換部１００と同様に、スライスを高解像度化する処理を含む。

また、アダプティブ解像度変換は、シーン解析部Ｃ５０から入力されたシーン情報と、学習パラメータテーブル２１０に記憶されたパラメータとに基づいて、ＤＲＡＭ２０４から読み出したスライスのサブブロック（例えば４×４画素や８×８画素のプリミティブ領域）を、複数のカテゴリの中のいずれかに分類する処理を含む。複数のカテゴリは、数十から数百のカテゴリを含んでもよい。例えば、複数のカテゴリは、エッジ領域（例えば画素値の変化量が大きい領域）、詳細領域（例えば画素値が細かく変化する領域）、フラット領域（例えば画素値の変化量が小さい領域）を含んでもよい。

アダプティブ解像度変換部２０８は、スライスのサブブロックのカテゴリに応じて、当該スライスのサブブロックに対してアンチエイリアス、シャープネス、ノイズ除去、コントラスト強調の少なくとも１つに関連するフィルタを適用してもよい。例えば、エッジ領域に分類したサブブロックに対して、シャープネスを弱めるフィルタを適用してもよい。また、詳細領域に分類したサブブロックに対して、シャープネスを強めるフィルタを適用してもよい。また、フラット領域に分類したサブブロックに対して、シャープネスを最小化するフィルタを適用してもよい。

アダプティブ解像度変換部２０８は、アダプティブ解像度変換後のスライスのＹ成分をＳＲＡＭ２０６に格納する（Ｙスライス２３０）。また、アダプティブ解像度変換部２０８は、アダプティブ解像度変換後のスライスのＵＶ成分をＳＲＡＭ２０６に格納する（ＵＶスライス２３２）。第２実施例では、ＧＰＵ２０２がＹＵＶ形式のフレーム２２０を生成するが、変形例として、ＧＰＵ２０２はＲＧＢ形式のフレーム２２０を生成してもよい。この場合、アダプティブ解像度変換部２０８は、ＲＧＢ形式のフレーム２２０をＹＵＶ形式に変換後、変換後のフレームからスライスデータを読み出してもよい。

モデル保持部１０６は、スライスのＹ成分に対する超解像処理のためのモデルを記憶する。典型的には、モデル保持部１０６は、シーンの分類と画像の変換・再構成のためのＤＮＮモデルを記憶する。変形例として、モデル保持部１０６は、ＤＮＮモデルと、別のアルゴリズム（例えば人間ベースのシーン解析アルゴリズムや超解像アルゴリズム）とを組み合わせて記憶してもよい。

超解像画像生成部１０４は、ＳＲＡＭ２０６からＹスライス２３０を読み出す。超解像画像生成部１０４は、ＳＲＡＭ２０６に記憶された画像特徴情報２２８およびメタ情報２２２と、モデル保持部１０６に記憶されたモデルとに基づいて、Ｙスライス２３０に対する超解像処理（高画質化等）を実行する。超解像画像生成部１０４は、ＤＮＮアクセラレータ１０８と制御ＭＣＵ（Micro Control Unit）２１２を含む。制御ＭＣＵ２１２は、第１実施例の超解像処理制御部１１０に対応する。制御ＭＣＵ２１２は、例えば、短冊状画像パイプライン処理、超解像アルゴリズムの小粒度ＤＭＡ（Direct Memory Access）およびアルゴリズムの切替処理を実行してもよい。

また、超解像画像生成部１０４は、Ｙスライス２３０に対する超解像処理において、ＤＲＡＭ２０４に格納された他画面データ２２４と過去フレーム２２６を参照してもよい。例えば、超解像画像生成部１０４は、他画面データ２２４と過去フレーム２２６を参照して、処理対象のＹスライス２３０に描かれた物体の動きや、処理対象のＹスライス２３０に含まれるノイズを検出してもよい。超解像画像生成部１０４は、Ｙスライス２３０に描かれた物体の動きに基づいて、超解像処理のアルゴリズム（フィルタ等）を切り替えてもよい。また、超解像画像生成部１０４は、超解像処理において、Ｙスライス２３０に含まれるノイズを打ち消してもよい。

超解像画像生成部１０４は、ゲームアプリケーションやＯＳが描画するメニューＵＩや字幕等が、どのような種別の画像か、どのような形状であるか、どのような画像座標位置に描画されているかといった情報を、超解像画像生成部１０４に入力されるいずれかのデータ（２２８，２３０，２３２，２２４，２２６等）から取得してもよい。超解像画像生成部１０４は、取得した上記情報に基づいて、Ｙスライス２３０に対する超解像処理を切り替えてもよい。例えば、超解像画像生成部１０４は、メニューＵＩや字幕の画像領域に対する超解像処理として、ＤＮＮモデルの学習結果に基づいて、エッジが破壊されにくい超解像処理を選択してもよい。

超解像画像生成部１０４は、Ｙスライス２３０に対する超解像処理の結果（後述のＳＲ－Ｙスライス２３４）を後述のＳＲＡＭ２４０に格納する。一方、超解像画像生成部１０４は、ＳＲＡＭ２０６に記憶されたＵＶスライス２３２に対する超解像処理をスキップする。ＳＲＡＭ２０６に記憶されたＵＶスライス２３２は、超解像処理が施されることなく、後述のＳＲＡＭ２４０に転送される。

図１７に示すように、第２実施例のゲームコンソール２００は、ＳＲＡＭ２４０、ＤＲＡＭ２４２、解像度変換部２４４、オーバレイ部２４６、ディスプレイインタフェース２４８をさらに備える。

ＳＲＡＭ２４０は、第１実施例の部分画像記憶部９２に対応する。ＳＲＡＭ２４０は、超解像処理部４８により生成されたＳＲ－Ｙスライス２３４と、超解像処理の対象外であるＵＶスライス２３２を記憶する。

ＧＰＵ２０２は、ゲームコンテンツ以外の画像であり、ユーザの操作に関連するユーザインタフェース（ＵＩ）の画像であるＵＩプレーン２３６をさらに生成する。ＧＰＵ２０２は、生成したＵＩプレーン２３６をＤＲＡＭ２４２に格納する。ＵＩプレーン２３６は、既述したように他画面データ２２４の一種であり、ゲームアプリケーションが生成するゲームの各種メニューを示す画像や、ゲームに対する各種設定用の画像を含む。また、ＵＩプレーン２３６は、ゲーム等のアプリケーションとは独立して、ゲームコンソール２００のＯＳ（Operating System）が生成するＵＩの画像を含む。ＯＳが生成するＵＩは、例えば、アプリケーションの切替や終了のための画像、ダウンロードの完了通知の画像、フレンド情報を示す画像等を含む。

解像度変換部２４４は、アダプティブ解像度変換部２０８による処理結果の画像と同等の解像度になるようＵＩプレーン２３６に対する解像度変換処理を実行してもよい。オーバレイ部２４６は、ＳＲＡＭ２４０に記憶されたＳＲ－Ｙスライス２３４およびＵＶスライス２３２と、解像度変換部２４４による解像度変換後のＵＩプレーン２３６とをオーバレイ（言い換えれば合成）し、すなわち、ゲームコンテンツの画像とＵＩの画像の両方を含む１つのスライス画像（すなわち部分画像）を生成する。

同一のフレーム２２０（スライス）から抽出されたＹスライス２３０およびＵＶスライス２３２と、超解像処理後のＳＲ－Ｙスライス２３４には、同一のＩＤ（例えば同一のフレームＩＤおよびスライスＩＤ）が付与される。ＳＲＡＭ２４０におけるＵＶスライス２３２を保持する時間には、そのＵＶスライス２３２に対応するＹスライス２３０に対する超解像処理の時間が追加される。対応するＹスライス２３０は、同一のスライスを起原とするＹスライス２３０であり、言い換えれば、同一のＩＤが付与されたＹスライス２３０である。オーバレイ部２４６は、同一のＩＤが付与されたＳＲ－Ｙスライス２３４とＵＶスライス２３２とを合成する。

すなわち、ＳＲＡＭ２０６における、画像特徴情報２２８、Ｙスライス２３０、メタ情報２２２のバッファリング量は、超解像画像生成部１０４が必要とする入力データが途切れない量（言い換えればアンダーフローを起こさない量）である。また、ＳＲＡＭ２４０におけるＳＲ－Ｙスライス２３４のバッファリング量は、オーバレイ部２４６が必要とする入力データが途切れない量（言い換えればアンダーフローを起こさない量）である。

一方、ＵＶスライス２３２のバッファリング量は、更に同一のスライスを起原とするＹスライス２３０に対する超解像処理が終了し、同一のスライスを起原とするＳＲ－Ｙスライス２３４とＵＶスライス２３２のＹＵＶ成分をオーバレイ部２４６で合体するタイミングとなるまでデータを保持する量とする。つまり下記の式が成り立つようにする。
ＳＲＡＭ２０６におけるＹスライス２３０の保持時間＋超解像画像生成部１０４のＹスライス処理時間＋ＳＲＡＭ２４０におけるＳＲ－Ｙスライス２３４の保持時間＝ＳＲＡＭ２４０におけるＵＶスライス２３２の保持時間
このようなバッファリングにおいて、同一のスライスを起原とするＹスライス２３０とＵＶスライス２３２に同一のＩＤを付与することで同期処理を実現する。

ディスプレイインタフェース２４８は、第１実施例のディスプレイコントローラ８４に対応する。ディスプレイインタフェース２４８は、オーバレイ部２４６により順次生成された複数のスライス画像を順次表示パネル５６（ディスプレイ８６）に表示させる。

第２実施例のゲームコンソール２００によると、第１実施例のクライアント端末１４と同様に、スライスを単位として超解像処理を実行し、超解像処理がなされたスライスを順次表示させることにより、超解像処理の遅延を抑制できる。また、ゲームコンソール２００は、スライスのＹ成分に超解像処理を行う一方で、スライスのＵＶ成分には超解像処理を行わない。これにより、超解像処理に要する計算量や時間を低減でき、また、ゲームコンソール２００のハードウェアリソース量を低減できる。

また、ゲームコンソール２００は、ＵＩプレーン２３６に対する超解像処理を行わず、コンテンツフレームの超解像処理の後にＵＩプレーン２３６を合成する。これにより、ＵＩプレーン２３６に対する超解像処理による副作用（例えばジャギーの発生等）を回避できる。なお、第２実施例で説明したスライスのＹ成分のみに対して超解像処理を行う構成や、ＵＩプレーン２３６に対する超解像処理を回避する構成は、第１実施例のクライアント端末１４にも適用可能である。

＜第３実施例＞
以下、第３実施例について、第２実施例と相違する構成を中心に説明し、共通する構成の説明は適宜省略する。第３実施例の構成要素のうち既述の実施例の構成要素と同一または対応する構成要素には同じ符号を付している。第３実施例の構成は、他の実施例および変形例の構成と任意の組合せが可能であることはもちろんである。

図１８は、第３実施例のゲームコンソールの構成を示すブロック図である。第３実施例のゲームコンソール２００は、図１６と図１７で示した第２実施例のゲームコンソール２００が備える機能ブロックに加えて、通信部４０、ＤＲＡＭ２５２、デマルチプレクサ２５４、ＤＲＡＭ２５６、ビデオデコーダ２５８を備える。第３実施例では、ゲームアプリケーションの描画は、サーバーのみで完結しなくてもよく、ゲームコンソール２００が追加の描画を実行してもよい。また、第３実施例では、ゲームアプリケーションとは異なる他のアプリケーションやＯＳが追加の描画を実行してもよい。

通信部４０は、サーバ１２からストリーミング送信されたビデオストリーム２６０を受け付け、受け付けたビデオストリーム２６０をＤＲＡＭ２５２に格納する。ビデオストリーム２６０は、超解像処理の対象となるスライスのデータを含む。ビデオストリーム２６０は、後述のビデオペイロード２６２、音声ペイロード２６４、スライス２６６を含む。通信部４０は、Ｗｉ－Ｆｉ（登録商標）、ギガビット・イーサネット（「イーサネット」は登録商標）、ＤＭＡ等の通信機能を含んでもよい。通信部４０は、公知の無線通信または有線通信を介してビデオストリーム２６０を取得してもよい。または、通信部４０は、所定のメモリに格納されたビデオストームをＤＭＡにより取得してもよい。

デマルチプレクサ２５４は、ＤＲＡＭ２５２に格納されたビデオストリーム２６０からビデオペイロード２６２、音声ペイロード２６４、メタ情報２２２を抽出し、抽出したビデオペイロード２６２、音声ペイロード２６４、メタ情報２２２をＤＲＡＭ２５６に格納する。

ＤＲＡＭ２５６は、ビデオペイロード２６２、音声ペイロード２６４、メタ情報２２２を記憶する。メタ情報２２２は、超解像処理のヒント情報とも言え、第１実施例においてサーバ１２からクライアント端末１４へ提供されるシーン情報を含んでもよく、例えば、スライスの圧縮符号化に関連するシーン情報を含んでもよい。また、メタ情報２２２は、サーバが生成した第１シーン情報と第２シーン情報も含んでもよい。

ビデオデコーダ２５８は、第１実施例の復号伸長部４４、ビデオデコーダ８２に対応する。ビデオデコーダ２５８は、ＤＲＡＭ２５６に記憶されたビデオペイロード２６２を復号伸長し、復号伸長後のデータ（スライス２６６）をＤＲＡＭ２０４に格納する。ＤＲＡＭ２０４は、第２実施例と同様にフレーム２２０、メタ情報２２２、他画面データ２２４、過去フレーム２２６を記憶し、第３実施例ではスライス２６６をさらに記憶する。ＤＲＡＭ２０４に記憶される他画面データ２２４と過去フレーム２２６の生成元は、ＧＰＵ２０２とビデオデコーダ２５８の両方である。

超解像処理部４８は、ＤＲＡＭ２０４に格納されたスライス２６６（すなわちサーバ１２から提供されたスライス）を読み込み、読み込んだスライスのＹ成分に対する超解像処理を実行する。超解像処理部４８は、第２実施例と同様に、ＤＲＡＭ２０４に格納されたフレーム２２０のデータをスライス単位でさらに読み込み、読み込んだスライスのＹ成分に対する超解像処理をさらに実行してもよい。第３実施例のゲームコンソール２００における以降の処理は、第２実施例のゲームコンソール２００と同じであるため、再度の説明を省略する。

第３実施例のゲームコンソール２００も、第２実施例のゲームコンソール２００と同様の効果を奏する。また、第３実施例のゲームコンソール２００によると、表示対象フレームをサーバ１２とゲームコンソール２００の両方で生成する場合にも、超解像処理の遅延を抑制できる。

＜第４実施例＞
以下、第４実施例について、第２実施例と相違する構成を中心に説明し、共通する構成の説明は適宜省略する。第４実施例の構成要素のうち既述の実施例の構成要素と同一または対応する構成要素には同じ符号を付している。第４実施例の構成は、他の実施例および変形例の構成と任意の組合せが可能であることはもちろんである。

第４実施例のゲームコンソールでは、シーン情報（すなわち超解像処理のヒント情報）を超解像処理部（後述の超解像画像生成部１０４）へ直接入力する。第４実施例のゲームコンソールは、シーン解析回路を備えない。その代わりに、第４実施例のゲームコンソールでは、予めシーン情報と入力画像のペアに適合する超解像処理の態様を機械学習させておく。第４実施例のゲームコンソールによると、シーン解析回路を省略することでハードウェアコストを低減しつつ、シーン解析回路を備える場合と同等の超解像処理を実現できる。すなわち、第４実施例のゲームコンソールは、既述の実施例のゲームコンソールと同様の効果を奏しつつ、ハードウェアコストを一層低減することができる。

また、第４実施例のゲームコンソールによると、図１７のゲームコンソール２００とは異なり、ＵＩプレーンを分離したデータパスやバッファリング系統を用意せずに、ＯＳ－ＵＩに対する超解像処理による副作用（例えばジャギーの発生等）を回避できる。また、後述するＯＳ－ＵＩプレーンに対しても超解像処理を施すことができる。さらにまた、シーン解析を省略することにより、超解像処理の遅延を抑制することができる。

図１９と図２１は、第４実施例のゲームコンソール２００の構成を示すブロック図である。図１９は、前段の処理に関する機能ブロックを示し、図２１は、図１９に続く処理に関する機能ブロックを示している。

図１９に示すように、第４実施例のゲームコンソール２００は、ＧＰＵ２０２、ＤＲＡＭ２０４、アダプティブ解像度変換部２７０、アダプティブ解像度変換部２７２、アダプティブ解像度変換部２７４、アダプティブ解像度変換部２７６、オーバレイ部２７８、色空間変換部２８０、色空間変換部２８２、色空間変換部２８４、ＳＲＡＭ２８６を備える。このうちアダプティブ解像度変換部２７０と色空間変換部２８０は、オプショナルな機能ブロックである。

ＧＰＵ２０２は、フレーム２２０、フレームメタ情報３１０、ＯＳ－ＵＩプレーン３１７、ＯＳ－ＵＩメタ情報３１８を生成してＤＲＡＭ２０４に格納する。フレームメタ情報３１０は、各フレーム２２０の描画内容に関するメタ情報である。フレームメタ情報３１０は、深度情報３１１、動きベクトル情報３１２、ブラー情報３１３、てかり強度情報３１４、ゲームＵＩメタ情報３１５、シーン識別メタ情報３１６を含む。

深度情報３１１は、各画素の奥行き情報（例えば図９の奥行き情報）、または３ＤゲームにおけるＺ値を含んでもよい。動きベクトル情報３１２は、フレーム２２０に描画された各オブジェクトの動きベクトル情報（例えば図９の動きベクトル情報）を含んでもよい。ブラー情報３１３は、上述のＭｏｔｉｏｎ Ｂｌｕｒ効果の使用有無と使用領域を示す情報であり、また、フレーム２２０の描画内容のボケ度合を示す情報を含んでもよい。てかり強度情報３１４は、フレーム２２０の描画内容のてかり強度をしめすもの（例えば図９のてかり強度情報）を含んでもよい。

ゲームＵＩメタ情報３１５は、第２実施例のＵＩプレーンのうちゲームアプリケーションが生成するゲームの各種メニューを示す画像や、ゲームに対する各種設定用の画像（以下「ゲームＵＩ」とも呼ぶ。）に関するメタ情報である。第４実施例では、ゲームＵＩは、フレーム２２０に描画される。ゲームＵＩメタ情報３１５は、画面またはフレーム２２０内におけるゲームＵＩの位置と、ゲームＵＩのα値（透明度）とを含む。シーン識別メタ情報３１６は、フレーム２２０に描画されたシーンの識別情報を含む。シーン識別メタ情報３１６は、例えば、第１実施例で既述した「超解像処理において判断材料とするシーン情報」を含んでもよい。

ＯＳ－ＵＩプレーン３１７は、第２実施例のＵＩプレーンのうちゲーム等のアプリケーションとは独立して、ゲームコンソール２００のＯＳ（Operating System）が生成するＵＩの画像（以下「ＯＳ－ＵＩ」とも呼ぶ。）である。ＯＳ－ＵＩメタ情報３１８は、ＯＳ－ＵＩに関するメタ情報である。ＯＳ－ＵＩメタ情報３１８は、画面またはフレーム２２０内におけるＯＳ－ＵＩの位置と、ＯＳ－ＵＩのα値（透明度）とを含む。

アダプティブ解像度変換部２７０は、ＤＲＡＭ２０４に記憶されたフレームメタ情報３１０に対するアダプティブ解像度変換を行う。アダプティブ解像度変換部２７２は、ＤＲＡＭ２０４に記憶されたフレーム２２０のうち過去フレームに対するアダプティブ解像度変換を行う。過去フレームは、例えば、断続的に生成され続けるフレーム２２０における過去に生成された超解像処理前のフレーム、もしくは、超解像処理後にディスプレイインタフェース２４８から出力したデータを図示しないデータパスでＤＲＡＭ２０４に書き戻したフレームを指す。アダプティブ解像度変換部２７４は、ＤＲＡＭ２０４に記憶されたフレーム２２０のうち最新フレーム（言い換えれば今回の超解像処理対象フレーム）に対するアダプティブ解像度変換を行う。アダプティブ解像度変換部２７６は、ＤＲＡＭ２０４に記憶されたＯＳ－ＵＩプレーン３１７に対するアダプティブ解像度変換を行う。

アダプティブ解像度変換は、第２実施例で説明したため再度の説明を省略する。なお、アダプティブ解像度変換部２７０、アダプティブ解像度変換部２７２、アダプティブ解像度変換部２７４、アダプティブ解像度変換部２７６のそれぞれは、第２実施例のアダプティブ解像度変換部２０８と同様に、それぞれの変換のための学習済パラメータを参照してアダプティブ解像度変換を実行してもよい。

オーバレイ部２７８は、ＯＳ－ＵＩメタ情報３１８に基づいて、アダプティブ解像度変換後のフレーム２２０とＯＳ－ＵＩプレーン３１７とをオーバレイする。オーバレイ部２７８は、ＯＳ－ＵＩメタ情報３１８が示すフレーム２２０内の位置に、ＯＳ－ＵＩメタ情報３１８が示す透明度にてＯＳ－ＵＩプレーン３１７を配置するように、フレーム２２０とＯＳ－ＵＩプレーン３１７とを合成してもよい。オーバレイ部２７８によるオーバレイ処理後の画像を以下「合成フレーム」と呼ぶ。

アダプティブ解像度変換後のフレームメタ情報３１０、過去フレーム、合成フレームは、必ずしも超解像処理に最適化された色空間のデータではない。例えば、過去フレームや合成フレームは、ＲＧＢ形式で各成分が８ビット長であってもよく、ＲＧＢ形式で各成分が浮動小数点３２ビット長であってもよい。また、過去フレームや合成フレームは、ＹＵＶ形式で水平方向に連続する４ピクセルから、ピクセル毎に輝度情報、輝度と青色成分の差、輝度と赤色成分の差をそれぞれ１サンプル採る方式のデータ（ＹＵＶ４４４）であってもよい。色空間変換部２８０、色空間変換部２８２、色空間変換部２８４は、アダプティブ解像度変換後のフレームメタ情報３１０、過去フレーム、合成フレームを超解像処理に最適化された色空間のデータに変換する。

色空間変換部２８０は、必要に応じて、フレームメタ情報３１０の各データ形式を超解像画像生成部に１０４に最適なデータ形式に変換する。予めシーン情報すなわちフレームメタ情報３１０と入力画像のペアに適合する超解像処理の態様を機械学習させたときに用いたフレームメタ情報３１０のデータ形式と、ＤＲＡＭ２０４に置かれるフレームメタ情報３１０のデータ形式が異なる場合、色空間変換部２８０は、データ形式を一致させるための変換を行う。色空間変換部２８０は、必要に応じてデータ変換を行った後のフレームメタ情報３１０のデータをライン単位で抽出し、そのラインデータ（「メタラインデータ２８８」と呼ぶ。）をＳＲＡＭ２８６に格納する。色空間変換部２８２は、過去フレームを、必要に応じてＹ成分が１２ビット長のＹＵＶ形式のデータに変換する。色空間変換部２８２は、色空間変換後の過去フレームのデータ（Ｙ成分のみ）をライン単位で抽出し、そのラインデータ（「過去ラインデータ２９０」と呼ぶ。）をＳＲＡＭ２８６に格納する。

色空間変換部２８４は、合成フレームを、必要に応じてＹ成分が１２ビット長のＹＵＶ形式のデータに変換する。色空間変換部２８４は、色空間変換後の合成フレームのデータ（Ｙ成分のみ）をライン単位で抽出し、そのラインデータ（「Ｙラインデータ２９２」と呼ぶ。）をＳＲＡＭ２８６に格納する。また、色空間変換部２８４は、色空間変換後の合成フレームのデータ（Ｕ成分およびＶ成分）をライン単位で抽出し、そのラインデータ（「ＵＶラインデータ２９４」と呼ぶ。）をＳＲＡＭ２８６に格納する。

ＳＲＡＭ２８６は、第１実施例の部分画像記憶部１０２に対応する。ＳＲＡＭ２８６は、複数のメタラインデータ２８８を格納するリングバッファ、複数の過去ラインデータ２９０を格納するリングバッファ、複数のＹラインデータ２９２を格納するリングバッファ、複数のＵＶラインデータ２９４を格納するリングバッファ、モデル保持部１０６を含む。

図２０は、ビデオタイミング例を示す。同図は、ＳＲＡＭ２８６に格納される各ラインデータを説明するための図である。ＳＲＡＭ２８６に格納される各ラインデータは、図２０に示すアクティブなディスプレイ期間（ＶａｃｔｉｖｅかつＨａｃｔｉｖｅの期間）におけるＡｃｔｉｖｅ Ｖｉｄｅｏの１つのラインに対応する。

図２１に示すように、第４実施例のゲームコンソール２００は、超解像画像生成部１０４、ＳＲＡＭ２９８、色空間変換部３０２、ディスプレイインタフェース２４８をさらに備える。

超解像画像生成部１０４は、モデル保持部１０６に記憶された深層学習に基づくモデルと、メタラインデータ２８８と、過去ラインデータ２９０とに基づいて、Ｙラインデータ２９２に対する深層学習に基づく超解像処理を実行する。例えば、超解像画像生成部１０４は、過去ラインデータ２９０とＹラインデータ２９２とを比較することにより、Ｙラインデータ２９２に映る物体の動きを検知し、その動きに適合するフィルタを選択してもよい。

また、超解像画像生成部１０４は、メタラインデータ２８８が示すゲームＵＩおよびＯＳ－ＵＩの位置と透明度に基づいて、Ｙラインデータ２９２に映るゲームＵＩおよびＯＳ－ＵＩの領域に、ゲームのコンテンツ領域とは異なるフィルタを選択してもよく、当該ＵＩ領域専用のフィルタを選択してもよい。また、超解像画像生成部１０４は、メタラインデータ２８８が示すゲームＵＩおよびＯＳ－ＵＩの位置と透明度に基づいて、Ｙラインデータ２９２に映るゲームＵＩおよびＯＳ－ＵＩにジャギーが生じないよう特殊なフィルタまたは専用のフィルタを選択してもよい。これにより、ゲームＵＩおよびＯＳ－ＵＩに対する超解像処理による副作用（例えばジャギーの発生等）を回避できる。

超解像画像生成部１０４のＤＮＮアクセラレータ１０８は、積和演算回路アレイ２９６を含む。積和演算回路アレイ２９６は、深層学習に基づく超解像処理において３×３または５×５の畳み込み計算を繰り返し実行する。３×３の畳み込み計算の場合、ＳＲＡＭ２８６の各リングバッファに最低３行のラインデータが入力されると処理を開始できる。そして、ＳＲＡＭ２８６の各リングバッファに新たな１行のラインデータが入力されるたびに次の行の畳み込み計算が可能になる。

超解像画像生成部１０４のＹスライス処理時間は、利用するモデルの畳み込み計算の構成とＤＮＮアクセラレータの演算器構成から計算することができる。モデルの構成情報としては、畳み込み計算のＫｅｒｎｅｌサイズ（３ｘ３、５ｘ５等）、畳み込み計算の密度を示すｓｔｒｉｄｅ，ｄｉｌａｔａｔｉｏｎ（１，２等）、各畳み込み層における入出力チャネル数（入力１、出力１６等）、畳み込み層の数、畳み込み層の構成（Ｆｕｌｌ ｃｏｎｖｏｌｕｔｉｏｎ，ｄｅｐｔｈｗｉｓｅ ｃｏｎｖｏｌｕｔｉｏｎ等）、アクティベーション層の構成（ＲｅＬＵ等）、入出力解像度（入力１９２０ｘ１０８０画素、出力３８４０ｘ２１６０画素等）等がある。ＤＮＮアクセラレータの演算器構成としては、同時処理可能な、積和演算数やアクティベーション演算数等がある。リングバッファに新たな１行のラインデータが入力されるたびに次の行の畳み込み計算が可能になる前提において、モデルの構成情報とＤＮＮアクセラレータの演算器構成から処理時間を計算することができる。

超解像画像生成部１０４は、Ｙラインデータ２９２に対する超解像処理の結果であるＳＲ－Ｙラインデータ３００をＳＲＡＭ２９８に格納する。一方、超解像画像生成部１０４は、ＳＲＡＭ２８６に記憶されたＵＶラインデータ２９４に対する超解像処理をスキップする。ＳＲＡＭ２８６に記憶されたＵＶラインデータ２９４は、超解像処理が施されることなく、後述の色空間変換部３０２に渡される。

色空間変換部３０２は、ＳＲＡＭ２９８に記憶されたＳＲ－Ｙラインデータ３００と、そのＳＲ－Ｙラインデータ３００に対応するＵＶラインデータ２９４とを合成し、表示する画像の１行に対応するラインデータ（ＹＵＶ形式）を生成する。色空間変換部３０２は、ＹＵＶ形式のラインデータを生成すると、そのラインデータの色空間をディスプレイにあわせて最適化する。色空間変換部３０２は、ＳＲＡＭ２９８に新たなＳＲ－Ｙラインデータ３００が格納される都度、新たなラインデータの合成と色空間変換を行い、複数のラインデータを順次ディスプレイインタフェース２４８に渡す。

ディスプレイインタフェース２４８は、第１実施例のディスプレイコントローラ８４に対応する。ディスプレイインタフェース２４８は、色空間変換部３０２から順次出力された複数のラインデータを順次表示パネル５６（ディスプレイ８６）に表示させる。

超解像画像生成部１０４は、超解像処理においてブラー情報を参照することで、ブラーが掛かった画像領域、すなわち意図的に画像をぼかしている領域については、機械学習結果に基づき、超解像処理による高精細化を抑制してもよい。これにより、超解像処理により、意図的なぼけが高精細化することを回避できる。また、人は、画像を視聴した際、動きが激しい物体が描画されている領域については、描画内容の細部を認識することは困難だが、エッジ領域等の変化には敏感である。そこで、超解像画像生成部１０４は、超解像処理において画像に映る物体の動きベクトル情報を参照することで、動きが激しい物体が描画されている領域については、機械学習に基づいて、超解像処理を抑制してもよい。また、超解像画像生成部１０４は、動きが激しい物体が描画されている領域のエッジ部分については、機械学習に基づいて、超解像処理（変換）を抑制してもよい。これにより、超解像処理が不要な領域の高精細化を抑制でき、また、エッジ領域の変換を抑制することができる。

以上、本開示を実施例をもとに説明した。この実施例は例示であり、各構成要素あるいは各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本開示の範囲にあることは当業者に理解されるところである。

各実施例や各変形例に記載の「閾値」は、特に断らない限り、情報処理システム１０またはゲームコンソール２００の開発者の知見や、情報処理システム１０またはゲームコンソール２００を用いた実験等により適切な値が決定されてよい。

上述した実施例および変形例の任意の組み合わせもまた本開示の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施例および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施例および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。

本開示の技術は、画像を処理する装置、サーバまたはシステムに適用することができる。

１０ 情報処理システム、 １２ サーバ、 １４ クライアント端末、 ２２ 画像生成部、 ２８ 圧縮符号化部、 ３２ シーン情報取得部、 ４２ データ取得部、 ４８ 超解像処理部、 ５４ 表示制御部。

Claims (10)

1. 動画像のデータを１フレームより小さい部分画像単位で取得する取得部と、
   前記取得部により取得された部分画像を単位として超解像処理を実行する超解像処理部と、
   前記超解像処理部により超解像処理がなされた部分画像を順次表示部に出力する表示制御部と、
   を備え、
   前記超解像処理部は、前記部分画像における離散的な位置から、前記部分画像より小さい解析単位粒度の領域画像を複数個抽出し、複数個の領域画像をもとにシーン解析を実行し、シーン解析結果をもとに前記部分画像に関する超解像処理を実行し、
   前記超解像処理部は、（１）ＣＵ（Coding Unit）割当情報に基づいて前記解析単位粒度の領域を割り当てること、（２）シーン解析に関するスコアが相対的に高い領域に対して前記解析単位粒度の領域を優先的に割り当てること、（３）Ｉフレームの部分画像には、Ｉフレーム以外の部分画像よりも、前記解析単位粒度の領域の割当数を多くすること、のうち少なくとも１つを実行する、
   画像処理装置。
2. 復号伸長部をさらに備え、
   前記取得部により取得される部分画像は、圧縮符号化後の部分画像であり、
   前記復号伸長部は、前記圧縮符号化後の部分画像を復号伸長し、
   前記超解像処理部は、復号伸長後の部分画像に対する超解像処理を実行する、
   請求項１に記載の画像処理装置。
3. 前記超解像処理部は、前記部分画像より解像度が低い部分画像を１つ以上生成し、解像度が相対的に低い部分画像から解像度が相対的に高い部分画像の順にシーン解析を実行する、
   請求項１または２に記載の画像処理装置。
4. 前記超解像処理部は、アプリケーションが最終描画結果を生成する前に、前記アプリケーションが持つ描画内部データを参照してシーン解析を実行し、シーン解析の結果を超解像処理に用いる、
   請求項１から３のいずれかに記載の画像処理装置。
5. 前記超解像処理部は、アプリケーションが最終描画結果を生成する前に、前記アプリケーションが持つ描画内部データを参照し、その描画内部データを超解像処理に用いる、
   請求項１から４のいずれかに記載の画像処理装置。
6. 前記超解像処理部は、超解像処理を行うまでの前段処理で取得された前記部分画像の特徴を示すシーン情報に基づいて、超解像処理の簡易化または未実行を選択する、
   請求項１から５のいずれかに記載の画像処理装置。
7. 前記超解像処理部は、前記部分画像が復号伸長される前に前記部分画像に関するシーン情報を取得し、取得したシーン情報に基づいて、超解像処理のためのモデルを切り替える、
   請求項２に記載の画像処理装置。
8. 前記超解像処理部は、アプリケーションが最終描画結果を生成する前に、前記アプリケーションが持つ描画内部データを用いてシーン情報を取得し、取得したシーン情報に基づいて、超解像処理のためのモデルを切り替える、
   請求項１から６のいずれかに記載の画像処理装置。
9. 前記超解像処理部は、前記部分画像をＹ成分のデータとＵＶ成分のデータとに分離し、前記Ｙ成分のデータに超解像処理を実行する一方、前記ＵＶ成分のデータには超解像処理を実行しない、
   請求項１から８のいずれかに記載の画像処理装置。
10. 同じ部分画像を起源とする前記Ｙ成分のデータと前記ＵＶ成分のデータには、同じＩＤが付与され、
    前記ＵＶ成分のデータは、前記Ｙ成分のデータに対する超解像処理の間バッファリングされ、同一のＩＤが付与された超解像処理後のＹ成分のデータと合成される、
    請求項９に記載の画像処理装置。

Images