IRONSOFTWAREHOME
他のコンポーネントと比較する

MODI OCR C# vs IronOCR: C#における正しい光学式文字認識ライブラリの選択

Kannaopat Udonpant
Kannapat Udonpant
Updated: 2026年6月28日

TesseractOCR(Sicos1977によるフォーク)は、真に活発な最新 for .NETラッパーであり、まさにその点が、その限界を詳しく検討する価値がある理由となっている。 アーカイブされた charlesw/tesseract プロジェクトとは異なり、このフォークは.NET 6 以降を対象とし、Tesseract 5.4.1 をラップしています。しかし、より新しいラッパーでは、その内部にある Tesseract エンジンの不具合は修正されていません。 フレームワークの互換性のためにcharleswからTesseractOCRにアップグレードするチームは、tessdataフォルダの管理、組み込みの前処理機能の皆無、ネイティブPDFサポートの欠如、そして同時実行シナリオでスレッドごとに1つのインスタンスしか実行できない非スレッドセーフなエンジンなど、あらゆる難題が依然として残っていることに気づく。

TesseractOCRについて理解する

TesseractOCRは、オリジナルのcharlesw/tesseractプロジェクトのコミュニティフォークとして、Kees van Spelde(Sicos1977)によってメンテナンスされているApache 2.0ライセンス for .NETラッパーです。 フォークの主な動機は実用的なものでした。charleswの活動は2023年以降鈍化し、 .NET 6/7/8の開発者は最新フレームワークに対応したTesseractバインディングを利用できなくなってしまったのです。 TesseractOCRは、 .NET 6.0、7.0、8.0をターゲットとし、Windows x64、Linux x64、macOS向けのTesseract 5.xネイティブライブラリをバンドルすることで、このギャップを埋めます。

このアーキテクチャはP/Invokeラッパーであり、マネージド.NETコードが相互運用機能を介してネイティブのTesseract C APIを呼び出します。NuGetパッケージには一般的なプラットフォーム向けのネイティブバイナリがバンドルされているため、従来のラッパーにあったネイティブライブラリのデプロイに関する煩雑さが解消されます。 しかし、基本的な設計はTesseractエンジンへの薄いバインディングにとどまっており、前処理ロジックも、PDFパイプラインも、スレッド抽象化も存在しない。

主な建築上の特徴:

-ボランティア開発者1名による積極的なメンテナンス- アップデートは提供されるが、SLAなし、商用サポートなし、バスファクターは1

  • Tesseract 5.5.0 をラップ— 最新の LSTM エンジンの改良が利用可能で、charlesw の 5.2.0 よりも優れています
  • .NET 6.0以降をターゲットとする— 最新のフレームワークをターゲットにすることが、このフォークが存在する主な理由です
  • 手動テスデータ管理が必要 — 言語 .traineddata ファイルは別途ダウンロードおよびアプリケーションと共にデプロイする必要があります
  • 組み込みの前処理なし — ラッパーは engine.Process(image) を直接呼び出します; 画質向上は完全に開発者の責任です
  • スレッドセーフでないエンジンEngine インスタンスはスレッド間で共有できません; 各並列ワーカーはそれぞれ独自のインスタンスを必要とするため、メモリ消費量が増加する。 -ネイティブの PDF サポートはありません— PDF 入力には、Tesseract が処理する前にページを画像にレンダリングするための別のライブラリ (Docnet.Core、PdfiumViewer) が必要です。
  • NuGetのダウンロード数は約20万件に対し、charlesw氏は約800万件と少ない。コミュニティが小さいということは、Stack Overflowの回答数やチュートリアルが少なく、既存のTesseractリソースからの適応作業が多くなることを意味する。

エンジンの初期化とtessdataの依存関係

すべてのTesseractOCRの操作は Engine の初期化から始まり、その初期化には言語 .traineddata ファイルを含むテスデータフォルダが必要です。これらのファイルは外部のリポジトリから手動でダウンロードする必要があります:

// tessdata/eng.traineddata must exist before this line runs
// Downloaded separately: curl -L -o tessdata/eng.traineddata
//   https://github.com/tesseract-ocr/tessdata_best/raw/main/eng.traineddata
using var engine = new Engine(@"./tessdata", Language.English, EngineMode.Default);
using var image = TesseractOCR.Pix.Image.LoadFromFile("document.png");
using var page = engine.Process(image);

string text = page.Text;
float confidence = page.MeanConfidence; // Returns 0.0-1.0 float

Engine コンストラクタはテスデータディレクトリパスと Language enum 値を受け入れます。 ディレクトリが存在しない場合、.traineddata ファイルが存在しない場合、またはファイルバージョンが Tesseract エンジンバージョンと一致しない場合、初期化は例外をスローします。 これらは、あらゆるTesseractラッパーで最もよく発生する3つの本番環境での不具合であり、TesseractOCRはそれらすべてを継承しています。 プロジェクトのREADMEファイルには、エンジンの構築を試みる前にtessdataフォルダと個々の言語ファイルを確認する防御的な検証コードが含まれています。これは、開発者がこの問題に遭遇する頻度を示しています。

