JP4312210B2

JP4312210B2 - モバイルウェブブラウザに対応する画像拡大／縮小方法およびプログラム、ならびにそれを利用した使用者インターフェイスおよび画像送信方法

Info

Publication number: JP4312210B2
Application number: JP2006131941A
Authority: JP
Inventors: 鐘植金; 泰慶李
Original assignee: ユーリテクノス株式会社
Priority date: 2006-05-10
Filing date: 2006-05-10
Publication date: 2009-08-12
Anticipated expiration: 2026-05-10
Also published as: JP2007304820A

Description

本発明は、モバイルウェブブラウザに対応する画像拡大／縮小方法およびプログラムに関し、さらにそれを利用した使用者インターフェイスおよび送信方法に関する。

一般的なモバイルウェブブラウザは、 WAP 2.0 （ Wireless Application Protocol 2.0 ）に基づく XHTML 規格に従って運用されている。これらのモバイルウェブブラウザは、PC環境において通常用いられているようなウェブブラウザに比べて、多くの部分で機能が制限されている。

ウェブブラウザでは、 IMAGE TAG を使って PNG 、 JPEG などを表現することができるが、これは単に画像（イメージ）が挿入される箇所と表示サイズを示しているに過ぎない。解像度の高い画像は容量が多いため、送信速度が遅いモバイルウェブブラウザでは送信待受時間が負担となり、メモリーが不足する場合には画像の表示ができない。また、画像を表示したとしても、それからさらに画像を移動・縮小・拡大するようなユーザーインターフェースを設けることはできない。

さらに、 800x600 ピクセル、もしくは 600x450 ピクセルなどの、PCでよく使われるサイズの画像は、現在の携帯電話の画面サイズが最大で 240x320 程度であるために、モバイルウェブブラウザではそのまま表示することはできない。このような大きなサイズの画像をモバイルウェブブラウザで表示させた場合には、画像の幅が240ピクセルよりも大きいと画像が崩れて表示されてしまう。これは、大きなサイズの画像を、ライン単位削除のような単純な方法で縮小しているためである。

一般的なWebページで使用されている画像は、例えば 1024x768 ピクセルのJPEG形式であれば、容量が約100KB以上となり、そのまま表示しようとすれば転送速度が遅い携帯電話においては大きな負担となってしまう。

上述したような従来技術に係る画像縮小／拡大方法においては、モバイルウェブブラウザにイメージを送るにあたって、一般的には、サイトに画像をアップロードするときに予め携帯電話の画面サイズに合わせて生成した画像を用意している。しかしながら、携帯電話の画面サイズの種類は、 96x89 、 116x122 、 120x117 、 120x130 、 222x261 、 128x128 、 132x144 、 144x144 、 160x180 、 176x220 、 240x320 （単位はいずれもピクセル）など、十一種類以上のモデルが既に存在している。このため、これらのすべてのサイズに対して、予め画像を何種類ものサイズで用意することにはコスト面での問題がある。

また、既存の携帯電話の中には gif 形式の画像を表示することができない機種があり、このときに必要な他形式への変換作業も考え合わせると、ひとつの元画像から、二十余個の画像を予め生成しておいてサーバーに保存しておく必要が生じてしまう。

また、上述したような画像の従来技術によるリサイズ・変換作業は、変換速度の短縮と、元画像の品質を保って（元画像を崩さずに）拡大／縮小をすることを両立することが難しい、という問題もあった。例えばショッピングサイトのような、コンテンツ内に多数の画像を有しており、且つユーザーからの多数のアクセスを受けるようなページの場合には、ユーザーの各環境に合わせた適切な画像を即座に用意することが困難であった。このため、ユーザーがアクセスをした直後に、目的とする画像をすぐに見ることができない（画像の拡大／縮小／変換処理終了まで待たされる）という問題が生じていた。

さらに、携帯電話に送られた縮小画像（サムネイル画像）の一部を拡大して閲覧したい場合、やはり上述したような容量と転送速度の問題から、スムースに閲覧することができないという問題もあった。

上述したような問題に鑑み、本発明では、複数のピクセルを含み、前記複数のピクセルのそれぞれが有するチャネルを表現するビット列を少なくともチャネルの数だけ含むように構成される画像のサイズの変換処理を行うために、前記画像を処理するための装置であって、
前記画像を格納する、記憶手段と、
前記記憶手段に格納された前記画像に含まれる前記チャネルを表現する前記ビット列のうちの少なくともいくつかについて、論理演算を含む演算を行う、シフト加算演算手段と、
前記シフト加算演算手段の算出結果に基づいて、前記画像のサイズの変換処理を行う、画像サイズ変換手段と
を含むことを特徴とする画像サイズ変換装置が提供される。

また、本発明では、上述のような画像サイズ変換装置を含んだサーバが行う画像配信システムであって、
携帯端末装置からのアクセス要求に対して、前記携帯端末装置の機種を判別する、携帯端末装置判定手段と、
変換画像送信手段と
を含み、判別した前記携帯端末装置の機種に対応して、前記サーバに含まれている前記画像サイズ変換装置が、前記画像のサイズを変換して、前記変換画像送信手段が前記サイズ変換した画像を前記携帯端末装置へと送信することを特徴とする、画像配信システムも提供される。

