JP5761007B2 - 情報処理装置、画像送信方法及び画像送信プログラム - Google Patents

Description

本発明は、情報処理装置、画像送信方法及び画像送信プログラムに関する。

シンクライアントというシステムが知られている。シンクライアントシステムでは、クライアントに最低限の機能しか持たせず、サーバでアプリケーションやファイルなどのリソースを管理するようにシステムが構築される。

かかるシンクライアントシステムは、実際にはサーバが処理を実行した処理結果やサーバが保持するデータをクライアントに表示させつつも、あたかもクライアントが主体となって処理を実行したり、データを保持しているかのように振る舞う。

このように、サーバがクライアントに表示させる画面データを伝送する場合には、サーバ及びクライアント間のネットワークに輻輳が生じることによって伝送遅延が発生する場合がある。このネットワークの伝送遅延によって、サーバから伝送される画面データがクライアント側で描画されるのが遅れる結果、クライアントで行われる操作に対するレスポンスが悪化する。

ところで、画像のデータ量を削減する技術の一例としては、次のような画像符号化装置が挙げられる。この画像符号化装置では、動画と静止画の符号化の間で処理が重なる回路を共用するために、量子化テーブルの値を動画処理と静止画処理とで変更することによって動画処理と静止画処理の両方に対応した量子化を行う。他の一例としては、次のようなグラフィカル・ユーザ・インタフェースの適応ビデオ圧縮法が挙げられる。この圧縮方では、入力データストリームがビデオ、テキストや画像などの複数のメディアを混合する混合メディアデータである場合に、各メディアに対応するメタデータを取得した後に、入力データストリームを各メディアに対応する領域に分割する。その上で、圧縮法は、各メディアのメタデータを参照して、入力データストリームの各領域を圧縮するのに適切な圧縮アルゴリズムを選択する。

特開２０００−５０２６３号公報 特開２００７−４３６７３号公報

しかしながら、上記の従来技術では、以下に説明するように、データ伝送量が増大することを防止できないという問題がある。

すなわち、一般的には、動画の圧縮符号化を行った符号化データの方が静止画の圧縮符号化を行った符号化データよりもサイズを小さくできるが、かかる関係が必ずしも成立するとは限らない。例えば、画面が単純な背景の線画である場合には、色の数が多い画像の圧縮に強い動画の圧縮方式を適用するよりも、線画向きの静止画の圧縮方式を適用した方が画面データのサイズが小さくなる場合もある。このような場合に、動画の圧縮方式を適用し続けると、静止画の圧縮方式を適用する場合よりも画面データの圧縮率が低下する結果、データ伝送量が増大してしまう。それにもかかわらず、上記の従来技術は、いずれも画像が入力された段階で選択された圧縮方式を途中で変更できないので、データ伝送量の増大を防ぐことはできない。

開示の技術は、上記に鑑みてなされたものであって、データ伝送量の増大を抑制できる情報処理装置、画像送信方法及び画像送信プログラムを提供することを目的とする。

本願の開示する情報処理装置は、ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリを有する。さらに、前記情報処理装置は、ソフトウェアの処理結果を前記画像メモリに描画する描画部を有する。さらに、前記情報処理装置は、前記画像のフレーム間で更新があった更新領域を検出する更新領域検出部を有する。さらに、前記情報処理装置は、前記更新領域の画像を静止画圧縮する第１の圧縮部を有する。さらに、前記情報処理装置は、前記更新領域の静止画圧縮データの圧縮率を算出する第１の算出部を有する。さらに、前記情報処理装置は、前記画像のフレーム間で変更の頻度が所定の頻度を超える高頻度の変更領域を識別する識別部を有する。さらに、前記情報処理装置は、前記高頻度の変更領域の画像を動画圧縮する第２の圧縮部を有する。さらに、前記情報処理装置は、前記高頻度の変更領域の動画圧縮データの圧縮率を算出する第２の算出部を有する。さらに、前記情報処理装置は、前記更新領域の静止画圧縮データと前記高頻度の変更領域の動画圧縮データとを前記端末装置へ送信する送信部を有する。さらに、前記情報処理装置は、前記高頻度の変更領域の動画圧縮データの圧縮率と、前記動画圧縮が開始される以前のフレームで前記高頻度の変更領域に対応する位置に検出されていた更新領域の静止画圧縮データの圧縮率との比較結果に基づいて、前記第２の圧縮部による動画圧縮を中止させる中止制御部を有する。

本願の開示する情報処理装置の一つの態様によれば、データ伝送量の増大を抑制できるという効果を奏する。

図１は、実施例１に係るシンクライアントシステムに含まれる各装置の機能的構成を示すブロック図である。 図２は、デスクトップ画面の分割要領を説明するための図である。 図３Ａは、デスクトップ画面の変更頻度の判別要領を説明するための図である。 図３Ｂは、デスクトップ画面の変更頻度の判別要領を説明するための図である。 図３Ｃは、デスクトップ画面の変更頻度の判別要領を説明するための図である。 図４は、メッシュ連結体の補正要領を説明するための図である。 図５は、高頻度変更領域の候補の合成要領を説明するための説明図である。 図６Ａは、高頻度変更領域の属性情報の通知要領を説明するための図である。 図６Ｂは、高頻度変更領域の属性情報の通知要領を説明するための図である。 図６Ｃは、高頻度変更領域の属性情報の通知要領を説明するための図である。 図７Ａは、オブジェクトが回転操作された場合の画面の遷移例を示す図である。 図７Ｂは、オブジェクトが回転操作された場合の画面の遷移例を示す図である。 図７Ｃは、オブジェクトが回転操作された場合の画面の遷移例を示す図である。 図７Ｄは、オブジェクトが回転操作された場合の画面の遷移例を示す図である。 図８Ａは、オブジェクトが回転操作された場合におけるデータ伝送量と時間の関係の一例を示すグラフである。 図８Ｂは、オブジェクトが回転操作された場合におけるデータ伝送量と時間の関係の一例を示すグラフである。 図８Ｃは、オブジェクトが回転操作された場合におけるデータ伝送量と時間の関係の一例を示すグラフである。 図８Ｄは、オブジェクトが回転操作された場合におけるデータ伝送量と時間の関係の一例を示すグラフである。 図９は、画面の遷移の具体例を示す図である。 図１０は、図９に示した画面の遷移におけるデータ伝送量と時間の関係の一例を示すグラフである。 図１１は、実施例１に係る画像送信処理の手順を示すフローチャート（１）である。 図１２は、実施例１に係る画像送信処理の手順を示すフローチャート（２）である。 図１３Ａは、マップクリアの延長要領を説明するための図である。 図１３Ｂは、マップクリアの延長要領を説明するための図である。 図１４Ａは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。 図１４Ｂは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。 図１５は、実施例１及び実施例２に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。

以下に、本願の開示する情報処理装置、画像送信方法及び画像送信プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

［システム構成］
まず、本実施例に係るシンクライアントシステムの構成について説明する。図１は、実施例１に係るシンクライアントシステムに含まれる各装置の機能的構成を示すブロック図である。

図１に示すシンクライアントシステム１は、クライアント端末２０が表示するデスクトップ画面をリモートでサーバ装置１０に制御させるものである。つまり、シンクライアントシステム１は、実際にはサーバ装置１０が実行した処理結果や保持するデータをクライアント端末２０に表示させつつも、あたかもクライアント端末２０が主体となって処理を実行したり、データを保持しているかのように振る舞う。

図１に示すように、シンクライアントシステム１は、サーバ装置１０と、クライアント端末２０とを有する。なお、図１の例では、１つのサーバ装置１０に対し、１つのクライアント端末２０を接続する場合を図示したが、任意の数のクライアント端末が接続される場合にも同様に適用できる。

これらサーバ装置１０及びクライアント端末２０は、所定のネットワークを介して、相互に通信可能に接続される。かかるネットワークには、有線または無線を問わず、インターネット、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。なお、サーバ装置１０及びクライアント端末２０間の通信プロトコルには、一例として、ＶＮＣ（Virtual Network Computing）におけるＲＦＢ（Remote Frame Buffer）プロトコルを採用する場合を想定する。

サーバ装置１０は、クライアント端末２０に表示させる画面をリモートで制御するサービスを提供するコンピュータである。このサーバ装置１０には、サーバ向けのリモート画面制御用のアプリケーションがインストールまたはプリインストールされる。なお、以下では、サーバ向けのリモート画面制御用のアプリケーションのことを「サーバ側のリモート画面制御用アプリ」と記載する場合がある。

このサーバ側のリモート画面制御用アプリは、基本機能として、リモート画面制御サービスを提供する機能を有する。一態様としては、サーバ側のリモート画面制御用アプリは、クライアント端末２０における操作情報を取得した上でその操作により要求された処理を自装置で動作するアプリケーションに実行させる。そして、サーバ側のリモート画面制御用アプリは、アプリケーションにより実行された処理結果を表示するための画面を生成した上でその画面をクライアント端末２０へ送信する。このとき、サーバ側のリモート画面制御用アプリは、今回の画面生成の前にクライアント端末２０で表示させていたビットマップ画像との間で変更があった部分の画素が集まった領域、すなわち更新矩形の画像を送信する。なお、以下では、一例として、更新部分の画像が矩形の画像で形成される場合を説明するが、開示の装置は更新部分の画像が矩形以外の形状で形成される場合にも適用できる。

このほか、サーバ側のリモート画面制御用アプリは、フレーム間で動きが大きい部分のデータを動画向けの圧縮方式のデータに圧縮してクライアント端末２０へ送信する機能も有する。一態様としては、サーバ側のリモート画面制御用アプリは、クライアント端末２０に表示させるデスクトップ画面を複数の領域に分割し、分割した領域ごとに変更の頻度を監視する。このとき、サーバ側のリモート画面制御用アプリは、変更の頻度がしきい値を超えた領域、すなわち高頻度変更領域の属性情報をクライアント端末２０へ送信する。これとともに、サーバ側のリモート画面制御用アプリは、高頻度変更領域のビットマップ画像をＭＰＥＧ（Moving Picture Experts Group）−２やＭＰＥＧ−４などの動画圧縮方式の符号化データにエンコードした上でクライアント端末２０へ送信する。なお、ここでは、ＭＰＥＧ方式の符号化データへエンコードする場合を例示したが、これに限定されない。例えば、動画向けの圧縮方式であれば任意の圧縮符号化方式、例えばＭｏｔｉｏｎ−ＪＰＥＧ（Joint Photographic Experts Group）などを採用できる。

