JP2004304446A

JP2004304446A - 画像サーバおよびその制御方法

Info

Publication number: JP2004304446A
Application number: JP2003093881A
Authority: JP
Inventors: Takashi Miyamoto; 隆司宮本
Original assignee: Fuji Photo Film Co Ltd
Current assignee: Fujifilm Holdings Corp
Priority date: 2003-03-31
Filing date: 2003-03-31
Publication date: 2004-10-28
Anticipated expiration: 2023-03-31
Also published as: JP3905485B2

Abstract

【目的】画像サーバ２の処理効率を向上する。
【構成】クライアント・コンピュータ１から画像サーバ２に画像処理方法およびその画像処理の対象となる画像ファイル名が含まれているＵＲＬを表すデータが送信される。画像サーバ２においてＵＲＬデータにもとづいて画像処理が行われ，画像処理後の画像データが画像サーバ２からクライアント・コンピュータ１に送信される。画像処理後の画像データをキャッシュ画像データとしてキャッシュ画像データベース４に記憶する。同じ内容のＵＲＬデータが画像サーバ２に与えられたときには，キャッシュ画像データベース４に記憶されているキャッシュ画像を表すデータが画像サーバ２から，ＵＲＬデータを送信したクライアント・コンピュータに送信される。同一の画像処理を重複して行うことを未然に防止でき，処理効率が上がる。
【選択図】図１

Description

