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

AzureのOCR vs IronOCR: .NETプロジェクトに最適な光学式文字認識ソリューションは?

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

Windows.Media.Ocr は、すべての Windows 10 および Windows 11 のインストールに無料で付属しているため魅力的ですが、同じアプリケーションをLinuxサーバー、Docker コンテナ、またはAWSラムダ関数にデプロイしようとすると、API が存在しないという問題が発生します。プラットフォームのロックインは、このライブラリの特殊なケースではありません。 それは決定的な制約条件である。 Windows.Media.Ocr を選択すること以降のすべてのアーキテクチャ上の決定は、ホスト OS が Windows 10 または Windows 11 のデスクトップまたはコンシューマー向けサーバーでなければならないという要件によって左右されます。 LinuxもmacOSもDockerもLinux上のAzure FunctionsもAWS Lambdaも利用できません。 外部に展開する予定が全くない、社内向けのWindowsツールを開発している開発者にとって、0ドルという価格は魅力的に映るだろう。 その他すべての企業にとって、隠れたコストとは、導入要件が変化した際に、OCRをまったく別のシステムに書き換える必要があることである。

Windows.Media.Ocr を理解する

Windows.Media.OcrはWindows Runtime (WinRT) APIの一部で、Windows 8.1で導入され、Windows 10および11用に改良されました。OcrResultを返します。

このAPIは、WinRTのasync/awaitコントラクトに基づいて構築されています。 すべての操作はWinRTのasync Task呼び出しを通じて流れる: RecognizeAsyncを呼び出す。 .NET 6以降、WinRT APIを利用するには、net8.0-windows10.0.19041.0のようなWindows専用のターゲットフレームワークモニカー(TFM)が必要です。 そのTFMがないプロジェクトファイルでは、Windows.Media.Ocrを参照するコードをコンパイルできません — その型はアセンブリグラフ内に存在しないのです。

主な建築上の特徴:

  • Windows 10/11のみ— Windows Server(デスクトップ エクスペリエンスなし)では、すべての構成でWinRT APIサーフェスは利用できず、LinuxおよびmacOSでは全く利用できません。
  • WinRT非同期モデル — すべての認識はIAsyncOperationサポートの非同期呼び出しを通じて流れます; 同期パスが存在しない
  • OSからの言語パックTryCreateFromUserProfileLanguagesは、その特定のマシンにユーザーまたはIT管理者によってインストールされたWindows言語パックから使用可能な言語を解決します; バンドルまたはポータブル言語モデルはありません
  • 画像のみの入力 — APIはSoftwareBitmapを直接受け入れます; APIのどのレイヤーにもPDF入力パスは存在しません -前処理パイプラインなし— 生のビットマップが認識器に渡されます。 回転補正、ノイズ除去、コントラスト強調、解像度スケーリングは、開発者が個別のWindowsイメージングAPIを使用して行う責任があります。 -検索可能なPDF出力はありません。認識されたテキストは、線形状を含むプレーンな文字列データとして返されます。 PDFへのエクスポート機能は提供されていません。
  • Windows専用TFMが必要 — プロジェクトファイルはnet*-windows* TFMをターゲットにする必要があり、これにより同じプロジェクトがクロスプラットフォームでコンパイルされることが妨げられます

WinRT非同期スタック

Windows.Media.Ocr を使用した基本的な OCR 操作では、認識を開始する前に、WinRT API サーフェスの複数のレイヤーをナビゲートする必要があります。

// Windows.Media.Ocr: 6+ async steps before receiving any text
// Requires net8.0-windows10.0.19041.0 TFM — will not compile cross-platform

public async Task<string> ExtractTextAsync(string imagePath)
{
    // Step 1: WinRT file system access
    var file = await StorageFile.GetFileFromPathAsync(imagePath);

    // Step 2: Open WinRT stream
    using var stream = await file.OpenAsync(FileAccessMode.Read);

    // Step 3: Create bitmap decoder
    var decoder = await BitmapDecoder.CreateAsync(stream);

    // Step 4: Decode to SoftwareBitmap
    var bitmap = await decoder.GetSoftwareBitmapAsync();

    // Step 5: Check language availability — null if not installed on this machine
    var engine = OcrEngine.TryCreateFromLanguage(
        new Windows.Globalization.Language("en-US"));
    if (engine == null)
        throw new Exception("OCR engine not available for this language");

    // Step 6: Recognize
    var result = await engine.RecognizeAsync(bitmap);
    return result.Text;
}

