(57)【要約】      （修正有）【課題】異なる画像ソースからの異なるフォーマットの画像ファイルを生成および／または表示するソフトウェアを利用するに当たって、単一の表示装置での複数の画像ソースの使用をサポート表示装置上で必要とされるソフトウェアの容量を低減する方法を提供する。【解決手段】画像の表示を可能にする通信ソフトウェアは、通信プロトコルを含んでいる。該プロトコルは、画像データの部分が、複数の異なるデータ構造の選択されたものに符号化されることを可能にするように構成されている。各データ構造は、受信位置での解析を容易にするために関連タグを有している。【選択図】図１
2010268494.tif 000002
【特許請求の範囲】
【請求項１】
画像表示システムであって、
画像ソースからサーバへの画像データの送信を可能にし、前記画像データに基づいて画像を表示させるように構成された通信プロトコルを備え、該通信プロトコルは、
ビットマップ情報を含むように定義されたビットマップ構造を含む複数の異なるデータ構造と、
複数の異なるタグとを具備し、
前記通信プロトコルを使用するクライアント・サーバ通信が、連続するデータ・ストリームとして生じるように前記通信プロトコルが構成される場合には、前記連続するデータ・ストリームは、複数の異なるデータ構造から選択されたデータ構造を使用して符号化されたデータ部分を含み、
前記複数の異なるタグのそれぞれは、宛先での連続するデータ・ストリームの解析を可能にするように、前記複数の異なるデータ構造の特定の１つに関連且つ対応しているシステム。
【請求項２】
前記複数の異なるデータ構造は、色空間情報を含むように定義された色空間構造を含んでいる請求項１記載のシステム。
【請求項３】
前記複数の異なるデータ構造は、圧縮情報を含むように定義された圧縮構造を含んでいる請求項１記載のシステム。
【請求項４】
前記複数の異なるデータ構造は、マークアップ情報を含むように定義されたマークアップ構造を含んでいる請求項１記載のシステム。
【請求項５】
前記複数の異なるデータ構造は、設定解像度情報を含むように定義された設定解像度構造を含んでいる請求項１記載のシステム。
【請求項６】
前記通信プロトコルは、前記画像ソースと前記サーバとの間の解像度のネゴシエーションを提供するように構成された反転チャネルを含んでいる請求項５記載のシステム。
【請求項７】
前記通信プロトコルは、双方向クライアント・サーバ通信が前記サーバに画像データの送信に対するフロー制御を提供することを可能にするように構成されている請求項１記載のシステム。
【請求項８】
前記通信プロトコルは、データが前記サーバの方へ流れる順方向チャネルと、データが前記画像ソースの方へ流れる反転チャネルとを含んでいる請求項１記載のシステム。
【請求項９】
前記反転チャネルは、前記画像ソースと前記サーバとの間の解像度のネゴシエーションを可能にするように構成されている請求項８記載のシステム。
【請求項１０】
前記反転チャネルは、前記サーバに画像データの送信に対するフロー制御を提供するように構成されている請求項８記載のシステム。
【請求項１１】
利用可能なバッファ・サイズは、前記反転チャネルのサーバによって報告される請求項１０記載のシステム。
【請求項１２】
画像データの送信に基づいた画像の表示をもたらすように画像ソースとサーバとの間で通信する方法であって、
それぞれ関連タグを有している複数の異なるデータ構造の選択されたものに前記画像データの部分を符号化すること、
連続するデータ・ストリームに符号化された画像データを前記サーバに送信すること、
前記サーバで、前記連続するデータ・ストリームに存在するタグを受信および処理することによって連続するデータ・ストリームを解析することを含む方法。
【請求項１３】
画像データを符号化することは、ビットマップ・タグを有するビットマップ・データ構造にビットマップ情報を符号化することを含んでいる請求項１２記載の方法。
【請求項１４】
画像データを符号化することは、色空間タグを有する色空間データ構造に色空間情報を符号化することを含んでいる請求項１２記載の方法。
【請求項１５】
画像データを符号化することは、圧縮タグを有する圧縮データ構造に圧縮情報を符号化することを含んでいる請求項１２記載の方法。
【請求項１６】
画像データを符号化することは、マークアップ・タグを有するマークアップ・データ構造にマークアップ情報を符号化することを含んでいる請求項１２記載の方法。
【請求項１７】
画像データを符号化することは、設定解像度タグを有する設定解像度データ構造に設定解像度情報を符号化することを含んでいる請求項１２記載の方法。
【請求項１８】
前記サーバへのデータ送信に対するフロー制御を提供するために、反転チャネルの前記サーバから前記画像ソースへバッファ情報を通信することをさらに含む請求項１２記載の方法。
【請求項１９】
前記画像ソースと前記サーバとの間で表示解像度をネゴシエーションするために、順方向チャネルおよび前記反転チャネルを使用することをさらに含む請求項１８記載の方法。
【請求項２０】
前記サーバに前記画像ソースのエンディアンネス仕様を送信することをさらに含む請求項１２記載の方法。
【請求項２１】
前記符号化された画像データを送信する前に前記サーバに認証識別子を送信することをさらに含み、前記認証識別子は、前記サーバへの有効なコネクタとして前記画像ソースを認証するように構成されている請求項１２記載の方法。
【請求項２２】
反転チャネルの前記サーバから報告された利用可能なバッファ・サイズ情報に基づいて前記サーバへの順方向チャネルにおける送信速度を動的に変更することをさらに含む請求項１２記載の方法。
【請求項２３】
画像表示システムであって、
サーバと通信するように構成され、前記サーバに結合された画像表示装置によって画像を表示させるクライアントを備え、
該クライアントは、
画像ソースから得られた画像データを符号化し、前記画像データの部分は、複数の異なるデータ構造の選択されたものに符号化され、前記複数の異なるデータ構造のそれぞれは、関連タグを有しており、
連続するデータ・ストリームに符号化された画像データを対象位置に送信する
ように構成された通信ソフトウェアを含んでいるシステム。
【請求項２４】
前記複数の異なるデータ構造は、ビットマップ情報を含むように定義されたビットマップ構造を含んでいる請求項２３記載のシステム。
【請求項２５】
前記複数の異なるデータ構造は、色空間情報を含むように定義された色空間構造を含んでいる請求項２３記載のシステム。
【請求項２６】
前記複数の異なるデータ構造は、圧縮情報を含むように定義された圧縮構造を含んでいる請求項２３記載のシステム。
【請求項２７】
前記複数の異なるデータ構造は、マークアップ情報を含むように定義されたマークアップ構造を含んでいる請求項２３記載のシステム。
【請求項２８】
前記複数の異なるデータ構造は、設定解像度情報を含むように定義された設定解像度構造を含んでいる請求項２３記載のシステム。
【請求項２９】
前記クライアントの通信ソフトウェアは、反転通信チャネルを介して受信された利用可能なバッファ・サイズ情報に応じて前方通信チャネルにおける送信速度を動的に変更するようにさらに構成されている請求項２３記載のシステム。
【請求項３０】
クライアント画像ソースが対象画像表示装置と通信することを可能にする画像データ処理システムであって、
ソース画像データを得て、対応するビットマップ表現を生成するように構成されたクライアント・ソフトウェアと、
前記クライアントの画像ソースおよび前記対象画像表示装置が前記バイト・ストリームを解析することを可能にするように構成されたタグを含む双方向バイト・ストリームの形態をした、前記クライアントの画像ソースと前記対象画像表示装置との間の通信を提供するように構成された通信ソフトウェアとを備えるシステム。
【請求項３１】
前記通信ソフトウェアは、前記対象画像表示装置に前記認証識別子および前記ビットマップ表現を送信するようにさらに構成され、前記認証識別子は、前記対象画像表示装置への有効なコネクタとして前記クライアント画像ソースを認証するように構成されている請求項３０記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、概して、画像データを処理する装置、システムおよび方法に関し、特に、クライアント画像ソース装置と対象表示装置との間のネットワーク通信を提供する装置、システムおよび方法に関する。
【発明の概要】
【０００２】
本願は、2004年5月28日に出願された米国仮特許出願第60/575,735号からの優先権を主張するものであり、参照によってすべての目的のためにその全体をここに援用する。
【課題を解決するための手段】
【０００３】
本発明にかかるシステムは、画像表示システムであって、画像ソースからサーバへの画像データの送信を可能にし、前記画像データに基づいて画像を表示させるように構成された通信プロトコルを備え、該通信プロトコルは、ビットマップ情報を含むように定義されたビットマップ構造を含む複数の異なるデータ構造と、複数の異なるタグとを具備し、前記通信プロトコルを使用するクライアント・サーバ通信が、連続するデータ・ストリームとして生じるように前記通信プロトコルが構成される場合には、前記連続するデータ・ストリームは、複数の異なるデータ構造から選択されたデータ構造を使用して符号化されたデータ部分を含み、前記複数の異なるタグのそれぞれは、宛先での連続するデータ・ストリームの解析を可能にするように、前記複数の異なるデータ構造の特定の１つに関連且つ対応していることを特徴とする。
【図面の簡単な説明】
【０００４】
【図１】本願発明の第１の実施の形態にかかる画像データ処理システムの模式図である。
【図２】本願発明のソフトウェア、システムおよび方法に関連して使用されることが可能である典型的な演算装置の模式図である。
【図３】本願発明にかかる画像データを処理する典型的な方法のフローチャートである。
【図４】本願発明にしたがって通信する典型的なクライアント画像ソース装置および対象表示装置の模式図である。
【図５】一又は複数の画像ソース装置と一又は複数の対象表示装置との間のネットワーク通信を容易にするのに使用されることが可能であるネットワーク通信プロトコルの典型的な態様を図示している。
【図６】一又は複数の画像ソース装置と一又は複数の対象表示装置との間のネットワーク通信を容易にするのに使用されることが可能であるネットワーク通信プロトコルの典型的な態様を図示している。
【図７】一又は複数の画像ソース装置と一又は複数の対象表示装置との間のネットワーク通信を容易にするのに使用されることが可能であるネットワーク通信プロトコルの典型的な態様を図示している。
【図８】一又は複数の画像ソース装置と一又は複数の対象表示装置との間のネットワーク通信を容易にするのに使用されることが可能であるネットワーク通信プロトコルの典型的な態様を図示している。
【図９】一又は複数の画像ソース装置と一又は複数の対象表示装置との間のネットワーク通信を容易にするのに使用されることが可能であるネットワーク通信プロトコルの典型的な態様を図示している。
【図１０】一又は複数の画像ソース装置と一又は複数の対象表示装置との間のネットワーク通信を容易にするのに使用されることが可能であるネットワーク通信プロトコルの典型的な態様を図示している。
【図１１】一又は複数の画像ソース装置と一又は複数の対象表示装置との間のネットワーク通信を容易にするのに使用されることが可能であるネットワーク通信プロトコルの典型的な態様を図示している。
【図１２】一又は複数の画像ソース装置と一又は複数の対象表示装置との間のネットワーク通信を容易にするのに使用されることが可能であるネットワーク通信プロトコルの典型的な態様を図示している。
【発明を実施するための形態】
【０００５】
図１は、概して20で、本願発明の第１の実施の形態にかかる画像データ処理システムの模式図を示している。画像処理システム20は、表示面24に画像を表示するように構成された表示装置22を備えている。表示装置22は、任意の適切な種類の表示装置であることが可能である。本例は、液晶表示装置（LCD）およびデジタル光処理（DLP）プロジェクタ、テレビジョン・システム、コンピュータ・モニタなどを含むが、これらに限定されるものではない。
【０００６】
画像処理システム20は、さらに、表示装置22に付随する画像レンダリング装置26と、ネットワーク30を介して画像レンダリング装置26と電気的に通信する一又は複数の画像ソース28とを備えている。画像レンダリング装置26は、画像ソース28によって送信された画像データを受信し、受信画像データを表示装置22による表示用に処理するように構成されている。画像レンダリング装置26は、表示装置22と一体にされるか、または、表示装置に接続可能な個別の構成要素として設けられることが可能である。適切な画像レンダリング装置の一例は、2003年6月2日に出願された米国特許出願第10/453,905号に開示され、それは参照によってここに援用される。システム20の部分間の相互接続は、無線（たとえば、ネットワーク30は、無線ネットワークであることが可能である）、有線、あるいは無線および有線リンクの組み合わせであることが可能である。
【０００７】
典型的には、画像データは、ラップトップもしくはデスクトップ・コンピュータ、携帯情報端末（PDA）または他の演算装置のような画像ソースを介して表示装置に供給される。いくつかの表示装置は、たとえば、802.11b（あるいは他の802.11プロトコル）、Bluetooth（登録商標）などのような通信プロトコルを介して、画像ソースから無線で画像データを受信するように構成されている。これらの表示装置は、画像ソースが会議室内の殆どいずれの位置からでも高速に接続されることを可能にし、したがって単一の表示装置での複数の画像ソースの使用を容易にすることが可能である。
【０００８】
しかしながら、単一の表示装置での複数の画像ソースの使用をサポートすることは、様々な障害を引き起こす場合がある。たとえば、異なる画像ソースが、異なるフォーマットの画像ファイルを生成および／または表示する異なるソフトウェアを利用することがある。この場合には、複数の画像ソースをサポートする表示装置は、多くの異なる種類の画像ファイルを解凍し、レンダリングし、および／または表示する適切なソフトウェアを備えている必要がある場合がある。多くの場合には、このソフトウェアは、表示装置のメーカ以外の会社によって提供されることがある。したがって、そのようなソフトウェアのインストールおよび更新は、表示装置をソフトウェア・ウィルス、プログラム・バグ、およびその表示装置のメーカがコントロールできない他の問題に晒すことがある。さらに、所望する画像データのフォーマットをすべて表示するために必要とされる複数のソフトウェア・プログラムを記憶および実行するために、比較的大きい量のメモリおよび処理能力が要求されることがある。
【０００９】
表示装置上で必要とされるソフトウェアの容量を低減する１つの可能性のある方法は、各画像ソースから表示装置に、フォーマットされた画像データ・ファイルではなく、生のデータ・ファイルだけを転送することである。この場合には、表示装置は、単一の画像データのフォーマットをサポートすることだけが必要となり、表示装置のソフトウェア要求を単純化することが可能である。しかしながら、そのような生のデータ・ファイルは、フォーマットされた画像ファイルと比較して大きい場合があり、したがって、使用される通信チャネルの帯域幅に依存して、画像ソースから表示装置に転送するのに比較的長い時間を必要とすることがある。それが、そのような表示装置でリアルタイムに動画を表示することが望まれる場合には、通信チャネルの帯域幅は、生の画像データ・ファイルを典型的な動画データのフレーム・レート（典型的には、約20フレーム／秒以上）で転送するには小さ過ぎることがある。
【００１０】
図１に戻って参照して、画像ソース28は、画像データを画像レンダリング装置26に供給することができる任意の適切な装置を備えることが可能である。本例は、デスクトップ・コンピュータおよび／またはサーバ28a、ラップトップ・コンピュータ28b、携帯情報端末（PDA）28c、携帯電話機28dなどを含んでいるが、これらに限定されるものではない。これに加えて、画像ソース28は、任意の適切な方法で画像レンダリング装置26と電気的に通信することが可能である。図示された実施の形態においては、各画像ソース28は、無線ネットワーク30を通じて画像レンダリング装置26と電気的に通信する。しかしながら、画像ソース28は、有線ネットワークを通じて、無線もしくは有線直接接続など、またはその任意の組み合わせを通じて、画像レンダリング装置26と通信することも可能である。
【００１１】
画像ソース28および／または表示装置22は、図２の典型的な演算装置40に示される構成要素のうちのいくつかまたはすべてを有している演算装置として実施されることが可能である。演算装置40は、バス48によって相互接続されたプロセッサ42、メモリ44および／または記憶装置46を備えている。さらに、様々な入力装置50（たとえば、キーボード、マウスなど）が、ユーザ入力を可能にするために接続されることが可能である。出力は、表示コントローラ52に結合されたモニタまたは他の表示装置を介して提供されることが可能である。示されるように、ネットワーク・インタフェース54は、ネットワーク30に接続された他の装置との通信を可能にするようにバス48に結合されることも可能である。より詳細に議論されるように、ここに記述される画像処理システムおよび方法においては、多くの場合、サーバ表示装置（たとえば、表示装置22）でネットワークを通じて無線通信することは、画像ソース／クライアント装置（たとえば、画像ソース28）にとって望ましいであろう。クライアントおよび／またはサーバ装置においては、無線プロトコルを含むネットワーク通信ソフトウェア60は、メモリ44内で実行し、無線ネットワーク通信を可能にするように動作することが可能である。
【００１２】
図１を再び参照して、画像ソース28が複数のフォーマットでの画像データを処理するように構成される場合には、画像レンダリング装置26は、各々の所望の画像データ・フォーマットでデータを復号化するように構成されることが可能である。しかしながら、上述したように、これは、各々の所望のフォーマットを復号化するために、個別のソフトウェア・プログラムを記憶するのに十分なメモリを有することを画像レンダリング装置26に要求することがある。これに加えて、これらのソフトウェア・プログラムの多くは、画像レンダリング装置26のメーカ以外のソースによって提供されることがある。したがって、そのようなソフトウェアの使用は、画像レンダリング装置26のメーカによる画像レンダリング装置26および／または表示装置22にインストールされたソフトウェア・プログラムに関してのコントロールを低下させることがある。これは、ソフトウェアのインストール、更新などの間に外部のソフトウェアによって導入されるウィルス、バグ、および他の問題に対してこれらの表示装置をオープンにすることがある。
【００１３】
画像レンダリング装置26の操作およびソフトウェア要求を単純化するために、各画像ソース28は、ディスプレイ32上に画像のビットマップを生成し、その後、そのビットマップを表示装置22による表示用に画像レンダリング装置26に送信するように構成されたソフトウェアを含むことが可能である。これには、画像レンダリング装置26が単一のフォーマットの画像データを受信および復号化するためのソフトウェアを含むことだけが必要であるという利点があり、したがってソフトウェアのインストールおよび／または更新中に画像レンダリング装置26へのウィルス、バグ、および他の問題の導入を防ぐことを助ける。しかしながら、上述したように、圧縮されていないビットマップ・ファイルは、かなり大きいことがあり、したがって使用される通信チャネルの帯域幅に依存して画像レンダリング装置26に送信するのに比較的長い時間が掛かることがある。これは、XGA以上のような比較的高解像度フォーマットの画像に特に真実である。データが動画データである場合、新しいデータ・フレームが画像レンダリング装置26に転送される速度は、約20フレーム／秒以上であることが可能である。この場合には、フレーム・レートは、全体のビットマップが生成され、且つ、画像レンダリング装置26に送信されることができる速度よりも速いことがあり、動画像の送信および表示におけるエラーに恐らく帰着する。
【００１４】
送信およびを表示エラーを回避するために、画像ソース28のうちの１つに表示される画像から生成されたビットマップは、画像データの各フレームに対して送信されるデータの量を減少させるために送信の前に処理されることが可能である。図３は、概して100で、画像ソース28のうちの１つでのディスプレイ32から生成されたビットマップ画像データを処理する方法の典型的な実施の形態を示している。本方法100は、ソフトウェア・コードによって典型的には実行され、画像ソース28のメモリに典型的には記憶され、各画像ソースのプロセッサによって実行可能である。
【００１５】
画像レンダリング装置26に送信されるデータの量を減少させるために、本方法100は、現在のフレームの直前に送信された画像データのフレームまたは組とは異なる画像データのフレームまたは組のそれらの部分だけを典型的には送信する。したがって、本方法100は、まず、102で、前に送信された画像データNの組またはフレームを、ディスプレイ32に現在表示されている画像データN+1の組またはフレームと比較し、次に、104で、フレームNとは異なるフレームN+1の部分を判断することが可能である。
【００１６】
102での２つのフレームの画像データの比較と、104での変更された部分の判断とは、任意の適切な方法で実行されることが可能である。たとえば、フレームNおよびN+1のそれぞれは、バッファに記憶されることが可能であり、その後、N+1バッファに記憶された画像データの各画素は、Nバッファに記憶された画像データの各画素と比較されることが可能である。
【００１７】
変更の位置が特定されると、変更された領域は任意の適切な方法で圧縮用に定義されることが可能である。たとえば、或る実施の形態においては、検出された変更のすべては、画像データのフレームN+1の変更された領域のすべてを包含するように描かれた可変サイズの単一の矩形領域によって規定されることが可能である。しかしながら、変更された部分を定義するそのような方法には、前に送信されたフレームから実際には変更されていない著しい量のデータの圧縮および送信に導く状態が存在することがある。
【００１８】
したがって、106で示されるように、本方法100は、変更された部分を異なる領域に分割することによって、画像データ・フレームNの変更された部分を定義することを含むことが可能である。前記領域は、典型的には、変更されていないデータの送信を最小限にするために、フレームの与えられた変更部分の周囲に定義されることができる最小の境界矩形である。
【００１９】
図３を依然として参照して、変更された部分を領域に分割する前に、同時に、あるいは後に、本方法100は、108で、画像のカラー・パレットが符号化および送信されたことを判断すること、および、110で、圧縮した画像データの解凍を助けるために画像レンダリング装置26にカラー・パレットに関する更新を送信することを含むことが可能である。これは、24ビット色が、カラー・パレットにおいて8ビットのルックアップ値によって省略されることがあるからである。色が繰り返し使用されるときに、8ビットの省略は、より少ない送信データに帰着する。これに加えて、あるいは、これに代えて、当然のことながら、任意のビット・サイズのルックアップ・テーブルが使用されることが可能である。たとえば、12または16ビットが使用されることが可能である。
【００２０】
次に、画像データは、118で、輝度／クロミナンス色空間に変換されることが可能である。適切な輝度／クロミナンス色空間の例は、YCrCb色空間のような装置依存の色空間のみならず、CIE XYZおよびCIE L*a*b*色空間のような装置非依存の色空間を含んでいる。適切な装置非依存の色空間の別の例は、次のようなものである。色空間は、輝度値rおよびクロミナンス値sおよびtを含んでおり、次の数式によってCIE L*a*b*色空間が導き出される。
【００２１】
r(L*-L*min)(rmax/(L*max-L*min))
s(a*-a*min)(smax/(a*max-a*min))
t(b*-b*min)(tmax/(b*max-b*min))
これらの数式から演算されたr、s、およびt値は、浮動小数点から整数の形態に数字の形態を変更され、したがって色空間における値に関する演算を単純化するために、最も近い整数値に丸められるか、あるいは切り捨てられることが可能である。これらの数式においては、値L*max、L*min、a*max、a*min、b*max、およびb*minは、L*、a*、およびb*色空間座標の各々の実際の範囲に対応することが可能であるか、または、CIE L*a*b*色空間上にマップされたときに、選択された画像装置28の色空間のような別の色空間の最大値および最小値に対応することが可能である。値rmax、smax、およびtmaxは、r、s、およびt色座標の各々に対する最大の整数値に対応し、座標の各々を特定するのに使用されるビット数に依存する。たとえば、6ビットが各座標を表現するのに使用される場合には、各座標（0〜63）に対して64の可能な整数値が存在し、rmax、smax、およびtmaxのそれぞれは、値63を有している。
【００２２】
色空間変換の後、低変化データは、120で、フィルタリングされ、非コンピュータ・グラフィックス・データ（「非CGデータ」）をコンピュータ・グラフィックス・データ（「CGデータ」）により近似させるようにすることが可能である。動画ゲーム、デジタルのスライド表示ファイルなどのようなCGデータを有している画像は、映画、スチール写真などのような非CGデータを有している画像よりも高周波数の画像データを備えたよりシャープな色境界を有する傾向にある。色境界でのこれらのデータの種類の異なる特性により、異なる圧縮アルゴリズムが、非CGデータよりもCGデータに対してうまく作用する傾向にある。いくつかの公知の画像データ処理システムは、データがCGデータであるか、あるいは非CGデータであるか否かを判断し、次に、各データの種類に対して異なる圧縮器を利用することを試みる。しかしながら、非CGデータとしてCGデータを誤認すること、あるいはこの逆は、これらのシステムの圧縮効率の損失に導くことがある。したがって、低変化データ120のフィルタリングは、あらかじめ選択された閾値変化よりも小さい変化を有する隣接した画像データ値を特定し（それは同系色間の移行を示すことがある）、次に、変化を低減するために画像データ値のうちのいくつかを変更し、それによってCGデータにより近似した色境界を生成することを含むことが可能である。したがって、低変化データのフィルタリングは、非CGデータおよびCGデータが同じ圧縮器で適切に圧縮されることを可能にすることがある。非CGデータになされた変更は、典型的には、認知可能な閾値よりも小さい変化を有する隣接した値にのみなされるが、その変更は、随意に、認知可能な閾値よりも大きい変化を有する値になされることも可能である。
【００２３】
いずれの適切な方法も、画像データ階層内の画像データから低変化データをフィルタリングするのに使用されることが可能である。適切な方法の一例は、低変化データを平滑化するための単純なノッチ・ノイズ除去フィルタを利用することである。ノッチ・ノイズ除去フィルタは、次のように実施されることが可能である。pcで現在の画素、plで現在の画素の左側の画素、そして、prで現在の画素の右側の画素を表現する。まず、pcとplとの間の差dl、およびpcとprとの間の差drが演算される。次に、dlおよびdrが比較される。dlおよびdrの絶対値が等しくなく、dlおよびdrのうちの小さい方の絶対値があらかじめ選択された認知可能な閾値よりも小さい場合には、pcは、dlおよびdrのうちの小さい方を0に変更するために、plまたはprと等しくリセットされることが可能である。これに代えて、同じ結果を達成するために、plおよびprのうちのいずれかが、等しいpcに変更されることも可能である。
【００２４】
dlおよびdrの絶対値が等しい場合には、pcを等しいplに変更することは、pcを等しいprに変更することと等価であるかも知れない。この場合には、dlおよびdrの絶対値が所定の認知可能な閾値よりも小さい場合には、pcは、plおよびprのうちのいずれかと等しく変更されることが可能である。さらに、dlおよびdrの絶対値が両方ともあらかじめ選択された認知可能な閾値よりも大きい場合には、pc、pl、またはprのいずれも変更されない。当然のことながら、上記フィルタリング方法は、単に典型的なものであり、非CGをCGデータにより近似させるために低変化データをフィルタリングする他の適切な方法が使用されることも可能である。たとえば、dlおよびdrの絶対値が、あらかじめ選択された認知可能な閾値以下である場合には、判断関数が、右または左、あるいは上または下に隣接する画素と一致するように現在の画素を変更するべきか否かを判断するのに使用されることが可能である。
【００２５】
非CGデータをよりCGデータに近似させるために低変化データをフィルタリングすることに加えて、本方法100は、122で、画像データのクロミナンス値の副標本を抽出することをさらに含むことが可能である。一般に、色度の副標本抽出は、少なくとも１つの色空間成分を少なくとも１つの他の色空間成分よりも低い空間周波数でサンプリングすることを含む圧縮技術である。解凍装置は、欠落成分を再演算する。輝度／クロミナンス色空間のための共通の副標本抽出データのフォーマットは、クロミナンス成分が水平方向において輝度成分の空間周波数の２分の１で、且つ、垂直方向において同じ空間周波数でサンプリングされる4:2:2副標本抽出と、クロミナンス成分が垂直および水平方向の両方向に沿って輝度成分の空間周波数の２分の１でサンプリングされる4:2:0副標本抽出とを含んでいる。これらの副標本抽出フォーマット、あるいは任意の他の適切な副標本抽出フォーマットのいずれかが、画像データのクロミナンス成分を副標本抽出するのに使用されることが可能である。
【００２６】
120で低変化データをフィルタリングし、そして、122でクロミナンス・データを副標本抽出した後で、本方法100は、次に、124で、送信データ量をさらに低減するために一又は複数の他の圧縮技術を採用する。典型的には、CGデータに対して良い圧縮を提供する圧縮方法が利用される。図示された例においては、本方法100は、126でデルタ変調圧縮ステップと、128でLZO圧縮ステップとを採用している。LZOは、圧縮比に対して速度が有利であるリアルタイム、ポータブル、非損失な圧縮方法であり、特に、CGデータのリアルタイム圧縮に適している。LZOには、同様に、他の利点がある。たとえば、LZO解凍には、最低限のメモリしか必要ではなく、圧縮には64キロバイトのメモリが必要なだけである。
【００２７】
一旦、画像データがソース装置（たとえば、装置28）から得られ、圧縮されると、圧縮されたデータは、画像レンダリング装置26に送信されることが可能である。動画データの送信においては、選択されたフレームを表わす画像データは、フレーム間隔中に通信チャネルを通じて送信することができる最大データ量よりも大きいことがある。この場合には、画像ソース28は、次のフレームの圧縮および送信が開始される前に、画像データの１つのフレームに対して送信することができるのと同じ量のデータだけを送信するように構成されることが可能である。
【００２８】
送信された画像データは、画像レンダリング装置で受信され、表示面24での表示用に表示装置22によって処理される。様々な特徴が、解凍性能を改善し、そして、したがって動画像を示すときの表示装置22および画像レンダリング装置26の性能を改善することを助ける解凍処理で実施されることが可能である。たとえば、副標本抽出された画像データの解凍を助けるために、画像レンダリング装置26は、解凍演算を実行するプロセッサに付随するキャッシュ・メモリよりも小さい解凍中の画像データを記憶する解凍バッファを備えることが可能である。
【００２９】
副標本抽出された画像データを解凍する公知の解凍システムは、典型的には、欠落クロミナンス値を演算する前に解凍バッファに圧縮した画像データの組全体を読み込む。頻繁に、圧縮した画像データは、それがバッファに読み込まれるときにキャッシュ・メモリにコピーされ、それは、キャッシュに記憶された値が解凍演算のために、より高速にアクセスされることを可能にする。しかしながら、圧縮した画像ファイルのサイズがキャッシュ・メモリよりも大きいことがあるので、キャッシュ・メモリ中のいくつかの画像データは、圧縮した画像データがバッファにコピーされるときに他の画像データによって上書きされる場合がある。キャッシュ・メモリ中の画像データの上書きは、画像データを解凍しているプロセッサがキャッシュ・メモリ中の上書きされたデータを捜すときに、キャッシュ・ミスを引き起こすことがある。あまりにも多くのキャッシュ・メモリの発生は、不利益な程度まで画像解凍を遅くすることがある。
【００３０】
キャッシュ・メモリよりも小さい解凍バッファの使用は、キャッシュ・ミスの発生を回避するのを助けることが可能である。キャッシュ・メモリは、典型的に比較的小さなメモリであるので、さらに、そのような解凍バッファは、ほとんどの画像ファイルよりも小さいことが可能である。換言すれば、画像データがA x B画素配列を有する画像を表わす場合には、解凍バッファは、画像データのA x C配列（ここでは、CはBよりも小さい）を保持するように構成されることが可能である。そのようなバッファは、バッファおよびキャッシュ・メモリに副標本抽出された画像データの組を、画像データの一連のより小さな部分集合として読むことによってその副標本抽出された画像データの組を解凍するのに使用されることが可能である。各画像データの部分集合は、圧縮した画像データの新しい部分集合が解凍バッファに読み込まれる前に、解凍され、バッファから出力されることが可能である。解凍バッファがキャッシュ・メモリよりも小さいので、キャッシュ・メモリ中のいずれの画像データも解凍演算に使用される間、上書きされるであろう可能性は低い。
【００３１】
解凍バッファは、任意の適切なサイズを有していていることが可能である。一般には、解凍バッファがキャッシュ・メモリに対して小さければ小さいほど、著しい数のキャッシュ・ミスの発生の可能性は低くなる。さらに、解凍バッファにおいて解凍される副標本抽出された画像データの種類と、圧縮した画像データを解凍するのに使用される演算の種類とは、解凍バッファのサイズに影響を及ぼすことがある。たとえば、4:2:0画像データ中の欠落クロミナンス成分は、副標本抽出されたクロミナンス値がコサイトにあるか、あるいは非コサイトにあるかに依存して異なって演算されることが可能である。コサイトのクロミナンス値は、選択された輝度値として画像上の同じ物理的位置で配置される一方、非コサイトのクロミナンス値は、いくつかの関連している輝度値間で間質的に配置される。4:2:0コサイト画像データの欠落クロミナンス値は、演算される欠落クロミナンス値の物理的位置に依存して、欠落値と同じライン、または隣接するラインのいずれかの副標本抽出されたクロミナンス値から演算されることが可能である。したがって、クロミナンス値が無いデータ・ラインを有している4:2:0コサイトの画像データを解凍するための解凍バッファは、欠落クロミナンス値が垂直方向に隣接するクロミナンス値から演算されることを可能にする複数ラインの画像データを保持するように構成されることが可能である。
【００３２】
任意の適切な方法が、単一のフレーム間隔中に画像ソース28から画像レンダリング装置26にどのくらいの量の画像データが送信されることがあるかを判断するのに使用されることが可能である。たとえば、簡単な方法は、送信がアクティブな画像ソース28上の画像データのフレームがいつ変更されるかを検出し、その検出された変更を、新しい圧縮および送信処理を開始するトリガとして使用することが可能である。このように、画像データの送信は、先の画像フレームに対するデータ送信が終了するときに（まだ完了していなければ）、選択された画像ソース上に表示された画像中に変更が検出されるまで続行されるであろう。
【００３３】
どれくらいの画像データが単一のフレーム間隔中に送信されることがあるかを判断する適切な方法の別の例は、通信チャネルの帯域幅を判断し、次に、検出された帯域幅および画像データの公知のフレーム・レートから、どれくらいの画像データが単一のフレーム間隔中に通信チャネルを通じて送信されることができるかを演算することを含んでいる。帯域幅は、圧縮した画像データの送信の前にあるいは送信中に一度判断されるか、または周期的に検出および更新されることが可能である。
【００３４】
上記の方法の様々な圧縮および送信操作を実施するソフトウェアは、単一のスレッド、単一の処理として動作することが可能であり、あるいは複数のスレッドまたは複数の処理、またはそれらの任意の組み合わせとして動作することが可能である。複数のスレッドあるいは複数の処理のアプローチは、送信帯域幅のようなシステム20のリソースが単一のスレッドあるいは単一の処理のアプローチよりも効率的に利用されることを可能にすることがある。様々な動作が、異なるスレッドまたは処理の任意の適切な個数で実行されることが可能である。たとえば、１つの実施の形態においては、３つの別個のスレッドが上記の典型的な方法の動作を実行するのに使用されることが可能である。これらのスレッドは、受信器、プロセッサおよび送信器と呼ばれることがある。受信器スレッドは、画像ソース28のスクリーン上の画像から生成されたビットマップ・データを得ることが可能である。プロセッサ・スレッドは、比較、領域分割、色空間変換、および本方法100の他の圧縮ステップを実行することが可能である。送信器スレッドは、上に議論された帯域幅監視および送信ステップを実行することが可能である。当然のことながら、これが単に典型的なソフトウェア・アーキテクチャであって、他の適切なソフトウェア・アーキテクチャが使用されることも可能である。
【００３５】
画像を表示するように、画像処理システム20は、クライアント装置（たとえば、画像ソース28）と、サーバ装置（たとえば、表示装置22）との間の通信を可能にするように構成されている。ここに記述された例においては、クライアントとサーバとは、別個の装置であるが、当然のことながら、クライアントとサーバとは、同じコンピュータ上に存在することも可能である。クライアント・サーバ通信を容易にするために、画像ソース28および／または表示装置22は、ネットワーク通信ソフトウェア60（図２）を備えることが可能である。図２において示されるように、通信ソフトウェア60は、クライアントまたはサーバ演算装置のメモリ44で実行するように構成されることが可能である。
【００３６】
典型的には、通信ソフトウェア60は、表示装置22で画像の表示を可能にするために画像データの転送を容易にする通信プロトコルを備えているか、または利用する。プロトコルは、図４に示されるように、クライアント（たとえば、画像ソース28）とサーバ（表示装置22）との間で送信されるバイト182のストリーム180から構成されることが可能であり、クライアントからサーバに送信される順方向チャネル184と、サーバからクライアントに送信される反転チャネル186とを含んでいる。フロー制御は、典型的には、反転チャネル186を介して実施される。典型的には、ソフトウェアおよびプロトコルは、拡張性を提供し、複数で同時のクライアント接続をサポートしている。したがって、同時にオープンおよびアクティブな複数の順方向および反転チャネル対が存在することがある。
【００３７】
順方向チャネルは、クライアント・コンピュータによってサーバ・プロジェクタに送信される。反転チャネルは、サーバ・プロジェクタによってクライアント・コンピュータに送信される。典型的には、通信プロトコルは、図４において示されるように、フレーム200に編成されたデータから構成されている。順方向チャネルにおいて、各フレーム200は、ヘッダ202と、ボディ204と、トレーラ206とを備えることが可能である。
【００３８】
ボディ204は、典型的には、下に記述されるように、選択されたデータ構造を使用して符号化された1〜nの一連のタグを付けられたデータ部分とから構成されている。通信プロトコルの典型的な使用法は、タグを付けられたデータ部分のストリームが後に続く、接続（たとえば、TCP/IP接続）の最初でのヘッダ202の一度だけの送信を含んでいる。トレーラ206は、すべての実施において利用されても利用されなくてもよいが、ある場合には、トレーラの使用は、クライアント・サーバ接続の終了中に様々なタスクを実行するためには望ましいかも知れない。
【００３９】
プロトコルは、各ヘッダの終わり、および／または、タグを付けられたボディ・データ部分のいくつかまたはすべての終端にチェックサムを組み込むことが可能である。典型的には、チェックサムは、プログラム上のロジック・エラーを検出するのに利用される一方で、移送エラーが典型的にはいくつかの他の機構を通じて検出される。利用されるときに、チェックサムは、ブロックの最後（n番目）のバイトとして現われることがある。チェックサムは、データ・ブロックの前のn-1バイトのmodulo-256サムとして定義されることが可能である。
【００４０】
ヘッダ202は、典型的には、接続の最初でクライアントからサーバに送信されるデータを含んでいる。図５に示されるように、ヘッダは、4バイトの無署名の識別子210から構成されることが可能であり、それは、それぞれのクライアント装置に特有であっても特有でなくてもよい。或る実施においては、識別子210（それはマジックナンバーと呼ばれることもある）は、それぞれのクライアント装置を、対象サーバ装置への有効なコネクタとして特定あるいは認証する。たとえば、クライアント装置28c（図１）からサーバ装置26に送信されるバイト・ストリームは、クライアント装置がサーバ装置26の有効なユーザであったことをサーバ装置26に示すような識別子210を含むことが可能である。
【００４１】
ヘッダ202は、クライアント・サーバ通信に利用されるプロトコル・バージョンを特定するのに使用されることが可能であるバージョン・フィールド212を含むことも可能である。ヘッダ202は、接続しているクライアント装置のエンディアンネスまたは他のプラットフォームもしくはアーキテクチャ決定特性を示すためのエンディアンネス・フィールド214をさらに含むことが可能である。たとえば、エンディアンネスの宣言を含むプロトコルの実施においては、フィールド214は、接続する装置のアーキテクチャが、最も低いメモリ・アドレス（「リトル・エンディアン」）におけるマルチバイト・シーケンスの最小桁値を記憶するか、あるいはその代わりに、最も低いメモリ・アドレス（「ビッグ・エンディアン」）における最大桁値を記憶することを示すことが可能である。双エンディアン・アーキテクチャが示されることも可能である。フィールド214の使用は、画像処理システム20が多様なアーキテクチャを有した複数接続するクライアント装置中の相互運用を提供および達成する能力を増強することが可能である。
【００４２】
異なるエンディアンネスを備えた装置を取り扱うプロトコルおよび対象サーバ装置の能力にも拘わらず、それは、ある場合、識別子210に対する一貫したバイト・オーダを維持するのには望ましいことがある。たとえば、識別子210は、32ビットの無署名の整数としてではなく、むしろ４つの個々の無署名のバイトとして出力ストリームに書かれることが可能である。
【００４３】
ボディ204は、典型的には次のうちのいくつかまたはすべてを含むバイト・ストリームの形態を取っている：（１）色空間情報、（２）圧縮情報、（３）ビットマップ情報、（４）マークアップ言語コマンド、（５）解像度情報、（６）反転チャネル通信の認識、および（７）終了情報。典型的な実施においては、記述された通信プロトコルは、ボディ部分の構成要素が任意の順番で送信されるように処理状態を把握しない。しかしながら、それは、多くの場合には色空間情報がボディの送信の初めに送信されることが望ましいであろう。
【００４４】
記述された典型的なプロトコルは、タグベースのアーキテクチャを含んでおり、ここでは、識別タグは、受信位置での解析を容易にするために特定のデータ構造に関連付けられている。これは、プロトコルを非常に効率的にし、対象での画像表示のために必要であるときよりも少ないデータを画像ソース（たとえば、クライアント装置）が送信することを可能にする。たとえば、冗長な情報（たとえば、色空間情報）がサーバ表示装置に繰り返し送信される固定フォーマットとは対照的に、タグ・アーキテクチャは、情報が必要に応じてのみ送信されることを可能にする。
【００４５】
具体的には、プロトコルは、複数の異なるデータ構造（たとえば、下に議論されるように、ビットマップ・データ構造、圧縮構造など）を含むかまたは定義する。異なるデータ構造のそれぞれは、対象が最低量の処理リソースを使用する間、受信データを効率的に解析することを可能にするために、データ構造に関連する特有の識別タグを有している。たとえば、ビットマップ情報は、付随するビットマップ・タグを有したビットマップ・データ構造に符号化される。受信データ・ストリームにおけるビットマップ・タグおよび他のタグの存在によって、対象位置は、受信データを効率的に解析することが可能である。
【００４６】
図６は、色空間データ構造220に符号化された色空間情報を含んだ典型的なバイト・ストリーム部分を図示している。図に示されるように、最初のバイト（あるいは１ビットまたは複数のビット）は、色空間情報を含むようなバイト・ストリーム部分を識別する色空間タグ222を含むことが可能である。後続する順方向チャネルの内容（たとえば、画像ビットマップ情報）用に使用される色空間は、バイトまたは部分224によって示されている。RGB（生）、YCbCr 4:4:4コサイト、YCbCr 4:2:2コサイト（DVCPRO50、デジタルBetacam、デジタルS）、YCbCr 4:1:1コサイト（YUV12）（480ラインDV、480ラインDVCAM、DVCPRO）、YCbCr 4:2:0（H.261、H.263、MPEG 1）、YCbCr 4:2:0（MPEG 2）、および YCbCr 4:2:0コサイト（576ラインDV、DVCAM）を含む任意の望ましい色空間が利用されることが可能である。色空間情報は、エラー・チェックを提供するためにチェックサム226を末尾に付けることが可能である。
【００４７】
図７は、圧縮データ構造240に符号化された圧縮情報を含む典型的なバイト・ストリーム区画を図示している。圧縮情報は、典型的には、送信される画像情報がどのように圧縮されるかまたは圧縮されているかを記述している。図に示されるように、データ構造は、圧縮情報を含むようなバイト・ストリーム部分を識別する圧縮タグ242を含むことが可能である。利用される圧縮方法は、バイトまたは部分244によって示されている。LZ圧縮および／または他の方法を含む任意の望ましい圧縮技術またはアルゴリズムが利用されることが可能である。さらに、部分244は、データが圧縮されていないことを示すために使用されることが可能である。プロトコルの他の部分でのように、チェックサム246は、圧縮情報のエラー・チェックを提供するのに使用されることが可能である。
【００４８】
典型的には、図８に示されるように、順方向チャネルのボディ部分は、さらに、対象サーバ装置26で表示される画像に対応するビットマップ情報の複数のバイトを含むであろう。ビットマップ情報の各部分は、ビットマップ構造260に符号化されることが可能である。構造260は、ビットマップ情報を含むようなデータ・ストリーム区画を識別するビットマップ・タグ（バイト1）を含むことが可能である。内容値（バイト2）のバイトまたはフィールドは、再構成されたビットマップがビット・ブロック転送（BLT）（生）を使用して、あるいは、XOR BLT（インクリメント）を使用してスクリーンにコピーされるか否かを示すために含まれることが可能である。さらに、示されるように、ビットマップ構造260は、ビットマップの垂直方向のオリエンテーション、ビットマップのサイズおよび開始位置（X-Y直線座標方法を使用して）、データ・ブロックのサイズ、および実際のデータ・ブロックに関係するデータを含むように定義されることが可能である。典型的には、チェックサムは、データ・ブロックの終端で利用されるであろう。
【００４９】
ボディ部分204は、HTMLまたはXMLのようなマークアップ言語で送信されるコマンド／情報を含む様々なフォーマットで送信される他のコマンドまたは情報を含むことも可能である。図９は、マークアップ構造280に符号化されたデータ・ストリーム部分の例を図示している。図に示されるように、符号化されたデータ・ストリーム部分は、ボディ部分204の他の構成要素と同様に、データ・ストリーム部分の（バイト1）およびエラー補正のために末尾に付けられたチェックサム（バイトn）の性質を識別する最初のタグを含むことが可能である。内容値バイト（バイト2）は、使用されているマークアップ言語（HTML、XMLなど）を特定するのに使用されることが可能であり、後続のバイトは、マークアップ言語の送信サイズを特定し、実際のマークアップ言語の情報を送信するのに使用されることが可能である。
【００５０】
図１０に示されるように、順方向チャネルのボディは、対象サーバ装置で使用される解像度を特定するのに使用されるバイトを含むことも可能である。示されるように、設定解像度情報（たとえば、設定解像度データ構造300に符号化された）は、最初の識別タグを含むことが可能であり、XおよびY解像度を特定するバイト、色深さ、およびエラー補正のためのチェックサムが後に続く。
【００５１】
順方向チャネルは、クライアントとサーバ装置との間の相互作用を容易にするための他の情報またはデータを含むことが可能である。バイト・ストリーム区画は、反転チャネル186上のサーバによって送信される設定スケール・コマンドを承認するために、および／または終了要求を送信するためにサーバの再開を要求するのに使用されることが可能である。トレーラ206は、接続の終了またはデータ送信の或る部分の終端に関連する様々なタスクを実行するために利用されることが可能である。
【００５２】
反転チャネル186は、フロー制御および他の機能性を提供するのに使用されることが可能である。典型的には、反転チャネル186は、順方向チャネル（たとえば、ヘッダ、ボディ、およびトレーラ区画を備えた）と同様のフレーム・フォーマットを使用するであろう。フロー制御は、利用可能なサーバ・バッファのサイズを周期的に（たとえば、1秒当たり10回）報告するサーバによって実施されることが可能である。報告されたバッファ・サイズには、典型的には、後続のバイトが図１１の典型的なバッファ・サイズ・ストリーム320に示されるようにバッファ・サイズに関する情報を含むことを示す識別タグが先行する。その後、利用可能なバッファ・サイズが報告される。現在の典型的な実施の形態においては、バッファ・サイズは、4バイトのストリームで報告され、次に、末尾に付けられたチェックサム・バイトがエラー・チェックを提供する。その後、報告された利用可能なバッファは、順方向チャネル184におけるその送信速度を動的に調整するためにクライアントによって使用されることが可能である。
【００５３】
図１２に示されるように、反転チャネル186は設定スケール・バイト・ストリーム区画340を含むことも可能である。識別タグに続いて、4バイトが、XおよびY次元のスケールを特定するのに利用されることが可能である。チェックサム・バイトは、エラー・チェックを提供するために再び使用される。反転チャネル通信は、特定のクライアント装置または接続を終了するためにサーバによる要求を含むことも可能である。
【００５４】
さらに、本開示は、特定の実施の形態を含んでいるが、特定の実施の形態は、複数の変形が可能であるので、限定した意味で考慮されるべきではない。本開示の主題は、ここに開示された種々の要素、特徴、機能、および／または特性の新規且つ非自明なコンビネーションおよびサブコンビネーションをすべて含んでいる。請求項は、新規且つ非自明であると見なされる或るコンビネーションおよびサブコンビネーションを特に指し示している。これらの請求項は、「１つの」要素もしくは「第１の」要素、またはその均等物を参照することがある。そのような請求項は、一又は複数のそのような要素の援用を、複数のそのような要素を除外することも要求することもなく含むと解釈されるべきである。特徴、機能、要素、および／または特性の他のコンビネーションおよびサブコンビネーションは、現在の請求項の補正を通じて、あるいはこのもしくは関連する出願において新しい請求項を提示することを通じて請求されることが可能である。そのような請求項は、元の請求項の範囲よりも広く、より狭く、等しく、あるいは異なっても、本開示の主題に含まれると見なされる。
【符号の説明】
【００５５】
20  画像処理システム、22  表示装置、26  画像レンダリング装置、28  画像ソース、30  ネットワーク、32  ディスプレイ、40  演算装置、44  メモリ、46  記憶装置、50  入力装置、52  表示コントローラ、54  ネットワーク・インタフェース、60  通信ソフトウェア（無線プロトコル付属）、100  方法、180  ストリーム、182  バイト、184  順方向チャネル、186  反転チャネル、200  フレーム、202  ヘッダ、204  ボディ、206  トレーラ、220  色空間データ構造、240  圧縮データ構造、260  ビットマップ構造、280  マークアップ構造、300  設定解像度データ構造、320  バッファ・サイズ・ストリーム、340  設定スケール・バイト・ストリーム。
【図１】
2010268494.tif 000003
【図２】
2010268494.tif 000004
【図３】
2010268494.tif 000005
【図４】
2010268494.tif 000006
【図５】
2010268494.tif 000007
【図６】
2010268494.tif 000008
【図７】
2010268494.tif 000009
【図８】
2010268494.tif 000010
【図９】
2010268494.tif 000011
【図１０】
2010268494.tif 000012
【図１１】
2010268494.tif 000013
【図１２】
2010268494.tif 000014
【手続補正書】
【提出日】平成22年7月27日(2010.7.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
画像ソースであって、
前記画像ソースから画像表示装置へ画像データの送信を通信路を用いて可能にし、前記画像表示装置を、前記画像データに基づいて画像を表示させるように構成してなる画像ソースにおいて、
前記画像データは、
ビットマップ情報を含むように定義されたビットマップ構造を含む複数の異なるデータ構造と、
複数の異なるタグとを具備し、
前記画像データが、連続するデータ・ストリームとして生じるよう構成される場合には、前記連続するデータ・ストリームは、複数の異なるデータ構造から一つ選択されたデータ構造の符号化されたデータ部分を含み、
前記複数の異なるタグのそれぞれは、前記連続するデータ・ストリームの解析を可能にするように、前記複数の異なるデータ構造の特定の１つに対応し、
前記複数の異なるデータ構造は、色空間情報を含むように定義された色空間構造を含むか、または、圧縮情報を含むように定義された圧縮構造を含むか、または、マークアップ情報を含むように定義されたマークアップ構造を含むか、または、設定解像度情報を含むように定義された設定解像度構造を含むか、のいずれかであることを特徴とする画像ソース。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００２
【補正方法】変更
【補正の内容】
【０００２】
単一の表示装置での複数の画像ソースの使用をサポートすることは、様々な障害を引き起こす場合がある。たとえば、異なる画像ソースが、異なるフォーマットの画像ファイルを生成および／または表示する異なるソフトウェアを利用することがある。この場合には、複数の画像ソースをサポートする表示装置は、多くの異なる種類の画像ファイルを解凍し、レンダリングし、および／または表示する適切なソフトウェアを備えている必要がある場合がある。多くの場合には、このソフトウェアは、表示装置のメーカ以外の会社によって提供されることがある。したがって、そのようなソフトウェアのインストールおよび更新は、表示装置をソフトウェア・ウィルス、プログラム・バグ、およびその表示装置のメーカがコントロールできない他の問題に晒すことがある。さらに、所望する画像データのフォーマットをすべて表示するために必要とされる複数のソフトウェア・プログラムを記憶および実行するために、比較的大きい量のメモリおよび処理能力が要求されることがある。
表示装置上で必要とされるソフトウェアの容量を低減する１つの可能性のある方法は、各画像ソースから表示装置に、フォーマットされた画像データ・ファイルではなく、生のデータ・ファイルだけを転送することである。この場合には、表示装置は、単一の画像データのフォーマットをサポートすることだけが必要となり、表示装置のソフトウェア要求を単純化することが可能である。しかしながら、そのような生のデータ・ファイルは、フォーマットされた画像ファイルと比較して大きい場合があり、したがって、使用される通信チャネルの帯域幅に依存して、画像ソースから表示装置に転送するのに比較的長い時間を必要とすることがある。それが、そのような表示装置でリアルタイムに動画を表示することが望まれる場合には、通信チャネルの帯域幅は、生の画像データ・ファイルを典型的な動画データのフレーム・レート（典型的には、約20フレーム／秒以上）で転送するには小さ過ぎることがある。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００３
【補正方法】変更
【補正の内容】
【０００３】
本発明に係る画像ソースは、
画像ソースであって、
前記画像ソースから画像表示装置へ画像データの送信を通信路を用いて可能にし、前記画像表示装置を、前記画像データに基づいて画像を表示させるように構成してなる画像ソースにおいて、
前記画像データは、
ビットマップ情報を含むように定義されたビットマップ構造を含む複数の異なるデータ構造と、
複数の異なるタグとを具備し、
前記画像データが、連続するデータ・ストリームとして生じるよう構成される場合には、前記連続するデータ・ストリームは、複数の異なるデータ構造から一つ選択されたデータ構造の符号化されたデータ部分を含み、
前記複数の異なるタグのそれぞれは、前記連続するデータ・ストリームの解析を可能にするように、前記複数の異なるデータ構造の特定の１つに対応し、
前記複数の異なるデータ構造は、色空間情報を含むように定義された色空間構造を含むか、または、圧縮情報を含むように定義された圧縮構造を含むか、または、マークアップ情報を含むように定義されたマークアップ構造を含むか、または、設定解像度情報を含むように定義された設定解像度構造を含むか、のいずれかであることを特徴とする。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】削除
【補正の内容】
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】削除
【補正の内容】