【０００１】
【技術分野】
この発明は，画像サーバおよびその制御方法ならびに画像サーバを制御するプログラムに関する。
【０００２】
【発明の背景】
所望のサイトのウェブ・ページをクライアント・コンピュータの表示装置の表示画面に表示させるときには，クライアント・コンピュータにインストールされているブラウザ・プログラムを起動させる。すると，表示画面上にブラウザが表示される。表示されたブラウザにＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）が書き込まれる。そのＵＲＬを表すデータが画像サーバに送信される。画像サーバにおいてＵＲＬデータが受信されると，そのＵＲＬによって特定されるウェブ・ページを表すデータが画像サーバからクライアント・コンピュータに送信される。クライアント・コンピュータのブラウザにウェブ・ページが表示される。ウェブ・ページに画像が含まれている場合には，その画像を表す画像データがキャッシュとしてクライアント・コンピュータに一時的に記憶される。キャッシュが多くなってしまった場合に，古いキャッシュを削除するものもある（例えば，特許文献１参照）。
【０００３】
【特許文献１】
特開２００２−２５９１９６号公報
【０００４】
所定の画像処理指令をＵＲＬに含ませることもできる。ＵＲＬに所定の画像処理指令が含まれていると，その画像処理指令にもとづく画像処理が画像サーバにおいて行われる。画像処理後の画像データが画像サーバからクライアント・コンピュータに送信され，画像処理後の画像が含まれているウェブ・ページがクライアント・コンピュータのブラウザに表示される。
【０００５】
ＵＲＬに画像処理指令が含まれている場合には，ＵＲＬを表すデータを受信する度にその画像処理が行われている。処理効率が悪い。
【０００６】
【発明の開示】
この発明は，画像処理の処理効率を向上することを目的とする。
【０００７】
この発明による画像サーバは，クライアント・コンピュータから送信された画像処理リクエストを受信する受信手段，上記受信手段によって受信された上記画像処理リクエストによって指定される画像データについて，上記画像処理リクエストによって指定される画像処理の後の画像を表すデータが画像データベースに記憶されているかどうかを判定する判定手段，上記判定手段によって画像処理後の画像データが上記画像データベースに記憶されていると判定されたことに応答して，その記憶されている画像データを上記クライアント・コンピュータに送信する第１の送信手段，上記判定手段によって画像処理後の画像データが上記画像データベースに記憶されていないと判定されたことに応答して，上記画像処理リクエストによって指定される画像を表す画像データについて，上記画像処理リクエストによって指定される画像処理を行う画像処理手段，上記画像処理手段によって画像処理が行われた画像データを上記画像リクエストに対応して上記画像データベースに記憶する記憶制御手段，および上記画像処理手段によって画像処理が行われた画像データを上記クライアント・コンピュータに送信する第２の送信手段を備えていることを特徴とする。
【０００８】
この発明は，上記画像サーバに適した制御方法も提供している。すなわち，この方法は，クライアント・コンピュータから送信された画像処理リクエストを受信し，受信した上記画像処理リクエストによって指定される画像データについて，上記画像処理リクエストによって指定される画像処理の後の画像を表すデータが画像データベースに記憶されているかどうかを判定し，画像処理後の画像データが上記画像データベースに記憶されていると判定されたことに応答して，その記憶されている画像データを上記クライアント・コンピュータに送信し，画像処理後の画像データが上記画像データベースに記憶されていないと判定されたことに応答して，上記画像処理リクエストによって指定される画像を表す画像データについて，上記画像処理リクエストによって指定される画像処理を行い，画像処理が行われた画像データを上記画像リクエストに対応して上記画像データベースに記憶し，画像処理が行われた画像データを上記クライアント・コンピュータに送信するものである。
【０００９】
また，この発明は，上記制御方法を実施するためのプログラムおよびそのプログラムを格納した記録媒体も提供している。
【００１０】
この発明によると，クライアント・コンピュータから画像サーバに画像処理リクエスト（ＵＲＬデータ）が送信される。この画像処理リクエストにより，画像処理の内容およびその画像処理を行うべき画像が指定される。
【００１１】
サーバにおいて，画像処理リクエストが受信されると，その画像リクエストによって指定される画像データについて，その画像処理リクエストによって指定される画像処理後の画像を表す画像データが画像データベースに記憶されているかどうかが判定される。画像処理後の画像データが画像データベースに記憶されていると，その記憶されている画像データが画像サーバからクライアント・コンピュータに送信される。画像処理後の画像データが画像データベースに記憶されていないと，画像処理リクエストによって指定される画像データについて，画像処理リクエストによって指定される画像処理が行われる。画像処理された画像データが画像サーバからクライアント・コンピュータに送信される。
【００１２】
画像処理リクエストに対応して，画像処理後の画像データが画像データベースに記憶されており，対応する画像処理リクエストがあった場合には，画像データベースに記憶されている画像処理後の画像データが画像サーバからクライアント・コンピュータに送信される。同じ画像処理リクエストが複数回あった場合に，同じ画像処理を重複して行ってしまうことを未然に防止できる。画像処理効率を向上させることができる。
【００１３】
画像処理の内容にもとづいて，上記記憶制御手段による記憶制御を停止する停止制御手段をさらに備えるようにしてもよい。
【００１４】
上記記憶制御手段は，たとえば，上記画像処理リクエストによって指定される画像データによって表される画像ごとに，上記画像処理手段における画像処理後の画像データを上記画像データベースに記憶するものである。
【００１５】
また，上記画像処理リクエストにもとづいて，ユニークＩＤを生成するユニークＩＤ生成手段をさらに備えるようにしてもよい。この場合，上記判定手段は，上記ユニークＩＤにもとづいて画像処理後の画像データが上記画像データベースに記憶されているかどうかを判定するものであり，上記記憶制御手段は，上記画像処理手段によって画像処理が行われた画像データを上記ユニークＩＤに対応して上記画像データベースに記憶するものとなろう。
【００１６】
上記画像処理リクエストは，複数の画像処理を行わせるものでもよい。この場合，上記記憶制御手段は，上記画像処理手段における複数の画像処理のうち途中まで画像処理された画像データを，上記画像リクエストに対応して上記画像データベースに記憶するものとなろう。
【００１７】
途中まで画像処理が終了しているので，その途中までの処理を省略できる。その後の処理は画像処理手段によって行われ，最終的に画像処理が終了した画像データが画像サーバからクライアント・コンピュータに送信されることとなる。
【００１８】
【実施例の説明】
図１は，この発明の実施例を示すもので，画像変換システムの概要を示している。
【００１９】
画像変換システムは，インターネットを介して互いに通信可能なクライアント・コンピュータ（携帯電話などブラウザが表示できればよい）１と画像サーバ２とから構成されている。
【００２０】
クライアント・コンピュータ１および画像サーバ２には，それぞれ，通信するための通信回路，ＣＰＵ，キーボード，表示装置，ＣＤ−ＲＯＭ（コンパクト・ディスク−リード・オンリ・メモリ）ドライバ，メモリ，ハードディスク・ドライバなどが内蔵されている。
【００２１】
画像サーバ２には，オリジナル画像データが格納されているオリジナル画像データベース３およびキャッシュ画像データが格納されているキャッシュ画像データベース４が接続されている。後述する画像通信プログラムおよび画像処理プログラムが格納されているＣＤ−ＲＯＭ５が画像サーバ２のＣＤ−ＲＯＭドライバに装填されると，ＣＤ−ＲＯＭ５に格納されているプログラムが画像サーバ２にインストールされ，後述する動作が行われる。
【００２２】
この実施例による画像変換システムにおいては，クライアント・コンピュータ１から画像サーバ２にＵＲＬを表すデータが送信される。このＵＲＬデータは，取得すべき画像の画像ファイル名およびその画像の処理内容が含まれているものである。ＵＲＬデータによって指定される画像について，ＵＲＬデータによって指定される画像処理が画像サーバ２において行われる。とくに，この実施例によると，画像処理後の画像を表す画像データ（画像ファイル）は，キャッシュ画像データとしてキャッシュ画像データベース４に格納される。キャッシュ画像データがキャッシュ画像データベース４に格納された後に，同じ内容のＵＲＬデータがクライアント・コンピュータ１から画像サーバ２に送信された場合には，再び画像処理を行うことなく，キャッシュ画像データベース４に格納されているキャッシュ画像データがクライアント・コンピュータ１に送信される。画像サーバ２の負荷が軽減される。
【００２３】
図２は，オリジナル画像データベース３のディレクトリ構造を示している。
【００２４】
ディレクトリ名”ＤｏｃＲｏｏｔ”のディレクトリ下の階層にディレクトリ名”ｅｘａｍｐｌｅ”のディレクトリが設けられており，このディレクトリ名”ｅｘａｍｐｌｅ”ディレクトリの下の階層にオリジナル画像のファイル（ファイル名００１．ｊｐｇ，００２．ｊｐｇ，００３．ｊｐｇなど）が格納されている。ディレクトリ名をたどることにより所望の画像ファイルを見つけることができる。
【００２５】
図３は，キャッシュ画像データベース４のディレクトリ構造を示している。
【００２６】
ディレクトリ名”ＣａｃｈｅＲｏｏｔ”のディレクトリ下の階層にディレクトリ名”ｅｘａｍｐｌｅ”のディレクトリが設けられており，このディレクトリ名”ｅｘａｍｐｌｅ”ディレクトリの下の階層にオリジナル画像のファイル名に対応した階層が設けられている。オリジナル画像のファイル名の階層のそれぞれファイル名の下の階層に，上述した画像処理済みのキャッシュ画像ファイル（キャッシュ画像データ）が格納されている。例えば，００１．ｊｐｇのファイル名の下の階層には，ユニークＩＤ（このユニークＩＤは，後述するようにＵＲＬから生成されるものである）ごとの階層が形成されている。ユニークＩＤ”ａｓｄｆ”のディレクトリ名をもつディレクトリの階層は，ＲＬスタンプ画像（後述するように，ＶＧＡ（ＶｉｄｅｏＧｒａｐｈｉｃＡｒｒａｙ）サイズの画像の右下に所定のロゴ・マークが合成された画像）のキャッシュ画像ファイルが格納されるものである。同様に，ユニークＩＤ”ｑｗｅｒ”のディレクトリ名をもつディレクトリの階層は，ＲＵスタンプ画像（ＶＧＡサイズの画像の右上に所定のロゴ・マークが合成された画像）のキャッシュ画像ファイルが格納され，ユニークＩＤ”ｚｘｃｖ”のディレクトリ名をもつディレクトリの階層は，ＬＵスタンプ画像（ＶＧＡサイズの画像の左上に所定のロゴ・マークが合成された画像）のキャッシュ画像ファイルが格納されるものである。また，ユニークＩＤ”ｓｔａｍｐ”のディレクトリ名をもつディレクトリの階層には，所定のロゴ・マークが合成されていないＶＧＡサイズの画像（画像合成処理が終了した画像ではなく，途中の処理まで行われた画像）を表す画像ファイルが格納されている。ＶＧＡサイズの画像を表す画像ファイルが格納されているので，ＶＧＡサイズの画像ファイルの生成処理を再び行うことを未然に防止できる。ＶＧＡサイズの画像ファイルを用いて，さらにロゴ・マークの合成などの処理を効率良くできる。
【００２７】
図４は，画像サーバ２の設定ファイルの内容の一例を示している。
【００２８】
第２行目の＜ｄｏｃｕｍｅｎｔｒｏｏｔ＞というタグは，オリジナル画像ファイルの格納場所（上述したＤｏｃＲｏｏｔ）を示すものである。
【００２９】
第３行目または第４行目に含まれる＜ｆｕｎｃｔｉｏｎ＞というタグは画像サーバ２の画像処理機能を指定するものである。第３行目から，クライアント・コンピュータ１から送信されたＵＲＬデータによって表されるＵＲＬに，”Ｆｕｎｃ＝Ｅｍｂｏｓｓ”とあると，”ｅｍｂｏｓｓ．ｐｌｕｇｉｎ”という画像処理プログラムが起動させられ，エンボス画像処理が行われることがわかる。同様に，第４行目から，クライアント・コンピュータ１から送信されたＵＲＬデータによって表されるＵＲＬに，”Ｆｕｎｃ＝Ｓｔａｍｐ”とあると，”Ｓｔａｍｐ．ｐｌｕｇｉｎ”という画像処理プログラムが起動させられ，エンボス画像処理が行われることがわかる。
【００３０】
図５および図６は，画像サーバ２の処理手順を示すフローチャートである。画像サーバ２は，画像通信プログラムと画像処理プログラムとにもとづいて動作するので，それぞれのフローチャートが示されている。図７は，オリジナル画像（画像ファイル名００１．ｊｐｇ）の一例を，図８は，ＶＧＡ画像の一例を，図９は，ＲＬスタンプ画像の一例を示している。以下，図９に示すＲＬスタンプ画像を画像サーバ２において生成し，生成されたＲＬスタンプ画像を表すデータが画像サーバ２からクライアント・コンピュータ１に送信されるものとする。
【００３１】
まず，画像通信プログラムおよびすべての画像処理プログラムが初期化される（図５ステップ１１，６）。
【００３２】
クライアント・コンピュータ１のユーザによってブラウザ・プログラムが立ち上げられ，ＵＲＬが入力される。すると，その入力されたＵＲＬを表すデータがクライアント・コンピュータ１から画像サーバ２に送信される。たとえば，クライアント・コンピュータ１において，

