Zum Fußzeileninhalt springen
MIT ANDEREN KOMPONENTEN VERGLEICHEN

OCR in Azure vs. IronOCR: Welche Lösung zur optischen Zeichenerkennung eignet sich am besten für .NET-Projekte?

Windows.Media.Ocr wird bei jeder Windows 10- und Windows 11-Installation kostenlos mitgeliefert, was es attraktiv macht, bis man versucht, dieselbe Anwendung auf einem Linux-Server, einem Docker-Container oder einer AWS Lambda-Funktion bereitzustellen – dann existiert die API schlichtweg nicht. Plattformabhängigkeit ist bei dieser Bibliothek kein Sonderfall; Es handelt sich um die entscheidende Einschränkung. Jede architektonische Entscheidung, die sich aus der Wahl von Windows.Media.Ocr ergibt, wird durch die Anforderung geprägt, dass das Host-Betriebssystem ein Windows 10- oder Windows 11-Desktop-PC oder ein Server für Endverbraucher sein muss. Kein Linux, kein macOS, kein Docker, keine Azure Functions unter Linux, kein AWS Lambda. Für Entwickler, die interne Windows-Tools erstellen und keinerlei Absicht haben, diese Grenze zu überschreiten, ist der Preis von 0 Dollar kaum zu überbieten. Für alle anderen besteht der versteckte Kostenaufwand darin, dass OCR bei sich ändernden Bereitstellungsanforderungen komplett in ein anderes System umgeschrieben werden muss.

Windows.Media.OCR verstehen

Windows.Media.Ocr ist Teil der Windows Runtime (WinRT) API-Oberfläche, die in Windows 8.1 eingeführt und für Windows 10 und 11 verfeinert wurde. Es gibt eine OcrEngine-Klasse im Windows.Media.Ocr-Namensraum, die eine SoftwareBitmap akzeptiert - selbst ein WinRT-Typ aus Windows.Graphics.Imaging - und gibt eine OcrResult zurück, die erkannten Text und Liniengeometrie enthält.

Die API basiert auf dem async/await-Vertrag von WinRT. Jeder Vorgang erfolgt über async Task-Aufrufe, die von WinRT-IAsyncOperation-Mechanismen unterstützt werden: Laden Sie eine StorageFile, öffnen Sie einen Stream, erstellen Sie eine BitmapDecoder, holen Sie eine SoftwareBitmap, und erst dann wird RecognizeAsync aufgerufen. Ab .NET 6 erfordert der Konsum von WinRT-APIs einen Windows-spezifischen Target Framework Moniker (TFM) wie z.B. net8.0-windows10.0.19041.0. Eine Projektdatei ohne dieses TFM kann keinen Code kompilieren, der Windows.Media.Ocr referenziert - die Typen existieren einfach nicht im Assemblygraphen.

Wichtigste architektonische Merkmale:

  • Nur Windows 10/11 – die WinRT-API-Oberfläche ist unter Windows-Serverohne Desktopdarstellung in keiner Konfiguration verfügbar und fehlt unter Linuxund macOSvollständig.
  • WinRT-Async-Modell - alle Erkennungen erfolgen über IAsyncOperation-gestützte Async-Aufrufe; kein synchroner Pfad existiert
  • Sprachpakete vom Betriebssystem - OcrEngine.TryCreateFromLanguage und TryCreateFromUserProfileLanguages lösen verfügbare Sprachen aus den von Benutzern oder IT-Administratoren installierten Windows-Sprachpaketen auf dieser bestimmten Maschine; es gibt kein gebündeltes oder tragbares Sprachmodell
  • Nur Bild-Eingabe - die API akzeptiert SoftwareBitmap direkt; Auf keiner Ebene der API existiert ein PDF-Eingabepfad.
  • Keine Vorverarbeitungspipeline – die rohe Bitmap wird an den Erkennungsalgorithmus übergeben; Rotationskorrektur, Rauschentfernung, Kontrastverbesserung und Auflösungsskalierung liegen in der Verantwortung des Entwicklers und erfolgen mithilfe separater Windows Imaging APIs.
  • Keine durchsuchbare PDF-Ausgabe — erkannter Text wird als einfacher String mit Liniengeometrie zurückgegeben; Es wird kein PDF-Export angeboten.
  • Windows-spezifisches TFM erforderlich - Projektdateien müssen auf ein net*-windows* TFM abzielen, was verhindert, dass dasselbe Projekt plattformübergreifend kompiliert wird

Der WinRT Async Stack

Jede grundlegende OCR-Operation mit Windows.Media.Ocr erfordert das Durchlaufen mehrerer Ebenen der WinRT-API-Oberfläche, bevor die Erkennung beginnen kann:

// 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;
}
// 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;
}
Imports System.Threading.Tasks
Imports Windows.Media.Ocr
Imports Windows.Storage
Imports Windows.Graphics.Imaging
Imports Windows.Storage.Streams
Imports Windows.Globalization

Public Async Function ExtractTextAsync(imagePath As String) As Task(Of String)
    ' Step 1: WinRT file system access
    Dim file As StorageFile = Await StorageFile.GetFileFromPathAsync(imagePath)

    ' Step 2: Open WinRT stream
    Using stream As IRandomAccessStream = Await file.OpenAsync(FileAccessMode.Read)

        ' Step 3: Create bitmap decoder
        Dim decoder As BitmapDecoder = Await BitmapDecoder.CreateAsync(stream)

        ' Step 4: Decode to SoftwareBitmap
        Dim bitmap As SoftwareBitmap = Await decoder.GetSoftwareBitmapAsync()

        ' Step 5: Check language availability — Nothing if not installed on this machine
        Dim engine As OcrEngine = OcrEngine.TryCreateFromLanguage(New Language("en-US"))
        If engine Is Nothing Then
            Throw New Exception("OCR engine not available for this language")
        End If

        ' Step 6: Recognize
        Dim result As OcrResult = Await engine.RecognizeAsync(bitmap)
        Return result.Text
    End Using