engineのヌルチェックは任意ではありません。 コードを実行しているマシンにターゲット言語パックがインストールされていない場合、TryCreateFromLanguageはnullを返し、認識は不可能です。 代替手段はない。 アプリケーションは、ユーザーにエラーを表示するか、あるいはエラーを通知せずに処理を終了する必要がある。

IronOCRを理解する

IronOCRは、最適化されたTesseract 5エンジンをベースに構築された商用.NET OCRライブラリであり、前処理、PDF読み取り、多言語対応、構造化データ出力などを処理するマネージドAPIレイヤーを備えています。 これは単一のNuGetパッケージとしてインストールされ、別途デプロイする必要のある外部ネイティブバイナリ、管理する必要のあるtessdataフォルダ、およびプラットフォーム固有のTFMは必要ありません。

主な特徴:

-設計段階からクロスプラットフォーム対応— コード変更なしで、Windows、Linux、macOS、Docker、Azure App Service (WindowsまたはLinux)、AWS Lambda、およびGCP Cloud Runで動作します

  • 自動前処理 — 傾き補正、ノイズ処理、コントラスト強調、二値化、および解像度拡大が、低品質の入力に対して自動的に適用され、OcrInputフィルタメソッドを通じて明示的な制御が可能です
  • ネイティブPDF入力IronTesseract.ReadはPDFパスを直接受け入れます; 変換ステップなし、外部ライブラリなし
  • 125以上の言語がバンドルされています— 言語パックは、アプリケーションとともにデプロイされるNuGetパッケージです。 OSにインストールされている言語データに依存しない
  • 検索可能なPDF出力OcrResult.SaveAsSearchablePdfは、スキャンされた入力からテキストレイヤーPDFを作成します
  • 構造化された結果モデルWords、および単語ごとの信頼性スコアとバウンディングボックスを公開します
  • スレッドセーフIronTesseract インスタンスは、追加の同期なしで並行ワークロードをサポートします
  • 永続ライセンス — $999 Liteから$4,799 Unlimitedまで、一度購入すれば無制限に文書を処理できます

機能比較

フィーチャーWindows.Media.OcrIronOCR
プラットフォームWindows 10/11のみWindows、Linux、macOS、Docker、クラウド
価格無料$4,799 永続
PDF入力なしネイティブ
言語モデルOSにインストールされたパックNuGet経由で 125 個以上がバンドルされています
前処理None自動フィルター + 明示的フィルター
検索可能なPDF出力なしはい
APIモデルWinRT 非同期.NET Standard

詳細な機能比較

フィーチャーWindows.Media.OcrIronOCR
プラットフォームサポート
Windows 10/11はいはい
Windowsサーバー制限的はい
Linuxなしはい
macOSなしはい
Dockerなしはい
Azure Functions(Linux)なしはい
AWSラムダなしはい
入力フォーマット
JPEG / PNG / BMPはい(WinRTパイプライン経由)はい
PDF(スキャン画像)なしはい
PDFファイル(パスワード保護あり)なしはい
TIFF / マルチページなしはい
ストリーム/バイト配列いいえ(WinRT StorageFileのみ)はい
URLなしはい
言語サポート
言語ソースOSにインストールされている言語パック125個以上のNuGetパックがバンドルされています
OS管理者権限なしでインストールなしはい(NuGet)
多言語同時通訳なしはい
マシン間での言語移植性なしはい
前処理
デスキューなしはい (input.Deskew())
ノイズ除去なしはい (input.DeNoise())
コントラスト強調なしはい (input.Contrast())
二値化なしはい (input.Binarize())
解像度スケーリングなしはい (input.EnhanceResolution(300))
出力
プレーンテキストはいはい
検索可能なPDFなしはい
hOCR / HTMLなしはい
単語レベルの境界ボックス部分的(線形状)はい
単語ごとの信頼度スコアなしはい
APIデザイン
TFM制限net*-windows* が必要ですNone
同期パスなしはい
OCR中のバーコード読み取りなしはい
地域ベースのOCRなしはい

