JP2013533540A - 適応画像レンダリングおよびインポスターの使用 - Google Patents

Abstract

周囲の環境に適合し、またユーザーの経験エクスペリエンスの質の認識を向上しうる方法で、画像および／または画像の集合をレンダリングできる。表示するために画像が要求されると、その画像のレンダリングされたバージョンがあるかどうか決定される。画像のレンダリングされたバージョンがない場合、インポスター画像が表示される。インポスター画像は、任意の色および／またはパターンを含みうる。画像の適切なレンダリングされたバージョンがある場合、インポスターバージョンの代わりにレンダリングされたバージョンが表示されうる。インポスターまたはレンダリングされた画像が表示されている間、画像を取得でき、他の解像度（たとえば、連続的に解像度がより高くなる）でレンダリングできる。解像度の選択は、利用可能な送信帯域幅、表示速度、または他の検討事項に適合されうる。

Description

本発明は、適応画像レンダリングおよびインポスターの使用に関する。

[0001]画像は基本的なコンテンツソースからレンダリングされる。多くのコンテンツソースによって、様々な解像度で、または任意に高解像度で画像をレンダリングできる。しかし、画像のレンダリングは計算集約型であるので、あるいは、入力／出力（Ｉ／Ｏ）応答時間のためにネットワークまたはより遅いローカル記憶装置から画像をダウンロードすることは長い時間がかかる場合があるので、スクリーン上に画像を表示するには長い時間がかかる場合がある。したがって、レンダリングにはかなりの時間がかかることがある。実際には、表示される画像コンテンツは画像の集合（たとえば、画像検索に応答する多くの画像のセット）であることが多い。集合内のそれぞれの画像は別々にレンダリングされなければならない独自のソースを有するので、画像の集合のレンダリングに関わる時間は単一の画像のレンダリングと比較して何倍にもなる。

[0002]質の高いユーザーエクスペリエンスを提供する観点から、通常、画像のレンダリングにかかる時間に対処する方法が２つある。１つの方法は、画像が要求される前にそれらの画像をプリレンダリングすることである。この手法は、どの画像が要求されるか、およびどんな解像度で要求されるかを予想することを含む。この方法は、多数のプリレンダリングされた画像を格納すること、および将来のある時点で要求されるかどうかわからない画像をレンダリングするために計算リソースを充てることも含む。さらに、プリレンダリングされた画像が高解像度の場合、画像をレンダリングする際の遅延は回避されるものの、高解像度画像を送信するためにかかる時間の量によって依然として遅延が生じる場合がある。高解像度画像の集合が含まれる場合も、やはりこの遅延が何倍にも増加する場合がある。

[0003]画像のレンダリングにかかる時間に対処するためのもう１つの方法は、画像をオンデマンドでレンダリングして、画像がレンダリングされる間待つ必要があることをユーザーに伝えることである。この技法が使用される場合、ユーザーは、画像がレンダリングされる間待つように伝えるメッセージを示されるか、あるいは画像がレンダリングされる間、記号または動画（たとえば、砂時計の中を砂が落ちている、時計の上で針が動いている、等）を示される場合がある。通常、この技法は質の低いユーザーエクスペリエンスをもたらす。

[0004]いくつかのシステムは限られた形式のプリレンダリングを使用する。たとえば、画像は大量のデータを含む高解像度画像と、解像度が非常に低い小さなサムネイル画像との２つの形式で格納されうる。この手法の欠点は、低解像度のサムネイルを表示するか、あるいは送信またはディスプレイ上の描画に長い時間がかかる場合がある高解像度画像を表示するかの間で選択するよう、ディスプレイシステムに強制することである。

[0005]既存のプリレンダリングされた画像の利用可能性、ならびに画像が送信および／または描画されうる速度を考慮し、また、たとえ利用可能なプリレンダリングされた画像がない場合でもユーザーエクスペリエンスも向上させる方法で画像をレンダリングできる。

[0006]画像が表示される場合、画像レンダリングシステムは、レンダリングを行っている機械上で、プリレンダリングされた画像がローカルに利用可能かどうかを決定しようとする。利用可能な場合、その画像が表示されうる。利用可能な、適切なプリレンダリングされた画像がない場合、システムは「インポスター（ｉｍｐｏｓｔｅｒ）」と呼ばれるプレースホルダー画像を描画する。インポスターは、たとえば曖昧な色である場合がある。インポスターの出現により、インポスターは順次高い解像度で明確になる画像の第１反復であることをユーザーに示唆できる。しかし、インポスターは、基本画像からのどの実際の情報にも基づかない場合がある。したがって、高解像度画像の描画の初期の段階にインポスターが示す推測は錯覚にすぎないが、ユーザーエクスペリエンスを向上させる。画像の集合がレンダリングされる場合（たとえば、画像検索に応答する画像のセット）、プリレンダリングされた形式で利用できないそれぞれの画像はインポスター画像として表示されうる。