End Function
$vbLabelText   $csharpLabel

Die Null-Prüfung auf engine ist nicht optional. Wenn das Zielsprachpaket nicht auf der Maschine installiert ist, die den Code ausführt, gibt TryCreateFromLanguage null zurück und die Erkennung ist unmöglich. Es gibt keinen Ausweg; Die Anwendung muss dem Benutzer einen Fehler anzeigen oder stillschweigend fehlschlagen.

IronOCR verstehen

IronOCR ist eine kommerzielle .NET OCR-Bibliothek, die auf einer optimierten Tesseract 5-Engine basiert und über eine verwaltete API-Schicht verfügt, die Vorverarbeitung, PDF-Lesen, Mehrsprachenauflösung und Ausgabe strukturierter Daten übernimmt. Es wird als einzelnes NuGet Paket installiert, ohne dass externe native Binärdateien separat bereitgestellt werden müssen, ohne dass tessdata-Ordner verwaltet werden müssen und ohne dass plattformspezifische TFMs erforderlich sind.

Hauptmerkmale:

  • Plattformübergreifend konzipiert – läuft ohne Codeänderungen unter Windows, Linux, macOS, Docker, Azure App Service (Windows oder Linux), AWS Lambdaund GCP Cloud Run.
  • Automatische Vorverarbeitung - Deskewing, Rauschminderung, Kontrasterhöhung, Binarisierung und Auflösungsskalierung werden automatisch auf qualitativ minderwertige Eingaben angewendet, mit expliziter Steuerung über OcrInput-Filtermethoden
  • Nativem PDF-Eingang - IronTesseract.Read akzeptiert PDF-Pfade direkt; kein Konvertierungsschritt, keine externe Bibliothek
  • Mehr als 125 Sprachen sind enthalten — Sprachpakete sind NuGet Pakete, die mit der Anwendung bereitgestellt werden; keine Abhängigkeit von auf dem Betriebssystem installierten Sprachdaten
  • Durchsuchbare PDF-Ausgabe - OcrResult.SaveAsSearchablePdf erstellt ein Text-Layer-PDF aus jedem gescannten Eingang
  • Strukturiertes Ergebnismodell - OcrResult bietet Pages, Paragraphs, Lines, Words und Zuverlässigkeitswerte sowie Begrenzungsrahmen pro Wort
  • Thread-sicher - IronTesseract Instanzen unterstützen parallele Workloads ohne zusätzliche Synchronisation
  • Unbefristete Lizenzierung - $999 Lite bis $5,999 Unlimited, einmaliger Kauf, unbegrenzte Dokumentenverarbeitung

Funktionsvergleich

Feature Windows.Media.Ocr IronOCR
Plattform Nur für Windows 10/11 Windows, Linux, macOS, Docker, Cloud
Preis Kostenlos $5,999 unbefristet
PDF-Eingabe Nein Native
Sprachmodell Vom Betriebssystem installierte Pakete Über 125 Pakete, die über NuGet verfügbar sind
Vorverarbeitung None Automatische + explizite Filter
Durchsuchbare PDF-Ausgabe Nein Ja
API-Modell WinRT asynchron Standard .NET

Detaillierter Funktionsvergleich

Feature Windows.Media.Ocr IronOCR
Windows, Linux, macOS, Docker, Azure, AWS.
Windows 10/11 Ja Ja
Windows-Server Beschränkt Ja
Linux Nein Ja
macOS Nein Ja
Docker Nein Ja
Azure Functions (Linux) Nein Ja
AWS Lambda Nein Ja
Eingabeformate
JPEG / PNG / BMP Ja (über die WinRT-Pipeline) Ja
PDF (eingescannt) Nein Ja
PDF (passwortgeschützt) Nein Ja
TIFF / mehrseitig Nein Ja
Stream / Byte-Array Nein (nur WinRT StorageFile) Ja
URL Nein Ja
Sprachunterstützung
Sprachquelle Vom Betriebssystem installierte Sprachpakete Mehr als 125 gebündelte NuGet -Pakete
Installation ohne Betriebssystemadministrator Nein Ja (NuGet)
Mehrsprachige Simultanübertragung Nein Ja
Sprachportabilität zwischen verschiedenen Maschinen Nein Ja
Vorverarbeitung
Entschiefen Nein Ja (input.Deskew())
Rauschunterdrückung Nein Ja (input.DeNoise())
Kontrastverbesserung Nein Ja (input.Contrast())
Binärisierung Nein Ja (input.Binarize())
Auflösungsskalierung Nein Ja (input.EnhanceResolution(300))
Ausgabe
Klartext Ja Ja
Durchsuchbares PDF Nein Ja
hOCR / HTML Nein Ja
Begrenzungsrahmen auf Wortebene Teilweise (Liniengeometrie) Ja
Vertrauenswerte pro Wort Nein Ja
API-Entwurf
TFM-Beschränkung net*-windows* erforderlich None
Synchroner Pfad Nein Ja
Barcode-Lesung während der OCR Nein Ja
Regionsbasierte OCR Nein Ja

Plattformbindung vs. plattformübergreifende Bereitstellung