クライアント端末２０は、サーバ装置１０によるリモート画面制御サービスの提供を受ける側のコンピュータである。かかるクライアント端末２０の一例としては、パーソナルコンピュータ（personal computer）など固定端末の他、携帯電話機、ＰＨＳ（Personal Handyphone System）やＰＤＡ（Personal Digital Assistant）などの移動体端末を採用することができる。このクライアント端末２０には、クライアント向けのリモート画面制御用アプリケーションがインストールまたはプリインストールされる。なお、以下では、クライアント向けのリモート画面制御用のアプリケーションのことを「クライアント側のリモート画面制御用アプリ」と記載する場合がある。

このクライアント側のリモート画面制御用アプリは、マウスやキーボードなどの各種の入力デバイスを介して受け付けた操作情報をサーバ装置１０へ通知する機能を有する。一態様としては、クライアント側のリモート画面制御用アプリは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。

さらに、クライアント側のリモート画面制御用アプリは、サーバ装置１０から受信した画像を所定の表示部に表示させる機能を有する。一態様としては、クライアント側のリモート画面制御用アプリは、サーバ装置１０から更新矩形のビットマップ画像を受信した場合には、更新矩形の画像を前回のビットマップ画像から変更のあった位置に合わせて表示する。他の一態様としては、クライアント側のリモート画面制御用アプリは、サーバ装置１０から高頻度変更領域の属性情報を受信した場合には、その属性情報に含まれる位置に対応する表示画面上の領域をビットマップ画像の表示対象外のブランク領域とする。その上で、クライアント側のリモート画面制御用アプリは、動画の符号化データを受信した場合にそのデータをデコードした上でブランク領域に表示する。

［サーバ装置の構成］
次に、本実施例に係るサーバ装置の機能的構成について説明する。図１に示すように、サーバ装置１０は、ＯＳ実行制御部１１ａと、アプリ実行制御部１１ｂと、グラフィックドライバ１２と、フレームバッファ１３と、リモート画面制御部１４とを有する。なお、図１の例では、図１に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや表示デバイスなどの機能を有するものとする。

ＯＳ実行制御部１１ａは、ＯＳ（Operating System）の実行を制御する処理部である。一態様としては、ＯＳ実行制御部１１ａは、後述の操作情報取得部１４ａにより取得された操作情報からアプリケーションの起動指示やアプリケーションに対するコマンドを検出する。例えば、ＯＳ実行制御部１１ａは、アプリケーションのアイコン上でダブルクリックを検出した場合に、そのアイコンに対応するアプリケーションの起動を後述のアプリ実行制御部１１ｂへ指示する。また、ＯＳ実行制御部１１ａは、起動中のアプリケーションの操作画面、いわゆるウィンドウ上でコマンドの実行を要求する操作を検出した場合に、そのコマンドの実行をアプリ実行制御部１１ｂへ指示する。なお、以下では、アプリケーションのことを「アプリ」と記載する場合がある。

アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによる指示に基づき、アプリケーションの実行を制御する処理部である。一態様としては、アプリ実行制御部１１ｂは、ＯＳ実行制御部１１ａによってアプリの起動が指示された場合や起動中のアプリにコマンドの実行が指示された場合にアプリを動作させる。そして、アプリ実行制御部１１ｂは、アプリを実行することにより得られた処理結果の表示用イメージをフレームバッファ１３に描画する要求を後述のグラフィックドライバ１２へ行う。このようにグラフィックドライバ１２へ描画要求を行う場合には、アプリ実行制御部１１ｂは、表示用イメージとともに表示用イメージの描画位置をグラフィックドライバ１２へ通知する。

なお、アプリ実行制御部１１ｂが実行するアプリは、プリインストールされたものであってもよく、サーバ装置１０の出荷後にインストールされたものであってもかまわない。また、ＪＡＶＡ（登録商標）などのネットワーク環境で動作するアプリであってもよい。

グラフィックドライバ１２は、フレームバッファ１３に対する描画処理を実行する処理部である。一態様としては、グラフィックドライバ１２は、アプリ実行制御部１１ｂからの描画要求を受け付けた場合に、アプリの処理結果の表示用イメージをアプリにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。なお、ここでは、アプリを介して描画要求を受け付ける場合を例示したが、ＯＳ実行制御部１１ａからの描画要求を受け付けることもできる。例えば、グラフィックドライバ１２は、ＯＳ実行制御部１１ａからマウスカーソルの描画要求を受け付けた場合に、マウスカーソルの表示用イメージをＯＳにより指定されたフレームバッファ１３上の描画位置へビットマップ形式で描画する。

フレームバッファ１３は、グラフィックドライバ１２によって描画されたビットマップ画像を記憶する記憶デバイスである。かかるフレームバッファ１３の一態様としては、ＶＲＡＭ（Video Random Access Memory）を始めとするＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory）やフラッシュメモリ（flash memory）などの半導体メモリ素子が挙げられる。なお、フレームバッファ１３は、ハードディスク、光ディスクなどの記憶装置を採用することとしてもかまわない。

リモート画面制御部１４は、サーバ側のリモート画面制御用アプリを通じて、リモート画面制御サービスをクライアント端末２０へ提供する処理部である。このリモート画面制御部１４は、図１に示すように、操作情報取得部１４ａと、画面生成部１４ｂと、変更頻度判別部１４ｃと、高頻度変更領域識別部１４ｄとを有する。さらに、リモート画面制御部１４は、第１のエンコーダ１４ｅと、第１の送信部１４ｆと、第２のエンコーダ１４ｇと、第２の送信部１４ｈとを有する。さらに、リモート画面制御部１４は、算出部１４ｊと、中止制御部１４ｋと、上書き制御部１４ｍとを有する。

操作情報取得部１４ａは、クライアント端末２０から操作情報を取得する処理部である。かかる操作情報の一例としては、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などが挙げられる。また、操作情報の他の一例としては、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども挙げられる。

画面生成部１４ｂは、クライアント端末２０の表示部２２に表示させる画面の画像を生成する処理部である。一態様としては、画面生成部１４ｂは、デスクトップ画面の更新間隔、例えば３３ｍｓｅｃ（ミリ秒）が経過する度に、次のような処理を起動する。すなわち、画面生成部１４ｂは、前回のフレーム生成時にクライアント端末２０で表示させていたデスクトップ画面と、今回のフレーム生成時にフレームバッファ１３へ書き込まれたデスクトップ画面とを比較する。そして、画面生成部１４ｂは、前回のフレームから変更があった部分の画素をつなげ合わせた上で矩形に整形した更新矩形の画像を生成し、更新矩形送信用のパケットを生成する。

変更頻度判別部１４ｃは、デスクトップ画面が分割された領域ごとにフレーム間の変更の頻度を判別する処理部である。一例としては、変更頻度判別部１４ｃは、画面生成部１４ｂにより生成された更新矩形を図示しない作業用の内部メモリへ所定の期間にわたって蓄積する。このとき、変更頻度判別部１４ｃは、更新矩形の位置および大きさを特定可能な属性情報、例えば更新矩形の左上の頂点の座標と更新矩形の幅および高さとを蓄積する。かかる更新矩形を蓄積させる期間は、高頻度変更領域を識別する精度と相関関係があり、期間を長くするほど高頻度変更領域の誤検出が低減される。なお、ここでは、一例として、３３０ｍｓｅｃにわたって更新矩形の画像を蓄積する場合を想定する。

このとき、変更頻度判別部１４ｃは、更新矩形の画像を蓄積してから所定の期間が経過した場合に、クライアント端末２０に表示させるデスクトップ画面をメッシュ状に分割したマップを用いて、デスクトップ画面の変更頻度を判別する。

図２は、デスクトップ画面の分割要領を説明するための図である。図２に示す符号３０は、変更頻度判別用のマップを示す。図２に示す符号３１は、マップ３０に含まれるメッシュを指す。図２に示す符号３２は、メッシュ３１を形成する画素のブロックに含まれる１画素を指す。図２に示す例では、変更頻度判別部１４ｃがマップ３０を占める画素のうち８画素×８画素のブロックを１つのメッシュとして分割する場合を想定している。この場合には、１つのメッシュに６４個の画素が含まれることになる。

ここで、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する。そして、変更頻度判別部１４ｃは、更新矩形をマップに展開する度に、マップ上で更新矩形と重なり合った部分のメッシュの変更回数を累積して加算する。このとき、変更頻度更新部１４ｃは、マップ上に展開された更新矩形がメッシュに含まれる画素との間で所定数にわたって重なり合った場合に、そのメッシュの変更回数を１つ加算する。なお、ここでは、更新矩形がメッシュに含まれる画素と１つでも重なり合った場合に、メッシュの変更回数を加算する場合を想定して説明を行う。

図３Ａ〜図３Ｃは、デスクトップ画面の変更頻度の判別要領を説明するための図である。図３Ａ〜図３Ｃに示す符号４０Ａ、符号４０Ｂ及び符号４０Ｎは変更頻度判別用のマップを示す。図３Ａ及び図３Ｂに示す符号４１Ａ及び符号４１Ｂは更新矩形を示す。ここで、マップ４０Ａのメッシュ内に図示した数字は、更新矩形４１Ａが展開された時点におけるメッシュの変更回数を示す。また、マップ４０Ｂのメッシュ内に図示した数字は、更新矩形４１Ｂが展開された時点におけるメッシュの変更回数を示す。さらに、マップ４０Ｎのメッシュ内に図示した数字は、作業用の内部メモリに蓄積した更新矩形が全て展開された時点におけるメッシュの変更回数を示す。なお、図３Ａ〜図３Ｃにおいて数字が図示されていないメッシュは変更回数がゼロであるものとする。