[0007]画像のために指定された場所に一旦何かが描画されると（描画されたアイテムがインポスターか、実際の画像の低解像度バージョンかに関わらず）、実際の画像、または画像の高解像度バージョンを取得する処理に移ることができる。適切なプリレンダリングされた画像がローカルに利用可能ではないと仮定すると、画像ソース（すなわち、ＪＰＥＧファイルなどの、レンダリングされるべき画像の基本モデルを含むデータ）が取得されうる。次いで、画像が高解像度でレンダリングされうる。適用可能であれば、集合内に含まれるべきいくつかの画像をレンダリングでき、この場合、集合の一部である別々の画像を取得およびレンダリングする処理をパラレルに行うことができる。低解像度画像またはインポスターと置換するために高解像度画像をレンダリングする考え方の１つの変化形は、より高い解像度の画像を連続的にレンダリングおよび描画して、それによって画像により焦点を合わせる処理をアニメートする（ａｎｉｍａｔｅ）ことである。インポスター画像が使用されると、連続する画像は、ますます増加する実際の画像データとインポスターデータとを混合できる。

[0008]画像がレンダリングおよび描画される方法は、様々なリソースの利用可能性および機能を考慮するように適応できる。たとえば、いくつかの画像フォーマットの特性は特定の解像度をレンダリングするための速い経路を提供するので（たとえば、ＪＰＥＧからは２５６または５１２ピクセルの解像度で画像を迅速にレンダリングできる）、特定のフォーマットの画像の利用可能性を、特定の解像度を選択するための基礎として使用できる。さらに、画像が描画および／または送信されうる速度を、画像のいくつの異なる解像度が描画されるべきかを選択するための基礎として使用できる。たとえば、連続的に解像度がより高くなる３０個の画像を１秒の間に表示することによって、焦点があってくる画像をアニメートしたい場合がある。しかし、環境の物理的機能により画像を３０フレーム／秒で描画および／または送信できない場合、システムは画像をレンダリングする解像度について異なる選択を行うことができる。反対に、環境により画像を高速で描画および／または送信できるが、それらの画像のレンダリングは遅い場合がある。言い換えれば、どの画像をレンダリングするべきか決定する場合、描画処理の遅さとレンダリング処理の遅さについての考慮とは別々に考慮されうる。

[0009]この概要は、以下の発明を実施するための形態においてさらに説明される概念の選択を簡単な形式で紹介するために提供される。この概要は、特許請求の範囲に記載された対象の主な特徴または本質的な特徴を識別することを意図するものではなく、また特許請求の範囲に記載された対象の範囲を限定するために使用されることを意図するものでもない。

[0010]連続的により高い解像度で画像がレンダリングされうる方法の例を示すブロック図である。 連続的により高い解像度で画像がレンダリングされうる方法の例を示すブロック図である。 [0011]例示的な画像集合のブロック図である。 [0012]コンテンツをレンダリングするために使用されうる、例示的なコンポーネントのブロック図である。 [0013]画像を提供する例示的処理の流れ図である。 [0014]本明細書に記載の対象によって実行されうる、いくつかの例示的適合のブロック図である。 [0015]本明細書に記載の対象の実装形態に関連して使用されうる、例示的なコンポーネントのブロック図である。

[0016]近年、コンピューティングにおいて、画像コンテンツは一層一般的になってきた。コンピューティングの初期には、通常、人とコンピューターとの間の対話はテキスト通信の形式で生じていた。現在、ユーザーは画像の形式でコンテンツを期待するようになり、画像の質と、それらの画像の配信におけるエクスペリエンスの質との両方について、ますます高い期待を持つようになった。電子メール、検索結果、ウェブページなどは通常画像を含み、ユーザーはこれらの画像が様々な種類の有線または無線接続を介してデスクトップコンピューターから無線電話までの範囲の多くの種類の装置に配信されることを期待する。

[0017]画像は、直接表示できない何らかの種類のモデルで格納される場合が多い。むしろ、画像はいくつかの解像度でピクセルにレンダリングされなければならないので、ディスプレイ装置にピクセルが表示されうる。画像をレンダリングする処理、特に高解像度画像をレンダリングする処理は、画像を生成するために必要な計算の量、または画像にＩ／Ｏ操作を実行するためにかかる時間の量の点でコストが高い。このような画像に対応するためにかかる時間の量は、それらの画像を受信する際のユーザーエクスペリエンスを低下させてしまう。レンダリングされる画像は集合（たとえば、画像検索のための検索結果を構成する画像の集合）の一部であることが多いので、集合をレンダリングするコストは単一の画像をレンダリングするコストよりも何倍も高くなる場合がある。

[0018]質の高いユーザーエクスペリエンスを提供することに関しては、レンダリングされた画像を提供する問題に対処するための多くの方法がある。ある方法は、ユーザーの要望に応じて画像をすぐに表示できるように、画像をプリレンダリングすることである。しかし、画像のプリレンダリングは、要求されるかどうかわからない画像の作成に大量の計算リソースおよびストレージを充てることを含むのでコストがかかる。画像は様々な解像度で要求される場合があり、これは画像のプリレンダリングはどの画像が要求されるかを予想するだけでなく、それらの画像がどんな解像度で要求されるかを予想することも含むことを意味する。さらに、利用可能な画像のセットは常に変化するので、画像のプリレンダリングは、要求される可能性がある新しい画像ごとに実行される必要がある継続的な処理である。