Der wichtigste Unterschied zwischen diesen beiden Bibliotheken liegt nicht in der Genauigkeit, nicht in der Vorverarbeitung und nicht in der PDF-Unterstützung – es ist die Bereitstellungstopologie. Windows.Media.Ocr existiert nur außerhalb von Windows 10/11. Das ist kein Konfigurationsproblem oder ein fehlendes NuGet Paket; Die WinRT-Laufzeitumgebung, die die API unterstützt, fehlt auf allen anderen Betriebssystemen.

Windows.Media.OCR-Ansatz

Die WinRT-Abhängigkeit manifestiert sich in der Projektdatei, bevor auch nur eine einzige Codezeile ausgeführt wird. Der TargetFramework muss eine Windows-Plattformversion angeben:


<PropertyGroup>
  <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
</PropertyGroup>

<PropertyGroup>
  <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
</PropertyGroup>
XML

Aufgrund dieser TFM kann das Projekt nicht in einem Linux-Container verwendet werden. Ein Docker-Image basierend auf mcr.microsoft.com/dotnet/aspnet:8.0 — dem Standard-Linux-Basisimage für ASP.NET-Bereitstellungen — hat keine WinRT-Laufzeit. Der Versuch, Windows.Media.Ocr-Typen in einem Projekt, das auf net8.0 (ohne Windows-Suffix) abzielt, zu referenzieren, führt zu Kompilierungsfehlern, nicht zu Laufzeitfehlern. Die Festlegung des Systems erfolgt während der Bauphase.

Wenn OCR-Anforderungen in einer Microservices-Architektur auftreten, in der der OCR-Worker unter Linuxläuft, oder in einer CI/CD-Pipeline, die plattformübergreifende Docker-Images erzeugt, ist Windows.Media.Ocr keine Option, die evaluiert werden kann – sie wird bereits vor dem ersten Auftreten von Problemen ausgeschlossen.

IronOCR-Ansatz

IronOCR zielt auf net6.0, net7.0, net8.0 und net9.0 ohne plattformspezifische TFMs. Das gleiche NuGet Paket und die gleiche Anwendungsdatei laufen unter Windows, Linuxund macOS. Das Deployen von IronOCR in Docker erfordert eine apt-get-Zeile für libgdiplus im Linux-Basisimage, sonst nichts:

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"]

Der Anwendungscode selbst ist zwischen den Windows- und Linux-Versionen unverändert:

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

IronOcr.License.LicenseKey = "YOUR-LICENSE-KEY";
var text = new IronTesseract().Read("document.jpg").Text;
// Same code — Windows, Linux, macOS, Docker, AWS Lambda
//Neinplatform TFM, no WinRT, no conditional compilation
using IronOcr;

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

IronOcr.License.LicenseKey = "YOUR-LICENSE-KEY"
Dim text As String = New IronTesseract().Read("document.jpg").Text
$vbLabelText   $csharpLabel

IronOCR läuft auf AWS Lambda , Azure Functions auf Linux und direkt auf Linux-Servern ohne Codeänderung. Das Bereitstellungsziel ist eine Konfigurationsfrage, keine architektonische Einschränkung.

Sprachunterstützung: Betriebssystemabhängigkeit vs. Paketlösungen

Windows.Media.Ocr delegiert die Sprachverfügbarkeit vollständig an den Hostrechner. Welche Sprachen Ihre Anwendung erkennt, hängt davon ab, welche Sprachpakete der Benutzer – oder ein IT-Administrator – auf der jeweiligen Windows-Installation installiert hat. Dadurch entsteht eine Art von Produktionsfehler, der nichts mit Ihrem Code zu tun hat.

Windows.Media.OCR-Ansatz

OcrEngine.TryCreateFromLanguage gibt null zurück, wenn die angeforderte Sprache nicht installiert ist. TryCreateFromUserProfileLanguages gibt null zurück, wenn überhaupt kein OCR-fähiges Sprachpaket existiert. Beide Wege erfordern die Behandlung von Nullwerten, und keiner bietet einen eleganten Wiederherstellungspfad – es gibt keine Möglichkeit, eine Sprache aus dem Code zu installieren oder sie mit der Anwendung zu bündeln:

// 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: 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);
Imports Windows.Globalization
Imports Windows.Media.Ocr

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

Dim engine = OcrEngine.TryCreateFromLanguage(New Language("fr-FR"))

If engine Is Nothing Then
    ' 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.")
End If

Dim result = Await engine.RecognizeAsync(bitmap)
$vbLabelText   $csharpLabel

Die Bereitstellung einer mehrsprachigen Dokumentenverarbeitungsanwendung mit Windows.Media.Ocr erfordert die Koordination der Installation von Windows-Sprachpaketen auf allen Rechnern im Bereitstellungsziel. Auf einem gemeinsam genutzten Server oder einem Benutzerrechner, der über Gruppenrichtlinien verwaltet wird, liegt dies nicht in der Hand des Entwicklers.

IronOCR-Ansatz

IronOCR liefert Sprachmodelle als separate NuGet Pakete aus, die zusammen mit der Anwendungsdatei bereitgestellt werden. Die Sprachdaten werden mit dem Build-Artefakt übertragen, nicht mit der Betriebssystemkonfiguration. Unterstützung von 125+ Sprachen ist ein dotnet add package-Vorgang:

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);
// 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);
Imports IronOcr

' IronOCR: language availability is a deploy-time guarantee, not a runtime unknown
Dim ocr As New IronTesseract()
ocr.Language = OcrLanguage.French
ocr.AddSecondaryLanguage(OcrLanguage.German)

' Works on any machine, any OS, zero OS configuration required
Dim result = ocr.Read("multilingual-document.jpg")
Console.WriteLine(result.Text)
$vbLabelText   $csharpLabel