図３Ａに示すように、更新矩形４１Ａがマップ４０Ａに展開された場合には、網掛け部分のメッシュが更新矩形４１Ａと重なり合う。このため、変更頻度判別部１４ｃは、網掛け部分のメッシュの更新回数を１つずつ加算する。この場合には、各メッシュの変更回数はゼロであるため、網掛け部分の変更回数は０から１に加算される。さらに、図３Ｂに示すように、更新矩形４１Ｂがマップ４０Ｂに展開された場合には、網掛け部分のメッシュが更新矩形４１Ｂと重なり合う。このため、変更頻度判別部１４ｃは、網掛け部分のメッシュの更新回数を１つずつ加算する。この場合には、各メッシュの変更回数は１であるため、網掛け部分の変更回数は１から２に加算される。このようにして全ての更新矩形がマップに展開された段階では、図３Ｃに示すマップ４０Ｎの結果が得られる。

そして、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形を全てマップに展開し終えた場合に、所定の期間における変更回数、すなわち変更頻度がしきい値を超えるメッシュを取得する。図３Ｃの例で言えば、閾値を「４」としたとき、網掛け部分のメッシュが取得されることになる。かかる閾値は、その値を高く設定するほどデスクトップ画面で動画が表示されている可能性が高い部分を後述の第２のエンコーダ１４ｇによりエンコードできる。なお、上記の「閾値」は、リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。

高頻度変更領域識別部１４ｄは、クライアント端末２０に表示されるデスクトップ画面のうち高頻度で変更される領域を高頻度変更領域として識別する処理部である。

これを説明すると、高頻度変更領域識別部１４ｄは、変更頻度判別部１４ｃによって変更回数がしきい値を超えるメッシュが取得された場合に、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する。一態様としては、高頻度変更領域識別部１４ｄは、メッシュ連結体に補間する補間領域を導出した上でメッシュ連結体に補間領域を足し合わせることによりメッシュ連結体を矩形に補正する。この補間領域の導出には、メッシュの連結体が最小の補間で矩形に整形される領域を導出するアルゴリズムが適用される。

図４は、メッシュ連結体の補正要領を説明するための図である。図４に示す符号５１は補正前のメッシュ連結体を示す。図４に示す符号５２は補間領域を示す。また、図４に示す符号５３は補正後の矩形を示す。図４に示すように、高頻度変更領域識別部１４ｄは、メッシュ連結体５１に補間領域５２を足し合わせることにより、メッシュ連結体５１を矩形５３に補正する。この段階では、後述の矩形の合成が完了しておらず、矩形５３が未だ高頻度変更領域と確定していないので、補正後の矩形を高頻度変更領域の候補と記載する場合がある。

その後、高頻度変更領域識別部１４ｄは、高頻度変更領域の候補が複数存在する場合には、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する。ここで言う高頻度変更領域の候補の距離とは、補正後の矩形の最短距離を指すものとする。一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域の候補を合成するにあたって各候補の間を埋める補間領域を導出した上で高頻度変更領域の候補に補間領域を足し合わせることにより、高頻度変更領域の候補同士を含む矩形に合成する。この補間領域の導出には、高頻度変更領域の候補の間が最小の補間で合成体に整形される領域を導出するアルゴリズムが適用される。

図５は、高頻度変更領域の候補の合成要領を説明するための説明図である。図５に示す符号６１Ａ及び符号６１Ｂは、高頻度変更領域の候補を指す。図５に示す符号６２は補間領域を指す。図５に示す符号６３は、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂの合成体を指す。図５に示すように、高頻度変更領域識別部１４ｄは、互いの距離が距離ｄ以内である高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂに補間領域６２を足し合わせることにより、高頻度変更領域の候補６１Ａ及び高頻度変更領域の候補６１Ｂを含む合成体６３へ合成する。そして、高頻度変更領域識別部１４ｄは、このようにして得た合成体を高頻度変更領域と識別する。

このように高頻度変更領域を識別すると、高頻度変更領域識別部１４ｄは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末２０へ送信する。これによって、クライアント端末２０で表示されるデスクトップ画面のビットマップ画像のうち高頻度変更領域に対応する部分をブランク表示させる。その後、高頻度変更領域識別部１４ｄは、作業用の内部メモリにマッピングされたメッシュの変更回数をクリアする。なお、高頻度変更領域識別部１４ｄは、高頻度変更領域の属性情報を作業用の内部メモリに登録する。

図６Ａ〜図６Ｃは、高頻度変更領域の属性情報の通知要領を説明するための図である。図６Ａに示す符号７０Ａは、フレームバッファ１３に描画されたデスクトップ画面の一例を示す。図６Ｂ〜図６Ｃに示す符号７０Ｂ及び符号７０Ｃは、変更頻度判別用のマップを示す。図６Ａに示す符号７１は、ブラウザ画面を指す。図６Ａに示す符号７２は、動画再生画面を指す。図６Ｂに示す符号７３は、マウスの移動軌跡を示す。図６Ｂに示す符号７４は、アプリによる動画再生領域を示す。

図６Ａに示すように、デスクトップ画面７０Ａには、ブラウザ画面７１及び動画再生画面７２が含まれる。このデスクトップ画面７０Ａから経時的な変化を追った場合には、図６Ｂに示すように、静止画であるブラウザ画面７１の更新矩形は検出されず、マウスの移動軌跡７３および動画再生領域７４に関する更新矩形が検出される。このうち、動画再生領域７４で変更回数がしきい値を超えるメッシュ、すなわち図示の網掛け部分が高頻度変更領域識別部１４ｄにより識別されたものとする。この場合には、高頻度変更領域識別部１４ｄは、図６Ｃに示す網掛け部分の高頻度変更領域の左上の頂点の座標（ｘ，ｙ）と、高頻度変更領域の幅ｗおよび高さｈとを高頻度変更領域の属性情報としてクライアント端末２０へ送信する。

なお、ここでは、高頻度変更領域の位置を特定する点として左上の頂点の座標を採用する場合を説明したが、他の頂点を採用することとしてもかまわない。また、高頻度変更領域の位置を特定することができる点であれば、頂点以外の任意の点、例えば重心などを採用できる。また、ここでは、画面上の左上を座標軸ＸＹの原点とする場合を説明したが、画面内および画面外の任意の点を原点とすることができる。

このように、デスクトップ画面の一部に高頻度変更領域が検出された場合には、デスクトップ画面のうち当該高頻度変更領域の動画化が開始される。この場合には、高頻度変更領域識別部１４ｄは、フレームバッファ１３に描画されたビットマップ画像のうち高頻度変更領域に対応する部分のビットマップ画像を後述の第２のエンコーダ１４ｇへ入力する。また、高頻度変更領域が検出された後には、動画化のＯＮまたはＯＦＦが頻繁に切り替わるのを抑制する観点から、所定の動画終了期間、例えば１秒間にわたって継続して高頻度変更領域が検出されなくなるまで、高頻度変更領域の動画化が継続される。この場合には、高頻度変更領域と識別されなかった場合でも、前回に識別された高頻度変更領域が動画化される。一方、高頻度変更領域が検出されたとしても、動画圧縮時における動画の符号化データの圧縮率の平均値Ｍｒが静止画圧縮時における静止画の符号化データの圧縮率の平均値Ｓｒよりも悪化した場合には、後述の中止制御部１４ｋによって動画化が中止される。なお、高頻度変更領域に含まれない更新矩形については、動画化が開始される前と同様に、静止画圧縮方式で圧縮される。すなわち、フレームバッファ１３に描画されたビットマップ画像のうち高頻度変更領域に含まれない更新矩形の画像が後述の第１のエンコーダ１４ｅへ入力される。

第１のエンコーダ１４ｅは、画面生成部１４ｂによって入力される更新矩形の画像を静止画の圧縮方式でエンコードする処理部である。一態様としては、第１のエンコーダ１４ｅは、各更新矩形の画像をＧＩＦ（Graphic Interchange Format）やＰＮＧ（Portable Network Graphics）などで圧縮することによって静止画の符号化データへエンコードする。なお、ここでは、静止画の圧縮方式としてＧＩＦとＰＮＧを例示したが、他の方式を適用することもできる。これらの圧縮方式は、ＣＡＤ（Computer-Aided Design）で、物体をワイヤーフレームで描画した画像や物体の平面を同じ色で塗りつぶした画像を扱う場合や、文書作成ソフトや表計算ソフトを利用する場合に、ＪＰＥＧで圧縮するよりも圧縮効率が高い傾向がある。

第１の送信部１４ｆは、第１のエンコーダ１４ｅによってエンコードされた更新矩形の符号化データをクライアント端末２０へ送信する処理部である。この更新矩形を送信する場合の通信プロトコルには、一例としてＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）プロトコルが採用される。あるいは、ＵＤＰ（User Datagram Protocol）も利用できる。

第２のエンコーダ１４ｇは、高頻度変更領域識別部１４ｄから入力される画像を動画の圧縮方式でエンコードする処理部である。一態様としては、第２のエンコーダ１４ｇは、高頻度変更領域の画像をＭＰＥＧで圧縮することによって動画の符号化データへエンコードする。なお、ここでは、動画の圧縮方式としてＭＰＥＧを例示したが、Ｍｏｔｉｏｎ−ＪＰＥＧなどの他の方式を適用することもできる。

第２の送信部１４ｈは、第２のエンコーダ１４ｇによってエンコードされた動画の符号化データをクライアント端末２０へ送信する処理部である。この高頻度変更領域のエンコード画像を送信する場合の通信プロトコルには、一例として、ＲＴＰ（Real-time Transport Protocol）を採用できる。

