(57)【特許請求の範囲】
【請求項１】
共有または参照をＢＯＸ情報に定義する符号フォーマットの入力符号ストリームを変換対象ファイルとして取り込み、この入力符号ストリームをそれと同様な内容を持つ、よりコンパクトなファイルサイズの出力符号ストリームへ変換する符号変換装置であって、前記変換のために、
前記入力符号ストリームからＢＯＸ情報を切り出すＢＯＸ分解手段と、
前記ＢＯＸ分解手段により切り出されたＢＯＸ情報に関し共有処理又は参照処理をするべきか判断する共有／参照判断手段と、
前記ＢＯＸ分解手段により切り出されたＢＯＸ情報に関し、前記共有／参照判断手段による判断の結果に従って必要な共有又は参照のための処理を行う共有／参照処理手段と、
を有し、
前記共有／参照処理手段は、部分符号を参照するときに参照される側の符号の論理的なまとまりの単位に参照単位を指定できる、
ことを特徴とする符号変換装置。
【請求項２】
前記変換対象ファイル以外のローカル・ファイル又はリモート・ファイルの内容も前記変換において参照又は共有の対象とする、
ことを特徴とする請求項１記載の符号変換装置。
【請求項３】
前記変換において共有又は参照されるＢＯＸ情報の指定又は非指定のための指示をユーザが入力する手段をさらに有する、
ことを特徴とする請求項１又は２記載の符号変換装置。
【請求項４】
前記変換の内容を示すステータスレポートを生成する手段をさらに含む、
ことを特徴とする請求項１又は２記載の符号変換装置。
【請求項５】
前記ステータスレポートに前記変換により共有又は参照されたオブジェクト毎に前記変換の内容が示される、
ことを特徴とする請求項４記載の符号変換装置。
【請求項６】
前記ステータスレポートに前記変換により削減されたサイズが含まれる、
ことを特徴とする請求項４記載の符号変換装置。
【請求項７】
前記変換において参照されるリモート・ファイルの範囲をユーザが指定する手段をさらに有する、
ことを特徴とする請求項２記載の符号変換装置。
【請求項８】
前記変換において参照されるリモート・ファイルの範囲がホップ数で指定される、
ことを特徴とする請求項７記載の符号変換装置。
【請求項９】
前記変換において参照されるリモート・ファイルの範囲がドメイン名又はそのリストで指定される、
ことを特徴とする請求項７記載の符号変換装置。
【請求項１０】
前記変換において参照されるリモート・ファイルの範囲がワークグループ名又はそのリストで指定される、
ことを特徴とする請求項７記載の符号変換装置。
【請求項１１】
前記変換において参照処理によりページサムネイルが統一される、
ことを特徴とする請求項１又は２記載の符号変換装置。
【請求項１２】
前記変換においてページサムネイルがないページについて他のページのページサムネイルが参照される、
ことを特徴とする請求項１１記載の符号変換装置。
【請求項１３】
前記変換において参照処理によりドキュメントサムネイルが統一される、
ことを特徴とする請求項１１記載の符号変換装置。
【請求項１４】
前記変換対象ファイルはＩＳＯ１５４４４−２に準拠したファイルである、
ことを特徴とする請求項１又は２記載の符号変換装置。
【請求項１５】
前記変換対象ファイルはＩＳＯ１５４４４−３に準拠したファイルである、
ことを特徴とする請求項１又は２記載の符号変換装置。
【請求項１６】
前記変換対象ファイルはＩＳＯ１５４４４−６に準拠したファイルである、
ことを特徴とする請求項１又は２記載の符号変換装置。
【請求項１７】
前記変換対象ファイルはＰＤＦ仕様に準拠したファイルである、
ことを特徴とする請求項１又は２記載の符号変換装置。
【請求項１８】
前記共有／参照処理手段による前記参照単位を解像度ごとに設定できる、
ことを特徴とする請求項１記載の符号変換装置。
【請求項１９】
前記共有／参照処理手段による前記参照単位を色成分ごとに設定できる、
ことを特徴とする請求項１記載の符号変換装置。
【請求項２０】
前記共有／参照処理手段による前記参照単位を位置ごとに設定できる、
ことを特徴とする請求項１記載の符号変換装置。
【請求項２１】
前記共有／参照処理手段による前記参照単位を画質ごとに設定できる、
ことを特徴とする請求項１記載の符号変換装置。
【請求項２２】
前記共有／参照処理手段による前記参照単位をプレシンクトごとに設定できる、
ことを特徴とする請求項１９記載の符号変換装置。
【請求項２３】
前記共有／参照処理手段による前記参照単位をタイルごとに設定できる、
ことを特徴とする請求項１９記載の符号変換装置。
【請求項２４】
前記ステータスレポートとして作成中／審査中／承認済みを示すように参照単位を変化させる、
ことを特徴とする請求項４記載の符号変換装置。
【請求項２５】
前記ステータスレポートとして作成中／編集中／削除済みを示すように参照単位を変化させる、
ことを特徴とする請求項４記載の符号変換装置。
【請求項２６】
共有または参照をＢＯＸ情報に定義する符号フォーマットの入力符号ストリームをそれと同様な内容を持つ、よりコンパクトなファイルサイズの出力符号ストリームへ変換する符号変換方法であって、前記変換のために、
前記入力符号ストリームからＢＯＸ情報を切り出すＢＯＸ分解工程と、
前記ＢＯＸ分解工程により切り出されたＢＯＸ情報に関し共有処理又は参照処理をするべきか判断する共有／参照判断工程と、
前記ＢＯＸ分解工程により切り出されたＢＯＸ情報に関し、前記共有／参照判断工程による判断結果に従って必要な共有又は参照のための処理を行う共有／参照処理工程と、
を有し、
前記共有／参照処理工程は、部分符号を参照するときに参照される側の符号の論理的なまとまりの単位に参照単位を指定できる、
ことを特徴とする符号変換方法。
【請求項２７】
共有または参照をＢＯＸ情報に定義する符号フォーマットの入力符号ストリームをそれと同様な内容を持つ、よりコンパクトなファイルサイズの出力符号ストリームへ変換するために、コンピュータに、
前記入力符号ストリームからＢＯＸ情報を切り出すＢＯＸ分解工程と、
前記ＢＯＸ分解工程により切り出されたＢＯＸ情報に関し共有処理又は参照処理をするべきか判断する共有／参照判断工程と、
前記ＢＯＸ分解工程により切り出されたＢＯＸ情報に関し、前記共有／参照判断工程による判断結果に従って必要な共有又は参照のための処理を行う共有／参照処理工程と、
を実行させ、
前記共有／参照処理工程は、部分符号を参照するときに参照される側の符号の論理的なまとまりの単位に参照単位を指定できる、
ことを特徴とするプログラム。
【請求項２８】
請求項２７記載のプログラムが記録されていることを特徴とするコンピュータが読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、符号変換装置、符号変換方法、プログラム及び記録媒体に関する。
【背景技術】
【０００２】
記憶メディア上の複数のファイルの共通部分と非共通部分を分別し、共通部分についてのファイル共通化情報と非共通部分を各ファイル毎に記憶させ、共通部分は複数のファイルで共有化させる発明が特許文献１に記載されている。
【０００３】
上述したような特許文献１に開示された技術は、概略的には、冗長度圧縮を行うものではなく、ＢＯＸ構造を持つ符号フォーマットの特性を利用してファイルの可逆圧縮を実現しようとするものである。
【０００４】
このようなＢＯＸ構造を持つ符号フォーマットとしては、ＢＯＸ情報に共有／参照が定義されていないもの（例えば非特許文献１参照）、ＢＯＸ情報に共有／参照が定義されているもの（例えば非特許文献２，３参照）がある。ここでＢＯＸとは、ファイル中でカプセル化されているバイナリ構造をもったオブジェクトである。本発明の対象となる符号フォーマットは、後者のＢＯＸ情報に共有／参照が定義された符号フォーマットである。
【０００５】
ここで、図２２は非特許文献１に記載されたＪＰＥＧのシンタックスを示すものである。図２２に示すように、“ENTROPY-CODED  SEGMENT  0”３０、“ENTROPY-CODED  SEGMENT  LAST”３１がそれぞれ“リスタート間隔終端シンボルＲＳＴ”３２で同期をはかって１つの“SCAN1”３３を構成し、これらのＳＣＡＮの集合体として“Frame”３４が構成され、“ＳＯＩマーカ”３５、“ＥＯＩマーカ”３６でカプセル化して符号フォーマットを構成している。しかしながら、この符号フォーマットの中では、１つのファイル中に同じ内容の“ENTROPY-CODED  SEGMENT”が複数存在しても、それらを共有したり参照するメカニズムは非特許文献１では全く定義されていない。
【０００６】
図２３は、非特許文献２で開示されているＪＰＭ（JPEG2000  Multi  Page）ファイルの概念的構造を示している。非特許文献２では、図２３に示した“Contiguous  Codestream  Box”３７、“Metadata  Boxes”３８等のＢｏｘの共有／参照が定義されている。
【０００７】
【特許文献１】特開２０００−２９３４１３号公報
【非特許文献１】Annex  B  （P31-49），“INFORMATION  TECHNOLOGY-DIGITAL  COMPRESSION  AND  CODINGOF  CONTINUOUS-TONE  STILL  IMAGES−REQUIREMENTS  AND  GUIDELINES，TEMINAL  EQUIPMENT  AND  PROTOCOLS  FOR  TELEMATIC  SERVICES,THE  INTERNATIONAL  TELEGRAPH  AND  TELEPHONE  CONSULTATIVE  COMITTEE”Recommendation  T.81，1992年9月，INTERNATIONAL  TELECOMMUNICATION  UNION
【非特許文献２】5.2.7  Shared  Data，“Information  technology−JPEG2000  Image  Coding  System−Part6：Compound  Image  File  Fomrmat，JPEG2000  Part６  FDIS”,  9  DECEMBER  2002，ISO/IEC  15444-6
【非特許文献３】5.2.7  Shared  Data，“Information  technology-JPEG2000  Image  Coding  System−Part2：Extentions，JPEG2000  Part2  FDIS”,  8  AUGUST  2001，ISO/IEC  15444-2
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ところで、文書の同じページに同じ画像を異なったサイズで複数箇所に配置したり、文書の複数のページにわたって共通のロゴマーク等を印刷したりする場合がある。このような共通したロゴマーク等の画像は、文書のファイル全体で１つのコードストリームを共有／参照するならば、ファイルをよりコンパクトにすることができる。大量のマニュアルを複数の担当者で分担作成する場合には、ロゴマークの色相などが担当セクション（ページ）毎に微妙に異なってしまうことがあるが、文書のファイル全体で１つのロゴマークのコードストリームを共有／参照するならば、ファイルをコンパクトにできるのみならず、ロゴマークの色相などが均一になり文書の見栄えの面で有利である。
【０００９】
しかしながら、このような共通したロゴマーク等のオブジェクトを共有／参照するために、人手でロゴマーク等のバイナリデータを検索し、その共有／参照の操作を行うことは現実的ではない。
【００１０】
本発明は、上記に鑑みてなされたものであって、ＢＯＸ情報の共有／参照が定義された符号フォーマットの特性に着目し、文書の同一ページ上あるいは複数のページにわたって共通するロゴマーク等のオブジェクトの共有／参照を自動的に行うことができ、さらには、類似の符号を同じ値で代表させ、それを共有／参照するように文書全体を整列させる操作をも自動的に行うことができる新規な符号変換装置及び符号変換方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述した課題を解決し、目的を達成するために、請求項１にかかる発明は、共有または参照をＢＯＸ情報に定義する符号フォーマットの入力符号ストリームを変換対象ファイルとして取り込み、この入力符号ストリームをそれと同様な内容を持つ、よりコンパクトなファイルサイズの出力符号ストリームへ変換する符号変換装置であって、前記変換のために、入力符号ストリームからＢＯＸ情報を切り出すＢＯＸ分解手段と、前記ＢＯＸ分解手段により切り出されたＢＯＸ情報に関し共有処理又は参照処理をするべきか判断する共有／参照判断手段と、前記ＢＯＸ分解手段により切り出されたＢＯＸ情報に関し、前記共有／参照判断手段による判断の結果に従って必要な共有又は参照のための処理を行う共有／参照処理手段と、を有し、前記共有／参照処理手段は、部分符号を参照するときに参照される側の符号の論理的なまとまりの単位に参照単位を指定できる。
【００１２】
また、請求項２にかかる発明は、請求項１の発明に係る符号変換装置において、前記変換対象ファイル以外のローカル・ファイル又はリモート・ファイルの内容も参照又は共有の対象とする。
【００１３】
また、請求項３にかかる発明は、請求項１又は２記載の符号変換装置において、前記変換において共有又は参照されるＢＯＸ情報の指定又は非指定のための指示をユーザが入力する手段をさらに有する。
【００１４】
また、請求項４にかかる発明は、請求項１又は２記載の符号変換装置において、前記変換の内容を示すステータスレポートを生成する手段をさらに含む。
【００１５】
また、請求項５にかかる発明は、請求項４記載の符号変換装置において、前記ステータスレポートに前記変換により共有又は参照されたオブジェクト毎に前記変換の内容が示される。
【００１６】
また、請求項６にかかる発明は、請求項４記載の符号変換装置において、前記ステータスレポートに前記変換により削減されたサイズが含まれる。
【００１７】
また、請求項７にかかる発明は、請求項２記載の符号変換装置において、前記変換において参照されるリモート・ファイルの範囲をユーザが指定する手段をさらに有する。
【００１８】
また、請求項８にかかる発明は、請求項７記載の符号変換装置において、前記変換において参照されるリモート・ファイルの範囲がホップ数で指定される。
【００１９】
また、請求項９にかかる発明は、請求項７記載の符号変換装置において、前記変換において参照されるリモート・ファイルの範囲がドメイン名又はそのリストで指定される。
【００２０】
また、請求項１０にかかる発明は、請求項７記載の符号変換装置において、前記変換において参照されるリモート・ファイルの範囲がワークグループ名又はそのリストで指定される。
【００２１】
また、請求項１１にかかる発明は、請求項１又は２記載の符号変換装置において、前記変換において参照処理によりページサムネイルが統一される。
【００２２】
また、請求項１２にかかる発明は、請求項１１記載の符号変換装置において、前記変換においてページサムネイルがないページについて他のページのページサムネイルが参照される。
【００２３】
また、請求項１３にかかる発明は、請求項１１記載の符号変換装置において、前記変換において参照処理によりドキュメントサムネイルが統一される。
【００２４】
また、請求項１４にかかる発明は、請求項１又は２記載の符号変換装置において、前記変換対象ファイルはＩＳ１５４４４−２に準拠したファイルである。
【００２５】
また、請求項１５にかかる発明は、請求項１又は２記載の符号変換装置において、前記変換対象ファイルはＩＳ１５４４４−３に準拠したファイルである。
【００２６】
また、請求項１６にかかる発明は、請求項１又は２記載の符号変換装置において、前記変換対象ファイルはＩＳ１５４４４−６に準拠したファイルである。
【００２７】
また、請求項１７にかかる発明は、請求項１又は２記載の符号変換装置において、前記変換対象ファイルはＰＤＦ仕様に準拠したファイルである。
【００２８】
また、請求項１８にかかる発明は、請求項１記載の符号変換装置において、前記共有／参照処理手段による前記参照単位を解像度ごとに設定できる。
【００２９】
また、請求項１９にかかる発明は、請求項１記載の符号変換装置において、前記共有／参照処理手段による前記参照単位を色成分ごとに設定できる。
【００３０】
また、請求項２０にかかる発明は、請求項１記載の符号変換装置において、前記共有／参照処理手段による前記参照単位を位置ごとに設定できる。
【００３１】
また、請求項２１にかかる発明は、請求項１記載の符号変換装置において、前記共有／参照処理手段による前記参照単位を画質ごとに設定できる。
【００３２】
また、請求項２２にかかる発明は、請求項１９記載の符号変換装置において、前記共有／参照処理手段による前記参照単位をプレシンクトごとに設定できる。
【００３３】
また、請求項２３にかかる発明は、請求項１９記載の符号変換装置において、前記共有／参照処理手段による前記参照単位をタイルごとに設定できる。
【００３４】
また、請求項２４にかかる発明は、請求項４記載の符号変換装置において、前記ステータスレポートとして作成中／審査中／承認済みを示すように参照単位を変化させる。
【００３５】
また、請求項２５にかかる発明は、請求項４記載の符号変換装置において、前記ステータスレポートとして作成中／編集中／削除済みを示すように参照単位を変化させる。
【００３６】
また、請求項２６にかかる発明は、共有または参照をＢＯＸ情報に定義する符号フォーマットの入力符号ストリームをそれと同様な内容を持つ、よりコンパクトなファイルサイズの出力符号ストリームへ変換する符号変換方法であって、前記変換のために、前記入力符号ストリームからＢＯＸ情報を切り出すＢＯＸ分解工程と、前記ＢＯＸ分解工程により切り出されたＢＯＸ情報に関し共有処理又は参照処理をするべきか判断する共有／参照判断工程と、前記ＢＯＸ分解工程により切り出されたＢＯＸ情報に関し、前記共有／参照判断工程による判断結果に従って必要な共有又は参照のための処理を行う共有／参照処理工程と、を有し、前記共有／参照処理工程は、部分符号を参照するときに参照される側の符号の論理的なまとまりの単位に参照単位を指定できる。
【００３７】
また、請求項２７にかかる発明のプログラムは、共有または参照をＢＯＸ情報に定義する符号フォーマットの入力符号ストリームをそれと同様な内容を持つ、よりコンパクトなファイルサイズの出力符号ストリームへ変換するために、コンピュータに、前記入力符号ストリームからＢＯＸ情報を切り出すＢＯＸ分解工程と、前記ＢＯＸ分解工程により切り出されたＢＯＸ情報に関し共有処理又は参照処理をするべきか判断する共有／参照判断工程と、前記ＢＯＸ分解工程により切り出されたＢＯＸ情報に関し、前記共有／参照判断工程による判断結果に従って必要な共有又は参照のための処理を行う共有／参照処理工程と、を実行させ、前記共有／参照処理工程は、部分符号を参照するときに参照される側の符号の論理的なまとまりの単位に参照単位を指定できる。
【００３８】
また、請求項２８にかかる発明のコンピュータが読み取り可能な記録媒体は、請求項２７記載のプログラムが記録されている。
【発明の効果】
【００３９】
請求項１にかかる発明によれば、ファイルの冗長な内容に対する共有／参照処理を符号の論理的なまとまりの単位である参照単位で行うことによって、ファイルの内容の同一性を保ったままファイルサイズを変換前より縮小させることができる、という効果を奏する。
【００４０】
また、請求項２にかかる発明によれば、変換対象ファイル以外のローカル・ファイル又はリモート・ファイルの内容についても共有／参照処理を行ってファイルサイズを縮小させることができる、という効果を奏する。
【００４１】
また、請求項３にかかる発明によれば、ファイル内で参照する画像に対する符号を明示的に示すことができるという効果を奏する。
【００４２】
また、請求項４にかかる発明によれば、ユーザは、ステータスレポートによって、変換の内容を容易に確認することができる、という効果を奏する。
【００４３】
また、請求項５にかかる発明によれば、ユーザは、ステータスレポートによって、変換において共有又は参照の対象となったオブジェクトの対応関係を容易に確認することができる、という効果を奏する。
【００４４】
また、請求項６にかかる発明によれば、ユーザは、ステータスレポートによって、変換によるサイズ削減効果を容易に確認することができる、という効果を奏する。
【００４５】
また、請求項７にかかる発明によれば、ユーザ側で、参照されるリモート・ファイルの範囲を明確にすることができるため、共有／参照の範囲とその効果の関係を的確に管理することができる、という効果を奏する。
【００４６】
また、請求項８にかかる発明によれば、ユーザ側で、参照されるリモート・ファイルの範囲を明確にすることができるため、共有／参照の範囲とその効果の関係を的確に管理することができる、という効果を奏する。
【００４７】
また、請求項９にかかる発明によれば、ユーザ側で、参照されるリモート・ファイルの範囲を明確にすることができるため、共有／参照の範囲とその効果の関係を的確に管理することができる、という効果を奏する。
【００４８】
また、請求項１０にかかる発明によれば、ユーザ側で、参照されるリモート・ファイルの範囲を明確にすることができるため、共有／参照の範囲とその効果の関係を的確に管理することができる、という効果を奏する。
【００４９】
また、請求項１１にかかる発明によれば、変換によって、ファイルサイズの削減と同時に、ページサムネイル又はドキュメントサムネイルを統一して文書の体裁を整えることができる、という効果を奏する。
【００５０】
また、請求項１２にかかる発明によれば、変換によって、ファイルサイズの削減と同時に、ページサムネイル又はドキュメントサムネイルを統一して文書の体裁を整えることができる、という効果を奏する。
【００５１】
また、請求項１３にかかる発明によれば、変換によって、ファイルサイズの削減と同時に、ページサムネイル又はドキュメントサムネイルを統一して文書の体裁を整えることができる、という効果を奏する。
【００５２】
また、請求項１４にかかる発明によれば、国際標準互換又はＰＤＦ互換を保ちつつファイルの可逆再圧縮が可能となる、という効果を奏する。
【００５３】
また、請求項１５にかかる発明によれば、国際標準互換又はＰＤＦ互換を保ちつつファイルの可逆再圧縮が可能となる、という効果を奏する。
【００５４】
また、請求項１６にかかる発明によれば、国際標準互換又はＰＤＦ互換を保ちつつファイルの可逆再圧縮が可能となる、という効果を奏する。
【００５５】
また、請求項１７にかかる発明によれば、国際標準互換又はＰＤＦ互換を保ちつつファイルの可逆再圧縮が可能となる、という効果を奏する。
【００５６】
また、請求項２６にかかる発明によれば、ファイルの冗長な内容に対する共有／参照処理を符号の論理的なまとまりの単位である参照単位で行うことによって、ファイルの内容の同一性を保ったままファイルサイズを変換前より縮小させることができる、という効果を奏する。
【００５７】
また、請求項２７にかかる発明によれば、コンピュータにプログラムをロードすることにより、請求項２６の発明を容易に実施することができる、という効果を奏する。
【００５８】
また、請求項２８にかかる発明によれば、コンピュータにプログラムをロードすることにより、請求項２６の発明を容易に実施することができる、という効果を奏する。
【発明を実施するための最良の形態】
【００５９】
最初に、本発明の前提となる「階層符号化アルゴリズム」及び「離散ウェーブレット変換に基づく符号化・復号化アルゴリズム」の概要について説明する。なお、「離散ウェーブレット変換に基づく符号化・復号化アルゴリズム」の代表例が「JPEG2000アルゴリズム」である。
【００６０】
図１は、離散ウェーブレット変換に基づく符号化方式の基本となる階層符号化アルゴリズムを実現するシステムの機能ブロック図である。このシステムは、画像圧縮手段として機能するものであって、色空間変換・逆変換部１０１、２次元ウェーブレット変換・逆変換部１０２、量子化・逆量子化部１０３、エントロピー符号化・復号化部１０４、タグ処理部１０５の各機能ブロックにより構成されている。
【００６１】
このシステムが従来のＪＰＥＧアルゴリズムと比較して最も大きく異なる点の一つは変換方式である。ＪＰＥＧでは離散コサイン変換（ＤＣＴ：Discrete Cosine Transform）を用いているのに対し、この階層符号化アルゴリズムでは、２次元ウェーブレット変換・逆変換部１０２において、離散ウェーブレット変換（ＤＷＴ：Discrete Wavelet Transform）を用いている。ＤＷＴはＤＣＴに比べて、高圧縮領域における画質が良いという長所を有し、この点が、ＪＰＥＧの後継アルゴリズムであるＪＰＥＧ２０００でＤＷＴが採用された大きな理由の一つとなっている。
【００６２】
また、他の大きな相違点は、この階層符号化アルゴリズムでは、システムの最終段に符号形成を行うために、タグ処理部１０５の機能ブロックが追加されていることである。このタグ処理部１０５で、画像の圧縮動作時には圧縮データが符号列データとして生成され、伸長動作時には伸長に必要な符号列データの解釈が行われる。そして、符号列データによって、ＪＰＥＧ２０００は様々な便利な機能を実現できるようになった。例えば、ブロック・ベースでのＤＷＴにおけるオクターブ分割に対応した任意の階層（デコンポジションレベル）で、静止画像の圧縮伸長動作を自由に停止させることができるようになる（後述する図３参照）。また、一つのファイルから低解像度画像（縮小画像）を取り出したり、画像の一部（タイリング画像）を取り出すことができるようになる。
【００６３】
原画像の入出力部分には、色空間変換・逆変換部１０１が接続される場合が多い。例えば、原色系のＲ（赤）／Ｇ（緑）／Ｂ（青）の各コンポーネントからなるＲＧＢ表色系や、補色系のＹ（黄）／Ｍ（マゼンタ）／Ｃ（シアン）の各コンポーネントからなるＹＭＣ表色系から、ＹＵＶあるいはＹＣｂＣｒ表色系への変換又は逆変換を行う部分がこれに相当する。
【００６４】
次に、ＪＰＥＧ２０００アルゴリズムについて説明する。カラー画像は、一般に、図２に示すように、原画像の各コンポーネント１１１（ここではＲＧＢ原色系）が、矩形をした領域によって分割される。この分割された矩形領域は、一般にブロックあるいはタイルと呼ばれているものであるが、ＪＰＥＧ２０００では、タイルと呼ぶことが一般的であるため、以下、このような分割された矩形領域をタイルと記述することにする（図２の例では、各コンポーネント１１１が縦横４×４、合計１６個の矩形のタイル１１２に分割されている）。このような個々のタイル１１２（図２の例で、Ｒ００，Ｒ０１，…，Ｒ１５／Ｇ００，Ｇ０１，…，Ｇ１５／Ｂ００，Ｂ０１，…，Ｂ１５）が、画像データの圧縮伸長プロセスを実行する際の基本単位となる。従って、画像データの圧縮伸長動作は、コンポーネント毎、また、タイル１１２毎に、独立に行われる。
【００６５】
画像データの符号化時には、各コンポーネント１１１の各タイル１１２のデータが、図１の色空間変換・逆変換部１０１に入力され、色空間変換を施された後、２次元ウェーブレット変換・逆変換部１０２で２次元ウェーブレット変換（順変換）が施されて、周波数帯に空間分割される。
【００６６】
図３には、デコンポジションレベル数が３の場合の、各デコンポジションレベルにおけるサブバンドを示している。即ち、原画像のタイル分割によって得られたタイル原画像（０ＬＬ）（デコンポジションレベル０）に対して、２次元ウェーブレット変換を施し、デコンポジションレベル１に示すサブバンド（１ＬＬ，１ＨＬ，１ＬＨ，１ＨＨ）を分離する。そして引き続き、この階層における低周波成分１ＬＬに対して、２次元ウェーブレット変換を施し、デコンポジションレベル２に示すサブバンド（２ＬＬ，２ＨＬ，２ＬＨ，２ＨＨ）を分離する。順次同様に、低周波成分２ＬＬに対しても、２次元ウェーブレット変換を施し、デコンポジションレベル３に示すサブバンド（３ＬＬ，３ＨＬ，３ＬＨ，３ＨＨ）を分離する。図３では、各デコンポジションレベルにおいて符号化の対象となるサブバンドを、網掛けで表してある。例えば、デコンポジションレベル数を３としたとき、網掛けで示したサブバンド（３ＨＬ，３ＬＨ，３ＨＨ，２ＨＬ，２ＬＨ，２ＨＨ，１ＨＬ，１ＬＨ，１ＨＨ）が符号化対象となり、３ＬＬサブバンドは符号化されない。
【００６７】
次いで、指定した符号化の順番で符号化の対象となるビットが定められ、図１に示す量子化・逆量子化部１０３で対象ビット周辺のビットからコンテキストが生成される。
【００６８】
この量子化の処理が終わったウェーブレット係数は、個々のサブバンド毎に、「プレシンクト」と呼ばれる重複しない矩形に分割される。これは、インプリメンテーションでメモリを効率的に使うために導入されたものである。図４に示したように、一つのプレシンクトは、空間的に一致した３つの矩形領域からなっている。更に、個々のプレシンクトは、重複しない矩形の「コード・ブロック」に分けられる。これは、エントロピー・コーディングを行う際の基本単位となる。
【００６９】
ウェーブレット変換後の係数値は、そのまま量子化し符号化することも可能であるが、
ＪＰＥＧ２０００では符号化効率を上げるために、係数値を「ビットプレーン」単位に分
解し、画素あるいはコード・ブロック毎に「ビットプレーン」に順位付けを行うことがで
きる。
【００７０】
ここで、図５はビットプレーンに順位付けする手順の一例を示す説明図である。図５に示すように、この例は、原画像（３２×３２画素）を１６×１６画素のタイル４つで分割した場合で、デコンポジションレベル１のプレシンクトとコード・ブロックの大きさは、各々８×８画素と４×４画素としている。プレシンクトとコード・ブロックの番号は、ラスター順に付けられており、この例では、プレンシクトが番号０から３まで、コード・ブロックが番号０から３まで割り当てられている。タイル境界外に対する画素拡張にはミラーリング法を使い、可逆（５，３）フィルタでウェーブレット変換を行い、デコンポジションレベル１のウェーブレット係数値を求めている。
【００７１】
また、タイル０／プレシンクト３／コード・ブロック３について、代表的な「レイヤ」構成の概念の一例を示す説明図も図５に併せて示す。変換後のコード・ブロックは、サブバンド（１ＬＬ，１ＨＬ，１ＬＨ，１ＨＨ）に分割され、各サブバンドにはウェーブレット係数値が割り当てられている。
【００７２】
レイヤの構造は、ウェーブレット係数値を横方向（ビットプレーン方向）から見ると理解し易い。１つのレイヤは任意の数のビットプレーンから構成される。この例では、レイヤ０，１，２，３は、各々、１，３，１，３のビットプレーンから成っている。そして、ＬＳＢ（Least Significant Bit：最下位ビット）に近いビットプレーンを含むレイヤ程、先に量子化の対象となり、逆に、ＭＳＢ（Most Significant Bit：最上位ビット）に近いレイヤは最後まで量子化されずに残ることになる。ＬＳＢに近いレイヤから破棄する方法はトランケーションと呼ばれ、量子化率を細かく制御することが可能である。
【００７３】
図１に示すエントロピー符号化・復号化部１０４では、コンテキストと対象ビットから確率推定によって、各コンポーネント１１１のタイル１１２に対する符号化を行う。こうして、原画像の全てのコンポーネント１１１について、タイル１１２単位で符号化処理が行われる。最後にタグ処理部１０５は、エントロピー符号化・復号化部１０４からの全符号化データを１本の符号列データに結合するとともに、それにタグを付加する処理を行う。
【００７４】
図６には、この符号列データの１フレーム分の概略構成を示している。この符号列データの先頭と各タイルの符号データ（bit stream）の先頭にはヘッダ（メインヘッダ（Main header）、タイル境界位置情報等であるタイルパートヘッダ（tile part header））と呼ばれるタグ情報が付加され、その後に、各タイルの符号化データが続く。なお、メインヘッダ（Main header）には、符号化パラメータや量子化パラメータが記述されている。そして、符号列データの終端には、再びタグ（end of codestream）が置かれる。また、図７は、符号化されたウェーブレット係数値が収容されたパケットをサブバンド毎に表わしたコードストリーム構造を示すものである。図７に示すように、タイルによる分割処理を行っても、あるいはタイルによる分割処理を行わなくても、同様のパケット列構造を持つことになる。
【００７５】
一方、符号化データの復号化時には、画像データの符号化時とは逆に、各コンポーネント１１１の各タイル１１２の符号列データから画像データを生成する。この場合、タグ処理部１０５は、外部より入力した符号列データに付加されたタグ情報を解釈し、符号列データを各コンポーネント１１１の各タイル１１２の符号列データに分解し、その各コンポーネント１１１の各タイル１１２の符号列データ毎に復号化処理（伸長処理）を行う。このとき、符号列データ内のタグ情報に基づく順番で復号化の対象となるビットの位置が定められるとともに、量子化・逆量子化部１０３で、その対象ビット位置の周辺ビット（既に復号化を終えている）の並びからコンテキストが生成される。エントロピー符号化・復号化部１０４で、このコンテキストと符号列データから確率推定によって復号化を行い、対象ビットを生成し、それを対象ビットの位置に書き込む。このようにして復号化されたデータは周波数帯域毎に空間分割されているため、これを２次元ウェーブレット変換・逆変換部１０２で２次元ウェーブレット逆変換を行うことにより、画像データの各コンポーネントの各タイルが復元される。復元されたデータは色空間変換・逆変換部１０１によって元の表色系の画像データに変換される。
【００７６】
以上が、「離散ウェーブレット変換に基づく符号化・復号化アルゴリズム」の概要である。
【００７７】
ところで、ＪＰＥＧ２０００には各種規格が定められており、例えば、ＲＯＩ（関心領域）の符号化オプションなどが含まれるＪＰＥＧ２０００のPart２（ＩＳＯ１５４４４−２）、動画規格であるＪＰＥＧ２０００のPart３（ＩＳＯ１５４４４−３）、絵や文字などの異なる特性を含む複合的な画像に特化した規格であるＪＰＥＧ２０００のPart６（ＩＳＯ１５４４４−６）などが挙げられる。
【００７８】
ここで、ＪＰＥＧ２０００のPart６“Compound image file Format”について説明する。ＪＰＥＧ２０００のPart６は、絵や文字などの異なる特性を含む複合的な画像に特化した規格であり、非特許文献１に示す国際標準ＩＳＯ１５４４４−６で規定されている。このようなＪＰＥＧ２０００のPart６の中で定められたＪＰＥＧ２０００データのファイル拡張子は、「ＪＰＭ」である。このような構造化文書の一例であるＪＰＭファイルは、図８に示すように、コードストリームの位置を示すオフセットを記入するObject Header Box２０１、参照されるコードストリームＢｏｘ２０２及びその他のＢｏｘ２０３から構成されている。このＪＰＭファイルは、そのファイル内でデータを参照するようにしたり、ＢＯＸ情報の順番を規定したり、オフセットによる位置指定ではなく参照する番号により参照できるようにしている。また、図８に示す所定のＢＯＸについては、そのレベルや範囲を維持していれば、その出現回数や出現する順番が変動しても標準互換のＪＰＭファイルとして機能すると規定されている。一例としては、各レイアウトオブジェクト内のオブジェクトに対するコードストリームについては、構造化文書の論理構造を満たし、
１）文書サムネイル（図８中の符号２０３）以降
２）最上位レベルの位置
であれば任意の位置に置いて良いことが規定されている。
【００７９】
続いて、本発明の実施の形態について詳細に説明する。なお、ここでは、JPEG2000に関する例について説明するが、言うまでもなく、本発明は以下の説明の内容に限定されるものではない。
【００８０】
ここで、図９は本実施の形態の符号変換装置１０００のハードウェア構成を示すブロック図である。符号変換装置１０００は、例えばパーソナルコンピュータやワークステーションを主体に構成されている。図９に示すように、このような符号変換装置１０００は、コンピュータの主要部であって各部を集中的に制御するＣＰＵ（Central Processing Unit）２を備えている。このＣＰＵ２には、ＢＩＯＳなどを記憶した読出し専用メモリであるＲＯＭ（Read Only Memory）３と、各種データを書換え可能に記憶するＲＡＭ（Random Access Memory）４とがバス５で接続されている。
【００８１】
さらにバス５には、各種のプログラム等を格納するＨＤＤ（Hard Disk Drive）６と、配布されたプログラムであるコンピュータソフトウェアを読み取るための機構としてＣＤ（Compact Disc）−ＲＯＭ７を読み取るＣＤ−ＲＯＭドライブ８と、ネットワーク９を介して外部の他のコンピュータ等と通信により情報を伝達するための通信制御装置１０と、ＣＰＵ２に対する各種命令や情報入力するためのキーボードやマウスなどの入力装置１１と、処理経過や結果等を表示するＣＲＴ（Cathode Ray Tube）、ＬＣＤ（Liquid Crystal Display）などの表示装置１２とが、図示しないＩ／Ｏを介して接続されている。
【００８２】
ＲＡＭ４は、各種データを書換え可能に記憶する性質を有していることから、ＣＰＵ２の作業エリアとして機能してバッファ等の役割を果たす。
【００８３】
図９に示すＣＤ−ＲＯＭ７は、この発明の記憶媒体を実施するものであり、ＯＳ（Operating System）や各種のプログラムが記憶されている。ＣＰＵ２は、ＣＤ−ＲＯＭ７に記憶されているプログラムをＣＤ−ＲＯＭドライブ８で読み取り、ＨＤＤ６にインストールする。
【００８４】
なお、記憶媒体としては、ＣＤ−ＲＯＭ７のみならず、ＤＶＤなどの各種の光ディスク、各種光磁気ディスク、フレキシブルディスクなどの各種磁気ディスク等、半導体メモリ等の各種方式のメディアを用いることができる。また、通信制御装置１０を介してインターネットなどからプログラムをダウンロードし、ＨＤＤ６にインストールするようにしてもよい。この場合に、送信側のサーバでプログラムを記憶している記憶装置も、この発明の記憶媒体である。なお、プログラムは、所定のＯＳ（Operating System）上で動作するものであってもよいし、その場合に後述の各種処理の一部の実行をＯＳに肩代わりさせるものであってもよいし、所定のアプリケーションソフトやＯＳなどを構成する一群のプログラムファイルの一部として含まれているものであってもよい。
【００８５】
このシステム全体の動作を制御するＣＰＵ２は、このシステムの主記憶として使用されるＨＤＤ６上にロードされたプログラムに基づいて各種処理を実行する。
【００８６】
次に、符号変換装置１０００のＨＤＤ６にインストールされている各種のプログラムがＣＰＵ２に実行させる機能のうち、本実施の形態の符号変換装置１０００が備える特長的な機能について説明する。
【００８７】
図１０は、符号変換装置１０００の機能構成を示すブロック図である。図１０において、１０００は本発明に係る符号変換装置であり、変換対象のファイルの符号ストリーム（入力符号ストリーム）１００１を取り込み、この入力符号ストリーム１００１と同様な内容を持つ、よりコンパクトなファイルサイズの符号ストリーム（出力符号ストリーム）１００２へ変換する動作を行うものである。なお、入力符号ストリーム１００１と出力符号ストリーム１００２は、同じシンタックスを持ち、ＢＯＸ情報の共有／参照が許されるものである。
【００８８】
符号変換装置１０００は、上記変換のために、入力符号ストリーム１００１からＢＯＸ情報を切り出すＢＯＸ分解手段１００３、切り出されたＢＯＸ情報に関し共有／参照処理をするべきか判断する共有／参照判断手段１００４、この共有／参照判断手段１００４による判断の結果に従って、入力符号ストリーム１００１より切り出されたＢＯＸ情報に関し必要な共有又は参照のための処理を行う共有／参照処理手段１００５を含むことを特徴とする。
【００８９】
図１１は、この符号変換装置１０００の処理フローの一例を示すフローチャートである。このフローチャート中のステップＳ９で呼び出される「共有処理」と「参照処理」の処理内容を図１２と図１３に示す。
【００９０】
符号変換装置１０００の動作説明に先立って、図１４、図１５及び図１６を用い共有／参照処理の動作イメージを説明する。
【００９１】
図１４は、ページ上に、同じ画像を、大きさを変えて５箇所にレンダリングする例を示している。そして、これら５つの画像０，１，２，３，０'の各符号データには、レンダリングの対象にはならない“Riooh  copyright”と著作権表示がされたメタデータが１つずつ付いているものとする。
【００９２】
共有／参照の対象に出来るものは符号フォーマットに依存するが、例えば非特許文献２，３に記載されている符号フォーマットの場合、
・共有の対象はメタデータやＢＯＸ情報のヘッダ
・参照の対象はコードストリーム
である。
【００９３】
そこで、以下の説明では非特許文献２で定義されるＪＰＭファイル（ＩＳＯ１５４４４−６）を変換対象ファイルの一例として説明する。ただし、本発明は、ＪＰＭファイルだけに限られず、共有／参照のメカニズムを持つ同様な符号フォーマットにも適用し得るものである。例えば、ＩＳＯ１５４４４-２に準拠したファイルやＩＳＯ１５４４４−３に準拠したファイル、ＰＤＦ仕様に準拠したファイルである。
【００９４】
図１４のようなページにおけるファイル内でのメタデータのイメージを図１５に示す。図１５において、（ａ）はメタデータの共有のないファイルを示している。画像０，１，２，３，０'それぞれ毎にレイアウトオブジェクト“Layout  Object  Box”を持ち、その中のメタデータ部に１５文字からなるメタデータ“Riooh  copyright”が入っていることが示されている。このようなレイアウトオブジェクトが各画像対応に計５つあるため、メタデータ部には合計して７５バイト（＝１５×５）のデータが入っていることになる。
【００９５】
図１５の（ｂ）は、非特許文献２の“Ｂ．１．８節”に詳しく説明されている共有データを適用したファイルのイメージである。すなわち、メタデータ“Riooh  copyright”はＪＰＭファイル中の“Shared  Data  Entry  Box”４２にＩＤとともに登録され、各画像に対応したレイアウトオブジェクトのメタデータ部４３に共有データのＩＤを記入することによりメタデータの共有が実現される。この場合、“Shared  Data  Entry  BOX”の１７バイト（＝ＩＤの２バイト＋メタデータの１５バイト）と、各参照先におけるＩＤの２バイト（ここでは５箇所であるので計１０バイト）が必要であるから、その合計バイト数は２７バイトとなる。したがって、メタデータを共有しない場合に比べ４８バイト（＝７５−２７）もサイズを圧縮することができる。
【００９６】
次に参照の場合を説明する。参照はコードストリームが対象である。図１４において、５つの画像は位置と大きさが異なるだけで、縮小率を指定することによって生成される画像は全く同じ内容であると仮定すると、下記に示すように、
画像３は、位置（ｘ３，ｙ０）に、大きさ１／６４
画像２は、位置（ｘ２，ｙ０）に、大きさ１／１６
画像１は、位置（ｘ１，ｙ０）に、大きさ１／４
画像０は、位置（ｘ０，ｙ０）に、大きさ１／１
画像０'は、位置（ｘ０'，ｙ０'）に、大きさ１／４
それぞれレンダリングされていることになる。
【００９７】
図１６は、このＪＰＭファイル内での構造を示している。図１６の（ａ）は参照の無いファイルを示しており、画像０，１，２，３，０'に対応して、独立して符号化された５つのコードストリーム“CodeStream”が入っている。符号化は可変長であるが、簡単のため符号長は画像の大きさに比例するとするものとして、各コードストリームの大まかなサイズが例えば、下記に示すように仮定すると、
CodeStream３のサイズ＝１ＫＢ
CodeStream２のサイズ＝４ＫＢ
CodeStream１のサイズ＝１６ＫＢ
CodeStream０のサイズ＝６４ＫＢ
CodeStream０'のサイズ＝１６ＫＢ
その合計サイズは１０１ＫＢとなる。
【００９８】
一方、図１６の（ｂ）は参照を適用したファイルを示す。各画像０，１，２，３，０'は縮小率により一意的に決定できる画像という仮定があるため、それら５つのコードストリームを１つの“Codestream０”で代表し、ファイルの先頭からCodeStream０へのオフセット“offset”４４、“CodeStream０”の長さ“length”４５を求め、それを各参照先に記入する。各参照先には、大きさを示す“ScaleBox”情報があり、それによって、参照されるコードストリームを伸長したときの画像の大きさとレンダリングされる画像の大きさの比率を指定することにより、（ａ）の場合と同じ画像を再現できる。
【００９９】
このときのデータの大きさは、“CodeStream０”の６４ＫＢであるため、参照しない（ａ）の場合に比べ、おおよそ３７ＫＢ（＝１０１ＫＢ−６４ＫＢ）もサイズを節約できる。なお、図１６（ａ）の場合にコードストリームの名前を書いていたところを、（ｂ）の場合にオフセットと長さの組で書いたことによる削減効果もあるが、これは微々たるものであるので上記計算では除外している。
【０１００】
なお、本発明は、部分符号を参照する場合、参照される側の符号の論理的なまとまりの単位に参照単位を指定できる。すなわち、参照単位を、解像度、色成分、位置、画質毎に設定ですることができる。また、参照単位を色成分毎に設定した場合には、参照単位をプレシンクトまたはタイル毎に設定することができる。
【０１０１】
以上が共有／参照の動作イメージの説明である。言うまでも無く、共有／参照は可逆の変換である。
【０１０２】
次に、本発明の符号変換装置１０００の動作を、図１１のフローチャートに沿って説明する。
【０１０３】
まず、ステップＳ１で入力バッファと出力バッファを用意する。入力バッファには変換前ファイルの符号ストリーム（入力符号ストリーム１００１）が取り込まれる。出力バッファは初期化される。
【０１０４】
ステップＳ２で、ＢＯＸ分解手段１００３は、入力符号ストリーム１００１の最後かどうかをチェックする。最後で無ければステップＳ３に進み、入力バッファ内の入力符号ストリーム１００１の最初からＢＯＸ情報を１つ切り出し、ＢＯＸ情報（Ａ）に入力する。
【０１０５】
次に、共有／参照判断手段１００４は、ステップＳ４で、ＢＯＸ情報（Ａ）の共有／参照が許されているかどうかをチェックする。ステップＳ４で許されていないと判断したならば、共有／参照によってファイルサイズをコンパクトにする余地はないので、処理はステップＳ２に戻る。
【０１０６】
一方、ステップＳ４で共有／参照が許されていると判断した場合は、ステップＳ５に進む。このステップＳ５で、共有／参照判断手段１００４は、ＢＯＸ情報（Ａ）の内容がファイル内部での共有データの形式でファイル内部で有効なＩＤが記述されているか、または、必要な“FLAGMENT  TABLE”を介してファイルの先頭から参照部分へのオフセット及び長さが書いてある形式になっているかどうかをチェックする。前者の場合は共有であり、後者の場合は参照である。どちらかの形式であればすでに共有／参照の形式になっているので処理はステップＳ２に戻る。一方、どちらの形式でもなければ共有／参照できる可能性があるので、共有する対象を見つけるためステップＳ６に進む。
【０１０７】
ステップＳ６からステップＳ１０までが入力符号ストリーム１００１の中に共有／参照できる対象があるかどうかを検出し、対応する処理をするステップである。
【０１０８】
先ずステップＳ６で、ＢＯＸ分解手段１００３により入力符号ストリーム１００１の最後のＢＯＸ情報を切り出し、それをＢＯＸ情報（Ｂ）にセットする。ステップＳ７で、共有／参照判断手段１００４は、ＢＯＸ情報（Ｂ）の位置がＢＯＸ情報（Ａ）よりも後ろかどうかをチェックする。その位置が一致したときには、ＢＯＸ情報（Ａ）の位置よりも後ろに共有／参照できる対象がなかったと判断してステップＳ１０に進むが、そうでないときはステップＳ８に進む。
【０１０９】
ステップＳ８で、共有／参照判断手段１００４は、先に入力したＢＯＸ情報（Ａ）の内容とＢＯＸ情報（Ｂ）の内容が同一かどうかをチェックする。内容が一致しないときにはステップＳ７に戻って１つ前のＢＯＸ情報をチェックするが、内容が一致したときには共有／参照の候補となるので処理はステップＳ９に進む。
【０１１０】
ステップＳ９で、共有／参照処理手段１００５は、予め決めてあったルールに従いＢＯＸ情報（Ａ）をＢＯＸ情報（Ｂ）の共有または参照データとして更新する手続きを行う。共有にするか参照にするかは、どちら一方に予め決めておくか、ファイルの仕様によって、ある場合には共有又は参照のみしか許さないなど一定のルールがあるので、それに準拠するものとする。
【０１１１】
例えばＩＳＯ１５４４４−６（Information  technology−JPEG2000  Image  Coding  System-Part6：Compound  Image  File  Format）では、ＢＯＸ情報（Ａ）と同一ファイル内での共有と参照のどちらも許されるが、この仕様に準拠する他のＪＰＭファイル内にあるＢＯＸ情報に対しては参照しか許されていない。
【０１１２】
さて、共有／参照処理手段１００５は、ステップＳ９で共有を選んだときには図１２に示す共有処理を行い、参照を選んだときには図１３に示す参照処理を行うが、これによりＢＯＸ情報（Ａ）とＢＯＸ情報（Ｂ）の関連づけが行われたので、次のステップＳ１０でＢＯＸ情報（Ａ）と“クロスリファレンステーブル”と“Fragment  Table”を出力バッファに書き出す。そして、次のＢＯＸ情報の処理のためにステップＳ２に戻る。
【０１１３】
こうした一連の操作が入力符号ストリーム１００１の最後まで行われ、ステップＳ２で
入力符号ストリーム１００１の最後が検出されると（ステップＳ２，Ｙ）、共有／参照処
理手段１００５は後処理に移行する。
【０１１４】
後処理の内容は、ＢＯＸ情報（Ａ）が共有なのか参照なのかによって異なる。共有の場合には、これまでの操作で共有として検出されたＢＯＸ情報（Ｂ）（共有エントリＢＯＸに入っている情報）も参照ＩＤに置換する。一方、参照の場合には、既に参照処理部分で入力ストリームのＢＯＸ情報（Ａ）に該当する部分はオフセットと長さに更新してあるので置換する対象がないため、格別の処理は必要でない。この後処理（ステップＳ１１〜ステップＳ１８）について、さらに説明する。
【０１１５】
先ず、ステップＳ１１で、ステップＳ９と同様に共有／参照を区別する。参照の場合には特に後処理は無いのでステップＳ１８に進む。
【０１１６】
一方、共有の場合には、ステップＳ１２に進み、共有エントリＢＯＸの最初のエントリの内容をBufferにコピーする。次のステップＳ１３で、Bufferの内容が“ヌル”であるかどうかをチェックする。“ヌル”とは共有エントリＢＯＸの最後であることを示しているため、“ヌル”であればステップＳ１８に進む。
【０１１７】
“ヌル”でなければ、そのエントリに対するＢＯＸ情報（Ｂ）を入力符号ストリーム１００１から探索する。すなわち、ステップＳ１４で、入力ストリームの最後から（あるいは最初から）順次にＢＯＸ情報（Ｂ）の内容をBufferと同じかどうかをチェックする。一致しなければ次のＢＯＸ情報（Ｂ）について同様な操作を繰り返し、一致箇所を探索する。
【０１１８】
ステップＳ１４において一致箇所が見つかったならばステップＳ１５に進み、ＢＯＸ情報（Ｂ）を共有ＢＯＸに書かれた該当エントリに対する参照ＩＤに更新する。そして、ステップＳ１６でクロスリファレンスＢＯＸがあるかチェックする。クロスリファレンスＢＯＸがある場合には、この更新によりオフセット値がずれてくる。そこで、クロスリファレンスＢＯＸが無い場合は特に処理は無いが、クロスレファレンスＢＯＸが有る場合にはステップＳ１７でオフセット値を補正する。
【０１１９】
ステップＳ１〜ステップＳ１０までの処理でＢＯＸ情報（Ｂ）が共有ＢＯＸのエントリと一致するのは１箇所だけと判っているため、ステップＳ１７の後は、入力符号ストリーム１００１の最後まで探索することなく、共有ＢＯＸの次のエントリを指し、ステップＳ１３からステップＳ１７について同様な操作を繰り返す。ステップＳ１３において共有ＢＯＸの最後のエントリであることが検出されるとステップＳ１８に進み、クロスリファレンスＢＯＸ，“Flagment  List  BOX”を出力バッファに書き出し、処理は終了する。
【０１２０】
ステップＳ９で呼び出される共有処理と参照処理の内容は図１２と図１３に示す通りである。すなわち、図１２に示すように、共有処理においては、まず共有エントリＢＯＸに新たなエントリを作り、その参照ＩＤをつける。
【０１２１】
次にＢＯＸ情報（Ａ）の内容を共有エントリＢＯＸに移動した後、その参照ＩＤに更新する。この操作により、参照される共有エントリＢＯＸの内容と参照するＢＯＸ情報（Ａ）の関連付けが行われる。このとき、ＢＯＸ情報（Ａ）は参照ＩＤに書き換えることによりＢＯＸ情報（Ａ）のサイズが小さくなる。
【０１２２】
そこで、そのファイル内のＢＯＸ情報（Ａ）より後ろに参照されるＢＯＸ情報がある他の組に対して、ファイルの先頭から参照する位置までのオフセットが変動してくる。そのためＢＯＸ情報（Ａ）の「変更前のサイズ−変更後のサイズ」分だけ、以前のオフセット値から減算することにより、両者の関係を維持する。以上で共有処理は終了する。図１７は、文書の複数のページにわたって共通のロゴマークを印刷する場合を示す例である。
【０１２３】
また、図１３に示すように、参照処理においては、まず、
・ファイルの先頭からＢＯＸ情報（Ｂ）までのオフセット
・ＢＯＸ情報（Ｂ）の長さ
を求める。
【０１２４】
クロスリファレンスＢＯＸからリンクされる“Fragment  List  BOX”に前記オフセットと長さを記入する。ＢＯＸ情報（Ａ）にクロスリファレンスＢＯＸの該当エントリ（参照が行われるたびに別のクロスリファレンスＢＯＸを生成する構成の場合はクロスリファレンス自身）を記録する。これにより、参照する側と参照される側の関連付けができた。また、この値の変更によってもＢＯＸ情報（Ａ）のサイズは小さくなるために、先に共有の動作の部分で説明したのと同じ理由により、クロスリファレンスＢＯＸ（または“Fragment  List  BOX”）内のそれ以外のエントリのオフセットについてもＢＯＸ情報（Ａ）の位置よりも後のＢＯＸ情報を参照している場合は、ＢＯＸ情報（Ａ）の変更前のサイズから変更後のサイズ分だけ以前のオフセット値から減算することにより、両者の関係を維持する。以上で参照処理は終了する。
【０１２５】
本発明の符号変換装置１０００によれば、上に述べたようにファイルの冗長な内容に対する共有／参照処理を符号の論理的なまとまりの単位である参照単位で行うことによって、ファイルサイズを変換前より縮小させることができる。
【０１２６】
次に、請求項２の発明について説明する。請求項２の発明によれば、符号変換装置１０００において、変換対象のファイル（自ファイル）以外のローカル・ファイル又はリモート・ファイルのデータも対象として共有／参照の処理を行うことができる。その内容を図１８を参照して具体的に説明する。
【０１２７】
図１８において、１１０１は変換対象のファイル（自ファイルと呼ぶ）である。１１０２，１１０３，１１０４は自ファイル内で共有／参照される他のファイルであり、ファイル１１０２，１１０３はローカル・ファイルであり、ファイル１１０４はインターネットなどのネットワーク１１０５上にあるリモート・ファイルである。
【０１２８】
ここでは、自ファイル１１０１は非特許文献３に示されるＪＰＸファイルとして説明するが、ＪＰＸファイルと同様な機構を持つ他の仕様のファイルでもよいことはいうまでもない。
【０１２９】
ＪＰＸファイルには、“Media  Data”と呼ばれるエリアがいくつかある。これは図１６中の“CodeStream”に相当するデータの断片である。
【０１３０】
さて、図１８に示した例においては、“Fragment  List  Box”に７つのエントリが登録されており、その参照先は、
・１，４，５，７番目のデータは自ファイル１１０１内のデータ
・２，３番目のデータはローカル・ファイル１１０２，１１０３内のデータ
・６番目のデータはリモート・ファイル１１０４内のデータ
となっている。
【０１３１】
ローカル・ファイル内のデータの参照は以下のように行われる。自ファイル１１０１内に“Data  Reference  BOX”がある。図１８の例では３つのエントリが示されているが、そのれぞれにＵＲＩ（Uniform  Resource  Identifiers）によりファイルの位置及びファイル名が指定されることにより他のファイルが参照されることになる。
【０１３２】
まず、参照先が自ファイル内か他ファイル内かは、“Fragment  List”のＤＲ（Data  Reference）ビットにより一意的に決定される。ＤＲビットが０ならば参照先は自ファイ
ル内だが、１の場合は参照先は他ファイル内となる。
【０１３３】
そして、他ファイル内のどの部分を参照するかを、“Fragment  Table”内にある“Fragment  List”の該当するエントリに書かれているオフセットと長さの組で指定する。このようにするならば、前述の自ファイル内の“Media  Data”の断片を参照する場合と全く同じ機構により参照することにより、他ファイルの内容の共有／参照処理を行ってファイルサイズを縮小させることができる。
【０１３４】
参照される他ファイルがネットワーク上にあるリモート・ファイルの場合、その参照方法は以下のとおりである。
【０１３５】
“Data  Reference  Box”にある“Data  Reference  table”には一般にＵＲＩで記述するので、ネットワーク上のリモート・ファイルを参照する場合には、そのネットワーク上での名前を“Data  Reference  table”に記入することにより、上に説明した他のローカル・ファイルの断片のアクセスと全く同じ機構により、“FragmentList”によって指定されたオフセットと長さで該当部分を参照することができる。かくして、リモート・ファイルの内容の共有／参照処理によって、ファイルサイズを縮小することができる。
【０１３６】
次に、請求項３の発明について説明する。請求項３の発明によれば、符号変換装置１０００に、ユーザが共有／参照するＢＯＸの指定又は非指定のための指示を入力する手段（不図示）が設けられる。
【０１３７】
ユーザが共有／参照するＢＯＸを指定する場合の作用について、図１９を用いて説明する。説明の便宜上、図１９では実空間上のデータを使って説明するが、実際の共有／参照はそれに対応する画像の符号化データやメタデータ等のＢＯＸ情報が操作の対象となることは言うまでもない。
【０１３８】
今、Ｐａｇｅ１００を編集中に既に作成済みのＰａｇｅ１上の符号データを参照する例を説明する。ここでは、Ｐａｇｅ１００はカラー画像の変倍を解説した頁であり、Ｐａｇｅ１はモノクロ画像の変倍を解説した頁である。
【０１３９】
Ｐａｇｅ１００を作成する上で、カラー画像の輝度成分、色差成分で独立した処理であることと解説の見易さを考慮し、Ｐａｇｅ１で作成した画像がそのまま使用できる部分（画像０，１，２，３）４０と新たに作成した部分（画像０'）４１がある。ここで画像０，１，２，３は、それぞれＰａｇｅ１の画像０，１，２，３を参照するとユーザが指定することにより、ファイル内で参照する画像に対する符号を明示的に示すことができる。この動作は、指定した画像がＰａｇｅ１にあるかどうかをチェックし、その画像がなければエラー、あれば、そのオフセットと長さを図１８に示した“Fragment  List”にそれぞれ記入すれば実現できる単純な操作なので、そのフローチャートはここでは省略する。
【０１４０】
そして、新たな画像０'４１に対する符号は文書内のどこにも参照する部分はないので、それを新たな符号としてファイル内の該当部分に記述する。
【０１４１】
なお、参照する画像を明示的に指定しない場合、その動作はより複雑となるが、既に図１８を用いて詳細に解説したので、ここではその説明を省略する。さらに共有の場合もオフセット、長さで指定せずに、共有エントリＢＯＸに登録し、参照ＩＤに変換するなど多少の違いは発生するが、その違いは図１９、図２０を用いて詳細に解説した通りとなり、共有／参照してよいデータと、共有／参照したくないデータを意図的に区分することができることにより、自ファイル内で将来編集する予定がある画像部分に対しても、編集前後でファイルサイズが大きく変動することがないため、ディスクの空き容量の制限により編集後保存が出来なくなる恐れが少なくなる。また、他のローカル・ファイルやリモート・ファイルなど、外部参照データに依存しないようにファイルを構成したり、逆に共有／参照データを統一することにより、文書全体を通して見やすく、仕上がりが美しい文書を作成するよう制御することができる。
【０１４２】
ユーザが共有／参照するＢＯＸを指定しない場合は、ファイル内の全てのＢＯＸが対象となり、図１８、図１９、図２０により説明した通りの作用となる。共有／参照が可能な全てのＢＯＸを対象として共有／参照処理が行われることにより、最も高い可逆圧縮率を実現することができる。
【０１４３】
次に、請求項４，５，６の発明について説明する。これら発明によれば、符号変換装置１０００は、共有／参照処理手段１００５において変換内容を示すステータスレポートを生成し、これを外部に出力する。これについて図２０を用いて説明する。
【０１４４】
図２０は、図１５に示した共有処理が行われた場合に生成されるステータスレポートの例を示している。図２０の前半部分４６は、各ＢＯＸの変換前後の対応関係を示している。各ＢＯＸにおいて、“→”の前は変換前の状態を、“→”の後は変換後の状態を示している。図２０の後半部分４７は、変換によるファイルサイズの変動を示している。
【０１４５】
以下、ＩＳＯ１５４４４−６で示されるＪＰＭファイルを例にとって図２０に示した内容を説明する。ただし、この説明は、同様な機能を果たす他のファイル構造に対しても適用し得ることは言うまでもない。
【０１４６】
まず、“→Shared  Data  Entry  BOX［１］”に、
参照ＩＤ＝０
Shared  Data＝“Riooh  copyright”
が作成されたことが示されている。次の“Page  BOX”では、
Layout  Object  Box3
Layout  Object  Box2
Layout  Object  Box1
Layout  Object  Box0
Layout  Object  Box0'
の各“Metadata  Boxes［１］”が
参照ＩＤ＝０
と記入されたことを示している。
【０１４７】
そして、
変換で新規作成されたサイズ＝２８バイト
変換で削除されたサイズ＝８０バイト
変換により削減されたサイズ＝５２バイト（＝８０−２８）
であることが示されている。
【０１４８】
ここで、新規作成されたサイズの内訳は、
Shared  Data  Entry  Box
ＩＤ＝２バイト
Shared  Data＝“Riooh  copyright\0”＝１６バイト（文字列の最後の区切りとして\0の１バイトが入る）
各“Layout  Object  Box”の“Metadata  Boxes［１］”
ＩＤ＝２バイト×５箇所
である。
【０１４９】
削除されたサイズは、各“Layout  Object  Box”の“Metadata  Boxes［１］”であり、そこに変更前に“Riooh  copyright\0”＝１６バイトが５箇所書かれていたが、これが削除された分である。
【０１５０】
そして、上記２つのバイト数の差から、ファイル全体として５２バイトが削減されたことが報告されている訳である。
【０１５１】
以上、共有の場合について説明したが、参照の場合もこれまで説明したアルゴリズムを参照することにより、図１６の例で変換前後でどのように対応しているか、またファイルサイズの変化状況はどのようになっているかも同様に説明することができる。
【０１５２】
なお、図２０に示したステータスレポートの例に見られるように、共有／参照としたオブジェクト毎に対照したステータスレポートが出力されるため、共有／参照の対象となったオブジェクトの対応関係を容易に確認することができ（請求項５）、また、変換により削減できたサイズが示されるため、共有／参照の効果を容易に確認することができる（請求項６）。
【０１５３】
また、ステータスレポートは、作成中／審査中／承認済みを示すように、参照単位を変化させるようにしても良い。さらに、ステータスレポートは、作成中／編集中／削除済みを示すように、参照単位を変化させるようにしても良い。
【０１５４】
次に、請求項７，８，９，１０の発明について説明する。図１８に関連して既に説明したように、リモート・ファイルを参照するには、その参照範囲を指定できないと、全世界のファイルが対象となって変換処理にかなり多くの時間がかかってしまう。そこで、図１８で例として示したインターネット等のネットワークの範囲を指定することにより、対象範囲を制限することが必要となる。請求項７，８，９の発明によれば、符号変換装置１０００に、そのような参照範囲をユーザが指定するための手段（不図示）が追加される。
【０１５５】
デフォルトでは自分が属するセグメント内とする等が考えられるが、ここでは自分が属するセグメントを中心にルータを通過する範囲であるホップ数、ネットワーク管理者が管理する範囲であるドメイン、あるいはネットワーク管理者がなく、共通目的で結合されているワークグループの範囲、あるいは、参照するＵＲＬのリストで範囲を指定すること等を挙げることができる。
【０１５６】
これらについてはネットワーク上での範囲を定義することができ、それぞれネットワーク関連の資料に詳しく説明されている通りの動作を示すこととなるが、いずれにしても範囲が明確になることにより、共有／参照の範囲とその効果の関係を的確に管理することができるようになる。そして、リモート・ファイルの参照範囲は、請求項８の発明によればホップ数によって指定され、請求項９の発明によればドメイン名やそのリストによって指定され、また、請求項１０の発明によればワークグループ名やそのリストによって指定されるわけである。
【０１５７】
次に、請求項１１，１２，１３の発明について説明する。ここでの説明に図２１を参照する。
【０１５８】
図２１はページサムネイルの統一、補完を示す図である。ここでは、簡単のために、全体が８ページ、各季節につき２ページが割り当てられた、“四季”を文書名とした文書があり、これをその各ページを別々の人が分担して作成してから統合することにより作成する場合を例にする。このような場合、例えば図２１の（ａ）に示すように、ページサムネイル４８が不揃いとなるのが通例である。各ページサムネイルの内容は以下の通りである。
「ページ」  「テーマ」    「アイコンの内容」
Ｐ１        春            つつじ
Ｐ２        春            なし        （同じ春のＰ１と不揃い）
Ｐ３        夏            ひまわり
Ｐ４        夏            朝顔        （同じ夏のＰ３と不揃い）
Ｐ５        秋            なし
Ｐ６        秋            紅葉        （同じ秋のＰ５と不揃い）
Ｐ７        冬            雪だるま１
Ｐ８        冬            雪だるま２  （同じ冬のＰ７と不揃い）
【０１５９】
これを図２１（ｂ）に示すように各季節毎に統一したページサムネイルになるようにし、文書の体裁を整える状況を想定する。
【０１６０】
この文書が非特許文献２に示すＩＳＯ１５４４４−６で示す符号化方式で符号化されていた場合、各ページサムネイルは図２３に示す“Page  BOX”の最初の“Layout  object  Box”（レイアウトオブジェクトＢＯＸ）にあるため、これを図１８及び図２０で説明した手順により参照処理すると、Ｐ２のサムネイルはＰ１のサムネイルを参照することにより、サムネイルが同一される。Ｐ３，Ｐ４のサムネイルは同じ夏のサムネイルであっても絵柄が不統一なため、例えばＰ３のサムネイルをＰ４の最初のレイアウトボックスに書かれているコードストリームと同じオフセットと長さを参照することにより、Ｐ３，Ｐ４のサムネイルが統一できる。同様にしてＰ６のページサムネイルをＰ５で参照し、Ｐ７のサムネイルをＰ８で参照することにより、図２１（ｂ）に示すような各季節毎にページサムネイルの統一化が図られる。なお、図２１中の４９はドキュメントサムネイルである。
【０１６１】
以上の操作により、同一テーマの各ページで共通のページサムネイルに統一できることとなり文書体裁を整えられるだけでなく、ファイルサイズも削減される。以上が請求項１１の発明についての説明であるが、これは請求項１２の発明の説明を兼ねる。
【０１６２】
すなわち、請求項１２の発明によれば、あるページのページサムネイルがなかったときに、他のページのページサムネイルを参照するが、これはＰ２のサムネイルをＰ１のサムネイルを参照する例において既に説明した通りであり、文書体裁を整えられるだけでなく、ファイルサイズを削減することができる。
【０１６３】
また、請求項１３の発明によれば、各文書で共通のドキュメントサムネイルに統一する。図２１ではページサムネイルの統一、補完を示したが、同様な操作を各文書にまたがってドキュメントサムネイルについて行うわけである。その具体的操作の内容は、請求項１１の発明についての上記説明において、下記に示すように、
（１）ページサムネイルをドキュメントサムネイル
（２）各ページの最初のレイアウトボックスを、図６の上から６番目にある“Contigeous  Codestream  BOX”
（３）自ファイル内での参照はなく、他のローカル・ファイル又はリモート・ファイル
それぞれ読み替えて理解すればよい。
【０１６４】
請求項１４の発明は、ＩＳＯ１５４４４−２に準拠したファイルを処理対象とすることが特徴である。すなわち、非特許文献３に示されるＪＰＸファイルは共有／参照を行う構造をもっているため、以上に説明した変換処理を実行することにより、国際標準互換を保った上での可逆再圧縮が可能である。
【０１６５】
請求項１５の発明は、ＩＳＯ１５４４４−３に準拠したファイルを処理対象とすることが特徴である。すなわち、ＩＳＯ１５４４４−３に準拠したＭＪ２ファイルは共有／参照を行う構造をもっているため、以上に説明した変換処理を実行することにより、国際標準互換を保った上での可逆再圧縮が可能である。
【０１６６】
請求項１６の発明は、ＩＳＯ１５４４４−６に準拠したファイルを処理対象とすることが特徴である。すなわち、非特許文献２に示されるＪＰＭファイルは共有／参照を行う構造をもっているため、以上に説明した変換処理を実行することにより、国際標準互換を保った上での可逆再圧縮が可能である。
【０１６７】
請求項１７の発明は、ＰＤＦ仕様に準拠したファイルを処理対象とすることが特徴である。すなわち、ＰＤＦファイルは共有／参照を行う構造をもっているため、以上に説明した変換処理を実行することにより、ＰＤＦ互換を保った上での可逆再圧縮が可能である。
【図面の簡単な説明】
【０１６８】
【図１】本発明の前提となる離散ウェーブレット変換に基づく符号化・復号化方式の基本となる階層符号化アルゴリズムを実現するシステムの機能ブロック図である。
【図２】原画像の各コンポーネントの分割された矩形領域を示す説明図である。
【図３】デコンポジションレベル数が３の場合の、各デコンポジションレベルにおけるサブバンドを示す説明図である。
【図４】プレシンクトを示す説明図である。
【図５】ビットプレーンに順位付けする手順の一例を示す説明図である。
【図６】符号列データの１フレーム分の概略構成を示す説明図である。
【図７】符号化されたウェーブレット係数値が収容されたパケットをサブバンド毎に表わしたコードストリーム構造を示す説明図である。
【図８】ＪＰＭファイルのデータ構成を示す模式図である。
【図９】本実施の形態の符号変換装置のハードウェア構成を示すブロック図である。
【図１０】符号変換装置の機能構成を示すブロック図である。
【図１１】符号変換装置の動作説明のためのフローチャートである。
【図１２】図１１中のステップＳ９で呼び出される共有処理における処理の流れを示す図である。
【図１３】図１１中のステップＳ９で呼び出される参照処理における処理の流れを示す図である。
【図１４】レンダリング画像例を示す図である。
【図１５】図１４の各レイアウトオブジェクトに書かれた同一の著作権表示メタデータを共有するＪＰＭファイルの例を示す図である。
【図１６】参照のないファイルを参照のあるファイルにしてコンパクトにしたＪＰＭファイルの例を示す図である。
【図１７】複数のページに渡って共通な部分を示す図である。
【図１８】ＪＰＸファイルで他のファイル内の情報を参照する場合の動作を説明するための図である。
【図１９】参照する／しないＢＯＸを指定する場合のイメージを示す図である。
【図２０】図１５の共有処理後のステータスレポート例を示す図である。
【図２１】ページサムネイルの統一、補完を説明する図である。
【図２２】シーケンシャルＤＣＴ、プログレッシブＤＣＴ，ロスレスＤＣＴのシンタックスを示す図である。
【図２３】ＪＰＭファイルの概念的構造を示す図である。
【符号の説明】
【０１６９】
３０      Entropy-coded  segment  0（エントロピー符号化セグメント０）
３１      Entropy-coded  segment  n（エントロピー符号化セグメントｎ）
３２      リスタート間隔終端シンボル
３３      ｓｃａｎ１
３４      フレーム
３５      ＳＯＩマーカセグメント
３６      ＥＯＩマーカセグメント
３７      Contiguous  Codestream  Box
３８      Metadata  Boxes
４０      参照する符号
４１      参照しない符号
４２      Shared  Data  Entry  Box
４３      Shared  Data  Reference  Box
４４      オフセット
４５      長さ
４６      ステータスレポートのオブジェクト対照部
４７      ステータスレポートの統計部
４８      ページサムネイル
４９      ドキュメントサムネイル
【図１】
0004812585.tif 000002
【図２】
0004812585.tif 000003
【図３】
0004812585.tif 000004
【図４】
0004812585.tif 000005
【図５】
0004812585.tif 000006
【図６】
0004812585.tif 000007
【図７】
0004812585.tif 000008
【図８】
0004812585.tif 000009
【図９】
0004812585.tif 000010
【図１０】
0004812585.tif 000011
【図１１】
0004812585.tif 000012
【図１２】
0004812585.tif 000013
【図１３】
0004812585.tif 000014
【図１４】
0004812585.tif 000015
【図１５】
0004812585.tif 000016
【図１６】
0004812585.tif 000017
【図１７】
0004812585.tif 000018
【図１８】
0004812585.tif 000019
【図１９】
0004812585.tif 000020
【図２０】
0004812585.tif 000021
【図２１】
0004812585.tif 000022
【図２２】
0004812585.tif 000023
【図２３】
0004812585.tif 000024