また、本発明では、複数のピクセルを含み、前記複数のピクセルのそれぞれが有するチャネルを表現するビット列を少なくともチャネルの数だけ含むように構成される画像のサイズの変換処理を行うための画像サイズ変換装置において、
前記画像を記憶手段に格納するステップと、
前記記憶手段に格納された前記画像に含まれる前記チャネルを表現する前記ビット列のうちの少なくともいくつかについて、論理演算を含む演算を行うステップと、
前記演算の結果に基づいて、前記画像のサイズの変換処理を行うステップと
を含むことを特徴とする画像サイズ変換方法も提供される。

さらに本発明では、複数のピクセルを含み、前記複数のピクセルのそれぞれが有するチャネルを表現するビット列を少なくともチャネルの数だけ含むように構成される画像のサイズの変換処理をコンピュータ上で行うための画像サイズ変換プログラムであって、
前記画像を記憶手段に格納するステップと、
前記記憶手段に格納された前記画像に含まれる前記チャネルを表現する前記ビット列のうちの少なくともいくつかについて、論理演算を含む演算を行うステップと、
前記演算の結果に基づいて、前記画像のサイズの変換処理を行うステップと
を実行することを含むことを特徴とする、画像サイズ変換プログラムも提供される。

さらに本発明では、上述した画像サイズ変換プログラムを実行するコンピュータを含んだサーバが行う画像配信システムであって、
携帯端末装置からのアクセス要求に対して、前記携帯端末装置の機種を判別する、携帯端末装置判定手段と、
変換画像送信手段と
を含み、判別した前記携帯端末装置の機種に対応して、前記サーバに含まれているコンピュータが前記画像サイズ変換プログラムを実行することによって前記画像のサイズを変換して、前記変換画像送信手段が前記サイズ変換した画像を前記携帯端末装置へと送信することを特徴とする画像配信システムも提供される。

本発明に係る画像サイズ変換装置、方法およびプログラムを用いることにより、従来よりも高速且つ元画像の品質の低下を最低限に抑えて画像のサイズの変換を行うことができる。

また、本発明に係る画像配信システムを用いることにより、各種携帯端末装置からのアクセスに応じて、携帯端末装置固有の画面の仕様に合わせて、元画像から高速且つ品質劣化の少ないサイズ変換画像を生成して配信することが可能になる。

さらに、本発明に係る画像配信システムを用いることによって携帯端末装置の各機種の画面サイズと転送速度などをデータベース化することができ、その情報を使ってモバイルウェブブラウザに送る画像のサイズと容量の最適化を行うことができる。

以下、本発明の実施形態を図面に基づいて詳細に説明するが、これは本発明を何ら限定するものではない。

［画像配信システムの概要］
図１は、本発明の或る実施形態に係る画像配信システム 100 の概要を示す図である。

この実施形態においては、画像配信システム 100 にはサーバ 110 、データベース格納手段 120 、画像サイズ変換装置 130 が含まれ、携帯端末装置 150 とネットワーク 140 を介して接続されている。

サーバ 110 は、例えば一般的なHTTPサーバもしくはFTPサーバとすることができ、また、サーバ 110 は通信手段 112 を含み、通信手段 112 を介してネットワーク 140 と接続する。なお、別の実施形態においては、サーバ 110 がデータベース格納手段 120 および画像サイズ変換装置 130 のうちの少なくとも一方を含んでいるように構成することもできる。

データベース格納手段 120 は、例えばUser-Agent情報と携帯端末装置の機種とを照合することができるようなデータを含むデータテーブルを有することができる。データベース格納手段 120 は独立したデータベースサーバであってもよいし、またはサーバ 110 に含まれるものであってもよい。データベース格納手段 120 は、キャッシュ手段（図示せず）をさらに含むことも可能であり、このキャッシュ手段はデータベース格納手段 120 の外部に存在して接続されるものであってもよい。あるいは、キャッシュ手段は記憶手段（図示せず）と兼用されるものであってもよい。キャッシュ手段は画像のDecoding/Re-encoding部分に係るサーバ 110 のCPU／メモリ負担を軽減するためのキャッシュを蓄積する。キャッシュには、接続要求を承けてサイズ変換処理された画像が含まれ、既接続機種からの二回目以降の接続に対して使用することが可能である。このようなキャッシュ手段を用いることにより、画像のヘッダーのみを抽出して処理することができ、画像のDecoding/Re-encoding処理に係る負荷を低減することができる。

画像サイズ変換装置 130 は、後述するような演算方法で画像のサイズを変換処理するための装置である。画像サイズ変換装置 130 は、画像の形式を変換するための画像形式変換手段（図示せず）をさらに含むことができ、画像サイズの変換のみならず形式の変換も行うことが可能である。

携帯端末装置 150 は、通信手段 154 およびユーザー操作手段 156 、さらに制御手段（図示せず）を有している。制御手段は、表示手段（図示せず）にモバイルウェブブラウザ 152 を表示するようにプログラムを実行することができる。携帯端末装置 150 のユーザーは、ユーザー操作手段 156 を操作してモバイルウェブブラウザ 152 を表示し、通信手段 154 およびネットワーク 140 を介して画像配信システム 100 と接続する。

図２は、画像配信システム 100 の動作の一例を示すフローチャートである。この例は、携帯端末装置 150 がネットワーク 140 を介してHTTPサーバ 110 と接続する場合を示している。

まず、携帯端末装置 150 から、画像配信システム 100 のHTTPサーバ 110 へ HTTP Request が送信される（ステップ S200 ）。通常、この接続要求情報にはUser-Agent情報という環境変数が含まれている。この環境変数にはサービス会社、携帯電話機種、JAVA（
登録商標）バージョンなどのような情報が含まれる。表１には、User-Agent情報の例を示した。