Der vollständige Sprachkatalog umfasst Latein, CJK, Arabisch, Hebräisch, Devanagari, Kyrillisch und spezielle Zeichensätze einschließlich mathematischer Notation. Jede Sprachpaketversion ist an die IronOCR Paketversion gekoppelt, sodass das Sprachmodell in der Produktionsumgebung mit dem lokal getesteten übereinstimmt.

Vorverarbeitung Abwesenheit

Scans von geringer Qualität – leicht gedrehte Seiten, fotokopierter Text mit Bildrauschen, verblasste Tinte auf cremefarbenem Papier – führen zu einer schlechten OCR-Genauigkeit bei jeder Engine, die sie unverändert erhält. Durch die Vorverarbeitung werden diese Fehler vor der Erkennung behoben. Windows.Media.Ocr bietet keinerlei Vorverarbeitungsschicht.

Windows.Media.OCR-Ansatz

Die API akzeptiert eine SoftwareBitmap und gibt Text zurück. Wie sich die Bildqualität zwischen diesen beiden Zeitpunkten entwickelt, lässt sich nicht konfigurieren. Entwickler, die die Genauigkeit bei suboptimalen Eingaben verbessern müssen, müssen die Vorverarbeitung manuell unter Verwendung der Windows Imaging Component APIs implementieren, bevor sie die SoftwareBitmap konstruieren. Das ist eine separate Codebasis mit eigenem Wartungsaufwand und bleibt aus demselben Grund Windows-spezifisch wie die OCR-API selbst:

// 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);
// 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);
Imports System.Threading.Tasks

' 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

Dim bitmap = Await decoder.GetSoftwareBitmapAsync()
' bitmap goes directly to recognition with no quality improvement
Dim result = Await engine.RecognizeAsync(bitmap)
$vbLabelText   $csharpLabel

Bei standardmäßigen, sauberen Dokumentenscans (kontrollierte Scanumgebung, gleichmäßige Beleuchtung, mindestens 300 DPI, korrekte Ausrichtung) ist diese Einschränkung verkraftbar. Für Dokumentenverarbeitungspipelines, die Bilder von Handykameras, Flachbettscannern mit automatischer Einzugsfehlausrichtung, gefaxten Dokumenten oder fotokopierten Materialien empfangen, bedeutet dies entweder den Aufbau einer Vorverarbeitungsschicht von Grund auf oder die Akzeptanz von Genauigkeitseinbußen.

IronOCR-Ansatz

Die OcrInput-Klasse von IronOCR bietet eine Vorverarbeitungspipeline mit einzelnen Filtermethoden, die in Reihe angewendet werden. Bildqualitätskorrekturfilter beheben die häufigsten Fehlerquellen bei der Dokumentenverarbeitung in der Produktion:

// 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: 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}%");
Imports IronOcr

' IronOCR: explicit preprocessing pipeline
' Each filter targets a specific quality defect
Using input As 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

    Dim result = New IronTesseract().Read(input)
    Console.WriteLine($"Confidence: {result.Confidence}%")
End Using
$vbLabelText   $csharpLabel

Für den allgemeinen Fall wendet IronOCR eine automatische Vorverarbeitung an, wenn direkt auf einem Dateipfad Read aufgerufen wird — die Engine erkennt Qualitätsprobleme und korrigiert sie ohne explizite Filterkonfiguration. Das Tutorial zu Bildfiltern deckt das gesamte Filterspektrum, einschließlich Sharpen, Dilate, Erode, Invert und ToGrayScale für spezialisierte Szenarien ab. Farbkorrekturfilter und Ausrichtungskorrektur erweitern den Workflow zusätzlich für Dokumente mit nicht standardmäßigen Farbprofilen oder Mehrwinkelrotation.

PDF-Unterstützung Abwesenheit

PDF ist das vorherrschende Dokumentenformat in Enterprise . Verträge, Rechnungen, gescannte Archive und Regierungsformulare kommen als PDFs an. Windows.Media.Ocr kennt kein PDF – es akzeptiert nur Bilddaten. Die OCR eines PDF-Dokuments erfordert eine separate PDF-Rendering-Bibliothek, eine seitenweise Rasterisierung und die manuelle Zusammenstellung der Ergebnisse.

Windows.Media.OCR-Ansatz

Es gibt keinen PDF-Pfad in der API. Um ein gescanntes PDF mit Windows.Media.Ocr zu OCRen, muss der Entwickler: jede Seite in ein SoftwareBitmap mithilfe einer separaten PDF-Rendering-Bibliothek (keine davon ist in Windows integriert) rendern, Seiten iterieren, RecognizeAsync pro Seite aufrufen und Ergebnisse manuell zusammenfügen. Diese Rendering-Bibliothek selbst bringt zusätzliche Lizenz- und Bereitstellungsaspekte mit sich. Der Windows.Media.Ocr-Code ist der kleinere Teil der Gesamtimplementierung:

// 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
// 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
' 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
' Dim bitmap = RenderPdfPageToBitmap(pdfPath, pageIndex) ' external library required

Dim engine = OcrEngine.TryCreateFromUserProfileLanguages()
If engine Is Nothing Then
    Throw New Exception("No OCR language available")
End If

' Step 3: Recognize the rasterized page
' Dim result = Await engine.RecognizeAsync(bitmap)
' Step 4: Collect and concatenate results across all pages manually
$vbLabelText   $csharpLabel

Allein der externe PDF-Rendering-Schritt fügt dem, was ursprünglich eine "kostenlose und integrierte" Lösung war, eine Abhängigkeit, eine separate Lernkurve und eine zusätzliche Fehlerquelle hinzu.

IronOCR-Ansatz