IronOCRを理解する

IronOCRは、最適化されたTesseract 5エンジンをベースに、自動前処理、ネイティブPDF入出力、スレッドセーフなアーキテクチャを備えた商用.NET OCRライブラリです。 ライブラリ全体は単一のNuGetパッケージとして提供され、外部依存関係、tessdataフォルダの管理、ネイティブライブラリの設定は一切不要です。

主な特徴:

  • 単一の NuGet インストールdotnet add package IronOcr は動作する OCR パイプラインを生成します。テスデータなし、ネイティブバイナリセットアップなし、コアワークフローに追加のパッケージは不要です -自動前処理— エンジンが傾き補正、ノイズ除去、コントラスト強調、二値化、解像度スケーリングを自動的に適用します。 explicit filter methods are available when fine-grained control is needed
  • ネイティブ PDF 入力および出力 — PDF は OcrInput.LoadPdf() を通じて直接読み込まれます; スキャンされた PDF は result.SaveAsSearchablePdf() を通じて検索可能な PDF 出力を生成します
  • スレッドセーフ IronTesseract — 単一のインスタンスで同時要求を処理し、スレッドごとに重複させる必要はありません
  • NuGetパッケージとして 125 以上の言語に対応— 外部ファイルのダウンロードは不要。 言語パックは dotnet add package IronOcr.Languages.French 経由でインストールされ、パス設定なしで参照されます
  • 永続ライセンス — $999 Lite / $1,499 Plus / $2,399 Professional; 文書ごとの料金は不要、購読も不要 -一貫した動作を実現するクロスプラットフォーム— Windows、Linux、macOS、Docker、Azure、AWS はすべて同じパッケージから動作し、プラットフォーム固有の設定は不要です。

機能比較

フィーチャーTesseractOCRIronOCR
.NETターゲット.NET 6.0、7.0、8.0.NET 6.0、7.0、8.0、 .NET Framework 4.6.2以降
ライセンスアパッチ2.0(無料)Commercial ($999+ 永続)
tessdata management必須(手動ダウンロード)必須ではありません(同梱されています)
組み込みの前処理None自動フィルター + 明示的フィルター
ネイティブPDF入力なしはい
検索可能なPDF出力なしはい
スレッドセーフティ(スレッドごとのエンジンは)ありませんはい(単一の共有インスタンス)

詳細な機能比較

フィーチャーTesseractOCRIronOCR
セットアップと展開
NuGetインストールTesseractOCRIronOcr
tessdata フォルダが必要です。はいなし
言語ファイルのダウンロードマニュアル(GitHub)NuGetパッケージ
ネイティブバイナリバンドル部分的(一般的なプラットフォーム)フル
単一パッケージのデプロイいいえ(tessdata別ファイル)はい
エアギャップ環境事前に準備されたtessdataが必要です言語NuGetパックはオフラインでも動作します
OCR機能
Tesseractエンジンバージョン5.5.05.x(最適化版)
自動傾き補正なしはい
自動ノイズ除去なしはい
自動コントラストなしはい
解像度の向上なしYes (EnhanceResolution(300))
二値化なしはい
PDFサポート
PDF入力いいえ(外部ライブラリが必要です)はい(ネイティブ)
パスワードで保護されたPDFいいえ(復号化+再処理が必要)はい(単一パラメータ)
検索可能なPDF出力なしはい
特定のページ範囲手動(ページごとのレンダリングループ)Yes (LoadPdfPages)
言語サポート
対応言語任意のtessdataファイルNuGet経由で125件以上
多言語構文Language.English | Language.FrenchOcrLanguage.English + OcrLanguage.French
カスタム言語データはい(ファイルをtessdataにコピーしてください)はい(カスタム言語パック)
スレッド処理とバッチ処理
スレッドセーフエンジンなしはい
並列処理パターンスレッドごとのエンジン(メモリを大量に消費する)単一インスタンス、並列入力
スレッドごとのメモリエンジンインスタンスあたり約40~100MB共有インスタンス
出力と結果
信頼度スコアpage.MeanConfidence (0.0-1.0)result.Confidence (0-100%)
単語レベルのポジショニング制限的はい(単語ごとのX座標、Y座標、幅、高さ)
構造化された結果階層なしページ、段落、行、単語
OCR中のバーコード読み取りなしはい
hOCRエクスポートなしはい
サポートとメンテナンス
メンテナンスモデル単独のボランティア開発者営業チーム
商用サポートなしはい(メール、SLAオプション)
GitHubの課題への対応ボランティアスケジュールコマーシャルスケジュール

Tessdata管理:なかなか解消されない導入上の問題

Sicos1977フォークは、Tesseractエンジンをアップデートし、ターゲットフレームワークを近代化した。 言語データの仕組み自体は変更されませんでした。TesseractOCRを実行するすべての環境には、最初の Engine コンストラクタ呼び出し前に .traineddata ファイルが配置されたテスデータフォルダが必要です。

TesseractOCRアプローチ