例えばHTTPサーバであるサーバ 110 が接続要求を受けると、画像配信システム 100 に含まれている携帯端末装置判定手段が、接続要求情報からUser-Agent情報の全体もしくは一部（例えばヘッダー値）を抽出する（ステップ S210 ）。携帯端末装置判定手段は、例えばサーバ 110 が含む制御手段によって実行されるCGIとすることができる。

携帯端末装置判定手段は、データベース格納手段 120 に含まれているデータテーブルを参照し、接続要求を行った携帯端末装置の機種を特定し（ステップ S220 ）、特定した機種の特性に対して最適な画像サイズを決定する（ステップ S230 ）。

携帯端末装置判定手段の分析結果を受けて、画像サイズ変換装置 130 は、携帯端末装置 150 によって閲覧要求された元画像に関して、最適な画像サイズへと変換処理を行い、サイズ変換した画像を記憶手段に格納する（ステップ S240 ）。必要であれば、この際にさらに元画像の形式の変換を行うこともできる。通信手段 112 が含む変換画像送信手段は、サイズ変換した画像を携帯端末装置 150 へと送信する（ステップ S250）。対象となる画像が複数ある場合には、上述した手順を任意に繰り返すことができる。

このようにして、携帯端末装置 150 は、接続要求した画像を含むコンテンツを受けることができる。
従来、携帯端末装置の画面よりも大きいサイズの画像を受信する場合、データの受信時間が長くなり、また縮小が粗いために画像がきれいに表示できなかったが、本発明の実施形態に係る画像配信システムによって、転送速度が遅い携帯端末装置であっても、即座に美しく縮小された画像（例えば、元画像が 1024x768 ピクセル、約100KBであったとすると、縮小して 160x120 ピクセル、約10KBとすることができる）を受信することが可能となる。

本発明の或る実施形態においては、Webサーバに画像の閲覧要求をする際に実質的にリアルタイムで拡大されたイメージを生成する方法が提供される。画像閲覧要求を受けて画像を転送するプログラムは、好ましくはC/C++で最適化されたCGIを利用するが、これに限定はされず、例えばJSP（Java（登録商標）Server Pages）もしくはPHPなどで構成してもよい。

［キャッシュを利用する手法］
本発明の或る実施形態においては、キャッシュ手段を用いて、サーバにかかる負担を軽減することができる。キャッシュ手段を用いる場合、例えば、(1) User-Agent 環境変数から携帯端末装置の機種を分析、 (2) 携帯端末装置について最適な画像サイズおよび容量を計算、 (3) イメージヘッダ抽出、 (4) 適正サイズ計算後、キャッシュファイルを検索し、キャッシュが存在する場合にはこれを即座に携帯端末装置へと送信、 (5) キャッシュが無い場合、閲覧要求を受けた画像を新たにdecoding、 (6) 画像を拡大する領域についてre-encoding、 (7) ステップ(5),(6)で作成した画像を携帯端末装置へと送信、という処理の流れを以って画像配信システムを構成することもできる。

［画像サイズ変換処理］
本発明の実施形態に係る画像サイズ変換装置の特徴について、以下にさらに詳述する。

モバイルウェブブラウザで携帯端末装置のスクリーンピクセルサイズよりも大きなサイズの画像を表示する場合には、画像を自動的に縮小して閲覧することになる。しかしながら、モバイルウェブブラウザの基本的なイメージ縮小方法は前述したように単純であり、横ピクセルもしくは縦ピクセルがスクリーンピクセルサイズよりも大きい場合、画像の細密な領域が壊れる場合がある。

従来技術に係る一般的な画像の拡大／縮小プロセスにおいては、もっとも単純な方法は最近傍法（Nearest Neighborhood method）である。この方法で画像を縮小する場合には、
ABABABABABABABABAB -> AAAAAAAAA
のように、或るピクセル A の近傍のピクセル B を削除する。この最近傍法は、簡単な方法であり且つ計算速度も高速であるため、一般に多用されている。しかしながら、最近傍法で拡大／縮小を行うと、元画像に較べて著しく品質が劣化するという問題があることが既知である。

現在一般的なモバイルウェブブラウザの基本的な機能においては、バイリニア補間法、もしくはバイキュービック補間法といった効率的な手法が充分に実行可能であるとは言い難い。そこで、画像の拡大／縮小処理を、ウェブサーバ側で効率的に代行処理し、送信する方法が考えられている。

サーバーで即時応答処理を行うためには、画像の拡大／縮小プロセスにおいては迅速なアルゴリズムが要求される。そのような迅速なアルゴリズムを使用すれは、一台のサーバで処理可能な同時使用者をより多くすることができ、費用削減の面でも役立つことになる。

図３は、画像サイズ変換装置で処理される元画像のサンプルである。これはPC上のWebブラウザで表示した例であり、サイズ 800x600 ピクセル、容量107KBである。なお、この例の画像は本来はカラー（256色）であるが、明細書の仕様上グレイスケールで示していることに留意されたい。以下、画像のサンプルについては特に断わらない限りは上記に準じる。

図４は、図３の元画像を、本発明の実施形態に係る画像サイズ変換装置を用いて、携帯端末装置用に縮小した例である。これはモバイルウェブブラウザで表示した例であり、サイズ 240x180 ピクセル、容量15KBである。

図５は、図３の元画像を、本発明の実施形態に係る画像サイズ変換装置を用いて、携帯端末装置用のインデックスイメージとして縮小した例であって、サイズ 96x76 ピクセル、容量3KBである。実施形態におけるこのインデックスイメージの用途については、後の節で述べる。