IronOCR liest PDFs nativ. Kein externer Renderer, kein Rasterisierungsschritt, keine manuelle Seitenzusammenstellung. Die gleiche IronTesseract.Read-Methode, die Bildpfade akzeptiert, akzeptiert auch PDF-Pfade. Die PDF-OCR in .NET ist eine einzeilige Operation:

// 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);

// Durchsuchbares PDF output: make a scanned PDF text-searchable
var ocrResult = new IronTesseract().Read("scanned-archive.pdf");
ocrResult.SaveAsSearchablePdf("searchable-output.pdf");
// 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);

// Durchsuchbares PDF output: make a scanned PDF text-searchable
var ocrResult = new IronTesseract().Read("scanned-archive.pdf");
ocrResult.SaveAsSearchablePdf("searchable-output.pdf");
Imports IronOcr

' IronOCR: native PDF support — no external renderer needed
Dim text As String = New IronTesseract().Read("scanned-document.pdf").Text

' Password-protected PDFs
Using input As New OcrInput()
    input.LoadPdf("encrypted.pdf", Password:="secret")
    Dim result = New IronTesseract().Read(input)
    Console.WriteLine(result.Text)
End Using

' Durchsuchbares PDF output: make a scanned PDF text-searchable
Dim ocrResult = New IronTesseract().Read("scanned-archive.pdf")
ocrResult.SaveAsSearchablePdf("searchable-output.pdf")
$vbLabelText   $csharpLabel

Die Funktion "Durchsuchbares PDF" bettet eine Textebene über das ursprüngliche gescannte Bild ein und erzeugt so ein PDF, das die visuelle Qualität beibehält und gleichzeitig die Volltextsuche und das Kopieren und Einfügen ermöglicht. Dies ist eine gängige Anforderung an Dokumentenmanagementsysteme und Compliance-Archive. Windows.Media.Ocr kann diese Ausgabe auf keiner Ebene seiner API erzeugen.

API-Mapping-Referenz

Windows.Media.Ocr IronOCR-Äquivalent
OcrEngine.TryCreateFromLanguage(lang) new IronTesseract() mit ocr.Language = OcrLanguage.X
OcrEngine.TryCreateFromUserProfileLanguages() new IronTesseract() (Standardsprache automatisch aufgelöst)
engine.RecognizeAsync(softwareBitmap) ocr.Read("image.jpg") oder ocr.Read(ocrInput)
OcrResult.Text OcrResult.Text
OcrResult.Lines OcrResult.Lines (mit erweitertem Metadaten)
OcrLine.Text OcrResult.Lines[i].Text
OcrLine.Words OcrResult.Words (mit Begrenzungsrahmen + Zuverlässigkeit)
OcrWord.BoundingRect OcrResult.Words[i].X, .Y, .Width, .Height
BitmapDecoder.CreateAsync(stream) input.LoadImage(stream) über OcrInput
StorageFile.GetFileFromPathAsync(path) ocr.Read("path") direkt
Kein Äquivalent (PDF wird nicht unterstützt) ocr.Read("document.pdf")
Kein Äquivalent (PDF wird nicht unterstützt) input.LoadPdf("file.pdf", Password: "x")
Kein Äquivalent (keine durchsuchbare PDF-Datei) result.SaveAsSearchablePdf("output.pdf")
Kein Äquivalent (keine Vorverarbeitung) input.Deskew(), input.DeNoise(), input.Contrast()
Kein Äquivalent (keine Mehrsprachigkeit) ocr.AddSecondaryLanguage(OcrLanguage.X)
Kein Äquivalent (kein Vertrauen) result.Confidence, word.Confidence

Wenn Teams einen Wechsel von Windows.Media.OCR zu IronOCR erwägen

Die Anwendung sprengt die Grenzen des Windows-Desktops.

Der häufigste Auslöser ist eine Anforderungsänderung, die ein Nicht-Windows-Bereitstellungsziel einführt. Ein Desktop-Dienstprogramm, das ursprünglich als internes Windows-Tool entwickelt wurde, wird zu einem Webdienst, einem Docker-basierten Mikrodienst oder einer Cloud-Funktion weiterentwickelt. Sobald das passiert, wird Windows.Media.Ocr zum Hindernis. Die OCR-Komponente muss komplett neu geschrieben werden, da die API auf der Zielplattform nicht existiert – es gibt keinen Port, keine Kompatibilitätsschicht und kein bedingtes Kompilierungsflag, das das Problem behebt. Teams, die mit IronOCR im Voraus geplant haben, sind von dieser Überarbeitung nicht betroffen.

Sprachanforderungen übersteigen die installierten Pakete

Dokumentenverarbeitungspipelines erweitern häufig ihren Umfang. Ein System, das für die Verarbeitung englischer Rechnungen konzipiert wurde, erhält die Anforderung, auch französische, deutsche, arabische oder japanische Dokumente verarbeiten zu können. Mit Windows.Media.Ocr erfordert die Unterstützung dieser Sprachen die Koordination der Installation des Betriebssystem-Sprachpakets auf allen Bereitstellungszielen – Entwicklerrechnern, Test-VMs, Produktionsservern und allen darin enthaltenen Containern. In Umgebungen, die über Gruppenrichtlinien verwaltet werden, oder in Cloud-VMs mit minimalem Betriebssystem-Footprint ist diese Koordination unpraktisch. Die NuGet-basierten Sprachpakete von IronOCR werden zusammen mit der Anwendung bereitgestellt und erfordern keine Betriebssystemkoordination.

PDF-Verarbeitung wird in den Leistungsumfang aufgenommen

