スキャンされたドキュメントのフォルダーに対して OCR PDF を実行すると、元のファイルと一致する名前を持つ検索可能な PDF が生成されます。バッチ OCR ツールが出力ファイルの名前を、output1.pdf、output2.pdf のように一般的に変更すると、元のバージョンと検索可能なバージョンの間の接続が失われます。 OCR プロセスを通じてファイル名を保存すると、スキャンされたドキュメントが整理され、追跡可能になります。
ファイル名の保存は構成の詳細であり、機能の制限ではありません。ほとんどの OCR ツールは、デフォルトで入力ファイル名に基づいて出力ファイル名を生成するか、出力命名パターンを指定できます。重要なのは、200 個のファイルの名前が変更されたことを発見した後ではなく、バッチを実行する前に適切な設定またはコマンド ライン フラグを見つけることです。
WukongPDF の スキャン PDF OCR ツールは、元のファイル名を維持しながらドキュメントを個別およびバッチで処理します。
Acrobat Pro のアクションウィザードを使用したバッチ OCR
Acrobat Pro のアクション ウィザードは、フォルダーに対する複数ステップの PDF 処理を自動化します。 [ツール]、[アクション ウィザード]、[新しいアクション] の順に移動します。アクションにテキスト認識ステップを追加し、正しい OCR 言語と出力設定を選択します。指定した出力フォルダーにファイルを保存する保存ステップを追加します。オプションで、検索可能なファイルとオリジナルを区別するために _OCR などの接尾辞を追加します。
入力フォルダーでアクションを実行します。 Acrobat は各ファイルを開いて OCR を実行し、元のファイル名にサフィックスを追加して出力を保存し、次のファイルに移動します。出力フォルダーには、元の report.pdf に対応する report_OCR.pdf のような名前の検索可能な PDF が含まれています。接尾辞のアプローチでは、元のファイル名を保持しながら、どのファイルが OCR 処理されたかを明確に示します。
Tesseract を使用したコマンドライン バッチ OCR
Tesseract は一度に 1 つの画像ファイルを処理します。スキャンした PDF のフォルダーをバッチ OCR する場合は、まず各 PDF ページを画像に変換し、Tesseract を実行してから、検索可能な PDF に再結合します。シェル スクリプトがパイプラインを処理します。フォルダー内の各 PDF について、スクリプトはベース ファイル名を抽出し、ページを TIFF イメージに変換し、適切な言語フラグを指定して Tesseract を実行し、元のベース ファイル名で検索可能な PDF を生成します。
スクリプトはパラメータ拡張を使用してファイル拡張子を取り除きます。base=${f%.pdf} は .pdf なしのファイル名を与えます。 Tesseract の出力は $base という名前で、結果の検索可能な PDF は ${base}_searchable.pdf として保存されます。元のファイル名は出力名に保持されます。 1 行のループでフォルダー全体が処理されます。 do tesseract $f ${f%.pdf} -l eng PDF;終わり。
OCRmyPDF を使用した効率的なバッチ OCR
OCRmyPDF は、既存の PDF に OCR テキスト レイヤーを追加する Python ベースのコマンドライン ツールです。画像抽出、OCR、PDF の再構成を内部で処理します。 1 つのコマンドで 1 つの PDF (ocrmypdf input.pdf Output.pdf) が処理されます。出力ではページ画像が保持され、認識されたテキストが非表示のレイヤーとしてその背後に追加されます。
バッチ処理の場合、OCRmyPDF は --batch フラグ付きのフォルダー パスを受け入れるか、シェル スクリプトでループすることができます。 PDF 処理における Tesseract に対する主な利点は、OCRmyPDF が PDF の入出力と直接連携することです。中間画像変換は必要ありません。出力ファイル名は、元の命名規則を維持してファイルごとに指定できます。大量のスキャンされた文書をデジタル化する場合、OCRmyPDF とシェル ループを組み合わせることで、生のスキャンから検索可能なアーカイブまでの最も効率的なパスが提供されます。
| ツール | バッチメソッド | ファイル名の処理 |
|---|---|---|
| Acrobat プロアクションウィザード | アクションを作成し、フォルダーに適用します | 元のファイル名を保持し、サフィックスを追加します |
| Tesseract CLI | フォルダーに対するシェルの for ループ | 出力は入力ファイル名と一致します |
| OCRmyPDF | ファイルまたはバッチごとに 1 つのコマンド | 設定ごとに上書きまたは新しいファイルを作成します |
バッチ OCR 出力の検証
バッチ処理後、元のファイルをアーカイブする前に、出力ファイルのサンプルを検証します。アルファベット順にソートされたファイル リストのさまざまな部分から 3 ～ 5 つの出力 PDF を開きます。スキャンした画像に表示される単語を検索します。検索で単語が見つかった場合、そのファイルの OCR は成功しました。サンプリングされた各ファイルの最初のページ、中間ページ、および最後のページを抜き取りチェックします。ページのスキャン品質が異なる場合、ドキュメント内で OCR 品質が異なる場合があります。
ドキュメントのワークフローに関しては、OCR が失敗したドキュメント (検索しても何も見つからなかった PDF によって示される) については、調整した設定で OCR を再実行します。元のスキャンの品質が低い場合は、画像解像度を 400 DPI に上げます。 Tesseract の結果が悪かった場合は、別の OCR エンジンを試してください。バッチ全体を再実行するのではなく、問題のあるファイルを個別に処理します。
ファイル名を保存したバッチ OCR は、アクセスできないスキャンされたドキュメントのフォルダーを、すべてのファイルがオリジナルまで追跡できる検索可能なアーカイブに変換します。ファイル名は、元のスキャンと OCR 強化バージョンの間のリンクです。
OCR 強化スキャン PDF の長期保存
セットアップが完了したら、バッチ OCR 処理後に、ページ画像と OCR テキスト レイヤーの両方を保存した場所に検索可能な PDF を保存します。テキスト レイヤーが埋め込まれた PDF/A 形式は、アーカイブの標準です。 Acrobat Pro または Ghostscript を PDF/A 出力設定で使用して、OCR 出力を PDF/A に変換します。
実際には、OCR テキスト レイヤーによって追加されるファイル サイズのオーバーヘッドは最小限 (通常は 5 ～ 15 パーセント) です。検索性を確保するためにファイルを少し大きくすることと引き換えに、ほとんどの場合、それだけの価値があります。検索できないスキャンされた文書は、検索できる文書に比べて有用性が大幅に低くなります。
実際には、ネストされたフォルダーを処理する場合、バッチ OCR 出力のディレクトリ構造は入力構造を反映する必要があります。相対パス構造を保持する再帰的バッチ スクリプトにより、OCR 拡張ファイルは元のファイルと同じ組織階層を維持します。
ドキュメント ワークフローに関しては、数千のドキュメントを含む非常に大規模なバッチ OCR プロジェクトの場合、ワークロードを複数のセッションまたはマシンに分割することを検討してください。 OCR は大量の計算を必要とするため、1 万ページのバッチを 1 台のマシンで処理するには数時間かかる場合があります。
セットアップが完了したら、バッチ OCR プロジェクトを完了した後、すべての入力ファイル、その出力ファイル、使用された OCR エンジンと設定、および処理日をリストした処理マニフェストを生成します。マニフェストはドキュメントとして機能し、処理されたファイルの記録として機能します。
これを実際に見てみると、検索不可能なスキャンされたアーカイブから検索可能な OCR 強化コレクションへの移行は、最も大きな影響を与えるデジタル化活動の 1 つです。以前はアクセスできなかったドキュメントを検索できる機能により、ドキュメントが静的な記録からアクティブな情報リソースに変換されます。
OCR の処理速度はドキュメントの複雑さによって異なります。テキストのみのページは迅速に処理されます。表、混合フォント、または装飾要素を含むページでは時間がかかります。均一なテキスト ページのバッチは、さまざまなコンテンツのバッチよりも速く完了します。
ほとんどのツールにおいて、OCR 言語設定はバッチ処理時間と精度に影響します。ドキュメント内に実際に存在する言語のみを選択すると、不必要な処理オーバーヘッドが回避され、未使用の言語モデルによる誤った文字認識が減少します。
テキストと写真の両方を含むドキュメントの場合、OCR エンジンは写真領域内のテキストを認識しようとし、ノイズ文字が生成されることがあります。 OCR 後のフィルタリングは、認識されたテキストの空間分布を分析することにより、これらのアーティファクトを除去します。
通常、OCR 入力画像の DPI 設定は、処理速度と精度のバランスをとります。 300 DPI が標準の推奨値です。 400 DPI により、小さなテキストの精度が向上します。 200 DPI は処理速度が速くなりますが、細かい文字を見逃してしまう可能性があります。
バッチ OCR の後、元のファイルに出現することがわかっている用語を使用して、処理されたファイル全体でキーワード検索テストを実行します。キーワードが見つからないファイルは、設定を調整して再処理するか、手動で確認する必要があります。
OCR 出力ファイルは、処理されたファイルと元のファイルを分離するフォルダー構造に保存する必要があります。これにより、すでに OCR 拡張されたファイルの誤った再処理が防止され、アーカイブが整理された状態に保たれます。
このコンテキスト内で、実際には、OCR テキスト レイヤーを抽出し、ドキュメントごとにプレーン テキスト ファイルとして個別に保存できます。個別のテキスト ファイルにより、各 PDF を個別に開かなくても、アーカイブ全体の全文検索がサポートされます。
文書処理では、価値の高いスキャンされたアーカイブの場合、2 つの異なるエンジンで OCR を実行し、出力を比較することを検討してください。エンジン間の不一致は、手動による検証が必要な不確実な認識を浮き彫りにします。
バッチ OCR は、紙のアーカイブとデジタル検索の間の橋渡しとなります。紙文書のファイリング キャビネットは、スキャンして OCR 処理すると、検索可能な知識ベースになります。物理的な情報から検索可能なデジタル情報への移行は、組織が行うことができる情報管理の変革の中で最も影響力のあるものの 1 つです。
ファイル名を保存したバッチ OCR は、アクセスできないスキャンされたドキュメントのフォルダーと検索可能なデジタル アーカイブの間の橋渡しとなります。処理は自動化されています。ファイル名により追跡可能性が得られます。 OCR テキスト レイヤーにより、すべてのドキュメントが検出可能になります。この組み合わせにより、静的なコレクションがアクティブな情報リソースに変換されます。