図６は、本発明の実施形態に係る画像サイズ変換装置に含まれるシフト加算演算手段の処理を説明するための模式図である。図中の "px for-loop cell_width" とは、一回のサイズ変換処理の対象とする領域（cell）のx軸方向（幅）のピクセルの数を意味し、また、 "py for-loop cell_height" はcellのy軸方向（高さ）のピクセルの数を意味する。具体的には、図６はx軸方向およびy軸方向をともに1/4に縮小する場合であるので、cellの幅と高さはともに4ピクセルとなっている。

従来の手法においては、個々のピクセルを逐一処理するため、二重のFor-Loopが必要となり、例えば二つのピクセルのため、全体を以下のような四重のFor-Loopで構成するしかなかった。このような構成は、処理速度において非常に問題がある。

For y loop x < width
For x loop y < height
For py loop py < cell_height
For px loop px < cell_width
Calculate Pixel

また、個々のピクセルのデータには色や透明度などを表現するためのチャネルが含まれており、例えばTrueColorを表現する画像のピクセルのデータには、 Red, Green, Blue のそれぞれのチャネルが含まれ、そのそれぞれが8ビットのデータ値を有している。画像拡大／縮小のような処理においては、チャネル別にデータを処理するため、上記のループがチャネルの数だけ反復されるので、実際の処理速度はさらに遅くなってしまう。

本発明の実施形態においては、上述したような最近傍法の欠点を解消する新規な画像拡大／縮小方法が提供される。
画像の拡大／縮小時に元画像の品質を劣化させないようするために、或るピクセル A と、その近傍のピクセル B との算術的な平均値をとる。例えば、簡単な場合を挙げると "(A+B) / 2" のようになる。図６のグレーの領域をピクセルの平均をとって処理する場合、 4x4 = 16個のピクセルを全て足した後に、その平均値をピクセルの個数で割って処理をする。

本発明のひとつの実施形態に係る平均値処理方法においては、対象とする二つのピクセルについて、二つのピクセルのそれぞれが有するチャネル（例えば、RGBの3チャネル）のデータを同時に平均演算する。ピクセルが有するチャネルがRGBデータのみの場合、32ビット型のInteger変数（例えばC/C++の場合にはint）にそれぞれ8ビットずつ割り当てることが可能である。本発明の実施形態に係る演算手法では、C/C++のプログラムで処理する場合、従来のような8ビットのchar型変数を用いる場合とは異なり、ひとつのピクセルをint型変数で扱い、RGBチャネルのすべてについて一度にまとめて処理することが可能となる。本発明の別の実施形態では、さらに多くのチャネルを有するピクセルについて同時に平均演算することもできる。本発明のなおも別の実施形態では、ピクセルが有するチャネルの一部についてのみ同時に平均演算することもできる。本発明のさらに別の実施形態では、さらに多くのピクセルについて同時に平均演算することもできることは当業者は容易に理解することができる。なお、int型変数は処理系によって記憶される値の範囲が異なることに留意されたい。好ましくは、本発明の実施形態は32ビット以上のCPUを有するコンピュータにおいて実施される。

一例として、 (0,0) のピクセルのデータをAとし、その近傍の点 (0,1) のピクセルデータをBとするとき、AとBとの平均をとって元画像から縮小を行う場合を考える。一般的なchar型変数を用いて処理すると、下記のように個別に処理されることになる。

Pr = (Ar + Br) / 2
Pg = (Ag + Bg) / 2
Pb = (Ab + Bb) / 2

ここで、Pr, Pg, Pb はそれぞれ、処理後のピクセルのRチャネルのデータ、Gチャネルのデータ、Bチャネルのデータとなる値であり、また、Ar, Ag, Ab はそれぞれ、AのRチャネルのデータ、Gチャネルのデータ、Bチャネルのデータであり、また、Br, Bg, Bb はそれぞれ、BのRチャネルのデータ、Gチャネルのデータ、Bチャネルのデータである。しかしながら、Interger型で処理する場合、加算演算においてオーバーフローもしくはアンダーフローの問題が生じるため、上記の数式で処理するのは非常に困難である。

本発明に係るひとつの実施形態では、32ビットInterger型変数に3チャネルのRGBデータを割り当てると下記のようになる。以下、C/C++の文法を例として説明するが、本発明はこれに限定はされない。

00000000 RRRRRRRR GGGGGGGG BBBBBBBB

二つのピクセルA、Bについて、 A + B を含む平均演算を行うと、

A = 00000000 RRRRRRRR GGGGGGGG BBBBBBBB
B = 00000000 RRRRRRRR GGGGGGGG BBBBBBBB

であるので、ビット演算子を用いて右側へ一桁シフトして

A >> 1
B >> 1

A = 00000000 0RRRRRRR RGGGGGGG GBBBBBBB
B = 00000000 0RRRRRRR RGGGGGGG GBBBBBBB

さらにオーバーフロー／アンダーフローを防止するために

A & 00000000 01111111 01111111 01111111
B & 00000000 01111111 01111111 01111111

とすると、

A = 00000000 0RRRRRRR 0GGGGGGG 0BBBBBBB
B = 00000000 0RRRRRRR 0GGGGGGG 0BBBBBBB

となる。この後に A + B の演算を行う。以上のプロセスをC/C++のような言語で表記すると以下のようになる。

A + B = (( A >> 1 ) & 0x007F7F7F ) + (( B >> 1 ) & 0x007F7F7F )

