JP4377066B2

JP4377066B2 - デジタル画像の移植性の改善

Info

Publication number: JP4377066B2
Application number: JP2000568048A
Authority: JP
Inventors: マティソン，フィリップ・イー
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1998-08-27
Filing date: 1999-08-17
Publication date: 2009-12-02
Anticipated expiration: 2019-08-17
Also published as: US7010177B1; DE19983504T1; TW442759B; GB2357926B; CN1324469A; JP2002524006A; CN101714249A; AU5567999A; GB2357926A; KR100579216B1; KR20010072958A; WO2000013132A1; GB0104702D0; DE19983504B4

Description

【０００１】
（背景情報）
（発明の分野）
本発明は、一般にデジタル撮像に関し、より詳細には、様々な固有のフォーマットが可能なデジタル画像をパッケージングし、これらを共通のフォーマットに変換する技法に関する。
【０００２】
（関連技術）
デジタル・カメラなどデジタル撮像装置の可用性が向上の一途をたどりつつあることによって、パーソナル・コンピュータ（ＰＣ）業界と写真業界とが結集するいまだかつてない好機が訪れている。デジタル・カメラが作成した写真は、ＰＣで使用するのには理論上好適であり、デジタル・カメラとパーソナル・コンピュータを統合させることには何の問題もないと思われる。ただし、この結合には大きな障害がある。
【０００３】
デジタル写真業界が現在実施していることは、製造業者がそれぞれ独自にデジタル・カメラを開発していることである。この動きは変わりそうもない。このような新しいカメラは、典型的には、画像をホスト処理システム上で表示できるように、それぞれ統合されたソフトウェア・パッケージにまとめられている。ソフトウェアは、具体的にはそのカメラで動作するように設計され、タイプの異なるデジタル・カメラまたは製造業者の異なるカメラとの互換性はサポートしていない。デジタル画像をカメラ内部に格納する方法、格納前に処理する方法、またはホスト・システム（たとえばＰＣ）がこれらを取り扱う方法については、製造業者間でほとんど、またはまったく取り決められていない。
【０００４】
装置とホストとの間でイメージを転送する基準に関する、これまでで最も新しい試みが、Ｔｗａｉｎドライバである。Ｔｗａｉｎドライバとは、撮像装置からデジタル画像を取り出すためのアプリケーション・プログラムへの標準インタフェースとなっているソフトウェア・モジュールである。モジュールは、撮像装置の固有フォーマットからアプリケーションが使用する何らかの共通フォーマットへ画像を変換する。このような共通フォーマットの例には、赤緑青（ＲＧＢ）ビットマップ、およびＭｉｃｒｏｓｏｆｔＣｏｒｐによって定義付けられたような装置非依存型ビットマップ（ＤＩＢ）が含まれる。
【０００５】
タイプの異なるデジタル・カメラは、デジタル画像を格納するために異なる固有フォーマットを使用することが多い。デジタル・カメラ内部には、装置、固有フォーマット、およびホスト・オペレーティング・システムの所与の組み合わせに特有のＴｗａｉｎモジュールを格納することができる。その後Ｔｗａｉｎモジュールを、画像データと共にそれぞれの新しいホストに転送することができる。ただし、このようなモジュールをデジタル・カメラ内部に格納することは、デジタル・カメラ内のメモリ・リソースが制限されていることから、実用的でない場合がある。また、このようなモジュールはホスト・オペレーティング・システムと直接対話するため、カメラ内にウィルスとしてセキュリティ・リスクが発生し、ホスト・システム内へと伝播される可能性がある。結局の所、Ｔｗａｉｎモジュールは典型的には特定のホスト・コンピュータに特有のコードで作成され、Ｔｗａｉｎソリューションが実際には移植不能となってしまう。
【０００６】
したがって、デジタル画像を異なる固有フォーマットで格納するタイプの異なる撮像装置が、大規模な装置特有のＴｗａｉｎドライバをホスト・システムにロードする必要なく、ホスト内部でこのような画像を共通フォーマットで表示または処理できるように、ホスト・システムと通信可能にする技法を有することが望ましい。
【０００７】
（概要）
一実施態様での本発明は、センサ・データを生成する画像センサと、画像オブジェクトを格納するメモリとを有する撮像装置を対象とするものである。画像オブジェクトは、センサ・データに関する画像データと、その画像データに基づいて変換された画像データを取得するためにアブストラクト・マシンが実行する画像メソッドとを有する。
【０００８】
前述の本発明の一実施態様を簡単にまとめた特徴、ならびに他の実施態様の他の特徴および利点は、以下の詳細な説明、特許請求の範囲、および図面から明らかになろう。
【０００９】
（詳細な説明）
上記で簡単に述べたように、一実施形態での本発明は、デジタル・カメラなどの撮像装置の製造業者に、デジタル画像データの取り出しおよび格納を行うための独自の固有フォーマットを選択する機能を与えると同時に、画像を作成した特定の撮像装置に特有の知識をホスト・システムが有する必要性をなくすものである。画像に関するデータは、オブジェクトの一部として格納される。したがって、それぞれの画像は画像ファイルとして表されるのではなく、オブジェクト指向ソフトウェアの従来の意味で画像オブジェクトの一部としてパッケージングされる。画像オブジェクトには、画像データと関連付けられたメソッドとが含まれる。このメソッドは、固有フォーマットから共通画像ファイルフォーマットへの変換をサポートするのに必要なインテリジェンスである。それぞれのメソッドが、関連付けられた画像データの固有フォーマットに特有の変換を定義する。
【００１０】
画像メソッドを解釈して実行するホスト・システム内のソフトウェアは、ハードウェアおよびオペレーティング・システムの如何にかかわらず、すべてのホスト処理システムに共通とすることが可能であって、撮像装置とは無関係に開発および配布することができる。このようなソフトウェアは、実質的に、仮想マシンなどのオブジェクト実行環境である。仮想マシンと受け取った画像データとの間には依存関係がないため、新しい様々な撮像装置を、共通のフォーマットおよびアプリケーション・ソフトウェアの開発とは関係なく開発することができる。共通フォーマットを使用すれば、アプリケーション開発者が現在使用中の様々な画像ファイルフォーマットを認識し処理する必要もなくなる。画像オブジェクトによって、画像製造業者は、撮像装置内に画像を格納するのに最適なフォーマットは何か、またこれらを処理する最適な方法は何かを判定することから解放される。このような解決策は、仮想マシンおよび／または共通画像ファイル・フォーマットの変更または改善が、撮像装置またはアプリケーション・ソフトウェアの変更よりも行われる頻度がおそらく少ないので、特に有利である。
【００１１】
図１は、本発明の様々な実施形態のシステム全体図であって、画像オブジェクトは異なる撮像装置１０４ａおよび１０４ｂ内ならびに記憶装置１１０内に形成または格納された後、ホスト・システム１０２に転送される。オブジェクト１０８ａ、１０８ｂ、または１０８ｃはそれぞれ、画像データを取り込むのに使用された特定タイプの撮像装置に固有のフォーマットの画像データである、少なくとも１つのデータ部分を含んでいる。たとえば、装置１０４ａは、その装置を使用して得られた単一の画像を表す、オブジェクト１０８ａを生成するように構成されたスキャナであってよい。これに対して、装置１０４ｂは、２つの静止画像を表す２つのデータ部分１１４ｂ₁および１１４ｂ₂を有する単一のオブジェクト１０８ｂを生成するように構成されたデジタル・カメラであって良い。
【００１２】
いったんホスト・システム１０２にオブジェクトが転送されると、そのメソッドはアブストラクト・マシン１２０によって解釈および実行され、その結果データ・ファイル１１６ａ（オブジェクト１０８ａから）、１１６ｂ₁および１１６ｂ₂（オブジェクト１０８ｂから）、ならびに１１６ｃ（オブジェクト１０８ｃから）となる。これらのファイルは、事前定義された共通フォーマットのデジタル画像を含んでいる。次いで、各データ・ファイル内で画像を操作または表示するために、アプリケーション１２４がデータ・ファイルにアクセスすることができる。アプリケーション１２４は、ＪｏｉｎｔＰｈｏｔｏｇｒａｐｈｉｃＥｘｐｅｒｔｓＧｒｏｕｐ（ＪＰＥＧ）フォーマット、ＧｒａｐｈｉｃｓＩｎｔｅｒｃｈａｎｇｅＦｏｒｍａｔ（ＧＩＦ）、ＩｎｔｅｒｃｈａｎｇｅＦｉｌｅＦｏｒｍａｔ（ＩＦＦ）、およびＴａｇｇｅｄＩｍａｇｅＦｉｌｅＦｏｒｍａｔ（ＴＩＦＦ）を含んでいる、多数の他のファイルフォーマットの１つに画像をさらに変換するように設計することができる。便宜上、下記の考察では、装置１０４ａと、オブジェクト１０８ａと、関連付けられたデータ１１４ａおよびメソッド１１５ａとの間の対話についてのみ説明する。ただし、この考察は、このような実施形態にのみ限定されるものではなく、図１に示されたものを含んでいる代替の装置、オブジェクト、データ、およびメソッドにも適用されるものであることを理解されよう。
【００１３】
本発明の実施形態とＴｗａｉｎモジュールを使用して装置とホストの間で画像データを転送する従来の技法との間の何らかの相違点をより理解しやすいようにするために、図１のシステムの一実施形態で実行されるステップが図２に示される。本発明の一実施形態に従って移植可能な画像データを作成および転送する技法は、生センサ・データを取り込むことによって、図２のステップ２０４から開始することができる。これは、デジタル・カメラなどの撮像装置に関連付けられた知られている技法に従って実行することができる。次に、事前定義された固有フォーマットの画像データ１１４ａが生センサ・データに基づいて形成される。一実施形態では、生センサ・データは、ステップ２０８で示されるように所望の固有フォーマットでデータを取得するために、ノイズ除去、色補間、画像圧縮、およびスケーリングなどの従来の操作および／または知的所有権のある操作に従い、撮像装置１０４ａによって処理される。あるいは、生センサ・データに対して重要な処理を実行せずに、ステップ２０８を省略することができる。この場合、生センサ・データは固有フォーマットであるとみなされる。ステップ２０８での処理量は、以下で論じる潜在的な性能の兼ね合いに関係する。次いで操作はステップ２１２に進む。
【００１４】
ステップ２１２では、撮像装置１０４ａが、画像データ１１４ａおよび関連付けられた画像メソッド１１５ａを含んでいるオブジェクト１０８ａを形成する。画像メソッド１１５ａは、画像データを固有フォーマットから事前定義された共通フォーマットに変換するためにアブストラクト・マシン１２０によって実行される、プログラムまたは命令リストである。メソッド１１５ａは、アブストラクト・マシン１２０の命令セットに基づくものである。ほとんどの場合、アブストラクト・マシンの命令セットは画像処理用に最適化することができるため、およびメモリ割振りなどの資源割振りはこのメソッドによらずにアブストラクト・マシン１２０に組み込むことができるため、このメソッドは従来のＴｗａｉｎモジュールよりもかなり小さくなると予想される。
【００１５】
画像オブジェクト１０８ａが撮像装置内で形成された後、図２の操作はホスト・システムへのオブジェクト転送に進む。これは、有線リンクなどの画像データを転送するよく知られた通信媒体を使用するか、または不揮発性メモリ・カードなどの取外し可能な記憶装置１１０を使用して、実行することができる。
【００１６】
通信媒体とホスト・システム内のアブストラクト・マシン１２０との間のインタフェースがオブジェクト・ドライバ１２２である。オブジェクト・ドライバ１２２は、アブストラクト・マシンがオブジェクト１０８ａを使用できるようにするために、ホスト・システム１０２内にある適切なハードウェアおよびソフトウェア（オペレーティング・システムを含んでいる）と通信する。オブジェクト・ドライバはローカルＯＳの下でアブストラクト・マシンを起動し、最終的にメソッドを実行させる。一実施形態では、オブジェクト・ドライバ１２２は、ＴａｇｇｅｄＩｍａｇｅＦｉｌｅＦｏｒｍａｔ（ＴＩＦＦ）に従って構成されたファイルを検索するよく知られたソフトウェア・ドライバを含んでいる。ＴＩＦＦは、ビットマップされた画像をＰＣおよびＭａｃｉｎｔｏｓｈコンピュータに格納する一般的なフォーマットであり、オブジェクト１０８ａを実装するのに使用することができる。オブジェクト１０８ａおよびその関連付けられたドライバ１２２を実装する他の技法は、当分野の通常の技術者であれば理解できるように使用することができる。
【００１７】
ローダ（図示せず）は、メソッドをアブストラクト・マシン内にロードし、画像データを示すポインタにこれを渡す。さらにローダは、画像カウントなど画像オブジェクトの一定のフィールドを認識し、ステップ２２０のように、各画像を処理するためにアブストラクト・マシンを繰返し初期設定する。その結果、画像データ１１４ａが共通フォーマットの変換済み画像データに変換および処理される。変換済みデータは、通常別のデータ・ファイル１１６ａ内に配置され、ハード・ディスク・ドライブなどの大容量記憶装置内に格納することができる。次いでアプリケーション１２４は、さらにこのデータ・ファイル１１６ａを所望の最終フォーマットに処理することができる。
【００１８】
以上、本発明の一実施形態についてシステム全体の見地から説明してきたが、図３および４では、本発明の他の実施形態を撮像装置１０４ａおよびホスト・システム１０２として例示する。図３は、画像オブジェクト１０８ａを受け入れて処理するように構成されたソフトウェアおよびハードウェアを含んでいる、ホスト処理システム１０２の一実施形態である。この特定の実施形態は、プロセッサ３３４が結合されたバス３３２を中心に構成される。システム１０２は、ＩｎｔｅｌプロセッサならびにＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ（登録商標）のグラフィカル・ユーザ・インタフェースおよびオペレーティング・システムを有する、従来のパーソナル・コンピュータであってよい。オペレーティング・システム・ソフトウェア３４０、オブジェクト・ドライバ１２２、およびアブストラクト・マシン１２０はメモリ３２８内に別々にロードされるように示されているが、当分野の通常の技術者であれば、これらソフトウェア構成要素が時には全体的または部分的に組み合わせられ、メモリ３２８と、大容量記憶装置３３８（たとえば磁気回転式ディスク）と、光コンパクト・ディスクなどのポータブル・メモリ（図示せず）との間で分配できることを理解されよう。
【００１９】
プロセッサ３３４は、メモリ３２８（たとえばランダム・アクセス・メモリ（ＲＡＭ））内および大容量記憶装置３３８内に格納された命令を実行する。メモリ３２８は、プロセッサ３３４によって実行されるとホスト処理システム１０２を構成するステップに様々な撮像装置および記憶装置からオブジェクトを受け取って処理させる命令をロードすることができる、半導体集積回路などの任意の機械読取り可読媒体である。
【００２０】
ホスト処理システム１２０は、ＲＳ−２３２シリアル、ユニバーサル・シリアル・バス（ＵＳＢ）、およびＩＥＥＥ標準１３９４〜１９９５を含んでいる従来のコンピュータ周辺バス標準のいずれか１つでコンパイルする、通信インタフェース３１６も含んでいる。物理的有線を介した通信に加えて、たとえば、データ伝送用の赤外線または無線周波を使用する無線通信媒体も企図されている。他の代替通信媒体としては、ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒＭｅｍｏｒｙＣａｒｄＩｎｔｅｒｎａｔｉｏｎａｌＡｓｓｏｃｉａｔｉｏｎ（ＰＣＭＣＩＡ）、ＩｎｔｅｌによるＦｌａｓｈＭｉｎｉａｔｕｒｅＣａｒｄ、およびデジタル画像データの移送に好適な任意の他の不揮発性記憶媒体を含んでいる、いくつかの異なる取外し可能記憶装置が企図されている。
【００２１】
図３のホスト処理システム１０２は、陰極線管（ＣＲＴ）、液晶表示（ＬＣＤ）、および電子画像を表示するのに好適な任意の他の表示技法を含んでいる任意の従来型表示装置とインタフェースする、グラフィックス・アダプタ・カードなどの、ユーザ表示装置インタフェース３４２も備えている。もちろん、ホスト処理システム１０２は、追加のＩ／Ｏを実行する追加のインタフェース（図示せず）（たとえばネットワーク・インタフェース・コントローラ）も備えることができる。
【００２２】
以上、本発明のシステム実施形態のホスト部分について論じてきたが、図４では、そのソフトウェア要素およびハードウェア要素を含んでいる撮像装置１０４ａについて例示する。図４の実施形態も、プロセッサ４２４およびメモリ４２８が結合されるバス４３２に基づくものである。ここでの代替例は、プロセッサ４２４およびメモリ４２８に取って代わるマイクロコントローラである。メモリは、半導体集積回路ＲＡＭなどの機械可読媒体または読取り専用メモリ（ＲＯＭ）などの不揮発性半導体メモリであってよい。メモリ４２８には、画像オブジェクト１０８の一部として画像データ１１４ａとメソッド１１５ａとの組み合わせを発生させる（図１参照）、プロセッサ４２４によって実行される命令がロードされる。図４では、このような命令をオブジェクト形成ソフトウェア４１２として集合的に表示している。画像メソッド１１５ａは、通常、以下で記載するように別々のソフトウェアとして開発される。
【００２３】
メモリ４２８は、画像センサ４０４から受け取った生センサ・データを、固有フォーマットの画像データ１１４ａに処理するために使用される、任意選択の信号処理ソフトウェア４０８を含むこともできる。画像処理論理回路４３６は、生センサ・データを処理するときにより良い性能を得るために、撮像装置１０４に含めることもできる。論理回路４３６は、一実施形態では相補型金属酸化膜半導体（ＣＭＯＳ）アクティブ・ピクセル・センサであってもよい、画像センサ４０４のタイに組み込むことができる。
【００２４】
図４には示されていないが、メモリ４２８は、インタフェース４１６および４２０にアクセスして撮像装置１０４ａの外部にある装置と通信する、プロセッサ４２４によって実行されるソフトウェアも格納する。通信媒体へのインタフェース４１６は、ホスト・システムに関して上記で論じたコンピュータ周辺バス標準でコンパイルするものであってよい。同様に、インタフェース４２０は、不揮発性記憶のフラッシュ・メモリ・カードなどの取外し可能記憶装置を接続したり、画像オブジェクト１０８ａの移送用のカードに接続することができる。
【００２５】
図４に示した本発明の実施形態は、画像オブジェクト１０８ａを形成してホスト・システム１０２に転送するために、主としてソフトウェア・ベースのプロセッサおよびバス・アーキテクチャを使用する。これに代わるものとしては、前述の画像オブジェクト１０８ａを形成および転送する場合と同じ機能を実行する、ゲート・アレイおよび特定用途向け集積回路（ＡＳＩＣ）に基づく主としてハードウェア・ベースのアーキテクチャとすることができる。
【００２６】
アブストラクト・マシンおよび画像オブジェクト
本開示の残りの部分では、画像メソッド１１５ａを構築する際に使用できる命令セットを含んでいる、画像オブジェクト１０８ａおよびアブストラクト・マシン１２０を実装する技法について論じる。
【００２７】
前述のように、オブジェクト１０８ａは、ＴａｇｇｅｄＩｍａｇｅＦｉｌｅＦｏｒｍａｔ（ＴＩＦＦ）／ＥｌｅｃｔｒｏｎｉｃＰｈｏｔｏｇｒａｐｈｙ（ＥＰ）構造またはファイルとして実装することができる。ＴＩＦＦファイルは、画像データ１１４ａおよび関連付けられたメソッド１１５ａの位置を指すファイル・ヘッダを含んでいる。ＴＩＦＦファイルおよびそのファイル・ヘッダは、オブジェクト・ドライバ１２２によってアクセス可能であり、アブストラクト・マシン１２０を使用可能にすることができる。
【００２８】
画像メソッド１１５ａを開発する手順は、撮像装置１０４ａの開発者が事前定義された固有フォーマットと共通フォーマットとを比較することによって開始される。画像データ１１４ａを固有フォーマットから共通フォーマットに変換するアルゴリズムが開発される。このようなアルゴリズムはよく知られたものであるか、または当分野の通常の技術者が簡単に開発できるものである。次いでこのアルゴリズムが、Ｃなどの高水準プログラミング言語および／または以下に記述するアブストラクト・マシン１２０の低水準命令セットを使用するプログラムで実施される。次いでこのプログラムがテストされ、任意選択で最適化される。次いでこのプログラムが、低水準命令を表すバイト・コードにコンパイルされる。これが所望の画像メソッド１１５ａになる。次いでこのメソッドが、撮像装置１０４ａ上の不揮発性メモリ（たとえばメモリ４２８）に、オブジェクト形成ソフトウェア４１２（図４を参照）の一部として格納される。
【００２９】
撮像装置１０４ａ内に常駐する画像オブジェクト１０８ａが必要とする記憶オーバヘッドは、記憶域が典型的に限られているデジタル・カメラなどの移植可能アプリケーションに関係する場合がある。このオーバヘッドは、（１）画像データ１１４ａをその固有フォーマットから共通フォーマットに変換するのに必要な処理の量および複雑さ、ならびに（２）その固有フォーマットでのデータ１１４ａのサイズによって決まる。事前定義された共通フォーマットに対して計算上はクローズである固有フォーマットを選択すると、画像メソッド１１５ａは、単純な数学的命令またはデータ移動命令の比較的短いリストになる。これに対して、メソッド１１５ａは、画像データ１１４ａを圧縮率の高い固有フォーマット（たとえばＪＰＥＧまたはフラクタル技術）から共通フォーマットに圧縮解除することが必要な場合、比較的大きくなりやすい。後者の場合、画像データを圧縮することによって得られる記憶スペース内の任意の利得が、画像データの圧縮解除に必要なより複雑で冗長なメソッドによって低減される。
【００３０】
記憶スペースの問題を解決するために、各メソッドがそれに基づいて形成される、アブストラクト・マシンの命令セットを高度に最適化することができる。たとえば、アブストラクト・マシン１２０が使用できる（画像データ１１４ａを受け取るための）入力バッファと（変換されたデータを共通フォーマットで格納する）出力バッファの場所を暗黙的にすることができる。アドレス計算および大多数のデータ移動は、画像メソッド１１５ａ内の特有の命令ではなく、アブストラクト・マシン１２０によって暗黙的に実行することができる。したがってこのメソッドは、その関連付けられた画像データ１１４ａを共通フォーマットに変換するのに必要なアルゴリズムに専念するだけでよい。
【００３１】
画像メソッド１１５ａをコンパクトにしておくように命令セットを最適化することに加え、撮像装置上の記憶域を節約する他の方法は、図１のオブジェクト１０８ｂに示されるように、メソッド１１５ａの単一コピーを複数セットの画像データに関連付けることである。この方法では、単一の画像オブジェクト１０８ｂが画像データ１１４ｂ₁および１１４ｂ₂内に複数の画像を含んでおり、実際には、メソッド１１５ｂの実行がフィルムの現像とおおよそ等価であるような、従来のフィルムの役割に似たものとなる。
【００３２】
記憶スペースに加え、撮像装置の製造業者に関する他の問題は、画像処理方法論（ｍｅｔｈｏｄｏｌｏｇｙ）の知的所有権を保護することである場合がある。このような処理は、たとえばカラー・フィルタ・アレイ・パターンの補間、ガンマ修正、ホワイト・バランス・アルゴリズムなど、最終画像品質を向上させるために生センサ・データに対して実行することができる。撮像装置１０４ａの製造業者は、メソッド１１５ａにこれら画像処理アルゴリズムを入れることによって、オブジェクト１０８ａがホスト・システム１０２に転送されたときにアルゴリズムを潜在的な競争相手に公開してしまうのではなく、主要な画像処理機能を撮像装置内部で実行させることを望む場合がある。その結果、生センサ・データの強力な処理済みバージョンである画像データ１１４ａが生じる。その極端な場合の一つとして、自分の画像処理技術を強力に保護することを望む製造業者は、このような処理をすべて撮像装置内に埋め込み、その結果、画像データ１１４ａが共通フォーマットとなる場合がある。この場合、対応するメソッド１１５ａは、データ１１４ａをホスト・システム１０２内の出力バッファにコピーするだけである。他方の極端な場合は、画像データ１１４ａをオブジェクト１０８ａにパッケージングする前には生センサ・データに対してどんな処理も実行しないことだけで、撮像装置１０４ａ内での画像処理を絶対最低に維持することができる。メソッド１１５ａは、共通フォーマットに達するのに必要なすべての処理を定義し、ホスト・システム内のアブストラクト・マシン１２０は、共通フォーマットの画像データを達成するためにこのような処理をすべて実行する。
【００３３】
仮想マシン・アーキテクチャ
アブストラクト・マシン１２０の一例が仮想マシンである。仮想マシンは、画像メソッド１１５ａを実行する別々のコンピュータであるかのように動作する、独立型オペレーティング環境である。仮想マシンは、ホスト・システムを、受け取ったオブジェクト１０８ａに内在している可能性のあるどんなウィルスからも遮蔽する助けとなる。仮想マシンは、ホスト処理システム１０２のハードウェア・プラットフォームから独立した、命令セット、レジスタ・セット、およびメモリ・モデルを有することができる。よく知られたインタープリタ、プログラミング言語、および関連ツールを備えた使用可能な仮想マシンの一例が、ＪＡＶＡ^TMの仮想マシンおよびプログラミング言語である。
【００３４】
一般に、仮想マシンは、比較的小さなコードを画像メソッド１１５ａ用に書き込めるように最適化しなければならない。他の望ましい特徴は、たとえば、メソッド１１５ａを解釈するために、知られた技法であるジャスト・イン・タイムのコード変換を使用する、単純な仮想マシン・インタフェースおよびスピーディなコード・コンパイルである。仮想マシンは、動的メモリ割振りを使用して、メソッド１１５ａを実行中に、一時データ記憶用のバッファを作成することができるものとする。したがって、メモリ管理のためにメソッド１１５ａで必要なオーバヘッドを最小限にすることができる。また、ホスト・システム１０２は、ホスト・システムが画像オブジェクト１０８ａによるどんな正当な要求も認められるように、画像オブジェクト１０８ａが必要とする資源に比べて十分な使用可能資源（たとえばメモリ）を有するものとする。
【００３５】
仮想マシンの命令セットについても考慮しなければならない。撮像技法に関する図１の実施形態の場合、命令セットは画像処理用に最適化されるものとする。たとえば、命令が、文字列、マルチタスク実行、またはグラフィカル・ユーザ・インタフェースを処理する必要はない。命令セットは、画像データ１１４ａ用のいくつかの異なる固有フォーマットを共通フォーマットに変換できる十分なフレキシビリティを有するように設計しなければならない。仮想マシンに提供されるどんな機能およびその命令セットも、画像データ１１４ａを格納するのに使用できるどんな固有フォーマットの知識もないことを想定しなければならない。
【００３６】
命令セットについて考慮すべきその他の点は、比較的深いスタックを備えたスタック指向のフロー制御（ｃａｌｌ／ｒｅｔｕｒｎ／ｐｕｓｈ／ｐｏｐ）をサポートすることである。たとえば、仮想マシンを実施するホスト・システム１０２は、オブジェクト１０８ａによる任意の正当なスタック使用量を処理することができる拡張可能な仮想スタックに、十分な資源を提供することができる。さらに、仮想マシンは、ホスト・システム１０２で使用可能な場合に、特に並列処理が画像処理アルゴリズムにとって主要な性能強化となる可能性があることから、並列処理サポートを利用できるプログラミング制約を与えなければならない。最終的に、仮想マシンは、あらゆる潜在的な例外に関する定義済みの省略時挙動を備えた、フレキシブルな例外処理も提供することができる。プログラミングをできる限り簡略化し、オブジェクト１０８ａ内のフロー制御オーバヘッドを最小限にするために、高水準フロー制御（ｉｆ／ｆｏｒ／ｗｈｉｌｅ／ｃａｓｅ）をサポートすることも望ましい。あるタイプの変数から他のタイプのものへキャストするときに必要となる可能性のある他の特徴に、フレキシブル・タイプのチェックもある。
【００３７】
仮想マシンの例−仮想画像プロセッサ
一実施形態での仮想マシンは、以下で説明する仮想画像プロセッサ（ＶＩＰ）であってもよい。この実施形態では、ユーザの介入がまったく予想されないので、ＶＩＰに関する従来のＩ／Ｏサポートはいっさい企図されていない。ＶＩＰは、画像データ１１４ａを固有フォーマットの入力として処理するため、および画像データを共通フォーマットの出力として生成するためにのみ存在する。このようなタスクに必要なメモリ資源は、通常ホスト・システム１０２によって提供され、したがって、画像オブジェクト１０８ａのプログラマは、メモリ資源がどのように提供されるかを正確に認識する必要がない。
【００３８】
以下の記述からも明らかなように、ＶＩＰの命令セットは、従来のハードウェア・マイクロプロセッサのそれとはほとんど似ていない場合がある。これは部分的には、メソッド１１５ａのコード・サイズを減らすことを所望しているため、および画像データ１１４ａの数学的処理に重点を置いているためである。ＶＩＰの命令セットは、画像処理に必要な操作を最小限の可能なスペース内に指定できるようにしなければならない。たとえば、フロー制御命令は、関連付けられた複雑さの相対的にかなりの部分を、命令セットではなくＶＩＰに組み込むことができるため、従来のマイクロプロセッサのそれに比べてかなり簡略化することができる。したがって、従来のハードウェア・マイクロプロセッサ内で実施するには複雑すぎる事象を、単一の命令でトリガすることができる。さらに、ＶＩＰ用の命令は、様々な数のオペランドを有することが可能であり、これはハードウェア・マイクロプロセッサの場合よりもはるかに多いことを意味する。物理レジスタの限定セットを使用するように設計された離散的な数値演算を使用して、数式をデータ移動命令のシーケンスに分ける必要がない。その代わりに、式は画像メソッド１１５ａ内に直接表され、ＶＩＰによって解釈される。割当て式は、逆ポーランド記法（ＲＰＮ）の式が後に続くターゲット・レジスタとして表すことができる。したがって演算子を、機械命令としてではなく式の構成要素として、画像メソッド１１５ａに直接コード化することができる。タイプのキャストおよび自動変換を管理する規則は、どんな式でも暗黙的にすることができる。
【００３９】
この実施形態では、以下のような７つのプログラム制御命令および５つのデータ操作命令が企図される。