プラットフォームロックイン vs. クロスプラットフォーム展開

これら2つのライブラリ間の最も重要な違いは、精度でも、前処理でも、PDFサポートでもなく、デプロイメントトポロジーである。 Windows.Media.Ocr はWindows 10/11以外では存在しません。これは構成の問題でもNuGetパッケージの欠落でもありません。 このAPIを支えるWinRTランタイムは、他のすべてのオペレーティングシステムには存在しない。

Windows.Media.OCR アプローチ

WinRTへの依存関係は、コードが1行も実行される前にプロジェクトファイル内で顕在化します。 TargetFramework はWindowsプラットフォームバージョンを指定する必要があります:

<!-- Project file: MUST use Windows TFM — cross-platform TFMs will not compile -->
<PropertyGroup>
  <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
</PropertyGroup>
XML

そのTFMでは、Linuxコンテナからプロジェクトを使用することはできません。 ASP.NETデプロイの標準的なLinuxベースのイメージであるnet8.0(Windowsサフィックスなし)をターゲットとしたプロジェクトで参照しようとすると、実行時エラーではなくコンパイルエラーが発生します。 ベンダーロックインはビルド時に強制されます。

OCRワーカーがLinux上で動作するマイクロサービスアーキテクチャ、またはクロスプラットフォームのDockerイメージを生成するCI/CDパイプラインでOCR要件が発生した場合、Windows.Media.Ocrは評価対象ではなく、最初のピークを迎える前に除外されます。

IronOCRのアプローチ

IronOCRは、プラットフォーム固有のTFMなしでnet9.0をターゲットにしています。 同じNuGetパッケージとアプリケーションバイナリは、Windows、Linux、macOS のいずれのプラットフォームでも動作します。 DockerにIronOCRをデプロイするには、Linuxベースのイメージにapt-getラインが1つ必要で、他には何も必要ありません:

FROM mcr.microsoft.com/dotnet/aspnet:8.0
#Linuxdependency for System.Drawing
RUN apt-get update && apt-get install -y libgdiplus

COPY --from=build /app/publish /app
WORKDIR /app
ENTRYPOINT ["dotnet", "YourApp.dll"]
Text

アプリケーションコード自体は、Windows版とLinux版で変更されていません。

// Same code — Windows, Linux, macOS, Docker, AWS Lambda
// なし platform TFM, no WinRT, no conditional compilation
using IronOcr;

IronOcr.License.LicenseKey = "YOUR-LICENSE-KEY";
var text = new IronTesseract().Read("document.jpg").Text;
C#

IronOCRは、AWS LambdaLinux上のAzure Functions 、およびLinuxサーバー上で、コードの変更なしで直接動作します。 展開対象は構成上の懸念事項であり、アーキテクチャ上の制約ではない。

言語サポート:OS依存性 vs. バンドルパック

Windows.Media.Ocr は、言語の可用性を完全にホストマシンに委ねます。アプリケーションが認識できる言語のセットは、ユーザーまたは IT 管理者が特定の Windows インストール環境にインストールした言語パックによって決まります。 これは、あなたのコードとは全く関係のない、ある種の生産上の障害を生み出します。

Windows.Media.OCR アプローチ

要求された言語がインストールされていない場合、OcrEngine.TryCreateFromLanguageはnullを返します。 OCR対応言語パックが全く存在しない場合、TryCreateFromUserProfileLanguagesはnullを返します。 どちらの方法もヌル値の処理が必要であり、どちらもスムーズな復旧手段を提供していません。つまり、コードから言語をインストールしたり、アプリケーションに言語をバンドルしたりする方法はありません。

// Windows.Media.Ocr: language availability is a runtime unknown
// Returns null if the language pack is not installed on this machine