このリポジトリの basic-ocr.cs ファイルにはプロジェクトが OCR 操作の前に実行することを推奨する ValidateTessData() メソッドが含まれています。 この防御的なパターンは、パイプライン途中での TesseractException スローが図抜けて頻繁であるため、そのライブラリ自身の例がそれを防ぐために存在します:

// From BasicOcrService in tesseractocr-basic-ocr.cs
private void ValidateTessData()
{
    if (!Directory.Exists(_tessDataPath))
    {
        throw new DirectoryNotFoundException(
            $"tessdata folder not found at: {_tessDataPath}\n" +
            "Download traineddata files from: https://github.com/tesseract-ocr/tessdata_best");
    }

    string engTrainedData = Path.Combine(_tessDataPath, "eng.traineddata");
    if (!File.Exists(engTrainedData))
    {
        throw new FileNotFoundException(
            $"eng.traineddata not found in {_tessDataPath}\n" +
            "Download from: https://github.com/tesseract-ocr/tessdata_best/raw/main/eng.traineddata");
    }
}

多言語OCRは問題をさらに複雑にする。 各言語にはそれ自身の .traineddata ファイルが必要で、言語ごとに 15 から 50 MB です。これらのファイルは正しいリポジトリバージョンから取得する必要があります。 tessdata_bestリポジトリは精度は高いものの、処理速度は遅い。 tessdata_fastは、速度を優先するために精度を犠牲にする。 異なるバージョンを混在させたり、Tesseract 4.x用に作成されたtessdataファイルをTesseract 5.xエンジンで使用したりすると、エラー信号が一切発生しないまま、精度が静かに低下します。

Docker環境でのデプロイの場合、tessdataファイルはイメージに組み込むか、既知のパスにマウントする必要があります。 CI/CDパイプラインの場合、ダウンロード手順はスクリプト化され、キャッシュされる必要があります。 エアギャップ環境の場合、ファイルは事前に準備しておく必要があります。 デプロイメント構成が増えるほど、失敗する可能性のある箇所も増える。

// Multi-language requires each .traineddata file pre-downloaded
// eng.traineddata + fra.traineddata + deu.traineddata all required
using var engine = new Engine(@"./tessdata",
    Language.English | Language.French | Language.German,
    EngineMode.Default);

// If any traineddata file is missing, this throws at construction time
using var image = TesseractOCR.Pix.Image.LoadFromFile(imagePath);
using var page = engine.Process(image);

return page.Text;

IronOCRのアプローチ

IronOCRは、言語サポートをNuGetパッケージとして提供しています。 英語はコアパッケージに含まれています。 追加言語は単一のコマンドでインストールでき、パスの設定は不要です。

// dotnet add package IronOcr.Languages.French
// dotnet add package IronOcr.Languages.German
// なし tessdata folder, no download scripts, no path validation

var ocr = new IronTesseract();
ocr.Language = OcrLanguage.French;
ocr.AddSecondaryLanguage(OcrLanguage.German);

using var input = new OcrInput();
input.LoadImage(imagePath);
var result = ocr.Read(input);

return result.Text;
C#

言語パックはNuGetの依存関係であり、バージョン管理され、自動的に復元され、アプリケーションバイナリとともにデプロイされます。 外部のGitHubリポジトリも、curlスクリプトも、ファイルを出力ディレクトリにコピーするためのビルドシステムの設定も一切使用していません。 エアギャップ環境の場合、 NuGetパッケージは他のパッケージと同様に、プライベートフィードからオフラインで復元できます。 多言語対応ガイドでは、サポートされている125以上の言語すべてについて設定方法を解説しています。

前処理:現代のフォークでもまだできないこと

TesseractOCRのSicos1977フォークはcharleswのものより新しく、最新 for .NETを対象としており、更新されたTesseractバイナリをバンドルしています。 それが変わることはありませんが、開発者が傾きのある、低コントラストの、または携帯電話のカメラ品質の画像を engine.Process(image) に渡すと何が起こるかも変わりません。 エンジンは生のピクセルデータを取得します。 Tesseractは劣化した出力を生成する。 開発者は次に、外部画像処理ライブラリを依存関係グラフに追加し、前処理コードを記述します。

TesseractOCRアプローチ

このリポジトリにある migration-comparison.cs ファイルは、TesseractOCR が必要とする前処理パターンを示しています。 この場合の外部イメージライブラリ(SixLabors.ImageSharp)は追加される必要があります。手動フィルターパラメータを調整する必要があり、TesseractOCR が画像を読み取れるようにする前に前処理された画像を一時ファイルに書き込む必要があります - TesseractOCR.Pix.Image API がファイルパスを期待しているためです:

// Requires: dotnet add package SixLabors.ImageSharp
// Manual preprocessing — each parameter requires tuning per document type

using var image = Image.Load(imagePath);

image.Mutate(x => x.Grayscale());
image.Mutate(x => x.Contrast(1.5f));         // 1.5 is a guess; tune per use case
image.Mutate(x => x.GaussianBlur(0.5f));     // Denoise with blur
image.Mutate(x => x.BinaryThreshold(0.5f)); // Threshold requires manual tuning