このように、ピクセルA、Bのデータ値を32ビットCPUレジスタで処理すると、8ビット型で処理をするよりも高速な演算が期待できる。加えて、従来の8ビット型の処理ではRead-Write処理が各3回ずつ必要であることと対比して、32ビットCPUレジスタによる処理では、Read-Write処理が各1回ずつで行うことができる。したがって、本発明の実施形態に係る手法は、リードライトが遅いシステムバスを用いてチャネルの処理を行う場合にきわめて有用である。
また、上述した手法を用いて、画像を拡大するプロセスを行うことが可能であるということを当業者は容易に理解できる。

［段階的な分割による平均計算法］
以下、本発明の実施形態に係る画像サイズ変換装置に含まれるシフト加算演算手段の特徴について、さらに詳述する。

図７は、本発明の実施形態に係る画像サイズ変換装置に含まれるシフト加算演算手段の処理を説明するフローチャートであって、全体的な流れの概要を示している。
大きいイメージを縮小する際、一般的には四重のFor-Loopを形成する。しかしながら、本発明に係るシフト加算演算手段においては、前述のように内部の二つのFor-Loopを省略することが可能となっている。

本発明の或る実施形態においては、画像サイズ変換装置は、高さ方向（Y方向）および幅方向（X方向）のピクセルサイズについて、目的とするサイズに至るまでそれぞれ連続的に半分ずつ縮小してゆき、最後の縮小プロセスのみを従来の縮小過程とすることによって、画像のサイズ変換処理を高速に行うことが可能とする。

まず、処理対象とする画像の変換目的とするピクセルサイズを Dstsize とし、処理途中の画像のピクセルサイズを Cursize とする。
Cursize / 2 < Dstsize
が真であるときには、二つのピクセルのそれぞれが含む3チャネルのデータを同時に平均演算するステップへと進み、偽であるときには一般平均演算ステップへと進む（ステップ S700 ）。

上述したような手法を用いて二つのピクセルのそれぞれが含む3チャネルのデータを同時に平均演算した（ステップ S710 ）後には、
Cursize / 2 == Dstsize
が偽であれば再びステップ S700 へ戻り、真であれば目的のサイズ変換処理が終了する（ステップ S720 ）。また、一般平均演算（ステップ S730 ）を終了した後もサイズ変換処理を終了する。

図８は、図７のステップ S710 の詳細を示すフローチャートである。 X を処理中の画像の幅方向のピクセルサイズ、 Y を処理中の画像の高さ方向のピクセルサイズ、 DstHeight を目的とする高さ方向のピクセルサイズ、 DstWidth を目的とする幅方向のピクセルサイズとする。二つのピクセルのそれぞれが含む3チャネルのデータを同時に平均演算し（ステップ S800 ）、
Y < DstHeight
が偽となるまで S800 をループさせ（ステップ S810 ）、その後に
X < DstWidth
が偽となるまで S800 をループさせる（ステップ S820 ）。なお、ステップ S810 と S820 の順序を逆にして実施することも可能である。

図９は、図７のステップ S730 の詳細を示すフローチャートである。 PX をcellの幅方向のピクセル、 PY をcellの高さ方向のピクセル、 cellHeight をcellの幅方向のピクセルサイズ、 cellWidth をcellの高さ方向のピクセルサイズとする。ここでcellは上述したものである。

一般の平均演算を行い（ステップ S900 ）、
PY < cellHeight
が偽となるまで S900 をループさせ（ステップ S910 ）、その後に
PX < cellWidth
が偽となるまで S900 をループさせる（ステップ S920 ）。さらにその後、
Y < DstHeight
が偽となるまで S900 をループさせ（ステップ S930 ）、その後に
X < DstWidth
が偽となるまで S900 をループさせる（ステップ S940 ）。なお、ステップ S910 と S920 、もしくはステップ S930 と S940 の順序を逆にして実施することも可能である。

例えば、 1600 ピクセルを 120 ピクセルに縮小する場合には、
第一段階 1600 / 2 = 800
第二段階 800 / 2 = 400
第三段階 400 / 2 = 200
第四段階 200 -> 120 で縮小
と四段階を経て行うことができる。上述の記述にしたがうと、このうち第一段階〜第三段階に図８のフロー、第四段階に図９のフローを用いることになる。このような手法は、元画像のサイズが大きければ大きいほど（例えば、 2560x1920 ピクセル＝約500万画素）処理の高速化の効果が増大する。また、下記のように平均値の特性上、個々の段階で割った結果値が累積されるため、より細分化された処理も可能である。
A / 16 = (((( A / 2 ) / 2 ) / 2 ) / 2 )

［画像のインデックスを作成して利用する手法］
WAP 2.0に基づく XHTML 規格に従って静的に表現された HTML では、移動・縮小・拡大のようなユーザーインターフェイスを実現するには限界がある。また、JAVA（登録商標）アプリやBREWアプリを使用する場合には、ユーザーがアプリをダウンロードして設置する必要が生じてしまう。さらに、携帯端末装置はアプリを読み込んでからまた戻る必要があるために不便であり、効率的な方法とは言えない。

また、多様なスクリプトが支援できない XHTML では、画像を拡大する部分を指定するためのボックスを表現することができず、画像を拡大して閲覧するためにはサーバから拡大画像を再受信するしかない。ここでの問題は、ユーザーが画像を拡大する操作を入力した後に即座に対応するための、画像を再受信する時間の長さである。