var engine = OcrEngine.TryCreateFromLanguage(
    new Windows.Globalization.Language("fr-FR"));

if (engine == null)
{
    // French OCR is simply unavailable — no recovery path
    // User must go to Windows Settings > Language to install French
    throw new InvalidOperationException(
        "French OCR unavailable. Install the French language pack in Windows Settings.");
}

var result = await engine.RecognizeAsync(bitmap);

Windows.Media.Ocr を使用した多言語文書処理アプリケーションをデプロイするには、デプロイ先のすべてのマシンで Windows 言語パックのインストールを調整する必要があります。 共有サーバーやグループポリシーで管理されているユーザーのマシンでは、これは開発者の制御範囲外です。

IronOCRのアプローチ

IronOCRは、言語モデルを専用のNuGetパッケージとして提供しており、アプリケーションバイナリと同時にデプロイされます。 言語データはビルド成果物とともに転送され、OSの設定には含まれません。 125以上の言語をサポートすることはdotnet add package操作です:

dotnet add package IronOcr.Languages.French, IronOcr.Languages.German, IronOcr.Languages.Arabic, IronOcr.Languages.ChineseSimplified

// IronOCR: language availability is a deploy-time guarantee, not a runtime unknown
var ocr = new IronTesseract();
ocr.Language = OcrLanguage.French;
ocr.AddSecondaryLanguage(OcrLanguage.German);

// Works on any machine, any OS, zero OS configuration required
var result = ocr.Read("multilingual-document.jpg");
Console.WriteLine(result.Text);

言語カタログには、ラテン語、CJK文字、アラビア語、ヘブライ語、デーヴァナーガリー文字、キリル文字、および数学記号などの特殊な文字セットがすべて含まれています。 各言語パックのバージョンはIronOCRパッケージのバージョンと連動しているため、本番環境で使用される言語モデルは、ローカル環境でテストされたものと一致します。

前処理の欠如

低品質のスキャン画像(わずかに回転したページ、斑点ノイズのあるコピーされたテキスト、オフホワイトの紙に薄れたインクなど)は、そのまま受け取ったOCRエンジンでは精度が低下します。 前処理によって、認識処理を実行する前にこれらの欠陥が修正されます。 Windows.Media.Ocr は、いかなる種類の前処理レイヤーも提供しません。

Windows.Media.OCR アプローチ

APIはSoftwareBitmapを受け入れ、テキストを返します。 その2点間の画質の変化は設定できません。 最適でない入力の精度を向上させる必要がある開発者は、SoftwareBitmapを構築する前にWindows Imaging Component APIを使用して手動で前処理を実装する必要があります。 それは独自の保守負担を伴う別のコードベースであり、OCR API自体がWindows専用であるのと同じ理由で、Windows専用のままになっている。

// Windows.Media.Ocr: no preprocessing — what you pass is what gets recognized
// Skewed, noisy, or low-resolution images degrade accuracy with no remedy
// Manual preprocessing via separate Windows Imaging APIs is the only option

var bitmap = await decoder.GetSoftwareBitmapAsync();
// bitmap goes directly to recognition with no quality improvement
var result = await engine.RecognizeAsync(bitmap);

標準的な、鮮明な文書スキャン(管理されたスキャン環境、一定の照明、最低300 DPI、正しい向き)であれば、この制限は許容範囲内です。 携帯電話のカメラ、自動給紙のずれがあるフラットベッドスキャナー、ファックス文書、またはコピーされた資料から画像を受け取る文書処理パイプラインの場合、これは前処理レイヤーをゼロから構築するか、精度の低下を受け入れるかのどちらかを意味します。

IronOCRのアプローチ

IronOCRのOcrInputクラスは、順番に適用される個々のフィルタメソッドを備えた前処理パイプラインを提供します。 画像品質補正フィルターは、生産文書処理における最も一般的な精度低下要因に対処します。

// IronOCR: explicit preprocessing pipeline
// Each filter targets a specific quality defect
using var input = new OcrInput();
input.LoadImage("low-quality-scan.jpg");