【００４０】
プログラム制御命令は、プログラム実行フローを管理するのに使用される。従来のマイクロプロセッサとは異なり、多数の条件付き分岐命令はない。また、（Ｃプログラミング言語の切り換えステートメントに対応する）インデックス付きジャンプの直接サポートがある。ターゲット・アドレス・サイズは、メソッド１１５ａ全体のサイズに応じて変化する。
【００４１】
データ移動命令は、実際に画像の変換および処理作業を実行するものである。一実施形態では、数値演算または論理演算が各命令に関連付けられたオペランド・リスト内に埋め込まれているので、これらを直接実施する命令はない。また、従来のマイクロプロセッサとは異なり、命令に関するオペランド・リストは数の異なるオペランドを有することができる。
【００４２】
プッシュ命令は、１つのデータ変数をデータ・スタックの上にプッシュする。データ・スタックがプログラム・フロー制御スタックとは異なることに留意されたい。プッシュ命令は、個々のプリミティブ・データ・タイプをデータ・スタックの上にプッシュするためにのみ使用できる。すなわち、アレイ全体をスタックの上にプッシュするのには使用できない。プッシュ命令のフォーマットは演算コードであり、その後に、スタック上にプッシュするデータを表すデータ変数のインデックスが続く。データ変数のタイプおよびサイズは、オペランドにコード化される。
【００４３】
ポップ命令は、データ・スタックから１つのデータ変数をポップする。関連付けられたデータ変数は、以前にスタック上にプッシュされたデータと同じタイプのものである必要はない。変数タイプがスタックの一番上にある既存のデータ・タイプと一致しないと、メソッド１１５ａを定義するのに使用される、より高水準なプログラミング言語のタイプ・キャストを管理するのと同じ規則に従って、自動タイプ・キャストが実行される。
【００４４】
移動命令は、データをソースから宛先に転送し、任意選択で、ソース内でコード化された式を評価する。すなわち、ソースは単一の変数である必要はなく、逆ポーランド記法（ＲＰＮ）を使用してコード化された任意の複雑な式であってよい。
【００４５】
作成命令は、新しいデータ変数を動的に作成し、その変数に参照を割り当てる。作成された変数は、単一のプリミティブ・データ・タイプまたはプリミティブ・データ変数のアレイであってよい。破棄命令は、作成命令によってデータ変数に割り振られたメモリを解除する。メソッド１１５ａを定義するのに使用される、より高水準なプログラミング言語用のコンパイラは、メソッド１１５ａのサブプログラムで使用される自動変数用の動的メモリを管理するために、作成命令および破棄命令を使用することができる。これは、自動変数を作成するスタックを使用するＣプログラミング言語での通常の実施とは異なる。ＶＩＰは物理マイクロプロセッサとしての実施を意図するものではないので、ハードウェア・スタックのどんな必然の結果である必要もない。
【００４６】
ＶＩＰ高水準言語
ＶＩＰの命令セットは画像プロセッサの仮想実装用に最適化されるため、ＶＩＰ用アセンブリなどの低水準プログラミング言語は、マイクロプロセッサ用の従来のアセンブリ言語のものとほとんど似ていない場合がある。前述の撮像に合わせた最適化には固有の制限があるため、メソッド１１５ａの定義に使用するＣまたはＣ＋＋などの高水準言語のフル・バージョンを実施するには実用的でない場合もある。したがって、適切な兼ね合いは、Ｃ言語のサブセットであってよい。このようなＣのサブセットを使用してＶＩＰ用に作成されたプログラムには、リンク・ステップがないことがある。むしろ、単一ファイルとして、または一連の組込みファイル（最終的には単一のファイル）としてコンパイルされることになる。
【００４７】
宣言
許容されるデータ・タイプは、上記で論じた命令セットで使用されるものである。ポインタは定義済みのタイプを指す（すなわち無効なポインタはない）。ポインタを指すポインタは許容されるが、多くとも２方向である。多次元アレイは、従来のＣと同じであると宣言される。ｔｙｐｅｄｅｆ宣言子およびｓｔｒｕｃｔ宣言子は予想されたとおりに挙動する。ｓｔｒｕｃｔなどの複雑なデータ・タイプは、アレイ以内の要素として使用することができる。ビット・フィールドなどの従来の関数の中には、ＶＩＰ実施形態の状況においては本質的に無意味なものがあるので、簡略化のためにビット・フィールドは許容されない。
【００４８】
タイプ・クォリファイアー
ＶＩＰではｃｏｎｓｔタイプ・クォリファイアーが許容されているが、変数はＶＩＰプログラムの範囲外にあるどんなプロセス（たとえばメソッド１１５ａ）にも見えるものではないので、揮発性クォリファイアーには意味がない。ｓｔｒｕｃｔなどの複雑なデータ・タイプを処理する技法はメソッド１１５ａでは提供されないが、コンパイル済みのＶＩＰコードの構造定義から推断される。これはＶＩＰと従来のマイクロプロセッサとの間の主要な相違点である。たとえば、次のようになる。
ｓｔｒｕｃｔ
｛
ｄｏｕｂｌｅｒｅａｌ＿ｐａｒｔ；
ｄｏｕｂｌｅｉｍａｇｉｎａｒｙ＿ｐａｒｔ；
｝ｃｏｍｐｌｅｘ［１０］；
ｓｈｏｒｔｉｎｄｅｘ＝１；
ｃｏｍｐｌｅｘ［ｉｎｄｅｘ］．ｒｅａｌ＿ｐａｒｔ＝０．０；
【００４９】
従来のコンパイラでは、上記のコード・セグメントに示された割当てステートメントは、その構成部分のその基本アドレスからの知られた変位に基づいて、構造フィールドのアドレスを計算するために、一連の命令に分割される。ただしＶＩＰでは、あらゆるデータ項目に一意のＩＤ番号が割り当てられるので、線形アドレス・スペースの直接的な必然の結果はない。データ項目は、メモリ内で連続していても連続していなくてもよい。ＶＩＰは、複雑なデータ・タイプ参照を、所望の変数を一意に区別する単一のＩＤ番号に分解する。ＶＩＰは、ＩＤ番号とアレイ・インデックスとを区別することができるので、あいまいさはない。前述の例は、各構造に２つのデータ項目が含まれる構造アレイである。これをコンパイルすると、次のように表される。
ｄｏｕｂｌｅｒｅａｌ＿ｐａｒｔ［１０］；
ｄｏｕｂｌｅｉｍａｇｉｎａｒｙ＿ｐａｒｔ［１０］；
その結果、次のような等価の割当てステートメントになる。
ｒｅａｌ＿ｐａｒｔ［ｉｎｄｅｘ］＝０．０；
この方法で、コンパイラは、構造定義および参照を、ＶＩＰが使用する記憶スキームに適合するプリミティブ・タイプに分割することができる。
【００５０】
記憶クラス
上記で論じたように、複雑なデータ・タイプの構造は実行可能コードというよりはデータ内で搬送され、データ・アクセスはアドレス計算によってではなく参照によって分解される。ＶＩＰ実施形態ではこれについて、画像データ１１４ａを受け取るための入力データ・バッファと、変換された画像データを保持する出力データ・バッファという、２つの例外がある。これらはバイトの連続したアレイであって、そのサイズは、ソース・ファイルがメソッド１１５ａにコンパイルされるときに定義される。これらは、標準Ｃには含まれていない記憶クラスによって、他の記憶タイプと区別される。
【００５１】
１つの入力バッファおよび１つの出力バッファがある。入力記憶クラスで宣言された任意の変数が、入力バッファを指す。出力記憶クラスで宣言された任意の変数が、出力バッファを指す。これら記憶クラスの１つで定義されたすべてのタイプが、それぞれのメモリ・アレイに、その始まりを基準にしてマッピングされる。メソッド１１５ａにＶＩＰの制御が与えられる前に、ｉｎｐｕｔ＿ｓｉｚｅおよびｏｕｔｐｕｔ＿ｓｉｚｅという２つの特別な変数がローダによって設定される。これらは、それぞれのバッファのバイト長さを定義し、メソッド１１５ａでこれらを第１に宣言せずに使用することができる（定義により有効である）。この点では、ＶＩＰに対しては無効な（目的にかなわない）標準Ｃで定義されるａｒｇｃ変数およびａｒｇｖ変数と同様である。これらの記憶クラスおよび特別変数を使用して、プログラマはどんなデータ・タイプでも入力バッファまたは出力バッファにマッピングすることができる。たとえば次のようになる。
ｉｎｐｕｔｕｎｓｉｇｎｅｄｉｎｔｅｇｅｒｒａｗ＿ｄａｔａ［ｉｎｐｕｔ＿ｓｉｚｅ／４］；
／／画像データ１１４ａからの生画像全体を表す整数配列を宣言する
ｉｎｐｕｔｆｌｏａｔｒａｗ＿ｆｄａｔａ［ｉｎｐｕｔ＿ｓｉｚｅ／４］；
／／画像データ１１４ａからの生画像全体を表すフロート配列を宣言する
変数ｒａｗ＿ｄａｔａ［ｎ］およびｒａｗ＿ｆｄａｔａ［ｎ］は同じデータを指すが、異なるタイプとして解釈される。
【００５２】
単一のメソッド１１５ａは、入力バッファおよび出力バッファならびに各画像のサイズ変数をローダに初期設定させることによって、サイズの異なる複数の画像を処理することができる。撮像装置１０４ａは共通フォーマットで画像を生成するので、最も単純で利用可能な画像メソッドは、入力バッファを出力バッファに直接コピーすることであろう。たとえば次のようになる。
ｍａｉｎ（）
｛
ｉｎｐｕｔｂｙｔｅｒａｗ［ｉｎｐｕｔ＿ｓｉｚｅ］；
ｏｕｔｐｕｔｂｙｔｅｆｉｎｉｓｈｅｄ［ｏｕｔｐｕｔ＿ｓｉｚｅ］；
ｆｉｎｉｓｈｅｄ＝ｒａｗ；
｝
【００５３】
割当てステートメントの、Ｃ＋＋クラスの割当て構文との類似性に留意されたい。これは暗黙の並列処理を可能にする、標準Ｃ構文からの偏位である。
【００５４】
アレイ
割当てステートメントまたは明示的インデックスのない式で使用されるアレイ・タイプは、演算がアレイ全体に適用され、アレイの要素間にはデータ依存関係がないことを暗示するものである。以下のコード断片化を考えてみる。
ｓｈｏｒｔｘ［２５６］；
ｓｈｏｒｔｙ［２５６］；
ｘ＝ｙ^*１．４１４；
これは、ｙアレイ内のあらゆる要素に定数１．４１４を掛け、その結果をｘアレイ内の対応する要素に割り当てるものである。アレイ・サイズが一致しない場合、演算は小さい方のアレイ内にある要素の数だけ繰り返される。これが暗示することは、可能であれば演算および割当てが並列で実行できるということである。このステートメントが暗示する特別のインデックス付け順序はない。等価の記数法は、次のようになる。
ｘ［］＝ｙ［］^*１．４１４；
これにより、多次元アレイを、所望であれば単一次元用に並列に処理することができる。たとえば次のようになる。
ｃｏｎｓｔｓｈｏｒｔｃｏｌｕｍｎ＝６４０；
ｃｏｎｓｔｓｈｏｒｔｒｏｗ＝４８０；
ｕｎｓｉｇｎｅｄｂｙｔｅｉｍａｇｅ［ｃｏｌｕｍｎ］［ｒｏｗ］；
ｉｍａｇｅ［］［１２］＝２５５；
【００５５】
このコード断片化は、画像アレイの行１２内にあるすべての要素に値２５５を割り当てるものである。このタイプの高水準コードを従来のマイクロプロセッサ用にコンパイルするとき、コンパイラは、ステートメント内にある暗黙のループ演算を明示的に実行するために、機械命令シーケンスを生成することがある。ただしＶＩＰコンパイラは、暗黙のループ演算および任意の必要な関連するパラメータを単に記録し、ＶＩＰそれ自体は、必要なインデックス反復を推断する。これにより、性能を犠牲にしてメソッド１１５ａに格納されるコードのサイズが減少する。このような兼ね合いは、ＶＩＰがインストールされているホスト・システム１０２の性能が、必要な機能を許容可能な速度で実行するのに十分な場合に許容される。
【００５６】
以上、本発明の様々な実施形態を、画像オブジェクトの概念を使用して静止画像データの移植性を改善する技法として述べてきた。ただし、記述された画像オブジェクトおよびアブストラクト・マシン技法は、一定タイプのオーディオまたはビデオなどの、コヒーレントであり制限がある他のタイプのデータにも適用可能であることが予想されよう。このような場合、画像メソッドは、オーディオ／ビデオ・シーケンスの圧縮および圧縮解除に典型的に使用される、オーディオ／ビデオ・コーデックに置き換えることができる。
【００５７】
上記に記載された本発明の実施形態は、もちろん構造および実施における他の変形形態の対象となるものである。たとえば、図１では、各撮像装置または記憶装置内に単一オブジェクトを例示しているが、これは本発明が所与の実施形態でどのように動作するかを簡単に説明する目的でのみ例示したものである。実際、当分野の通常の技術者であれば、各装置によって生成された複数の画像を表すために、各装置によって複数のオブジェクトが作成され、必要に応じてホスト・システムに転送できることを理解されよう。また、図３および４のコンピューティング・アーキテクチャについて、画像の取り込みおよび画像オブジェクトの形成を達成する多くの他の代替実施形態が可能である。したがって、本発明の範囲は、例示された実施形態によるのではなく、添付の請求項およびその法的な等価物によって決定されるものとする。
【図面の簡単な説明】
【図１】本発明の一実施形態に従った撮像システムのシステム全体図である。
【図２】本発明の他の実施形態に従い、デジタル画像の移植性を改善するために実行されるステップを示す図である。
【図３】本発明の他の実施形態に従って構成されたソフトウェアおよびハードウェアを含んでいる、ホスト処理システムを示す図である。
【図４】本発明の他の実施形態に従って構成されたソフトウェアおよびハードウェアの要素を含んでいる、撮像装置の一部を示す図である。