// Deskew is NOT in ImageSharp — requires separate Hough transform implementation
// (~50-100 additional lines)

string tempPath = Path.GetTempFileName() + ".png";
try
{
    image.Save(tempPath);

    using var engine = new Engine(@"./tessdata", Language.English);
    using var pixImage = TesseractOCR.Pix.Image.LoadFromFile(tempPath);
    using var page = engine.Process(pixImage);

    return page.Text;
}
finally
{
    File.Delete(tempPath); // Clean up temp file
}

TesseractOCRのREADMEには、入力が不完全な場合の精度低下が記載されています。5度の傾きで精度が97%から65~75%に低下します。 スマートフォンのカメラの撮影精度は30~50%に低下する。 これらは本番環境における特殊なケースではなく、スキャンされた文書、ホワイトボードの写真、ファックスのデフォルトの状態です。 その精度を回復するには、傾き補正、ノイズ低減、コントラスト正規化が必要です。 一般的な.NET画像処理ライブラリには、デスクキュー補正機能単体は含まれておらず、ハフ変換による角度検出アルゴリズムを実装する必要があります。

IronOCRのアプローチ

IronOCR の前処理パイプラインは OcrInput に組み込まれています。 Deskew(), DeNoise(), Contrast(), および EnhanceResolution() を呼び出すことで、通常の文書タイプに対して外部ライブラリや一時ファイルを使用せず、パラメータ調整なしで対応するアルゴリズムを適用できます:

// なし external imaging library needed
// なし temp files, no manual parameter tuning

using var input = new OcrInput();
input.LoadImage(imagePath);
input.Deskew();           // Automatic angle detection and correction
input.DeNoise();          // Intelligent noise removal
input.Contrast();         // 自動コントラスト enhancement
input.EnhanceResolution(300); // Upscale if below 300 DPI

var result = new IronTesseract().Read(input);

return result.Text;
C#

品質上の問題が事前に不明な文書の場合、エンジンは明示的なフィルタ呼び出しなしに、ベースライン補正を自動的に適用します。 画像品質補正ガイドでは、各フィルターについて、自動動作の調整が必要な場合のパラメータオプションを解説しています。 画像方向補正ガイドでは、特に傾きと回転の検出について説明しています。これらは、TesseractOCRではカスタム実装が必要となる操作です。 低品質スキャンの例は、難易度の高い文書における精度の違いを示しています。

PDF処理:外部ライブラリ税

TesseractOCRは画像を処理します。 PDFファイルは処理できません。 TesseractOCRを使用したすべてのPDFワークフローでは、PDFページを画像ファイルにレンダリングするための別のライブラリが必要となり、また、PDFから画像にレンダリングされたワークフローでは、一時ファイルの管理、バイト形式の変換、およびクリーンアップロジックが必要となります。

TesseractOCRアプローチ

このリポジトリにあるtesseractocr-pdf-processing.csファイルは、完全なPDF OCRサービスを実装しています。追加の依存関係としてDocnet.Coreが必要で、 IronOCRが3行で実現する処理を約100行のコードで実現しています。 コア抽出ループは Docnet で PDF を読み込み、各ページを BGRA バイト配列にレンダリングし、各ページを一時ファイルに書き出し(TesseractOCR.Pix.Image.LoadFromFile がバイト配列でなくファイルパスを必要とするため)、一時ファイルを OCR 処理し、StringBuilder に追加し、finally ブロックで一時ファイルを削除するという流れを含みます:

// Requires: dotnet add package TesseractOCR
//           dotnet add package Docnet.Core
// Note: Docnet is MIT-licensed; iTextSharp would be AGPL

using var library = DocLib.Instance;
using var docReader = library.GetDocReader(pdfPath, new PageDimensions(dpi, dpi));

int pageCount = docReader.GetPageCount();
var allText = new StringBuilder();
var tempFiles = new List<string>();

try
{
    using var engine = new Engine(_tessDataPath, Language.English, EngineMode.Default);

    for (int pageIndex = 0; pageIndex < pageCount; pageIndex++)
    {
        using var pageReader = docReader.GetPageReader(pageIndex);
        var width = pageReader.GetPageWidth();
        var height = pageReader.GetPageHeight();
        var imageBytes = pageReader.GetImage(); // BGRA bytes

        // TesseractOCR.Pix.Image requires a file path — write to temp
        string tempPath = Path.Combine(_tempDirectory, $"page_{pageIndex}_{Guid.NewGuid()}.png");
        tempFiles.Add(tempPath);
        SaveBgraAsPng(imageBytes, width, height, tempPath); // ~30 lines

        using var image = TesseractOCR.Pix.Image.LoadFromFile(tempPath);
        using var page = engine.Process(image);

        allText.AppendLine($"--- Page {pageIndex + 1} ---");
        allText.AppendLine(page.Text);
    }
}
finally
{
    foreach (var tempFile in tempFiles)
    {
        try { File.Delete(tempFile); } catch { }
    }
}