input.Deskew();              // Correct page rotation up to ~40 degrees
input.DeNoise();             // Remove scanner speckle and compression artifacts
input.Contrast();            // Boost contrast on faded or washed-out text
input.Binarize();            // Convert to black/white with optimal threshold
input.EnhanceResolution(300); // Scale image to 300 DPI for recognition

var result = new IronTesseract().Read(input);
Console.WriteLine($"Confidence: {result.Confidence}%");

一般的なケースでは、IronOCRはファイルパスにReadを直接呼び出す際に自動前処理を適用し、エンジンが品質問題を検出して、明示的なフィルタ構成なしに修正します。 画像フィルタチュートリアルは、ToGrayScaleを含む、特殊なシナリオのための完全なフィルタセットをカバーしています。 色補正フィルター向き補正は、標準以外の色プロファイルを持つドキュメントや、複数の角度で回転されたドキュメントに対応するために、処理パイプラインをさらに拡張します。

PDFサポート不在

PDFはEnterprise環境において最も主流な文書フォーマットである。 契約書、請求書、スキャンされたアーカイブ、政府発行の書類などはPDFファイルで届きます。 Windows.Media.OcrにはPDFの概念はなく、画像データのみを受け入れます。 PDF文書のOCR処理には、別途PDFレンダリングライブラリ、ページごとのラスタライズ処理、および結果の手動による組み立てが必要となる。

Windows.Media.OCR アプローチ

APIにはPDFへのパスは含まれていません。 Windows.Media.OcrでスキャンしたPDFをOCRするために、開発者は次のように行います: 個別のPDFレンダリングライブラリ(Windowsに組み込まれていないもの)を使用して各ページをRecognizeAsyncを呼び出し、結果を手動で連結します。 そのレンダリングライブラリ自体には、追加のライセンスおよび展開に関する考慮事項があります。 Windows.Media.Ocr コードは、実装全体のごく一部です。

// Windows.Media.Ocr: no PDF support
// Requires external PDF renderer to rasterize pages before OCR
// Conceptual pattern — a PDF rendering library is not provided by Windows APIs

// Step 1: Use external PDF library to render page to bitmap (not shown)
// Step 2: Pass rendered bitmap to Windows OCR
// var bitmap = RenderPdfPageToBitmap(pdfPath, pageIndex); // external library required

var engine = OcrEngine.TryCreateFromUserProfileLanguages();
if (engine == null)
    throw new Exception("No OCR language available");

// Step 3: Recognize the rasterized page
// var result = await engine.RecognizeAsync(bitmap);
// Step 4: Collect and concatenate results across all pages manually

外部PDFレンダリングのステップを追加するだけで、当初は"無料で組み込み済みの"ソリューションだったものが、依存関係、学習曲線、そして新たな障害発生箇所を抱えることになる。

IronOCRのアプローチ

IronOCRはPDFをネイティブに読み取ります。 外部レンダラーなし、ラスタライズ工程なし、手動ページ組み立てなし。 画像パスを受け入れる同じIronTesseract.Readメソッドは、PDFパスも受け入れます。 .NETにおけるPDF OCRはたった1行のコードで実現できます。

// IronOCR: native PDF support — no external renderer needed
var text = new IronTesseract().Read("scanned-document.pdf").Text;

// Password-protected PDFs
using var input = new OcrInput();
input.LoadPdf("encrypted.pdf", Password: "secret");
var result = new IronTesseract().Read(input);
Console.WriteLine(result.Text);

// 検索可能なPDF output: make a scanned PDF text-searchable
var ocrResult = new IronTesseract().Read("scanned-archive.pdf");
ocrResult.SaveAsSearchablePdf("searchable-output.pdf");
C#

検索可能なPDF機能は、元のスキャン画像の上にテキストレイヤーを埋め込むことで、視覚的な忠実度を維持しながら、全文検索やコピー&ペーストを可能にするPDFを生成します。 これは、文書管理システムやコンプライアンスアーカイブにおける一般的な要件です。 Windows.Media.Ocr は、その API のどのレベルにおいても、この出力を生成することはできません。

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