ここで、一般的には、動画の圧縮符号化を行った符号化データの方が静止画の圧縮符号化を行った符号化データよりもサイズを小さくできるが、かかる関係が必ずしも成立するとは限らない。例えば、画面が単純な背景の線画である場合には、色の数が多い画像の圧縮に強い動画の圧縮方式であるＭＰＥＧを適用するよりも、線画向きの静止画の圧縮方式であるＰＮＧ等を適用した方が画面データのサイズが小さくできる場合もある。

図７Ａ〜図７Ｄは、オブジェクトが回転操作された場合の画面の遷移例を示す図である。これら図７Ａ〜図７Ｄの例では、ＣＡＤなどの設計・製図ソフトの実行中に製品または製品を構成する部品などのオブジェクトが回転操作された場合を想定している。このうち、図７Ａ及び図７Ｂは、オブジェクトがポリゴン等の陰影によって描画されたシェーディングモデルを指し、一方、図７Ｃ及び図７Ｄは、オブジェクトが線形状によって描画されたワイヤーフレームモデルを指す。なお、図７Ａ及び図７Ｃの例では、オブジェクトの回転開始から回転終了まで静止画の符号化データがクライアント端末２０へ送信された場合を示す。また、図７Ｂ及び図７Ｄの例では、オブジェクトの回転途中から動画化が開始されて動画の符号化データがクライアント端末２０へ送信された場合を示す。

また、図８Ａ〜図８Ｄは、オブジェクトが回転操作された場合におけるデータ伝送量と時間の関係の一例を示すグラフである。これら図８Ａ〜図８Ｄのグラフの縦軸は、サーバ装置１０及びクライアント端末２０間のデータの伝送量を指し、また、グラフの横軸は、時間を指す。なお、図８Ａのグラフは、図７Ａに示す画面の遷移に対応し、図８Ｂのグラフは、図７Ｂに示す画面の遷移に対応し、図８Ｃのグラフは、図７Ｃに示す画面の遷移に対応し、また、図８Ｄのグラフは、図７Ｄに示す画面の遷移に対応するものとする。

図７Ａに示すように、ＣＡＤソフトによって展開されたＣＡＤウィンドウ２１０上でシェーディングによって黒背景に描画されたオブジェクトの回転操作が開始され、ＣＡＤウィンドウ２１１内の向きまでオブジェクトが回転操作されたとする。この図７Ａの例では、オブジェクトの回転開始から回転終了までＰＮＧによって静止画圧縮された符号化データがクライアント端末２０へ送信される。よって、オブジェクトの回転開始から回転終了まで画質の劣化は発生しない。この場合には、図８Ａに示すように、２Ｍｂｐｓを超える量のデータがオブジェクトの回転開始から回転終了まで伝送されることになる。

一方、図７Ｂに示すように、ＣＡＤウィンドウ２２０上でシェーディングによって黒背景に描画されたオブジェクトの回転操作が開始され、ＣＡＤウィンドウ２２１内の向きまでオブジェクトが回転操作されたとする。この図７Ｂの例では、回転途中の段階でＭＰＥＧによってシェーディングモデルのオブジェクトが動画圧縮された符号化データがクライアント端末２０へ送信される。このため、回転途中からは、動画の符号化データが送信される結果、ＣＡＤウィンドウ２２１内のオブジェクトの画像はＣＡＤウィンドウ２２０における画像よりも画質が若干劣化する。その反面で、色数が多いシェーディングによってレンダリングされたオブジェクトの場合には、ＭＰＥＧによって効果的に動画圧縮される。このため、図８Ｂに示すように、回転途中からは、図８Ａに示した静止画の符号化データの伝送量よりも大幅にデータ伝送量を削減できる。このように、一般的には、動画の圧縮符号化を行った符号化データの方が静止画の圧縮符号化を行った符号化データよりもサイズを小さくできる。

また、図７Ｃに示すように、ＣＡＤソフトによって展開されたＣＡＤウィンドウ２３０上でワイヤーフレームによって黒背景に描画されたオブジェクトの回転操作が開始され、ＣＡＤウィンドウ２３１内の向きまでオブジェクトが回転操作されたとする。この図７Ｃの例では、オブジェクトの回転開始から回転終了までＰＮＧによって静止画圧縮された符号化データがクライアント端末２０へ送信される。よって、オブジェクトの回転開始から回転終了まで画質の劣化は発生しない。さらに、色数が少ないワイヤーフレームによってレンダリングされたオブジェクトの場合には、線画向きの静止画圧縮方式であるＰＮＧ等を用いると、ＪＰＥＧ等の静止画圧縮方式に比べて効果的に静止画圧縮される。すなわち、図８Ｃに示すように、オブジェクトの回転開始から回転終了まで１Ｍｂｐｓ未満のデータ量に抑えて伝送されることになる。

一方、図７Ｄに示すように、ＣＡＤウィンドウ２４０上でワイヤーフレームによって黒背景に描画されたオブジェクトの回転操作が開始され、ＣＡＤウィンドウ２４１内の向きまでオブジェクトが回転操作されたとする。この図７Ｄの例では、回転途中の段階でＭＰＥＧによってワイヤーフレームモデルのオブジェクトが動画圧縮された符号化データがクライアント端末２０へ送信される。このため、回転途中からは、動画の符号化データが送信される結果、ＣＡＤウィンドウ２４１内のオブジェクトの画像はＣＡＤウィンドウ２４０における画像よりも画質が若干劣化する。さらに、色数が少ないワイヤーフレームによってレンダリングされたオブジェクトの場合には、画像を構成する色の周波数成分のうち高周波成分を除去することによって高い圧縮率を得るＭＰＥＧにとって不向きな内容であるとも言える。このため、図８Ｄに示すように、高頻度変更領域の画像にＭＰＥＧを適用したとしても効果的に動画圧縮することができず、図８Ｃに示した静止画の符号化データの伝送量よりもデータ伝送量が多くなってしまう場合がある。

これらのことから、本実施例では、ＭＰＥＧにとって不向きな内容の画像が動画圧縮されている場合に、後述の中止制御部１４ｋによって動画化を中止させ、第１のエンコーダ１４ｅによってＰＮＧで圧縮されるようにする。

算出部１４ｊは、第２のエンコーダ１４ｇによる動画圧縮、すなわち動画化を中止するか否かの判定に用いられる各種のパラメータ、例えば静止画の圧縮率や動画の圧縮率を算出する処理部である。

一態様としては、算出部１４ｊは、第１のエンコーダ１４ｅによって更新矩形の画像が静止画の符号化データへエンコードされた場合に、当該更新矩形に関する静止画の圧縮率の平均値Ｓｒを算出する。かかる圧縮率の平均値Ｓｒは、現フレームの更新矩形の圧縮率と、現フレームよりも前に算出されていた所定数のフレームで当該更新矩形に対応する位置にあった更新矩形の圧縮率とを平均化した値である。なお、圧縮率の平均値Ｓｒは、画面生成部１４ｂによって入力される更新矩形ごとに算出される。

これを説明すると、まず、算出部１４ｊは、第１のエンコーダ１４ｅによってエンコードされた静止画の符号化データのデータ量を画面生成部１４ｂによって生成された更新矩形の画像のデータ量で除算することによって現フレームの圧縮率を算出する。その後、算出部１４ｊは、先のようにして算出した現フレームの更新矩形の圧縮率をフレームの識別情報、更新矩形の識別情報、位置及び大きさに対応付けて図示しない作業用の内部メモリに格納する。その上で、算出部１４ｊは、現フレームの圧縮率と、現フレームよりも前に算出されていた所定数のフレーム、例えば過去の２フレームの圧縮率とを平均することによって当該更新矩形に関する静止画の圧縮率の平均値Ｓｒを算出する。このとき、算出部１４ｊは、作業用の内部メモリに記憶された過去２フレームの更新矩形のうち現フレームの更新矩形の位置と重複する更新矩形の圧縮率を平均化に用いる。なお、現フレームの更新矩形の位置と重複する更新矩形が複数存在する場合には、面積が最大の更新矩形が平均化の対象とされる。

なお、ここでは、圧縮後の画像のデータ量を圧縮前の画像のデータ量で除算することによって圧縮率を算出する場合を例示したが、圧縮率の算出方法はこれに限定されない。例えば、算出部１４ｊは、圧縮前および圧縮後の画像のデータ量の差分を圧縮前の画像のデータ量で除算することによって圧縮率を算出することとしてもかまわない。また、ここでは、現フレームの圧縮率と過去数フレームの圧縮率とを相加平均することによって圧縮率の平均値Ｓｒを算出する場合を例示したが、平均値の算出方法はこれに限定されない。例えば、算出部１４ｊは、現フレームに近づくほど重み付けを大きくして現フレームの圧縮率と過去数フレームの圧縮率とを加重平均によって圧縮率の平均値Ｓｒを算出することもできる。

他の一態様としては、算出部１４ｊは、第２のエンコーダ１４ｇによって高頻度変更領域の画像が動画の符号化データへエンコードされた場合に、当該高頻度変更領域に関する動画の圧縮率の平均値Ｍｒを算出する。

ここで、算出部１４ｊは、上記の動画の圧縮率の平均値Ｍｒを算出するのに先立って高頻度変更領域の画像に含まれる色の数を計数する。その上で、算出部１４ｊは、高頻度変更領域の色の数が所定の閾値、例えば６４色以下であるか否かを判定する。このように高頻度変更領域の色の数を閾値判定するのは、高頻度変更領域の画像がＭＰＥＧの不向きなタイプの画像であるか、言い換えればＰＮＧ等の線画向きの静止画の圧縮方式が得意な画像であるかを判別するためである。なお、上記の閾値には、画像の内容が単純な背景の線画である可能性が高い値、例えば６４色を用いることができる。

このとき、高頻度変更領域の色の数が閾値を超える場合には、高頻度変更領域の画像の色数が単純背景の線画の色数よりも多いと言えるので、ＭＰＥＧに適しているタイプの画像、言い換えれば線画向きの静止画の圧縮方式が得意な画像ではないと判別できる。この場合には、高頻度変更領域の画像の動画圧縮を中止する必要はないので、動画圧縮の中止を判定するために用いる動画の圧縮率の平均値Ｍｒは算出されない。したがって、中止制御部１４ｋによる静止画の圧縮率の平均値Ｓｒと動画の圧縮率の平均値Ｍｒとの比較、動画圧縮の中止制御も実行されない。