パスワードで保護されたPDFは、ドキュメントを最初に復号化するための第3のライブラリ (AGPLライセンスのiTextまたはPDFSharp) を必要とし、追加の依存関係と評価するための別のライセンスの懸案を追加します。 tesseractocr-pdf-processing.cs ファイルのこの件に関するコメントは直接的です。"TesseractOCR + Docnet はパスワードで保護された PDF を直接処理できません。" 以下の手順が必要です。1. 復号化をサポートするPDFライブラリを使用する... 2. まずパスワードを復号化/削除してください... 3. 復号化されたPDFを保存します... 4.次に、上記のコードで処理します。

IronOCRのアプローチ

IronOCRはPDFをネイティブでサポートしています。外部ライブラリも、一時ファイルも、バイト形式変換も不要です。 PDF入力ガイドでは、文書全体、ページ範囲、パスワードで保護されたファイルなど、あらゆるPDFシナリオに対応しています。

// フルPDF — native, no external library
var ocr = new IronTesseract();
using var input = new OcrInput();
input.LoadPdf(pdfPath);
var result = ocr.Read(input);
string text = result.Text;

// パスワードで保護されたPDF — built-in, one parameter
using var encryptedInput = new OcrInput();
encryptedInput.LoadPdf("encrypted.pdf", Password: "secret");
var encryptedResult = ocr.Read(encryptedInput);

// Specific page range — no manual loop required
using var pageInput = new OcrInput();
pageInput.LoadPdfPages(pdfPath, startPage: 1, endPage: 5);
var pageResult = ocr.Read(pageInput);
C#

スキャンされた PDF は、TesseractOCR の Docnet + 前処理 + OCR の組み合わせが最も苦痛となるシナリオであり、IronOCR の前処理パイプラインが最も重要となるシナリオでもあります。スキャンされた PDF は LoadPdf() を通り、前処理が自動で行われ、OCR 処理が実行され、検索可能な PDF のオプションの出力があり、一時ファイル管理なしに直線的なチェーンを通ります。 PDF OCR の例検索可能な PDF ガイドresult.SaveAsSearchablePdf() を含む全ワークフローをカバーしており、これはTesseractOCRには同等のものがありません。

スレッド処理:スレッドセーフでないエンジンのメモリコスト

TesseractOCR の Engine はスレッドセーフではありません。 basic-ocr.cs ファイルには明示的な警告が含まれた ThreadSafeOcrService クラスが含まれています: "メモリのオーバーヘッド: 4 スレッド x 50MB = 200MB+ ちょうどエンジンだけで"。並行なTesseractOCRのコストはスレッドごとに 1 エンジンインスタンスであり、それぞれが 40-100MB のネイティブ Tesseract メモリを保持し、それぞれが約 500ms の初期化時間を必要とします。

TesseractOCRアプローチ

TesseractOCR を用いた並列処理では、各ワーカーラムダ内で新しい Engine を作成する必要があります:

// WARNING: Engine is NOT thread-safe — must create per thread
// Memory: _maxDegreeOfParallelism * engine footprint (~40-100MB each)

var results = new ConcurrentDictionary<string, string>();

Parallel.ForEach(
    imagePaths,
    new ParallelOptions { MaxDegreeOfParallelism = 4 },
    imagePath =>
    {
        // Per-thread engine — required, expensive (~500ms init, ~50MB memory)
        using var engine = new Engine(@"./tessdata", Language.English, EngineMode.Default);
        using var image = TesseractOCR.Pix.Image.LoadFromFile(imagePath);
        using var page = engine.Process(image);

        results[imagePath] = page.Text;
    });

単一エンジン再利用パターン(ループの外で1つのエンジンを作成し、それを順次再利用する)は、シリアル処理には有効ですが、他のスレッドがインスタンスにアクセスすると機能しなくなります。 したがって、負荷がかかった状態でのバッチ処理では、スレッドごとのエンジンのメモリコストを受け入れるか、慎重なライフサイクル管理を備えたスレッドローカルなエンジンプールを実装するかのいずれかが必要となる。

IronOCRのアプローチ

IronTesseract はスレッドセーフです。 1つのインスタンスが、任意の数の同時スレッドからのリクエストを処理します。

// Single instance — thread-safe, no per-thread duplication
var ocr = new IronTesseract();

var results = new ConcurrentDictionary<string, string>();

Parallel.ForEach(imagePaths, imagePath =>
{
    using var input = new OcrInput(imagePath);
    results[imagePath] = ocr.Read(input).Text;
});

マルチスレッドの例は、そのパターンを示している。 4つの並列ワーカーに必要なメモリは、4つのエンジンインスタンスではなく、1つのエンジンインスタンスで済みます。 スループットが重要なバッチ文書処理パイプラインにおいては、これは大きな違いとなる。

APIマッピングリファレンス