Windows.Media.OcrIronOCR相当値
OcrEngine.TryCreateFromLanguage(lang)new IronTesseract() with ocr.Language = OcrLanguage.X
OcrEngine.TryCreateFromUserProfileLanguages()new IronTesseract() (デフォルト言語自動解決)
engine.RecognizeAsync(softwareBitmap)ocr.Read("image.jpg") or ocr.Read(ocrInput)
OcrResult.TextOcrResult.Text
OcrResult.LinesOcrResult.Lines (拡張メタデータ付き)
OcrLine.TextOcrResult.Lines[i].Text
OcrLine.WordsOcrResult.Words (バウンディングボックス+信頼度付き)
OcrWord.BoundingRectOcrResult.Words[i].X, .Y, .Width, .Height
BitmapDecoder.CreateAsync(stream)input.LoadImage(stream) via OcrInput
StorageFile.GetFileFromPathAsync(path)ocr.Read("path") directly
同等のファイルはありません(PDFはサポートされていません)ocr.Read("document.pdf")
同等のファイルはありません(PDFはサポートされていません)input.LoadPdf("file.pdf", Password: "x")
同等のファイルはありません(検索可能なPDFファイルはありません)。result.SaveAsSearchablePdf("output.pdf")
同等の項目なし(前処理なし)input.Deskew(), input.DeNoise(), input.Contrast()
同等のものはありません(多言語対応ではありません)ocr.AddSecondaryLanguage(OcrLanguage.X)
該当するものなし(信頼性なし)result.Confidence, word.Confidence

チームがWindows.Media.OcrからIronOCRへの移行を検討する場合

アプリケーションがWindowsデスクトップの容量を超えました

最も一般的なきっかけは、Windows以外の展開対象を導入する要件変更です。 当初はWindowsの内部ツールとして開発されたデスクトップユーティリティが、Webサービス、Dockerベースのマイクロサービス、またはクラウド機能へと昇格する。 その瞬間、Windows.Media.Ocr が障害物となる。 OCRコンポーネントは、対象プラットフォームにAPIが存在しないため、完全に書き直す必要があります。ポートも互換性シムも、問題を解決する条件付きコンパイルフラグもありません。 IronOCRを事前に導入していたチームは、今回の書き換え作業の必要はありません。

言語要件がインストール済みパックを超えています

文書処理パイプラインは、しばしばその範囲を拡大する。 英語の請求書を処理するために構築されたシステムに、フランス語、ドイツ語、アラビア語、または日本語の文書を処理する必要性が生じる。 Windows.Media.Ocr を使用する場合、これらの言語をサポートするには、開発者マシン、テスト用仮想マシン、本番サーバー、およびそれらに含まれるすべてのコンテナなど、すべての展開対象にわたって OS 言語パックのインストールを調整する必要があります。 グループポリシーで管理される環境や、OSのフットプリントが最小限のクラウドVMでは、そのような連携は現実的ではありません。 IronOCRのNuGetベースの言語パックはアプリケーションと共にデプロイされるため、OSとの連携は不要です。

PDF処理が対象範囲に追加されました

当初の要件が"フラットベッドスキャナーからの画像をOCR処理する"だった場合、Windows.Media.Ocrは機能します。 要件が"アーカイブに蓄積されたスキャン済みPDFの処理も行う"まで拡大すると、2つ目のライブラリが検討対象に加わる。 そのライブラリは、追加の依存関係、追加のライセンス上の考慮事項、そして追加の障害発生箇所となる。 画像OCRとPDF OCRの両方を統一されたAPIで必要とするチームにとって、 IronOCRは最初から2つのライブラリを使用するアーキテクチャを排除できることが分かります。

実世界の入力では精度が低下する

管理されたスキャン環境は、鮮明な画像を生み出す。 実際の入力データ(携帯電話で撮影した写真、わずかに傾いたフラットベッドスキャン、古いファックスで受信した文書、コピーされた資料など)は、Windows.Media.Ocr では修正できない精度低下を引き起こします。 顧客からテキストメッセージが届かなかったという苦情が寄せられ始めると、チームはこれまで省略していた前処理手順が必要になったことに気づく。 WindowsイメージングAPIを使用した前処理を後付けすることは、相当な開発作業となり、ソリューションがWindows専用のままになってしまう。 IronOCRの前処理パイプラインは既に完成している。