モバイルウェブブラウザからWebサーバに画像を要求する場合には、画像のURLを転送している。このとき、ファイル送信と同様に一つのファイルの全体容量を送り、携帯端末側では画像の全体を表示することになる。したがって、画像の一部だけを拡大して表示するためには、モバイルウェブブラウザで拡大した領域のみを含む画像を受信する必要がある。通常、Webサーバでは、一つのイメージファイルだけを置いており、新たに先述のような一部拡大画像のすべてを用意するとなると莫大な数となってしまう。つまり、画像をサーバに登録する段階でこのような処理をするには相当な無理があると言わざるを得ない。

このような問題に鑑み、本発明の或る実施形態に係る画像配信システムにおいては、携帯端末装置から利用することができる、画像の拡大／縮小のためのユーザーインターフェースが提供される。

ユーザーが拡大したい領域を指定するためのインターフェイスを作成するために、図５のような小さいインデックス画像を用いることができる。例えば、 96x76 ピクセル、容量3KB未満であれば、3Gフォンの場合には1秒未満で受信することができる。このような容量の小さいインデックス画像を用いると、拡大／縮小のための迅速な再受信を行うためのユーザーインターフェイスを構築することができる。元画像について、予めいくつかの内部ブロックに分割したようなインデックス画像を用意する。このインデックス画像のいずれかを選択することによって、ユーザーは拡大したい領域を選択することができる。その後、選択した部分について、携帯端末の画面サイズに合わせて本発明に係る画像サイズ変換装置を用いて高速に拡大した画像を再受信する。このときに拡大した画像についてさらにインデックスを用意し、再度の拡大を行うことも可能である。また、迅速に以前の画面に戻す（元画像の全体を示すインデックス画像に戻る）こともできる。この拡大／縮小段階の階層は任意に設定することができる。

実施形態の例として、以下の表で示されるような合計四段階の拡大／縮小について述べる。例として元画像のサイズを 240x180 ピクセルとする。また、ここでは携帯端末装置の例として一般的な10+2キーをユーザー操作手段として有している携帯電話を用いて説明するが、本発明はこれに限定されるものではない。

図１０では、ユーザーが拡大表示モードに移行するように操作を行うと、サーバ側では元画像を図１０の 1000 のように16等分し、そのうちの一部である指定範囲画像 1010 （グレー部分）を、 96x72 ピクセルのインデックス画像として変換し、携帯電話側へと送信する。なお、 1000 および 1010 は携帯電話の表示手段に表示された場合の例である。携帯電話にはユーザー操作手段としてテンキー 1020 が含まれている。ユーザーはテンキー 1020 を、例えば以下のように操作して画像の拡大／縮小インターフェイスとして用いることができる。

〈方向移動キー〉
「1番」：指定範囲画像を左上へ移動
「2番」：指定範囲画像を上へ移動
「3番」：指定範囲画像を右上へ移動
「4番」：指定範囲画像を左へ移動
「6番」：指定範囲画像を右へ移動
「7番」：指定範囲画像を左下へ移動
「8番」：指定範囲画像を下へ移動
「9番」：指定範囲画像を右下へ移動
〈モード遷移キー〉
「5番」：全体画面モードへ移行
「0番」：初期画像に戻る
操作の一例として、テンキー 1020 の「6番」キーを 1010 の範囲の状態で押すと、図１１のように携帯電話の表示手段上で指定範囲画像が 1100 へと移動する（つまり、「元画像のうちの中央部分が見える状態」から、「元画像の中央右部分が見える状態」へと移行する）。このとき、サーバ側では、「6番」のキー操作を受信すると、本発明の実施形態に係る画像拡大方法を用いて領域 1100 に相当する部分を拡大してインデックス画像としてサイズを適切に調節してから、携帯電話側に送信する。

また、テンキー 1020 の「5番」キーを 1010 の範囲の状態で押すと、図１２のように携帯電話の表示手段上で画像が拡大され、「元画像のうちの中央部分が見える状態」から、「元画像の中央部分の中央部分が見える状態」へと移行する。このとき、サーバ側では、「5番」のキー操作を受信すると、本発明の実施形態に係る画像拡大方法を用いて領域 1010 に相当する部分を拡大して、さらにその拡大された部分について新たに16分割し、そのうちの領域 1200 に相当する部分を拡大してインデックス画像としてサイズを適切に調節してから、携帯電話側に送信する。

以下、本発明の実施形態に係る画像拡大／縮小インターフェイスの例についてさらに詳述する。
〈段階0〉
携帯電話の画面サイズ等に対して最適化されたサイズ（240ピクセル）で、携帯電話の画面に元画像の全体の領域（以下、「全体画面」と称する）を表示する。

・Text Button "拡大モード" を入力
-> 元画像の中央部分（16分割した場合、中央の4個の領域）を拡大して表示
〈段階1〉
携帯電話の画面には、2倍に拡大されたインデックス画像（96ピクセル）を表示する。

・範囲移動キー（1〜4番、もしくは6〜9番キー）を入力
-> 元画像の範囲内において、表示するインデックス画像を切り換える
・全体画面の表示（5番キー）を入力
-> 全体画像（240ピクセル）を表示する
・初期画面への回帰（0番キー）を入力
-> 初期画面（段階1に入ったときに最初に表示した領域の画像）に戻る
・Text Button "拡大モード" を入力
-> 段階1の画像として携帯電話の画面に表示されている画像の中央部分（16分割した場合、中央の4個の領域）をさらに拡大して表示
〈段階2〉
携帯電話の画面には、4倍に拡大されたインデックス画像（96ピクセル）を表示する。