[0019]さらに、プリレンダリングは、画像が要求された後にその画像をレンダリングするために待つ必要がある時間の量を（事実上ゼロに）減少させるので、プリレンダリングは他の種類の時間コストを課すことができる。少数の異なる解像度（たとえば、低、中、高）だけで画像をレンダリングすることが可能な場合があるので、プリレンダリングされた高画質画像は利用可能な送信帯域幅の量、または画像が表示される装置の描画速度と適合できない場合がある。たとえば、中解像度および高解像度で画像が利用可能な場合、（応答時間および品質のトレードオフに関して）ユーザーエクスペリエンスを最適化するために、中解像度と高解像度の間のどこかの解像度で画像を表示するのが当然であろう。しかし、このような画像がない場合、システムは中解像度画像を提供することと、高解像度画像を提供することとの間で選択しなければならない。前者の選択は低い画質を提供することによってユーザーエクスペリエンスを低下させる場合があり、後者の選択はユーザー装置への画像の送信にかかる時間の量、またはディスプレイ上に描画するためにかかる時間の量の点でユーザーエクスペリエンスを低下させる場合がある。本明細書に記載の対象は、単一の画像がレンダリングされる場合と画像の集合がレンダリングされる場合との両方に適用されるが、単一の画像がレンダリングされる場合と比較して、画像の集合がレンダリングされる場合は、高画質画像を迅速にレンダリングするという問題が何倍にも増える点に留意されたい。

[0020]本明細書に記載の対象によって、全体的に高品質なユーザーエクスペリエンスを提供するために、画像を提供することに対する様々な制約に適合する方法で画像をレンダリングできるようになる。画像を提供する機能に存在しうる制約のいくつかの例には、プリレンダリングされた画像の利用可能性（または利用可能性の欠如）、他と比較してある解像度で画像をレンダリングすることの相対的容易さ、レンダラーから画像が表示される装置へ画像を送信するための帯域幅の利用可能性、およびディスプレイ装置が連続画像を描画できる速度がある。さらに、インポスター画像の使用を通じて、本明細書に記載の対象は、たとえ容易に利用可能なプリレンダリングされた画像がなくても（低解像度の画像さえなくても）、画像受信のユーザーの経験の認識を向上できる。

[0021]１つまたは複数の画像を求める要求が行われると、本明細書に記載の対象によって設計されたシステムは、何を迅速に提供できるか決定しようとする。画像を求める要求は、直接ユーザー要求の形式をとる場合がある。あるいは、他の例では、画像検索要求に応答する処理の一部として、検索エンジンが画像を要求する場合がある。あるいは、さらなる例として、画像はウェブページ上で参照される場合があり、ウェブブラウザがウェブページの処理の一部として画像を要求する場合がある。本明細書に記載の対象は、画像を求める要求が生じる任意の特定の方法に限定されない。低解像度のプリレンダリングされた画像が利用可能である場合があり、この場合はそれらの画像が提供されうる。低解像度画像は迅速に送信および描画されうるので、低解像度画像を使用すると、要求への応答が非常に速く見える場合がある。しかし、低解像度画像が利用可能ではない場合、システムはインポスター画像を提供する場合がある。インポスター画像は、ユーザーには、順次より高い解像度で画像を描画する処理における非常に初期の段階に見える場合がある画像である。しかし、インポスター画像は画像のサイズと縦横比だけに基づく場合がある。たとえば、インポスター画像は、後にレンダリングされる描画の形状およびサイズで表示された、単に曖昧な色およびパターンである場合がある。しかし、インポスター画像は描画についての情報にほとんどまたは全く基づいていない場合があるので、非常に迅速に提供することができ、したがって画像要求に応答するために使用されうるいくつかのコンテンツを提供できる。この迅速な応答によって、ユーザーの経験の認識を向上できる。

[0022]ユーザーがインポスター画像または低解像度画像を見せられている間、システムは他の解像度での画像の取得に取りかかることができる。これらの画像の生成には様々なタスクが含まれうる。まず、基本的なレンダリングされていない画像が、ローカルまた遠隔ソースから配置されなければならない。一旦これらの画像が配置されると、画像をレンダリングする方法について様々な決定が行われうる。まず、システムは、連続的により高い解像度の画像のレンダリングを表示することによって、高解像度で画像を描画する処理をアニメートしたい場合がある。このアニメートが行われうる速度は、画像が送信されうる速度、画像がスクリーン上に描画されうる速度、ユニット時間ごとに行われうる異なる画像レンダリングの数、および、画像集合の場合は、その集合に含まれる画像の数に依存しうる。したがって、システムは、連続画像についての解像度を倍増することによって、画像に焦点を合わせる処理をアニメートしたい場合がある。しかし、２のべき乗の画像ごとにそれぞれの解像度で新しい画像をレンダリングすることが、システムの計算リソースが所与のユニット時間内で処理できる画像よりも多くの画像をレンダリングすること、あるいは、通信および／またはディスプレイ技術がユニット時間ごとに処理できる画像よりも多くの画像を送信および／または再描画することを含むとしたら、システムは各画像が以前の解像度の４倍の解像度を有するような連続画像をレンダリングすることを選択する場合がある。あるいは、ある画像フォーマット（たとえばＪＰＥＧ）では、いくつかの解像度が他の解像度よりも速くレンダリングできるので、システムは、他の全てのことが同等の場合に、たとえシステムが異なる解像度を選択したとしても、迅速にレンダリングされうる解像度で画像をレンダリングすることを選択する場合がある。