という第１のＵＲＬが入力され，その第１のＵＲＬデータがクライアント・コンピュータ１から画像サーバ２に送信される。このＵＲＬは，００１．ｊｐｇの画像ファイル名をもつ画像の右下に所定のｃｏｍｐａｎｙ．ｇｉｆ３３のロゴを合成する画像処理を示している。また，オリジナル画像３０からＶＧＡサイズの画像３１となるようにサイズ調整されるものとする。
【００３３】
クライアント・コンピュータ１から送信されたＵＲＬデータが画像サーバ２において受信されると（図５ステップ１２でＹＥＳ），そのＵＲＬデータによって表されるＵＲＬの中に”Ｆｕｎｃ＝ＸＸＸ”という機能を指定する引数が含まれているかどうかが確認される（図５ステップ１３）。
【００３４】
引数が含まれていなければ（図５ステップ１３でＮＯ），ＵＲＬによって指定される画像ファイルがオリジナル画像データベース３から見つけられる。見つけられた画像ファイルが画像サーバ２からクライアント・コンピュータ１に送信される（図５ステップ１４）。例えば，上述したＵＲＬデータが画像サーバ２において受信されると，画像ファイル名００１．ｊｐｇをもつ画像ファイルがオリジナル画像データベース２から見つけられ，クライアント・コンピュータ１に送信される。クライアント・コンピュータ１の表示装置の表示画面上にファイル名００１．ｊｐｇをもつ画像ファイルによって表されるオリジナル画像（図６に示す画像）３０が表示される。
【００３５】
引数が含まれていると（図５ステップ１３でＹＥＳ），ＵＲＬからユニークなＩＤが生成される（図５ステップ１５）。ユニークなＩＤは，第１のＵＲＬを機能ごとに分類して（機能名：Ｓｔａｍｐ，オリジナル画像ファイル名：／ｅｘａｍｐｌｅ／００１．ｊｐｇ，第１の引数：ｎａｍｅ＝ｃｏｍｐａｎｙ．ｇｉｆ，第２の引数：ｐｏｓｉｔｉｏｎ＝ＲＬ），アルファベット順に並べてスラッシュを除いたもの（Ｓｔａｍｐｅｘａｍｐｌｅ００１．ｊｐｇｎａｍｅ＝ｃｏｍｐａｎｙ．ｇｉｆｐｏｓｉｔｉｏｎ＝ＲＬ）でもよい。また，ＵＲＬを機能ごとに分類したものについてＭＤ（ｍｅｓｓａｇｅＤｉｇｅｓｔａｌｇｏｒｉｔｈｍ）５などのハッシュ関数を用いてユニークＩＤを生成してもよい。
【００３６】
生成されたユニークＩＤに対応したキャッシュ画像がキャッシュ画像データベース４から見つけられる（図５ステップ１６）。生成されたユニークＩＤに対応するキャッシュ画像ファイルがキャッシュ画像データベース４に格納されていると（図５ステップ１７でＹＥＳ），その見つけられたキャッシュ画像ファイルが画像サーバ２からクライアント・コンピュータ１に送信される（図５ステップ１８）。たとえば，上述したＵＲＬデータがクライアント・コンピュータ１から画像サーバ２に送信された場合において，画像処理後のキャッシュ画像を表す画像ファイルがキャッシュ画像データベース４に格納されている場合には，そのキャッシュ画像ファイル（例えば，図９に示すＲＬスタンプ画像３２を表す画像ファイル）が画像サーバ２からクライアント・コンピュータ１に送信される。
【００３７】
キャッシュ画像データベース４にキャッシュ画像が格納されていなければ（図５ステップ１７でＮＯ），ＵＲＬによって指定されるオリジナル画像ファイルがオリジナル画像データベース３から見つけられ，ＵＲＬに含まれる”Ｆｕｎｃ＝ＸＸＸ”という引数に対応する画像処理プログラムに与えられる（図６ステップ１９）。
【００３８】
画像処理プログラムにしたがって，見つけられたオリジナル画像ファイルが画像処理される（図６ステップ７）。まず，オリジナル画像３０が図８に示すＶＧＡサイズの画像３１となるようにサイズ調整処理が行われる。画像サーバ２のメモリに記憶されている所定のｃｏｍｐａｎｙ．ｇｉｆのロゴ３３（図９参照）を表すデータが読み取られ，図９に示すようにＶＧＡ画像３１の右下にそのロゴ３３が合成されてＲＬスタンプ画像３２が生成されて画像処理が終了する。上述したように，ＶＧＡサイズにサイズ調整処理された画像ファイルをキャッシュ画像データベース４に格納するようにしてもよいのはいうまでもない。
【００３９】
生成されたＲＬスタンプ画像３２がキャッシュ画像データベース４の中に，図３に示すディレクトリ構成にしたがって格納される（図６ステップ２０）。また，生成されＲＬスタンプ画像３２を表すデータが画像サーバ２からクライアント・コンピュータ１に送信される（図６ステップ２１）。クライアント・コンピュータ１の表示装置の表示画面上に，図９に示すＲＬスタンプ画像３２が表示されるようになる。
【００４０】
上述した実施例においては，キャッシュ画像データベース４は，図３に示すようにディレクトリ構造によってキャッシュ画像が格納されているが，ユニークＩＤと一対一対応のテーブルに対応するキャッシュ画像ファイルが格納されるようにしてもよい。
【００４１】
第１のＵＲＬデータによって上述した図９に示すキャッシュ画像が生成された後に，