サーバー展開に関する疑問が生じる

Windows.Media.Ocr のドキュメントでは、クライアントアプリケーション向けの API が明確に位置づけられています。 サーバー環境(ユーザーがアップロードしたドキュメントを処理するASP.NETアプリケーション、ドキュメントキューを利用するWindowsサービスなど)で実行するには、デスクトップエクスペリエンスがインストールされたWindows Server環境が必要となり、これはLinuxコンテナよりも負荷が高く、コストも高くなります。 インフラストラクチャチームが、ホスティングコストを削減するためにOCRワーカーをLinuxインスタンスで実行できるかどうかを尋ねた場合、Windows.Media.Ocrでは答えは"いいえ"です。

一般的な移行の考慮事項

プロジェクトファイル TFM の変更

Windows.Media.Ocrは、プロジェクトファイルにWindows専用のTFMが必要です (net8.0-windows10.0.19041.0など)。 クロスプラットフォーム対応のためにその依存関係を解消するということは、TFMサフィックスを削除することを意味します。 IronOCRは、Windows専用のサフィックスなしでnet9.0をターゲットにしています。 移行時には、プロジェクト内の他の WinRT API 依存関係が Windows TFM を必要としないことを確認してください。他の Windows プラットフォーム機能 (シェル統合、Windows 通知など) は、プラットフォームチェックの背後に抽象化する必要がある場合があります。

非同期から同期への移行

Windows.Media.Ocrは完全に非同期です — Task<OcrResult>にマッピングされます。IronOCRは同期および非同期の両方のパスを提供します。 同期型ocr.Read("file.jpg")は多段のawaitチェーンを直接置き換えます。 OCR呼び出しがバックグラウンドサービスまたはタスクベースのパイプライン内に存在するサーバーアプリケーションの場合、非同期パスも利用可能です。 いずれにしても、6つ以上の非同期ステップから1つの呼び出しへの移行は簡単です。

// Before: Windows.Media.Ocr — 6+ await operations
var file = await StorageFile.GetFileFromPathAsync(imagePath);
using var stream = await file.OpenAsync(FileAccessMode.Read);
var decoder = await BitmapDecoder.CreateAsync(stream);
var bitmap = await decoder.GetSoftwareBitmapAsync();
var engine = OcrEngine.TryCreateFromUserProfileLanguages();
var winResult = await engine.RecognizeAsync(bitmap);
string text = winResult.Text;

// After: IronOCR — 1 call, same result, any platform
string text = new IronTesseract().Read(imagePath).Text;

言語パックの置き換え

以前ocr.Language = OcrLanguage.Frenchを設定します。 IronOCRの言語カタログには、利用可能な125種類以上のパックがすべて掲載されています。 言語コードはBCP-47タグからOcrLanguage列挙型へ簡単にマッピングされます。

ヌルエンジンのハンドリング削除

Windows.Media.Ocr では、エンジン作成呼び出しのたびに null チェックを行う必要があります。 IronOCRは、設定または初期化の失敗時にnullを返すのではなく、構造化された例外をスローします。 nullチェックのガード句を削除し、必要に応じて標準的な例外処理に置き換えてください。 その結果、よりクリーンな通話サイトが実現し、"利用できない言語がサイレントに表示される"という障害モードも発生しなくなりました。

IronOCRの追加機能

IronOCRは、Windows.Media.Ocrの機能を直接置き換える機能に加えて、Windows.Media.Ocrには同等の機能がない以下の機能も備えています。

-スキャン文書処理— TIFFや複数ページのPDF入力を含む、複数ページのスキャンアーカイブ専用の処理機能 -表の抽出— 請求書明細項目、レポートグリッド、フォームマトリックスなど、文書内の表形式データを構造的に検出します。 -特殊な文書タイプ(パスポートのMRZゾーン、MICRチェックライン、ナンバープレート、手書き文字など)には、それぞれ専用の処理経路が用意されています。 -進捗状況の追跡— バッチ処理はイベントを介して進捗状況を報告し、アプリケーションUIで進捗バーと処理速度の監視を可能にします。

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