Wenn die ursprüngliche Anforderung "OCR-Bilder von einem Flachbettscanner" lautete, funktioniert Windows.Media.Ocr. Wenn die Anforderung erweitert wird auf "auch die Verarbeitung des Rückstands an gescannten PDFs in unserem Archiv", kommt eine zweite Bibliothek ins Spiel. Diese Bibliothek stellt eine zusätzliche Abhängigkeit, eine zusätzliche Lizenzierungsüberlegung und eine zusätzliche Fehlerquelle dar. Teams, die sowohl Bild-OCR als auch PDF-OCR über eine einheitliche API benötigen, stellen fest, dass IronOCR die Zwei-Bibliotheken-Architektur von vornherein überflüssig macht.

Die Genauigkeit nimmt bei Eingaben aus der realen Welt ab.

Kontrollierte Scanumgebungen erzeugen saubere Bilder. Eingaben aus der Praxis – Fotos, die mit Mobiltelefonen aufgenommen wurden, leicht verzerrte Scans von Flachbettscannern, ältere Faxdokumente, fotokopierte Materialien – führen zu Genauigkeitseinbußen, die sich mit Windows.Media.Ocr nicht beheben lassen. Als die ersten Kundenbeschwerden über verpasste SMS eintreffen, stellen die Teams fest, dass der zuvor übersprungene Vorverarbeitungsschritt nun notwendig geworden ist. Die nachträgliche Integration der Vorverarbeitung mithilfe der Windows Imaging APIs ist ein erheblicher Entwicklungsaufwand, der die Lösung auf Windows beschränkt. Die Vorverarbeitungspipeline von IronOCR ist bereits vorhanden.

Es stellt sich die Frage der Serverbereitstellung.

Die Dokumentation zu Windows.Media.Ocr positioniert die API explizit für Clientanwendungen. Die Ausführung im Serverkontext – beispielsweise als ASP.NET Anwendung zur Verarbeitung von Benutzer-Upload-Dokumenten oder als Windows-Dienst zur Verarbeitung einer Dokumentenwarteschlange – erfordert eine Windows Server-Umgebung mit installierter Desktopdarstellung. Dies ist ein ressourcenintensiveres und teureres VM-Profil als ein Linux-Container. Wenn das Infrastrukturteam fragt, ob der OCR-Worker auf einer Linux-Instanz ausgeführt werden kann, um die Hostingkosten zu senken, lautet die Antwort bei Windows.Media.Ocr nein.

Gemeinsame Überlegungen zur Migration

Projektdatei TFM-Änderung

Windows.Media.Ocr erfordert ein Windows-spezifisches TFM in der Projektdatei (net8.0-windows10.0.19041.0 oder ähnlich). Um diese Abhängigkeit zu beseitigen und plattformübergreifende Ziele zu unterstützen, muss das Suffix TFM entfernt werden.IronOCR zielt auf net6.0, net8.0 und net9.0 ohne Windows-spezifische Suffixe. Bei der Migration ist zu prüfen, ob andere WinRT-API-Abhängigkeiten im Projekt das Windows TFM benötigen – gegebenenfalls müssen andere Windows-Plattformfunktionen (Shell-Integration, Windows-Benachrichtigungen usw.) durch Plattformprüfungen abstrahiert werden.

Migration von asynchron zu synchron

Windows.Media.Ocr ist vollständig asynchron — RecognizeAsync gibt IAsyncOperation<OcrResult> zurück, das über die WinRT-Interop auf Task<OcrResult> abbildet.IronOCR bietet sowohl synchrone als auch asynchrone Pfade. Der synchrone ocr.Read("file.jpg") ersetzt direkt die mehrstufige Await-Kette. Für Serveranwendungen, bei denen der OCR-Aufruf in einem Hintergrunddienst oder einer aufgabenbasierten Pipeline erfolgt, steht auch der asynchrone Pfad zur Verfügung. In beiden Fällen ist der Übergang von 6 oder mehr asynchronen Schritten zu einem einzigen Aufruf unkompliziert:

// 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;
// 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;
Imports Windows.Storage
Imports Windows.Graphics.Imaging
Imports Windows.Media.Ocr

' Before: Windows.Media.Ocr — 6+ await operations
Dim file As StorageFile = Await StorageFile.GetFileFromPathAsync(imagePath)
Using stream = Await file.OpenAsync(FileAccessMode.Read)
    Dim decoder As BitmapDecoder = Await BitmapDecoder.CreateAsync(stream)
    Dim bitmap = Await decoder.GetSoftwareBitmapAsync()
    Dim engine = OcrEngine.TryCreateFromUserProfileLanguages()
    Dim winResult = Await engine.RecognizeAsync(bitmap)
    Dim text As String = winResult.Text
End Using

' After: IronOCR— 1 call, same result, any platform
Dim text As String = New IronTesseract().Read(imagePath).Text
$vbLabelText   $csharpLabel

Sprachpaket-Ersetzung

Für jede Sprache, die zuvor über OcrEngine.TryCreateFromLanguage(new Windows.Globalization.Language("fr-FR")) aufgelöst wurde, installieren Sie das entsprechende IronOCR-Sprachpaket und setzen Sie ocr.Language = OcrLanguage.French. Der IronOCR Sprachkatalog listet alle über 125 verfügbaren Pakete auf. Sprachcodes werden problemlos von BCP-47-Tags auf das OcrLanguage-Enum abgebildet.

Null-Motorhandhabung Entfernung

Windows.Media.Ocr erfordert eine Nullprüfung bei jedem Aufruf zur Engine-Erstellung.IronOCR löst bei Konfigurations- oder Initialisierungsfehlern strukturierte Ausnahmen aus, anstatt null zurückzugeben. Entfernen Sie die Nullprüfungsklauseln und ersetzen Sie sie gegebenenfalls durch eine Standard-Ausnahmebehandlung. Das Ergebnis ist eine übersichtlichere Anrufplattform ohne den Fehlermodus "still nicht verfügbare Sprache".