一方、高頻度変更領域の色の数が閾値以下である場合には、高頻度変更領域の画像の色数が単純背景の線画の色数と同等であると言えるので、ＭＰＥＧの不向きなタイプの画像、つまり線画向きの静止画の圧縮方式が得意な画像である可能性があると判別できる。

この場合には、算出部１４ｊは、動画の圧縮率の平均値Ｍｒの算出を実行するフェイズに遷る。上記の圧縮率の平均値Ｍｒは、現フレームの高頻度変更領域の圧縮率と、現フレームよりも前に算出されていた所定数のフレームにおける高頻度変更領域の圧縮率とを平均化した値である。なお、圧縮率の平均値Ｍｒは、高頻度変更領域識別部１４ｄによって入力される高頻度変更領域ごとに算出される。

これを説明すると、算出部１４ｊは、第２のエンコーダ１４ｇによってエンコードされた動画の符号化データのデータ量を高頻度変更領域識別部１４ｄによって識別された高頻度変更領域の画像のデータ量で除算することによって現フレームの圧縮率を算出する。その後、算出部１４ｊは、先のようにして算出した現フレームの高頻度変更領域の圧縮率をフレームの識別情報、高頻度変更領域の識別情報、位置及び大きさに対応付けて図示しない作業用の内部メモリに格納する。その上で、算出部１４ｊは、現フレームの圧縮率と、現フレームよりも前に算出されていた所定数のフレーム、例えば過去の２フレームの圧縮率とを平均することによって当該高頻度変更領域に関する動画の圧縮率の平均値Ｍｒを算出する。このとき、算出部１４ｊは、作業用の内部メモリに記憶された過去２フレームの高頻度変更領域の圧縮率のうちＩピクチャ（Intra Picture）の圧縮率は用いず、Ｐピクチャ（Predictive Picture）の圧縮率だけを平均化に用いる。

このように、Ｐピクチャだけを圧縮率の平均化に用いることとしたのは、ＭＰＥＧによる動画圧縮の圧縮性能がオリジナルの画像に近いＩピクチャよりも顕著に現れるからである。それゆえ、圧縮率の平均化の対象をＰピクチャだけに絞ることによってＩピクチャを含めて平均化を行う場合よりも短いフレーム数で動画圧縮の中止の要否を後述の中止制御部１４ｋに判定させることができる。さらに、Ｉピクチャが動画圧縮された直後は、Ｐピクチャの圧縮性能が安定しにくいので、Ｉピクチャから数フレームとばしたＰピクチャの圧縮率を平均化の対象とすることもできる。なお、ＭＰＥＧのＧＯＰ（Group Of Pictures）がＩピクチャ、Ｐピクチャ及びＢピクチャ（Bidirectionally Picture）によって構成される場合には、Ｂピクチャの圧縮率も平均化に用いることとしてもかまわない。

中止制御部１４ｋは、第２のエンコーダ１４ｇによる動画圧縮を中止させる処理部である。一態様としては、中止制御部１４ｋは、高頻度変更領域の動画の圧縮率Ｍｒと、動画圧縮が開始される以前のフレームで高頻度変更領域に対応する位置に検出されていた更新矩形の静止画の圧縮率Ｓｒとの比較結果に基づいて、第２のエンコーダ１４ｇによる動画圧縮を中止させる。

これを説明すると、中止制御部１４ｋは、算出部１４ｊによって動画の圧縮率の平均値Ｍｒが算出された場合に、当該動画の圧縮率の平均値Ｍｒが動画圧縮の中止判定に使用可能であるか否かを判定する。すなわち、中止制御部１４ｋは、動画の圧縮率の平均値Ｍｒが規定のフレーム数、本例では３フレームにおける高頻度変更領域の圧縮率から算出されたものであるか否かを判定する。このとき、動画の圧縮率の平均値Ｍｒが規定数未満のフレームから算出されたものである場合には、規定のフレーム数の圧縮率が出揃うまで動画圧縮の中止判定を延期する。

一方、中止制御部１４ｋは、動画の圧縮率の平均値Ｍｒが動画圧縮の中止判定に使用可能である場合に、静止画の圧縮率の平均値Ｓｒが動画の圧縮率の平均値Ｍｒに所定の係数αが乗算された乗算値「Ｍｒ＊α」よりも小さいか否かを判定する。これによって、中止制御部１４ｋは、動画圧縮を中止して静止画圧縮に戻すか否かを判定する。なお、上記の係数αには、動画の圧縮率の平均値Ｍｒに乗算して静止画の圧縮率の平均値Ｓｒと比較することによって動画圧縮を中止して静止画圧縮に戻す価値があると推定できる値が設定される。すなわち、動画の圧縮率の平均値及び静止画の圧縮率の平均値に大差がない場合、偶然に悪化したサンプルを動画圧縮の中止判定に使用してしまう可能性が高まる。よって、上記の係数αには、一例として、動画の圧縮率の平均値Ｍｒが静止画の圧縮率の平均値Ｓｒの２倍程度まで悪化するのを許容する値を設定するのが好ましい。

ここで、静止画の圧縮率の平均値Ｓｒが乗算値「Ｍｒ＊α」よりも小さい場合には、動画圧縮を中止して静止画圧縮に戻す価値があると判別できる。よって、中止制御部１４ｋは、図示しない作業用の内部メモリに記憶された動画化中止フラグをＯＮに設定する。一方、静止画の圧縮率の平均値Ｓｒが乗算値「Ｍｒ＊α」以上である場合には、ＭＰＥＧによる動画圧縮に一定の効果があると判別できる。よって、この場合には、動画化中止フラグはＯＮに設定されない。なお、上記の「動画化中止フラグ」は、動画化を中止するか否かを示すフラグを指す。例えば、動画化中止フラグがＯＮである場合には、高頻度変更領域が識別されたとしても動画圧縮させずに更新矩形の画像を静止画圧縮させ、また、動画化中止フラグがＯＦＦである場合には、高頻度変更領域の画像の動画圧縮は中止されない。

上書き制御部１４ｍは、動画圧縮が終了した場合に、当該動画圧縮が実行されていた間に動画の符号化データが送信された高頻度変更領域を上書きさせる上書き画像を静止画圧縮させた上でクライアント端末２０へ送信させる処理部である。

一態様としては、上書き制御部１４ｍは、動画化中止フラグがＯＮに設定されてから上書き待機時間、例えば５秒間を経過した場合、すなわち動画化中止された場合に静止画による上書き処理を起動する。また、上書き制御部１４ｍは、高頻度変更領域が識別されなくなってから動画終了期間を経過し、かつ上書き待機時間を経過した場合、すなわち動画化が終了した場合にも、静止画による上書き処理を起動する。

これを説明すると、上書き制御部１４ｍは、第２のエンコーダ１４ｇによって動画圧縮が実行されていた間に第２の送信部１４ｈによって動画の符号化データが送信された高頻度変更領域のうち動画圧縮の中止後または終了後に更新矩形の画像が未送信である領域を上書き領域として抽出する。このとき、上書き制御部１４ｍは、上書き領域が存在する場合に、当該上書き領域の画像を第１のエンコーダ１４ｅに静止画の符号化データへエンコードさせた上で第１の送信部１４ｆに当該上書き画像の符号化データをクライアント端末２０へ送信させる。なお、かかる上書き領域の画像の送信は、画面生成部１４ｂによって更新矩形が生成されるか否かとは無関係に独立して実行される。

これによって、動画化によって静止画よりも画質が劣化していたクライアント端末２０のデスクトップ画面を静止画によって上書きさせることができる。このため、画質の劣化が認識されにくい動画化中には、粗いデスクトップ画面を表示させつつ、動画化が終了して画質の劣化が認識されやすくなった段階で画質の劣化を抑えたデスクトップ画面を表示させることができる。

さらに、高頻度変更領域であった領域の中でも更新矩形の画像が未送信である領域だけを上書き領域としてクライアント端末２０へ送信するので、高頻度変更領域全体を上書き領域とする場合よりもデータ伝送量を低減できる。

なお、ＯＳ実行制御部１１ａ、アプリ実行制御部１１ｂ、グラフィックドライバ１２、リモート画面制御部１４には、各種の集積回路や電子回路を採用できる。また、リモート画面制御部１４に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）が挙げられる。また、電子回路としては、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などが挙げられる。

［具体例］
次に、図９及び図１０を用いて、クライアント端末２０によって表示される画面遷移の具体例について説明する。図９は、画面の遷移の具体例を示す図である。また、図１０は、図９に示した画面の遷移におけるデータ伝送量と時間の関係の一例を示すグラフである。図１０に示すグラフの縦軸は、サーバ装置１０及びクライアント端末２０間のデータの伝送量を指し、また、グラフの横軸は、時間を指す。なお、図９の例では、ＣＡＤソフトによって展開されたＣＡＤウィンドウ上でシェーディングによって黒背景に描画されたオブジェクトの回転操作がなされた場合を想定する。

図９に示すように、ＣＡＤウィンドウ３００上でワイヤーフレームによって黒背景に描画されたオブジェクトの回転操作が開始される。このとき、オブジェクトを含む周辺領域の変更頻度が高くなり、高頻度変更領域と識別されたとする。この結果、以降はＭＰＥＧによって高頻度変更領域の画像が第２のエンコーダ１４ｇによって動画の符号化データへエンコードされる。ところが、色数が少ないワイヤーフレームによってレンダリングされたオブジェクトの場合には、図１０に示すように、高頻度変更領域の画像にＭＰＥＧを適用したとしても効果的に動画圧縮することができず、静止画の符号化データの伝送量よりもデータ伝送量が多くなってしまう。