IronOCRは、プラットフォーム固有のサフィックスのない標準TFM上で.NET 6、 .NET 7、 .NET 8、および.NET 9をサポートするとともに、レガシーアプリケーションのサポートとして.NET Framework 4.6.2から4.8までをサポートしています。 このライブラリは、 .NET のリリースサイクルに合わせて定期的に更新され、2026 年のロードマップには.NET 10 のサポートが含まれています。Windows.Media.Ocr は、 .NET 5 以降で WinRT 相互運用をサポートするすべて for .NETバージョンで使用できますが、Windows TFM の要件により、適用対象は Windows をターゲットとするプロジェクトに限定されます。 .NETのクロスプラットフォーム戦略が成熟するにつれ、より多くのチームがLinuxコンテナやクラウド関数を第一級のデプロイメントターゲットとして採用するようになるにつれて、Windows.Media.OcrのTFM制約は、些細な注意点ではなく、より顕著なアーキテクチャ上の問題となってきています。

結論

Windows.Media.Ocrは、特定の正当なニッチ市場を開拓しています。それは、クロスプラットフォーム対応を一切目指さず、基本的な画像OCR機能のみを必要とし、予算も0ドルという厳しい制約のあるWindows 10/11デスクトップアプリケーションです。そして、そのニッチ市場において、このアプリケーションは十分に機能します。 そのニッチな分野以外、つまりLinuxコンテナ、クラウド関数、多言語要件を持つサーバー、またはPDFを処理するドキュメントパイプラインを対象とするデプロイメントの場合、対象プラットフォームにはAPIが存在しないため、コードを置き換える必要があります。

より根本的な問題は、Windows.Media.Ocrの制限が偶発的なものではなく、アーキテクチャ上の問題であるということだ。 プラットフォームのロックインは、無効にする設定フラグではありません。 APIが依存しているWinRTランタイムに組み込まれています。 言語の可用性は、ビルド時に含めるべきパッケージではなく、OS管理者に委ねられています。 PDFサポートは、 NuGetパッケージで追加すべき不足機能ではありません。 APIインターフェース上には全く存在しない。 それぞれの制約には、それを補うための別のシステムが必要であり、それぞれの補填システムはプラットフォームへの依存性を再び生み出す。

IronOCRは、プラットフォーム、言語、前処理、PDFという4つの制約すべてを単一のパッケージで解決します。 $999のエントリ価格は$0ではなく、管理された入力と英語のみの文書を持つWindows専用のデスクトップユーティリティの場合、Windows.Media.Ocrは有効な選択のままです。より広範な要件を持つプロジェクトでは、Windows.Media.Ocrの制限に基づいて構築するコストが、プロジェクトが最初の本番展開に達する前に、開発者の時間の中でIronOCRのライセンスコストを超える可能性があります。

実地テストは簡単です。展開先がLinux、Docker、またはクラウド機能になる可能性があり、入力ドキュメントがPDFであったり、デフォルトのOSパック以外の言語で入力される可能性がある場合、Windows.Media.Ocrは適切な基盤ではありません。 プロジェクトの途中でそれに気づくのは、最初から適切なツールを選ぶよりもはるかにコストがかかる。 IronOCRの機能セットを自社の具体的な要件と照らし合わせて評価してから、どちらの方向性を選択するかを決定するのが、最も効率的な方法です。

ご注意: TesseractおよびWindows Media OCRはそれぞれの所有者の登録商標です。 本サイトはGoogleやMicrosoftと提携しておらず、推薦またはスポンサーされていません。 すべての製品名、ロゴ、およびブランドは各所有者の所有物です。 比較は情報提供のみを目的としており、執筆時点で公開されている情報を反映しています。

関連する記事

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日間の試用キーをすぐに入手。
クレジットカードやアカウントの作成は不要です。