[0023]一般に、本明細書に記載の対象は、単一の画像を含む任意の数の画像を表示するために使用されうる。しかし一例では、システムは、画像検索クエリーに応答してユーザーに提供されている複数の画像などの画像の集合をレンダリングするために使用されうる。

[0024]次に図面を参照すると、図１および２は画像が連続的により高い解像度でレンダリングされうる方法の例を示している。図１で、画像１０２が要求されている。画像１０２は、ジョイント・フォトグラフィック・エキスパート・グループ（ＪＰＥＧ）ファイル、タグ付き画像ファイル・フォーマット（ＴＩＦＦ）、形状を幾何学的に表すフォーマット（たとえば、ＶＩＳＩＯ描画プログラムによって生成されたファイル）などの何らかのフォーマットでもよく、または他の任意のタイプの画像でもよい。画像１０２を求める要求は任意の方法で生じうる。たとえば、ユーザーが画像１０２を求める明確な要求を行ってもよく、ブラウザがロードしようとするウェブページ内で画像１０２が参照されてもよく、また検索クエリーへの応答として画像１０２が検索エンジンによって返されてもよい。上記の記述は画像を求める要求が生じうる方法のいくつかの例であるが、画像１０２を求める要求は任意の方法で生じうる。

[0025]図１および２の例では、利用可能な画像１０２のプリレンダリングされたバージョンがない場合がある。したがって、インポスター画像１０４が表示されうる。インポスター画像１０４は色を有することもできるが、図１の例では、様々なパターンで描かれた白黒の曖昧な斜線が表示されている。この例では、インポスター画像１０４は画像１０２と同じ縦横比の長方形である。縦横比または形状は画像１０２のメタデータから決定できるので、たとえ画像１０２のレンダリングされたバージョンが利用可能ではなくても、画像１０２の縦横比（または、より一般的には画像１０２の形状）を確認することが可能な場合がある。実際、画像１０２が容易に利用可能でなくても、そのメタデータは別の場所で利用可能な場合がある。したがって、まるでインポスター画像１０４が実際に画像１０２の描画の初期の段階であるかのように見せるために、インポスター画像１０４は画像１０２の縦横比で、および画像１０２が描画されるべきサイズでレンダリングされうる。画像１０２が長方形ではない場合、メタデータは画像の形状を明らかにすることができ、その場合、インポスター画像１０４は画像１０２の形状で描画されうる。（通常、縦横比は特定の種類の形状の記述であり、長方形に適用される。）極端な場合、画像１０２のメタデータを取得することさえできない場合がある。その場合、インポスター画像１０４は何らかの任意の縦横比（または何らかの他の形状）で描画されうる。いくつかのシステムでは、画像をレンダリングする間、画像を受信する際に遅延があるであろうことを示す何らかの種類のメッセージ（たとえば、「画像を取得する間お待ちください」）を提供するか、待ち時間または時間の経過を表す何らかの種類の記号（たとえば、砂時計の中を砂が落ちている、円が回転している、時計、等）を提供する点に留意されたい。しかし、インポスター画像はこのようなメッセージまたは記号を含まない場合もあるので、インポスターは異なる手法を実装できる。つまり、インポスター画像は、遅延を説明または通知するためではなく、むしろユーザーに画像を受信し始めたかのように感じさせるように設計されうる。

[0026]インポスター画像１０４が描画された後、ユーザーは、要求した画像の描画にシステムが取りかかっていると満足する場合がある。したがって、画像を取得する処理、画像をレンダリングする解像度を決定する処理、およびそれらの解像度で画像をレンダリングする処理が実行されうる。これらの処理が実行される方法の例は、図４〜６に関連して以下で説明する。しかし、図１および２のために、１つまたは複数のレンダリングされた画像が何らかの方法で取得されると仮定される。

[0027]それらの画像のうちの最初の画像はレンダリング１０６である。レンダリング１０６は画像１０２の低解像度でのレンダリングである。低解像度画像は実際には画像が比較的少数のピクセルのみによって表されたものであるが、例示のために、画像の様々な要素を点線で表すことによって、画像の低解像度の特性が図１に表されている。図２では、（画像１０６の点線よりも高密度に見える点線によって示されるように）レンダリング１０８がより高解像度で画像１０２を表している。画像１０２の、連続的により解像度が高くなるバージョンが描画されうる。最後に、レンダリングの連続はレンダリング１１０のように見え、比較的高い解像度の画像１０２（たとえば、レンダリングが表示されるディスプレイ装置と同じくらい高い解像度の画像）に見える。図１および２における、インポスター画像１０４からレンダリング１０６、１０８、および１１０へのレンダリングの進行は、画像をより高い解像度および／またはより明瞭にする処理のアニメートの例である点に留意されたい。

