(57)【要約】【課題】画像データを画像処理モジュールに提供する方法及びシステムを提供する。【解決手段】画像データが縮小器に読み出される。第１解像度の画像データが第１バッファの中に格納される。画像処理モジュールが要求する画像データ領域が予想され、予想データ領域の少なくとも一部に対応するデータが第２バッファの中に格納される。第２バッファのデータは、第１解像度よりも高い解像度を有する。データ要求がモジュールから受け取られると、要求データに対応するデータが第２バッファにあるかが決定される。要求データに対応するデータが第２バッファにある場合は、画像データは、第２バッファから画像処理モジュールに提供される。要求データに対応するデータが第２バッファにはない場合は、要求データの代替物を高解像度に適合する解像度で提供するために第１バッファからのデータが拡大され、拡大データがモジュールに提供される。【選択図】図３
2014053896.tif 000002
【特許請求の範囲】
【請求項１】
画像データを画像処理モジュールに提供する方法であって、
画像データをメモリから該画像データを第１の解像度まで縮小する縮小器内に読み取る段階と、
前記第１の解像度の画像データを第１のバッファに格納する段階と、
前記画像処理モジュールが要求することになる画像データ領域を予想する段階と、
前記予想画像データ領域の少なくとも一部に対応する画像データをメモリから第２のバッファの中に格納し、該第２のバッファの該画像データが、前記第１の解像度よりも高い解像度にある段階と、
前記画像処理モジュールから画像データに対する要求を受け取る段階と、
前記要求画像データの少なくとも一部分に対応する画像データが前記第２のバッファにはないと決定する段階と、
前記要求画像データの前記少なくとも一部分に対する代替物を前記高い解像度に少なくとも適合する解像度で提供するために前記第１のバッファからの画像データを拡大する段階と、
前記拡大画像データを前記画像処理モジュールに提供する段階と、
を含むことを特徴とする方法。
【請求項２】
前記予想画像データ領域の少なくとも一部に対応する画像データをメモリから前記第２のバッファの中に格納する前記段階は、
画像データをメモリから該画像データを第２の解像度まで縮小する縮小器の中に読み取る段階と、
前記第２の解像度の画像データを前記第２のバッファに格納する段階と、
を含む、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記要求画像データの一部分に対応する画像データが前記第２のバッファにあると決定する段階と、
画像データを前記第２のバッファから前記画像処理モジュールに前記高い解像度に少なくとも等しい解像度で提供する段階と、
を更に含むことを特徴とする請求項１又は請求項２に記載の方法。
【請求項４】
前記第１のバッファは、画像フレームの全幅に対応する画像データを格納することを特徴とする請求項１から請求項３のいずれか１項に記載の方法。
【請求項５】
画像データが、前記第１及び第２のバッファの各々に矩形ブロックで配置されることを特徴とする請求項１から請求項４のいずれか１項に記載の方法。
【請求項６】
前記第１のバッファ内の前記ブロックのサイズが、前記第１の解像度と前記高い解像度の間の差に対応する倍率によって前記第２のバッファ内の前記ブロックのサイズに関連することを特徴とする請求項５に記載の方法。
【請求項７】
前記第２のバッファは、内容アドレスメモリを用いて実施されることを特徴とする請求項１から請求項６のいずれか１項に記載の方法。
【請求項８】
前記画像処理モジュールが要求することになる画像データ領域が、該画像処理モジュール又は更に別の画像処理モジュールによって供給されるデータを用いて予想されることを特徴とする請求項１から請求項７のいずれか１項に記載の方法。
【請求項９】
前記画像処理モジュールが要求することになる前記画像データ領域は、該画像処理モジュール又は前記更に別の画像処理モジュールによって供給される動きベクトルを用いて予想されることを特徴とする請求項８に記載の方法。
【請求項１０】
前記第１の解像度の画像データを前記第１のバッファに格納する段階は、該第１の解像度の画像データをメモリに書き込む段階と、該第１の解像度の画像データをメモリから該第１のバッファの中に読み取る段階とを含むことを特徴とする請求項１から請求項９のいずれか１項に記載の方法。
【請求項１１】
前記縮小器は、前記高い解像度での画像データと前記第１の解像度から該高い解像度に拡大された画像データとの間の差を決定することによって残差画像データを生成することを特徴とする請求項１から請求項１０のいずれか１項に記載の方法。
【請求項１２】
前記残差画像データは、非可逆圧縮又は可逆圧縮を用いて圧縮されることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記第２のバッファにおいて前記予想画像データ領域の少なくとも一部に対応する画像データが、残差画像データを含むことを特徴とする請求項１１又は請求項１２に記載の方法。
【請求項１４】
画像データを前記第２のバッファから前記画像処理モジュールに提供する段階は、
前記第１のバッファからの画像データを前記高い解像度に少なくとも適合するように拡大する段階と、
前記第２のバッファからの残差画像データを前記拡大画像データと組み合わせる段階と、
その結果を前記画像処理モジュールに提供する段階と、
を含む、
ことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記画像の一部における高周期情報の量を決定する段階を更に含むことを特徴とする請求項１から請求項１４のいずれか１項に記載の方法。
【請求項１６】
前記予想画像データ領域の一部に対応する画像データが、それが該画像のその部分における高周期情報の量が閾値よりも少ないと決定された場合に前記第２のバッファに格納されないことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記予想画像データ領域の一部に対応する画像データが、該予想画像データ領域のその部分が前記画像処理モジュールによって使用されることにならないことが示された場合に前記第２のバッファに格納されないことを特徴とする請求項１から請求項１６のいずれか１項に記載の方法。
【請求項１８】
どれ程の画像データがメモリから前記第２のバッファに格納されるかが、メモリ帯域幅消費率要件を踏まえて決定されることを特徴とする請求項１から請求項１７のいずれか１項に記載の方法。
【請求項１９】
前記閾値は、前記画像の異なる部分における高周期情報の量及び前記メモリ帯域幅消費率要件を踏まえて調節されることを特徴とする請求項１６に従属する時の請求項１８に記載の方法。
【請求項２０】
前記第１の解像度での画像データに対する前記又は更に別の画像処理モジュールからの要求に応じて、第１の解像度の画像データを前記第１のバッファから該又は該更に別の画像処理モジュールに提供する段階を更に含むことを特徴とする請求項１から請求項１９のいずれか１項に記載の方法。
【請求項２１】
前記又は前記更に別の画像処理モジュールは、前記第１の解像度の前記画像データを使用する動き推定器を含むことを特徴とする請求項２０に記載の方法。
【請求項２２】
少なくとも前記高い解像度の画像データが提供された前記画像処理モジュールは、動き推定器の結果に基づいて画像を出力することを特徴とする請求項１から請求項２１のいずれか１項に記載の方法。
【請求項２３】
前記画像処理モジュールは、フレームレートコンバータの映像構築器を含むことを特徴とする請求項２２に記載の方法。
【請求項２４】
前記フレームレートコンバータの前記映像構築器は、前記第１のバッファから前記第１の解像度の画像データが提供された解析器を更に含むことを特徴とする請求項２０に従属する時の請求項２３に記載の方法。
【請求項２５】
前記第１のバッファからの前記拡大画像データと前記第２のバッファから提供された画像データとの間の潜在的な不連続の場所が識別されることを特徴とする請求項１から請求項２４のいずれか１項に記載の方法。
【請求項２６】
混合ユニットが、前記不連続の可視性を低減するために該不連続の近くで前記第２のバッファからの画像データを前記第１のバッファからの拡大画像データと組み合わせることを特徴とする請求項２５に記載の方法。
【請求項２７】
前記予想画像データ領域の前記少なくとも一部に対応する少なくとも一部の色度画像データが、前記第２のバッファに格納されないことを特徴とする請求項１から請求項２６のいずれか１項に記載の方法。
【請求項２８】
画像データを画像処理モジュールに提供するためのシステムであって、
メモリからの画像データを第１の解像度まで縮小するように構成された縮小器と、
前記第１の解像度の画像データを格納するように配置された第１のバッファと、
予想画像データ領域の少なくとも一部に対応する画像データを格納するように配置された第２のバッファであって、該第２のバッファに格納される該画像データの解像度が前記第１の解像度よりも高い前記第２のバッファと、
画像データをメモリから前記縮小器内に読み取り、かつ前記第１の解像度の画像データを前記第１のバッファに格納し、
前記画像処理モジュールが要求することになる画像データ領域を予想し、
前記予想画像データ領域の少なくとも一部に対応する画像データをメモリから前記第２のバッファの中に格納し、
画像データに対する要求を前記画像処理モジュールから受け取り、
前記要求画像データの少なくとも一部分に対応する画像データが前記第２のバッファにはないと決定し、
前記要求画像データ領域の前記少なくとも一部分に対する代替物を前記高い解像度に少なくとも適合する解像度で提供するために、拡大器を用いて前記第１のバッファからの画像データを拡大し、かつ
前記拡大画像データを前記画像処理モジュールに提供する、
ように構成されたプロセッサと、
を含むことを特徴とするシステム。
【請求項２９】
前記プロセッサは、前記予想画像データ領域の少なくとも一部に対応する画像データを、
画像データをメモリから該画像データを第２の解像度まで縮小する縮小器内に読み取り、かつ
前記第２の解像度の画像データを前記第２のバッファに格納する、
ことによって前記第２のバッファに格納するように構成されることを特徴とする請求項２８に記載のシステム。
【請求項３０】
前記プロセッサは、
前記要求画像データの一部分に対応する画像データが前記第２のバッファにあると決定し、かつ
画像データを前記第２のバッファから前記画像処理モジュールに前記高い解像度に少なくとも等しい解像度で提供する、
ように更に構成されることを特徴とする請求項２８又は請求項２９に記載のシステム。
【請求項３１】
前記第１のバッファは、画像フレームの全幅に対応する画像データを格納することを特徴とする請求項２８から請求項３０のいずれか１項に記載のシステム。
【請求項３２】
前記画像データは、前記第１及び第２のバッファの各々に矩形ブロックで配置されることを特徴とする請求項２８から請求項３１のいずれか１項に記載のシステム。
【請求項３３】
前記第１のバッファ内の前記ブロックのサイズが、前記第１の解像度と前記高い解像度の間の差に対応する倍率によって前記第２のバッファ内の前記ブロックのサイズに関連することを特徴とする請求項３２に記載のシステム。
【請求項３４】
前記第２のバッファは、内容アドレスメモリを用いて実施されることを特徴とする請求項２８から請求項３３のいずれか１項に記載のシステム。
【請求項３５】
前記画像処理モジュールが要求することになる画像データ領域が、該画像処理モジュール又は更に別の画像処理モジュールによって供給されるデータを用いて予想されることを特徴とする請求項２８から請求項３４のいずれか１項に記載のシステム。
【請求項３６】
前記画像処理モジュールが要求することになる前記画像データ領域は、該画像処理モジュール又は前記更に別の画像処理モジュールによって供給される動きベクトルを用いて予想されることを特徴とする請求項３５に記載のシステム。
【請求項３７】
前記プロセッサは、前記第１の解像度の画像データをメモリに書込み、かつ該第１の解像度の画像データをメモリから前記第１のバッファの中に読み取ることにより、該第１の解像度の画像データを該第１のバッファに格納するように構成されることを特徴とする請求項２８から請求項３６のいずれか１項に記載のシステム。
【請求項３８】
前記縮小器は、前記高い解像度での画像データと前記第１の解像度から該高い解像度に拡大された画像データとの間の差を決定することによって残差画像データを生成することを特徴とする請求項２８から請求項３７のいずれか１項に記載のシステム。
【請求項３９】
前記残差画像データは、非可逆圧縮又は可逆圧縮を用いて圧縮されることを特徴とする請求項３８に記載のシステム。
【請求項４０】
前記第２のバッファに格納されて前記予想画像データ領域の少なくとも一部に対応する画像データが、残差画像データを含むことを特徴とする請求項３８又は請求項３９に記載のシステム。
【請求項４１】
前記プロセッサは、前記第２のバッファから画像データを、
前記第１のバッファからの画像データを拡大器を用いて前記高い解像度に少なくとも適合するように拡大し、
前記第２のバッファからの残差画像データを前記高い解像度に少なくとも適合するように拡大された前記第１のバッファからの画像データと組み合わせ、かつ
その結果を前記画像処理モジュールに提供する、
ことによって前記画像処理モジュールに提供するように構成されることを特徴とする請求項３０に従属する時の請求項４０に記載のシステム。
【請求項４２】
前記プロセッサは、前記画像の一部における高周期情報の量を決定するように更に構成されることを特徴とする請求項２８から請求項４１のいずれか１項に記載のシステム。
【請求項４３】
前記予想画像データ領域の一部に対応する画像データが、それが該画像のその部分における高周期情報の量が閾値よりも少ないと決定された場合に前記第２のバッファに格納されないことを特徴とする請求項４２に記載のシステム。
【請求項４４】
前記予想画像データ領域の少なくとも一部に対応する画像データが、該予想画像データ領域のその部分が前記画像処理モジュールによって使用されることにならないことが示された場合に前記第２のバッファに格納されないことを特徴とする請求項２８から請求項４３のいずれか１項に記載のシステム。
【請求項４５】
どれ程の画像データがメモリから前記第２のバッファに格納されるかが、メモリ帯域幅消費率要件を踏まえて決定されることを特徴とする請求項２８から請求項４４のいずれか１項に記載のシステム。
【請求項４６】
前記閾値は、前記画像の異なる部分における高周期情報の量及び前記メモリ帯域幅消費率要件を踏まえて調節されることを特徴とする請求項４３に従属する時の請求項４５に記載のシステム。
【請求項４７】
前記プロセッサは、前記第１の解像度での画像データに対する前記又は更に別の画像処理モジュールからの要求に応じて、第１の解像度の画像データを前記第１のバッファから該又は該更に別の画像処理モジュールに提供するように更に構成されることを特徴とする請求項２８から請求項４６のいずれか１項に記載のシステム。
【請求項４８】
前記第１の解像度での画像データを要求する前記又は前記更に別の画像処理モジュールは、該第１の解像度での該画像データを使用する動き推定器を含むことを特徴とする請求項４７に記載のシステム。
【請求項４９】
少なくとも前記高い解像度での画像データを要求する前記画像処理モジュールは、動き推定器の結果に基づいて画像を出力することを特徴とする請求項２８から請求項４８のいずれか１項に記載のシステム。
【請求項５０】
前記画像処理モジュールは、フレームレートコンバータの映像構築器を含むことを特徴とする請求項４９に記載のシステム。
【請求項５１】
前記フレームレートコンバータの前記映像構築器は、前記第１のバッファから前記第１の解像度の画像データが提供された解析器を更に含むことを特徴とする請求項４７に従属する時の請求項５０に記載のシステム。
【請求項５２】
前記プロセッサは、前記第１のバッファからの前記拡大画像データと前記第２のバッファから提供された画像データとの間の潜在的な不連続の場所を識別するように更に構成されることを特徴とする請求項２８から請求項５１のいずれか１項に記載のシステム。
【請求項５３】
混合ユニットが、前記不連続の可視性を低減するために該不連続の近くで、前記第２のバッファから提供された画像データを前記第１のバッファからの拡大画像データと組み合わせることを特徴とする請求項５２に記載のシステム。
【請求項５４】
前記予想画像データ領域の前記少なくとも一部に対応する少なくとも一部の色度画像データが、前記第２のバッファに格納されないことを特徴とする請求項２８から請求項５３のいずれか１項に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像データを画像処理モジュールに提供する方法及びシステムに関する。
【背景技術】
【０００２】
画像又はビデオ処理システムは、メモリシステムに対して重い要求を課す可能性がある。一般的に、画像処理デバイスは、有限の帯域幅を有するバスを用いてメモリに接続される。多くの場合に、バスを通じてメモリにから読み出されるか、又はメモリに書き込まれるデータの量を低減することを目的とするバッファ又はキャッシュとして作動する画像処理デバイスに対してローカルなメモリも存在することになる。バスを通じてメモリからデータを読み取るのは、ローカルメモリから同じデータを読み取るのと比較して相対的に低速であり、より多くの電力を消費する。
【０００３】
何らかのメモリ帯域幅は不可避である。一般的な処理システムは、各入力画像フレームをメモリからバスを通じて読み取り、各出力画像フレームをメモリにバスを通じて書き込まなければならない。高精細（ＨＤ）ビデオでは、フレームは、１９２０ピクセル幅及び１０８０ピクセル高である場合がある。一般的な４２０色度サブサンプリングモードでは、フレームサイズは、約３．１メガバイト（ＭＢ）である。２４フレーム毎秒（ｆｐｓ）の入力フレームレートでは、入力データ帯域幅だけで約７４ＭＢ／秒である。
【０００４】
出力ビデオのサイズ及びフレームレートは、適用される処理に基づいて、入力ビデオのサイズ及びフレームレートとは異なる場合がある。１つの考えられる処理アルゴリズムは、入力フレームを２４ｆｐｓで読み取り、出力フレームを例えば１２０ｆｐｓで書き込むことができる高精細動き補償フレームレートコンバータである。この場合、上述の７４ＭＢ／秒の入力データ帯域幅に加えて、出力データ帯域幅は、３００ＭＢ／秒よりも大きい。この量のデータ転送はほぼ不可避である。
【０００５】
例示的なフレームレート変換アルゴリズムは、２つの主要段階で作動する。最初に、動き推定が、連続する入力フレームの対の間の動きを表すベクトル場を計算する。第２に、映像構築又は内挿段階が、入力フレームから得られて動きベクトルによって決定された位置で出力フレームに置かれたピクセルを用いていくつかの出力フレームを構成する。
【０００６】
動き推定には様々な手法が存在する。一般的なものは、フレームを小さい矩形ブロックに分割し、各ブロックに対して、隣接入力フレーム内でピクセルデータの適合区域を検索するものである。一般的に、検索処理は、いくつかの動きベクトル候補の各々の評価を必要とし、適合の品質は、ブロック内のピクセルと隣接フレームからのピクセルとの間の差絶対値和（ＳＡＤ）のようなメトリックを用いて決定される。ピクセルの適合区域の間の位置オフセットは、当該ブロックに対する動きベクトルを決定する。
【０００７】
動きベクトル候補は、検索範囲のあらゆるベクトルとすることができる。検索範囲は、ブロックを取り囲み、そのサイズは、検出して追跡することができる動きの範囲を決定する。多くの場合に、類似の値を有するいくつかの候補が存在し、これは、隣接フレームからのピクセルを複数回読み出さなければならないことを意味する。従って、検索範囲に対応する隣接フレームピクセルデータをローカルバッファに格納することが適切である。バッファが一杯になると、いずれの付加的なメモリ帯域幅も消費することなく、多くのベクトル候補を試験することができるが、バッファを一杯にするメモリ帯域幅消費を考慮しなければならない。
【０００８】
アルゴリズムの映像構築段階では、選択された動きベクトルに対応するピクセルデータが、出力フレーム内のその位置に投影される。いくつかの別の動き推定結果を投影することができ、出力フレーム内のピクセル値は、これらの各々の合成物から形成される。また、映像構築に使用されるピクセルデータは、動き推定のためにピクセルを供給するものと同じピクセルデータバッファから読み出される。
【０００９】
図１は、ピクセルデータバッファの設計に対する１つの手法を示している。バッファ１００を動き推定器の検索範囲１０５と同じサイズに示しており、このバッファは、動き推定が発生するブロック１１０を中心とする。実際には、バッファサイズは、フレームレートコンバータの映像構築段階のような他の処理にデータを供給するために若干拡張される場合がある。動き推定処理が次のブロック１１５に移動すると、ピクセルデータバッファは、検索範囲の一方のエッジにあるブロック列１２０に対応するデータを廃棄して、検索範囲の反対のエッジにあるブロック列１２５に対応するデータを読み取る。検索範囲の高さがＶ個のブロックである場合には、動き推定器内で処理される各新しいブロックに対して、ピクセルデータのＶ個のブロックを読み出さなければならない。検索範囲が画面のエッジと重なり始めると、ある程度の節約を行うことができるが、この節約は、処理位置が次の行に下がる時に長いブロック行１３０を読み取る必要性によってほぼ相殺される。次の行の反対の終端にジャンプして戻る処理が、負担の大きいバッファ内容１４５全体の入れ替えを必要とすることになることに関しては、ラスター走査順序１４０よりは蛇行処理順序１３５が好ましい。
【００１０】
フレームの動き推定において、隣接フレーム内のピクセルデータの全てのブロックを少なくとも一度は調べなければならないと予想するのは妥当性がある。殆どの動きはほぼ平行移動のものであり、ベクトル場は比較的均一である。隣接フレームのかなりの部分が動き推定器によるアクセスを受けないという例外はあるが、この例外が適用されることに依存することは決してできない。隣接フレームからの各ブロックが、たった一度だけ読み出される場合には、動き推定器は、メモリ帯域幅に関して最適なものであるとある程度いうことができる。
【００１１】
図１の設計は、最適な設計のメモリ帯域幅消費の約Ｖ倍という犠牲を払って、ピクセルデータバッファに必要とされるストレージの量を最小にするという利点を有する。妥当性のある垂直動き検索範囲では、Ｖは特に小さいわけではない。
【００１２】
図２は、全フレーム幅であるピクセルデータバッファ２００を示している。動き推定器の検索範囲２０５は、処理中のブロック２１０に対応する。動き推定が次のブロック２１５に進むと、１つの付加的なブロック２２０を読み出さなければならず、１つのブロック２２５が廃棄されなければならない。読み取りブロック位置は、処理位置が現在の行の終端に来ると次の行の開始点に折り返し、蛇行処理順序とラスター走査処理順序の間の違いはそれ程有意ではなくなる。各フレームブロックは一度しか読み取る必要がないので、この設計は、最適なメモリ帯域幅を得る。フレームが幅広である場合には、最初のブロックを処理することができるようにバッファが十分に一杯になる前に大幅な遅延がある場合がある。この設計の最も有意な欠点は、ピクセルデータバッファにかなり大量のローカルメモリを必要とすることである。
【００１３】
通常、この種の用途では、メモリキャッシュは、キャッシュ・ミスの際にメモリからバスを通じてデータを取得するのに要する時間に起因して、ピクセルデータバッファの適切な代替物ではない。それとは対照的に、ピクセルデータバッファ設計は、データが即座に利用可能であることを保証する。これは、ビデオ処理のような計算負荷が高い実時間アプリケーションでは有意である。
【００１４】
ビデオフレームサイズが増大すると、ピクセルデータバッファに必要とされるストレージ量は比例して増大する。高精細（ＨＤ）画像は、１９２０×１０８０ピクセルである。ビデオシーケンスにおける動きのサイズには制限がないが、多くの場合に、動き推定器の検索範囲のサイズには実際的な制約条件が存在する。検索範囲の垂直サイズＶは、特に重要なものである。動き推定器が、ＨＤビデオ内の移動の大部分を追跡するためには、バッファは、数百ピクセル高であることが必要な場合がある。ピクセルデータバッファが画面幅であり、垂直検索範囲Ｖが２００ピクセルである場合には、約１９２０×２００ピクセルに対するストレージが必要である。（図２は、バッファが、その幅の一部にわたって１ブロック短い場合があることを示す。）多くの場合に、動き推定は、異なるフレーム間で又は同時に異なる間隔にわたって作動し、場合によって２つ、３つ、又は４つのフレームに関するピクセルデータを同時に必要とする。従って、ストレージ要件は、それに応じて拡大されなければならない。必要とされる合計ストレージ量は大きく、ピクセルデータバッファリングは、動き推定デバイスのシリコン面積のかなりの割合に対応する。
【００１５】
超高精細テレビジョン（ＵＨＤＴＶ）規格は、ＨＤよりも高い解像度を有する新しいビデオフォーマットを定める。４Ｋ  ＵＨＤＴＶは、各寸法においてＨＤのサイズの２倍、すなわち、３８４０×２１６０ピクセルのフレームを有するフォーマットである。フレームを読み取る必要性は不可避のままに留まり、従って、メモリ帯域幅は、少なくともフレーム面積に比例し、すなわち、４倍に増大する。その結果、不要なメモリ帯域幅を追加することなく、ピクセルデータバッファリングを可能な限り最適に近いように設計することが望ましい。これは、画面の全幅のピクセルデータバッファの使用を意味する。一般的な動きベクトルも、フレームサイズに比例してスケーリングされ、従って、検索範囲寸法は２倍になる。従って、この場合、全幅のピクセルデータバッファは、約３８４０×４００ピクセルになり、ＨＤ方式のサイズの４倍、従って、そのシリコン面積のほぼ４倍になる。
【００１６】
８Ｋ  ＵＨＤＴＶフレームは、各寸法において４Ｋ  ＵＨＤＴＶのサイズの２倍である。それによって帯域幅要件は、ＨＤビデオのもの１６倍に増大し、ピクセルデータバッファストレージ量の１６倍が必要である。
【発明の概要】
【発明が解決しようとする課題】
【００１７】
本出願人は、画像データバッファによって必要とされるメモリ空間の量を低減し、同時にメモリ帯域幅消費も低減することが望ましいと考えた。
【課題を解決するための手段】
【００１８】
本発明により、画像データを第１の解像度まで縮小する縮小器内に画像データをメモリから読み取る段階と、第１の解像度の画像データを第１のバッファに格納する段階と、画像処理モジュールが要求することになる画像データ領域を予想する段階と、予想画像データ領域の少なくとも一部に対応する画像データをメモリからバッファ内の画像データが第１の解像度よりも高い解像度にある第２のバッファに格納する段階と、画像処理モジュールから画像データに対する要求を受け取る段階と、要求画像データの少なくとも一部分に対応する画像データが第２のバッファにはないと決定する段階と、要求画像データの少なくとも一部分に対する代替物を高い解像度に少なくとも適合する解像度で提供するために第１のバッファからの画像データを拡大する段階と、拡大画像データを画像処理モジュールに提供する段階とを含む画像データを画像処理モジュールに提供する方法を提供する。
【００１９】
本発明の実施形態は、要求画像データに対応する画像データが第２のバッファにはない場合に、画像データをメモリから取り出すことが必要になるという多くの用途において許容不能な遅延をもたらす場合がある危険性なしに、第２のバッファ内に高い解像度で格納される画像データの量を小さくすることができるという利点を有する。要求画像データに対応する画像データが第２のバッファにはない場合には、要求画像データに対する代替物を高い解像度に少なくとも適合する解像度で提供するために第１のバッファからの画像データが拡大される。この方法は、一部の事例では、低品質の画像データが画像処理モジュールに提供される場合があるという欠点を有する。高周期情報は、縮小処理中に失われ、その後に、画像データを拡大することに基づいて回収することができない。しかし、この方法は、画像データバッファによって必要とされるメモリ空間を低減することができるという利点を有する。
【００２０】
画像の領域に関する画像データは、第２のバッファ内と第１のバッファ内の両方に格納される場合があるが、第２のバッファ（高解像度画像データを格納する）は、小さくすることができるので（低い解像度の画像データを第１のバッファ内に有するというフォールバックに起因して）、これらのバッファの両方に必要とされる合計メモリ空間は、第１のバッファの中に格納される画像データの全てが高い解像度で格納された場合のものよりも小さくすることができる。
【００２１】
従って、これはまた、より大きい画像領域に関する画像データを同じ量のバッファメモリに格納することができることを意味する。これは、一部の用途において、バッファ内には存在しない画像データを再度読み取るのに必要とされるメモリ帯域幅をバッファによって必要とされるメモリ空間量を増加させることなく低減することができるという利点を有する。
【００２２】
本発明の好ましい実施形態において、第１のバッファは、画像フレームの全幅に対応する画像データを格納する。
【００２３】
好ましくは、第２のバッファ内の画像データは、メモリから第２のバッファの中に読み出される。しかし、別の実施形態において、予想画像データ領域の少なくとも一部に対応する画像データをメモリから第２のバッファに格納する段階は、画像データを第２の解像度まで縮小する縮小器内に画像データをメモリから読み取る段階と、第２の解像度の画像データを第２のバッファに格納する段階とを含む。
【００２４】
本発明の実施形態は、要求画像データの一部分に対応する画像データが第２のバッファにあると決定する段階と、画像データを第２のバッファから画像処理モジュールに高い解像度に少なくとも等しい解像度で提供する段階とを更に含む。
【００２５】
画像データは、第１及び第２のバッファの各々の内部に矩形ブロックで配置することができる。好ましくは、第１のバッファ内のブロックのサイズは、第１の解像度と高い解像度の間の差に対応する倍率によって第２のバッファ内のブロックのサイズに関連している。
【００２６】
第２のバッファは、内容アドレスメモリを用いて実施することができる。
【００２７】
画像処理モジュールが要求することになる画像データ領域は、画像処理モジュール又は更に別の画像処理モジュールによって供給されるデータを用いて予想することができる。例えば、画像処理モジュールが要求することになる画像データ領域は、画像処理モジュール又は更に別の画像処理モジュールによって供給される動きベクトルを用いて予想することができる。
【００２８】
本発明の好ましい実施形態において、第１の解像度の画像データは、第１の解像度の画像データをメモリに書込み、かつ第１の解像度の画像データをメモリから第１のバッファの中に読み取ることによって第１のバッファの中に格納される。第１の解像度の画像データをメモリに書き込む段階は、メモリ帯域幅を使用する。しかし、本出願人は、そうでなければ画像データを再度読み取って縮小することが必要になる用途において、第１の解像度の画像データをメモリに書き込むことにより、全体的なメモリ帯域幅の節約をもたらすことができることを認めた。第１の解像度の画像データをメモリに書込み、かつメモリから読み取るのに必要とされるメモリ帯域幅の量は、高い解像度にある画像データを読み取るのに必要とされるメモリ帯域幅よりも小さくすることができ、この節約は、画像データをメモリから複数回読み取る必要がある場合に増加することになる。更に、この方法は、画像データを一度しか縮小しなくてもよいので、画像データを縮小するのに必要とされる処理電力を低減することを可能にする。
【００２９】
本発明の更に好ましい実施形態において、縮小器は、高い解像度にある画像データと第１の解像度から高い解像度に拡大された画像データとの間の差を決定することによって残差画像データを生成する。
【００３０】
この実施形態において、予想画像データ領域の少なくとも一部に対応する第２のバッファ内の画像データは、残差画像データを含むことができる。残差画像データは、高い解像度と同じ解像度を有する。しかし、残差画像データを使用する利点は、多くの場合に、残差画像データは、高い解像度の画像データよりも容易かつ十分に圧縮することができる点である。これは、残差画像データをメモリから読み取り、かつメモリに書き込むのに必要とされるメモリ帯域幅を高い解像度の画像データを読み取るのに必要とされるメモリ帯域幅よりも有利に小さくすることができることを意味する。更に、第２のバッファによって必要とされるメモリ空間は、低減することができる。残差画像データは、非可逆圧縮又は可逆圧縮を用いて圧縮することができる。
【００３１】
この実施形態において、画像データを第２のバッファから画像処理モジュールに提供する段階は、第１のバッファからの画像データを高い解像度に少なくとも適合するように拡大する段階と、第２のバッファからの残差画像データを拡大画像データと組み合わせる段階と、結果を画像処理モジュールに提供する段階とを含むことができる。
【００３２】
本発明の更に好ましい実施形態において、本方法は、画像の一部における高周期情報の量を決定する段階を含む。この段階は、残差画像データを解析することによって行うことができる。
【００３３】
この実施形態において、予想画像データ領域の一部に対応する画像データは、画像のその部分における高周期情報の量が閾値よりも少ないと決定された場合には、第２のバッファに格納されない場合がある。それによってメモリ帯域幅を節約することが可能になり、更に、他のデータによる占有に向けて第２のバッファ内の空間を解放することが可能になる。これらの他のデータは、依然として格納されていないデータ、又は既に格納されている（将来的に有用である可能性がある）第２のバッファをキャッシュデータのように考えたデータであり、押し出しを回避することができる。
【００３４】
予想画像データ領域の一部に対応する画像データは、予想画像データ領域のその部分が画像処理モジュールによって使用されることにならないことが示された場合にも、第２のバッファに格納されない場合がある。これは、例えば、予想画像データにおける信頼性が低い場合とすることができる。
【００３５】
本発明の更に好ましい実施形態において、どれ程の画像データがメモリから第２のバッファに格納されるかは、メモリ帯域幅消費率要件を踏まえて決定される。
【００３６】
好ましくは、閾値は、画像の異なる部分における高周期情報の量及びメモリ帯域幅消費率要件を踏まえて調節される。
【００３７】
本発明の更に好ましい実施形態において、画像処理モジュール又は更に別の画像処理モジュールからの第１の解像度での画像データに対する要求に応じて、第１の解像度の画像データを第１のバッファから画像処理モジュール又は更に別の画像処理モジュールに提供することができる。例えば、画像処理モジュール又は更に別の画像処理モジュールは、第１の解像度にある画像データを使用する動き推定器を含むことができる。
【００３８】
画像処理モジュールは、例えば、動き推定器の結果に基づいて、少なくとも高い解像度にある画像を出力するフレームレートコンバータの映像構築器とすることができる。一実施形態において、フレームレートコンバータの映像構築器は、第１のバッファから第１の解像度にある画像データが供給される解析器を更に含む。
【００３９】
本発明の実施形態において、第１のバッファからの拡大画像データと第２のバッファから供給される画像データとの間の潜在的な不連続の場所が識別される。本発明の好ましい実施形態において、不連続の可視性を低減するために、混合ユニットが、第２のバッファからの画像データを第１のバッファからの拡大画像データと不連続の近くで組み合わせる。
【００４０】
本発明の更に好ましい実施形態において、予想画像データ領域の少なくとも一部に対応する少なくとも一部の色度画像データは、第２のバッファに格納されない。本出願人は、一般的に、色度画像データでは、高周期情報は、輝度画像データにおいて知覚される程容易には知覚されないことを認めた。従って、１つ又はそれよりも多くの画像ピクセルにおける色度画像データを第２のバッファの中に読み出さないことにより、メモリ帯域幅を取り置くことが可能になり、同時に、画像処理モジュールに提供される画像データの品質のあらゆる低下が抑制される。更に、それによって第２のバッファ内の空間を他のデータによる占有に向けて解放することが可能になる。
【００４１】
本発明により、メモリからの画像データを第１の解像度まで縮小するように構成された縮小器と、第１の解像度の画像データを格納するように配置された第１のバッファと、予想画像データ領域の少なくとも一部に対応する画像データを格納するように配置されて、バッファ内の画像データが第１の解像度よりも高い解像度にある第２のバッファと、画像データをメモリから縮小器内に読み取って第１の解像度の画像データを第１のバッファに格納し、画像処理モジュールが要求することになる画像データ領域を予想し、予想画像データ領域の少なくとも一部に対応する画像データをメモリから第２のバッファに格納し、画像データに対する要求を画像処理モジュールから受け取り、要求画像データ領域の少なくとも一部に対応する画像データが第２のバッファに格納されていないと決定し、要求画像データ領域の少なくとも一部分に対する代替物を高い解像度に少なくとも適合する解像度で提供するために第１のバッファからの画像データを拡大器を用いて拡大し、かつ拡大画像データを画像処理モジュールに提供するように構成されたプロセッサとを含む画像データを画像処理モジュールに提供するためのシステムも提供する。
【００４２】
従って、本発明の好ましい実施形態において、第２のバッファは、キャッシュのように作動させることができ、いくつかのピクセルブロックを高解像度で格納する。第２の（高い解像度の）バッファの内容は、画像処理モジュールによって要求されるピクセルデータを供給し、同時にメモリ帯域幅消費を更に調整するために、予想アルゴリズム及びレート制御アルゴリズムを使用することができるバッファコントローラによって維持することができる。
【００４３】
アプリケーション（動き推定器及びフレームレートコンバータの映像構築器のような）は、第１のバッファ又は第２のバッファのいずれかからのデータにアクセス可能である。例えば、動き推定器は、完全に第１のバッファからの低い（第１の）解像度のデータから作動するように設計することができる。映像構築器は、出力フレームが可能な場合は必ず入力フレームの解像度を維持するように、好ましくは、高解像度データを用いて作動されなければならない。第２の（高解像度の）バッファへのアクセスは、バッファコントローラを通じたものであり、バッファコントローラは、高解像度データが高解像度バッファ内で利用可能な場合は高解像度データを供給し、高解像度データが利用可能ではない場合は、第１の（低解像度の）バッファからのデータを拡大したものを供給する。
【００４４】
本発明の好ましい実施形態の更に別の特徴及び利点は、以下に続く詳細説明から明らかになるであろう。
【００４５】
ここで、本発明の実施形態を添付図面を参照して単なる例として以下に説明する。
【図面の簡単な説明】
【００４６】
【図１】動き推定器の検索範囲と同じサイズのピクセルデータバッファの図である。
【図２】ビデオフレームと同じ幅のピクセルデータバッファの図である。
【図３】本発明の実施形態におけるバッファコントローラの制御下にある高解像度バッファ及び低解像度バッファを有するシステムのアーキテクチャを示すブロック図である。
【図４】本発明の実施形態における低解像度フレームと残差データとを格納する拡張システムのブロック図である。
【図５】本発明の実施形態におけるバッファ制御ユニットのブロック図である。
【図６】本発明の実施形態における残差データのバッファリングを管理する別のバッファ制御ユニットのブロック図である。
【図７】バッファストレージブロックに対する要求データの様々なアラインメントの図である。
【図８】要求されたブロック内のデータのバッファからの利用可能性及び取得不能性の図である。
【図９】本発明の実施形態における混合ユニットを組み込むバッファ制御ユニットの変形の図である。
【図１０】本発明の実施形態における中間解像度のデータを格納する付加的なバッファを有するシステムのブロック図である。
【発明を実施するための形態】
【００４７】
本明細書に説明するピクセルバッファリング技術は、オンチップメモリのサイズを入力フレームサイズから分離し、同時にメモリ帯域幅消費を制限する。
【００４８】
このアーキテクチャは、２つの両極端の間の有利で柔軟な妥協を提供する。図１のシステムは、小さいオンチップバッファメモリを使用するが、メモリ帯域幅は過剰である。全幅の高解像度ピクセルバッファを有する図２のシステムは、法外に大きいオンチップバッファメモリ量という犠牲を払って、メモリ帯域幅を最小にする。いずれの手法も、ビデオ解像度が低い場合は実現可能であるが、解像度が高まる時に両方の欠点が明らかになる。適切な倍率及びバッファサイズの選択により、説明する技術は、コストと帯域幅と画像品質との適切な均衡を求めることを可能にする。説明する例は、主に高解像度ビデオ処理システムに関するが、低解像度システムに同じく適用することができ、この場合、既存の設計に優る更に別の節約を行うことができる。
【００４９】
下記の例を動き補償フレームレートコンバータの状況で説明する。しかし、当業者は、この技術を様々な画像処理用途及びビデオ処理用途に適用することができることを認めるであろう。
【００５０】
本明細書では「アプリケーション」という用語をバッファリングされたピクセルデータを使用する処理ブロック又はモジュールを説明するのに使用する。一般的にアプリケーションは、ピクセルバッファリングシステムと同じハードウエアデバイスの一部として具現化され、例えば、汎用コンピュータ上で作動するソフトウエアアプリケーションと混同しないようにされなければならない。動き補償フレームレートコンバータは、バッファリングされたピクセルデータを使用するアプリケーションの一例であり、このアプリケーションは、各々がピクセルデータを異なる手法で使用するいくつかのアプリケーションとして具現化することができることが分かるであろう。
【００５１】
図３は、高解像度ビデオフレームがメモリ３００に格納されるシステムの簡単なブロック図を示している。縮小ユニット３０５は、高解像度フレームを低い解像度のものに変換し、低解像度ピクセルデータを低解像度バッファ３１０に格納する。メモリ帯域幅消費を最小にするために、縮小画像の全幅のバッファが好ましい。
【００５２】
縮小処理は、画像スケーリングのための公知の技術のうちのあらゆるものを使用することができる。低解像度バッファからのピクセルが出力画像内に出現することができるので、双３次型のようなある程度高い品質のスケーリング器が推奨される。
【００５３】
一部のアプリケーションに対しては、縮小データの解像度で全く差し支えない。そのようなアプリケーションを低解像度アプリケーション３１５として示している。フレームレートコンバータの例では、以下に説明するように、動き推定器を低解像度アプリケーションとして作動させることを可能にすることができる。
【００５４】
バッファ制御ユニット３２０は、高解像度画像データを高解像度アプリケーション３３５に提供する。高解像度アプリケーションは、図２に示すような高解像度ピクセルデータを含む最大サイズのピクセルデータバッファへのアクセスを有するかのように作動する。実際にはそのようなバッファは存在しない。バッファ制御ユニット３２０は、小量の高解像度データを高解像度バッファ３３０内に維持する。アプリケーション３３５がピクセルデータを要求すると、バッファ制御ユニットは、そのピクセルデータが利用可能である場合には、それを高解像度バッファ３３０から供給する。データが高解像度バッファから利用可能ではない場合には、バッファ制御ユニットは、データを低解像度バッファ３１０から拡大器３２５を通じて供給する。低解像度データの縮尺が高解像度フレームのものと適合するように、拡大器の比は、縮小器３０５の比に適合する。高解像度アプリケーション３３５は、いずれかの特定のピクセルが低解像度経路を通じて供給されたか否かを把握する必要はない。当然ながら、縮小処理中には高周期情報が失われる。出力を構成するのに拡大データが使用される場合には、高周期情報の欠如は、画像の目視可能な不鮮明化をもたらす場合がある。
【００５５】
バッファ制御ユニット３２０は、可能な場合は必ず、高解像度アプリケーション３３５によって要求されるデータが高解像度バッファ３３０に存在することを保証する。
【００５６】
一例では、高解像度バッファ３３０内のピクセルデータストレージは、矩形ブロックに編成される。これらのストレージブロックのサイズは、バッファリングシステムの最良の性能に関して選択することができ、高解像度アプリケーション３３５による処理に使用されるいずれかのブロックがある場合には、そのブロックサイズとは異なる場合がある。高解像度ストレージのブロックへの分割は、拡大器３２５及び低解像度バッファ３１０からの拡大データの領域の要求に対するバッファ内容の好ましい細分性における管理を可能にする。
【００５７】
同じく低解像度バッファ３１０も、ピクセルデータを矩形ブロックで格納することができる。例えば、縮小器３０５及び拡大器３２５に使用される倍率によって高解像度ストレージブロックサイズに関連する低解像度ストレージブロックサイズを選択することを特に好適とすることができる。このようにして、１つの低解像度ブロックは、１つの高解像度ブロックに対応する。
【００５８】
メモリキャッシュは公知である。従来のメモリキャッシュは、データに対する要求を特定のメモリアドレスから受け取り、このデータを要求が行われたデバイスに供給する。初めてデータピースが要求される場合は、このデータピースは、メモリからバスを通じて取り出される。２回目に要求された場合には、データをメモリから再度取り出すのではなく、キャッシュから供給することができるように、データはキャッシュ内で複製される。これは、「キャッシュ・ヒット」として公知である。キャッシュ内のストレージの量は比較的小さく、従って、キャッシュが作業データセット全体の複製物を保持することは一般的に可能ではない。これは、画像データ又はビデオデータの場合にそうであるように、ワーキングセットが大きい場合に特に適用される。一般的にキャッシュ内にロードされる新しいデータピースは、別のデータピースを押し出すことになる。押し出されたデータピースが再度要求された場合には、それをメモリから再度取り出すことが必要になる。読み取り要求によってデータがメモリから取り出される状況は、「キャッシュ・ミス」として公知である。キャッシュのサイズ、マッピング規則、及び置換ポリシーが、キャッシュの挙動を決定し、これらは、汎用性能、又は特定のアプリケーションにおける性能に関して選択することができる。
【００５９】
先取りは、データピースがキャッシュから近々に要求さることになることを予想することができる時にキャッシュと共に使用される技術である。先取りは、データが最初に要求される時にキャッシュ・ヒットが発生するように、データをキャッシュ内に転送する。この転送は、ビデオアプリケーションにおいて、例えば、ピクセルブロックがラスター走査順序で処理されている場合に適切なものとすることができる。１つのブロックの処理が完了する直前に次のブロックの処理が始まるのに次のブロックに関するデータが即座に利用可能であるように、次のブロックに関するデータをキャッシュ内に取り出すための先取り命令を出すことができる。先取りは、帯域幅消費を低減しないが、キャッシュ・ミスに関する待ち時間（遅延）を隠すのに確かに役立つ。先取りが使用される場合には、先取りデータが、他のデータをそれが依然として使用状態にある間にキャッシュから押し出すことになり、付加的なキャッシュ・ミスを引き起こす可能性を考慮しなければならない。
【００６０】
高解像度バッファ３３０及びコントローラ３２０は、高解像度バッファにはないデータに対する要求により、このデータがメモリから取り出されることがない点で従来のキャッシュとは異なる。代替的に、データは、低解像度バッファ３１０から拡大器３２５を通じて提供される。このようにしてメモリアクセスの待ち時間が常に回避される。
【００６１】
高解像度バッファ３３０を埋める上で「キャッシュ・ミス」のような手段がない場合には、何らかの他の機構を設けなければならない。バッファコントローラ３２０は、この機能をアプリケーション３３５へのデータの供給と並行して実施する。
【００６２】
バッファ制御ユニット３２０の構造を図５に示している。読み取りコントローラ５００は、アプリケーションから画像データブロックに対する要求を受け取る。高解像度バッファ５０５から必要とされるデータを決定するために、この要求は、例えば、この要求を高解像度ストレージブロックサイズに対してマップすることによって処理される。次に、高解像度バッファが要求データを含むか否かを決定するために、このバッファが照会される。バッファを照会するための機構は、キャッシュ設計に使用されるものと類似の技術を使用することができる。例えば、バッファリングデータ５１５の各ブロックと共にタグ５１０が格納され、このタグは、フレーム内のピクセルデータの座標から、又はメモリ内のデータのアドレスから導出することができる。この場合、バッファは、特定のタグに対応するデータを取得することを可能にする内容アドレスメモリ（ＣＡＭ）として具現化することができる。
【００６３】
要求データが高解像度バッファ内に含まれる場合には、データは、経路５２０を通じてマルチプレクサ５２５に供給される。要求データが高解像度バッファ内に含まれない場合には、要求は、拡大器に（更に拡大器から低解像度バッファに）送られ、低解像度データを拡大したものが経路５３０を通じて供給される。代替的に、低解像度データを拡大することに関連付けられた待ち時間の大部分が、高解像度バッファの照会に取られる時間の背後で目立たないように、データに対する要求は、高解像度バッファと拡大器に同時に送ることができる。
【００６４】
任意的に、データに対する要求は、バスを通じてメモリに送ることができ、高解像度のものが、経路５３５を通じてマルチプレクサに供給される。一般的に、システムは、メモリへのアクセスに関する有意な待ち時間及び帯域幅消費を回避するために、データを低解像度バッファ経路又は高解像度バッファ経路のいずれかを通じて供給する。それにも関わらず、一部のアプリケーションでは、データをメモリから供給するという選択肢を有利とすることができる。
【００６５】
マルチプレクサ５２５は、読み取りコントローラ５００の制御下で、出力５４０において適切なデータをアプリケーションに供給するように様々なデータ経路の間で切り換えを行う。
【００６６】
先取りコントローラ５４５は、メモリからデータを読み取り、それを高解像度バッファに格納するように機能する。理想的には、データがアプリケーションによって要求される前に、全てのデータが取り出されてしまっており、高解像度バッファ内で利用可能になる。実際には、データの利用可能性は、要求の予想可能性、高解像度バッファ内のストレージポリシー（すなわち、１つのデータピースを格納することが、別のもの押し出しをもたらすか否か）、及びメモリインタフェースに適用されるレート制御のような他のファクタに依存することになる。一般的に、先取り制御アルゴリズムは、アプリケーションの特性に依存することになる。
【００６７】
フレームレートコンバータの映像構築段階は、高解像度アプリケーションとして作動する可能性が高い。入力フレーム内のピクセルデータを取得すべき場所を識別するために、動き推定段階中に決定される動きベクトルが使用される。次に、得られたピクセルデータは、場合によって他の入力フレームから得られた他のピクセルデータと合成され、表示のための出力フレーム内に入れられる。
【００６８】
動きベクトルが、映像構築器の正確なデータ要件を把握することを可能にするように、動き推定アプリケーションが十分に先行して作動する場合には、映像構築アプリケーションにおける先取り制御は容易である。この場合、先取り制御は、予想されるデータ要求のＦＩＦＯ（先入れ先出し）待ち行列を含むことができ、データは、映像構築器によって要求される直前に高解像度バッファに供給される。
【００６９】
実際の動きベクトルが十分に先行して利用可能ではない場合には、先取りコントローラは、映像構築器が行う可能性が高い要求を識別しようと試みることができる。
【００７０】
予想法の一例は、動きが、前のフレーム間隔中の同じ場所に存在したものと同じになると仮定することである。移動物体は、通常は移動し続け、従って、この仮定は、通常、良好な予想をもたらす。例外は、ベクトルが、離遠した物体の動きに対応する移動物体のエッジである。ベクトル場の動き補償は、これらの場合の予想を改善することができる。
【００７１】
多くの場合に、フレーム内で大半を占める動きは、カメラの動き、例えば、水平パンの場合におけるものに起因する。この動きを表すベクトルは、広域動きベクトルとして公知であり、ベクトル場の平均値から導出することができる。シーンが移動物体を含む場合でさえも、中央値を用いて計算された平均は、多くの場合に、フレーム内のブロックの大部分における動きベクトルにつての良好な予想である広域動きベクトルを生成する。従って、広域動きベクトルは、先取りコントローラによる使用に適する別の予想をもたらす。
【００７２】
前のフレーム間隔からのベクトルを個々に使用する場合、又は広域動きとして使用する場合のいずれにおいても、予想の精度は、フレーム間隔毎にそれ程変化しない動きを拠り所とする。幸いにも、これは一般的に言えることである。動き推定が現在のフレーム間隔内で進行中に、これらのベクトルを予想の中に組み込むことができ、小さい動き変化に対応することが可能になる。
【００７３】
予想が失敗した場合には、要求されたピクセルデータは、高解像度バッファ内では利用可能とはならず、従って、代わりに低解像度ピクセルデータが供給されることになる。予想は、移動物体又は急激な動き変化が存在する場合に失敗する可能性が最も高い。モーションブラーは、移動物体の外見を不鮮明にする可能性があり、閲覧者は、不規則に移動する物体を追跡することができにくくなる。従って、低解像度ピクセルデータの供給は、高解像度の内容が不在であるか又は容易に知覚されないかのいずれかである画像区域に適合する可能性が高い。その結果、予想失敗の視覚的影響は低減される。
【００７４】
予想が良好に機能する理想的な場合には、高解像度ピクセルデータの供給に起因するメモリ帯域幅消費は、全てのピクセル（又はピクセルブロック）が一度読み出される最適な場合に近づくと予想することができる。実際には、高解像度アプリケーションによって要求されるピクセルブロックは、高解像度バッファ内に使用されるストレージブロックグリッドと整合する可能性が低い。
【００７５】
図７ａは、不整合データ要求の一般的な場合を示している。ブロック７００が要求された場合には、４つのストレージブロック７１１、７１２、７１３、及び７１４からのピクセルが出力されなければならない。高解像度アプリケーションがブロックをラスター走査順序で処理する場合には、高解像度バッファのキャッシュ効果は、メモリ帯域幅消費を４×から２×に低減することができる。例えば、ブロック７２０が要求された場合には、ストレージブロック７１３及び７１４は、前のアクセスからのバッファ内に留まり、２つの付加的なブロック７３１及び７３２が必要である。
【００７６】
リソースが許す場合には、より大きい高解像度バッファにより、１つの行の処理中にロードされたブロックが、次の行が処理される時の再使用に向けて利用可能なままに留まることを可能にすることができる。例えば、ブロック７４０が要求された場合には、ストレージブロック７１２及び７１４はバッファ内に留まり、付加的なブロック７５１及び７５２が必要である。次に、ブロック７６０が要求された場合には、ブロック７１４、７３２、及び７５２はバッファ内に留まり、１つの付加的なブロック７５３が必要である。この場合、メモリ帯域幅消費を１×に近づけることができる。
【００７７】
代替的に、ブロック処理順序をラスター走査から傾斜レイアウト、又はアプリケーションが許す場合はモートン順序レイアウトに変更することにより、バッファサイズの大幅な増加なしにキャッシュ性能の改善を得ることができる。
【００７８】
動き補償システムでは、ベクトル場が均一な場合には、ブロック要求は、詰まったグリッド（ブロック７００、７２０、７４０、及び７６０等）で配置されることになる。ベクトル場が均一ではない場合には、７４０、７６０、７８０のようなブロック要求のシーケンスがもたらされる場合がある。このシーケンスは、全く予想可能にすることができるが（ベクトル場の前の情報が与えられた場合）、バッファのキャッシュ性能を狂わせる可能性も高い。例えば、ストレージブロック７３２及び７９２はバッファ内に留まることができるが、ブロック７３１及び７９１は廃棄されてしまっている可能性が高い。
【００７９】
動き推定器は、低解像度アプリケーションとして作動するのに非常に適する処理である。信号調節は、動き推定器の性能を改善する公知の技術であり、多くの場合に、画像データのローパスフィルタ処理を含む。信号調節が有利である理由は、ノイズ低減、及び差絶対値和（ＳＡＤ）のようなブロック適合手段の非常に高周期の細部への過感度を含む。その結果、低い解像度に縮小されたデータに対して動き推定器を作動させることには、通常、非常に僅かな欠点しか存在せず、時にはある程度の利点が存在する。
【００８０】
それにも関わらず、動き推定器は、ある程度予想可能なデータへのアクセスを行い、局所性の程度は、動き推定器を高解像度処理として具現化するように選択される場合に、高解像度バッファが良好に機能することができるようなものである。
【００８１】
動き推定器では、ピクセルデータブロックの比較は、一般的に、１つのフレーム内の１つのグリッド整合ピクセルブロックと、隣接フレーム内のいくつかの不整合候補ブロックとの比較である。図７ｂには、いくつかの不整合候補ブロックを示している。候補ブロック位置の選択は、本明細書では解説しないが、当業者には馴染み深いものになる複雑な題材である。この選択は、基本的に、物体の動きを予想する問題である。候補ブロック位置の集合は、一般的に、動きベクトル場が時間と共に改善して適合することを可能にする小さい位置変化を伴って、１つ又はそれよりも多くの可能性が高い動きベクトルの周囲に集塊することになる。それぞれ４つ及び２つの候補を有する集塊７７７及び７７８を示している。いくつかの候補場所は、ピクセルデータストレージブロックの同じ集合からのデータを必要とするので、バッファが良好に機能することを見ることができる。
【００８２】
各候補ブロック位置は、候補が試験されるに時に要求されることになるピクセルデータの区域を表すので、候補ブロック位置は、これらの位置を十分に先行して予想できる限り、先取りコントローラ５４５への有利な入力を供給する。先取りコントローラは、アプリケーションからデータ経路５５０を通じて、この種のデータを含むことができる入力を取得する。
【００８３】
図４は、更に別の例示的なシステムにおいて実施することができる付加的な細部を示すブロック図である。
【００８４】
多くのアプリケーションでは、各ビデオフレームは何回か処理される。動き推定器の例では、検索は、１対のフレーム間で発生する。最初の動き推定は、フレーム０とフレーム１の間で発生する。２回目の動き推定はフレーム１とフレーム２の間、３回目の動き推定はフレーム２とフレーム３の間で発生し、以降同じように続く。シーケンス内の最初のフレームを除き、各フレームは、２つの動き推定によって必要とされる。より高度な動き推定器は、異なる間隔及び異なる方向にわたって検索を実施することができる（例えば、フレームｎの内容をフレームｎ−１内で検索する段階は、フレームｎ−１の内容をフレームｎ内で検索する段階と同じではない）。その結果、各ビデオフレームは、２回、３回、又はそれよりも多い回数読み出されることになる場合がある。フレーム全体をバッファストレージに格納するのは通常は実現可能ではないので、上記に応じてメモリ帯域幅は増大する。
【００８５】
別の実施形態において、メモリ４００は、縮小器４１０によって処理される高解像度ビデオフレーム４０５のためのストレージを含む。低解像度バッファ制御４１５は、ここでもまた、縮小ピクセルデータを低解像度バッファに格納し、更にこれらのデータをメモリ４２０に戻す。同じフレームが２回目に処理される場合には、低解像度バッファコントローラは、低解像度フレーム４２０をメモリから取得し、高解像度フレームを再度縮小する必要性を回避する。
【００８６】
高解像度フレームのメモリサイズがＢであり、かつ０．５という一般的な縮小係数が使用される場合には、低解像度フレームのサイズはＢ／４である。最初にフレームが処理される場合には、メモリ帯域幅消費は、Ｂの読み取りにＢ／４の書込みを加えたものである。２回目にフレームが処理される場合には、メモリ帯域幅消費はＢ／４の読み取りである。ｎ回目に処理されるフレームでは、合計メモリメモリ帯域幅消費は、縮小フレームを格納しないシステムにおけるｎＢと比較すると（１＋ｎ／４）Ｂである。従って、一度よりも多くアクセスされるあらゆるフレームにおいて帯域幅の節約が存在する。縮小器４１０は少数のフレームしか処理しなくてもよいので、シリコン面積を節約するか又は電力消費を低減する機会も存在する。
【００８７】
縮小器４１０は、残差出力を生成することができる。残差は、高解像度ピクセルデータと、低解像度ピクセルデータが拡大される時に最終的に再現されることになるピクセルデータとの間の差である。残差データは、高解像度ピクセルデータと同じ解像度を有するが、圧縮することが比較的容易であるという利点を有する。残差符号化器４２５は、残差データを圧縮して、それを４３０にあるメモリに格納する。
【００８８】
この場合、バッファ制御ユニット４３５は、高解像度ピクセルデータ３３０のバッファではなく、符号化された残差データ４４０のバッファを維持する。高解像度アプリケーションがピクセルデータを要求し、適切な残差データピースが残差バッファ４４０内で利用可能である場合には、残差は４４５で復号され、低解像度データを拡大したものに追加される。これは、高解像度データを直接供給することと等しい。
【００８９】
残差データの圧縮性は、かなり高い周期の細部の区域における非常に僅かなものから、高解像度フレームが非常に僅かな高周期細部のみを有する区域におけるかなりのものまでの間で変化する。最悪の場合には、メモリから取り出さなければならない残差データのサイズは、高解像度ピクセルデータが供給された場合のものと同じである。平均すると、残差データは小さく、メモリ帯域幅が更に低減される。更に、圧縮された残差データは、残差バッファ４４０内で小さい空間しか占有せず、バッファの有効サイズを増大させ、これは、バッファコントローラ４３５が、アプリケーションに低解像度ピクセルデータを供給しなければならなくなる機会が少ないことを意味する。
【００９０】
図６は、図４のシステムにおいて機能するように修正された図５のバッファ制御ユニットを示している。高解像度ピクセルデータバッファは、残差バッファ６００と、図４のブロック４４５に対応する残差復号器６０５とで置換される。
【００９１】
復号された残差データは、６１０において低解像度データと加え合わされて、高解像度ピクセルデータがマルチプレクサに供給される。バッファリングなし残差データ経路６１５が使用される場合には、このデータは、残差復号器に伝達されなければならない。
【００９２】
残差データは、好ましくは、高解像度バッファによって使用されるストレージブロックサイズと同じサイズのブロックで格納することができる。残差データの圧縮には様々な方法を適切なものとすることができ、そのような方法は、画像及びビデオの符号化の分野から公知である。離散余弦変換（ＤＣＴ）又はウェーブレットに基づく方法が適切である。そのような方法を使用すると、残差データの非可逆符号化を考慮することも可能になる。非可逆符号化は、例えば、ＪＰＥＧ画像符号化又はＭＰＥＧビデオ符号化に使用される。
【００９３】
本明細書に説明するシステムでは、残差の非可逆符号化は、メモリ帯域幅を更に低減することができ、可逆残差符号化を用いて可能なものよりも遥かに大量の残差を高解像度バッファに格納することを可能にすることができる。考えられる欠点は、低解像度画像を拡大したものと残差とでの高解像度ピクセルデータの再構成がもはや完全なものではないということである。多くの場合に、損失の程度は視覚的に知覚不能とすることができ、殆どの場合には、再構成された高解像度データは、かなりの程度の情報損失をそれ自体が意味する低解像度データを拡大したものの使用よりも好ましいものになる。非可逆残差圧縮を使用するか否か、及び使用される圧縮の程度は、アプリケーションに依存することになる。
【００９４】
残差を計算することにより、高解像度画像の内容を解析する機会も与えられる。残差が格納されない図３のシステムにおいてさえも、この解析を実施することにはかなりの利点が存在する。ブロックの残差が小さい場合には、画像のその部分の内部には、僅かな高周期内容も存在しない。バッファの使用及び帯域幅消費を最適化するために、画像内の高周期細部の分散の情報をバッファコントローラ３２０を使用することができる。
【００９５】
ブロックにおける残差が、高解像度ピクセルデータと低解像度ピクセルデータとの間で有意な視覚差が存在しないことになると決定することができる程に十分に小さい場合には、高解像度アプリケーションによって高解像度データが要求されることになると予想される場合であっても、バッファコントローラは、メモリから高解像度データをロードしないことを選択することができる。高解像度バッファ内のデータの不在により、代わりに低解像度データが供給されることになり、帯域幅消費の節約が提供されることになる。
【００９６】
アプリケーションによって供給される情報を用いて類似の恩典を得ることができる。図５及び図６は、両方共にアプリケーションデータを先取りコントローラに供給する入力５５０及び６２０を示している。アプリケーションデータは、上述したように、動きベクトルデータと広域動きベクトルデータとを含むことができるが、更に別のデータ、例えば、アルゴリズムの性能に関するものを含むことができる。
【００９７】
フレームレートコンバータの例では、映像構築器は、合成画像を構成するときに動きベクトル及びピクセルデータを解析することができる。先取りコントローラが帯域幅消費を最適化することを可能にするアプリケーションデータを映像構築器が供給することができるいくつかの状況が発生する場合がある。
【００９８】
上述したように、一般的な映像構築器は、いくつかの入力フレームからいくつかの異なる動きベクトル場に従って投影されたピクセルデータを用いて合成画像を作成する。映像構築器の仕事は、可能な最良の合成出力を生成するために、異なる投影の間の不適合を解決することである。一般的に出力は、画像内のあらゆる特定の位置における投影の一部又は全ての間の重み付きの混合物である。
【００９９】
一例では、映像構築器は、解析段階と合成段階という２つの部分に分割される。この場合、解析段階は低解像度アプリケーションとして作動し、合成段階は高解像度アプリケーションとして作動する。
【０１００】
解析段階が、投影のうちの全て又は大部分が互いに適合すると決定する場合には、混合は不要であり、適合する投影のうちのいずれのものも、出力画像において単独に使用するのに十分に良好なものである。この場合、解析段階は、投影画像のうちの１枚だけが合成段階によって必要とされることを示すアプリケーションデータを先取りコントローラに送ることができる。この投影に対応する高解像度データが、高解像度バッファ内に取り出されることになるが、他の投影に関するデータは、取り出されることにはならない。
【０１０１】
合成画像の正当性の信頼度が低い場合には、様々な種類のエラー隠蔽が使用される。１つの特定の種類のエラー隠蔽は、出力画像にローパスフィルタ又はぼけ処理を適用することである。解像度がフィルタ処理によって劣化されることになる場合には、高解像度データを読み取ることには殆ど意味がないことを認識されるであろう。従って、アプリケーションデータをバッファコントローラに送ることにより、エラー隠蔽の使用を示すことができる。バッファコントローラは、高解像度データを読み取ることを回避することになり、帯域幅消費の低減がもたらされる。
【０１０２】
合成段階によって投影画像の部分集合しか必要とされないと決定することができる場合はいつでも、類似の節約を行うことができる。
【０１０３】
上述の例がフレームレート変換以外のアプリケーションに関連すること、及び先取りコントローラがメモリ帯域幅消費を適切な手法で最適化することを可能にするアプリケーションデータを多くのアルゴリズムが供給することができることになることは明らかであろう。
【０１０４】
上述の例は、バッファコントローラが、低解像度データで十分になることを示す情報に基づいて、高解像度データのある一定のブロックを取り出すことを回避する状況を表している。高解像度データが望ましいものになるが、いずれかの理由から利用可能ではない他の場合が存在する可能性がある。理由は、高解像度バッファ内の不十分な空間、アプリケーション又は先取りコントローラによる不正確な予想、又は高解像度データを供給するには不十分な利用可能メモリ帯域幅を含むことができる。
【０１０５】
この後者の場合には、システムは、消費されるメモリ帯域幅の量に対して制限を課すことができる。図７の説明及び不整合データ要求の解説において、要求のアラインメント及びバッファのキャッシュ性能に基づいて、メモリ帯域幅消費が要求データ量の１×と４×との間で変化することができると示した。
【０１０６】
一例では、高解像度データ先取りにレート制御を適用することができる。例えば、要求データ量の２．２×のメモリ帯域幅を典型的に消費することになるシステムを１．５×しか消費しないように制限することができる。帯域幅制限は、高解像度データのある一定のブロックを読み取ることを回避し、その代わりに低解像度データをアプリケーションに供給することによって適用される。
【０１０７】
符号化ビットストリームを望ましいデータレートで生成するという要件が高頻度で存在するビデオ符号化では、レート制御アルゴリズムが使用される。ビデオ符号化器は、各符号化ブロックに対して使用される量子化の程度を変更することによってデータレートを制御する。高解像度データがメモリから読み出される図３のシステムでは、レートコントローラは、各ブロックに関するデータを読み取ること又は読み出さないことのいずれかを行うことができる。図４のシステムでは、残差データが適切に符号化された場合に、レートコントローラは、各ブロックにおける残差のうちの全てを読み取ること、一部を読み取ること、又はいずれも読み出さないことを選択することができる。それによって図３のシステムにおいて可能なものよりも高度なレート制御を可能にすることができる。
【０１０８】
典型的なレート制御アルゴリズムは、ターゲットレートよりも大きい短期の変動を多くの場合に許容しながら、ターゲットレートを長期的に得ることになる。ビデオ処理のようなフレーム単位のシステムでは、利用可能な帯域幅をフレームにわたって適切に分散させることが望ましい。レート制御は、フレームの上部部分に高解像度データを供給することがフレームの下側部分でデータが不足することを意味する場合には、そうすることで帯域幅を浪費すべきではない。一方、存在しない高解像度細部を予想して、帯域幅を過度に確保すべきではない。残差の計算に関して説明したもののようなフレーム内の細部の分散の解析は、レートコントローラが帯域幅を適切に割り当てるのに使用することができるデータを提供する。アプリケーションデータが、画像のうちの一部の部分に関する高解像度データを読み取ることを先取りコントローラが回避することも可能にする場合には、アプリケーションデータをレートコントローラに供給して、レート制御計算の中に組み込むことができる。
【０１０９】
図７は既に説明しており、データ要求のアラインメントの帯域幅に対する効果も解説した。高解像度データが高解像度バッファから利用可能ではない場合にもたらされる別の問題は、出力画像内で高解像度データと低解像度データの間の遷移が発生する場合の目視可能な不連続の可能性である。
【０１１０】
図８ａは、高解像度データが完全には利用可能ではない状況を示している。８００のような陰付きに示すストレージブロックは、高解像度データが利用可能なブロックであり、８０５のような陰なしブロックは、高解像度データが利用可能ではないブロックである。ピクセルデータブロック８１０に対する要求は、完全に高解像度バッファから満たすことができる。しかし、ピクセルデータブロック８１５は、高解像度バッファ内では利用可能ではないストレージブロック８０５からのデータを必要とする。従って、要求のうちの少なくとも部分８２０は、低解像度データを用いて満たさなければならない。
【０１１１】
図８ｂは、ブロック８１０に対する要求の後のある時点で発生する更に別のピクセルデータブロック８５０に対する要求を示している。前にバッファ内で利用可能であったストレージブロック８００に関する高解像度データ、従って、要求の部分８５５は、低解像度データを用いて満足される。
【０１１２】
８１５又は８２５のようなブロックが要求される場合には、読み取りコントローラは、要求ブロックに対して低解像度ピクセルデータのみを供給するか、又は利用可能な高解像度ピクセルを供給し、かつ残りの部分を低解像度バッファから供給するかという選択肢を有する。この決定は、利用可能な高解像度ピクセルの比率、又はブロック内でのこれらのピクセルの分散に基づくことができる。高解像度ピクセルと低解像度ピクセルとの組合せが供給される場合には、図５の読み取り制御ユニット５００は、高解像度バッファ内でのデータの部分利用可能性に応答して、ピクセル単位でマルチプレクサ５２５を制御しなければならない。図６に示す類似のユニットは、類似の挙動を示している。
【０１１３】
解像度の不連続に対する手法は、アプリケーションに強く依存する。データが要求された場合に、どのピクセルを高解像度バッファから供給することができ、どれを低解像度バッファから供給することができるかは常に把握される。この場合、アプリケーションは、可能性が高いあらゆる不連続の可視性を決定するために、残差サイズ、又は画像解析中に得られる他の情報のようなデータを考慮することができる。１つの選択肢は、平滑化後処理アプリケーションによって不連続を隠蔽することである。この手法は、Ｈ．２６４のようなビデオ復号器において公知であるデブロッキング手法と類似のものと捉えることができる。代替的に、低解像度データのみの供給は、ブロック内の不連続を回避することになるが、必ずしもこれらのブロックのエッジにおける不連続を回避することにはならない。図８ａでは、ピクセルデータブロック８１５がアプリケーションに供給される時に、内部エッジ８２５及び８３０における不連続が把握される。図８ｂでは、例えば、映像構築器アプリケーションにおいてピクセルデータが出力画像に組み立てられる時になって初めて外部エッジ８６０及び８６５における不連続を把握することができる。
【０１１４】
代替の手法は、データが供給される時にフィルタ処理又は混合処理を適用する。図９は、図５のシステムに対する適切な修正を示すが、この修正は、図６のシステムにも同じく適用することができる。マルチプレクサは、混合ユニット９１０によって置換され、混合ユニット９１０は、読み取り制御ユニット９００からの適切な制御９１５により、高解像度データと低解像度データの間の滑らかな遷移を与える。混合制御データは、ピクセル単位の切り換えを与えるのではなく、この場合、各位置に使用するべき低解像度データの比率を示す小数値を与えなければならない。低解像度データは常に利用可能であり、高解像度データはそうではない場合があるので、混合領域は、常に不連続線の高解像度側に位置する。混合ユニットの詳細な制御は、アプリケーションと各特定の場合に使用される先取りアルゴリズムとに依存し、特に、読み取り要求のパターン及び高解像度バッファ内でのデータの利用可能性を先行して把握することができる程度に依存することになる。
【０１１５】
ビデオ画像は、多くの場合に、輝度データと色度データを用いて表される。輝度データは、高解像度の白黒画像を含み、色度データは、有色画像を形成するのに必要とされる追加データを含む。色度データは、一般的に部分サンプリングされ、従って、対応する輝度データよりも低い解像度にある。画像内の細部及び鮮明度の知覚は、主に輝度データからもたらされ、画像の劣化が容易に知覚される前に色度データからかなりの量の情報を削除することができることは公知である。
【０１１６】
別の例では、バッファコントローラは、輝度データと色度データを別個に処理する。データを高解像度バッファ内にロードするか否かの決定を行う場合に、先取りコントローラは、輝度データに対して、対応する色度データに対して行うものとは異なる決定を行うことができる。この決定は、例えば、輝度データ及び色度データ内の高周期細部の量、アプリケーションからのデータ、又はレートコントローラの要件に基づくとすることができる。画像データに対する要求は、輝度データ又は色度データが高解像度バッファ内で利用可能であるか否かに従って処理され、取得不能なあらゆる成分は、低解像度バッファから拡大器を通じて供給される。システムは、殆どの色度データが低解像度バッファから供給され、帯域幅を節約し、かつ輝度データに対してより大きい高解像度バッファ空間を作るように構成することができる。代替的に、システムは、全ての色度データを低解像度バッファから供給することができる。
【０１１７】
上述の例では、画像データが２つの解像度で存在するシステムを説明した。同じ技術をあらゆる個数の解像度に拡張することができることは明らかである。例えば、システムは、中程度の解像度の画像バッファを追加することができる。図１０は、バッファ制御ユニット１０００が高解像度バッファ１０１５と中解像度バッファ１０１０の両方を管理する図３のシステムの修正を示している。スケーリング器１００５は、高解像度から中解像度への縮小及び中解像度から高分解能への拡大の両方を実施する。システムは、解析が、低解像度データが使用された場合に画像内容が許容不能に劣化することになることを示すが、高解像度データの使用が際立った利点を殆どもたらさないことになる場合に、中解像度の画像データをバッファリングすることを選択することができる。中解像度バッファ１０１０は、高解像度バッファ１０１５と共に、各解像度のデータに割り当てられるストレージの比率を変更することができる単一のメモリ１０２０に統合することができる。高解像度データではなく中解像度データのストレージは、メモリ１０２０の有効容量を増大させ、システムのバッファリング性能を改善する。
【符号の説明】
【０１１８】
３００  外部メモリ
３０５  縮小
３１０  低解像度バッファ
３１５  低解像度アプリケーション
３２５  拡大
【図３】
2014053896.tif 000003
【図４】
2014053896.tif 000004
【図５】
2014053896.tif 000005
【図６】
2014053896.tif 000006
【図７】
2014053896.tif 000007
【図９】
2014053896.tif 000008
【図１０】
2014053896.tif 000009
【図１】
2014053896.tif 000010
【図２】
2014053896.tif 000011
【図８】
2014053896.tif 000012
【外国語明細書】
2014053896000001.pdf