TesseractOCRIronOCR相当値ノート
Engine(tessDataPath, Language.English, EngineMode.Default)new IronTesseract()tessdataパスは不要です
TesseractOCR.Pix.Image.LoadFromFile(path)new OcrInput(path)より多くのフォーマットに対応
engine.Process(image)ocr.Read(input)コアOCR呼び出し
page.Textresult.Text抽出された全文
page.MeanConfidence (0.0-1.0)result.Confidence (0-100)スケールが異なる
Language.English | Language.FrenchOcrLanguage.English + OcrLanguage.Frenchオペレーターが異なります
EngineMode.Default該当なし自動選択
TesseractOCR.Exceptions.TesseractExceptionIronOcr.Exceptions.OcrException処理すべき例外の種類が少なくなる
手動前処理(ImageSharp)input.Deskew(), input.DeNoise(), input.Contrast()組み込み機能、外部ライブラリ不要
Docnet GetPageReader().GetImage() + 一時ファイルinput.LoadPdf(path)ネイティブPDF、一時ファイルなし
該当なしinput.LoadPdf(path, Password: "secret")追加ライブラリなしでは同等のものは存在しない
該当なしresult.SaveAsSearchablePdf(path)TesseractOCRには同等の機能はありません
該当なしresult.Pages, result.Lines, result.Words構造化された出力
該当なしocr.Configuration.ReadBarCodes = trueバーコードの同時読み取り
スレッドごとの Engine インスタンス単一の IronTesseract インスタンスねじの安全性を内蔵

チームがTesseractOCRからIronOCRへの移行を検討する場合

文書の品質は変動する

TesseractOCRとの連携は、高画質の300 DPIスキャン画像でも問題なく動作します。 文書の品質が低下した瞬間、例えばフラットベッドプリンターで印刷した歪んだページ、コントラストの低いファックス、領収書を携帯電話で撮影した写真などでは、正確性のギャップが生じる。 READMEファイルに記載されているベンチマークによると、前処理なしの場合、スマートフォンのカメラで撮影した画像の精度は30~50%に低下することが示されています。 ImageSharpまたはSkiaSharpで前処理パイプラインを構築および調整してその精度を回復するには、8~20時間の開発時間が必要となり、追加の依存関係が発生します。 TesseractOCRへの移行において、最初の統合から6か月後に"高品質スキャン"という前提が間違っていたことに気づくチームは、典型的なケースと言えるでしょう。 前処理のギャップは、一度解決すれば済むような設定上の問題ではなく、新しい文書タイプやキャプチャ方法がパイプラインに導入されるたびに発生する問題です。

PDF文書は入力ワークフローの一部です

PDF OCR に Docnet.Core とTesseractOCRを組み合わせる方法は機能しますが、既存のコード 3 を置き換えるには約 100 行のコードが必要です。より実際的な観点からは、Docnet のライセンス (MIT ライセンス)、クロスプラットフォームでの動作、不正な形式の PDF の処理、既存の tessdata および前処理コードとの連携などを評価する必要があります。 文書管理システム、請求書処理システム、またはPDFが主要な入力として送られてくるあらゆるワークフローを構築するチームは、外部ライブラリのPDF方式では、ページサイズの取り扱い、レンダリングのためのDPI選択、一時ファイルのクリーンアップロジック、そして検索可能なPDF出力が全くないことなど、時間の経過とともに摩擦が蓄積していくことに気づきます。 スキャンした入力データから検索可能なPDFを作成する必要があるチームにとって、TesseractOCR単体では解決策が見つからない。

スレッドアーキテクチャがメモリの限界に達する

TesseractOCRでは、4つの同時OCRワーカーが、1枚の画像を処理する前にエンジンメモリを200~400MB消費します。 これは、処理能力の低いバックグラウンドジョブにとっては問題になりません。 これは、複数のドキュメントの同時アップロードを処理するASP.NET Coreエンドポイント、またはスループットを向上させるバッチプロセッサにとって問題となります。 スレッドごとのエンジンパターンでは、新しいスレッドはそれぞれ、最初のドキュメントを処理する前に約500ミリ秒の初期化コストを支払う必要がある。 TesseractOCRをバックグラウンドサービスとして選択し、その後スループットを拡張する必要が生じたチームは、この限界に直面する。 スレッドセーフなエンジンに移行することで、スレッドごとのオーバーヘッドを完全に排除できます。

初期開発後の展開環境の変更

TesseractOCRは、アプリケーションと同時にデプロイされるtessdataファイルを必要とします。 開発者のローカル環境であれば、これは管理可能な範囲です。 Dockerコンテナの場合、tessdataファイルをイメージに埋め込む(言語ごとにイメージサイズが15~50MB増加する)か、既知のパスにボリュームをマウントする(運用上の複雑さが増す)かのどちらかになります。 CI/CDパイプラインにおいては、これはダウンロードをスクリプト化してキャッシュすることを意味します。 Azure App Service または AWS Lambda では、tessdata パスの設定は、開発環境とは異なる可能性のある、環境固有の設定の 1 つです。 ローカル環境のみでの概念実証から始め、その後コンテナ化またはクラウド環境への移行を行うチームは、tessdataの要件がそれぞれの環境で異なる挙動を示すことに気づく。 IronOCRのNuGetベースの言語パックは、パッケージが復元されるすべての場所で同じように展開されます。

地域社会の支援が分岐点に達する