[0028]図１および２はインポスターから高解像度画像に進む際に単一の画像を表示しているが、レンダリングされる画像は、図３に示される集合３００などの集合の一部でよい点に留意されたい。図３の例では、集合３００は、３０２、３０４、３０６、３０８、３１０、３１２、３１４、３１６、および３１８の９つのレンダリングを含む、いくつかの画像の集合である。図示されるように、集合３００内の様々な画像は、レンダリングおよび／または利用可能性の異なる段階にある。たとえば、レンダリング３０２は中解像度で表示されている。（異なる画像の）レンダリング３０４は低解像度で表示されている。（さらに異なる画像の）レンダリング３０６は高解像度で表示されている。レンダリング３０８〜３１８はインポスター画像として表示されており、対応する画像のレンダリングがまだ利用可能ではないことを示している。集合３００は様々な方法で表示されうる。一例では、集合内の全ての画像（または、画像が利用可能ではない場合はインポスター）は単一のビットマップ上にレンダリングされ、そのビットマップが表示されうる。たとえば、ウェブサーバーは、画像の集合を含む単一のページを構成でき、次いでそのページのビットマップを、ユーザーのブラウザによってレンダリングされるように、ユーザーの機械に送信できる。さらなる画像（または、既存の画像のより高い解像度バージョン）が利用可能になると、ビットマップはアップデートされて、ブラウザによって現在表示されているビットマップを置換するためにブラウザに再送されうる。あるいは、他の例では、集合内の各画像が別々にレンダリングされうる。たとえば、ウェブページは画像へのリンクを含むことができるので、ブラウザはそれぞれの統一リソースロケータ（ＵＲＬ）から画像を１つずつ取得して、ページ上の適切な場所に各画像を表示する。画像へのリンクが要求されると、どのレンダリングされた画像が利用可能かによって、サーバーはインポスター画像、低解像度画像、または高解像度画像を提供できる。個々の画像は、高解像度画像が利用可能になると、高解像度画像でアップデートされうる。

[0029]図４は、コンテンツをレンダリングするために使用されうる、例示的システム４００のコンポーネントを示している。システム４００は、１つまたは複数の画像を求める要求４０２を処理して、画像を取得およびレンダリングする処理を管理する。

[0030]要求４０２は収集システムによって受信されうる。収集システム４０４は画像をフェッチする処理を管理し、また複数の画像を単一の画像に複合する処理を管理できる（集合が表示されるべき場合）。

[0031]画像フェッチング処理を管理する際の収集システム４０４の役割については、収集システム４０４がどの画像が提供されるべきかを決定すると、収集システム４０４は画像フェッチャー４０６に要請してそれらの画像を取得できる。画像フェッチャー４０６は、遠隔画像ソース４０８および／またはローカル画像ソース４１０を含む様々なソースから画像を取得できる。遠隔画像ソース４０８は、画像フェッチャー４０６が動作している機械以外のどこかに位置するソースである。ローカル画像ソース４１０は、画像フェッチャー４０６が動作している機械上に位置するソースである。「画像フェッチャー４０６が動作している機械」を構成するものに関しては、様々なシナリオがある点に留意されたい。一例では、画像フェッチャー４０６は、画像が表示される機械と同じ機械（たとえば、ユーザーのコンピューター、ユーザーのスマートフォンなど）上で動作しており、この場合、ローカル画像ソース４１０はそのコンピューター、スマートフォンなどの記憶領域でよい。他の例では、画像フェッチャー４０６は、そのサーバー上では表示されないが、ユーザーの機械上で表示されるためにユーザーの機械のブラウザに遠隔に配信される画像をレンダリングするサーバー上で動作している。後者の例では、ローカルソース４１０は、画像が表示される機械上に位置するソースではなく、画像をレンダリングしているサーバー上のソースである。

[0032]収集システム４０４は、遠隔ソースおよびローカルソースから画像を取得することに加えて、画像キャッシュ４１２からプリレンダリングされた画像を取得することもできる。遠隔画像ソース４０８およびローカル画像ソース４１０と画像キャッシュ４１２との違いは、画像キャッシュ４１２が画像のレンダリングされたバージョンを格納するのに対して、遠隔画像ソース４０８およびローカル画像ソース４１０はまだレンダリングされていない画像の表示を格納できることである。同じ画像が複数回要求される場合があるので、画像キャッシュ４１２は、いくつかの以前の要求のサービスの一部としてレンダリングされた可能性のある画像を格納する。したがって、画像キャッシュ４１２によってそれらの画像が再び使用できるようになり、したがって画像をレンダリングする作業が既に行われている場合はその作業を回避できる。

[0033]システム４００は、画像のレンダリングの実際の作業を実行できるレンダラー４１４も備えることができる。すなわち、ソース画像が取得されると、レンダラー４１４はそのソース画像を使用して、表示される実際のピクセルを作成できる。レンダラー４１４が画像をレンダリングすると、画像はディスプレイ４１６に送信されうる。さらに、画像がレンダリングされると、レンダラー４１４はその画像を画像キャッシュ４１２に預けて、後に同じ画像が再び要求された場合に、現在レンダリングされている画像が将来使用するために利用可能であるようにすることができる。

[0034]画像をフェッチする処理は、複数のスレッドを使用してパラレルに行われうる点に留意されたい。たとえば、２０個の画像などの集合が含まれる場合、収集システム４０４は、画像フェッチャー４０６が動作する２０個の別々のスレッドを作成できるので、画像は同時に取得されうる。

