(57)【特許請求の範囲】
【請求項１】
メモリーと、
モデル画像が、タイトル欄を含みかつ第１の組のアフィン座標によって表現され、第１の組のアフィン座標が、オブジェクトに基づくアフィン座標軸により定まり、複数のモデル画像の少なくとも１つが、１つかまたはそれ以上の原稿ページを記憶するのに使用するためのインデックス情報を有するテキストを含む領域を含む、前記メモリーに記憶された複数の該モデル画像と、
オブジェクトに基づくアフィン座標軸により定まる第２の組のアフィン座標として表現される検索画像と、
第２の組のアフィン座標と第１の組のアフィン座標の内のタイトル欄に対応する部分とを対応させてインデックス情報を有するテキストを含む領域を得るための、前記メモリーと通信する画像位置探索モジュールと、
１つかまたはそれ以上の原稿ページを記憶するために、テキストを含む領域からインデックス情報を抽出するための、前記画像位置探索モジュールと通信するテキスト抽出モジュールと、
を備えたドキュメント処理システム。
【請求項２】
モデル画像が、タイトル欄を含みかつ第１の組のアフィン座標によって表現され、第１の組のアフィン座標が、オブジェクトに基づくアフィン座標軸により定まり、複数のモデル画像の少なくとも１つが、１つかまたはそれ以上の原稿ページを記憶するのに使用するためのインデックス情報を有するテキストを含む領域を含む、複数のモデル画像が記憶されるメモリーを有するドキュメント処理システムにおいて、検索画像を自動的に処理して１つのモデル画像のテキストを含む領域からインデックス情報を得るためのインデックス情報獲得方法であって、
（ａ）オブジェクトに基づくアフィン座標軸により定まる第２の組のアフィン座標として検索画像を表現するステップと、
（ｂ）第２の組のアフィン座標と第１の組のアフィン座標の内のタイトル欄に対応する部分とを対応させてインデックス情報を有するテキストを含む領域を得るステップと、
（ｃ）１つかまたはそれ以上の電子的な原稿ページを記憶するのを容易にするために、前記ステップ（ｂ）に応答して、テキストを含む領域からインデックス情報を抽出するステップと、
を備えたインデックス情報獲得方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、パターン位置探索に関し、より詳細には、２次元パターン位置探索とテキスト認識とを組み合わせてインデックステキストキーワードを抽出するのを可能にするシステムに関する。
【０００２】
なお、本出願は、１９９８年１２月１８日に米国に出願した仮出願第６０／１１２，９２７号に基づくものである。
【０００３】
【従来の技術】
画像内容に基づく検索は、従来のテキスト注釈に基づく検索の代わりとなるあるいはそれに追加される有効な検索方法となりつつある。それでも、テキストに基づく検索が有するロバストネスおよび演算効率をまだこれから達成しなければならない。一方、テキストに基づく検索は、キーワードのブール組み合わせが可能であっても、すっかり評判になるほどに正確さに欠ける。良く知られた従来の探索方法を使用する者には、原稿（スキャンされた電子的な原稿）の全テキストインデックス付けは、関連性のないきわめて多くの原稿を検索しなければならないことが一般に知られている。
【０００４】
テキストに基づく検索のより生産性のある使用は、それが画像内容に基づく検索と組み合わせられた場合である。
【０００５】
技術図面の原稿を電子変換することは、大画面スキャナーを製造するメーカーにとって重要な仕事である。良く知られるように、大画面スキャナーは、２５枚／分の比較的に速い速度で技術図面の原稿をスキャンすることができ、大型の図面画像（例えば、１４０００×９０００画素）からなるきわめて大きなデータベース（１００，０００オブジェクト以上の）をすぐに発生させる。一般には、そのような原稿へのインデックス付けは、熟練したキーボードオペレータの手作業でなされ、スキャンされた画像をディジタル化するのにかなりのコストがかかる高い労働集約型の作業と考えられている。さらに、キーボードオペレータの手作業によるインデックス付けは、信頼できない場合がある。なぜなら、ユーザが使用するキーワードは、データベースの生成において原稿に付与されたものと一致しないことがあるからである。
【０００６】
純粋なテキスト原稿の全テキストインデックス付けとは対照的に、従来のＯＣＲアルゴリズムを用いた自動全テキストインデックス付けは、図面画像の場合には有効な結果をもたらさない。幸いにも、そのような図面画像にインデックスを付けるのに有効なテキスト情報が、「タイトル欄」と呼ばれる特定の画像構造に存在する。典型的には、タイトル欄は、部品番号、描写されるユニットの名称、設計日付、および、設計者の氏名のような、対応する図面にインデックスを付けることに関係のある情報を含む。そのような画像構造からインデックスキーワードを抽出するためには、まず最初に、画像構造自体が識別されなければならない。
【０００７】
図面原稿への手作業によるインデックス付けは、時間がかかり、したがって、望ましいものではない。さらに、関連するインデックステキストは、予め記憶された図面原稿に組み込まれている２次元パターン（例えば、タイトル欄）からより容易に得ることができる。しかしながら、本質的に存在するこれらのパターンを識別することは難しい場合がある。なぜなら、そのパターンの隣接するその他の多くのパターンとの相対的な向きおよび／または位置は、一般にはわからないからである。
【０００８】
【発明が解決しようとする課題】
予め記憶された第１の組の図面原稿に基づいて検索画像の位置を突き止めることによって、予め記憶された第１の組の図面原稿からインデックス情報を自動的に得て、第２の組の図面原稿を記憶するのに使用するために、対応するテキストをそれから抽出することのできるインデックス付けシステムを提供することは望ましいことである。
【０００９】
【課題を解決するための手段】
上記目的達成のため請求項１記載の発明は、メモリーと、 モデル画像が、第１の組の情報によって表現され、第１の組の情報が、オブジェクトに基づく座標の関数として変化し、複数のモデル画像の少なくとも１つが、１つかまたはそれ以上の原稿ページを記憶するのに使用するためのインデックス情報を有するテキストを含む領域を含む、前記メモリーに記憶された複数の該モデル画像と、 オブジェクトに基づく座標の関数として変化する第２の組の情報として表現される検索画像と、 第２の組の情報と第１の組の情報の一部分とを対応させてテキストを含む領域を得るための、前記メモリーと通信する画像位置探索モジュールと、１つかまたはそれ以上の原稿ページを記憶するのを容易にするために、テキストを含む領域からインデックス情報を抽出するための、前記画像位置探索モジュールと通信するテキスト抽出モジュールと、を備えている。
【００１０】
請求項２記載の発明は、モデル画像が、第１の組の情報によって表現され、第１の組の情報が、オブジェクトに基づく座標の関数として変化し、複数のモデル画像の少なくとも１つが、１つかまたはそれ以上の原稿ページを記憶するのに使用するためのインデックス情報を有するテキストを含む領域を含む、複数のモデル画像が記憶されるメモリーを有するドキュメント処理システムにおいて、検索画像を自動的に処理して１つのモデル画像のテキストを含む領域からインデックス情報を得るためのインデックス情報獲得方法であって、（ａ）オブジェクトに基づく座標の関数として変化する第２の組の情報として検索画像を表現するステップと、（ｂ）第２の組の情報と第１の組の情報の一部分とを対応させてテキストを含む領域を得るステップと、（ｃ）１つかまたはそれ以上の電子的な原稿ページを記憶するのを容易にするために、前記ステップ（ｂ）に応答して、テキストを含む領域からインデックス情報を抽出するステップと、とを備えている。
【００１１】
本発明によれば、メモリーと、モデル画像が、第１の組の情報によって表現され、第１の組の情報が、オブジェクトに基づく座標の関数として変化し、複数のモデル画像の少なくとも１つが、１つかまたはそれ以上の原稿ページを記憶するのに使用するためのインデックス情報を有するテキストを含む領域を含む、前記メモリーに記憶された複数の該モデル画像と、オブジェクトに基づく座標の関数として変化する第２の組の情報として表現される検索画像と、第２の組の情報を第１の組の情報の一部分と対応させてテキストを含む領域を得るための、前記メモリーと通信する画像位置探索モジュールと、１つかまたはそれ以上の原稿ページを記憶するのを容易にするために、テキストを含む領域からインデックス情報を抽出するための、前記画像位置探索モジュールと通信するテキスト抽出モジュールと、を備えた原稿処理システムが提供される。
【００１２】
【発明の実施の形態】
以下、図面を参照して、本発明の実施の形態を詳細に説明する。
〔データベースにおける検索２次元オブジェクトの位置探索〕
１．概論
以下の説明においては、図面データベース内のタイトル欄パターンにインデックスを付ける問題が考察される。より詳細には、ロケーションハッシングと呼ばれる、データベースに含まれる画像内の任意の検索２次元パターンにインデックスを付けるための技術が提供され、この技術が、技術図面画像内のタイトル欄の位置を突き止める問題に適用される。ロケーションハッシングは、幾何学的ハッシングの変形であり、データベース内の関連画像と２次元パターンをもっとも含んでいそうなそれらの画像内の領域とを同時に判定する。さらに、ロケーションハッシングを用いてタイトル欄の位置を突き止め、これらの領域からインデックステキストキーワードを抽出する技術図面画像インデックスシステムが説明される。これは、従来のテキスト処理装置を用いて図面原稿を検索するのを可能にする。
【００１３】
２．タイトル欄の位置探索
セグメント化されていない図面画像内のタイトル欄パターンの検出は、いくつかの理由のために難しい問題である。まず最初に、タイトル欄は、様々な様式を有することがある２次元パターンである。図２および図３を参照すると、様々なタイトル欄またはパターンが図面ごとに存在する可能性があることがわかる。これらのパターンは、図面の様々な位置に描写されてもよく（図１）、また、スキャン処理に依存して様々な向きで描写されてもよい。さらに、タイトル欄は、その他の表パターン領域とごちゃまぜになることがあり、他の輪郭と結合しているように見え、および／または、スキャンの解像度のために、ノイズののった不要な特徴を有する。最後に、タイトル欄パターンは、元々は手書きであるので、同じ基本様式を有するパターンであっても、輪郭の相対的な位置が変化することがあり、さらに、フィールド情報も変化する。
【００１４】
いくつかの様式認識ソフトウェアパッケージ（例えば、アキュフォーム（Ａｃｃｕｆｏｒｍ）、ファースト（ＦＩＲＳＴ）、オムニフォーム（ＯｍｎｉＦｏｒｍ）など）が市販されているが、これらの方法は、一般に、様式自身を多かれ少なかれ含む画像内の制約された姿勢（ｐｏｓｅｓ）で様式を認識する。これらは、技術図面にインデックスを付けるためには不十分なものである。なぜなら、タイトル欄パターンは、姿勢に依存することなく認識されなければならないだけでなく、まず最初に、インデックスを付けられなければならないからである。すなわち、タイトル欄を含んでいそうな画像内の関連する領域だけでなくデータベースに含まれる関連画像も識別されなければならない。
【００１５】
この理由から、タイトル欄の位置探索は、データベースに含まれるセグメント化されていない画像内の検索２次元パターンの位置探索に関する一般的問題の例と考えられる。これは、内容に基づく検索におけるもっとも難しい問題の１つであり、比較的に少ない研究者しか研究していないと思われる。この問題の解決方法は、データベースに含まれる関連画像に加えて、そのような画像内のパターンを含んでいそうな候補領域をも識別することのできる演算効率の良い方法でなければならない。解決方法は、データベースかまたは画像自体のいずれかを子細に探索することなく達成することができるものでなければならない。
【００１６】
ここで、ロケーションハッシングと呼ばれる画像データベース内の２次元パターンの位置を突き止めるための技術を説明する。この技術においては、データベースの画像インデックス付けを可能にするために、幾何学的なハッシングが変更される。幾何学的ハッシングの基礎をなす前提条件およびハッシュテーブルＨの展開については上で詳細に説明した。
【００１７】
２．１  ロケーションハッシング
ロケーションハッシングは、画像インデックス付けが有する問題を解決する。
すなわち、その目的は、データベース内の検索パターンを含む関連画像を識別するためだけでなく画像内の２次元パターンを含む領域の位置を突き止めるためにもハッシング技術を使用することである。それの元々の形態での幾何学的ハッシングは、２つの理由から、ロケーションハッシングに直接に適用できるとは考えられない。まず第１に、ハッシュテーブルが、すべての可能な基準トリプルを考えることによって完全に同じように組み立てられても、これは演算的に不可能である。具体的には、それは、画像に必要なハッシュテーブルのサイズはＯ（Ｐ＊Ｎ４ ）と表現されることが示され、ここで、Ｐは、画像の数であり、Ｎは、１画像当たりの特徴の数である。典型的な画像の場合、Ｎは、約１０００の特徴（例えば、角）であり、その結果として、データベースに１つの画像が存在する場合でさえも、ハッシュテーブルのサイズは、Ｏ（Ｎ４ ）〜１０１２  になることがあり、ハッシュテーブルとしては実現できない大きさである。
【００１８】
第２に、すべての特徴のアフィン座標がすべての基準トリプルに基づいて計算されても、もっとも大きなヒット数は、画像全体に分布する特徴の任意のトリプルから得られる１つの基準点に対するものであるかもしれない。したがって、もっとも大きなヒット数に対するハッシングは、ただ１つの画像位置に対応するとは限らない。ハッシュテーブルを生成する前に特徴のグループ化がなされるならば、これらの２つの問題のいずれをも軽減できる。しかしながら、グループ化における信頼性を実現するのは、シーンに発生するすべてのオブジェクトの場合はいうまでもなく、単一のオブジェクトの場合でさえも難しいことが知られている。さらに、一般的なグループ化方式は、画像に存在するオブジェクトの数より相当に多いグループの数を提供して偽陰性を回避する。これが、さらに、ハッシュテーブルのサイズを増大させる。
【００１９】
ロケーションハッシングは、ハッシュテーブルを組み立てる際に中間コースを通り、それは、完全にグループ化された特徴を備えたバージョンと、すべての基準トリプルを考察するグループ化されていないバージョンと、の中間に位置する。より詳細には、特徴が、単一のオブジェクトから得られそうな構造から選択され、そして、少数のグループを提供するために、特徴が大まかにグループ化される。具体的には、特徴を生成するために、曲線が基準ユニットとして選択され、基準点を生成するために、連続する角特徴が曲線に沿って選択される。たとえすべての曲線が単一のオブジェクトから得られなくても、（とくに、オクルージョンおよびノイズが存在する場合には）曲線内から生成される特徴は画像全体から任意に選択された特徴の任意の基準トリプルよりも単一の画像の位置を指示しそうであるという論理的根拠に基づいて、曲線が選択される。
【００２０】
さらに、連続する角点を選択する際に曲線順序付けを使用することは、線の数の基準特徴だけをハッシュテーブルに記録すればよいことを保証する。しかしながら、曲線だけでは、頑健なインデックス付けを実現するに足るだけの多くのグループを含まないことがある。グループ自体が信頼性がない場合を除けばインデックス付けにおける信頼性は多くのグループを使用することによって増大することを従来の研究も説明している。したがって、インデックス付けのために、曲線のグループを形成する。いくつかの曲線グループ化技術が文献から利用できる。
グループ化の制約の選択は、アプリケーション領域において変化してもよく、ここでは特定しない。しかしながら、グループ化の制約は、少数のグループ（おそらくは、線の数）が比較的に高速の方法で生成されることを保証するものでなければならない。
【００２１】
２．２  ロケーションハッシュテーブルの構造
この章は、次の２．３章とともに、図４のフローチャートを参照しながら読んでいただきたい。したがって、フローチャートの参照符号が以下の説明で使用される。
【００２２】
図４のステップ１００を参照すると、モデル画像が、データベースに提供される（ステップ１００）。曲線が、データベースのすべての画像から抽出され（ステップ１０１）、連続する角特徴が抽出される。曲線のグループ（曲線グループ）が、適切なグループ化技術（そのようなグループ化の１つが次の章で説明される）を用いて形成され（ステップ１０２）、特徴が、曲線グループから抽出される（ステップ１０３）。基準トリプルが、曲線に沿った連続する特徴から生成される（ステップ１０４）。曲線グループ内の曲線上のそれぞれの基準トリプルごとに、曲線グループ内のすべてのその他の特徴のアフィン座標が計算される（ステップ１０５）。この処理は、データベースのすべての画像内のすべての曲線グループに対して反復される。それぞれの基準トリプルＢごとに、曲線グループＲＢ が抽出され、ロケーションインデックスとして機能する。さらに、それぞれの基準トリプルＢが属する画像ＩｍＲＢが指示される。結果として、それぞれのアフィン座標（α，β）が、トリプルのリストに対応づけられ、
【００２３】
【数１】
0004577931.tif 000002
【００２４】
そして、それが、ハッシュテーブルに記憶される（ステップ１０６）。
【００２５】
実際には、ハッシュテーブルは、アフィン座標空間の量子化されたバージョンであり、量子化レベルは、画像サイズと特徴セットとの関数である。画像のサイズはデータベース内で変化してもよいが、それぞれのタイプのデータベースは、それ自身の典型的なサイズを有する。したがって、技術図面データベースは、高い解像度でスキャンされたサイズが９０００×１４０００の技術図面から構成されてもよく、ビデオカメラから生成されたシーン画像データベースは、典型的には、サイズが５１２×６４０の画像を含む。また、特徴セットは、とくに特徴の分布に基づいてハッシュテーブルの量子化を決定する。技術図面画像においては、例えば、曲線は、鋭い角を端部に備えた長い直線である傾向があり、曲線に沿った連続する点のアフィン座標をさらに引き離し、より粗い量子化を可能にする。一般に、緻密な量子化は、正確な一致が検索に必要とされる場合に適しているが、必要とされるメモリー量のためにコストがかかる場合がある。粗い量子化は、検索を記憶されたモデルに一致させるのに柔軟性を与えるが、好ましくないかなりの数の誤った一致をもたらす。
【００２６】
２．２．１  幾何学的（または、ロケーション）ハッシュツリー
適切な量子化が選択された後であっても、その結果として得られた対応するアフィン座標平面のアレイサイズは、かなり大きい場合がある。例えば、典型的な技術図面データベース領域を使用すると、それぞれのアフィン座標の観測される範囲は、（−１００００．０，１００００．０）にある。１．０の量子化レベルを使用すると、簡単なアレイを実現することによって、約４×１０１１すなわち４０ギガバイトのアレイサイズが得られ、既存のいずれのコンピュータのメインメモリーにも収容するには大きすぎるテーブルである。ほとんどすべてのユニットは空なので、アフィン座標空間のそのような一様な分割は必要がなく、したがって、よりぎっしりと詰まった表現が推奨される。
【００２７】
上述の画像データベースにおいては、典型的には、４×１０１１個のセルの中の多くとも２０００個が動作しているに過ぎない。したがって、ロケーションハッシュテーブルは、釣り合いのとれたバイナリー・サーチ・ツリーのようなよりぎっしりと詰まった構造によって物理的に表現されてもよい（ステップ１０７、１０８）。よりぎっしりと詰まった構造を実現するために、単純な２次元順序付けが、対応するアフィン座標に使用され、アクティブエントリーが、バイナリー・サーチ・ツリーとしてアフィン座標平面に編成された。
【００２８】
１つの例においては、アフィン座標（α，β）の空間は、２つに分割される。
すぐ下で説明するように、分割は、複数に分割される形態であってもよく、簡単な方式が選択された。それによれば、ノードの順序付けは、値（α１ ，β１ ）を有するノードの左側のサブツリーにあるすべてのノードがそれらのアフィン座標（α，β）を有するようなものであり、そのために、（α＜α１ ，β＜β１ ）となり、また、右側のサブツリーにあるすべてのノードは、α≧α１ かまたはβ≧β１ を有するが、（α＝α１ かつβ＝β１ ）ではない。図５に示されるように、１つかまたは複数の画像を表現する曲線グループは、４つの部分に分割されてもよい（２つの部分とは対照的に）。図４に示される処理は、複数の部分に分割すること（例えば、４つかあるいは２つに）を意図するものであることを十分に理解されたい。
【００２９】
バイナリー・サーチ・ツリーの釣り合いを保つために、それを表現するのに赤黒ツリーとしてそれを表現したい。赤黒ツリーは、それぞれのツリーノードに付与されたさらなるカラー情報を備えたバイナリー・サーチ・ツリーであり、以下の性質を有する。（１）すべてのノードは赤か黒のどちらかである。（２）すべてのリーフ（ツリー構造の終端の項目）（ＮＩＬ）は黒である。（３）もしノードが赤であれば、その２人の子は黒である。（４）ノードからその子孫の先端までの単純なすべての経路は、同じ数の黒ノードを含む。これらの性質によって、赤黒ツリーは釣り合いを保つことができる。具体的には、ｎ個の内部ノードを有する赤黒ツリーは、大きくても２ｌｏｇ（ｎ＋１）の高さしかないことがわかる。
【００３０】
幾何学的ハッシュツリー（ＧＨＴ）表現またはロケーションハッシュツリー（ＬＨＴ）表現を使用すると、ロケーションハッシュテーブル内の空でないそれぞれのエントリーは、ノードＮ１ によって表現され、ここで、
【００３１】
【数２】
0004577931.tif 000003
【００３２】
ここで、Ｎは、ロケーションハッシュテーブル内の占有されたセルの数であり、ｌｅｆｔ（ｉ）およびｒｉｇｈｔ（ｉ）は、左右のポインターである。（Ｉαｉ ，Ｉβｉ ）は、選択された量子化に基づいたハッシュテーブル内のアフィン座標（α，β）のインデックスであり、
【００３３】
【数３】
0004577931.tif 000004
【００３４】
ここで、Ｃ（ｉ）は、２つのカラーの一方、すなわち、赤かまたは黒である。
Ｄａｔａ（ｉ）のセットは、すべてのアフィン座標に関する情報の集合を表し、それらは、（Ｉα，Ｉβ）で表現されるセルに入る。Ｆｊｔは、セルのアフィン座標を発生させる基準トリプルの基準トリプル情報のリストであり、ｋｉ は、ノードｉごとのデータエントリー数を表す。
【００３５】
２．２．２  ＧＨＴにおける挿入
画像のグループ（領域）からアフィン座標が生成された後、以下のようにしてＧＨＴが組み立てられる。計算されたそれぞれの新しいアフィン座標特徴は、ｚ＝（ｋｅｙ（ｚ），ｃｏｌｏｒ（ｚ），ｄａｔａ（ｚ），ＮＩＬ，ＮＩＬ）によって表され、ここで、ｋｅｙ（ｚ）＝（Ｉα，Ｉβ）、ｃｏｌｏｒ（ｚ）＝ＲＥＤ、そして、
【００３６】
【数４】
0004577931.tif 000005
【００３７】
である。
【００３８】
特徴の挿入は、２つのステップ、すなわち、ツリーの探索および挿入とツリーの釣り合いを保つこととからなる。ツリーの挿入は、ノードにおいてキーが一致すればデータ成分が以下のようにして更新されることを除けば、従来のバイナリー・サーチの場合と同じように行われる。
【００３９】
【外１】
0004577931.tif 000006
【００４０】
上述において、ｐ〔ｘ〕は、ノードｘの親を表現し、Ｔは、ＧＨＴのルートノードへのポインターである（これは最初はＮＩＬである）。
【００４１】
従来の赤黒ツリーと同じように釣り合いが保たれ、さらに、探索がなされ、上で略述した赤黒ツリーの釣り合い特性を保つためにツリーを回転させる。具体的には、ＧＨＴのバイナリー・サーチ・ツリーの形状は、ノードに新たに色付けすることによって、また、回転させることによって変更される。以下に示される釣り合わせのためのほとんどのコードは、変更されたツリーが設定されたときに発生するかもしれない様々な事態を処理する。以下においては、上に示されたＴＲＥＥ  ＩＮＳＥＲＴ（Ｔ，ｘ）がすでに実行されており、かつ、ｃｏｌｏｒ〔ｘ〕＝ＲＥＤであると仮定する。
【００４２】
【外２】
0004577931.tif 000007
【００４３】
上において、ｐ〔ｘ〕は、ノードｘの親を表現し、ＬＥＦＴ−ＲＯＴＡＴＥは、次のように与えられる。
【００４４】
【外３】
0004577931.tif 000008
【００４５】
ＲＩＧＨＴ−ＲＯＴＡＴＥのためのコードもこれに類似したものである。ＬＥＦＴ−ＲＯＴＡＴＥおよびＲＩＧＨＴ−ＲＯＴＡＴＥのいずれもがＯ（１）回だけ実行される。ＧＨＴ（赤黒ツリーである）の高さはＯ（ｌｏｇｎ）であるので、負担のかかるｎ個のノードを有するＧＨＴへの挿入は、Ｏ（ｌｏｇｎ）回目に達成される。
【００４６】
２．３  ２次元パターンのためのインデックス付け
この章は、図６を参照しながら読んでいただきたい。図６のとりわけステップ１１６を参照すると、検索画像すなわち２次元パターンが提供される。幾何学的ハッシュツリーによって表現されたデータベースに含まれる画像内の２次元パターンの位置を探索するために、パターンが処理され、前章で説明したようなやり方でアフィン座標特徴が生成される（ステップ１１８）。ステップ１１６および１１８は、図４に示されるフローチャートのステップ１０１〜１０５に類似している。
【００４７】
ＧＨＴにインデックスを付けるために、それぞれのパターン曲線グループからのアフィン座標特徴が次々に使用され（ステップ１２０）、複数の基準トリプルとそれらに対応する領域及び画像インデックスとの潜在的な一致を検索する。インデックスを付けられた基準トリプルすなわち「ヒット」のヒストグラムが得られ、ヒストグラムのピークは、検索基準トリプルにもっとも一致しそうな基準トリプルを示す。同様に、図６のステップ１２４によって強調されるように、インデックス付けされた領域のヒストグラム（いくつかの検索基準トリプルから生成されたアフィン座標を使用して得られた）は、もっともパターンを含んでいそうな領域（すなわち、もっとも期待できそうな画像）を指示する。位置探索は、もっともオブジェクトを含んでいそうな箇所しか指示しないので（必ずそうするとは限らないが）、好ましくは、位置探索の後に確認段階（ステップ１２６）が続く。
【００４８】
以下のアルゴリズムは、さらに詳細に位置探索を説明する。
【００４９】
【外４】
0004577931.tif 000009
【００５０】
上のアルゴリズムにおいて、Ｒは、検索領域（特徴グループ）を表し、ＦＱ （Ｒ）は、検索グループＲから生成されたアフィン座標特徴のセットを表す。それぞれのアフィン座標特徴は、Ｆｑ ＝（ｋｅｙ（Ｆｑ ），ｄａｔａ（Ｆｑ ））であり、ここで、アフィン座標αおよびβに対して、
【００５１】
【外５】
0004577931.tif 000010
【００５２】
である。ＧＨＴ（ＬＨＴ（または、ＧＨＴ）−ＩＮＤＥＸ）のインデックス付けは、ＴＲＥＥ−ＩＮＳＥＲＴの前に実行されたバイナリー・サーチに類似する。
ノードにおいて一致が検出されると、ノードのデータ成分が戻される。一致が検出されなければ、探索はリーフノードの外に到達し、ＮＩＬが戻される。
【００５３】
項ｈ（ｉ）は、それぞれの量のヒストグラムを表し、（ＢＭ ，ＲＭ ，ＩＭ ）は、それぞれ、もっとも検索オブジェクトを含んでいそうな基準トリプル、もっとも検索オブジェクトを含んでいそうな領域、および、もっとも検索オブジェクトを含んでいそうな画像である。最初の２つの量は、基準トリプルのヒストグラムにおけるピークおよびＧＨＴにおける領域「ヒット」に対応する。画像インデックスは、もっとも期待できそうな領域がそこから発生する画像である。ＱＵＥＲＹ−ＩＮＤＥＸから得られる結果は、領域に対して適切に選択されたしきい値ＴＢ およびＴＲ に対してｈ（ＢＭ ）＞ＴＢ かつｈ（ＲＭ ）＞ＴＲ であれば、高い信頼度で受け入れることができる（例えば、９５％以上の検索特徴グループアフィン座標を基準トリプルが占めるならば、判定基準が満足される）。特徴グループは、少なくとも１つの検索領域（曲線グループ）が対応するデータベースに含まれる画像から一致するグループをうまく検出できるまで、ＧＨＴに次々にインデックスを付けるのに使用される。そして、基準トリプルの一致からリカバーされた変換値を用いて潜在的な画像領域に検索をプロジェクトすることによって、期待できそうな候補位置が検査されなければならない。
【００５４】
２．４  ロケーションハッシングを用いたタイトル欄の位置探索
ここで、上述したことを考慮して、タイトル欄パターンの位置を突き止めるためのロケーションハッシング技術が適用される。位置探索のために使用するパターンは、トレーニング段階においていつでも手に入れることができると仮定し、サンプル画像から典型的な領域をクロップすることによって得ることができる。
特徴抽出処理（これは、タイトル欄とスキャン画像とにまったく同じように適用される）は、以下のようになる。
【００５５】
図面画像は、サイズが比較的に大きい場合があるので（例えば、４００ｄｐｉのスキャン解像度で１４０００×９０００）、まず最初に、それらの画像が、一定サイズに正規化される（ロケーションハッシングはスケールに依存しないので、画像正規化はハッシングに悪影響を与えることはない）。輪郭画素の連結領域だけを残すために、スケーリングされ正規化された画像がさらに処理される。個々の曲線を提供するために境界輪郭がなぞられる。そして、単一深度で先着順にツリーを横断することによって、曲線に沿った点の順序付けがなされる。
【００５６】
次に、スケーリングされた画像から連結成分が抽出される。単一の連結領域から得られた曲線をグループ化することによって、曲線のグループが形成される。
この簡単なグループ化は、グループの中の線の数を確保し、タイトル欄（周囲の輪郭と結合されているかもしれない）を含む領域を分離することができる。角特徴が、すべての曲線から抽出され、単一の曲線に沿った連続する角点が、基準トリプルを形成するのに使用される。
【００５７】
グループに存在するすべての角特徴のアフィン座標が、グループの基準トリプルに基づいて計算される。類似する処理が、タイトル欄パターンにもなされる。
アフィン座標のための量子化レベルが、トレーニングに使用されたタイトル欄のアフィン座標の分布から選択され、そのようなタイトル欄の位置を突き止めるのにふさわしい量子化レベルを提供する。前章で説明したように、基準点のＧＨＴが生成され、そこに、それぞれの基準トリプルの領域および画像インデックスが基準トリプルとともに記憶される。
【００５８】
与えられたタイトル欄にあるもっとも大きな曲線グループから開始し、記録されたヒット数によっておそらく一致するであろうことが確認できるまで、それぞれの曲線グループが技術図面データベースのＧＨＴにインデックスを付けるのに次々に使用される。結果として得られた一致した基準点が、潜在的なアフィン変換値をリカバーするのに使用され、タイトル欄が、検査のために、指示された位置にプロジェクトされる。ロケーションハッシングには角特徴が使用されたが、検査には曲線グループの中の直線が適切に使用される。
【００５９】
３．インデックスキーワードの抽出
上述したタイトル欄の位置探索の目的は、図面画像内の位置を突き止められた領域からインデックスキーワードを抽出するのを可能にするためのものであった。しかしながら、タイトル欄のすべてのフィールドが、関連するインデックス情報を含むとは限らない。例えば、図２および図３のタイトル欄の一方または両方において、会社ラベル、日付、図面番号などを備えたフィールドの値は、インデックス付けには重要と思われる。重要なインデックス情報を含む領域は、タイトル欄パターンの組み立てにおけるトレーニング段階で記入されてもよい。与えられたタイトル欄の中のテキストは、左から右以外の向きで現れてもよいので、テキストの向きは、好ましくは、トレーニングにおいて指示される。
【００６０】
いったんタイトル欄の位置が突き止められると、関連テキスト情報が、以下のようにして抽出される。テキスト領域の元々の既知の位置と向きおよび位置を突き止められたタイトル欄の計算された姿勢を用いて、関連テキストフィールド領域は、タイトル欄内の位置を突き止められ、テキスト情報を好ましく左から右へ順番に現れさせることのできる適切な変換値が得られる。そして、これらの領域は、必要であれば、再びスケーリングされて元の解像度（４００ｄｐｉ）に戻され、正確なテキスト認識を可能にする。タイトル欄フィールドのラベルは活字フォントである場合もあるが、フィールド値はほとんどの場合手書きである（例えば、日付または部品番号）。
【００６１】
信頼性のある汎用の手書き活字体テキスト認識エンジンは市販されていないようなので、手書き活字体認識システム（プロジェクトされスケーリングされた領域がテキスト認識に提供される）が開発された。この手書き活字体認識装置は、手書き活字体文字および機械印刷文字のための文字分類器に基づくニューラル・ネットワークである。
【００６２】
数字、アルファベット、および、英数字の認識は、タイトル欄トレーニング段階において対応するフィールドに提供されたメタデータ（metadata）に基づくテキスト領域のそれぞれに個々に実施されてもよい。ニューラル・ネットワークのためのトレーニングデータは、ＮＩＳＴデータベースおよびＵＮＬＶデータベースのようないくつかの機械印刷および手書き活字体のデータベースからすでに得られている。認識された文字は、ワードに組み立てられ、技術図面から生成された領域用語の辞書が、ワード認識を支援するために使用される。
【００６３】
４．技術図面インデックスシステム
インデックスキーワードを抽出するためのシステムが、ウィンドウズＮＴプラットホームのために開発された。Ｊａｖａに基づいたインタフェースが、トレーニング図面画像から領域をクロップすることによって得られたタイトル欄パターンの簡単なトレーニングに使用された。また、それぞれのインデックスフィールドのメタデータ（フィールド座標、それらのラベル、それらの向き）は、ダイアログボックスによって指示された。そして、タイトル欄テンプレートが、会話モードまたはバッチモードで使用された。
【００６４】
会話式のモードにおいて、個々のユーザは、利用可能なメニューから選択されたタイトル欄テンプレートを用いて、技術図面データベース（一般には、ＴＩＦＦファイルのリスト）にインデックスを付けることを実施することができる。タイトル欄を含む画像のリストが、領域内の認識されたテキストキーワードとともに戻される。これらのキーワードは、個々のそれらの図面画像のインデックスを形成する。
【００６５】
バッチモードは、対応する画像からインデックスキーワードを得るために１組のテンプレートが次々に使用されることを除けば、会話式のモードにやり方が類似する。また、インデックスシステムは、図面をスキャンして「オンザフライ」でインデックスを付けるために、大画面ドキュメントスキャナーと一体化されてもよい。効率的なアルゴリズムを使用することによって、特徴抽出およびＧＨＴの組み立て時間は、約３０秒／画像にまで減少した。テキスト認識は、さらに３０秒を要する。
【００６６】
ここで、図７を参照すると、技術図面インデックスシステム（符号１３０で示される）が、詳細に説明される。このシステムは、熟練したユーザの助けによってタイトル欄に含まれるコメントの位置を突き止めて構文解析するのに必要な情報を学習するトレーニングモジュール（ブロック１３２）を含む。インデックスシステムの３つの主要構成要素は、（ａ）タイトル欄トレーニングのためのトレーニングモジュール、（ｂ）タイトル欄位置探索モジュール（ブロック１３４）、および、（ｃ）テキスト認識モジュール（ブロック１３６）である。インデックスシステム１３０は、大画面スキャナーなどの様々な画像読み取り装置によって実施することができる。さらに、システムは、２つのモードすなわちトレーニングモードまたは認識／インデックス付けモードの少なくとも一方で動作するように意図される。
【００６７】
タイトル欄トレーニングモジュール（図７のブロック１３０）の機能は、後にタイトル欄領域を探索することに関連のある技術図面のタイトル欄領域からの情報を推論することである。トレーニングモジュールは、Ｊａｖａに基づくユーザインタフェースを含み、それによって、スキャンされおよび／または前処理された技術図面画像（ＴＩＦＦフォーマットによる）を表示することができる。熟練したユーザは、図面内のタイトル欄領域を強調表示し、トレーニングモジュールが、拡大された領域をユーザに再表示する。表示された領域は、その後の計算のために基準画像として使用されてもよい。有益なインデックス情報を含むタイトル欄内の領域が、同様に、ユーザによって強調表示される（マウスインタフェースを介して）。それに続いて、強調表示された領域に関するメタデータを入力するために、ダイアログウィンドウがユーザに提供される。一般には、インデックスフィールドの名前、それの内容のタイプ（アルファベット、数字、英数字）、テキストの向き（左から右、上から下、など）、および、テキスト認識を支援するための付加的なコメントが、ユーザによって提供される。タイトル欄領域は、ほとんどの場合、多種多様な向きでテキストを描写するので、テキストの向きを指示することは重要なことがある。
【００６８】
トレーニングセッションの終了時点で、タイトル欄領域に関する以下の情報が生成される。すなわち、（１）タイトル欄の画像領域、（２）画像内におけるそれらの位置およびユーザによって入力されたメタデータを含むインデックスフィールド情報、および、（３）元々のタイトル欄領域の認識のたびに正規化されスケーリングされたバージョン、である。上述の情報は、タイトル欄「モデル」または後にインデックス付けの段階において使用するためのテンプレート情報を備えてもよい。このテンプレートは、選択されたディレクトリーに記憶され、ユーザによって選択された名前が、テンプレート記述へのインデックスとして割り当てられる。そして、このテンプレート名前が、スキャンし自動インデックス付けするときに使用するために、スキャンサブシステムのテンプレートメニューに現れる。
【００６９】
１つの例においては、タイトル欄位置探索モジュール（図７のブロック１３２）は、入力として、スキャンされ前処理された技術図面とユーザが選択したタイトル欄テンプレートとをＴＩＦＦフォーマットで受け取る。このモジュールは、ユーザ選択テンプレートに対応する領域がスキャンされた画像内に存在するかどうかを判定する。判定には、上述したロケーションハッシング技術を使用し、このロケーションハッシング技術によって、姿勢に依存しない特徴が、与えられた画像だけでなくタイトル欄テンプレートからも抽出される。画像内の特徴は、釣り合いのとれたバイナリー・サーチ・ツリーすなわち幾何学的ハッシュツリーを用いて効率的な探索ができるように、ぎっしりと詰めて表現および編成される。
【００７０】
上述したように、同じアフィン座標を有する、すなわち、タイトル欄領域が存在する可能性を有する特徴の集合を有する画像内の候補位置を指示するために、オブジェクトに基づく座標（例えば、アフィン座標）が、ＧＨＴにインデックスを付けるのに使用されてもよい。１つの例では、このインデックス付けにおけるいちばん上の５つのヒットが残されかつユーザに表示される。予想されるように、いちばん上のヒットは、検索オブジェクトまたは検索図面内のタイトル欄の位置を指示する。ここで説明される位置探索技術は、図面の姿勢または向きを規定するので、必要であれば、テキスト認識を開始するために、左から右へ適切な向きにテキストを含むように与えられたタイトル欄内の個々のフィールド領域を逆回転させることができる。
【００７１】
テキスト処理モジュール（ブロック１３４）は、位置探索モジュール（ブロック１３２）からの領域を含むインデックスキーワード、および、選択されたタイトル欄テンプレート内のメタデータを受け取り、さらに、文脈情報によるテキスト認識を支援するための辞書を受け取るかもしれない。そして、モジュール１３４は、ワード認識（機械印刷および手書き活字体）を実行し、原稿にインデックスを付けるのに使用されるべきキーワードを出力として提供する。手書き活字体のテキストを認識するように設計されたとしても、このモジュールは、機械印刷のテキストを認識することもできる。認識されるテキストの種類には、数字（０〜９のアラビア数字を含む）、アルファベット（Ａ〜Ｚの２６個のローマ字からなる）、および、英数字（アルファベットと数字を組み合わせた集合からなる３６個の要素を含む）がある。
【００７２】
例２
図２、図７、および、図８を参照して、テキスト処理モジュール１３４の動作例が説明される。図２および図７を組み合わせて参照すると、図示されたテキストは、図２の主題タイトル欄から得られたことがわかる。図８に示される画像データは、図２に示される原稿のスキャンされたフィールドの２値サンプルを表現し、ここで、黒サンプルは「１」であり、白サンプルは「０」である。第１の段階は、画像上のすべての連続する黒領域の輪郭を判定し符号化することによって、画像内の文字を分離することである。文字を表現しない小さいかまたは極端に大きい輪郭を除去するために、輪郭のリストがフィルタリングされる。次に、文字を形成するために、輪郭がグループとして分類される。この体系における様々なグループ化方式が考えられるが、中心が０．０１２５インチだけ分離され、かつ、垂直方向に４５％だけ重なり合うように輪郭をグループ化するグループ化方式が使用された。
【００７３】
グループ化は、独立した輪郭が残らなくなるまで、輪郭のリストを巡回して新しいグループを形成するかまたは輪郭を既存のグループに追加することによって実行される。ここで、それぞれのグループは文字を表現し、それが、１２８画素×１２８画素にラスター化される。そして、ラスター化された文字は、正規化モジュールに送られ、この正規化モジュールは、Ｎａｔｉｏｎａｌ  Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｔｅｃｈｎｏｌｏｇｙ  ａｎｄ  Ｓｔａｎｄａｒｄｓによって提供されるアルゴリズムおよびコンピュータコードを使用して、文字の傾斜を補正し文字のサイズを標準の３２画素×３２画素に変更する。
【００７４】
正規化は、特徴のクラス内での変動を減少させることによって、分類トレーニングを容易にする。正規化された水平および垂直の黒および白のランレングスカウントからなる３２×３２画素の文字画像のそれぞれから抽出された７２個の特徴が存在する。隠れた層に１５のノードを有するフィードフォーワードニューラル・ネットワークが、データの種類ごとにトレーニングされ、入力は７２個の実数であり、データの種類が数字、アルファベット、それとも、英数字かに依存して、出力は、０〜１の間の１０、２６、または、３６個の実数のベクトルであった。認識において、もっとも大きな値を有する出力ノードが、認識されたクラス（文字）として報告された。
【００７５】
文字は、元々の原稿内の位置によって、左から右、上から下へソートされる。
近接し垂直方向に重なり合った認識文字がワードとして集められる。垂直方向に分離されたワードが行に割り当てられる。ワードが単一スペースおよび２つのスペースのデリミットラインによって分離されたストリングは、ＡＳＣＩＩ表現のフィールドとして戻される。
【００７６】
５．結果
ここで、インデックスシステムの実施例の能力について説明する。スキャンされた技術図面のデータベースが、従来の大画面スキャナーでハードコピー図面を４００ｄｐｉの解像度でスキャンすることによって組み立てられた。データベースは、１０００枚の図面を含むものであった。最大追加可能画像サイズに基づく量子化レベルが使用されたので、以前からある画像のためにアフィン座標を再計算することなく、新しい画像をＧＨＴに追加することができた。インデックスシステムの能力は、文字認識の能力だけでなくタイトル欄の位置を突き止める能力の関数でもある。
【００７７】
手書き活字体認識モジュールが、ＵＮＬＶデータベースのような標準データセットで厳密に検査され、印刷されたテキストの場合には９５％の精度および手書き活字体テキストの場合には６８％の精度で文字を認識することがわかった。さらに、手書き活字体認識モジュールは、タイトル欄の位置探索およびインデックス領域の抽出と組み合わせて、限られた範囲に対して検査がなされ、得られた結果は、同じような能力を示した。図２および図３のどちらか一方のタイトル欄パターンを使用して、タイトル欄に含まれる画像が、データベース内で検出された。パターンを含むことが検出された画像に、プロジェクトされたタイトル欄パターン（ロケーションハッシングにおいて計算された姿勢を用いて）を重ね合わせることによって、位置探索の結果が示される。検索パターンとモデル画像との間の異なる位置および向きにもかかわらず、パターンの位置を正確に突き止めることができることがわかった。
【００７８】
５．１  記憶能力
記憶効率は、インデックス付けの能力の重要な側面であるので、ＧＨＴのサイズ、それぞれの図面画像において生成された角特徴の数、および、形成されたグループの数はすべて記録された。形成されたグループの数は、幾何学的ハッシングにおけるハッシュテーブルのサイズを見積もるための基準として使用された（上述した式Ｏ（Ｐ＊Ｍ４ ）を用いて）。記録結果が、データベースのほんの一部分として以下の表１に示される。
【００７９】
【表１】
0004577931.tif 000011
【００８０】
第２列のデータによって示されるように、特徴の数は、ほとんどの図面画像に関してきわめて多く、従来のモデルに基づく認識方法による位置探索を不可能ではないにしても困難なものにした。さらに、この表からわかるように、ＧＨＴは、幾何学的ハッシングに取って代わるきわめて空間効率のよい方法であり、アレイに基づいてロケーションハッシングを簡単に実施できることを示すものである。
【００８１】
５．２  インデックス付け時間に関する能力
タイトル欄の位置探索に必要な実際のＣＰＵ時間が、ウィンドウズＮＴプラットフォーム（２００ＭＨｚおよび２５０Ｍのページサイズ）にインストールされたＣ／Ｃ＋＋言語を用いて記録された。コードは、処理速度のために最適化されていなかったが、タイトル欄パターン内のただ１つの曲線グループにインデックスを付けるのに要するＣＰＵ時間は、それに対応する能力を指示した。４０個のタイトル欄検索パターンに必要な平均ＣＰＵ時間は、データベースサイズの関数であることが認められた。結果が図９にプロットされている。これからわかるように、時間的能力は、パターンの複雑さ（特徴の数によって指示される）にそれほど影響されることはなく、複雑なパターンの場合でも、効率のよいインデックス付けを示す。
【００８２】
５．３  精度および再現度
タイトル欄のロケーションハッシングの有効性を精度および再現度に関して評価するために、データベースの図面画像内のタイトル欄パターンの実際の発生回数が手作業によって記録された。検索ごとに、相当な数のヒットが認められ、有効な最大ヒット数に達するまで、すべての発生を検出するのに必要なヒット数が検査された。上位１０個のヒットにおけるタイトル欄の発生数が認められ、精度がよいことを示した。少数の検索に対しての結果が、以下の表２に示される。
【００８３】
【表２】
0004577931.tif 000012
【００８４】
これからわかるように、ほんの少しのヒットを検査することによって、ロケーションハッシングを用いてすべての発生を検索することができる。さらに、きわめて少ない検索パターンの発生が、上位１０個以内のヒットで検索された。
【００８５】
６．特徴
上述した実施例の様々な特徴は、この分野に精通する者には明らかなことである。まず最初に、姿勢に依存しない特徴情報を記憶するようにとくにうまく適合された幾何学的ハッシュツリー（「ＧＨＴ」）と呼ばれるデータ構造が提供される。このＧＨＴによれば、そのような情報を、色を付けられた釣り合いのとれたバイナリー・ツリーとして編成することができ、このツリーは、パターンの検索／位置探索を容易にするような方法でデータを効率的に記憶するのを可能にする。このデータ構造は、データベース編成のために新しい幾何学的探索ツリーとして、また、原稿処理システムにおいて任意のパターンを位置探索／認識するためのツールとして、大きな意義を有する。
【００８６】
第２に、技術図面原稿のタイトル欄からテキストを自動的に抽出することのできるシステムが提供される。このシステムは、画像読み取り装置（例えば、大画面スキャナー）と容易に一体化でき、対応する原稿シートを保管場所に記憶する前に、図面原稿に内容に基づいて自動的に注釈を付けるのを容易にする。システムは、幾何学的な認識能力とテキストの認識能力とを組み合わせて、（ｉ）タイトル欄の形状および様式、（ｉｉ）図面内におけるそれらの位置、（ｉｉｉ）スキャンされた図面におけるスキュー、および、（ｉｖ）スキャンおよび用紙の品質に起因する小さなノイズ、に依存しないように、技術図面画像からインデックス情報を抽出する。図７について上述したように、システムは、タイトル欄１３８の向きがモデルタイトル欄１４０の向きに一致しない場合でも、それらのタイトル欄１３８を認識することができる。
【図面の簡単な説明】
【図１】縮小された３つの技術図面原稿シートの平面図である。
【図２】図１に示される縮小された技術図面原稿シートから抽出されたタイトル欄の平面図である。
【図３】図１に示される縮小された技術図面原稿シートから抽出された他のタイトル欄の平面図である。
【図４】幾何学的ハッシュテーブルから幾何学的ハッシュツリーを生成するための処理を説明するフローチャートである。
【図５】幾何学的ハッシュツリーを生成するために、図４に示される処理によって、幾何学的ハッシュテーブルがどのように分割されるかを説明する概略図である。
【図６】幾何学的ハッシュツリーによって表現されたデータベースに含まれる画像内の２次元（「２Ｄ」）パターンの位置を突き止めるための処理を説明するフローチャートである。
【図７】技術図面インデックスシステムの概略構成図である。
【図８】図２に示されるタイトル欄の１つから抽出されたテキストに対応する画像データの平面図である。
【図９】検索の複雑さの関数としてプロットされた幾何学的ハッシュツリーに関する時間的な性能データを示すグラフである。
【符号の説明】
１３０      タイトル欄トレーニングモジュール
１３２      タイトル欄位置探索モジュール
１３４      テキスト処理モジュール
【図１】
0004577931.tif 000013
【図２】
0004577931.tif 000014
【図３】
0004577931.tif 000015
【図４】
0004577931.tif 000016
【図５】
0004577931.tif 000017
【図６】
0004577931.tif 000018
【図７】
0004577931.tif 000019
【図８】
0004577931.tif 000020
【図９】
0004577931.tif 000021