Claims

第１のメソッドに関連付けられた第１の画像データを有する第１オブジェクトを、第１の撮像装置から仮想マシンを有する処理システムに転送するステップと、
前記仮想マシンが、第１の画像データに基づいた第１の変換済み画像データを生成する第１のメソッドを実行するステップと、
第２のメソッドに関連付けられており、第１の画像データとは異なるフォーマットである第２の画像データを有する第２オブジェクトを、第２の撮像装置から処理システムに転送するステップと、
前記仮想マシンが、第２の画像データに基づいた第２の変換済み画像データを生成する第２のメソッドを実行するステップと
を含み、前記第１と第２の変換済み画像データが同じ共通のフォーマットであることを特徴とする方法。
プロセッサと、このプロセッサに結合されるとともに命令を記憶したメモリとを有し、
この命令を前記プロセッサが実行したときに、該プロセッサに、
画像データと対応するメソッドをそれぞれ有する第１および第２のオブジェクトであって、それらのオブジェクトの画像データが異なるフォーマットである第１および第２のオブジェクトを、それぞれ第１および第２の撮像装置から受け取るためのシステムを構成させることと、
仮想マシンが、画像データに基づいて共通フォーマットの変換済み画像データを得るために、前記各オブジェクトの対応するメソッドを実行させること
とを行わせる、データ処理システム。
前記共通フォーマットが事前定義されていることを特徴とする請求項１に記載の方法。
前記共通フォーマットを多数のファイル・フォーマットの一つに変換するステップを、さらに含む請求項１に記載の方法。
前記多数のファイル・フォーマットの一つがＪＰＥＧ、ＧＩＦまたはＴＩＦＦフォーマットである請求項４に記載の方法。