そして、オブジェクトがＣＡＤウィンドウ３１０に示す向きまで回転された段階で、図１０に示すように、規定数のフレームからＰピクチャだけを用いて算出された動画の圧縮率の平均値Ｍｒ（＝１２％）が得られる。このとき、図１０に示すように、動画化が開始される前の静止画の圧縮率の平均値Ｓｒが５％であるとしたとき、静止画の圧縮率の平均値Ｓｒ「５％」が動画の圧縮率の平均値Ｍｒに係数α（＝１／２）を乗算した乗算値Ｍｒ＊α「１２％÷２＝６％」よりも小さくなる。このため、動画化中止フラグがＯＮに設定され、以降は、高頻度変更領域の画像の動画圧縮が中止され、更新矩形の画像が静止画圧縮されて送信される。この結果、ワイヤーフレームによってレンダリングされたオブジェクトの一部または全部を含む更新矩形の画像が線画向きの静止画圧縮方式であるＰＮＧによって効果的に静止画圧縮される。

その後、オブジェクトがＣＡＤウィンドウ３２０に示す向きまで回転された段階で、ユーザによって操作がなされない無操作状態となる。このとき、クライアント端末２０に表示されているＣＡＤウィンドウ３２０には、動画化が中止されてから未だ更新矩形の画像を受信していない領域３２０ａ及び領域３２０ｂが残っている。そして、動画化中止フラグがＯＮに設定されてから上書き待機時間である５秒後を経過した段階で、更新矩形の画像が未送信である領域３２０ａ及び領域３２０ｂの画像が静止画圧縮された上でクライアント端末２０へ送信される。これによって、動画の符号化データによる表示が残っていないＣＡＤウィンドウ３３０が表示される。

このように、高頻度変更領域が一度は動画化されたとしても、動画の圧縮率の平均値Ｍｒが静止画の圧縮率の平均値Ｓｒよりも悪化している場合には、動画圧縮を中止して静止画圧縮に戻される。このため、図１０に示すように、ＭＰＥＧによる動画圧縮が不向きな画像には、ＭＰＥＧによる動画圧縮を中止して線画向きの静止画圧縮方式であるＰＮＧを用いて効果的に静止画圧縮する結果、データ伝送量の増大を抑制できる。また、動画化が中止された場合には、更新矩形の画像が送信されずに動画の符号化データが表示されていた上書き領域３２０ａ及び３２０ｂが静止画によって上書きされる。かかる静止画による上書きによって、画質の劣化が認識されやすくなった段階で画質の劣化を抑えたデスクトップ画面を表示させることができる。

［クライアント端末の構成］
次に、本実施例に係るクライアント端末の機能的構成について説明する。図１に示すように、クライアント端末２０は、入力部２１と、表示部２２と、クライアント側のリモート画面制御部２３とを有する。なお、図１の例では、図１に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば音声出力部などの機能を有するものとする。

入力部２１は、各種の情報、例えば後述のクライアント側リモート画面制御部２３に対する指示入力を受け付ける入力デバイスであり、一例としては、キーボードやマウスなどを適用できる。なお、後述の表示部２２も、マウスと協働して、ポインティングデバイス機能を実現する。

表示部２２は、各種の情報、例えばサーバ装置１０から送信されたデスクトップ画面などを表示する表示デバイスであり、一例としては、モニタ、ディスプレイやタッチパネルなどを適用できる。

リモート画面制御部２３は、クライアント側のリモート画面制御用アプリを通じて、サーバ装置１０によるリモート画面制御サービスの提供を受ける処理部である。このリモート画面制御部２３は、図１に示すように、操作情報通知部２３ａと、第１の受信部２３ｂと、第１のデコーダ２３ｃと、第１の表示制御部２３ｄとを有する。さらに、リモート画面制御部２３は、第２の受信部２３ｅと、第２のデコーダ２３ｆと、第２の表示制御部２３ｇとを有する。

操作情報通知部２３ａは、入力部２１による操作情報をサーバ装置１０へ通知する処理部である。一態様としては、操作情報通知部２３ａは、マウスの左右のクリックを始め、ダブルクリックやドラッグ、マウスの移動操作を介して得られたマウスカーソルの移動量などを操作情報として通知する。他の一例としては、操作情報通知部２３ａは、マウスホイールの回転量、キーボードのうち押下されたキーの種別なども操作情報として通知する。

第１の受信部２３ｂは、サーバ装置１０の第１の送信部１４ｆにより送信された更新矩形の符号化データを受信する処理部である。また、第１の受信部２３ｂは、サーバ装置１０の高頻度変更領域識別部１４ｄによって送信された高頻度変更領域の属性情報も受信する。

第１のデコーダ２３ｃは、第１の受信部２３ｂによって受信された更新矩形の符号化データをデコードする処理部である。この第１のデコーダ２３ｃには、サーバ装置１０に搭載されるエンコード方式に適合するデコード方式のデコーダが搭載される。

第１の表示制御部２３ｄは、第１のデコーダ２３ｃによってデコードされた更新矩形の画像を表示部２２に表示させる処理部である。一態様としては、第１の表示制御部２３ｄは、第１の受信部２３ｂによって受信された更新矩形の属性情報に含まれる位置および大きさに対応する表示部２２の画面領域に更新矩形のビットマップ画像を表示させる。また、第１の表示制御部２３ｄは、第１の受信部２３ｂによって高頻度変更領域の属性情報が受信された場合には、次のような処理を行う。すなわち、第１の表示制御部２３ｄは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部２２の画面領域をビットマップ画像の表示対象外のブランク領域とする。

第２の受信部２３ｅは、サーバ装置１０の第２の送信部１４ｈにより送信された動画の符号化データを受信する処理部である。この第２の受信部２３ｅは、サーバ装置１０の高頻度変更領域識別部１４ｄによって送信された高頻度変更領域の属性情報も受信する。

第２のデコーダ２３ｆは、第２の受信部２３ｅによって受信された動画の符号化データをデコードする処理部である。この第２のデコーダ２３ｆには、サーバ装置１０に搭載されたエンコード方式に適合するデコード方式のデコーダが搭載される。

第２の表示制御部２３ｇは、第２の受信部２３ｅによって受信された高頻度変更領域の属性情報に基づき、第２のデコーダ２３ｆによってデコードされた高頻度変更領域の画像を表示部２２に表示させる処理部である。一態様としては、第２の表示制御部２３ｇは、高頻度変更領域の属性情報に含まれる高頻度変更領域の位置および大きさに対応する表示部２２の画面領域に高頻度変更領域の動画を再生させる。

なお、クライアント側のリモート画面制御部２３には、各種の集積回路や電子回路を採用できる。また、リモート画面制御部２３に含まれる機能部の一部を別の集積回路や電子回路とすることもできる。例えば、集積回路としては、ＡＳＩＣやＦＰＧＡが挙げられる。また、電子回路としては、ＣＰＵやＭＰＵなどが挙げられる。

［処理の流れ］
次に、本実施例に係るサーバ装置１０の処理の流れについて説明する。図１１〜図１２は、実施例１に係る画像送信処理の手順を示すフローチャートである。この画像送信処理は、サーバ装置１０によって実行される処理であり、フレームバッファ１３にビットマップデータが描画された場合に起動する。

図１１に示すように、画面生成部１４ｂは、前回のフレームから変更があった部分の画素をつなぎ合わせた上で矩形に整形した更新矩形の画像を生成する（ステップＳ１０１）。そして、画面生成部１４ｂは、先に生成した更新矩形の画像から更新矩形送信用のパケットを生成する（ステップＳ１０２）。

続いて、変更頻度判別部１４ｃは、画面生成部１４ｂにより生成された更新矩形を図示しない作業用の内部メモリへ蓄積する（ステップＳ１０３）。このとき、更新矩形の蓄積を開始してから所定の期間が経過していない場合（ステップＳ１０４否定）には、以降に続く高頻度変更領域の識別に関する処理をとばし、後述のステップＳ１１３へ移行する。

一方、更新矩形の蓄積を開始してから所定の期間が経過した場合（ステップＳ１０４肯定）には、変更頻度判別部１４ｃは、次のような処理を行う。すなわち、変更頻度判別部１４ｃは、作業用の内部メモリに蓄積した更新矩形の位置および大きさにしたがって更新矩形の画像を変更頻度判別用のマップに順次展開する（ステップＳ１０５）。そして、変更頻度判別部１４ｃは、変更頻度判別用のマップに含まれるメッシュのうち変更頻度がしきい値を超えるメッシュを取得する（ステップＳ１０６）。

その後、高頻度変更領域識別部１４ｄは、変更頻度判別部１４ｃにより変更頻度がしきい値を超えるメッシュが取得されたか否かを判定する（ステップＳ１０７）。このとき、変更頻度がしきい値を超えるメッシュが存在しない場合（ステップＳ１０７否定）には、高頻度変更領域がデスクトップ画面に存在しないので、以降に続く高頻度変更領域の識別に関する処理をとばし、ステップＳ１１２へ移行する。

一方、変更頻度がしきい値を超えるメッシュが存在する場合（ステップＳ１０７肯定）には、高頻度変更領域識別部１４ｄは、隣接するメッシュ同士を連結したメッシュ連結体を矩形に補正する（ステップＳ１０８）。

そして、補正後の矩形、すなわち高頻度変更領域の候補が複数存在する場合（ステップＳ１０９肯定）には、高頻度変更領域識別部１４ｄは、次のような処理を行う。すなわち、高頻度変更領域識別部１４ｄは、複数の高頻度変更領域の候補の距離が所定の値以下である高頻度変更領域の候補同士を含む矩形に合成する（ステップＳ１１０）。なお、高頻度変更領域の候補が複数存在しない場合（ステップＳ１０９否定）には、矩形の合成を行わずにステップＳ１１１へ移行する。

続いて、高頻度変更領域識別部１４ｄは、高頻度変更領域の位置および大きさを特定可能な属性情報をクライアント端末２０へ送信する（ステップＳ１１１）。そして、高頻度変更領域識別部１４ｄは、作業用の内部メモリにマッピングされたメッシュの変更回数をクリアする（ステップＳ１１２）。

