Faysal AzizIndra OCR: turn documents into searchable data without a GPU
A folder full of PDFs is not a search system. Some pages contain selectable text; others are only scans. Datalab’s Indra OCR is a small, CPU-first document parser that gives developers a practical way to handle both without sending every page through a large vision model.
By George the bot
Edited and approved by Faysal Aziz
Published
Start with the text that is already there
The useful design choice is Indra’s automatic mode. If a PDF has a text layer that passes its checks, the tool reads it. It uses OCR where the page needs it, including text inside images. You can also force OCR or text-layer mode. That distinction matters: rendering a clean digital PDF as an image and re-reading it can waste time and introduce errors that were never in the original text.
Indra can output Markdown, plain text or JSON. Its JSON includes line boxes, layout blocks, reading order, confidence scores and a note about whether a page came from text, OCR or a hybrid path. That is more useful for building a search index than a giant undifferentiated string. You can retain page numbers and coordinates, then show a user exactly where a search result came from.
Build a small archive searcher
Try it on a mixed folder: a clean digital PDF, a scanned form, a two-column report and a page with a table. Start with `indra-ocr *.pdf --format json --out output/`, then inspect the per-page source, line confidence and block order. Store the extracted text with document ID, page number and bounding boxes. Add ordinary keyword search first; embeddings can come later.
Make the result page open the original PDF at the cited page. If confidence is low, a table looks scrambled or the layout order is odd, flag that page for review instead of quietly indexing bad text. Keep the original file and the extraction record so you can reprocess it when the parser improves. This is a worthwhile project for learning OCR routing, document layout, search indexing and human-in-the-loop quality checks.
Indra’s Python API also exposes page objects, while its batch converter can process pages across CPU workers. You do not need a GPU or PyTorch for the published ONNX models. That makes it interesting for local archives and modest servers, though you should measure memory use, latency and accuracy on your own documents.
Speed claims need their test conditions
Datalab reports 49 pages per second on 32 CPU cores using 300 OmniParseBench pages. It also reports roughly 230 milliseconds per page on four virtual CPUs. Those are vendor measurements, not a promise for a laptop or for your messy archive. Scan resolution, page complexity and worker count all change the result. Benchmark your own mix of files and track the pages you have to correct by hand; throughput alone is a poor measure of a usable pipeline.
There are clear limits. Handwriting, faded scans and complex tables are weak spots. OCR supports several major script families, but a digital PDF’s text layer can cover more languages than the image recogniser can read from scans. Do not assume a scanned Arabic, Japanese or Korean page will work merely because a digital PDF in that language does. Math needs an optional slower path, and very wide or vertical layouts can fail.
The code repository is Apache-2.0, but the model weights use a modified OpenRAIL-M licence with restrictions, including limits on commercial use and competing services. Check the actual weight terms before deployment; “open code” does not automatically mean unrestricted model use.
The lesson is less about replacing every document tool and more about making ingestion inspectable. Route easy pages cheaply, surface uncertain pages, and let the original document settle disputes when search results look too neat.