（所定のロゴ・マークを右上に合成する点を除いて第１のＵＲＬデータと同じである）という第２のＵＲＬデータが画像サーバ２において受信されると，対応するＶＧＡサイズのキャッシュ画像（中間キャッシュ画像）３１を表すすべての画像ファイル（図３の”Ｓｔａｍｐ”というディレクトリ名のディレクトリ下の画像ファイル）がキャッシュ画像データベース４から見つけられる。見つけられた中間キャッシュ画像ファイルとＵＲＬ引数とにもとづいて画像処理が行われる。オリジナル画像ファイルを用いて画像処理が行われずに，途中まで生成された中間キャッシュ画像ファイルを用いて画像処理が行われるので，画像サーバ２の負荷も軽減される。
【００４２】
図１０から図１２は，他の実施例を示すものである。
【００４３】
図１０は，画像サーバ２の設定ファイルの内容を示している。
【００４４】
図１０に示す設定ファイルは，図４に示す設定ファイルと比べて第７行目が追加されている。第７行目においては，”Ｔｉｍｅ”という引数がＵＲＬに含まれていた場合には，Ｔｉｍｅプログラムを起動させるが，キャッシュ画像の生成は停止することを示している（ｏｐｔｉｏｎ＝”ｃａｃｈｅ−ｏｆｆ”）。
【００４５】
図１１および図１２は，画像サーバ２の画像通信プログラムの処理手順の一部を示すフローチャートである。これらの図において図５および図６に示す処理と同一の処理については同一の符号を付して説明を省略する。これらの処理は，画像サーバ２においてキャッシュ画像の生成を停止できるものである。
【００４６】
キャッシュ画像の生成停止は，上述したように画像サーバ２の設定ファイルに設定されているものでもよいし，画像処理プログラムから画像通信プログラムにキャッシュ画像の生成停止指令を与えるものでもよい。画像処理プログラムから画像通信プログラムにキャッシュ画像の生成停止指令を与える場合には，画像処理プログラムの初期化の時に生成停止指令を画像通信プログラムに与えるものでもよいし，画像処理プログラムにおいて画像処理が行われた時に生成停止指令を画像通信プログラムに与えるものでもよい。
【００４７】
図１１を参照して，上述したように，画像通信プログラムが初期化されると（ステップ１１），設定ファイルにキャッシュ画像生成停止指令を示す”ｃｈａｃｈｅ−ｏｆｆ”が記録されているかどうかが確認される（ステップ４１）。記録されていると（ステップ４１でＹＥＳ），対応する画像処理についてキャッシュ・オフが記憶される（ステップ４２）。
【００４８】
また，上述のように画像処理プログラムも初期化が行われる。画像処理プログラムの初期化において，その画像処理プログラムの動作が行われる場合には，キャッシュ画像生成停止指令を示す”ｃｈａｃｈｅ−ｏｆｆ”が記録されていると，その画像処理プログラムから画像通信プログラムにキャッシュ・オフ指令が与えられる。キャッシュ・オフ指令が与えられると（ステップ４３でＹＥＳ），対応する画像処理についてキャッシュ・オフが記憶される（ステップ４４）。
【００４９】
図１２を参照して，クライアント・コンピュータ１から送信されたＵＲＬデータによって表されるＵＲＬに”Ｆｕｎｃ＝ＸＸＸ”という引数が含まれており，対応する画像処理プログラムにオリジナル画像が与えられると（ステップ１９）。その画像処理プログラムに従って，上述のように画像処理が行われる。画像処理後の画像ファイルとともに，キャッシュ・オフ・ステータスが画像処理プログラムから画像通信プログラムに与えられると（ステップ５１でＹＥＳ）。キャッシュ・オフが記憶される（ステップ５２）。
【００５０】
キャッシュ・オフが記憶されていると，キャッシュ画像を表す画像ファイルをキャッシュ画像データベース４に格納する処理はスキップされる（ステップ２０）。たとえば，上述したようにＵＲＬにおいて”Ｆｕｎｃ＝Ｔｉｍｅ”と指定することにより画像の右下に現在の時刻を合成するような画像処理プログラムを考える。このような場合において画像処理後のキャッシュ画像がキャッシュ画像データベース４に記憶され，記憶されているキャッシュ画像を表す画像ファイルが画像サーバ２からクライアント・コンピュータ１に送信されてしまうと，正確な時刻が合成されていない画像がクライアント・コンピュータ１の表示装置の表示画面に表示されてしまう。このような場合には，キャッシュ・オフとすることにより，不正確な時刻が画像に合成されてしまうことを未然に防止できる。
【００５１】
上述の実施例において，画像サーバ２の管理者がキャッシュ画像を保存するかどうかを判定できる場合には，図１０に示す設定ファイルを用いて画像サーバ２を設定すればよい。画像サーバ２の管理者がキャッシュ画像を保存するかどうかを判定できない場合には，画像処理プログラムの起動時に画像処理プログラムから画像通信プログラムにキャッシュ・オフを与えることができるようにすればよい。
【００５２】
さらに，画像処理プログラムにおける画像処理ごとに，キャッシュ・オフを画像処理プログラムから画像通信プログラムに与えるようにしてもよい。たとえば，監視カメラ・システムにおいて監視場所を撮影し，００１．ｊｐｇというファイル名をもつ撮影によって得られた画像が数秒おきに更新されるものとする。撮影されている画像は，クライアント・コンピュータ１の表示装置の表示画面上に表示され，クライアント・コンピュータ１のユーザはその撮影画像を見ることができる。この場合は，キャッシュ・オフとしなければ，過去に撮影された画像が表示され続けることとなり監視カメラの役割をしなくなってしまう。逆に，常にキャッシュ・オフであると，侵入者がいた場合に撮影された画像も更新されてしまい，侵入者を表す画像が消去されてしまうことがある。このような場合においては，監視を行う画像処理プログラムが「侵入者はいない」と判断すると，画像処理時においてキャッシュ・オフのステータスが画像処理プログラムから画像通信プログラムに与えられる。画像処理プログラムが「侵入者がいる」と判断すると，画像処理時においてキャッシュ・オフのステータスを画像処理プログラムから画像通信プログラムに与えずに侵入者が映ったキャッシュ画像がキャッシュ画像データベース４に記憶されることとなる。
【００５３】
上述した監視カメラ・システムに利用されるときの画像サーバ２の設定ファイルは，図１３のようになろう。第５行目が，与えられるＵＲＬに”Ｆｕｎｃ＝ＤｅｔｅｃｔＩｎｔｒｕｄｅｒ”が含まれていることにより，監視カメラ・システムにおける画像処理プログラムを起動することを示している。クライアント・コンピュータ１から画像サーバ２に与えられるＵＲＬデータによって表されるＵＲＬは，たとえば，