その後、図１２に示すように、高頻度変更領域が識別された場合（ステップＳ１１３肯定）には、高頻度変更領域識別部１４ｄは、動画化中止フラグがＯＮに設定されているか否かを判定する（ステップＳ１１５）。

このとき、動画化中止フラグがＯＮに設定されていない場合（ステップＳ１１５否定）には、第２のエンコーダ１４ｇは、高頻度変更領域の画像を動画の符号化データにエンコードする（ステップＳ１１６）。

そして、算出部１４ｊは、高頻度変更領域の色の数が所定の閾値以下であるか否かを判定する（ステップＳ１１７）。このとき、高頻度変更領域の色の数が閾値を超える場合（ステップＳ１１７否定）には、高頻度変更領域の画像の色数が単純背景の線画の色数よりも多いと言える。このため、ＭＰＥＧの不向きなタイプの画像、言い換えれば線画向きの静止画の圧縮方式が得意な画像ではないと判別できる。この場合には、高頻度変更領域の画像の動画圧縮を中止する必要はないので、ステップＳ１１８〜ステップＳ１２１の処理をとばし、ステップＳ１２９の処理へ移行する。

一方、高頻度変更領域の色の数が閾値以下である場合（ステップＳ１１７肯定）には、高頻度変更領域の画像の色数が単純背景の線画の色数と同等であると言える。このため、ＭＰＥＧの不向きなタイプの画像、つまり線画向きの静止画の圧縮方式が得意な画像である可能性があると判別できる。この場合には、算出部１４ｊは、高頻度変更領域に関する動画の圧縮率の平均値Ｍｒを算出する（ステップＳ１１８）。

続いて、中止制御部１４ｋは、動画の圧縮率の平均値Ｍｒが規定のフレーム数における高頻度変更領域の圧縮率から算出されたものであるか否か、すなわち動画圧縮の中止判定に使用可能であるか否かを判定する（ステップＳ１１９）。

このとき、動画の圧縮率の平均値Ｍｒが動画圧縮の中止判定に使用可能である場合（ステップＳ１１９肯定）には、中止制御部１４ｋは、次のような判定をさらに実行する。すなわち、中止制御部１４ｋは、静止画の圧縮率の平均値Ｓｒが動画の圧縮率の平均値Ｍｒに係数αが乗算された乗算値「Ｍｒ＊α」よりも小さいか否かを判定する（ステップＳ１２０）。なお、動画の圧縮率の平均値Ｍｒが動画圧縮の中止判定に使用不可能である場合（ステップＳ１１９否定）には、規定のフレーム数の圧縮率が出揃うまで動画圧縮の中止判定を延期するために以降の処理をとばし、ステップＳ１２９へ移行する。

ここで、静止画の圧縮率の平均値Ｓｒが乗算値「Ｍｒ＊α」よりも小さい場合（ステップＳ１２０肯定）には、動画圧縮を中止して静止画圧縮に戻す価値があると判別できる。よって、中止制御部１４ｋは、図示しない作業用の内部メモリに記憶された動画化中止フラグをＯＮに設定する（ステップＳ１２１）。

一方、静止画の圧縮率の平均値Ｓｒが乗算値「Ｍｒ＊α」以上である場合（ステップＳ１２０否定）には、ＭＰＥＧによる動画圧縮に一定の効果があると判別できる。よって、この場合には、動画化中止フラグをＯＮに設定せずにステップＳ１２９へ移行する。

また、高頻度変更領域が識別されなかった場合（ステップＳ１１３否定）、高頻度変更領域識別部１４ｄは、上書き画像を送信して動画化が終了しているか否かを判定する（ステップＳ１２２）。なお、上書き画像を送信して動画化が終了している場合（ステップＳ１２２肯定）には、ステップＳ１２９の処理へ移行する。

そして、動画化が終了していない場合（ステップＳ１２２否定）には、高頻度変更領域識別部１４ｄは、高頻度変更領域が動画終了期間、例えば１秒間にわたって継続して識別されなくなったか否かを判定する（ステップＳ１２３）。なお、動画終了期間にわたって継続していない場合（ステップＳ１２３否定）には、動画化を継続するために、ステップＳ１１５へ移行する。

一方、高頻度変更領域が動画終了期間にわたって継続して識別されなかった場合（ステップＳ１２３肯定）には、上書き制御部１４ｍは、動画終了期間を経過してから上書き待機時間、例えば５秒間を経過したか否かを判定する（ステップＳ１２４）。

また、動画中止フラグがＯＮに設定されている場合（ステップＳ１１５肯定）には、上書き制御部１４ｍは、動画化中止フラグがＯＮに設定されてから上書き待機時間を経過したか否かを判定する（ステップＳ１２４）。

このとき、動画終了期間を経過してから上書き待機時間を経過するか、あるいは動画化中止フラグがＯＮに設定されてから上書き待機時間を経過した場合（ステップＳ１２４肯定）には、上書き制御部１４ｍは、次のような処理を実行する。すなわち、上書き制御部１４ｍは、動画圧縮が実行されていた間に動画の符号化データが送信された高頻度変更領域のうち動画圧縮の中止後または終了後に更新矩形の画像が未送信である領域を上書き領域として抽出する（ステップＳ１２５）。

そして、上書き領域が存在する場合（ステップＳ１２６肯定）に、上書き制御部１４ｍは、当該上書き領域の画像を第１のエンコーダ１４ｅに静止画の符号化データへエンコードさせる（ステップＳ１２７）。このとき、上書き制御部１４ｍは、動画化中止フラグをＯＦＦに設定する（ステップＳ１２８）。

また、動画終了期間を経過してから上書き待機時間を経過していないか、あるいは動画化中止フラグがＯＮに設定されてから上書き待機時間を経過していない場合（ステップＳ１２４否定）には、ステップＳ１２９へ移行する。

その後、更新矩形が存在する場合（ステップＳ１２９肯定）には、第１のエンコーダ１４ｅは、更新矩形の画像を静止画の符号化データへエンコードする（ステップＳ１３０）。そして、算出部１４ｊは、当該更新矩形に関する静止画の圧縮率の平均値Ｓｒを算出する（ステップＳ１３１）。

その後、第１の送信部１４ｆ及び第２の送信部１４ｈは、静止画及び／又は動画の符号化データをクライアント端末２０へ送信し（ステップＳ１３２）、処理を終了する。

［実施例１の効果］
上述してきたように、本実施例に係るサーバ装置１０は、デスクトップ画面の伝送方式を静止画から動画に切り換えた場合に静止画の圧縮率の平均値Ｓｒ及び動画の圧縮率の平均値Ｍｒを比較する。その上で、本実施例に係るサーバ装置１０は、動画の圧縮率の平均値Ｍｒが低い場合に画面の伝送方式を動画から静止画に戻す。このため、本実施例に係るサーバ装置１０では、一度は動画化されたとしても、動画の圧縮率の平均値Ｍｒが静止画の圧縮率の平均値Ｓｒよりも悪化している場合には、動画圧縮を中止して静止画圧縮に戻される。このため、本実施例に係るサーバ装置１０では、動画圧縮が不向きな画像には、動画圧縮を中止して線画向きの静止画の圧縮方式を用いて効果的に静止画圧縮できる。したがって、本実施例に係るサーバ装置１０は、データ伝送量の増大を抑制できる。

さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

［動画化の再開］
例えば、上記の実施例１では、動画化が一度中止された場合にそのまま上書き処理を実行することとしたが、開示の装置はこれに限定されない。例えば、開示の装置は、動画化が一度中止されたとしてもその後の静止画の圧縮率の平均値Ｓｒが所定の悪化傾向にある場合には、動画化中止フラグをＯＦＦに設定することによって高頻度変更領域の画像の動画圧縮を再開することもできる。このとき、動画化中止フラグのＯＮ及びＯＦＦの頻繁な切替えを防止するために、静止画の圧縮率の平均値Ｓｒが先に算出されていた動画の圧縮率の平均値Ｍｒの２倍以上になった場合に、高頻度変更領域の画像の動画圧縮を再開するのが好ましい。これによって、一時的に動画の圧縮率が低下した場合であっても、高頻度変更領域の動画圧縮を再開できる。

［マップクリアの延長］
例えば、上記の実施例１では、高頻度変更領域識別部１４ｄが更新矩形を蓄積させる周期に合わせて変更頻度判別用のマップをクリアする場合を説明したが、変更頻度判別用のマップをクリアする契機はこれに限定されない。

一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域として識別した領域において変更頻度がしきい値を超えなくなった後も所定の期間にわたって継続して高頻度変更領域と識別することもできる。

図１３Ａ及び図１３Ｂは、マップクリアの延長要領を説明するための図である。図１３Ａの例では、高頻度変更領域が最初に識別された時点の変更頻度判別用のマップ８０Ａと、その時点の高頻度変更領域の識別結果８１Ａとを図示している。また、図１３Ｂの例では、高頻度変更領域が最初に識別されてから所定の期間内である特定の時点の変更頻度判別用のマップ８０Ｂと、その時点の高頻度変更領域の識別結果８１Ａとを図示している。

図１３Ａに示すように、マップ８０Ａで変更回数がしきい値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果８１Ａが得られた場合には、以降に変更回数が閾値を超えるメッシュ連結体が取得されなくとも識別結果８１Ａを所定の期間引き継ぐ。すなわち、図１３Ｂに示すように、マップ８０Ｂで変更回数が閾値を超えるメッシュ連結体が取得されずとも、最初に高頻度変更領域の識別結果８１Ａを識別してから所定の期間内であれば高頻度変更領域の識別結果８１Ａを引き継ぐ。なお、上記の「閾値」は、サーバ側リモート画面制御用アプリの開発者が段階的に設定した値をエンドユーザに選択させたり、また、エンドユーザが値を直接設定することができる。

これによって、実際に動画が再生される領域において間欠的に動きがなくなった場合でも、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズが安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。

