(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-09-10
(45)【発行日】2024-09-19
(54)【発明の名称】画像処理装置
(51)【国際特許分類】
H04N 7/01 20060101AFI20240911BHJP
G06T 3/4053 20240101ALI20240911BHJP
A63F 13/49 20140101ALI20240911BHJP
A63F 13/35 20140101ALI20240911BHJP
【FI】
H04N7/01 170
G06T3/4053
A63F13/49
A63F13/35
(21)【出願番号】P 2022510557
(86)(22)【出願日】2021-03-23
(86)【国際出願番号】 JP2021012027
(87)【国際公開番号】W WO2021193649
(87)【国際公開日】2021-09-30
【審査請求日】2022-08-29
(31)【優先権主張番号】P 2020054672
(32)【優先日】2020-03-25
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】310021766
【氏名又は名称】株式会社ソニー・インタラクティブエンタテインメント
(74)【代理人】
【識別番号】100105924
【氏名又は名称】森下 賢樹
(74)【代理人】
【識別番号】100109047
【氏名又は名称】村田 雄祐
(74)【代理人】
【識別番号】100109081
【氏名又は名称】三木 友由
(74)【代理人】
【識別番号】100134256
【氏名又は名称】青木 武司
(72)【発明者】
【氏名】大塚 活志
【審査官】長谷川 素直
(56)【参考文献】
【文献】特表2017-510114(JP,A)
【文献】特開2012-049747(JP,A)
【文献】特開2009-117886(JP,A)
【文献】特開2010-278898(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04N 7/01
H04N 19/00-19/98
G06T 3/40
A63F 13/00
(57)【特許請求の範囲】
【請求項1】
入力された画像に対して、当該画像の特徴を示すシーン情報をもとに超解像処理を実行する超解像処理部と、
前記超解像処理部により超解像処理がなされた画像を表示部に出力する表示制御部と、
を備え、
前記シーン情報は、超解像処理の対象となる画像に対する超解像処理が行われるまでの前段処理において取得されたものであり、
前記超解像処理部は、(A)メインコンテンツの画像と付加的なコンテンツの画像とがオーバレイされた画像の超解像処理において、α値に関するデータを参照し、前記メインコンテンツの画像の領域と、前記付加的なコンテンツの画像の領域とでは、異なる超解像処理を実行し、または、(B)前記画像を生成したアプリケーションが持つ描画内部データに含まれるブラー情報を参照し、前記画像におけるブラーが掛かった領域に対する超解像処理を切り替えることを特徴とする画像処理装置。
【請求項2】
入力された画像に対して、当該画像の特徴を示すシーン情報をもとに超解像処理を実行する超解像処理部と、
前記超解像処理部により超解像処理がなされた画像を表示部に出力する表示制御部と、
を備え、
前記シーン情報は、超解像処理の対象となる画像に対する超解像処理が行われるまでの前段処理において取得されたものであり、
超解像処理における内部処理の単位となる領域を解析単位粒度の領域と呼ぶとき、
(A)前記超解像処理部は、前記画像の圧縮符号化に関するCU(Coding Unit)割当情報を参照して、前記画像における1CUあたり1つの解析単位粒度の領域を割り当て、
または、(B)前記超解像処理部は、前記画像の複数の領域のそれぞれに有限個数の解析単位粒度の領域を割り当てる場合に、シーン解析における所定の基準で算出されたスコアが相対的に高い領域に対して、前記スコアが相対的に低い領域より多くの解析単位粒度の領域を割り当て、
または、(C)前記超解像処理部は、前記画像の複数の領域のそれぞれに有限個数の解析単位粒度の領域を割り当てる場合に、人肌推定処理における所定の基準で算出されたスコアが相対的に高い領域に対して、前記スコアが相対的に低い領域より多くの解析単位粒度の領域を割り当て、
または、(D)
前記超解像処理部は、前記画像がIフレームの場合、前記画像がIフレーム以外である場合より、前記画像全体での前記解析単位粒度の領域の割当数を多くすることを特徴とする画像処理装置。
【請求項3】
サーバから提供された圧縮符号化後の画像を復号伸長する復号伸長部をさらに備え、
前記超解像処理部は、前記復号伸長部により復号伸長された画像に対する超解像処理を、前記サーバから提供されたシーン情報をもとに実行する、
請求項1または2に記載の画像処理装置。
【請求項4】
サーバから提供された圧縮符号化後の画像を復号伸長する復号伸長部をさらに備え、
前記復号伸長部は、復号伸長処理において使用する圧縮符号化処理の構成を示す情報から、前記画像に関するシーン情報を取得し、
前記超解像処理部は、前記復号伸長部により復号伸長された画像に対する超解像処理を、前記復号伸長部において取得されたシーン情報をもとに実行する、
請求項1または2に記載の画像処理装置。
【請求項5】
前記超解像処理部は、非可逆圧縮を経た画像の超解像処理において、前記画像を描画したアプリケーションが持つ描画内部データに基づいてシーン解析を実行し、シーン解析の結果を超解像処理に用いる、
請求項1から4のいずれかに記載の画像処理装置。
【請求項6】
前記超解像処理部は、非可逆圧縮を経た画像の超解像処理において、前記画像を描画したアプリケーションが持つ描画内部データを超解像処理に用いる、
請求項1から5のいずれかに記載の画像処理装置。
【請求項7】
前記超解像処理部は、前記画像に映る物体の動きベクトル情報を参照し、移動体が描画されている領域に対する超解像処理を抑制し、または、移動体が描画されている領域のエッジ部分に対する超解像処理を抑制する、
請求項1から6のいずれかに記載の画像処理装置。
【請求項8】
前記超解像処理部は、前記画像のアーティファクト強度を参照し、画質劣化が強い領域に対する平滑化処理を強化する、
請求項1から7のいずれかに記載の画像処理装置。
【発明の詳細な説明】
【技術分野】
【0001】
本開示はデータ処理技術に関し、特に画像処理装置およびサーバに関する。
【背景技術】
【0002】
クラウドゲームにおいては、サーバにてゲームアプリケーションが実行され、ゲームシーン画像が描画される。サーバは、描画したゲームシーン画像を、ネットワークを介してクライアント端末に提供する。クライアント端末は、サーバから提供されたゲームシーン画像を表示させる。
【発明の概要】
【発明が解決しようとする課題】
【0003】
サーバから提供されるゲームシーン画像は、有限ネットワーク帯域にて送信するために、非可逆圧縮符号化による映像クオリティの劣化や、解像度の引き下げが起きえる。また、クライアント端末が備えるディスプレイの解像度や対応色空間が、サーバから提供されたゲームシーン画像の解像度や色空間よりも高度な場合がある。このような場合、ユーザが視聴するゲームシーン画像のクオリティを引き上げるために、クライアント端末が超解像処理を実行することが考えられる。
【0004】
従来の手法では超解像処理に長い時間を要しており、ユーザがクラウドゲームをリアルタイムでプレイすることが困難になる可能性がある。
【0005】
本開示はこうした課題に鑑みてなされたものであり、1つの目的は、超解像を低遅延で処理する技術を提供することにある。
【課題を解決するための手段】
【0006】
上記課題を解決するために、本開示のある態様の画像処理装置は、入力された画像に対して、当該画像の特徴を示すシーン情報をもとに超解像処理を実行する超解像処理部と、超解像処理部により超解像処理がなされた画像を表示部に出力する表示制御部と、を備える。シーン情報は、超解像処理の対象となる画像に対する超解像処理が行われるまでの前段処理において取得されたものである。
【0007】
本開示の別の態様は、サーバである。このサーバは、アプリケーションの画像を生成する画像生成部と、画像生成部により生成された画像の特徴を示すシーン情報を取得するシーン情報取得部と、画像のデータとシーン情報とをクライアント端末に送信することにより、画像に対する超解像処理をシーン情報に基づいてクライアント端末に実行させる送信部と、を備える。
【0008】
なお、以上の構成要素の任意の組合せ、本開示の表現を、システム、コンピュータプログラム、コンピュータプログラムを記録した記録媒体などの間で変換したものもまた、本開示の態様として有効である。
【発明の効果】
【0009】
本開示によれば、超解像を低遅延で処理することができる。
【図面の簡単な説明】
【0010】
【
図1】第1実施例の情報処理システムの構成を示すブロック図である。
【
図2】第1実施例の情報処理システムの構成を示すブロック図である。
【
図3】
図2の超解像処理部の詳細な構成を示すブロック図である。
【
図4】シーン解析処理を低遅延化する方法を模式的に示す図である。
【
図5】機械学習ベースの超解像処理を模式的に示す図である。
【
図6】深層学習ベースの超解像処理を模式的に示す図である。
【
図7】部分画像単位のパイプライン処理の概念図である。
【
図8】部分画像単位のパイプライン処理の概念図である。
【
図9】ゲームアプリケーションが保持するシーン情報の例を示す図である。
【
図11】CUユニット割当情報の例を示す図である。
【
図15】第2実施例のゲームコンソールの構成を示すブロック図である。
【
図16】第2実施例のゲームコンソールの構成を示すブロック図である。
【
図17】第2実施例のゲームコンソールの構成を示すブロック図である。
【
図18】第3実施例のゲームコンソールの構成を示すブロック図である。
【
図19】第4実施例のゲームコンソールの構成を示すブロック図である。
【
図21】第4実施例のゲームコンソールの構成を示すブロック図である。
【発明を実施するための形態】
【0011】
<背景と課題>
クラウドゲームで超解像を処理する背景と課題を説明する。超解像処理(Super Resolution, Video quality enhancement)とは、画像の高精細度化や、高周波成分の復元または再構築を含む画像処理である。
【0012】
クラウドゲームにおいては、サーバにてゲームアプリケーションが実行され、ゲームシーン画像が描画される。ゲームシーン画像は、ネットワークを介して、クライアント端末に提供される。ユーザはクライアント端末を介してゲームシーンを視聴し、ゲームに対する入力を行う。ユーザの入力に関するデータは、ネットワークを介してサーバに転送され、ゲームアプリケーションの進行に反映される。
この一連の処理に時間がかかると、クライアント端末へのゲームシーン画像の到着が遅れ、ユーザはリアルタイムでのゲームプレイが困難になる。そのため、処理系全体の低遅延化が求められる。
【0013】
また、ゲームシーン画像は、例えば、FHD(Full HD)画像(1920×1080画素)の60fps(frames per second)や、4K画像(3840×2160画素)の60fps等のビデオ映像である。ゲームシーン画像を有限ネットワーク帯域(例えば10Mbpsや30Mbps)で送信するには圧縮符号化が必要となる。
【0014】
ここで、有限ネットワーク帯域にて送信するために、ゲームシーン画像には、非可逆圧縮符号化による映像クオリティの劣化や、解像度の引き下げ(ダウンスケーリング)が起き得る。また、クライアント端末が備える表示ディスプレイの解像度や対応色空間が、サーバから送信されたゲームシーン画像の解像度や色空間よりも高度な場合がある。そのため、ユーザが視聴するゲームシーン画像のクオリティ引き上げのために、ゲームシーン画像が提供されたクライアント端末で超解像処理を実行することが考えられる。
【0015】
超解像処理では、画像に映る内容を判別または推定するシーン解析の結果に基づいて、当該画像に対して解像度の引き上げ処理(アップスケーリング)やフィルタ処理、復元・再構築処理等が実行される。前述の通り、処理系全体の低遅延化が求められるなかで、追加で発生する処理時間を最小化する必要がある。しかし、従来の超解像処理手法では、これらの処理において1フレーム以上の遅延が発生する。また、超解像処理に先立つシーン解析処理において、あらゆる映像条件に対応してシーンを判別することには限界があり、また、解析能力を引き上げようとすると、高度な処理が必要となって処理遅延が増加してしまうジレンマもある。
【0016】
本開示では、このような背景と課題を鑑みて、クラウドゲームにおいて、低遅延で超解像処理を実現させる技術と、クラウドゲームにおいて、シーン情報に基づいた超解像処理を実現させる技術を提案する。
【0017】
本開示にて提案する、クラウドゲームにおいて超解像を処理する方法を説明する。
<第1の解決手法:クラウドゲームにおいて超解像を低遅延で処理する方法A>
(1)超解像処理部が、部分画像(以下「スライス」とも呼ぶ。)単位で処理し、表示制御部へ、同様もしくはより小粒度で処理結果を出力する。
(2)ビデオ圧縮符号化部・復号伸長部が、部分画像(スライス)単位で処理し、伸長結果の画像を部分画像(スライス)単位で出力する場合において、後続処理である超解像処理部が、同じ部分画像(スライス)単位で処理し、表示制御部へ、同様もしくはより小粒度で処理結果を出力する。
(3)超解像処理部が、ビデオ圧縮符号化の処理における基本単位と一致させた、基本単位もしくは整数倍の単位で処理を実行する。
【0018】
(4)超解像処理部が、自ら行うシーン解析において、部分画像(スライス)単位で処理する。
(5)超解像処理部が、部分画像(スライス)単位で処理する。前段のビデオ復号伸長部と超解像処理部との間に、部分画像単位でデータを保持するメモリを設ける。後段の表示制御部と超解像処理部との間に、部分画像単位でデータを保持するメモリを設ける。超解像処理部は、ビデオ復号伸長部との間、および、表示制御部との間で、部分画像単位でフロー制御を実行する。
(6)超解像処理部が、シーン解析もしくはシーン情報統合処理、画像解像度の引き上げ処理(アップスケーリング)、画像フィルタ処理、画像の復元・再構築処理等を実行する場合に、それら個々の処理を部分画像単位で実行する。超解像処理部の内部処理における単位粒度を、整数倍すると、部分画像単位となるようにする。
【0019】
(7)超解像処理部が、超解像処理において深層学習を用いる場合に、複数の推論処理部を持たせて随時切替利用可能とする。これにより、シーン解析結果に基づいて異なる深層学習モデル(学習結果を保持するデータベース)を推論処理部へ動的に適用する必要がある場合において、設定初期化に要する時間を隠蔽することができる。
(8)シーン解析において、入力画像をピラミッドスケーリングを用いて複数通りの低解像度に変換し、低解像度画像から順にシーン解析を実行する。
(9)シーン解析において、入力画像の離散的な位置からオリジナル解像度でサンプリングした小領域でシーン解析を実行する。
(10)ゲームアプリケーションから取得したシーン種別に基づいて、超解像処理の簡易化または未実行を選択する。
【0020】
<第2の解決手法:クラウドゲームにおいて超解像を低遅延で処理する方法B>
この解決手法は、クラウドゲームにおいてシーン情報に基づいて超解像を処理する方法でもある。
(1)超解像処理部は、シーン情報を、ヒントとして前段処理から取得し、超解像処理で利用する。
(2)クライアント端末における超解像処理で利用するシーン情報を、サーバにおいて予め取得し、クライアント端末へ送信する。
(3)クライアント端末における超解像処理で利用するシーン情報を、サーバにおいて圧縮符号化と並行して取得し、クライアント端末へ送信する。
【0021】
(4)クライアント端末における超解像処理で利用するシーン情報を、サーバにおいて圧縮符号化と並行して解析し、クライアント端末へ送信する。
(5)クライアント端末における超解像処理で利用するシーン情報を、サーバにおいてゲームアプリケーションから取得し、クライアント端末へ送信する。
(6)クライアント端末における超解像処理で利用するシーン情報を、サーバにおける圧縮符号化で用いたシーン解析結果から取得し、クライアント端末へ送信する。
【0022】
(7)クライアント端末における超解像処理で利用するシーン情報を、復号伸長部が使用する圧縮符号化処理の構成結果から取得する。
(8)クライアント端末の超解像処理部は、サーバまたは復号伸長部から取得した、シーン情報を用いて超解像処理を実行する。
(9)クライアント端末の超解像処理部は、サーバまたは復号伸長部から取得した、シーン情報を用いることで、自ら行うシーン解析を省略もしくは簡易化する。
【0023】
<第1実施例>
図1は、実施例の情報処理システム10の構成を示すブロック図である。情報処理システム10は、サーバ12とクライアント端末14を備える。サーバ12は、アプリケーション(実施例ではゲームアプリケーション)を実行する情報処理装置である。クライアント端末14は、サーバ12で実行されたアプリケーションの画像(例えばゲームシーン画像)を表示する画像処理装置(情報処理装置とも言え、例えば据置型ゲーム機)である。サーバ12とクライアント端末14は、LAN・WAN・インターネット等を含む通信網を介して接続される。
【0024】
サーバ12は、内容決定部20、画像生成部22、バッファ24(レンダリングバッファおよびフレームバッファ)、圧縮符号化部28、シーン解析部B26、シーン情報取得部32、パケット化部34、通信部36を備える。圧縮符号化部28は、シーン解析部A30を含む。クライアント端末14は、通信部40、データ取得部42、復号伸長部44、超解像処理部48、表示制御部54、表示パネル56を備える。復号伸長部44は、符号化方法取得部46を含む。超解像処理部48は、シーン解析部C50とシーン情報統合部52を含む。
【0025】
本開示のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのCPU・メモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
【0026】
図1の各機能ブロックの処理を説明する。サーバ12の内容決定部20は、主にCPUにより実現され、ゲームアプリケーションを実行して、描画すべき内容を決定する。サーバ12の画像生成部22は、主にGPUにより実現され、内容決定部20によるゲームアプリケーションの処理結果(例えば描画すべき内容に関するデータ)に基づいて、ゲームアプリケーションの動画像のフレームを描画する(言い換えれば生成する)。画像生成部22は、描画結果のフレームをバッファ24(フレームバッファ)に格納する。なお、サーバ12のバッファ24(レンダリングバッファ)は、画像生成部22による描画処理の途中結果等を記憶する。
【0027】
サーバ12の圧縮符号化部28は、バッファ24(フレームバッファ)に格納された画像(フレーム)のデータを、1フレームより小さい部分画像の単位で圧縮符号化する。圧縮符号化部28は、非可逆圧縮を行ってもよい。部分画像は、フレームの画像平面を所定サイズに分割してなる各領域の画像である。すなわち部分画像は、例えば画像平面を横方向、縦方向、縦横双方向、または斜め方向に設定した境界線で分割してなる、各領域の画像である。圧縮符号化部28は内部においてIフレームとPフレームを生成してもよく、上記の1フレームより小さい部分画像は、Iフレームの部分画像であってもよく、Pフレームの部分画像であってもよい。圧縮符号化部28は、圧縮符号化後の部分画像のデータをパケット化部34へ出力する。
【0028】
圧縮符号化部28のシーン解析部A30は、圧縮符号化のために元来行うシーン解析処理を実行する。例えば、シーン解析部A30は、シーン解析処理を実行して、イントラ解析結果(平面類似性)、インター解析結果(動きベクトル)、CU(Coding Unit)割り当て検討結果、シーンセグメンテーション結果を得る。シーン解析部A30によるシーン解析処理の結果は、圧縮符号化済みのデータを参照するだけでは判らない解析結果を含む。なお、実施例のシーン解析処理の結果は、解析対象の画像(実施例では部分画像)を特定可能な解析対象の画像の識別情報を含んでもよい。以下のシーン解析結果およびシーン情報も同様である。
【0029】
サーバ12のシーン解析部B26は、バッファ24(フレームバッファ)に格納された画像(フレーム)のデータを参照して、超解像処理が元来必要とするシーン解析処理を実行する。シーン解析部B26は、圧縮符号化部28による圧縮符号化処理と並行にシーン解析処理を実行することで、処理時間を隠蔽する。また、シーン解析部B26は、シーン解析処理において、バッファ24(フレームバッファ)に格納されたゲームアプリケーションの描画内容も超解像処理のヒントとして得る。
【0030】
また、シーン解析部B26は、シーン解析処理において、バッファ24(フレームバッファ)に格納されたゲームアプリケーション以外のアプリケーションやOSの描画内容も超解像処理のヒントとしてさらに取得してもよい。超解像処理のヒントは、例えば、ゲームアプリケーションやOSが描画するメニューUIや字幕等が、どのような種別の画像であるか、どのような形状であるか、どのような画像座標位置に描画されているかといった情報である。この情報には、アプリケーションのメインコンテンツ(ゲームの場合、キャラクタ等)の画像に対して、メニューUIや字幕等の付加的なコンテンツの画像が合成(オーバレイ)された画像についての情報であり、付加的なコンテンツが、どのような画像座標位置に、どのような透明度で、メインコンテンツの画像に対して合成されるかを示すα(アルファ)値に関する情報(テーブル等)が含まれてもよい。
【0031】
サーバ12のシーン情報取得部32は、シーン解析部A30によるシーン解析処理の結果と、シーン解析部B26によるシーン解析処理の結果を取得する。また、シーン情報取得部32は、内容決定部20から、ゲームアプリケーションに関して描画対象のシーン内容を示す情報を取得する。シーン内容を示す情報は、例えば、3Dオブジェクトの配置状態や、利用テクスチャ特性、シーンセグメンテーション情報を含んでもよい。シーン情報取得部32は、シーン解析部A30によるシーン解析処理の結果と、シーン解析部B26によるシーン解析処理の結果と、内容決定部20から得られたシーン内容を示す情報とを含むシーン情報(以下「第1シーン情報」とも呼ぶ。)をパケット化部34へ出力する。
【0032】
サーバ12のパケット化部34は、圧縮符号化部28から出力された圧縮符号化後の部分画像のデータと、シーン情報取得部32から出力された第1シーン情報とをパケット化し、通信部36へ出力する。サーバ12の通信部36は、パケット化部34から出力されたパケットデータを、通信網を介してクライアント端末14へ送信する。サーバ12のパケット化部34と通信部36は、クライアント端末14へデータを送信する送信部とも言える。
【0033】
クライアント端末14の通信部40は、サーバ12から送信されたパケットデータを、通信網を介して受信する。クライアント端末14のデータ取得部42は、通信部40により受信されたパケットデータをもとに、圧縮符号化された部分画像のデータと、第1シーン情報とを取得(再構築)する。データ取得部42は、圧縮符号化された部分画像のデータを復号伸長部44へ出力し、第1シーン情報をシーン情報統合部52へ出力する。
【0034】
クライアント端末14の復号伸長部44は、圧縮符号化された部分画像のデータに対する復号伸長処理を実行して、元の部分画像を得る。復号伸長部44は、復号伸長後の部分画像を超解像処理部48へ出力する。復号伸長部44の符号化方法取得部46は、圧縮符号化された部分画像のデータに含まれるシーン情報(以下「第2シーン情報」とも呼ぶ。)を得る。言い換えれば、符号化方法取得部46は、復号伸長処理において使用するサーバ12における圧縮符号化処理の構成を示す情報(構成結果とも言える)から、復号伸長対象の部分画像に関する第2シーン情報を取得する。第2シーン情報は、フレーム種別(Iフレーム、Pフレーム等の種別)、量子化パラメータ(QP)値、動きベクトル、CU割り当て情報を含む。符号化方法取得部46は、第2シーン情報をシーン情報統合部52へ出力する。
【0035】
クライアント端末14の超解像処理部48は、復号伸長部44から入力された部分画像に対する超解像処理(例えば高解像度化および高画質化)を実行する。超解像処理部48は、CPUおよび/またはGPUが、超解像処理のロジックが実装されたコンピュータプログラムを実行することにより実現されてもよい。
【0036】
超解像処理部48のシーン解析部C50は、公知技術を用いて超解像処理の前段処理としてのシーン解析処理を実行する。具体的には、シーン解析部C50は、圧縮符号化および/または解像度引き下げによって劣化した部分画像を分析する。シーン解析部C50は、サーバ12のシーン解析部B26と同等のシーン解析処理をさらに実行してもよい。シーン解析部C50は、シーン解析処理の結果を第3シーン情報としてシーン情報統合部52へ出力する。
【0037】
シーン情報統合部52は、特定の部分画像の特徴を示す複数種類のシーン情報を統合する。具体的には、シーン情報統合部52は、データ取得部42から入力された第1シーン情報と、符号化方法取得部46から入力された第2シーン情報と、シーン解析部C50から入力された第3シーン情報を、各シーン情報に含まれる画像の識別情報をもとに統合することにより、上記特定の部分画像のシーン情報(統合されたシーン情報)を取得する。なお、第1シーン情報、第2シーン情報、第3シーン情報のうちいずれかが欠けてもよく、シーン情報統合部52は、第1シーン情報、第2シーン情報、第3シーン情報のうち入力されたシーン情報を統合してもよい。超解像処理部48は、入力された部分画像に対する超解像処理を、シーン情報統合部52により統合された当該部分画像に対応するシーン情報に基づいて実行する。超解像処理の具体例は後述する。
【0038】
クライアント端末14の表示制御部54は、超解像処理部48により超解像処理がなされた複数の部分画像を表示パネル56に順次出力して表示させる。
【0039】
このように、クライアント端末14のデータ取得部42は、表示パネル56に表示させるべき動画像のデータを1フレームより小さい部分画像単位で取得する。クライアント端末14の超解像処理部48は、データ取得部42により取得された部分画像を単位として超解像処理を実行する。クライアント端末14の表示制御部54は、超解像処理部48により超解像処理がなされた部分画像を順次表示パネル56に出力する。実施例のクライアント端末14によると、超解像処理の遅延を抑制することができる。
【0040】
また、クライアント端末14の超解像処理部48は、入力された画像に対して、当該画像の特徴を示すシーン情報をもとに超解像処理を実行する。クライアント端末14の表示制御部54は、超解像処理部48により超解像処理がなされた画像を表示パネル56に出力する。上記のシーン情報は、超解像処理の対象となる画像に対する超解像処理が行われるまでの前段処理において、予め取得されたものである(例えば第1シーン情報~第3シーン情報)。実施例のクライアント端末14によると、あらかじめどのようなシーンであるか把握することにより、超解像処理部の処理時間を抑制しながら、そのシーンに最も適した超解像処理を選択実行することが可能となり、高画質化を図りながら、超解像処理の遅延を抑制することができる。
【0041】
また、サーバ12の画像生成部22は、アプリケーションの動画像をフレーム単位で生成する。サーバ12の圧縮符号化部28は、画像生成部22により生成された画像(例えばゲームシーン画像)を1フレームより小さい部分画像の単位で圧縮符号化する。サーバ12の送信部(例えばパケット化部34および通信部36)は、圧縮符号化された部分画像を、部分画像を単位として超解像処理を実行するクライアント端末14に送信する。実施例のサーバ12によると、クライアント端末14における超解像処理の遅延を抑制することができる。
【0042】
また、サーバ12の画像生成部22は、アプリケーションの画像を生成する。サーバ12のシーン情報取得部32は、画像生成部により生成された画像の特徴を示すシーン情報(例えば第1シーン情報)を取得する。サーバ12の送信部は、画像のデータとシーン情報とをクライアント端末14に送信することにより、上記画像に対する超解像処理を上記シーン情報に基づいてクライアント端末14に実行させる。実施例のサーバ12によると、クライアント端末14において効率的な超解像処理が可能となり、クライアント端末14における超解像処理の遅延を抑制することができる。
【0043】
図2も、実施例の情報処理システム10の構成を示すブロック図である。
図2の情報処理システム10の機能ブロックのうち、
図1の情報処理システム10の機能ブロックと同一の機能ブロックには同一の符号を付している。
【0044】
図2のサーバ12の描画制御部60は、
図1の内容決定部20に対応する。
図2のサーバ12の画像描画部62は、
図1の画像生成部22に対応する。
図2のサーバ12のフレームバッファ64は、
図1のバッファ24に対応する。
図2のサーバ12のビデオエンコーダ66は、
図1の圧縮符号化部28に対応する。
図2のサーバ12のビデオストリーム制御部68は、
図1のパケット化部34に対応する。
図2のサーバ12の入出力I/F70は、
図1の通信部36に対応する。
【0045】
サーバ12は、部分画像記憶部72と制御部74をさらに備える。部分画像記憶部72は、ビデオエンコーダ66から出力された、圧縮符号化後の部分画像のデータを記憶する。制御部74は、CPUにより実現されてもよく、各機能ブロックにおける処理の開始と終了を制御し、また機能ブロック間での処理の同期を制御し、また機能ブロック間でのデータの送受信を制御する(フロー制御)。
【0046】
図2のクライアント端末14の入出力I/F80は、
図1の通信部40およびデータ取得部42に対応する。
図2のクライアント端末14のビデオデコーダ82は、
図1の復号伸長部44に対応する。
図2のクライアント端末14のディスプレイコントローラ84は、
図1の表示制御部54に対応する。
図2のクライアント端末14のディスプレイ86は、
図1の表示パネル56に対応する。
【0047】
クライアント端末14は、部分画像記憶部88、部分画像記憶部90、部分画像記憶部92、制御部94をさらに備える。部分画像記憶部88は、入出力I/F80により取得された(言い換えればサーバ12から送信された)部分画像のデータを記憶する。部分画像記憶部90は、ビデオデコーダ82による復号伸長後の部分画像のデータを記憶する。部分画像記憶部92は、超解像処理部48による超解像処理後の部分画像のデータを記憶する。制御部94は、各機能ブロックにおける処理の開始と終了を制御し、また機能ブロック間での処理の同期を制御し、また機能ブロック間でのデータの送受信を制御する(フロー制御)。
【0048】
図2には不図示だが、クライアント端末14は、画像処理部をさらに備えてもよい。画像処理部は、部分画像記憶部90または部分画像記憶部92に記憶された部分画像に関する(1)複数のプレーンの合成処理、(2)色空間の変換処理、(3)解像度変換処理のうち少なくとも1つを実行してもよい。
【0049】
図3は、
図2の超解像処理部48の詳細な構成を示すブロック図である。超解像処理部48は、シーン解析部C50、シーン情報統合部52、解像度変換部100、部分画像記憶部102、超解像画像生成部104、超解像処理制御部110を備える。
【0050】
超解像処理制御部110は、超解像処理部48内の他の機能ブロックに対して制御信号を送信し、同期制御やタイミング制御、フロー制御を実施する。解像度変換部100は、ビデオデコーダ82から出力された復号伸張化後の部分画像の解像度を変換する。具体的には、解像度変換部100は、補間等の公知の手法により部分画像を高解像度化し、高解像度化した部分画像を部分画像記憶部102に格納する。超解像画像生成部104は、部分画像記憶部102に記憶された部分画像を読み出し、読み出した部分画像に対してフィルタ処理や、画像の復元・再構築処理を実行することにより、部分画像を高画質化する。
【0051】
超解像画像生成部104は、モデル保持部106とDNN(Deep Neural Network)アクセラレータ108を含む。モデル保持部106は、超解像処理のためのモデルであり、
図6に関連して後述する深層学習により生成されたモデルを記憶する。モデルは、例えば、超解像処理(例えば、画像フィルタ処理、画像の復元・再構築処理等)のアルゴリズムが実装された計算式、関数であってもよい。
【0052】
DNNアクセラレータ108は、解像度変換部100により高解像度化された部分画像を部分画像記憶部102から読み出し、読み出した部分画像を、モデル保持部106に記憶されたモデルに基づいて高画質化する。DNNアクセラレータ108は、高画質化した部分画像を部分画像記憶部92に出力する。
【0053】
変形例として、モデル保持部106は、
図5に関連して後述する機械学習により生成されたモデルを記憶してもよい。また、解像度変換部100は、第1シーン情報、第2シーン情報、シーン解析部C50からの第3シーン情報の少なくとも1つを参照して解像度変換処理を実行してもよい。また、解像度変換部100は、超解像画像生成部104の後段に設けられてもよく、すなわち、解像度変換部100は、超解像画像生成部104により高画質化された部分画像を高解像度化してもよい。また、超解像処理部48は、解像度変換部100を含まない構成であってもよく、すなわち、解像度変換処理を実行しない構成であってもよい。また、超解像処理部48は、解像度変換部100を含まず、超解像画像生成部104が、部分画像の高画質化と解像度変換処理とを同時に実行する構成であってもよい。
【0054】
図4は、シーン解析処理を低遅延化する方法を模式的に示す。
図3等に関連して説明したように、超解像処理部48は、シーン解析処理、シーン情報統合処理、画像解像度の引き上げ処理(アップスケーリング)、画像フィルタ処理、画像の復元・再構築処理等の内部処理を実行する。
図4の(1)に示すように、超解像処理部48は、これら個々の内部処理を部分画像単位で実行する。超解像処理部48の内部処理における単位粒度は、整数倍すると部分画像単位となるように構成されることが望ましい。
図4では、内部処理における単位粒度を点線の四角(以下「解析単位粒度」とも呼ぶ。)で示している。
【0055】
また、
図4の(2)に示すように、超解像処理部48は、シーン解析(シーン解析部C50)において、入力画像をピラミッドスケーリングを用いて複数通りの低解像度部分画像に変換する。そして、超解像処理部48は、解像度が相対的に低い部分画像から解像度が相対的に高い部分画像の順にシーン解析処理を実行する。
【0056】
超解像処理部48(シーン解析部C50)は、複数通りの解像度の部分画像それぞれに対するシーン解析結果を、解像度が異なる全ての部分画像の解析終了を待たず、順次、シーン情報統合部52へ出力する。これにより、超解像画像生成部104は、超解像画像の生成処理をいち早く開始できるようになる。超解像画像の生成に必要十分なシーン解析結果が得られた場合、超解像画像生成部104は、そのことをシーン解析部C50へ通知する。この通知を受けたシーン解析部C50は、高解像度の部分画像に対するシーン解析処理を打ち切り、言い換えれば、処理途中であっても終了する。なお、超解像画像生成部104が超解像画像の生成処理を開始した後も、シーン解析部C50は、より高解像度の部分画像に対するシーン解析処理を継続してもよく、その解析結果を超解像画像生成部104へ補充提供してもよい。
【0057】
また、
図4の(3)に示すように、超解像処理部48(シーン解析部C50)は、シーン解析において、入力画像の離散的な位置からオリジナル解像度でサンプリングした小領域(例えば解析単位粒度の領域)の画像を複数個抽出する。この抽出処理は以下の方針で実行されてもよい。すなわち、離散的な「解析単位粒度の領域」の割り当てにおいて、以下の(a)~(d)の方針のうち少なくとも1つを採用してもよい。(a)後述の
図11に示すように、CU割当情報を使って、1CUにつき、1つの解析単位粒度の領域を割り当てること。
【0058】
(b)後述の
図10に示すシーン解析に関するスコア算出ルールに基づいて、入力画像の複数領域それぞれのスコアを算出する場合、有限個数の「解析単位粒度の領域」の割り当てにおいて、高スコアである画像領域に対して「解析単位粒度の領域」を重点的に割り当てること。(c)後述の
図13に示すシーン解析に関するスコア算出ルール(人肌推定処理)に基づいて、入力画像の複数領域それぞれのスコアを算出する場合、有限個数の「解析単位粒度の領域」の割り当てにおいて、高スコアである画像領域に対して「解析単位粒度の領域」を重点的に割り当てること。(b)(c)では、例えば、相対的に高スコアである画像領域に対して、相対的に低スコアの画像領域より優先して解析単位粒度の領域を割り当ててもよい。また、スコアが高い画像領域ほど優先して解析単位粒度の領域を割り当ててもよい。重点的に割り当てること、または優先的に割り当てることは、相対的に多くの個数の「解析単位粒度の領域」を割り当てることであってもよい。
【0059】
(d)Iフレームにおいては、部分画像あたりの「解析単位粒度の領域」の割り当て総数を引き上げること。割り当て総数を引き上げることは、割り当て総数をその初期値より大きくすることでもよく、Iフレーム以外のフレームに対する割り当て総数より大きくすることでもよい。例えば、超解像処理部48(シーン解析部C50)は、入力された部分画像がIフレームの場合、入力された部分画像がIフレーム以外である場合より、部分画像全体での解析単位粒度の領域の割当数を多くしてもよい。超解像処理部48(シーン解析部C50)は、抽出した複数個の小領域の画像のみでシーン解析を実行する。
図4の(1)~(3)に示す構成によると、シーン解析の負荷が低減され、また、処理時間を抑制することもできる。
【0060】
図5は、機械学習ベースの超解像処理を模式的に示す。ソース画像122は、超解像処理前の画像であり、解像度と画質が相対的に低い画像(実施例では部分画像)である。高画質画像128は、超解像処理後の画像であり、解像度と画質が相対的に低い画像(実施例では部分画像)である。モデル保持部120は、
図3のモデル保持部106に対応する。モデル保持部120は、例えば、オフラインでの機械学習により作成されたモデルを記憶する。
【0061】
オフラインでの機械学習とその学習により作成されるモデルは、以下の(a)~(e)の特徴のうち少なくとも1つを有してもよい。(a)オフライン、かつ、事前に、学習を実行する。(b)学習においては、教師データとして、「超解像処理結果が目指すべき画質の高精細画像」、「その高精細画像におけるシーン解析結果」を利用する。(c)学習および推論(すなわち機械学習プロセッサや深層学習プロセッサを用いた高画質画像の生成)において、「シーン解析結果」も入力する。これにより、ソース画像のみを入力する場合に比べて、モデルの学習収束性を高め、モデルの精度を高め、モデルの肥大化や推論処理時間の増加を抑制し、より的確な超解像処理が可能となる。(d)特に、第1シーン情報と第2シーン情報を、シーン解析に用いて、そのシーン解析結果である特徴量を超解像処理の学習および推論に用いる。これにより、非可逆圧縮符号化による映像クオリティの劣化や、解像度の引き下げ、色空間の縮小等が生じる前の画質を再現可能になる。(e)シーン解析結果の代わりに、シーン情報そのものを、学習および推論に入力することで同様の効果を目指してもよい。
【0062】
シーン解析部124は、
図1のシーン解析部A30、シーン解析部B26、シーン解析部C50およびシーン情報統合部52に対応する。シーン解析部124は、ソース画像122の特徴量を計算し、その特徴量をもとに、従来の超解像よりも大きなローカルサブブロックを複数のカテゴリ(例えば数千のカテゴリ)のいずれかに分類してもよい。例えば、シーン解析部124は、ソース画像122(それに映るコンテンツ)を、空、雲、顔、砂漠、または機械構造に分類してもよい。上記の特徴量は、画像圧縮に伴う好ましくない副作用(ノイズ等)を検出するための特徴量を含んでもよい。
【0063】
機械学習プロセッサ126は、
図3のDNNアクセラレータ108に対応する。機械学習プロセッサ126は、シーン解析部124によるシーン解析の結果をもとに、画像の変換処理や再構成処理を実行する。機械学習プロセッサ126は、アンチエイリアス、シャープネス、ノイズ除去、コントラスト強化のための各種フィルタ処理と解像度変換を実行してもよい。機械学習プロセッサ126は、各種フィルタ、変換、再構成のためのパラメータを、分類されたサブブロック領域ごとに変更してもよい。
【0064】
処理粒度は、オブジェクトを検出するフレームであってもよく、フレームより小さい部分画像であってもよい。また、人または機械学習により予め作成されたアルゴリズムとパラメータの組が用意されてよく、機械学習プロセッサ126は、シーン解析結果に適合するアルゴリズムとパラメータの組を選択してもよい。いくつかのアルゴリズムは、動きベクトル検出と3次元デジタルノイズリダクション(3DNR)のための時間的アプローチを用いるものであってもよい。
【0065】
図6は、深層学習ベースの超解像処理を模式的に示す。モデル保持部130は、
図3のモデル保持部106に対応する。モデル保持部130は、例えば、オフラインでの深層学習により作成されたDNNのモデルを記憶する。オフラインでの深層学習とその学習により作成されるDNNのモデルは、
図5に関連して説明した、オフラインでの機械学習とその学習により作成されるモデルの特徴(a)~(e)のうち少なくとも1つを有してもよい。
【0066】
シーン解析部132は、
図1のシーン解析部A30、シーン解析部B26、シーン解析部C50およびシーン情報統合部52に対応する。シーン解析部132は、ソース画像122の特徴量を計算し、その特徴量をもとに、ローカルサブブロックを複数のカテゴリ(例えば数千のカテゴリ)のいずれかに分類してもよい。例えば、シーン解析部132は、ソース画像122(それに映るコンテンツ)を、空、雲、顔、砂漠、または機械構造に分類してもよい。上記の特徴量は、画像圧縮に伴う好ましくない副作用(ノイズ等)を検出するための特徴量を含んでもよい。
【0067】
深層学習推論プロセッサ134は、
図3のDNNアクセラレータ108に対応する。深層学習推論プロセッサ134は、シーン解析部132によるシーン解析の結果をもとに、画像の変換処理や再構成処理を実行する。深層学習推論プロセッサ134は、典型的には、シーンの分類と画像の変換・再構成のためのDNNモデルを使用する。変形例として、深層学習推論プロセッサ134は、DNNモデルと、別のアルゴリズム(例えば人間ベースのシーン解析アルゴリズムや超解像アルゴリズム)とを組み合わせて使用してもよい。深層学習推論プロセッサ134は、アンチエイリアス、シャープネス、ノイズ除去、コントラスト強化のための各種フィルタ処理を実行してもよい。深層学習推論プロセッサ134は、各種フィルタ、変換、再構成のためのパラメータを、分類されたサブブロック領域ごとに変更してもよい。
【0068】
学習済のDNNモデルは、浮動小数点ベースで学習されている場合でも、整数ベースの推論アクセラレータ用に最適化される。処理粒度は、オブジェクトを検出するフレームであってもよく、フレームより小さい部分画像であってもよい。いくつかのアルゴリズムは、動きベクトル検出と3DNRのための時間的アプローチを用いるものであってもよい。
【0069】
超解像処理の実施方法についてさらに説明する。
超解像処理部48の超解像画像生成部104は、部分画像に対する超解像処理を、その部分画像に対応するシーン情報をもとに実行する。超解像処理部48の超解像画像生成部104は、画像領域(すなわち部分画像に映る内容)に応じて、画像の高精細化を行う処理を動的に切り替えるためにシーン情報を利用する。以下、超解像画像生成部104による処理の事例を説明する。
【0070】
(事例1)
処理対象の画像領域が、絵としてフラットで変化が少ない内容(例えば、雲一つない青空の絵や、舗装が痛んでいない綺麗な道路の路面を遠くから俯瞰した絵)であるとき、超解像画像生成部104は、シャープネス系の画像変換処理の実行量を必要最低限とする。言い換えれば、超解像画像生成部104は、シャープネス系の画像変換処理の実行量を、画像領域が絵としてフラットで変化が少ない内容でないときよりも少なくする。画像領域が絵としてフラットで変化が少ない内容である場合、シャープネス系処理の効果が大きい。そのため、人工的なフィルタ処理結果が目立ちやすく、言い換えれば、人工的なフィルタ処理による逆効果が目立ちやすいからである。
【0071】
(事例2)
処理対象の画像領域が、絵として高密度で断続的な変化をもつ内容(例えば、森を遠くから俯瞰した絵)であるとき、超解像画像生成部104は、シャープネス系の画像変換処理を積極的に行う。言い換えれば、超解像画像生成部104は、シャープネス系の画像変換処理の実行量を、画像領域が絵として高密度で断続的な変化をもつ内容でないときよりも増加させる。画像領域が絵として高密度で断続的な変化をもつ内容である場合、シャープネス系処理の効果が表れにくいうえ、人工的なフィルタ処理による逆効果が目立ちにくいからである。
【0072】
(事例3)
処理対象の画像領域が、絵としてはっきりとした線や点などをもつ内容(例えば、輪郭がはっきりしている複雑な形状の人工的な物体や文字)であるとき、超解像画像生成部104は、シャープネス系の画像変換処理を抑制する。超解像画像生成部104は、シャープネス系の画像変換処理をスキップしてもよい。画像領域が絵としてはっきりとした線や点などをもつ内容である場合、シャープネス系処理の効果が弱く、人工的なフィルタ処理による逆効果が非常に目立ちやすいからである。このような画像領域においては、超解像画像生成部104は、線や点の種類に応じた専用の輪郭補正処理を行うことが好ましい。
【0073】
(事例4)
処理対象の画像領域が、大きな移動量で動く物体(例えば車両等)をもつとき、人の動体視力を鑑みると、物体表面領域の高精細化処理を行うメリットが低い場合がある。しかし、物体の端に画像圧縮起因の輪郭破綻系ノイズが含まれていると、人は認識しやすい。そのため、超解像画像生成部104は、処理対象の画像領域に輪郭破綻系ノイズを検出した場合、輪郭破綻系ノイズに特化した画像変換処理を実行する。
【0074】
(事例5)
人は、画像に映る人物の、肌の色合いや顔の表情を認識する能力が高い。そのため、超解像画像生成部104は、処理対象の画像領域が人物を含むことを検出した場合、人物に特化した画像変換処理(フィルタ処理)を実行する。
【0075】
上記の複数の事例に記載したような、判定ルールと、それに対して行うフィルタ処理や変換処理の組を多数定義してもよい。これらの組は、テーブル、データベース、モデルとして実装されてもよい。そして、これらの組に対して様々な入力条件を与え、フィルタ処理や変換処理の結果を学習し、また最適化してもよい。その結果、シーン情報と入力画像内容に基づいて、超解像画像の生成内容が切り替わる処理系を実現できる。
【0076】
なお、超解像画像生成部104は、シーン情報(第1~第3シーン情報)のみに基づいて、実行する画像変換内容(フィルタ処理や変換処理の内容)を決定してもよい。また、超解像画像生成部104は、シーン情報と入力画像(部分画像)に基づいて、実行する画像変換内容を決定してもよい。いずれの方法を採るかに応じて、テーブル、データベース、またはモデルを変更してもよい。
【0077】
図3に戻り、超解像処理部48による超解像処理をさらに説明する。シーン情報統合部52は、シーン解析単位粒度(例えば
図4に示した解析単位粒度)毎のシーン情報を、超解像画像生成部104に出力する。シーン情報統合部52は、過去フレームまたは過去部分画像におけるシーン情報を蓄積し、最新のフレームまたは最新の部分画像におけるシーン情報を構築する際に参照してもよい。超解像画像生成部104は、シーン解析単位粒度と同じ粒度で処理を進めてもよく、それ以外の粒度で処理を進めてもよい。
【0078】
超解像画像生成部104は、シーン情報に基づいて、モデル保持部106に記憶された複数のモデルの中で、利用するモデルを切り替えてもよい。また、超解像画像生成部104は、モデルの切替時間を隠蔽するために、(1)複数のモデルを予めモデル保持部106にロードしてもよく、(2)複数のDNNアクセラレータを起動してもよく、(3)予めロードしたモデルと、予め起動したDNNアクセラレータの少なくとも一方を動的に切り替えてもよい。超解像画像生成部104が利用するモデルは、予め、様々な条件のシーン情報と入力画像に対応できるように学習および構築されてもよい。これにより、シーン情報に応じたモデル切替を抑制し、またはモデル切替時間を抑制してもよい。超解像処理制御部110は、シーン情報(シーン解析結果)と、対となる画像(部分画像)とを紐づけるために、識別子などを使ってもよい。
【0079】
図7は、部分画像単位のパイプライン処理の概念図である。上述の通り、サーバ12は、動画像のフレーム140を所定または可変のレートで生成する。図示の例では、フレーム140は、左右に二等分した領域に左目用、右目用の画像をそれぞれ表した構成を有するが、サーバで生成する画像の構成をこれに限る趣旨ではない。
【0080】
上述の通り、サーバ12は、フレーム140を部分画像ごとに圧縮符号化する。
図7では画像平面を水平方向に5分割し、部分画像142a、142b、142c、142d、142eとしている。
図7では、部分画像142a、142b、142c、142d、142eはこの順で次々に圧縮符号化され、矢印に示すようにクライアント端末14へ順次伝送され表示される。すなわち最上段の部分画像142aに対し、圧縮符号化、送信、復号伸張、表示パネル56への出力といった処理が施されている間に、その下の部分画像142b、さらに下の部分画像142c、というように順次部分画像が伝送され表示される。これにより、画像の描画から表示までに必要な各種処理を並列に実施でき、転送時間が介在しても最低限の遅延で表示を進捗させることができる。
【0081】
図8も、部分画像単位のパイプライン処理の概念図である。同図は、本出願人による過去の出願(特願2019-213536)の
図6を引用したものである。同図は、サーバ12における画像生成から、クライアント端末14における画像表示までの処理タイミングを示している。
図8には不図示だが、本実施例のクライアント端末14では、復号伸長処理と表示処理との間に、超解像処理部の処理時間が追加される。一方、復号伸長部44の符号化方法取得部46の処理時間は、この処理を復号伸長処理のバックグラウンド処理として実行することで隠蔽することができる。サーバ12においても、シーン解析部A30、シーン解析部B26、シーン情報取得部32の処理時間は、これらの処理を圧縮符号化部28による圧縮符号化処理のバックグラウンドで実行することで隠蔽することができる。また、データ取得部42からシーン情報統合部52へシーン情報を出力する処理も、復号伸長部44による復号伸長処理のバックグラウンド処理として実行できる。
【0082】
図9は、ゲームアプリケーションが保持するシーン情報の例を示す。ゲームアプリケーション(言い換えればゲームアプリケーションを実行する内容決定部20および画像生成部22)は、フレームを描画する過程において、内部データとして、(1)各オブジェクトの色情報、(2)各オブジェクトの動きベクトル情報、(3)オブジェクト配置に関する奥行き情報、(4)各オブジェクトの反射てかり強度情報を生成する。ゲームアプリケーションを実行する内容決定部20および画像生成部22は、これらの内部データをバッファ24(レンダリングバッファ)に格納する。シーン解析部A30およびシーン解析部B26は、バッファ24(レンダリングバッファ)に格納された上記(1)~(4)のデータをシーン情報として取得してもよい。本明細書における「てかり」は、「ハイライト」とも呼ばれる。なお、
図9に示すようなアプリケーションが持つ描画内部データは、アプリケーションが最終描画結果を生成する前から存在するデータであり、アプリケーションが最終描画結果を生成する際に参照されるデータである。
【0083】
また、実施例の情報処理システム10では、超解像処理の前に、上記(1)~(4)のデータを参照してシーン解析(例えばシーンセグメンテーション等)を予め実行する。これにより、処理遅延の削減や、シーン解析精度の向上を実現する。なお、
図9に示す例では、例えば、手前にある動きが激しい物体の位置や、光が当たっている物体の位置、暗所で画像がつぶれている位置(物体の識別が困難な位置)等のシーン情報も得られる。
【0084】
図10は、シーン解析の例を示す。サーバ12のシーン解析部A30、シーン解析部B26、クライアント端末14のシーン解析部C50のうち少なくとも1つは、特願2019-179439および特願2019-179440に記載されたパラメータ群とスコア算出ルールを用いて、シーン解析を実行してもよい。
図10は、特願2019-179439の
図27~
図31を示している。
【0085】
シーン解析(例えばゲーム描画内容の判定)に用いるパラメータは、以下の項目の少なくとも1つを含んでもよい。(1)オプティカル・フローの量(例えば、どの方向に画素が動いているか、および画素領域が動く速さ)。(2)エンコードMotion Estimation(ME)の量(例えば、どの方向に矩形領域が動いているか、および矩形領域が動く速さ)。(3)エンコードCU割当の粒度(例えば、CUの大きさ)。(4)シーン切り替えか否か(例えば、エンコードIフレームを挿入する場所か否か)。
【0086】
(5)画面を占める画像テクスチャ種類(エッジ領域、フラット領域、またはHigh Density/Detail/Crowd領域等)。このテクスチャ種類は、3D描画に用いているテクスチャ種類ではなく、描画結果の2次元画像に分布するテクスチャ種類である。(6)ハリス・コーナー特徴点やエッジの量(例えば、特徴点やエッジがある座標、およびエッジ強度等)。(7)深度データ(例えば、各画素の奥行き情報、または3DゲームにおけるZ値等。(8)オブジェクト量(例えば、椅子や車といった物体の量や、物体が画面に占める大きさ)。(9)3D描画にて用いているMipmapテクスチャの各レベルの使用量。
【0087】
(10)3D描画にて用いているLOD(Level of Detail)。(11)テッセレーションの各レベルの使用量。(12)文字や記号の量。(13)描画シーン種類。この種類は、例えば、メニュー、設定、ローディング画面、主観視線描画、俯瞰視線描画、2次元ドット絵ゲーム、3次元描画ゲーム、ファースト・パーソン・シューティングゲーム、レースゲーム、スポーツゲーム、アクションゲーム、シミュレーションゲーム、アドベンチャー・ノベルゲームのいずれかであってもよい。
【0088】
また、スコア算出ルールは、特願2019-179439および特願2019-179440に記載されたように、例えば、(1)画像上の像の大きさに基づくスコア算出ルール、(2)オブジェクトの細かさに基づくスコア算出ルール、(3)コントラスト、ダイナミックレンジに基づくスコア算出ルール、(4)像の動きに基づくスコア算出ルール、(5)テクスチャの種類に基づくスコア算出ルールのいずれかであってもよい。また、スコア算出ルールは、(6)解像度重視のスコア算出ルール、(7)フレームレート重視のスコア算出ルール、(8)量子化パラメータ(QP)値重視のスコア算出ルールであってもよい。サーバ12のシーン解析部A30、シーン解析部B26、クライアント端末14のシーン解析部C50のうち少なくとも1つは、超解像処理部48の内部処理における単位領域毎または部分画像毎にスコアを算出してもよい。
【0089】
さらにまた、サーバ12のシーン解析部A30、シーン解析部B26、クライアント端末14のシーン解析部C50のうち少なくとも1つは、特願2019-037907と同様のパラメータを用いてシーン解析を実行してもよい。このパラメータは、入力ビデオ画像(例えば部分画像)から得られる特徴量と、入力ビデオ画像の圧縮符号化時(例えばAVC/HEVCエンコーダ)に得られる特徴量の少なくとも一方を含んでもよい。
【0090】
入力ビデオ画像から得られる特徴量は、以下の(1)~(5)の少なくとも1つを含んでもよい。(1)画像のテクスチャ種類(エッジ領域、フラット領域、またはHigh Density/Detail/Crowd領域等)。(2)ハリス・コーナー特徴点やエッジの量(例えば、特徴点やエッジがある座標、およびエッジ強度等)。(3)オプティカル・フロー(例えば、どの方向に矩形領域が動いているか、および矩形領域が動く速さ)。(4)深度データ(例えば、各画素の奥行き情報)。(5)画像認識により物体を検出した結果(例えば、椅子や車がある座標領域の情報)。
【0091】
入力ビデオ画像の圧縮符号化時に得られる特徴量は、以下の(1)~(6)の少なくとも1つを含んでもよい。(1)Motion Estimation(ME)情報(例えば、どの方向に矩形領域が動いているか、および矩形領域が動く速さ)。(2)CU割当情報(例えば、CUの大きさ)。(3)Resion of Interest(ROI)領域の情報。ROI領域は、注目領域または関心領域とも呼ばれ、例えば、高画質化のため高ビットレートを割り当てた画像領域である。(4)使用した量子化パラメータ(QP)の情報。(5)シーン切替であるか否か。(6)キーフレーム(例えば、Iフレーム)であるか否か。
【0092】
図11は、CU割当情報の例を示す。同図のCU割当情報は、色の変化が大きい領域ほど小さい符号化単位ブロックが割り当てられたことを示している。例えば、シーン解析部A30は、CU割当情報をもとに色の変化が大きい領域を検出してもよく、シーン情報取得部32は、色の変化が大きい領域を示す第1シーン情報を生成してもよい。クライアント端末14の超解像処理部48は、部分画像の第1シーン情報が示す当該部分画像の色の変化が大きい領域に基づいて超解像処理を実行してもよい。
【0093】
図12は、シーン解析手法の例を示す。同図は、シーンセグメンテーションによって画像に映るオブジェクトの種類を抽出することを示している。例えば、サーバ12のシーン解析部A30、シーン解析部B26、クライアント端末14のシーン解析部C50のうち少なくとも1つは、公知のテンプレートマッチング等の手法により、
図12の画像144を、空、樹木、車、建物、道路、車線等の領域に分類してもよい。
【0094】
図13も、シーン解析手法の例を示す。サーバ12のシーン解析部A30、シーン解析部B26、クライアント端末14のシーン解析部C50のうち少なくとも1つは、公知の人肌領域推定処理を実行して画像の特徴量を抽出してもよい。
図13の網掛けで示す領域は、人肌として推定された領域を示している。人肌領域推定処理は、入力画像内の複数領域それぞれのスコアを算出してもよい。人肌領域推定処理におけるスコア算出ルールは、人肌として推定された領域に対して、人肌として推定されなかった領域より高いスコアを割り当てるものであってもよい。
【0095】
図14も、シーン解析手法の例を示す。
図14は、ビデオ圧縮ノイズを検出する例を示している。サーバ12のシーン解析部A30、シーン解析部B26、クライアント端末14のシーン解析部C50のうち少なくとも1つは、画像からビデオ圧縮ノイズを検出し、ビデオ圧縮ノイズを画像の特徴量として抽出してもよい。同図の出典は、“Local estimation of video compression artifacts” 2011 IEEE International Conference on Consumer Electronics (ICCE)、である。
【0096】
超解像画像生成部104は、
図14に示したようなアーティファクト(artifact)強度を参照してもよい。アーティファクト強度は、圧縮アーティファクトの強度と言え、非可逆圧縮の適用によって引き起こされた画像劣化(画像の歪み等)の度合いを示すデータである。超解像画像生成部104は、超解像処理において、ノイズによる画像劣化が激しい領域については、機械学習結果に基づき、平滑フィルタの強度をあげてもよい。例えば、超解像画像生成部104は、アーティファクト強度が予め定められた閾値未満の領域に対して第1の強度の平滑化処理を実行し、アーティファクト強度が上記閾値未満の領域に対して、第1の強度より強い第2の強度の平滑化処理を実行してもよい。また、超解像画像生成部104は、アーティファクト強度が強い領域ほど、強い平滑化処理を実行してもよい。
【0097】
超解像処理において判断材料とするシーン情報の例を説明する。サーバ12のシーン解析部A30、シーン解析部B26、クライアント端末14の符号化方法取得部46、シーン解析部C50のうち少なくとも1つは、(1)ユーザ・インタラクション重視のシーンであるか否かを示すシーン情報、(2)シーンの内容または画像の種類を示すシーン情報、(3)現在の描画手法を示すシーン情報の少なくとも1つを取得してもよい。クライアント端末14の超解像処理部48は、これら(1)~(3)のシーン情報の少なくとも1つを用いて超解像処理を実行してもよい。
【0098】
(1)のシーン情報は、以下の情報の少なくとも1つを含んでもよい。
(1-1)描画内容が、ユーザー操作の入力を必要としないムービーシーン(プリ・レンダリング)やローディング待ち、またはセットアップ待ちであることを示す情報。
(1-2)描画内容が、ユーザー操作の入力を必要とするゲームプレイシーン(リアルタイム・レンダリング)であることを示す情報。
(1-3)描画内容が、ユーザー操作の入力を必要とするゲームプレイシーンであったとき、ユーザー入力をサンプリングしている頻度を示す情報。
(1-4)描画内容が、ユーザー操作の入力を必要とするゲームプレイシーンであったとき、ゲーム種別(カテゴリ等)を示す情報。例えば、ドライブゲーム、シューティングゲーム、アクション格闘ゲーム、ストラテジーゲーム、シミュレーションゲーム等。
【0099】
(2)のシーン情報は、以下の情報の少なくとも1つを含んでもよい。
(2-1)GUIシーン(例えばメニューシーン)であること、ゲームシーンであること、または他のビデオストリーム・アプリケーションであることを示す情報。
(2-2)カメラ撮影自然画像であること、CG(Computer Graphics)画像であること、またはアニメ系画像であることを示す情報。
【0100】
(3)のシーン情報は、描画時のオリジナル設定、および、圧縮符号化・転送における設定に関するシーン情報とも言える。
(3)のシーン情報は、以下の情報の少なくとも1つを含んでもよい。
(3-1)描画解像度、フレームレート、および描画ビットカラー深度。
(3-2)レンダリング手法に関する情報。例えば、レイトレーシング利用しているか。レイトレーシング手法を適用している画像領域や物体配置。フォグ処理を使用有無と使用領域。バンプマッピングの使用有無と使用領域。反射処理の使用有無と使用領域。Motion Blur効果(物体をぼやかす処理)の使用有無と使用領域。
(3-3)レンダリングにおけるテクスチャフィルタリング処理内容、またはテクスチャ圧縮手法。
【0101】
(3-4)非可逆フレームバッファ圧縮を用いている場合の圧縮手法。
(3-5)描画アンチエイリアシング手法。例えば、フィルタ構成、フィルタタップ数、フィルタ係数、画像における輪郭や微細模様に特化した処理の有無。
(3-6)解像度変換を行う場合の解像度変換手法。例えば、フィルタ構成、フィルタタップ数、フィルタ係数、画像における輪郭や微細模様に特化した処理の有無。
(3-7)描画ダイナミックレンジ、HDR(High-Dynamic-range Rendering)プロファイル、またはトーンマッピング手法。例えば、GPU描画において、浮動小数点演算結果からフレームバッファ出力へ落とし込むときの丸め込みなどを含むマッピング手法、または計算手法。また例えば、元々描画処理過程において持っていたダイナミックレンジの情報と、フレームバッファ出力におけるダイナミックレンジの情報。
【0102】
(3-8)描画のディザリング手法の情報。
(3-9)利用している圧縮符号化の手法の情報。例えば、マクロブロック割当方法。スライス割当方法。係数。デノイズフィルタ種別係数。インター圧縮(フレーム間圧縮)を用いているかの情報。圧縮規格(例えばAVC、HEVC、VP9、AV1、DSC等)の情報。可逆または不可逆かの情報。ビット深度。量子化パラメータ(QP)。レート制御手法。ターゲットビットレート。IDR方式とGDR方式のいずれであるかを示す情報。
【0103】
一部既述したように、超解像処理部48は、ゲームアプリケーションから取得されたシーン情報であって、超解像処理に至るまでのサーバ12またはクライアント端末14における前段処理で取得されたシーン情報に基づいて、超解像処理の簡易化または未実行を選択してもよい。超解像処理部48は、シーン情報に基づいて、超解像処理による高画質化と、低遅延性のいずれを重視するかを判定してもよい。
【0104】
<第2実施例>
以下、第2実施例について、第1実施例と相違する構成を中心に説明し、共通する構成の説明は適宜省略する。第2実施例の構成要素のうち第1実施例の構成要素と同一または対応する構成要素には同じ符号を付している。第2実施例の構成は、第1実施例および変形例の構成と任意の組合せが可能であることはもちろんである。
【0105】
第2実施例は、画像の表示を制御する情報処理装置(第2実施例ではゲームコンソール)が、画像の生成も行う点で第1実施例と異なる。第2実施例のゲームコンソールは、第1実施例のクライアント端末14に対応するが、第1実施例のクライアント端末14とは異なり、画像の生成、画像の超解像処理、超解像画像の表示制御を単体で実行する。なお、第2実施例以降の技術思想は、ゲームコンソールに制限されず、画像を処理する種々の情報処理装置に適用できる。
【0106】
図15は、第2実施例のゲームコンソール200の構成を示すブロック図である。ゲームコンソール200は、内容決定部20、画像生成部22、バッファ24、シーン解析部B26、シーン情報取得部32、超解像処理部48、表示制御部54、表示パネル56を備える。超解像処理部48は、シーン解析部C50とシーン情報統合部52を含む。ゲームコンソール200は、第1実施例のサーバ12とクライアント端末14が備えた機能のうち、圧縮符号化および復号伸長に関連する機能は備えない。
図15に示す各機能ブロックの詳細は説明済みであるため、再度の説明を省略する。
【0107】
図16と
図17も、第2実施例のゲームコンソール200の構成を示すブロック図である。
図16は、前段の処理に関する機能ブロックを示し、
図17は、
図16に続く処理に関する機能ブロックを示している。
【0108】
図16に示すように、第2実施例のゲームコンソール200は、CPU201、GPU202、DRAM(Dynamic Random Access Memory)204、超解像処理部48を備える。超解像処理部48は、シーン解析部C50、SRAM(Static Random Access Memory)206、アダプティブ解像度変換部208、学習パラメータテーブル210、超解像画像生成部104、モデル保持部106を含む。本明細書のブロック図に示すDRAM、SRAMの配置は論理的なものであり、物理的なDRAM、SRAMの個数に制限はない。例えば、ブロック図の複数のDRAM、SRAMは、物理的には同一のDRAM、SRAMにより実現されてもよい。
【0109】
DRAM204は、ゲームアプリケーションの画像に関する各種データを記憶する。DRAM204は、第1実施例のバッファ24および部分画像記憶部90に対応する。具体的には、DRAM204は、フレーム220、メタ情報222、他画面データ224、過去フレーム226を記憶する。フレーム220は、実行中のゲームアプリケーションにより生成された画像データであり、言い換えれば、ゲームコンテンツの映像データである。GPU202は、第1実施例の画像生成部22および画像描画部62に対応する。GPU202は、フレーム220を生成し、フレーム220をDRAM204に格納する。
【0110】
メタ情報222は、第1実施例のシーン解析部B26による解析結果としてのシーン情報(例えばフレーム220の描画内容を示す情報)を含み、また、第1実施例の内容決定部20から得られるシーン情報(例えば3Dオブジェクトの配置状態や、利用テクスチャ特性、シーンセグメンテーション情報)を含む。メタ情報222は、CPU201(内容決定部20)とGPU202の一方または両方で生成されてもよい。サーバがない場合、メタ情報222は、ゲームコンソール200のCPU201(内容決定部20)やシーン解析部B26から得られた、第1シーン情報を含んでもよい。
【0111】
他画面データ224は、ゲームコンソール200におけるゲームアプリケーション以外の画像データである。他画面データ224は、(a)ゲームコンソール200のシーン解析部B26から得られた第1シーン情報、(b)ゲームコンソール200の画像生成部22が生成した、
図9の描画内部データや第1シーン情報、および、(c)後述のUIプレーン236等を含んでもよい。他画面データ224は、これら(a)~(c)の総称である。
【0112】
過去フレーム226は、実行中のゲームアプリケーションの過去表示された画像のデータである。過去フレーム226は、断続的に生成され続けるフレーム220における過去に生成された超解像処理前のフレーム220であってもよく、もしくは、超解像処理後にディスプレイインタフェース248から出力したデータを図示しないデータパスでDRAMに書き戻したフレームであってもよい。
【0113】
DRAM204のメタ情報222、他画面データ224、過去フレーム226のそれぞれは、スライス単位に超解像処理部48へ入力される。図示しないが、他画面データ224と過去フレーム226は、シーン解析部C50やアダプティブ解像度変換部208に入力されてもよい。シーン解析部C50やアダプティブ解像度変換部208に入力された他画面データ224と過去フレーム226に基づいて、追加データとしての画像特徴情報228、Yスライス230、UVスライス232、メタ情報222がSRAM206に生成されてもよい。SRAM206に生成されたこれらの追加データは、必要に応じて超解像画像生成部104に追加入力されてもよい。
【0114】
シーン解析部C50は、オプショナルな機能ブロックであり、DRAM204に記憶されたメタ情報222を参照し、公知技術を用いて超解像処理の前段処理としてのシーン解析処理を実行する。シーン解析部C50は、第1実施例のシーン解析部B26と同等のシーン解析処理を実行してもよい。シーン解析部C50は、シーン解析結果(シーン情報)をアダプティブ解像度変換部208に渡すとともに、シーン解析結果(シーン情報)を画像特徴情報228としてSRAM206に格納する。なお、第2実施例のシーン情報は、圧縮符号化および復号伸長に関連する内容が除外される以外、第1実施例のシーン情報と同様の内容を含んでもよい。
【0115】
SRAM206は、第1実施例の部分画像記憶部102に対応する。SRAM206は、画像特徴情報228を記憶し、Yスライス230、UVスライス232、メタ情報222をさらに記憶する。メタ情報222は、DRAM204から転送される。メタ情報222には、シーン解析部C50から得られた第3シーン情報が追加されてもよい。Yスライス230とUVスライス232は、フレーム220の部分画像であるスライス(実施例ではYUV形式)に関するデータである。Yスライス230は、スライスのY成分のデータである。UVスライス232は、スライスのUV成分のデータである。Y成分は、輝度成分または輝度信号と言える。UV成分は、色差成分と言え、輝度信号と青色成分の差(U)と、輝度信号と赤色成分の差(V)とを含む。UV成分は、色相成分および彩度成分と言うこともできる。
【0116】
学習パラメータテーブル210は、スライスの内容を複数のカテゴリの中のいずれかに分類するために参照されるパラメータであり、機械学習により作成されたパラメータを保持するテーブルである。
【0117】
アダプティブ解像度変換部208は、第1実施例の解像度変換部100に対応し、DRAM204に記憶されたフレーム220のデータをスライス単位で読み出し、読み出したスライスに対するアダプティブ解像度変換を実行する。アダプティブ解像度変換は、第1実施例の解像度変換部100と同様に、スライスを高解像度化する処理を含む。
【0118】
また、アダプティブ解像度変換は、シーン解析部C50から入力されたシーン情報と、学習パラメータテーブル210に記憶されたパラメータとに基づいて、DRAM204から読み出したスライスのサブブロック(例えば4×4画素や8×8画素のプリミティブ領域)を、複数のカテゴリの中のいずれかに分類する処理を含む。複数のカテゴリは、数十から数百のカテゴリを含んでもよい。例えば、複数のカテゴリは、エッジ領域(例えば画素値の変化量が大きい領域)、詳細領域(例えば画素値が細かく変化する領域)、フラット領域(例えば画素値の変化量が小さい領域)を含んでもよい。
【0119】
アダプティブ解像度変換部208は、スライスのサブブロックのカテゴリに応じて、当該スライスのサブブロックに対してアンチエイリアス、シャープネス、ノイズ除去、コントラスト強調の少なくとも1つに関連するフィルタを適用してもよい。例えば、エッジ領域に分類したサブブロックに対して、シャープネスを弱めるフィルタを適用してもよい。また、詳細領域に分類したサブブロックに対して、シャープネスを強めるフィルタを適用してもよい。また、フラット領域に分類したサブブロックに対して、シャープネスを最小化するフィルタを適用してもよい。
【0120】
アダプティブ解像度変換部208は、アダプティブ解像度変換後のスライスのY成分をSRAM206に格納する(Yスライス230)。また、アダプティブ解像度変換部208は、アダプティブ解像度変換後のスライスのUV成分をSRAM206に格納する(UVスライス232)。第2実施例では、GPU202がYUV形式のフレーム220を生成するが、変形例として、GPU202はRGB形式のフレーム220を生成してもよい。この場合、アダプティブ解像度変換部208は、RGB形式のフレーム220をYUV形式に変換後、変換後のフレームからスライスデータを読み出してもよい。
【0121】
モデル保持部106は、スライスのY成分に対する超解像処理のためのモデルを記憶する。典型的には、モデル保持部106は、シーンの分類と画像の変換・再構成のためのDNNモデルを記憶する。変形例として、モデル保持部106は、DNNモデルと、別のアルゴリズム(例えば人間ベースのシーン解析アルゴリズムや超解像アルゴリズム)とを組み合わせて記憶してもよい。
【0122】
超解像画像生成部104は、SRAM206からYスライス230を読み出す。超解像画像生成部104は、SRAM206に記憶された画像特徴情報228およびメタ情報222と、モデル保持部106に記憶されたモデルとに基づいて、Yスライス230に対する超解像処理(高画質化等)を実行する。超解像画像生成部104は、DNNアクセラレータ108と制御MCU(Micro Control Unit)212を含む。制御MCU212は、第1実施例の超解像処理制御部110に対応する。制御MCU212は、例えば、短冊状画像パイプライン処理、超解像アルゴリズムの小粒度DMA(Direct Memory Access)およびアルゴリズムの切替処理を実行してもよい。
【0123】
また、超解像画像生成部104は、Yスライス230に対する超解像処理において、DRAM204に格納された他画面データ224と過去フレーム226を参照してもよい。例えば、超解像画像生成部104は、他画面データ224と過去フレーム226を参照して、処理対象のYスライス230に描かれた物体の動きや、処理対象のYスライス230に含まれるノイズを検出してもよい。超解像画像生成部104は、Yスライス230に描かれた物体の動きに基づいて、超解像処理のアルゴリズム(フィルタ等)を切り替えてもよい。また、超解像画像生成部104は、超解像処理において、Yスライス230に含まれるノイズを打ち消してもよい。
【0124】
超解像画像生成部104は、ゲームアプリケーションやOSが描画するメニューUIや字幕等が、どのような種別の画像か、どのような形状であるか、どのような画像座標位置に描画されているかといった情報を、超解像画像生成部104に入力されるいずれかのデータ(228,230,232,224,226等)から取得してもよい。超解像画像生成部104は、取得した上記情報に基づいて、Yスライス230に対する超解像処理を切り替えてもよい。例えば、超解像画像生成部104は、メニューUIや字幕の画像領域に対する超解像処理として、DNNモデルの学習結果に基づいて、エッジが破壊されにくい超解像処理を選択してもよい。
【0125】
超解像画像生成部104は、Yスライス230に対する超解像処理の結果(後述のSR-Yスライス234)を後述のSRAM240に格納する。一方、超解像画像生成部104は、SRAM206に記憶されたUVスライス232に対する超解像処理をスキップする。SRAM206に記憶されたUVスライス232は、超解像処理が施されることなく、後述のSRAM240に転送される。
【0126】
図17に示すように、第2実施例のゲームコンソール200は、SRAM240、DRAM242、解像度変換部244、オーバレイ部246、ディスプレイインタフェース248をさらに備える。
【0127】
SRAM240は、第1実施例の部分画像記憶部92に対応する。SRAM240は、超解像処理部48により生成されたSR-Yスライス234と、超解像処理の対象外であるUVスライス232を記憶する。
【0128】
GPU202は、ゲームコンテンツ以外の画像であり、ユーザの操作に関連するユーザインタフェース(UI)の画像であるUIプレーン236をさらに生成する。GPU202は、生成したUIプレーン236をDRAM242に格納する。UIプレーン236は、既述したように他画面データ224の一種であり、ゲームアプリケーションが生成するゲームの各種メニューを示す画像や、ゲームに対する各種設定用の画像を含む。また、UIプレーン236は、ゲーム等のアプリケーションとは独立して、ゲームコンソール200のOS(Operating System)が生成するUIの画像を含む。OSが生成するUIは、例えば、アプリケーションの切替や終了のための画像、ダウンロードの完了通知の画像、フレンド情報を示す画像等を含む。
【0129】
解像度変換部244は、アダプティブ解像度変換部208による処理結果の画像と同等の解像度になるようUIプレーン236に対する解像度変換処理を実行してもよい。オーバレイ部246は、SRAM240に記憶されたSR-Yスライス234およびUVスライス232と、解像度変換部244による解像度変換後のUIプレーン236とをオーバレイ(言い換えれば合成)し、すなわち、ゲームコンテンツの画像とUIの画像の両方を含む1つのスライス画像(すなわち部分画像)を生成する。
【0130】
同一のフレーム220(スライス)から抽出されたYスライス230およびUVスライス232と、超解像処理後のSR-Yスライス234には、同一のID(例えば同一のフレームIDおよびスライスID)が付与される。SRAM240におけるUVスライス232を保持する時間には、そのUVスライス232に対応するYスライス230に対する超解像処理の時間が追加される。対応するYスライス230は、同一のスライスを起原とするYスライス230であり、言い換えれば、同一のIDが付与されたYスライス230である。オーバレイ部246は、同一のIDが付与されたSR-Yスライス234とUVスライス232とを合成する。
【0131】
すなわち、SRAM206における、画像特徴情報228、Yスライス230、メタ情報222のバッファリング量は、超解像画像生成部104が必要とする入力データが途切れない量(言い換えればアンダーフローを起こさない量)である。また、SRAM240におけるSR-Yスライス234のバッファリング量は、オーバレイ部246が必要とする入力データが途切れない量(言い換えればアンダーフローを起こさない量)である。
【0132】
一方、UVスライス232のバッファリング量は、更に同一のスライスを起原とするYスライス230に対する超解像処理が終了し、同一のスライスを起原とするSR-Yスライス234とUVスライス232のYUV成分をオーバレイ部246で合体するタイミングとなるまでデータを保持する量とする。つまり下記の式が成り立つようにする。
SRAM206におけるYスライス230の保持時間+超解像画像生成部104のYスライス処理時間+SRAM240におけるSR-Yスライス234の保持時間=SRAM240におけるUVスライス232の保持時間
このようなバッファリングにおいて、同一のスライスを起原とするYスライス230とUVスライス232に同一のIDを付与することで同期処理を実現する。
【0133】
ディスプレイインタフェース248は、第1実施例のディスプレイコントローラ84に対応する。ディスプレイインタフェース248は、オーバレイ部246により順次生成された複数のスライス画像を順次表示パネル56(ディスプレイ86)に表示させる。
【0134】
第2実施例のゲームコンソール200によると、第1実施例のクライアント端末14と同様に、スライスを単位として超解像処理を実行し、超解像処理がなされたスライスを順次表示させることにより、超解像処理の遅延を抑制できる。また、ゲームコンソール200は、スライスのY成分に超解像処理を行う一方で、スライスのUV成分には超解像処理を行わない。これにより、超解像処理に要する計算量や時間を低減でき、また、ゲームコンソール200のハードウェアリソース量を低減できる。
【0135】
また、ゲームコンソール200は、UIプレーン236に対する超解像処理を行わず、コンテンツフレームの超解像処理の後にUIプレーン236を合成する。これにより、UIプレーン236に対する超解像処理による副作用(例えばジャギーの発生等)を回避できる。なお、第2実施例で説明したスライスのY成分のみに対して超解像処理を行う構成や、UIプレーン236に対する超解像処理を回避する構成は、第1実施例のクライアント端末14にも適用可能である。
【0136】
<第3実施例>
以下、第3実施例について、第2実施例と相違する構成を中心に説明し、共通する構成の説明は適宜省略する。第3実施例の構成要素のうち既述の実施例の構成要素と同一または対応する構成要素には同じ符号を付している。第3実施例の構成は、他の実施例および変形例の構成と任意の組合せが可能であることはもちろんである。
【0137】
図18は、第3実施例のゲームコンソールの構成を示すブロック図である。第3実施例のゲームコンソール200は、
図16と
図17で示した第2実施例のゲームコンソール200が備える機能ブロックに加えて、通信部40、DRAM252、デマルチプレクサ254、DRAM256、ビデオデコーダ258を備える。第3実施例では、ゲームアプリケーションの描画は、サーバーのみで完結しなくてもよく、ゲームコンソール200が追加の描画を実行してもよい。また、第3実施例では、ゲームアプリケーションとは異なる他のアプリケーションやOSが追加の描画を実行してもよい。
【0138】
通信部40は、サーバ12からストリーミング送信されたビデオストリーム260を受け付け、受け付けたビデオストリーム260をDRAM252に格納する。ビデオストリーム260は、超解像処理の対象となるスライスのデータを含む。ビデオストリーム260は、後述のビデオペイロード262、音声ペイロード264、スライス266を含む。通信部40は、Wi-Fi(登録商標)、ギガビット・イーサネット(「イーサネット」は登録商標)、DMA等の通信機能を含んでもよい。通信部40は、公知の無線通信または有線通信を介してビデオストリーム260を取得してもよい。または、通信部40は、所定のメモリに格納されたビデオストームをDMAにより取得してもよい。
【0139】
デマルチプレクサ254は、DRAM252に格納されたビデオストリーム260からビデオペイロード262、音声ペイロード264、メタ情報222を抽出し、抽出したビデオペイロード262、音声ペイロード264、メタ情報222をDRAM256に格納する。
【0140】
DRAM256は、ビデオペイロード262、音声ペイロード264、メタ情報222を記憶する。メタ情報222は、超解像処理のヒント情報とも言え、第1実施例においてサーバ12からクライアント端末14へ提供されるシーン情報を含んでもよく、例えば、スライスの圧縮符号化に関連するシーン情報を含んでもよい。また、メタ情報222は、サーバが生成した第1シーン情報と第2シーン情報も含んでもよい。
【0141】
ビデオデコーダ258は、第1実施例の復号伸長部44、ビデオデコーダ82に対応する。ビデオデコーダ258は、DRAM256に記憶されたビデオペイロード262を復号伸長し、復号伸長後のデータ(スライス266)をDRAM204に格納する。DRAM204は、第2実施例と同様にフレーム220、メタ情報222、他画面データ224、過去フレーム226を記憶し、第3実施例ではスライス266をさらに記憶する。DRAM204に記憶される他画面データ224と過去フレーム226の生成元は、GPU202とビデオデコーダ258の両方である。
【0142】
超解像処理部48は、DRAM204に格納されたスライス266(すなわちサーバ12から提供されたスライス)を読み込み、読み込んだスライスのY成分に対する超解像処理を実行する。超解像処理部48は、第2実施例と同様に、DRAM204に格納されたフレーム220のデータをスライス単位でさらに読み込み、読み込んだスライスのY成分に対する超解像処理をさらに実行してもよい。第3実施例のゲームコンソール200における以降の処理は、第2実施例のゲームコンソール200と同じであるため、再度の説明を省略する。
【0143】
第3実施例のゲームコンソール200も、第2実施例のゲームコンソール200と同様の効果を奏する。また、第3実施例のゲームコンソール200によると、表示対象フレームをサーバ12とゲームコンソール200の両方で生成する場合にも、超解像処理の遅延を抑制できる。
【0144】
<第4実施例>
以下、第4実施例について、第2実施例と相違する構成を中心に説明し、共通する構成の説明は適宜省略する。第4実施例の構成要素のうち既述の実施例の構成要素と同一または対応する構成要素には同じ符号を付している。第4実施例の構成は、他の実施例および変形例の構成と任意の組合せが可能であることはもちろんである。
【0145】
第4実施例のゲームコンソールでは、シーン情報(すなわち超解像処理のヒント情報)を超解像処理部(後述の超解像画像生成部104)へ直接入力する。第4実施例のゲームコンソールは、シーン解析回路を備えない。その代わりに、第4実施例のゲームコンソールでは、予めシーン情報と入力画像のペアに適合する超解像処理の態様を機械学習させておく。第4実施例のゲームコンソールによると、シーン解析回路を省略することでハードウェアコストを低減しつつ、シーン解析回路を備える場合と同等の超解像処理を実現できる。すなわち、第4実施例のゲームコンソールは、既述の実施例のゲームコンソールと同様の効果を奏しつつ、ハードウェアコストを一層低減することができる。
【0146】
また、第4実施例のゲームコンソールによると、
図17のゲームコンソール200とは異なり、UIプレーンを分離したデータパスやバッファリング系統を用意せずに、OS-UIに対する超解像処理による副作用(例えばジャギーの発生等)を回避できる。また、後述するOS-UIプレーンに対しても超解像処理を施すことができる。さらにまた、シーン解析を省略することにより、超解像処理の遅延を抑制することができる。
【0147】
図19と
図21は、第4実施例のゲームコンソール200の構成を示すブロック図である。
図19は、前段の処理に関する機能ブロックを示し、
図21は、
図19に続く処理に関する機能ブロックを示している。
【0148】
図19に示すように、第4実施例のゲームコンソール200は、GPU202、DRAM204、アダプティブ解像度変換部270、アダプティブ解像度変換部272、アダプティブ解像度変換部274、アダプティブ解像度変換部276、オーバレイ部278、色空間変換部280、色空間変換部282、色空間変換部284、SRAM286を備える。このうちアダプティブ解像度変換部270と色空間変換部280は、オプショナルな機能ブロックである。
【0149】
GPU202は、フレーム220、フレームメタ情報310、OS-UIプレーン317、OS-UIメタ情報318を生成してDRAM204に格納する。フレームメタ情報310は、各フレーム220の描画内容に関するメタ情報である。フレームメタ情報310は、深度情報311、動きベクトル情報312、ブラー情報313、てかり強度情報314、ゲームUIメタ情報315、シーン識別メタ情報316を含む。
【0150】
深度情報311は、各画素の奥行き情報(例えば
図9の奥行き情報)、または3DゲームにおけるZ値を含んでもよい。動きベクトル情報312は、フレーム220に描画された各オブジェクトの動きベクトル情報(例えば
図9の動きベクトル情報)を含んでもよい。ブラー情報313は、上述のMotion Blur効果の使用有無と使用領域を示す情報であり、また、フレーム220の描画内容のボケ度合を示す情報を含んでもよい。てかり強度情報314は、フレーム220の描画内容のてかり強度をしめすもの(例えば
図9のてかり強度情報)を含んでもよい。
【0151】
ゲームUIメタ情報315は、第2実施例のUIプレーンのうちゲームアプリケーションが生成するゲームの各種メニューを示す画像や、ゲームに対する各種設定用の画像(以下「ゲームUI」とも呼ぶ。)に関するメタ情報である。第4実施例では、ゲームUIは、フレーム220に描画される。ゲームUIメタ情報315は、画面またはフレーム220内におけるゲームUIの位置と、ゲームUIのα値(透明度)とを含む。シーン識別メタ情報316は、フレーム220に描画されたシーンの識別情報を含む。シーン識別メタ情報316は、例えば、第1実施例で既述した「超解像処理において判断材料とするシーン情報」を含んでもよい。
【0152】
OS-UIプレーン317は、第2実施例のUIプレーンのうちゲーム等のアプリケーションとは独立して、ゲームコンソール200のOS(Operating System)が生成するUIの画像(以下「OS-UI」とも呼ぶ。)である。OS-UIメタ情報318は、OS-UIに関するメタ情報である。OS-UIメタ情報318は、画面またはフレーム220内におけるOS-UIの位置と、OS-UIのα値(透明度)とを含む。
【0153】
アダプティブ解像度変換部270は、DRAM204に記憶されたフレームメタ情報310に対するアダプティブ解像度変換を行う。アダプティブ解像度変換部272は、DRAM204に記憶されたフレーム220のうち過去フレームに対するアダプティブ解像度変換を行う。過去フレームは、例えば、断続的に生成され続けるフレーム220における過去に生成された超解像処理前のフレーム、もしくは、超解像処理後にディスプレイインタフェース248から出力したデータを図示しないデータパスでDRAM204に書き戻したフレームを指す。アダプティブ解像度変換部274は、DRAM204に記憶されたフレーム220のうち最新フレーム(言い換えれば今回の超解像処理対象フレーム)に対するアダプティブ解像度変換を行う。アダプティブ解像度変換部276は、DRAM204に記憶されたOS-UIプレーン317に対するアダプティブ解像度変換を行う。
【0154】
アダプティブ解像度変換は、第2実施例で説明したため再度の説明を省略する。なお、アダプティブ解像度変換部270、アダプティブ解像度変換部272、アダプティブ解像度変換部274、アダプティブ解像度変換部276のそれぞれは、第2実施例のアダプティブ解像度変換部208と同様に、それぞれの変換のための学習済パラメータを参照してアダプティブ解像度変換を実行してもよい。
【0155】
オーバレイ部278は、OS-UIメタ情報318に基づいて、アダプティブ解像度変換後のフレーム220とOS-UIプレーン317とをオーバレイする。オーバレイ部278は、OS-UIメタ情報318が示すフレーム220内の位置に、OS-UIメタ情報318が示す透明度にてOS-UIプレーン317を配置するように、フレーム220とOS-UIプレーン317とを合成してもよい。オーバレイ部278によるオーバレイ処理後の画像を以下「合成フレーム」と呼ぶ。
【0156】
アダプティブ解像度変換後のフレームメタ情報310、過去フレーム、合成フレームは、必ずしも超解像処理に最適化された色空間のデータではない。例えば、過去フレームや合成フレームは、RGB形式で各成分が8ビット長であってもよく、RGB形式で各成分が浮動小数点32ビット長であってもよい。また、過去フレームや合成フレームは、YUV形式で水平方向に連続する4ピクセルから、ピクセル毎に輝度情報、輝度と青色成分の差、輝度と赤色成分の差をそれぞれ1サンプル採る方式のデータ(YUV444)であってもよい。色空間変換部280、色空間変換部282、色空間変換部284は、アダプティブ解像度変換後のフレームメタ情報310、過去フレーム、合成フレームを超解像処理に最適化された色空間のデータに変換する。
【0157】
色空間変換部280は、必要に応じて、フレームメタ情報310の各データ形式を超解像画像生成部に104に最適なデータ形式に変換する。予めシーン情報すなわちフレームメタ情報310と入力画像のペアに適合する超解像処理の態様を機械学習させたときに用いたフレームメタ情報310のデータ形式と、DRAM204に置かれるフレームメタ情報310のデータ形式が異なる場合、色空間変換部280は、データ形式を一致させるための変換を行う。色空間変換部280は、必要に応じてデータ変換を行った後のフレームメタ情報310のデータをライン単位で抽出し、そのラインデータ(「メタラインデータ288」と呼ぶ。)をSRAM286に格納する。色空間変換部282は、過去フレームを、必要に応じてY成分が12ビット長のYUV形式のデータに変換する。色空間変換部282は、色空間変換後の過去フレームのデータ(Y成分のみ)をライン単位で抽出し、そのラインデータ(「過去ラインデータ290」と呼ぶ。)をSRAM286に格納する。
【0158】
色空間変換部284は、合成フレームを、必要に応じてY成分が12ビット長のYUV形式のデータに変換する。色空間変換部284は、色空間変換後の合成フレームのデータ(Y成分のみ)をライン単位で抽出し、そのラインデータ(「Yラインデータ292」と呼ぶ。)をSRAM286に格納する。また、色空間変換部284は、色空間変換後の合成フレームのデータ(U成分およびV成分)をライン単位で抽出し、そのラインデータ(「UVラインデータ294」と呼ぶ。)をSRAM286に格納する。
【0159】
SRAM286は、第1実施例の部分画像記憶部102に対応する。SRAM286は、複数のメタラインデータ288を格納するリングバッファ、複数の過去ラインデータ290を格納するリングバッファ、複数のYラインデータ292を格納するリングバッファ、複数のUVラインデータ294を格納するリングバッファ、モデル保持部106を含む。
【0160】
図20は、ビデオタイミング例を示す。同図は、SRAM286に格納される各ラインデータを説明するための図である。SRAM286に格納される各ラインデータは、
図20に示すアクティブなディスプレイ期間(VactiveかつHactiveの期間)におけるActive Videoの1つのラインに対応する。
【0161】
図21に示すように、第4実施例のゲームコンソール200は、超解像画像生成部104、SRAM298、色空間変換部302、ディスプレイインタフェース248をさらに備える。
【0162】
超解像画像生成部104は、モデル保持部106に記憶された深層学習に基づくモデルと、メタラインデータ288と、過去ラインデータ290とに基づいて、Yラインデータ292に対する深層学習に基づく超解像処理を実行する。例えば、超解像画像生成部104は、過去ラインデータ290とYラインデータ292とを比較することにより、Yラインデータ292に映る物体の動きを検知し、その動きに適合するフィルタを選択してもよい。
【0163】
また、超解像画像生成部104は、メタラインデータ288が示すゲームUIおよびOS-UIの位置と透明度に基づいて、Yラインデータ292に映るゲームUIおよびOS-UIの領域に、ゲームのコンテンツ領域とは異なるフィルタを選択してもよく、当該UI領域専用のフィルタを選択してもよい。また、超解像画像生成部104は、メタラインデータ288が示すゲームUIおよびOS-UIの位置と透明度に基づいて、Yラインデータ292に映るゲームUIおよびOS-UIにジャギーが生じないよう特殊なフィルタまたは専用のフィルタを選択してもよい。これにより、ゲームUIおよびOS-UIに対する超解像処理による副作用(例えばジャギーの発生等)を回避できる。
【0164】
超解像画像生成部104のDNNアクセラレータ108は、積和演算回路アレイ296を含む。積和演算回路アレイ296は、深層学習に基づく超解像処理において3×3または5×5の畳み込み計算を繰り返し実行する。3×3の畳み込み計算の場合、SRAM286の各リングバッファに最低3行のラインデータが入力されると処理を開始できる。そして、SRAM286の各リングバッファに新たな1行のラインデータが入力されるたびに次の行の畳み込み計算が可能になる。
【0165】
超解像画像生成部104のYスライス処理時間は、利用するモデルの畳み込み計算の構成とDNNアクセラレータの演算器構成から計算することができる。モデルの構成情報としては、畳み込み計算のKernelサイズ(3x3、5x5等)、畳み込み計算の密度を示すstride,dilatation(1,2等)、各畳み込み層における入出力チャネル数(入力1、出力16等)、畳み込み層の数、畳み込み層の構成(Full convolution,depthwise convolution等)、アクティベーション層の構成(ReLU等)、入出力解像度(入力1920x1080画素、出力3840x2160画素等)等がある。DNNアクセラレータの演算器構成としては、同時処理可能な、積和演算数やアクティベーション演算数等がある。リングバッファに新たな1行のラインデータが入力されるたびに次の行の畳み込み計算が可能になる前提において、モデルの構成情報とDNNアクセラレータの演算器構成から処理時間を計算することができる。
【0166】
超解像画像生成部104は、Yラインデータ292に対する超解像処理の結果であるSR-Yラインデータ300をSRAM298に格納する。一方、超解像画像生成部104は、SRAM286に記憶されたUVラインデータ294に対する超解像処理をスキップする。SRAM286に記憶されたUVラインデータ294は、超解像処理が施されることなく、後述の色空間変換部302に渡される。
【0167】
色空間変換部302は、SRAM298に記憶されたSR-Yラインデータ300と、そのSR-Yラインデータ300に対応するUVラインデータ294とを合成し、表示する画像の1行に対応するラインデータ(YUV形式)を生成する。色空間変換部302は、YUV形式のラインデータを生成すると、そのラインデータの色空間をディスプレイにあわせて最適化する。色空間変換部302は、SRAM298に新たなSR-Yラインデータ300が格納される都度、新たなラインデータの合成と色空間変換を行い、複数のラインデータを順次ディスプレイインタフェース248に渡す。
【0168】
ディスプレイインタフェース248は、第1実施例のディスプレイコントローラ84に対応する。ディスプレイインタフェース248は、色空間変換部302から順次出力された複数のラインデータを順次表示パネル56(ディスプレイ86)に表示させる。
【0169】
超解像画像生成部104は、超解像処理においてブラー情報を参照することで、ブラーが掛かった画像領域、すなわち意図的に画像をぼかしている領域については、機械学習結果に基づき、超解像処理による高精細化を抑制してもよい。これにより、超解像処理により、意図的なぼけが高精細化することを回避できる。また、人は、画像を視聴した際、動きが激しい物体が描画されている領域については、描画内容の細部を認識することは困難だが、エッジ領域等の変化には敏感である。そこで、超解像画像生成部104は、超解像処理において画像に映る物体の動きベクトル情報を参照することで、動きが激しい物体が描画されている領域については、機械学習に基づいて、超解像処理を抑制してもよい。また、超解像画像生成部104は、動きが激しい物体が描画されている領域のエッジ部分については、機械学習に基づいて、超解像処理(変換)を抑制してもよい。これにより、超解像処理が不要な領域の高精細化を抑制でき、また、エッジ領域の変換を抑制することができる。
【0170】
以上、本開示を実施例をもとに説明した。この実施例は例示であり、各構成要素あるいは各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本開示の範囲にあることは当業者に理解されるところである。
【0171】
各実施例や各変形例に記載の「閾値」は、特に断らない限り、情報処理システム10またはゲームコンソール200の開発者の知見や、情報処理システム10またはゲームコンソール200を用いた実験等により適切な値が決定されてよい。
【0172】
上述した実施例および変形例の任意の組み合わせもまた本開示の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施例および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施例および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。
【産業上の利用可能性】
【0173】
本開示の技術は、画像を処理する装置、サーバまたはシステムに適用することができる。
【符号の説明】
【0174】
10 情報処理システム、 12 サーバ、 14 クライアント端末、 22 画像生成部、 28 圧縮符号化部、 32 シーン情報取得部、 42 データ取得部、 48 超解像処理部、 54 表示制御部。