・範囲移動キー（1〜4番、もしくは6〜9番キー）を入力
-> 段階1で指定した範囲内において、表示するインデックス画像を切り換える
・全体画面の表示（5番キー）を入力
-> 全体画像（240ピクセル）を表示する
・初期画面への回帰（0番キー）を入力
-> 初期画面（段階2に入ったときに最初に表示した領域の画像）に戻る
・Text Button "拡大モード" を入力
-> 段階2の画像として携帯電話の画面に表示されている画像の中央部分（16分割した場合、中央の4個の領域）をさらに拡大して表示
〈段階3〉
携帯電話の画面には、8倍に拡大されたインデックス画像（96ピクセル）を表示する。

・範囲移動キー（1〜4番、もしくは6〜9番キー）を入力
-> 段階2で指定した範囲内において、表示するインデックス画像を切り換える
・全体画面の表示（5番キー）を入力
-> 全体画像（240ピクセル）を表示する
・初期画面への回帰（0番キー）を入力
-> 初期画面（段階3に入ったときに最初に表示した領域の画像）に戻る
また、例えば元画像の幅が800ピクセルで、携帯電話の画面の幅が240ピクセルである場合には、元画像の2倍の倍率で携帯電話の画面に表示させる場合、
上限倍率 = 倍率 x 元画像サイズ / 画面サイズ
= 2 x 800 / 240
とする。画像拡大時にこの上限倍率よりも拡大しようとすると、品質の過度の劣化を起こすため、これ以上はユーザーに拡大させないように設定することが好ましい。

図１３は、本発明に係るプログラムを実行するハードウェア構成の概要図であって、CPU 1300 、メモリ 1302 、入力装置 1304 、出力装置 1306 、外部記憶装置 1308 、媒体駆動装置 1310 、可搬記録媒体 1312 、ネットワーク接続装置 1314 が、バス 1316 によって接続されている。本発明に係るプログラムは、外部記憶装置 1308 もしくは媒体駆動装置 1310 によって駆動される可搬記録媒体 1312 に格納することができる。また、ハードウェアは、ネットワーク接続装置 1314 を介してネットワークと接続することができ、入力装置 1304 および出力装置 1306 を通じて本発明に係るプログラムを入出力することが可能である。

本発明に係るモバイルウェブブラウザに対応する画像拡大／縮小方法およびプログラムに関し、さらにそれを利用した使用者インターフェイスおよび送信方法を使用することによって、元画像から高速且つ品質劣化の少ないサイズ変換画像を生成し、携帯端末装置に対して効率的に配信することが可能となり、コンピュータリソースの使用量およびデータ転送量を低減することができる。

図１は、本発明の実施形態に係る画像配信システムの概要図である。図２は、画像配信システム 100 の動作例を示すフローチャートである。図３は、画像サイズ変換装置で処理される元画像のサンプルである。図４は、図３の元画像を、本発明の実施形態に係る画像サイズ変換装置を用いて、携帯端末装置用に縮小した例である。図５は、図３の元画像を、本発明の実施形態に係る画像サイズ変換装置を用いて、携帯端末装置用のインデックスイメージとして縮小した例である。図６は、本発明の実施形態に係る画像サイズ変換装置に含まれるシフト加算演算手段の処理を説明するための模式図である。図７は、本発明の実施形態に係る画像サイズ変換装置に含まれるシフト加算演算手段の処理を説明するフローチャートである。図８は、本発明の実施形態に係る画像サイズ変換装置に含まれるシフト加算演算手段の処理を説明するフローチャートである。図９は、本発明の実施形態に係る画像サイズ変換装置に含まれるシフト加算演算手段の処理を説明するフローチャートである。図１０は、本発明の実施形態に係るユーザーインターフェイスを説明するための概念図である。図１１は、本発明の実施形態に係るユーザーインターフェイスを説明するための概念図である。図１２は、本発明の実施形態に係るユーザーインターフェイスを説明するための概念図である。図１３は、本発明の実施形態に係るプログラムを実行するためのハードウェア構成図である。

符号の説明

100 画像配信システム
110 サーバ
112 通信手段
120 データベース格納手段
130 画像サイズ変換装置
140 ネットワーク
150 携帯端末装置
152 モバイルウェブブラウザ
154 通信手段
156 ユーザー操作手段
1000 携帯端末装置の表示手段に表示された画像
1010 画像 1000 の一部を指定した範囲の画像
1020 携帯端末装置のユーザー操作手段であるテンキー
1100 画像 1000 の一部を指定した範囲の画像
1200 画像 1010 の一部を指定した範囲の画像
1300 CPU
1302 メモリ
1304 入力装置
1306 出力装置
1308 外部記憶装置
1310 媒体駆動装置
1312 可搬記録媒体
1314 ネットワーク接続装置
1316 バス

Claims

