Jak OCR czyta zeskanowany PDF i dlaczego to narzędzie zwraca Markdown

Zeskanowany PDF przechowuje strony jako obrazy rastrowe, czyli zdjęcia tekstu, a nie zaznaczalne znaki. OCR (optyczne rozpoznawanie znaków) patrzy na te piksele, zgaduje, które kształty są literami, i zwraca prawdziwy tekst. W PDF123 działa to jako darmowe narzędzie w przeglądarce oraz jako POST /api/v1/misc/ocr-pdf; odpowiedzią jest Markdown, a nie przepisany PDF.

Skan pozostaje obrazem

OCR nie czyści, nie wyostrza ani nie zastępuje bitmapy. Ostry skan, który OCR odczyta błędnie, nadal wygląda ostro. Wąskim gardłem nigdy nie była jakość obrazu, lecz rozpoznawanie: zmień silnik rozpoznawania na tej samej partii skanów, a dokładność może się mocno zmienić, choć same piksele pozostają nietknięte.

Klasyczny OCR w PDF zapisuje drugą, niewidoczną warstwę tekstu wyrównaną pod obrazem, aby zaznaczanie i wyszukiwanie trafiało we właściwe słowa. Pokazuje to schemat i tak nadal działa wiele narzędzi desktopowych.

Co faktycznie zwraca ten punkt końcowy

Ścieżka OCR wywołuje /api/v1/misc/ocr-pdf, która działa na samodzielnym crate’cie Rust, pdf-inspector (zbudowanym z jego funkcją ocr). Nie oddaje całego PDF-a modelowi rozpoznawania. pdf-inspector najpierw klasyfikuje każdą stronę jako mającą już tekst natywny do wyodrębnienia albo jako samo zdjęcie. Strony z tekstem natywnym zachowują ten tekst bez zmian i nigdy nie trafiają do modelu rozpoznawania; strony będące samym obrazem przechodzą zamiast tego przez potok rozpoznawania — PDFium (ten sam otwartoźródłowy renderer, którego Chrome używa wewnętrznie) rasteryzuje stronę, a ONNX Runtime uruchamia model PP-OCRv6 Small, aby ją odczytać. Oba rodzaje stron są zszywane po kolei w jeden dokument Markdown, dlatego odpowiedź ma typ text/markdown, a pobierany plik kończy się na .md.

Ten kontrakt jest nowy w tym przepisaniu. Projekt działał wcześniej na backendzie Java/Spring Boot, który wywoływał OCRmyPDF — klasyczne podejście „obraz plus ukryta warstwa tekstu” — i zwracał PDF. Przepisanie na Rust zastąpiło tę ścieżkę w całości selektywnym OCR-em z pdf-inspector, a wraz z tym wyjście zmieniło się z PDF-a na Markdown. Stary backend w Javie został od tamtej pory całkowicie usunięty z repozytorium; to nie jest przełącznik, który można cofnąć.

Jeśli potrzebujesz przeszukiwalnego PDF (obraz plus warstwa tekstu), ten punkt końcowy ci go nie da. Daje tekst, który agent lub potok danych może wykorzystać bezpośrednio.

Auto kontra Force OCR

Formularz ma pole ocrType:

• Normal (wszystko inne niż force-ocr) odpowiada trybowi Auto: używa istniejącego tekstu tam, gdzie plik już go ma, a OCR uruchamia tylko na stronach z samymi obrazami. W czystym pliku cyfrowym Auto nie wczytuje środowiska OCR.
• Force OCR (ocrType=force-ocr) uruchamia rozpoznawanie na każdej stronie, także na tej, która ma już warstwę tekstu. Na stronach rzeczywiście zawierających tylko obraz płacisz czasem, a nie dodatkową dokładnością; dostajesz przebieg, który ignoruje uszkodzoną lub niepełną istniejącą warstwę.

Domyślnie portal wybiera Force OCR. Nie ma ustawienia języka: pozostałe kody tessdata ze starej ścieżki w Javie są ignorowane.

Podział Auto/Force zachodzi wewnątrz samego żądania i ani portal, ani sonda możliwości API nie sprawdzają tego z wyprzedzeniem. GET /api/v1/settings/get-endpoints-status zawsze zgłasza ocr-pdf jako włączony, w ogóle nie weryfikując, czy PDFium, ONNX Runtime i model PP-OCRv6 są zainstalowane. Rzeczywista weryfikacja następuje dopiero w chwili, gdy żądanie uruchamia rozpoznawanie: jeśli czegoś z tego brakuje, punkt końcowy zwraca 503, a nie zdegradowany Markdown, który po cichu spada do samego tekstu natywnego. Sam model PP-OCRv6 Small waży około 31 MB; jeśli nie został wcześniej wgrany do lokalnego cache podczas wdrożenia, pobiera się z sieci przy pierwszej rzeczywistej potrzebie rozpoznania. Maszyna offline bez wcześniej wgranego modelu najprawdopodobniej zawiedzie właśnie przy pierwszym żądaniu Force, zamiast po prostu działać wolniej.

Rozpoznawanie ma charakter probabilistyczny

Silniki dopasowują wzorce pikseli do modeli liter i słów. Radzą sobie dobrze z czystym, kontrastowym drukiem standardową czcionką, a gorzej z:

• skanami o niskiej rozdzielczości lub niskim kontraście (jakość faksu kontra oryginał 300 DPI),
• pismem ręcznym, czcionkami ozdobnymi, nietypowymi układami (tabele wielokolumnowe, obrócony tekst, gęste formularze),
• przekrzywionymi stronami, które zniekształcają kształty glifów na tyle, by mylić dopasowanie.

Rozmazany faks nie podda się OCR jak czysty skan, niezależnie od trybu Auto czy Force. To ograniczenie samego modelu, którego nie naprawi żaden parametr.

Czego OCR nie robi

OCR daje tekst. Nie odtwarza akapitów, nagłówków, tabel ani dokumentu Word do swobodnej edycji. Edytowalny układ to problem konwersji nakładający się na błąd rozpoznawania, a nie to samo zadanie co odczytanie skanu.

OCR PDF działa po stronie serwera i nie wymaga konta. Pobierasz Markdown. Jeśli istniejąca warstwa tekstu wygląda źle, użyj Force OCR, aby Auto jej nie ufało; a żeby sprawdzić, czy dana maszyna faktycznie ma zainstalowane PDFium i model, wysłanie prawdziwego żądania jest pewniejsze niż odczytanie sondy możliwości, bo ta potwierdza jedynie, że punkt końcowy istnieje, a nie że jego środowisko wykonawcze jest gotowe. Klucze do automatyzacji i OpenAPI opisuje Dla programistów.