となろう。
【図面の簡単な説明】
【図１】画像変換システムの概要を示している。
【図２】オリジナル画像データベースのディレクトリ構造を示している。
【図３】キャッシュ画像データベースのディレクトリ構造を示している。
【図４】画像サーバの設定ファイルの内容を示している。
【図５】画像サーバの処理手順の一部を示すフローチャートである。
【図６】画像サーバの処理手順の一部を示すフローチャートである。
【図７】オリジナル画像の一例である。
【図８】ＶＧＡ画像の一例である。
【図９】ＲＬスタンプ画像の一例である。
【図１０】画像サーバの設定ファイルの内容を示している。
【図１１】画像サーバの処理手順の一例を示すフローチャートである。
【図１２】画像サーバの処理手順の一例を示すフローチャートである。
【図１３】画像サーバの設定ファイルの内容を示している。
【符号の説明】
１クライアント・コンピュータ
２画像サーバ
３オリジナル画像データベース
４キャッシュ画像データベース（画像データベース）
５ＣＤ−ＲＯＭ
３０オリジナル画像
３１ＶＧＡ画像（途中まで画像処理された画像）
３２ＲＬスタンプ画像（画像処理後の画像）

Claims

クライアント・コンピュータから送信された画像処理リクエストを受信する受信手段，
上記受信手段によって受信された上記画像処理リクエストによって指定される画像データについて，上記画像処理リクエストによって指定される画像処理の後の画像を表すデータが画像データベースに記憶されているかどうかを判定する判定手段，
上記判定手段によって画像処理後の画像データが上記画像データベースに記憶されていると判定されたことに応答して，その記憶されている画像データを上記クライアント・コンピュータに送信する第１の送信手段，
上記判定手段によって画像処理後の画像データが上記画像データベースに記憶されていないと判定されたことに応答して，上記画像処理リクエストによって指定される画像を表す画像データについて，上記画像処理リクエストによって指定される画像処理を行う画像処理手段，
上記画像処理手段によって画像処理が行われた画像データを上記画像リクエストに対応して上記画像データベースに記憶する記憶制御手段，および
上記画像処理手段によって画像処理が行われた画像データを上記クライアント・コンピュータに送信する第２の送信手段，
を備えた画像サーバ。
画像処理内容にもとづいて，上記記憶制御手段による記憶制御を停止する停止制御手段をさらに備えた請求項１に記載の画像サーバ。
上記記憶制御手段が，上記画像処理リクエストによって指定される画像データによって表される画像ごとに，上記画像処理手段における画像処理後の画像データを上記画像データベースに記憶するものである，請求項１に記載の画像サーバ。
上記画像処理リクエストにもとづいて，ユニークＩＤを生成するユニークＩＤ生成手段をさらに備え，
上記判定手段は，上記ユニークＩＤにもとづいて画像処理後の画像データが上記画像データベースに記憶されているかどうかを判定するものであり，
上記記憶制御手段は，上記画像処理手段によって画像処理が行われた画像データを上記ユニークＩＤに対応して上記画像データベースに記憶するものである，
請求項１に記載の画像サーバ。
上記画像処理リクエストは，複数の画像処理を行わせるものであり，
上記記憶制御手段は，上記画像処理手段における複数の画像処理のうち途中まで画像処理された画像データを，上記画像リクエストに対応して上記画像データベースに記憶するものである，
請求項１に記載の画像サーバ。
クライアント・コンピュータから送信された画像処理リクエストを受信し，
受信した上記画像処理リクエストによって指定される画像データについて，上記画像処理リクエストによって指定される画像処理の後の画像を表すデータが画像データベースに記憶されているかどうかを判定し，
画像処理後の画像データが上記画像データベースに記憶されていると判定されたことに応答して，その記憶されている画像データを上記クライアント・コンピュータに送信し，
画像処理後の画像データが上記画像データベースに記憶されていないと判定されたことに応答して，上記画像処理リクエストによって指定される画像を表す画像データについて，上記画像処理リクエストによって指定される画像処理を行い，
画像処理が行われた画像データを上記画像リクエストに対応して上記画像データベースに記憶し，
画像処理が行われた画像データを上記クライアント・コンピュータに送信する，
画像サーバの制御方法。
クライアント・コンピュータから送信された画像処理リクエストを受信させ，
受信した上記画像処理リクエストによって指定される画像データについて，上記画像処理リクエストによって指定される画像処理の後の画像を表すデータが画像データベースに記憶されているかどうかを判定させ，
画像処理後の画像データが上記画像データベースに記憶されていると判定されたことに応答して，その記憶されている画像データを上記クライアント・コンピュータに送信させ，
画像処理後の画像データが上記画像データベースに記憶されていないと判定されたことに応答して，上記画像処理リクエストによって指定される画像を表す画像データについて行われた画像処理後の画像データを上記画像リクエストに対応して上記画像データベースに記憶させ，
画像処理が行われた画像データを上記クライアント・コンピュータに送信させる，
画像サーバを制御するプログラム。
請求項７に記載のプログラムを格納した記録媒体。