Zusätzliche Funktionen von IronOCR

Über die Funktionen hinaus, die die Funktionalität von Windows.Media.Ocr direkt ersetzen, bietet IronOCR Funktionen, für die Windows.Media.Ocr kein Äquivalent hat:

  • Verarbeitung gescannter Dokumente – speziell entwickelte Verarbeitung für mehrseitige gescannte Archive, einschließlich TIFF- und mehrseitiger PDF-Dateien
  • Tabellenextraktion – strukturierte Erkennung tabellarischer Daten in Dokumenten für Rechnungspositionen, Berichtstabellen und Formularmatrizen
  • Spezielle Dokumenttypen – MRZ-Zonen im Reisepass, MICR-Scheckzeilen, Kfz-Kennzeichen und handschriftlicher Text – verfügen jeweils über eigene Verarbeitungspfade.
  • Fortschrittsverfolgung – Stapelverarbeitungsvorgänge melden ihren Fortschritt über Ereignisse, wodurch Fortschrittsbalken und die Überwachung der Verarbeitungsrate in den Anwendungs-UIs ermöglicht werden.

.NET-Kompatibilität und Zukunftsfähigkeit

IronOCR unterstützt .NET 6, .NET 7, .NET 8 und .NET 9 auf Standard-TFMs ohne plattformspezifische Suffixe sowie .NET Framework 4.6.2 bis 4.8 für die Unterstützung älterer Anwendungen. Die Bibliothek wird regelmäßig im Einklang mit dem .NET Releasezyklus aktualisiert, wobei die Unterstützung für .NET 10 für 2026 geplant ist. Windows.Media.Ocr ist ab .NET 5 auf jeder .NET Version verfügbar, die WinRT-Interop unterstützt, jedoch schränkt die Windows TFM-Anforderung die Anwendbarkeit dauerhaft auf Windows-Projekte ein. Mit zunehmender Reife der plattformübergreifenden Architektur von .NET – wobei immer mehr Teams Linux-Container und Cloud-Funktionen als erstklassige Bereitstellungsziele anvisieren – wird die TFM-Beschränkung von Windows.Media.Ocr zu einer deutlicheren architektonischen Schwäche und nicht mehr nur zu einem geringfügigen Vorbehalt.

Abschluss

Windows.Media.Ocr besetzt eine spezifische und legitime Nische: eine Windows 10/11Desktop-Anwendung ohne plattformübergreifende Ambitionen, mit grundlegenden Anforderungen an die Bild-OCR und einem strikten Budgetlimit von 0 US-Dollar. Innerhalb dieser Nische funktioniert sie. Außerhalb dieser Nische – sobald die Bereitstellung auf einen Linux-Container, eine Cloud-Funktion, einen Server mit mehreren Sprachanforderungen oder eine Dokumentenpipeline abzielt, die PDFs verarbeitet – existiert die API nicht auf der Zielplattform und der Code muss ersetzt werden.

Das eigentliche Problem ist, dass die Einschränkungen von Windows.Media.Ocr architektonisch bedingt und nicht zufällig sind. Plattformbindung ist keine Konfigurationsoption, die deaktiviert werden kann; Es ist in die WinRT-Laufzeitumgebung integriert, von der die API abhängt. Die Sprachverfügbarkeit ist kein Bestandteil des Build-Prozesses; sie wird den Betriebssystemadministratoren überlassen. PDF-Unterstützung ist keine fehlende Funktion, die mit einem NuGet Paket hinzugefügt werden sollte; Es fehlt vollständig auf der API-Oberfläche. Jede Einschränkung erfordert ein separates System, um sie auszugleichen, und jedes dieser Ausgleichssysteme führt zu neuen Plattformabhängigkeiten.

IronOCR erfüllt alle vier Anforderungen – Plattform, Sprache, Vorverarbeitung und PDF – in einem einzigen Paket. Der $999-Einstiegspreis ist nicht $0, und für ein Windows-Desktop-Dienstprogramm mit kontrollierten Eingaben und nur englischen Dokumenten bleibt Windows.Media.Ocr eine gültige Wahl. Für jedes Projekt mit breiteren Anforderungen können die Kosten für den Aufbau rund um die Einschränkungen von Windows.Media.Ocr die IronOCR-Lizenzkosten in Entwicklerstunden übersteigen, bevor das Projekt seine erste Produktionsbereitstellung erreicht.

Der praktische Test ist einfach: Wenn das Zielsystem jemals Linux, Dockeroder eine Cloud-Funktion sein könnte und wenn die Eingabedokumente jemals PDFs sein oder in Sprachen jenseits des Standard-Betriebssystempakets vorliegen könnten, ist Windows.Media.Ocr die falsche Grundlage. Die Erkenntnis, dass dies erst mitten im Projekt geschieht, ist wesentlich teurer als die Wahl des richtigen Werkzeugs zu Beginn. Die effizienteste Methode, um diese Entscheidung zu treffen, besteht darin, den Funktionsumfang von IronOCR anhand Ihrer spezifischen Anforderungen zu bewerten, bevor Sie sich für eine der beiden Richtungen entscheiden.

Hinweis:Tesseract und Windows Media OCR sind eingetragene Marken ihrer jeweiligen Eigentümer. Diese Website ist nicht mit Google oder Microsoft verbunden, nicht gesponsert oder unterstützt. Alle Produktnamen, Logos und Marken sind Eigentum ihrer jeweiligen Eigentümer. Vergleiche dienen nur zu Informationszwecken und spiegeln öffentlich zugängliche Informationen zum Zeitpunkt des Schreibens wider.