[0035]図５は画像を提供する例示的処理を示している。図５の説明を始める前に、この処理は任意のシステムで実行でき、図１〜４に示されるシナリオに限定されないが、例として図１〜４に示されるコンポーネントを参照して図５に含まれる流れ図を説明する点に留意されたい。さらに、図５における流れ図は、ブロックをつなぐ線で示されるように、処理の段階が特定の順序で実行される例を示しているが、この図に示される様々な段階は任意の順序、あるいは任意の組合せまたは副結合で実行されうる。

[0036]５０２で、画像が要求されうる。上述のように、要求は、直接ユーザー要求を通じて、または画像が検索に応答するためエンジンがその画像を要求する検索エンジンを通じて、などの任意の方法で発生しうる。５０４で、要求はその要求を処理するコンポーネントによって受信されうる。５０６で、画像のプリレンダリングされたバージョンが画像キャッシュ内で利用可能かどうか決定されうる。画像が利用可能な場合（および／または、キャッシュ内に適切な解像度で利用可能な画像が見つかった場合）、５１４でレンダリングされた画像が表示されうる。画像が利用可能ではない場合、処理は画像をレンダリングせずに進む。

[0037]画像をレンダリングせずに進むために、５０８でインポスター画像が表示されうる。上述のように、インポスター画像は基本画像から取得していない色および／またはパターンを含む画像である場合があるが、連続的に解像度がより高くなる画像のレンダリングの非常に初期の段階であるという印象をユーザーに与えることができる。一例では、インポスター画像は、基本画像の縦横比および／または形状で、ならびに実際の画像が最終的にレンダリングされるサイズで描画されうる。しかし、本明細書に記載の対象は、インポスター画像が基本画像についてのどの情報にも（縦横比および／または形状にさえも）全く基づかない状況も含む。

[0038]インポスター画像が表示されると、５１０で、処理はソースからの画像の取得に進むことができる。たとえば、図４に関連して上述したように、遠隔画像ソース４０８および／またはローカル画像ソース４１０から画像を取得するために画像フェッチャー４０６が使用されうる。やはり上述のように、集合の一部としてレンダリングされるべきいくつかの画像がある場合があり、したがってこれらの画像を取得する処理は、たとえばいくつかの同時スレッドに画像フェッチャーを実行することによって、パラレルに進むことができる。さらに、集合内のいくつかの画像が利用可能であり、他の画像が利用可能ではない場合がある点に留意されたい。したがって、図５の処理では、集合内のいくつかの画像が最初にインポスターとして表示され、他の画像が最初に基本画像のレンダリングとして画像されることが可能である。

[0039]一旦画像が取得されると、５１２で、実現可能な解像度で画像がレンダリングされうる。実現可能性を構成するものは、該当する環境に依存する。システムが実現可能性を評価できる様々な方法は、本明細書に記載の対象の適応性を示す。たとえば、上述のように、画像がレンダリングされうる速度、画像が描画されうる速度、レンダリング位置からディスプレイ位置に画像が送信されうる速度に関する問題、またはその他の検討事項がある場合がある。これらの検討事項のうちのいくつかは図６に示されており、次に説明する。

[0040]一般に、適応の１つのタイプは、画像表示が行われているコンテキストに適応することである（ブロック６０２）。このコンテキストの例には、レンダリングされている画像の数（たとえば、単一の画像または画像の集合）、利用可能な送信帯域幅、ディスプレイシステムの描画速度がある。これらの問題は、画像をレンダリングするための実現可能な解像度を構成するものを定義しうる。たとえば、上述のように、画像のそれぞれの連続した描画の解像度を２倍にすることによって、次第に高い解像度になる画像の処理をアニメートしたい場合がある。しかし、十分な送信帯域幅または描画速度、あるいは十分なレンダリング帯域幅がない場合、連続した画像の解像度を２倍にするだけだと、解像度が高くなっていく画像をアニメートするために時間がかかりすぎてしまう。したがって、連続する画像間の解像度を４倍にする選択が行われうる。

[0041]他のタイプの適応は、コンテンツの特徴に適応することである（ブロック６０４）。たとえば上述のように、ある種のコンテンツはある解像度でのレンダリングを他の解像度でのレンダリングよりも容易にすることができる。たとえばＪＰＥＧの特性は、２５６または５１２ピクセルでのレンダリングを他の解像度でのレンダリングよりも容易にすることができる。したがって、特定の解像度でのコンテンツのレンダリングの容易さ（および／またはコンテンツの他の特徴）は、コンテンツをレンダリングするための解像度の選択を通知できる。画像をレンダリングする解像度を選択すると、どの解像度が迅速に描画されうるかについて懸念がない場合、システムは特定の解像度（たとえば、解像度Ａ）を選択する場合がある点に留意されたい。しかし、特定の解像度への速い経路（パス、path）の存在によって、システムは異なる解像度（たとえば、解像度Ｂ）を選択する場合があり、これはそうでない場合にシステムが選択する解像度ではない。言い換えれば、このような例ではシステムはそれがシステムが実現しようとしている体裁に基づいてシステムが選択する解像度だから解像度Ｂを選択するのではなく、特に速い経路の利用可能性のために、システムは解像度Ａではなく解像度Ｂを選択する場合がある。