複数のピクセルを含み、前記複数のピクセルのそれぞれが有するチャネルを表現するビット列を少なくともチャネルの数だけ含むように構成される画像のサイズの変換処理を行うために、前記画像を処理するための装置であって、
前記画像を格納する、記憶手段と、
前記記憶手段に格納された前記画像に含まれる前記チャネルを表現する前記ビット列のうちの少なくともいくつかをシフトしてから論理演算を行って、シフトと論理演算を施した前記ビット列同士を加算する、シフト加算演算手段と、
前記シフト加算演算手段の算出結果に基づいて、前記画像を縮小する前記画像のサイズの変換処理を行う、画像サイズ変換手段と
を含み、ここで前記シフト加算演算手段が、
前記チャネルを表現する前記ビット列の上位または下位に、 "0" もしくは "1" の固定ビットを挿入することによってオーバーフローあるいはアンダーフローを防止する、オーバーフロー／アンダーフロー防止手段
を含む
ことを特徴とする、画像サイズ変換装置。
前記シフト加算演算手段が、前記演算を複数回行うことによって、段階的に前記画像のサイズ変換処理を行うことを特徴とする、請求項１記載の画像サイズ変換装置。
前記シフト加算演算手段が、平均演算を行うことによって画像サイズ変換処理を実行することを特徴とする、請求項１〜２のいずれか一項に記載の画像サイズ変換装置。
前記画像の形式を変換する、画像形式変換手段
をさらに含むことを特徴とする、請求項１〜３のいずれか一項に記載の画像サイズ変換装置。
複数のピクセルを含み、前記複数のピクセルのそれぞれが有するチャネルを表現するビット列を少なくともチャネルの数だけ含むように構成される画像のサイズの変換処理を行
うための画像サイズ変換装置において、
前記画像を記憶手段に格納するステップと、
前記記憶手段に格納された前記画像に含まれる前記チャネルを表現する前記ビット列のうちの少なくともいくつかをシフトしてから論理演算を行って、シフトと論理演算を施した前記ビット列同士を加算する、シフト加算演算ステップと、
前記シフト加算演算ステップの結果に基づいて、前記画像を縮小する前記画像のサイズの変換処理を行うステップと
を含み、ここで前記シフト加算演算ステップが、
前記チャネルを表現する前記ビット列の上位または下位に、 "0" もしくは "1" の固定ビットを挿入することによってオーバーフローあるいはアンダーフローを防止するステップ
を含む
ことを特徴とする、画像サイズ変換方法。
複数のピクセルを含み、前記複数のピクセルのそれぞれが有するチャネルを表現するビット列を少なくともチャネルの数だけ含むように構成される画像のサイズの変換処理をコンピュータ上で行うための画像サイズ変換プログラムであって、
前記画像を記憶手段に格納するステップと、
前記記憶手段に格納された前記画像に含まれる前記チャネルを表現する前記ビット列のうちの少なくともいくつかをシフトしてから論理演算を行って、シフトと論理演算を施した前記ビット列同士を加算する、シフト加算演算ステップと、
前記シフト加算演算ステップの結果に基づいて、前記画像を縮小する前記画像のサイズの変換処理を行うステップと
を実行することを含み、ここで前記シフト加算演算ステップが、
前記チャネルを表現する前記ビット列の上位または下位に、 "0" もしくは "1" の固定ビットを挿入することによってオーバーフローあるいはアンダーフローを防止するステップ
を含む
ことを特徴とする、画像サイズ変換プログラム。
前記コンピュータが有する演算処理部が、32ビット以上のCPUであることを特徴とする
、請求項６記載の画像サイズ変換プログラム。
請求項１〜４のいずれか一項に記載の画像サイズ変換装置を含んだサーバが行う画像配信システムであって、
携帯端末装置からのアクセス要求に対して、前記携帯端末装置の機種を判別する、携帯端末装置判定手段と、
変換画像送信手段と
を含み、判別した前記携帯端末装置の機種に対応して、前記サーバに含まれている前記画像サイズ変換装置が、前記画像のサイズを変換して、前記変換画像送信手段が前記サイズ変換した画像を前記携帯端末装置へと送信することを特徴とする、画像配信システム。
前記携帯端末装置判定手段が、前記携帯端末装置のUser-Agent情報を用いることを特徴とする、請求項８記載の画像配信システム。
前記画像のインデックスを作成するインデックス作成手段
をさらに含み、前記インデックス、および作成された前記サイズ変換した画像に基づいて、前記携帯端末装置が前記画像の任意の部分を選択し拡大表示することを特徴とする、請求項８もしくは９に記載の画像配信システム。
前記携帯端末装置が有するユーザー操作手段を用いて前記画像の任意の部分を選択することを特徴とする、請求項１０記載の画像配信システム。
前記サーバがキャッシュ手段をさらに含み、前記キャッシュ手段が、前記画像サイズ変換装置が作成したサイズ変換画像を格納することを特徴とする、請求項８〜１１のいずれか一項に記載の画像配信システム。
請求項６もしくは７に記載の画像サイズ変換プログラムを実行するコンピュータを含んだサーバが行う画像配信システムであって、
携帯端末装置からのアクセス要求に対して、前記携帯端末装置の機種を判別する、携帯端末装置判定手段と、
変換画像送信手段と
を含み、判別した前記携帯端末装置の機種に対応して、前記サーバに含まれているコンピュータが前記画像サイズ変換プログラムを実行することによって前記画像のサイズを変換して、前記変換画像送信手段が前記サイズ変換した画像を前記携帯端末装置へと送信することを特徴とする、画像配信システム。
画像を格納する、記憶手段と、
チャネルを表現するビット列を少なくともチャネルの数だけ含むように構成される前記画像のデータを単位として、前記記憶手段のリードライト処理を、前記チャネルを表現する前記ビット列のうちの少なくともいくつかをシフトしてから論理演算を行って、シフトと論理演算を施した前記ビット列同士を加算するようにして行う、画像データ処理手段とを含み、ここで前記画像データ処理手段が、
前記チャネルを表現する前記ビット列の上位または下位に、 "0" もしくは "1" の固定ビットを挿入することによってオーバーフローあるいはアンダーフローを防止する、オーバーフロー／アンダーフロー防止手段
を含む
ことを特徴とする、画像処理装置。
前記画像の前記データの単位が、1ワード32ビット以上であることを特徴とする、請求
項１４記載の画像処理装置。