Häufig gestellte Fragen

Was ist Windows.Media.Ocr?

Windows.Media.Ocr ist eine OCR-Lösung, die von Entwicklern und Unternehmen verwendet wird, um Text aus Bildern und Dokumenten zu extrahieren. Sie ist eine von mehreren OCR-Optionen, die neben IronOCR for .NET Application Development evaluiert wurden.

Wie ist IronOCR im Vergleich zu Windows.Media.Ocr for .NET-Entwicklern?

IronOCR ist eine NuGet-native OCR-Bibliothek für .NET, die IronTesseract als Kern-Engine verwendet. Im Vergleich zu Windows.Media.Ocr bietet sie eine einfachere Bereitstellung (keine SDK-Installationsprogramme), Pauschalpreise und eine saubere C#-API ohne COM-Interop oder Cloud-Abhängigkeiten.

Ist IronOCR einfacher einzurichten als Windows.Media.Ocr?

IronOCR wird über ein einziges NuGet-Paket installiert. Es gibt keine SDK-Installationsprogramme, keine Lizenzdateien, die kopiert werden müssen, keine COM-Komponenten, die registriert werden müssen, und keine separaten Laufzeit-Binärdateien, die verwaltet werden müssen. Die gesamte OCR-Engine ist in diesem Paket enthalten.

Welche Genauigkeitsunterschiede bestehen zwischen Windows.Media.Ocr und IronOCR?

IronOCR erreicht eine hohe Erkennungsgenauigkeit für Standardgeschäftsdokumente, Rechnungen, Quittungen und gescannte Formulare. Bei stark degradierten Dokumenten oder ungewöhnlichen Skripten variiert die Genauigkeit je nach Qualität der Quelle. IronOCR enthält Bildvorverarbeitungsfilter zur Verbesserung der Erkennung bei Eingaben von geringer Qualität.

Unterstützt IronOCR die PDF-Textextraktion?

Ja, IronOCR extrahiert Text sowohl aus nativen PDF-Dateien als auch aus gescannten PDF-Bildern in einem einzigen Aufruf. Es unterstützt auch mehrseitige TIFF-Dateien, Bilder und Streams. Bei gescannten PDFs wird die OCR seitenweise mit seitenweisen Ergebnisobjekten angewendet.

Wie sieht die Lizenzierung von Windows.Media.Ocr im Vergleich zu IronOcr aus?

IronOCR verwendet eine unbefristete Pauschallizenz, bei der keine Gebühren pro Seite oder pro Scan anfallen. Unternehmen, die große Dokumentenmengen verarbeiten, zahlen unabhängig vom Volumen die gleichen Lizenzkosten. Einzelheiten und Volumenpreise finden Sie auf der IronOCR-Lizenzierungsseite.

Welche Sprachen unterstützt IronOCR?

IronOCR unterstützt 127 Sprachen über separate NuGet-Sprachpakete. Das Hinzufügen einer Sprache erfordert einen einzigen Befehl 'dotnet add package IronOcr.Languages.{Language}'. Es ist keine manuelle Dateiablage oder Pfadkonfiguration erforderlich.

Wie installiere ich IronOCR in einem .NET -Projekt?

Installation über NuGet: 'Install-Package IronOcr' in der Paketmanager-Konsole oder 'dotnet add package IronOcr' in der CLI. Zusätzliche Sprachpakete werden auf die gleiche Weise installiert. Es ist kein natives SDK-Installationsprogramm erforderlich.

Ist IronOCR im Gegensatz zu Windows.Media.Ocr für Docker und containerisierte Bereitstellungen geeignet?

Ja, IronOCR funktioniert in Docker-Containern über sein NuGet-Paket. Der Lizenzschlüssel wird über eine Umgebungsvariable festgelegt. Für die OCR-Engine selbst sind keine Lizenzdateien, SDK-Pfade oder Volume-Mounts erforderlich.

Kann ich IronOCR im Vergleich zu Windows.Media.Ocr vor dem Kauf ausprobieren?

Ja. Der IronOCR-Testmodus verarbeitet Dokumente und liefert OCR-Ergebnisse mit einem Wasserzeichen als Overlay auf der Ausgabe. Sie können die Genauigkeit an Ihren eigenen Dokumenten überprüfen, bevor Sie eine Lizenz erwerben.

Unterstützt IronOCR neben der Textextraktion auch das Lesen von Barcodes?

IronOCR konzentriert sich auf die Textextraktion und OCR. Für das Lesen von Barcodes bietet Iron Software IronBarcode als Begleitbibliothek an. Beide sind einzeln oder als Teil des Iron Suite-Pakets erhältlich.

Ist es einfach, von Windows.Media.Ocr zu IronOcr zu migrieren?

Die Migration von Windows.Media.Ocr zu IronOCR umfasst in der Regel das Ersetzen von Initialisierungssequenzen durch IronTesseract-Instanziierung, das Entfernen des COM-Lifecycle-Managements und die Aktualisierung von API-Aufrufen. Die meisten Migrationen reduzieren die Komplexität des Codes erheblich.

Kannaopat Udonpant
Software Ingenieur
Bevor er Software-Ingenieur wurde, absolvierte Kannapat ein PhD in Umweltressourcen an der Hokkaido University in Japan. Während seines Studiums wurde Kannapat auch Mitglied des Vehicle Robotics Laboratory, das Teil der Fakultät für Bioproduktionstechnik ist. Im Jahr 2022 nutzte er seine C#-Kenntnisse, um dem Engineering-Team von Iron Software ...
Weiterlesen

Iron-Support-Team

Wir sind 24 Stunden am Tag, 5 Tage die Woche online.
Chat
E-Mail
Rufen Sie mich an