[0042]適応の他の形式は、画像フェッチおよび／またはレンダリング処理をマルチスレッドする機能である（ブロック６０６）。上述のように、画像は集合の一部でよく、集合内の様々な画像を同時に取得することが可能でよい。同様に、取得された画像に関して、レンダリング処理をマルチスレッドすることも可能でよく、それによって取得された画像を同時にレンダリングできるようになる。

[0043]図５に戻ると、一旦画像がレンダリングされると（５０６で決定されたように、レンダリングされた画像が既に利用可能であったので、または画像が要求された後に画像が取得されてレンダリングされたので）、５１４でレンダリングされた画像が表示されうる。画像を表示する動作は、スクリーンまたは他の装置上に画像を物理的に表示することを含みうる。あるいは、画像を表示する動作は、画像の表示を他の装置上に生じさせるよう指示することを含みうる。（たとえば、サーバーが、画像を表示する命令をクライアントに送信すると、この動作はサーバーによって実行される表示動作として理解されうる。）
[0044]５１６で、レンダリングされるべきさらなる解像度があるかどうか決定されうる。上述のように、順次より高い解像度で画像を表示する処理をアニメートしたい場合があり、したがって同じ画像のいくつかのレンダリングが実行されうる。このアニメート処理について選択されうる特定の解像度は、上述の実現可能性問題に基づいて決定されうる。しかし、どの解像度でレンダリングするかの選択が何らかの方法で行われたと仮定すると（レンダリングおよびフェッチング処理の進行中に、この選択自体が変化する場合があるが）、５１６で、レンダリングする画像のさらなる解像度があるかどうか決定される。このようなさらなる解像度がある場合、処理は５１２に戻って、さらなる解像度で画像をレンダリングする。さらなる解像度がない場合、画像は最終的な解像度でレンダリングされて、処理は終了できる。

[0045]図７は、本明細書に記載した対象の態様を展開しうる例示的環境を示している。
[0046]コンピューター７００は、１つまたは複数のプロセッサー７０２と、１つまたは複数のデータ記憶コンポーネント７０４とを含む。プロセッサー７０２は、一般的に、パーソナルデスクトップまたはラップトップコンピューター、サーバー、ハンドヘルドコンピューター、あるいは他の種類のコンピューティングデバイスなどに見られるものなどのマイクロプロセッサーである。データ記憶コンポーネント７０４は、短期間または長期間にわたってデータを格納できるコンポーネントである。データ記憶コンポーネント７０４の例には、ハードディスク、リムーバブルディスク（光および磁気ディスクを含む）、揮発性および不揮発性ランダムアクセスメモリー（ＲＡＭ）、読出し専用メモリー（ＲＯＭ）、フラッシュメモリー、磁気テープなどがある。データ記憶コンポーネント７０４は、コンピューター読み取り可能な記憶媒体の例である。コンピューター７００は、ブラウン管（ＣＲＴ）モニター、液晶ディスプレイ（ＬＣＤ）モニター、または他の任意のタイプのモニターでよいディスプレイ７１２を備えるか、それに関連付けられうる。

[0047]ソフトウェアは、データ記憶コンポーネント７０４に格納されて、１つまたは複数のプロセッサー７０２上で実行されうる。ソフトウェアの一例は適応画像レンダリングソフトウェア７０６であり、図１〜６に関連して上述した機能のうちのいくつかまたは全てを実装できるが、任意のタイプのソフトウェアが使用されうる。ソフトウェア７０６は、たとえば１つまたは複数のコンポーネントを通じて実装でき、それらは分散システム中のコンポーネントでもよく、別々のファイル、別々の機能、別々のオブジェクト、別々の命令行などでもよい。プログラムがハードディスク上に格納され、ＲＡＭにロードされ、コンピューターのプロセッサー上で実行されるコンピューター（たとえば、パーソナルコンピューター、サーバーコンピューター、ハンドヘルドコンピューター、スマートフォンなど）は、図７に示されたシナリオの典型であるが、本明細書に記載の対象はこの例に限定されない。

[0048]本明細書に記載の対象は、データ記憶コンポーネント７０４のうちの１つまたは複数に格納されて、プロセッサー７０２のうちの１つまたは複数上で実行するソフトウェアとして実装されうる。他の例では、本明細書に記載の対象は、１つまたは複数のコンピューター読み取り可能な記憶媒体に格納される命令として実装されうる。光ディスクまたは磁気ディスクなどの有形の媒体は、記憶媒体の例である。命令は持続性媒体上に存在しうる。このような命令は、コンピューターまたは他の機械によって実行されると、コンピューターまたは他の機械に方法の１つまたは複数の動作を実行させることができる。動作を実行するための命令は１つの媒体に格納することもでき、複数の媒体にわたって分散することもできるので、全ての命令が同じ媒体上にあるかどうかに関わらず、命令は１つまたは複数のコンピューター読み取り可能な記憶媒体上に集合的に見える場合がある。