TesseractOCRは、 NuGetで約20万回ダウンロードされています。 charlesw/tesseract は約 8M です。 Stack Overflow の質問、ブログ投稿、GitHub の課題で Tesseract .NET ラッパーについて圧倒的に参照されているのは charlesw の API であり、TesseractEngine であって Engine ではありません; Pix.LoadFromFile, not TesseractOCR.Pix.Image.LoadFromFile. charlesw に有効なソリューションは、TesseractOCR の API の違いに合わせて調整する必要があります。 主な支援モデルが地域社会のリソースであるチームにとって、これはまさに摩擦を増幅させる要因となる。

一般的な移行の考慮事項

名前空間とクラスの置換

コア置換は EngineIronTesseract に、TesseractOCR.Pix.Image.LoadFromFile()OcrInput に変えます。 ネームスペースの変更 (using TesseractOCRusing IronOcr に) により、ほとんどの参照をキャッチします。 TesseractOCRがLanguage.Englishを使用する場合 |Language.French(bitwise OR on a flags enum), IronOCR usesOcrLanguage.English + OcrLanguage.French(加算演算子)。 信頼スケールも異なります:TesseractOCRはpage.MeanConfidenceを 0.0-1.0 の浮動小数点数として返します; IronOCR はresult.Confidence` を 0-100 の倍精度浮動小数点数として返します。 信頼度を比較する閾値ロジックはすべて更新する必要がある。

// Before (TesseractOCR)
using var engine = new Engine(@"./tessdata", Language.English, EngineMode.Default);
using var image = TesseractOCR.Pix.Image.LoadFromFile("document.png");
using var page = engine.Process(image);
float confidence = page.MeanConfidence; // 0.0 to 1.0

// After (IronOCR)
var ocr = new IronTesseract();
using var input = new OcrInput("document.png");
var result = ocr.Read(input);
double confidence = result.Confidence; // 0 to 100

前処理の依存関係を削除する

既存のTesseractOCR統合にImageSharpまたはSkiaSharpの前処理パイプラインが既に存在する場合、移行後にそのコードを削除できます。 IronOCR の組み込みの Deskew(), DeNoise(), Contrast(), および EnhanceResolution() メソッドは外部フィルターチェーンを置き換えます。 前処理された画像を囲む一時ファイルの作成とクリーンアップコードも削除されます - OcrInput は中間ファイル書き込みなしでファイルパス、バイト配列、ストリーム、または Bitmap を直接受け入れます。画像フィルター例 は利用可能なフィルターとその同等物をカバーしています。

PDF外部ライブラリを削除する

PDFレンダリングにDocnet.CoreまたはPdfiumViewerを使用しているチームは、これらのパッケージを完全に削除できます。 PDF レンダリングループ全体 - DocLib.Instance, GetDocReader, GetPageReader, GetImage, SaveBgraAsPng, 一時ファイル作成, Pix.Image.LoadFromFile, engine.Process - を input.LoadPdf(pdfPath) に置き換えます。 PDF入力ガイドPDF OCR使用事例ページでは、 IronOCR PDF APIの全機能を網羅しています。 プロジェクトから tessdata フォルダを削除し、tessdata ファイル用の <CopyToOutputDirectory> ビルド設定を削除し、apt-get install tesseract-ocr ステップを削除するために Docker イメージを更新します。

エラー処理サーフェスの縮小

TesseractOCR では、エンジン初期化の失敗を捕捉するために TesseractOCR.Exceptions.TesseractException が必要であり、ネイティブライブラリの欠如には DllNotFoundException が必要であり、アーキテクチャに不一致がある場合には BadImageFormatException が必要です。 IronOCRは独自の依存関係をバンドルし、初期化を内部的に管理するため、これらの例外タイプは適用されません。 残りのエラー表面は標準 IOException であり、ファイルアクセスの問題と OCR 特有の失敗には IronOcr.Exceptions.OcrException を用います。

IronOCRの追加機能

この比較で取り上げた分野以外にも、 IronOCRにはTesseractOCRにはない機能が含まれています。

  • 検索可能な PDF 出力result.SaveAsSearchablePdf() がスキャンされた文書を埋め込み可能で選択可能なテキストを持つ PDF に変換します; TesseractOCRは、いかなる種類のPDF出力も生成しません。
  • 領域ベースの OCRinput.LoadImage("invoice.jpg", new CropRectangle(0, 0, 600, 100)) は処理を特定の領域に制限します; フォームフィールドの抽出と構造化ドキュメントの解析に役立つ
  • OCR 中のバーコード読み取りocr.Configuration.ReadBarCodes = true が文書に埋め込まれたバーコードと QR コードを同時に読み取ります。
  • 構造化された結果データresult.Pages, result.Paragraphs, result.Lines, および result.Words が文書構造を単語ごとの座標データと共に公開します; TesseractOCRは、単一の信頼度値を持つフラットなテキスト文字列を返します。
  • hOCR エクスポートresult.SaveAsHocrFile() が下流の文書処理パイプライン用の hOCR フォーマット出力を生成します
  • 非同期 OCR — ASP.NET Core 統合のためのネイティブな async/await サポートで、手動 Task.Run ラッパーは不要です -単語ごとの信頼度スコア— 単語レベルの信頼度により、不確実な抽出をフィルタリングできます。 TesseractOCRは文書レベルの平均信頼度のみを提供します -特殊な文書読み取り— パスポート、MICRチェック、ナンバープレートの読み取り。一般的なOCRを超えた、ドメイン固有の最適化が施されています。

.NETの互換性と将来の準備

TesseractOCRは.NET 6.0、7.0、および8.0を対象としており、これは現在アクティブなLTSおよびSTSリリースを網羅しています。 IronOCRは、最新 for .NETバージョンをサポートするだけでなく、フレームワークの移行を完了していないチーム向けに、 .NET Framework 4.6.2以降との下位互換性も提供します。 どちらのライブラリも、Windows、Linux、macOSで動作します。 IronOCRは、プラットフォーム固有の設定を必要とせずに、サポートされているすべてのプラットフォーム向けに、プラットフォーム固有の最適化をNuGetパッケージに同梱しています。 TesseractOCRは一般的なプラットフォーム向けにネイティブバイナリを同梱していますが、一般的なLinuxディストリビューションやカスタムDockerベースイメージの場合は、追加のネイティブライブラリ設定が必要です。 IronOCRは、本番環境向けに検証済みの構成を含む、 DockerLinuxAzure 、およびAWSのデプロイガイドを公開しています。

結論

TesseractOCRは、独自のニッチ市場を開拓しています。Apache 2.0ライセンスを必要とするプロジェクトで、クリーンで高品質な画像を処理し、パイプラインに必要な前処理を構築するための社内画像処理の専門知識を持っている場合、TesseractOCRは最適な選択肢となります。 Sicos1977 のフォークは、新しい.NET 6+ 開発において、アーカイブされた charlesw プロジェクトを使用するよりもはるかに優れています。新しいエンジン、アクティブなバグ修正、真のクロスプラットフォームネイティブバンドルなどが特徴です。 クリーンな入力データを使用し、オープンソースのみを使用するというプロファイルに合致するプロジェクトであれば、それで十分です。

この比較の論点はより具体的です。ラッパーを更新しても、Tesseract自体が提供していない機能は修正されません。tessdataの要件は変更されていません。 スレッドセーフではないエンジンは変更されていません。 前処理が行われていない点は変更されていません。 PDFのネイティブサポートがない点は変更されていません。TesseractOCRを最新 for .NETターゲットとして選択したチームは、初期設定、前処理の実装、および PDF 統合に 26 ~ 56 時間の予算を確保する必要があります。これは、charlesw を使用した場合に必要だった予算と同じです。 現代のフォークはバージョン間の摩擦を軽減する。 それは統合作業を軽減するものではない。

IronOCR は 4 つすべてのギャップに直接対応します:言語は NuGet パッケージとしてインストールされ、IronTesseract はスレッドセーフで、前処理は自動的に行われ、PDF はネイティブです。トレードオフとして Lite ライセンスで $999 が要求されます。 ほとんどの運用アプリケーションでは、このトレードオフはすぐに解消されます。競争力のある価格で開発を行うと、継続的なメンテナンス費用を考慮に入れる前の、最初の1週間のセットアップ作業だけで、開発者の作業時間がライセンス費用を上回ってしまうからです。

TesseractOCRを評価するどのチームにとっても、未解決の疑問は、フォークが活発で適切にメンテナンスされているかどうかではなく、実際にそうである。 問題は、テッセラクトの基本的なアーキテクチャが、実際の運用要件に適合するかどうかである。 回答が、品質の異なる文書、PDF入力、スケーラブルなスループット、またはtessdata管理が課題となる展開モデルに関わる場合、IronOCRのアプローチは、1回限りのライセンス料でこれらの問題を解消します。

ご注意: PDFium, PDFSharp, Tesseract, iText はそれぞれの所有者の登録商標です。 このサイトはChromiumプロジェクト、Google、empira Software GmbH、またはiText Groupとは提携、承認、またはスポンサーはされていません。すべての製品名、ロゴ、およびブランドはそれぞれの所有者の財産です。 比較は情報提供のみを目的としており、執筆時点で公開されている情報を反映しています。

関連する記事

Key in blue circle

無料の30日間トライアルキーをすぐに入手してください。

Your trial license will be sent to your email address

制限なし。100% ロック解除済み。クレジットカード不要。

bullet_checkedクレジットカードやアカウントの作成は不要です。制限なし。100% ロック解除済み。クレジットカード不要。
  • Logo Aetna
  • Logo NASA
  • Logo GE
  • Logo Porsche
  • Logo USDA
  • Logo Qatar
Join Millions of Engineers who’ve tried IronPDF
義務のない相談を受ける
下記のフォームを記入するか、sales@ironsoftware.comにメールしてください。
あなたの詳細は常に守秘されます。
世界中の数百万人のエンジニアから信頼されています。
ライセンスはより安く
あなたの無料30日間の試用キーをすぐに入手。
クレジットカードやアカウントの作成は不要です。