［高頻度変更領域の縮小の抑制］
他の一例としては、高頻度変更領域識別部１４ｄは、高頻度変更領域として識別した領域が以前に高頻度変更領域と識別した領域よりも縮小した場合に、次のような処理を行う。すなわち、高頻度変更領域識別部１４ｄは、当該縮小した度合いが所定の閾値以下であるならば、前回の識別時に高頻度変更領域と識別した領域を今回の識別結果として引き継ぐ。

図１４Ａ及び図１４Ｂは、高頻度変更領域の縮小に関する抑制要領を説明するための図である。図１４Ａの例では、時点Ｔ１の変更頻度判別用のマップ９０Ａと高頻度変更領域の識別結果９１Ａとを図示している。また、図１４Ｂの例では、時点Ｔ２の変更頻度判別用のマップ９０Ｂと高頻度変更領域の識別結果９１Ａとを図示している。なお、上記の時点Ｔ１および時点Ｔ２はＴ１＜Ｔ２であるものとする。

図１４Ａに示すように、マップ９０Ａで変更回数がしきい値を超えるメッシュ連結体が取得されて高頻度変更領域の識別結果９１Ａが得られた場合には、時点Ｔ１以降に変更回数が閾値を超えるメッシュ連結体が縮小されても直ちに高頻度変更領域を縮小しない。すなわち、図１４Ｂに示すように、変更回数が閾値を超えるメッシュ連結体が斜線の部分について縮小したとしてもその面積が所定の閾値、例えば半分以下であるならば、高頻度変更領域の識別結果９１Ａを引き継ぐ。

これによって、実際に動画が再生される領域において一部の動きが間欠的になったとしても、高頻度変更領域を断続的に識別することがなくなる結果、高頻度変更領域で画像のコマ落ちが断続的に発生するのを防止できる。さらに、高頻度変更領域の識別結果を引き継ぐことにより高頻度変更領域のサイズが安定するので、エンコード時のパラメータを初期化する頻度を低減できる結果、エンコーダにかかる負荷を低減することも可能になる。

［上書き領域］
上記の実施例１では、動画化中に高頻度変更領域であった領域のうち更新矩形の画像が未送信である領域を上書き領域とする場合を例示したが、開示の装置はこれに限定されない。例えば、開示の装置は、デスクトップ画面全体を上書き領域とすることもできるし、また、高頻度変更領域を上書き領域とすることもできる。

［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、サーバ装置１０の第１の送信部１４ｆ及び第２の送信部１４ｈが実行する画像の送信処理を１つの送信部に統合することとしてもよい。また、クライアント端末２０の第１の受信部２３ｂ及び第２の受信部２３ｅが実行する画像の受信処理を１つの画像受信部に統合することとしてもかまわない。さらに、クライアント端末２０の第１の表示制御部２３ｄ及び第２の表示制御部２３ｇが実行する表示制御処理を１つの表示制御部に統合することとしてもよい。

［画像送信プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１５を用いて、上記の実施例と同様の機能を有する画像送信プログラムを実行するコンピュータの一例について説明する。

図１５は、実施例１及び実施例２に係る画像送信プログラムを実行するコンピュータの一例について説明するための図である。図１５に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０と有する。これら１１０〜１８０の各部はバス１４０を介して接続される。

ＨＤＤ１７０には、図１５に示すように、上記の実施例１で示したサーバ側のリモート画面制御部１４と同様の機能を発揮する画像送信プログラム１７０ａが予め記憶される。この画像送信プログラム１７０ａについては、図１に示した各々のリモート画面制御部１４の各構成要素と同様、適宜統合又は分離しても良い。すなわち、ＨＤＤ１７０に格納される各データは、常に全てのデータがＨＤＤ１７０に格納される必要はなく、処理に必要なデータのみがＨＤＤ１７０に格納されれば良い。

そして、ＣＰＵ１５０が、画像送信プログラム１７０ａをＨＤＤ１７０から読み出してＲＡＭ１８０に展開する。これによって、図１５に示すように、画像送信プログラム１７０ａは、画像送信プロセス１８０ａとして機能する。この画像送信プロセス１８０ａは、ＨＤＤ１７０から読み出した各種データを適宜ＲＡＭ１８０上の自身に割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、画像送信プロセス１８０ａは、図１に示した各々のリモート画面制御部１４にて実行される処理、例えば図１１〜図１２に示す処理を含む。また、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。

なお、上記の画像送信プログラム１７０ａについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。

１ シンクライアントシステム
１０ サーバ装置
１１ａ ＯＳ実行制御部
１１ｂ アプリ実行制御部
１２ グラフィックドライバ
１３ フレームバッファ
１４ リモート画面制御部
１４ａ 操作情報取得部
１４ｂ 画面生成部
１４ｃ 変更頻度判別部
１４ｄ 高頻度変更領域識別部
１４ｅ 第１のエンコーダ
１４ｆ 第１の送信部
１４ｇ 第２のエンコーダ
１４ｈ 第２の送信部
１４ｊ 算出部
１４ｋ 中止制御部
１４ｍ 上書き制御部
２０ クライアント端末
２１ 入力部
２２ 表示部
２３ リモート画面制御部
２３ａ 操作情報通知部
２３ｂ 第１の受信部
２３ｃ 第１のデコーダ
２３ｄ 第１の表示制御部
２３ｅ 第２の受信部
２３ｆ 第２のデコーダ
２３ｇ 第２の表示制御部

Claims (7)

1. ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリと、
   ソフトウェアの処理結果を前記画像メモリに描画する描画部と、
   前記画像のフレーム間で更新があった更新領域を検出する更新領域検出部と、
   前記更新領域の画像を静止画圧縮する第１の圧縮部と、
   前記更新領域の静止画圧縮データの圧縮率を算出する第１の算出部と、
   前記画像のフレーム間で変更の頻度が所定の頻度を超える高頻度の変更領域を識別する識別部と、
   前記高頻度の変更領域の画像を動画圧縮する第２の圧縮部と、
   前記高頻度の変更領域の動画圧縮データの圧縮率を算出する第２の算出部と、
   前記更新領域の静止画圧縮データと前記高頻度の変更領域の動画圧縮データとを前記端末装置へ送信する送信部と、
   前記高頻度の変更領域の動画圧縮データの圧縮率と、前記動画圧縮が開始される以前のフレームで前記高頻度の変更領域に対応する位置に検出されていた更新領域の静止画圧縮データの圧縮率との比較結果に基づいて、前記第２の圧縮部による動画圧縮を中止させる中止制御部と
   を有することを特徴とする情報処理装置。
2. 前記中止制御部によって動画圧縮が中止された場合に、当該動画圧縮が実行されていた間に前記動画圧縮データが送信された高頻度の変更領域のうち前記動画圧縮の中止後に前記更新領域の画像が未送信である上書き領域の画像を前記第１の圧縮部に静止画圧縮させた上で前記送信部に送信させる上書き制御部をさらに有することを特徴とする請求項１に記載の情報処理装置。
3. 前記第２の算出部は、前記高頻度の変更領域の画像に含まれる色の数が所定の閾値以下である場合に、前記動画圧縮データの圧縮率の算出を実行することを特徴とする請求項１または２に記載の情報処理装置。
4. 前記第１の算出部は、複数のフレーム間で前記更新領域の静止画圧縮データの圧縮率の平均値を算出し、
   前記第２の算出部は、複数のフレーム間で前記動画圧縮データのうちＩ（Intra）ピクチャ以外のピクチャの圧縮率の平均値を算出し、
   前記中止制御部は、前記Ｉピクチャ以外のピクチャの圧縮率の平均値が前記静止画圧縮データの圧縮率の平均値よりも悪化している場合に、前記第２の圧縮部による動画圧縮を中止させることを特徴とする請求項１、２または３に記載の情報処理装置。
5. 前記中止制御部による動画圧縮の中止後に前記更新領域の静止画圧縮データの圧縮率が悪化傾向にある場合に、前記高頻度の変更領域の動画圧縮を再開する再開部をさらに有することを特徴とする請求項１〜４のいずれか１つに記載の情報処理装置。
6. コンピュータが、
   ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリに対し、ソフトウェアの処理結果を前記画像メモリに描画し、
   前記画像のフレーム間で更新があった更新領域を検出し、
   前記更新領域の画像を静止画圧縮し、
   前記更新領域の静止画圧縮データの圧縮率を算出し、
   前記画像のフレーム間で変更の頻度が所定の頻度を超える高頻度の変更領域を識別し、
   前記高頻度の変更領域の画像を動画圧縮し、
   前記高頻度の変更領域の動画圧縮データの圧縮率を算出し、
   前記更新領域の静止画圧縮データと前記高頻度の変更領域の動画圧縮データとを前記端末装置へ送信し、
   前記高頻度の変更領域の動画圧縮データの圧縮率と、前記動画圧縮が開始される以前のフレームで前記高頻度の変更領域に対応する位置に検出されていた更新領域の静止画圧縮データの圧縮率との比較結果に基づいて、前記動画圧縮を中止させる処理
   を実行することを特徴とする画像送信方法。
7. コンピュータに、
   ネットワークを介して接続された端末装置に表示させる表示用の画像を記憶する画像メモリに対し、ソフトウェアの処理結果を前記画像メモリに描画し、
   前記画像のフレーム間で更新があった更新領域を検出し、
   前記更新領域の画像を静止画圧縮し、
   前記更新領域の静止画圧縮データの圧縮率を算出し、
   前記画像のフレーム間で変更の頻度が所定の頻度を超える高頻度の変更領域を識別し、
   前記高頻度の変更領域の画像を動画圧縮し、
   前記高頻度の変更領域の動画圧縮データの圧縮率を算出し、
   前記更新領域の静止画圧縮データと前記高頻度の変更領域の動画圧縮データとを前記端末装置へ送信し、
   前記高頻度の変更領域の動画圧縮データの圧縮率と、前記動画圧縮が開始される以前のフレームで前記高頻度の変更領域に対応する位置に検出されていた更新領域の静止画圧縮データの圧縮率との比較結果に基づいて、前記動画圧縮を中止させる処理
   を実行させることを特徴とする画像送信プログラム。

Images