[0049]さらに、本明細書に記載のあらゆる動作（図に示されているかどうかに関わらず）は、方法の一部としてプロセッサー（たとえば、１つまたは複数のプロセッサー７０２）によって実行されうる。したがって、動作Ａ、Ｂ、およびＣが本明細書に記載されている場合、動作Ａ、Ｂ、およびＣを備える方法が実行されうる。さらに、動作Ａ、Ｂ、およびＣが本明細書に記載されている場合、動作Ａ、Ｂ、およびＣを実行するためにプロセッサーを使用するステップを備える方法が実行されうる。

[0050]一つの例示的な環境では、コンピューター７００は、ネットワーク７０８を通じて１つまたは複数の他の装置と通信可能なように接続されてよい。コンピューター７００と構造が類似してよいコンピューター７１０は、コンピューター７００に接続されうる装置の例であるが、他の種類の装置もそのように接続されてよい。

[0051]主題は構造的特徴および／または方法論的動作に特有の言葉で本明細書に記載されているが、添付の特許請求の範囲において定義される主題は、上述の特定の特徴または動作に必ずしも限定されないことが理解されるべきである。むしろ、上述の特定の特徴および動作は、特許請求の範囲を実施する例示的形式として開示される。

Claims (15)

1. 画像をレンダリングする要求を受信するステップと、
   前記画像のレンダリングされたバージョン、またはインポスター画像を、前記画像を含む画像の集合の一部として提供するステップと、
   順次より高い解像度で前記画像を表示する処理をアニメートするために前記画像をレンダリングするための複数の解像度を決定するステップであって、前記複数の解像度が送信帯域幅、描画速度、または画像フォーマットに基づいて決定される、ステップと、
   複数のレンダリングされた画像を作成するために、前記複数の解像度で前記画像をレンダリングするステップと、
   前記複数の解像度で前記複数のレンダリングされた画像を提供するステップとを備える、画像をレンダリングする方法。
2. 前記画像がある形状を有し、
   前記形状を含むデータを取得するステップと、
   前記形状で前記インポスター画像を作成するステップとをさらに備える、請求項１に記載の方法。
3. 前記複数の解像度が、前記画像を送信するために利用可能な送信帯域幅の量に基づいて決定される、請求項１に記載の方法。
4. 前記複数の解像度が、前記画像が表示される装置の描画速度に基づいて決定される、請求項１に記載の方法。
5. 前記複数の解像度が、前記画像が格納されるフォーマットに基づいて決定される、請求項１に記載の方法。
6. 前記フォーマットが、第１の解像度で前記画像をレンダリングするための速い経路を提供し、前記決定するステップが、利用可能な送信帯域幅または描画速度に基づいて、前記第１の解像度とは異なる第２の解像度を選択して、次いで、前記速い経路の利用可能性のために、前記画像を前記第２の解像度ではなく前記第１の解像度でレンダリングすることを決定する、請求項５に記載の方法。
7. 別々のフェッチスレッドを使用して、前記集合内の画像を同時にフェッチするステップをさらに備える、請求項１に記載の方法。
8. 請求項１乃至７のいずれか１項に記載の方法を実行するためのコンピューター実行可能命令を有するコンピューター読み取り可能な媒体。
9. プロセッサーと、
   データ記憶コンポーネントと、
   前記データ記憶コンポーネントに格納される画像キャッシュと、
   前記システムにとってローカルなソース、および前記システムにとって遠隔にあるソースから画像を取得する画像フェッチャーと、
   前記プロセッサー上で実行する収集コンポーネントであって、前記収集コンポーネントが画像をレンダリングする要求を受信して前記画像のレンダリングされたバージョンが前記画像キャッシュ内で利用可能かどうかを決定し、前記収集コンポーネントが前記画像を取得するよう前記画像フェッチャーに指示し、前記システムが前記画像の前記レンダリングされたバージョンが前記画像キャッシュ内にない場合はインポスター画像が表示されるよう指示する、収集コンポーネントと、
   前記画像フェッチャーによって取得された前記画像をレンダリングして、前記画像を前記システムによって表示させるか、または前記画像が表示される装置に提供させるレンダラーとを備える、画像をレンダリングするためのシステム。
10. 前記収集コンポーネントが、前記インポスター画像が表示されるよう指示し、前記画像がある形状を有し、前記システムが前記形状で前記インポスター画像を作成する、請求項９に記載のシステム。
11. 前記形状が長方形を含み、前記インポスター画像が前記長方形の縦横比を有する長方形で作成される、請求項１０に記載のシステム。
12. 前記システムが、前記画像の解像度の増加をアニメートし、前記画像を送信するために利用可能な帯域幅の量に基づいて前記画像をレンダリングするための解像度を選択する、請求項９に記載のシステム。
13. 前記システムが前記画像の解像度の増加をアニメートし、前記装置の描画速度に基づいて前記画像をレンダリングするための解像度を選択する、請求項９に記載のシステム。
14. 前記システムが前記画像の解像度の増加をアニメートし、前記画像のフォーマットに基づいて前記画像をレンダリングするための解像度を選択する、請求項９に記載のシステム。
15. 前記フォーマットが、第１の解像度とは異なる第２の解像度で前記画像をレンダリングするための経路よりも速い前記第１の解像度で前記画像をレンダリングするための経路を提供し、前記システムが、前記経路の存在のために、前記第２の解像度ではなく前記第１の解像度を選択する、請求項１４に記載のシステム。

Images