(57)【特許請求の範囲】
【請求項１】
少なくとも１つのデジタル画像を含む電子ファイルを符号化する方法であって、
複数のブール演算を表すための式であって前記デジタル画像を読み取るのに必要な機能についての複数の条件を示す式を決定する工程と、
前記電子ファイル内の所定の領域に前記式を加える工程と
を備えることを特徴とする方法。
【請求項２】
前記複数のブール演算を表すための式は、少なくとも１つのビット単位のＡＮＤ演算子を含むことを特徴とする請求項１記載の方法。
【請求項３】
前記複数のブール演算を表すための式は、ビット単位のＡＮＤ演算子により区切られた一連のビット単位のＯＲ演算子を含むことを特徴とする請求項１記載の方法。
【請求項４】
前記複数のブール演算を表すための式は符号化されて、少なくとも１つの識別フラグとともに、前記所定の領域に加えられることを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記識別フラグは、列挙型の値又はユニバーサルユニークＩＤ（Universal Unique Identifier）を指定することを特徴とする請求項４記載の方法。
【請求項６】
前記列挙型の値の第１ビットは、前記識別フラグがユニバーサルユニークＩＤ（Universal Unique Identifier）を指定することを示すために使用されることを特徴とする請求項５記載の方法。
【請求項７】
少なくとも１つのデジタル画像を含む電子ファイルを符号化するための装置であって、
複数のブール演算を表すための式であって前記デジタル画像データを読み取るのに必要な機能についての複数の条件を示す式を受信する手段と、
前記電子ファイル内の所定の領域に前記式を加えるための手段と
を備えることを特徴とする装置。
【請求項８】
前記複数のブール演算を表すための式は、少なくとも１つのビット単位のＡＮＤ演算子を含むことを特徴とする請求項７記載の装置。
【請求項９】
前記複数のブール演算を表すための式は、ビット単位のＡＮＤ演算子により区切られた一連のビット単位のＯＲ演算子を含むことを特徴とする請求項７記載の装置。
【請求項１０】
前記複数のブール演算を表すための式は符号化されて、少なくとも１つの識別フラグとともに、前記所定の領域に加えられることを特徴とする請求項７乃至９のいずれか１項に記載の装置。
【請求項１１】
前記識別フラグは、列挙型の値又はユニバーサルユニークＩＤ（Universal Unique Identifier）を指定することを特徴とする請求項１０記載の装置。
【請求項１２】
前記列挙型の値の第１ビットは、前記識別フラグがユニバーサルユニークＩＤ（Universal Unique Identifier）を指定することを示すために使用されることを特徴とする請求項１１記載の装置。
【請求項１３】
少なくとも１つのコンピュータプラットフォームでのインタラクティブ動作に適合する複数のソフトウェアモジュールを具備し、少なくとも１つのデジタル画像を含む電子ファイルを符号化するのに適したプログラムを記録したコンピュータ可読な媒体であって、
前記プログラムは、
複数のブール演算を表すための式であって前記デジタル画像データを読み取るのに必要な機能についての複数の条件を示す式を決定するためのコードと、
前記電子ファイル内の所定の領域に前記式を加えるためのコードと
を備えることを特徴とするコンピュータ可読な媒体。
【請求項１４】
前記複数のブール演算を表すための式は、少なくとも１つのビット単位のＡＮＤ演算子を含むことを特徴とする請求項１３記載のコンピュータ可読な媒体。
【請求項１５】
前記複数のブール演算を表すための式は、ビット単位のＡＮＤ演算子により区切られた一連のビット単位のＯＲ演算子を含むことを特徴とする請求項１３記載のコンピュータ可読な媒体。
【請求項１６】
前記複数のブール演算を表すための式は符号化されて、少なくとも１つの識別フラグとともに、前記所定の領域に加えられることを特徴とする請求項１３乃至１５のいずれか１項に記載のコンピュータ可読な媒体。
【請求項１７】
前記識別フラグは、列挙型の値又はユニバーサルユニークＩＤ（Universal Unique Identifier）を指定することを特徴とする請求項１６記載のコンピュータ可読な媒体。
【請求項１８】
前記列挙型の値の第１ビットは、前記識別フラグがユニバーサルユニークＩＤ（Universal Unique Identifier）を指定することを示すために使用されることを特徴とする請求項１７記載のコンピュータ可読な媒体。
【請求項１９】
デジタル画像データと、
複数のブール演算を表す式と、を備え、
前記複数のブール演算を表す式は、前記デジタル画像データを読み取るのに必要な機能についての複数の条件が定義されていることを特徴とする電子ファイル。
【発明の詳細な説明】
【０００１】
発明の技術分野
本発明はファイル形式の設定に関し、特に、ファイル形式データをファイル中に提供することで、ファイル中のデータの読み取り可否を読み取りプログラム自体が判定可能となる、電子ファイルの符号化／復号化方法及び装置に関する。
【０００２】
背景技術
コンピュータネットワークシステムを介して配信するためのデータ、及び／又は特定のコンピュータに格納するためのデータを含む様々な種類のファイルを識別する方法として、種々の方法が知られている。特定のファイルを識別するのに使用される方法は、通常、ファイルと関連付けられたファイル拡張子により識別することができる。Joint Photographics Expert Group（ＪＰＥＧ）規格及びTagged Image File（ＴＩＦ）規格は、画像ファイルを識別するのにそれぞれファイル拡張子「．ｊｐｇ」及び「．ｔｉｆ」を使用する。別の周知の方法では、Ｍａｃｉｎｔｏｓｈ（登録商標）のリソースフォークと呼ばれるファイル内の情報を使用する。この情報は、ファイルを識別するバイナリデータである。
【０００３】
前述の方法には、幾つかの欠点がある。例えば、一部のコンピュータネットワークシステムにより使用されるファイル拡張子が、別のシステムでは無視され、ファイル間での非互換性につながることもある。
【０００４】
また、同じものとして識別されたファイルが実際は異なった構成である場合も多い。例えば、ＪＰＥＧ規格及びＴＩＦ規格では種々のオプションが認められているが、これらのオプションに全てのファイル読み取りプログラムが対応している訳ではない。更に、個々のコンピュータネットワークシステムは、ある特定のファイルをどのアプリケーションが読み取るべきであるかを識別によって判定するが、選択されたアプリケーションには特有のオプションを含むファイルを読み取る機能がないことも多い。
【０００５】
コンピュータネットワークシステムの中には、ファイルを構成するのに使用するコンポーネントを迅速に識別できるように、種々の索引を使用してファイルに索引付けしようと試みるものもある。このような種々の索引は汎用のものではなく、一部のアプリケーションでは動作しても、その他のアプリケーションでは使用できない。また、索引は常にファイルの先頭に格納されるとは限らないので、効率的に読み取ることはできない。更に、ファイル形式の新規バージョンが作成されると索引も変更されるので、汎用的に互換性のある索引システムは実現されない。
【０００６】
ファイル形式の中には、１つのファイル内に複数部のデータのコピーを格納することが可能なものもある。このとき、各ファイルは別々の形式で構成される。このようなファイル形式により、ファイルの読み取りを行なうコンピュータネットワークシステムは、環境、ファイル読み取りプログラムの機能、及び、ユーザのニーズに応じてどのデータを読み取るべきかを決定することができる。かかるファイル形式を使用するシステムは、ファイルの種々のコンポーネントを列挙するが、コンポーネントのどの組み合わせがファイルを読み取るのに必要とされるかに関する詳細を記載することはない。
【０００７】
電子メール（Ｅメール）メッセージの内容としてデータを転送できるようにするために使用されるある周知のシステムである、Multipurpose Internet Messaging Extensions（ＭＩＭＥ）システムと呼ばれるシステムは、ファイルの識別にファイルラッパを利用する。また、ＭＩＭＥシステムは、ファイルを全体として識別し、ファイル内で使用されるオプション項目は識別しない。
【０００８】
マルチレイヤ（マルチページ）画像は、１組の画像として考えることが可能である。全ての画像は、通常同じサイズであるが、必ずしも同サイズである必要はなく、表示を目的として結合されたものである。このため、多重画像（レイヤ）ファイル形式は、１つのファイル中の複数の画像を指し、ファイル中の各画像はレイヤと呼ばれる。デコーダがマルチレイヤファイルの各レイヤを結合するのに使用するデータは、必然的に、ファイル形式拡張機能の形態を取る。
【０００９】
Graphics Interchange Format（ＧＩＦ）規格によると、例えば、グラフィクス制御拡張機能と呼ばれる付加的な制御構造が、各画像レイヤの前に位置する情報の一部（すなわち、オーバヘッド情報）としてファイル中に含まれる。この情報は、特に、グローバルファイルヘッダで定義される画像領域全体に対するレイヤの左上の座標と、レイヤを表示してからファイルの次のレイヤを表示するまでの時間とを含む。また、ＧＩＦは、順次合成される複数のレイヤ（すなわち、複数の画像）を含む。
【００１０】
ＧＩＦファイルの各レイヤは異なるサイズであっても良く、レイヤ間の変化を含む領域が少数のみである場合に、格納効率を向上させるためにオフセット座標を使用して位置決めされても良い。ＧＩＦ規格は、各レイヤが合成される仮想画面を定義する。ＧＩＦ規格は、制御ブロック構造を使用して、ファイル中の各レイヤがどのように表示されるのかを示す。制御ブロックは、ファイル形式の各レイヤの前に位置する。この制御ブロックは、仮想画面の左上の位置に関する情報と、ファイルの次のレイヤへと進むまでレイヤが表示されるべき時間の長さについての情報と、ファイルの次のレイヤの表示に先立ってレイヤが除去されるべきか否かについての情報とを含む。
【００１１】
ＧＩＦは、簡易で限定的な設計構造を有するので、多くの開発者にとってＧＩＦ画像を扱うことが可能なファイルビューワを実現するのは容易である。しかし、ＧＩＦの簡易性は、コーディングの際の効率を代価として得られるものである。例えば、ＧＩＦファイル中の各レイヤは１つの画像に対応するので、スプライト及びオーバレイは効率的にコーディングされない。これは、各フレームが個別の画像レイヤとして存在しなければならないからである。画像シーケンスの工程を通して再利用される画像は、画像が出現するフレームごとにファイル中に格納しておく必要がある。
【００１２】
ごく最近では、以上のような問題に対処する試みとして、「多重画像」ファイル形式が開発されてきている。多重画像ファイル形式は、単一ファイル中の多重画像から構成され、ファイル中の各画像は、少なくとも１枚のレイヤと関連付けられている。ある周知の多重画像（レイヤ）ファイル形式では、Portable Network Graphics（ＰＮＧ）ファイル形式への拡張機能に基づいて画像フレームワークを定義する。しかし、多重画像ファイル形式の符号化／復号化を効率的に行うために、ある特定のファイル中のレイヤごとに記述情報が必要となる。
【００１３】
発明の概要
本発明の目的は、既存の構成の１つ以上の欠点をほぼ克服、あるいは、少なくとも改善することである。
【００１４】
本発明の第１の面によると、
少なくとも１つのデジタル画像を含む電子ファイルを符号化する方法であって、
複数のブール演算を表すための式であって前記デジタル画像を読み取るのに必要な機能についての複数の条件を示す式を決定する工程と、
前記電子ファイル内の所定の領域に前記式を加える工程と
を備えることを特徴とする方法が提供される。
【００１５】
上記方法において、前記複数のブール演算を表すための式は、少なくとも１つのビット単位のＡＮＤ演算子を含むことを特徴とする。
【００１６】
上記方法において、前記複数のブール演算を表すための式は、ビット単位のＡＮＤ演算子により区切られた一連のビット単位のＯＲ演算子を含むことを特徴とする。
【００１７】
上記方法において、前記複数のブール演算を表すための式は符号化されて、少なくとも１つの識別フラグとともに、前記所定の領域に加えられることを特徴とする。
【００１８】
上記方法において、前記識別フラグは、列挙型の値又はユニバーサルユニークＩＤ（Universal Unique Identifier）を指定することを特徴とする。
【００１９】
上記方法において、前記列挙型の値の第１ビットは、前記識別フラグがユニバーサルユニークＩＤ（Universal Unique Identifier）を指定することを示すために使用されることを特徴とする。
【００２０】
本発明の別の面によると、
少なくとも１つのデジタル画像を含む電子ファイルを符号化するための装置であって、
複数のブール演算を表すための式であって前記デジタル画像データを読み取るのに必要な機能についての複数の条件を示す式を受信する手段と、
前記電子ファイル内の所定の領域に前記式を加えるための手段と
を備えることを特徴とする装置が提供される。
【００２１】
上記装置において、前記複数のブール演算を表すための式は、少なくとも１つのビット単位のＡＮＤ演算子を含むことを特徴とする。
【００２２】
上記装置において、前記複数のブール演算を表すための式は、ビット単位のＡＮＤ演算子により区切られた一連のビット単位のＯＲ演算子を含むことを特徴とする。
【００２３】
上記装置において、前記複数のブール演算を表すための式は符号化されて、少なくとも１つの識別フラグとともに、前記所定の領域に加えられることを特徴とする。
【００２４】
上記装置において、前記識別フラグは、列挙型の値又はユニバーサルユニークＩＤ（Universal Unique Identifier）を指定することを特徴とする。
【００２５】
上記装置において、前記列挙型の値の第１ビットは、前記識別フラグがユニバーサルユニークＩＤ（Universal Unique Identifier）を指定することを示すために使用されることを特徴とする。
【００２６】
本発明の更に別の面によると、
少なくとも１つのコンピュータプラットフォームでのインタラクティブ動作に適合する複数のソフトウェアモジュールを具備し、少なくとも１つのデジタル画像を含む電子ファイルを符号化するのに適したプログラムを記録したコンピュータ可読な媒体であって、
前記プログラムは、
複数のブール演算を表すための式であって前記デジタル画像データを読み取るのに必要な機能についての複数の条件を示す式を決定するためのコードと、
前記電子ファイル内の所定の領域に前記式を加えるためのコードと
を備えることを特徴とするコンピュータ可読な媒体が提供される。
【００２７】
上記媒体において、前記複数のブール演算を表すための式は、少なくとも１つのビット単位のＡＮＤ演算子を含むことを特徴とする。
【００２８】
上記媒体において、前記複数のブール演算を表すための式は、ビット単位のＡＮＤ演算子により区切られた一連のビット単位のＯＲ演算子を含むことを特徴とする。
【００２９】
上記媒体において、前記複数のブール演算を表すための式は符号化されて、少なくとも１つの識別フラグとともに、前記所定の領域に加えられることを特徴とする。
【００３０】
上記媒体において、前記識別フラグは、列挙型の値又はユニバーサルユニークＩＤ（Universal Unique Identifier）を指定することを特徴とする。
【００３１】
上記媒体において、前記列挙型の値の第１ビットは、前記識別フラグがユニバーサルユニークＩＤ（Universal Unique Identifier）を指定することを示すために使用されることを特徴とする。
【００３２】
本発明の更に別の面によると、
デジタル画像データと、
複数のブール演算を表す式と、を備え、
前記複数のブール演算を表す式は、前記デジタル画像データを読み取るのに必要な機能についての複数の条件が定義されていることを特徴とする電子ファイルが提供される。
【００３４】
発明の実施の形態
最良の形態を含む詳細な説明
添付のいずれか１つ以上の図面において、同じ符号を有するステップ及び／又は特徴に言及する場合、特に明記されていない限り、以下の記述においては、これらのステップ及び／又は特徴は、同じ機能又は動作を有するものとする。
【００３５】
画像データは、通常、２次元配列の値として表され、各値は表示画面上のレンダリング対象画素に対する各属性を表す。属性は、グレースケール画像の場合の画像の当該画素の輝度を表してもよいし、あるいは、当該画素の１つの色成分の輝度を表しても良い。カラー画像は、通常、幾つかの成分、すなわち、色成分（例えば、赤、緑及び青）、輝度成分、及び、場合によっては不透明度などの補助成分を有する。従って、画像データの表現は、使用されるカラーモデルへの依存度が高い。
【００３６】
画像は、通常、符号化されてビットストリームを形成する。通常、これらのビットストリームの１つ以上を関連するオーバーヘッド情報と結合させることでコードストリームを形成することができる。コードストリームは、画像を格納及び／又は伝送するのに使用されることとなる。関連するオーバーヘッド情報は、読み取りプログラムが、ビットストリームを復号化し、それを画像データに展開するのに必要とされる情報である。
【００３７】
ビットストリームを復号化し、画像データに展開するのに必要な機能を指定するのに利用可能な式を以下で説明する。この式は、ビットストリームに対するオーバーヘッド情報に含まれるのが好ましい。カラーモデルを符号化／復号化する種々の方法は複雑であるため、ビットストリームの復号化／展開に必要な機能を指定するには、ビットストリームのオーバーヘッド情報内に可能なオプションのリストを含むだけでは十分ではないであろう。ビットストリームは多様なカラーモデルを含んでも良いが、それに限らず、ビットストリームを符号化する方法は数多くある。同じ画像データを同じファイルに格納する場合でも多様な方法で行なって良い。例えば、動画フレームを含む画像データファイルと、第１のカラーモデルと同様に第１のエンコーダとも互換性がある動画フレームを読み取るデコーダとがあるとすると、そのデコーダが第２のカラーモデルとも互換性がある場合、キーフレームを読み取る際に、デコーダを使用して動画ファイルを理解するが、第１のカラーモデルを理解しない読み取りプログラムにおいては、キーフレームを表示することしかできない。
【００３８】
ファイルを読み取るために必要な機能を指定するために、ファイルに対するオーバーヘッド情報に含むことができる式の一例を以下に示す：
(A OR B) AND (C OR D)                                     （１）
式中、各文字は、必要な機能の各アスペクトを表す。従って、ファイルを読み取るには、読み取りプログラムは、機能Ａ又は機能Ｂに対応すると共に、機能Ｃ及び機能Ｄのいずれかに対応する必要がある。
【００３９】
上述の機能式は、ビットマスクを使用して表されるのが好ましく、互換性ボックスへと符号化される。図１は、ビットマスク及び互換性ボックスを構成するための方法を示すフローチャート２００である。フローチャート２００のプロセスは、第１のステップ２１０で開始され、入力として機能式が受信される。次のステップ２２０において、機能式は、ＡＮＤステートメントで区切られた一連のＯＲ部分式へと展開される。
【００４０】
次のステップ２３０において、マスクテーブルが作成される。テーブルの各列は、必要な機能のアスペクトを表す。ＯＲ部分式は、マスクテーブルの各列に配置される。図２は、式（１）の機能式のためのマスクテーブル３００を示す。マスクテーブル３００は、必要な機能３１０の各アスペクト（すなわち、Ａ、Ｂ、Ｃ及びＤ）を行として有する。マスクテーブル３００の列３２０及び３３０は、それぞれ、ＯＲ部分式のうちの１つを表す。第１のＯＲ部分式（すなわち、A OR B）は、ＯＲ部分式に存在するアスペクトの各々を１のビットで表し、残りを０のビットで表すことによって、列３２０に配置される。ＯＲ部分式（A OR B）にはアスペクトＡ及びＢのみが存在するので、列３２０は、エントリとしてビットストリング「１１００」を有する。同様に、第２のＯＲ部分式（C OR D）は、エントリ「００１１」により列３３０に配置される。
【００４１】
ファイルを読み取るために必要なマスクテーブル３００中の全ての列に対してビット単位のＯＲ演算子を実行した結果を含む必要なマスク列３４０も提供される。図２の例によると、ビット単位のＯＲ演算子が行３１０の各エントリに対して実行され、すなわち、10 OR 10 OR 01 OR 01が実行され、必要なマスクが１１として作成される。
【００４２】
より複雑な機能式の一例を以下に示す：
(A AND B) OR (C AND D)                                    （２）
式（２）は、読み取りプログラムが、機能アスペクトＡ及び機能アスペクトＢに対応するか、あるいは、機能アスペクトＣ及び機能アスペクトＤに対応する必要があることを示す。
【００４３】
式（２）は、指定された形式（すなわち、ＡＮＤステートメントで区切られた一連のＯＲ部分式）ではないので、ステップＳ２２０で展開されて以下の形態が得られる：
(A AND B) OR (C AND D) = (A OR C) AND (A OR D) AND(B OR C) AND (B OR D)          （３）
次のステップ２３０において、図３に示すようにマスク３５０が作成される。マスク３５０のＯＲ部分式の各々が各列に配置される。必要な機能のアスペクトがＯＲ部分式に存在する場合、そのアスペクトは列において１のビットで表される。展開された式には４つのＯＲ部分式があるので、マスク３５０は４つの列を有する。必要なマスクエントリは１１１１である。
【００４４】
フローチャート２００の次のステップ２４０において、ファイルにアクセスするのに必要な機能に関する情報を指定するために、互換性ボックスがマスクテーブルから作成される。この機能は、ベンダ特有であっても、公認の規格によって定義されても良い。互換性ボックスは、ファイルの冒頭付近に配置されるので、読み取りプログラムは、ファイルの解釈が可能であるか否かを迅速に判定することができる。互換性情報によれば、必要な機能からなる簡略化したアスペクトの組を用いて、所定のファイルを解釈するのに適していることを表すことができる。例えば、互換性ボックスの情報によれば、ある静止画読み取りプログラムが、動画ファイルの静止画版を表示するのに適していることを指定することができる。
【００４５】
図４は、互換性ボックス４００に対する好適な形式を示す。互換性ボックス４００は、ＭＬフィールド４１０、ＲＭフィールド４２０、Ｆｌａｇiフィールド、ＥＦiフィールド４４０及びＭＳiフィールドを含む。これらのフィールドは以下のように定義される：
ＭＬ：このフィールドは、互換性マスクに使用されるバイト数を指定する１バイトであり、必要な機能のアスペクトごとのマスクと共に必要なマスクを含む。有効値は、１、２、４及び８である。
【００４６】
ＲＭ：このフィールドは必要なマスクを指定する。
【００４７】
Ｆｌａｇi：このフィールドは、必要な機能の各アスペクトの意味を読み取りプログラムに通知する互換性フラグを提供する。互換性フラグには「標準」フラグと「拡張」フラグの２種類がある。標準フラグを格納するのには１バイトを使用することができ、拡張フラグを指定するのには６４ビットユニバーサルユニークＩＤ（Universal Unique Identifier（ＵＵＩＤ））を使用することができる。Ｆｌａｇiフィールドは、ある標準フラグが必要な機能のアスペクトを表現するのに使用されることを指定する１バイトである。しかし、フィールドの最上位ビットが設定される場合、フィールドの残りは、ＵＵＩＤ拡張フラグの最上位バイトになる。
【００４８】
ＥＦi：これはＵＵＩＤ拡張フラグの下位１５バイトを表すオプションのフィールドである。
【００４９】
ＭＳi：このフィールドは、必要な機能のアスペクトに対するマスクを指定する。
【００５０】
従って、互換性ボックスは以下のようなフィールドを有し、各フィールドは、以下の表１に示すような指定サイズ及び予想値を有する：
【００５１】
【表１】
0003768959.tif 000002
詳細な情報は、ＵＵＩＤに関する更なる情報を指定するＵＲＬにＵＵＩＤをリンクするファイル中で指定することができる。
【００５２】
以下の表（すなわち、表２、表３及び表４）に、好適な互換性フラグを列挙する。表はコードストリームフラグ、カラーフラグ及びメタデータフラグとしてグループ化される。
【００５３】
【表２】
0003768959.tif 000003
【００５４】
【表３】
0003768959.tif 000004
【００５５】
【表４】
0003768959.tif 000005
【００５６】
多くの標準ファイル形式（例えば、ＪＰＥＧ２０００）では、拡張フラグは指定されず、ベンダがＵＵＩＤを使用して独自の互換性フラグを作成するための対応がなされている。例えば、ベンダが独自のベンダ特有のカラーモデルを指定することを希望する場合、そのカラーモデルはＵＵＩＤを使用して識別される。新規のカラーモデルを指定するのに、ファイルを通して１つのＵＵＩＤが使用されるのが好ましい。
【００５７】
例えば、単一の圧縮したコードストリームと限定ＩＣＣプロファイルカラーモデル及びｓＲＧＢカラーモデルと知的財産権情報を含むメタデータとを含むファイルに対する互換性ボックスを、フローチャート２００の方法を使用して以下に示すように構成することができる：
ステップ２１０において、ファイルの互換性情報が式として入力される。前述の情報から、適切な機能式は以下の通りである：
(A AND B AND C AND E) OR (A AND B AND D AND E)          （４）
式中、Ａは単一のコードストリームを表し、Ｂは圧縮方式Ｘのコードストリームを表し、ＣはｓＲＧＢカラーモデルを表し、Ｄは限定ＩＣＣプロファイルを表し、Ｅは知的財産権情報を含むメタデータを表す。
【００５８】
次のステップ２２０において、式（４）の機能式が以下に示すようにＡＮＤステートメントで区切られた一連のＯＲ部分式へと展開される：
A AND B AND (C OR D) AND E                                （５）
次のステップ２３０において、式（５）の機能式のために図５に示すようなマスクテーブル５００が作成される。テーブル５００の各行は、必要な機能のアスペクトを表す。必要な機能のアスペクトは５つあり、それぞれ、Ａ、Ｂ、Ｃ、Ｄ及びＥで表される。ＯＲ部分式は、マスクテーブル５００の各列に配置される。尚、式（５）に対するＯＲ部分式の大半は、実際にはＯＲ演算子を含まず、ＡＮＤ演算子により区切られることで識別される。
【００５９】
必要なマスク列５１０は、全ての行に対してＯＲ演算子を実行した結果を含む。図５の例に従って、ＯＲ演算子は以下に示すように実行される：
0001 OR 0010 OR 0100 OR 0100 OR 1000 = 1111             （６）
次のステップ２４０において、以下に示すように互換性ボックスがマスクテーブル５００から作成される。ＭＬフィールドエントリが１として選択され、１バイトが互換性マスクのために使用できるようになる。ＲＭフィールドエントリは、ＭＬフィールドで指定されたバイト数を埋めるための０ビットを加えた行５１０である。従って、ＲＭフィールドエントリは００００１１１１、すなわち、１０進法での１５である。
【００６０】
次に、互換性フラグ及び各々のマスクを定義することができる。全ての互換性フラグは標準フラグであり、それぞれが１バイトで表される。互換性フラグテーブルから必要な機能の各アスペクトを参照すると、例示した各互換性フラグは以下に示すように指定される：
単一のコードストリーム       ３、
圧縮方式Ｘのコードストリーム     ５、
ｓＲＧＢカラーモデル     １６、
限定ＩＣＣプロファイル     １７、及び
知的財産権情報を含むメタデータ   ６４
標準フラグのみが使用されるので、ＥＦiフィールドは存在しない。最後に、必要な機能のアスペクトごとにマスクＭＳiが判定される。これらのマスクＭＳiは、実質的にはマスクテーブル５００の行であり（必要なマスク行５１０を除く）、ＭＬフィールドで指定されたバイト数を埋めるために０ビットが加えられている。
【００６１】
要約すると、この例での互換性ボックスは、以下に示すように指定される：
ＭＬ＝１
ＲＭ＝００００ １１１１
Ｆｌａｇ1＝３  ＭＳ1＝００００ ０００１
Ｆｌａｇ2＝５  ＭＳ2＝００００ ００１０
Ｆｌａｇ3＝１６ ＭＳ3＝００００ ０１００
Ｆｌａｇ4＝１７ ＭＳ4＝００００ ０１００
Ｆｌａｇ5＝６４ ＭＳ5＝００００ １０００
互換性ボックスは、種々のフィールドを結合することによって、以下に示すように１６進文字列としてファイルのオーバーヘッド情報に含めることができる：
「0x010F03010502100411044008」                             （７）
この例での互換性ボックスは、読み取りプログラムが１つの圧縮方式Ｘのコードストリームを理解しなければならず、ｓＲＧＢカラーモデル及び限定ＩＣＣのいずれかが必要であることを示している。また、互換性ボックスは、ｓＲＧＢカラーモデル及び限定ＩＣＣプロファイルが同一の機能を提供することも示している。
【００６２】
図６は、ファイルが特定の読み取りプログラムと互換性があるか否かを判定する方法を示すフローチャート６００である。ファイルは、互換性ボックスを有し、この互換性ボックスが、先に指定したようなフラグのリスト及びフラグマスクを有する。第１のステップ６１０において、変数ｃｏｍｐａｔが０に設定される。次のステップ６２０において、ファイルの互換性ボックス内に含まれるフラグのリストから次のフラグの値が変数ｆｌａｇに割り当てられる。
【００６３】
フローチャート６００のプロセスは、次のステップ６３０へと進み、読み取りプログラムがフラグ（Ｆｌａｇi）に対応しているか否かが判定される。フラグに対応している場合、フラグと一致する必要な機能のアスペクトに対して、変数ｃｏｍｐａｔとマスクとの間でのビット単位でのＯＲ演算が次のステップ６４０で実行される。例えば、フラグがＦｌａｇ3である場合、ｆｌａｇ＿ｍａｓｋはマスクＭＳ3＝００００ ０１００である。このビット単位でのＯＲ演算の結果が、変数ｃｏｍｐａｔに対する新規の値として割り当てられる。
【００６４】
ステップ６３０において、読み取りプログラムがフラグに対応していない場合、フローチャート６００のプロセスはステップ６５０へと進む。ステップ６５０において、互換性ボックスに記述されたフラグのリストにフラグが残っているか否かが判定される。ステップ６５０においてフラグが残っている場合、プロセスはステップ６２０へと戻り、次のフラグが読み取られる。
【００６５】
これに対し、互換性ボックスに含まれる全てのフラグがステップ６５０で判定された場合、フローチャート６００のプロセスはステップ６８０へと進む。ステップ６８０において、変数ｃｏｍｐａｔと互換性ボックス中の必要なマスクフィールドの値との間でビット単位のＡＮＤ演算が実行される。この演算の結果は、互換性ボックス中の必要なマスクフィールドと比較される。値が一致する場合、ステップ６９０において互換性が報告される。値が一致しない場合、ステップ６９５においてファイルが読み取りプログラムと互換性がないと報告され、ファイルは開かれない。
【００６６】
以上のような方法により、読み取りプログラムは、任意のファイルが読み取り可能であるか否かを判定できるだけでなく、ファイル内の機能のどのアスペクトを読み取るべきかを判定することができるようになる。また、これらの方法により、読み取りプログラムは、今後作成される全ての互換性のあるファイルを理解することができるようになり、今後の読み取りプログラムは互換性のある現ファイルを読み取ることができるようになる。これが可能になるのは、各ファイルが提供する機能を読み取りプログラムが判定するのではなく、ファイル自体がそれを指定するからである。
【００６７】
図８は、本発明の別の面による画像ファイル構造を示す。ファイル８００は、順次パックしてバイナリファイルにした複数の要素８０２から８０８により構成される。ファイルの前部に位置する要素には、ファイル８００に含まれる画像データのパラメータを記述する情報のみならず、ファイルの種類を識別する情報を含むことが可能なヘッダ情報８０２（すなわち、オーバヘッド情報）も含まれる。
【００６８】
ファイル８００は、画像データ８０６から８０８を含む１つ以上の要素の各々に格納される種類及びチャネル情報、すなわち、画像データに対する参照情報を列挙するコードストリームヘッダボックス８０５を含むのが好ましい。コードストリームヘッダボックス８０５については、本明細書でより詳細に後述する。
【００６９】
幾つかの別個の静止画像８０６から８０８をファイルに含むことができる。すなわち、これらをファイル中で参照することができ、各々は前述のようにレイヤとして参照される。これらのレイヤの中には、個別に見ると不完全なものもあるかもしれないが、それは、そのレイヤを表示するためには、ファイルの他の画像レイヤと相互に重ね合わせるからか、あるいは、相互に結合することが意図されているからである。しかし、各レイヤは、単独での復号化が可能な完全なコードストリーム、あるいは１組のコードストリームであり、各レイヤは、ここでの説明の趣旨の範囲内では、それぞれ別個のものであると考えられる。アニメーションは、画像レイヤ８０６から８０８のうちの１枚以上を単独で、あるいは、組み合わせて使用することで実行することができる。この場合、ファイル８００は、アニメーション制御情報を含むアニメーション制御ブロック８０４を具備する。
【００７０】
各画像レイヤ（例えば８０６）は、１つ以上のチャネルを具備する。このチャネルは、ファイル８００中に含まれる１つ以上のコードストリームとして存在することも可能であるが、ファイルによって参照したりすることも、あるいは、ルックアップテーブルを介して画像要素をマッピングすることによって得たりすることもできる。ファイル８００に含まれる各コードストリーム又は参照情報は、１つ以上のファイル要素中に存在する。ヘッダ要素中の情報は、ファイル読み取りプログラムが、完全なコードストリームを復元し、それを画像レイヤへと復号化するのに使用する。例えば、前述のように、ヘッダ要素中の情報は、コードストリームフラグ（コードストリーム索引、コードストリームの数、コードストリームの種類など）、カラーフラグ（ｓＲＧＢ色空間、限定ＩＣＣプロファイル、パレット化カラーなど）及びメタデータフラグ（知的財産権情報、コンテンツ記述、作成情報及び履歴情報など）を含むことが可能である。
【００７１】
各レイヤ（例えば８０６）のチャネルは、画素値のアレイから構成される。これらのチャネルは、ある色空間に特有の色情報のサンプルに対応する。この色空間は、ファイル８００のヘッダ要素８０２内で定義される。１つのチャネルであっても、グレースケール画像におけるように輝度サンプルに対応することが可能である。１つ以上のチャネルは、レイヤ中の他のチャネルをレンダリングする際に使用する不透明度情報のサンプルを含むこともできる。このチャネルは、一般的に、αチャネルと呼ばれる。αチャネルデータは、各サンプルが、完全に透明である場合と完全に不透明である場合と対応する２つの予想値のうちの１つのみをとる２値（すなわち、２レベル）とすることもできる。２値のαデータは、完全に透明な場合に、全ての画素に一意の色を割り当てることによってカラーチャネルで符号化される。
【００７２】
デジタル画像をファイル８００により表される図８によるファイル形式（すなわち、コード化表現）へと符号化する方法を以下で説明する。ファイル８００は、ファイル中に含まれる任意の画像レイヤを表示するのに必要な画面領域を含むがそれに限定されないグローバルパラメータを伴うヘッダ８０２と、コードストリームヘッダボックスとして知られ、コードストリームの種類及びチャネル情報を表すブロック８０５と、任意の適切な方法（例えば、ＲＧＢ、Ｌ＊ａ'ｂ'）を使用して符号化された一連の画像レイヤ８０６から８０８と、を含むファイル又はコードストリーム８００から構成される。
【００７３】
コードストリームヘッダボックス８０５は、ヘッダ８０２に組み込むこともできる。
【００７４】
図１１は、デジタル画像を図８のファイル形式によるコード化表現として符号化する方法を示すフローチャートである。プロセスはステップ１１０１で開始され、ファイル８０２（すなわち、コード化表現）中のデジタル画像（レイヤ）ごとに記述が判定される。次のステップ１１０３において、記述及びデジタル画像は、ビットストリームとして符号化され、記述のうちの少なくとも１つは、複数のデジタル画像と順次関連付けられる。
【００７５】
図８に戻って説明すると、コードストリームヘッダボックス８０５は、ファイル８００の画像レイヤ８０６から８０８の各々に格納される種類及びチャネル情報を列挙する。図８のファイル形式と共に使用するのに適した周知のコードストリームヘッダボックスの１つは、「jcsh」（X'6A637368'）である。
【００７６】
コードストリームヘッダボックス８０５は、図８の展開図に示すように複数のフィールド９０１から９１７を含む。コードストリームヘッダボックス８０５は、画像レイヤ８０６から８０８の各々と関連付けられた各コードストリームのコードストリーム記述から構成される。例えば、レイヤが２つの関連するコードストリームを有する場合、コードストリームヘッダボックス８０５は、その特定のレイヤに対して２つのコードストリーム記述を含むことになる。図８のファイル形式によると、コードストリーム記述は、図８に示すように、フィールド９０５から９１７により構成される。
【００７７】
ＮＬの文字で示されるフィールド９０１は、ファイル中のレイヤの枚数を含む。ＮＣの文字で示されるフィールド９０３は、ファイル中のコードストリームの数を含む。ＣＴiの文字で参照されるフィールド９０５は、現在処理中のコードストリームｉに対するコードストリームの種類を指定する。例えば、コードストリームｉは、Joint Photographics Experts Group（ＪＰＥＧ）規格、Embedded Zerotree Wavelet（ＥＺＷ）圧縮、Set Partitioning in Hierarchical Trees（ＳＰＩＨＴ）アルゴリズム、Scalable Image Compression（スケーラブル画像圧縮）、又は、その他の適切な画像圧縮方法により符号化することができる。ＣＳiの文字で参照されるフィールド９０７は、現在処理中のコードストリームｉのカラー仕様の数を表す。フィールド９０７の値の０は、コードストリームｉに対してカラー仕様が使用されないことを示す。ＰＬＴiの文字で示されるフィールド９０９は、コードストリームｉのパレット数を表す。フィールド９０９の値の０は、コードストリームｉに対してパレットが使用されないことを示す。ＬＹＲiの文字で示されるフィールド９１１は、コードストリームｉが対応するレイヤを指定する。レイヤは、ファイル８００中の第１のレイヤ８０６を表す１から最後のレイヤ８０８を表すｎまででラベル付けされるのが好ましい。ＮＬＣiの文字で示されるフィールド９１３は、コードストリームｉの論理コンポーネントの数を指定する。頭字語ＣＬＴixの文字で示されるフィールド９１５は、ｉ番目のコードストリームのｘ番目の論理コンポーネント中のデータの性質を定義する。フィールド９１５は、４つの値「０、１、２又は３」のうちの１つを有することができる。フィールド９１５の値０から３の各々と関連付けられる意味を以下の表５に示す：
【００７８】
【表５】
0003768959.tif 000006
ＣＬＡixの文字で示されるフィールド９１７は、現在のレイヤのデータが関連付けられるカラーチャネルを表す索引を含む。フィールド９１７は数値であるのが好ましく、ネットワークバイト順を使用して１６ビットの符号ないし整数として符号化されるのが好ましい。フィールド９１７の値はｉ番目のコードストリームのｘ番目の論理コンポーネントを指定の色空間中のチャネルと関連付ける。色空間中のチャネルは、１からｍまでナンバリングされるのが好ましい。ｍは、チャネル数を表す。例えば、カラー仕様がｓＲＧＢの場合、１の値は、コンポーネントを赤色チャネルと関連付ける。更に、特殊値（０）は、コンポーネントを指定の色空間の全てのカラーチャネルと関連付ける。輝度に（０）を使用することにより、コードストリームがグレースケールサンプルを含むことを指定することができる。
【００７９】
フィールド９０１から９１７の各々のサイズ及び各フィールドの設定可能な値を図８のファイル形式に従って以下の表６に示す：
【００８０】
【表６】
0003768959.tif 000007
コードストリームヘッダボックス８０５中の最後のレイヤ記述は、ファイル８００内の残る全てのレイヤを記述するのに使用されるのが好ましい。例えば、ファイル８００が２００枚のレイヤ及び３つのレイヤ記述を含む場合、最初の２つのレイヤ記述は、最初の２枚のレイヤを記述し、第３のレイヤ記述は、ファイル８００中の残る１９８枚のレイヤを記述する。すなわち、最後の未指定のレイヤは、必要に応じて繰り返される。従って、同じ記述を有する複数のレイヤは、１つの記述により表すことが可能であり、各レイヤに対応する記述を有する必要がないので、結果としてより効率的なファイル形式が得られる。更に、ファイル読み取りプログラムが図８のファイル形式に従って符号化されたファイルを処理するのに要する時間が短縮される。
【００８１】
例えば、ファイル８００が以下の表７により定義されるような以下のヘッダ情報を含むと想定する：
【００８２】
【表７】
0003768959.tif 000008
表７において、「ＲＧＢ」は、ＲＧＢ色空間を表し、「Ａ」はアルファチャネルを表す。表７の例によると、コードストリームヘッダボックス８０５は、以下に示す情報を含むであろう。説明の助けとなるように、括弧で囲まれた「レイヤ記述番号」が加えられている：
ＮＬ＝４
ＮＣ＝５
（レイヤ記述１）
ＣＴ1＝ＥＺＷ
ＣＳ1１＝１
ＰＬＴ1１＝０
ＬＹＲ1１＝１
ＮＬＣ1１＝３
ＣＬＴ1１１＝０  ＣＬＴ12＝０ ＣＬＴ13＝０
ＣＬＡ1１１＝１  ＣＬＡ12＝２ ＣＬＡ13＝３
（レイヤ記述２）
ＣＴ2＝ＥＺＷ
ＣＳ2＝１
ＰＬＴ2＝０
ＬＹＲ2＝２
ＮＬＣ2＝３
ＣＬＴ21＝０  ＣＬＴ22＝０ ＣＬＴ23＝０
ＣＬＡ21＝１  ＣＬＡ22＝２ ＣＬＡ23＝３
ＣＴ3＝ＥＺＷ
ＣＳ3＝１
ＰＬＴ3＝０
ＬＹＲ3＝２
ＮＬＣ3＝１
ＣＬＴ31＝１
ＣＬＡ31＝０
（レイヤ記述３）
ＣＴ4＝ＥＺＷ
ＣＳ4＝１
ＰＬＴ4＝０
ＬＹＲ4＝３
ＮＬＣ4＝４
ＣＬＴ41＝０  ＣＬＴ42＝０ ＣＬＴ43＝０ ＣＬＴ44＝１
ＣＬＡ41＝１  ＣＬＡ42＝２ ＣＬＡ43＝３ ＣＬＡ44＝０
尚、レイヤ４は指定されておらず、この例によるとレイヤ３と同じである。更に、表７において明らかなように、レイヤ２が２つのコードストリーム（すなわち、ＲＧＢ及びアルファチャネルＡ）から構成されるとき、レイヤ記述２は、２つのコードストリーム記述を含む。前述の表７の例では、ファイル８００が復号化されるときに、ファイル読み取りプログラムは、レイヤ記述より多い枚数のレイヤが存在する（すなわち、ＮＬ＝４、レイヤ記述＝３）と判定し、レイヤ記述３をレイヤ４（及び残存するレイヤ）の記述に利用するであろう。
【００８３】
本発明の更に別の面によると、ファイル１０００のヘッダ１００２は、少なくともボックス１００１から構成される。図９において明らかなように、ボックス１００１は、ファイル１０００中のレイヤ１００６から１００８の各々に対する定義と共に、レイヤの枚数のみならず表示される画像の幅及び高さも含む。ボックス１００１は、画像サイズ仕様１００３、レイヤ記述（例えば１００５）（すなわち、レイヤ仕様）、コンポーネントマッピング及びコンポーネント変換リストをマージする。これにより、ヘッダ１００２が読み取りやすくなる。ボックス１００１のフィールドは、以下でより詳細に説明する。
【００８４】
図９のファイル形式によると、レイヤ記述（例えば１００５）は、レイヤ記述１００５が適用される連続レイヤの枚数を指定する「繰り返し」フラグ９２５を含む。繰り返しフラグは、好ましくは「０〜６５５３５」の範囲の値を有することができる。繰り返しフラグ９２５の値が「６５５３５」の場合、特定のレイヤ記述がファイル１０００中の残る全てのレイヤに適用されることを示す。繰り返しフラグ９２５により、レイヤの連続グループは同様のレイヤ記述を有することが可能になる。従って、同じ記述を有する複数のレイヤは、１つの記述により表すことが可能になり、結果として、より効率的なファイル形式が得られる。
【００８５】
図９のファイル形式によると、各レイヤ記述（例えば１００５）は、図９の展開図において明らかなように、コードストリーム１００７の数及び関連するコードストリーム記述１００９から構成される。各コードストリームは、圧縮の種類１０１１、カラー仕様１０１３、パレットにより定義されるコンポーネント変換又はマッピング１０１５、及び、１組のコンポーネント定義１０１７（種類の連想対）−コンポーネント当たり１つ−とにより定義される。
【００８６】
図９のファイル形式によると、色空間及びカラーパレットの双方は、ヘッダ１００２において、ヘッダボックス９２１及び９１９とに別々に示されるカラー仕様とパレットの組への索引によって指定される。コンポーネント変換又はパレット参照は、第１のステップとして復号化された画像データに適用されるのが好ましく、結果として生じる画素は、使用中のカラー仕様（例えば、ｓＲＧＢ又は限定ＩＣＣプロファイルにより定義される空間）により定義される色空間に割り当てられる。
【００８７】
１つのレイヤファイルを１つのカラー仕様などと共に処理するときに、図９のヘッダ１００２は、図１０において明らかなように、ヘッダボックス１０１９へと簡略化されるであろう。図１０は、図９のヘッダ１００２により簡略化された全ての付加的な機能に対して、基線シンタックスが複雑でないことを示す。
ヘッダボックス１００１、１０２１中のフィールドは、以下の表８において定義される：
【００８８】
【表８】
0003768959.tif 000009
レイヤ仕様ボックス９２３、１０２３中のフィールドは、以下のように表９において定義される：
【００８９】
【表９】
0003768959.tif 000010
コードストリーム記述１００９は、以下のように表１０において定義される：
【００９０】
【表１０】
0003768959.tif 000011
コンポーネント変換／マッピング仕様１０１５により定義される情報は、以下に示すように表１１、表１２及び表１３において定義される：
【００９１】
【表１１】
0003768959.tif 000012
【００９２】
【表１２】
0003768959.tif 000013
【００９３】
【表１３】
0003768959.tif 000014
図１２は、１つ以上の画像を図８及び図９のファイル形式（すなわち、コード化表現）へと符号化する方法を示すフローチャートである。プロセスはステップ１２０１で開始され、必要なレイヤの枚数が判定される。次のステップ１２０３において、各レイヤに対して使用される符号化の種類及び各レイヤにおけるコードストリームの数に応じて、レイヤごとにレイヤ記述が判定される。プロセスは、次のステップ１２０５へと進む。ステップ１２０５において、レイヤ記述は比較され、同様の記述を有するレイヤの枚数が判定される。次のステップ１２０７において、レイヤの表示の順序が判定される。プロセスは次のステップ１２０９で終結する。ステップ１２０９において、記述及びレイヤは好適なファイル形式のうちのいずれか１つへと符号化されるか、あるいは、ビットストリームとして符号化される。これにより、同様のレイヤ記述のうちの少なくとも１つが好適なファイル形式に含まれる。更に、同様のレイヤ記述を有するこれらのレイヤは、特定のファイルの終わりに順次配置される。
【００９４】
ここで説明される方法は、Joint Photographics Experts Group（ＪＰＥＧ）規格内の特定のアプリケーションを有する。特に、ＪＰＥＧ２０００パート１規格は、ファイルが準拠する規格内でその規格又はプロファイルを記述する４バイトコードのリストを含むプロファイルボックスを定義する。しかし、ここで説明される方法により処理されるＪＰＥＧ２０００パート１規格に関してはいくつもの制限がある。まず、個別の互換性を記述するのに同じ４バイトコードが使用されていないことを確実にするために、ＪＰＥＧ２０００パート１規格用のコードが、中央の管轄官庁により提供されなければならない。個別のベンダにより生成することが可能なＵＵＩＤを使用する際に、ここで説明される方法は、個別の互換性を記述するのに一意的なコードが使用されることを確実にする。
【００９５】
第２に、ＪＰＥＧ２０００パート１規格は、コードストリームにとってどの機能グループが必須であり、どの機能グループがオプションであるのかに関して示さずに、機能のグループを列挙している。例えば、ＪＰＥＧ２０００パート２規格コードストリームと結合された複雑なカラー定義が、特定のコードストリーム伝送にとって必要であることを定義する方法はない。ここで説明される方法により、機能のグループを定義することができる。
【００９６】
第３に、規格又は規格内のプロファイルへの参照は、特定の機能を定義するには粗雑すぎる。また、このような参照は２つの異なる規格間でのオーバラップを許容しない。例えば、ＪＰＥＧ２０００ファイルは、限定ＩＣＣプロファイルを使用する。ここで説明される方法は、１つの機能の指定を可能にするので、ファイル形式を理解し、限定ＩＣＣプロファイルを読み取ることが可能なものであれば、ここで説明される方法に従って形式設定されたファイルを読み取ることができる。
【００９７】
第４に、ファイルが１つのＪＰＥＧ２０００パート１規格コードストリーム、ヘッダ及びカラー仕様を含む場合、前述のようにファイルを記述することによって、ＪＰＥＧ２０００と互換性のある読み取りプログラムは、ファイルがＪＰＥＧ２０００準拠であることを指定する必要なしに、ファイルを読み取ることができる。
【００９８】
第５に、特定のファイルが複数のプロファイルを指定し、特定の機能を指定しない場合、読み取りプログラムは、今後のファイルを読み取ることができない可能性がある。読み取りプログラムは、今後のプロファイルを理解しなくても、前述のようにプロファイルにより提供される特定の機能を理解すれば、ファイルを読み取ることが可能である。
【００９９】
前述の互換性ボックス内の各特徴は、ＪＰＥＧ２０００ファイルを通して使用することができる。ＪＰＥＧ２０００ファイル中の他の場所で参照される特徴は、列挙された値又はＵＵＩＤを使用して同様に識別することができる。例えば、ｓＲＧＢ（値１６を使用して定義）は、カラー仕様内で使用することが可能であり、互換性ボックス内の同じ値を有するのが好ましい。
【０１００】
加えて、ＪＰＥＧ２０００規格で使用される現在のＵＵＩＤリストボックスは、ＵＵＩＤに関するより多くの情報を指定するためにリンクとして使用されるＵＲＬを指定する。ＪＰＥＧ２０００パート１規格によると、これらのＵＲＬは、ＵＵＩＤボックスを定義するのに使用される。ＵＵＩＤリストボックスは、前述の互換性ボックス中の機能を記述するのに使用されるＵＵＩＤを定義するのにも使用することができる。
【０１０１】
以上の方法は、図７に示すような従来の汎用コンピュータシステム７００を使用して実施されるのが好ましい。図１から図６及び図８から図１１のプロセスは、コンピュータシステム７００内で実行されるアプリケーションプログラムなどのソフトウェアとして実現されても良い。特に前述の方法は、コンピュータにより実行されるソフトウェア中の命令により実施される。ソフトウェアは、前述の方法を実行する部分と、後者とユーザとの間のユーザインタフェースを管理する部分との２つの別々の部分に分割されても良い。ソフトウェアは、例えば、後述する記憶装置を含むコンピュータ可読な媒体に格納されても良い。ソフトウェアは、コンピュータ可読な媒体からコンピュータにロードされ、そのコンピュータにより実行される。このようなソフトウェア又はそのソフトウェアに記録されるコンピュータプログラムを有するコンピュータ可読な媒体は、コンピュータプログラム製品である。コンピュータにおいてコンピュータプログラム製品を使用することにより、本発明の各実施形態に従ってデジタル画像を符号化するのに有利な装置を実現するのが好ましい。
【０１０２】
コンピュータシステム７００は、コンピュータモジュール７０１と、キーボード７０２及びマウス７０３などの入力装置と、プリンタ７１５及び表示装置７１４を含む出力装置とを具備する。例えば、電話回線７２１又はその他の機能媒体を介して接続可能な通信ネットワーク７２０と通信するために、コンピュータモジュール７０１は、変復調（モデム）送受信機７１６を使用する。モデム７１６は、インターネット及び構内通信網（ＬＡＮ）又は広域通信網（ＷＡＮ）などのその他のネットワークシステムへのアクセス権を取得するのに使用することができる。
【０１０３】
コンピュータモジュール７０１は、通常、少なくとも１つのプロセッサ装置７０５と、例えば、半導体ランダムアクセスメモリ（ＲＡＭ）及び読出し専用メモリ（ＲＯＭ）から構成されるメモリ装置７０６と、ビデオインタフェース７０７、キーボード７０２及びマウス７０３及びオプションとしてのジョイスティック（不図示）用のＩ／Ｏインタフェース７１３、及び、モデム７１６用のインタフェース７０８を含むＩ／Ｏインタフェースとを含む。記憶装置７０９が設けられ、この記憶装置は、通常、ハードディスクドライブ７１０及びフロッピーディスクドライブ７１１を含む。磁気テープドライブ（不図示）を使用しても良い。データの不揮発性ソースとしては、通常、ＣＤ−ＲＯＭドライブ７１２が設けられる。コンピュータモジュール７０１の構成要素７０５から７１３は、通常、相互接続バス７０４を介して通信を行ない、当業者に周知のコンピュータシステム７００の従来の動作モードと結果的に同じ様式で通信を行なう。実施形態を実施することが可能なコンピュータの例としてIntelプロセッサベースのＰＣ及び互換機、Sun Sparcstation又はそれより進化した同様のコンピュータシステムが挙げられる。
【０１０４】
通常、好適な実施形態のアプリケーションプログラムは、ハードディスクドライブ７１０に常駐しており、実行時にプロセッサ７０５により読み出され、制御される。プログラムの中間記憶装置及びネットワーク７２０からフェッチしたいかなるデータも半導体メモリ７０６を用いて、あるいはハードディスクドライブ７１０と共に用いて達成してもよい。幾つかの例においては、アプリケーションプログラムは、ＣＤ−ＲＯＭ又はフロッピーディスク上で符号化した状態でユーザに供給し、対応するドライブ７１２又は７１１を介して読み出すか、あるいはモデム装置７１６を介してユーザがネットワーク７２０から読み出してもよい。更に、ソフトウェアは、磁気テープと、ＲＯＭ又は集積回路と、光磁気ディスクと、コンピュータモジュール７０１と別の装置との間の無線又は赤外線の伝送チャネルと、ＰＣＭＣＩＡカードなどのコンピュータ可読なカードと、電子メール伝送及びウェブサイト上などで記録された情報を含むインターネット及びイントラネットとを含むその他のコンピュータ可読な媒体からコンピュータシステム７００にロードすることも可能である。これまでの説明は、関連するコンピュータ可読な媒体の単なる例示である。その他のコンピュータ可読な媒体も、本発明の趣旨から逸脱することなく実施することができる。
【０１０５】
また、以上のような方法は、その機能又は下位の機能を実行する１つ以上の集積回路などの専用のハードウェアで実現されても良い。このような専用のハードウェアは、グラフィックプロセッサ、デジタル信号プロセッサ、又は、１つ以上のマイクロプロセッサ及び関連メモリを含んでも良い。
【０１０６】
産業上の利用可能性
以上の説明から、本発明の実施形態は、コンピュータ産業、及びデータ処理産業に適用可能であり、特に、これらの産業の各部門に適用可能である。また、本発明の実施形態は、広告産業及び娯楽産業にも適用可能である。
【０１０７】
以上、本発明の実施形態の幾つかのみを説明したが、本発明の趣旨から逸脱することなく、変形及び／又は変更を行なっても良い。実施形態は、例示のためのものであり、本発明を限定するものではない。
【図面の簡単な説明】
【図１】  ビットマスク及び互換性ボックスを構成する方法を示すフローチャートである。
【図２】  機能式の例のためのマスクテーブルを示す図である。
【図３】  機能式の更なる例のための別のマスクテーブルを示す図である。
【図４】  互換性ボックスの好適な形式を示す図である。
【図５】  機能式の更に別の例のためのマスクテーブルを示す図である。
【図６】  ファイルが読み取りプログラムと互換性があるか否かを判定するための方法を示すフローチャートである。
【図７】  前述の構成が実施されるであろうコンピュータシステムの概略ブロック図である。
【図８】  画像ファイル構造を示す図である。
【図９】  更なる画像ファイル構造を示す図である。
【図１０】  １つのカラー仕様を伴う１つのレイヤファイルが処理されているときの図９の画像ファイル構造を示す図である。
【図１１】  図８のファイル形式に従ってデジタル画像をコード化表現に符号化する方法を示すフローチャートである。
【図１２】  図８及び図９のファイル形式に従って１つ以上の画像を符号化する方法を示すフローチャートである。
【図１】
0003768959.tif 000015
【図２】
0003768959.tif 000016
【図３】
0003768959.tif 000017
【図４】
0003768959.tif 000018
【図５】
0003768959.tif 000019
【図６】
0003768959.tif 000020
【図７】
0003768959.tif 000021
【図８】
0003768959.tif 000022
【図９】
0003768959.tif 000023
【図１０】
0003768959.tif 000024
【図１１】
0003768959.tif 000025
【図１２】
0003768959.tif 000026