Lakir: Hindko OCR

Every line deserves to be read.

Hindko is spoken by millions of people, and almost none of it exists as digital text. Its stories, poetry and news live on paper, in books and newspapers that no computer can search or learn from.

Lakir began with a different goal: a language model that could speak Hindko. The archive shared by the Gandhara Hindko Board held about 5 million tokens of digital text, far too little to train one. The rest of the language was in print, and typing it out by hand would take years. So the first thing to build was a reader.

Lakir (لکیر, "line") reads printed Hindko one line at a time. On a sealed test of 13,026 newspaper lines it had never seen, it gets 99.5% of characters right (0.513%8 character error), 13× fewer mistakes than the model it started from. It has 15.9 million parameters, and it was trained without a single hand-labelled line.

At a glance

OCR for printed Hindko: Perso-Arabic script in the Noori Nastaliq typeface; Northern Hindko (hno) and Southern Hindko (hnd, which includes Peshawari). Built by Muhammad Uzair. Technical name: HindkoPrint-OCR v1.

To our knowledge, this is the first OCR model built for printed Hindko. On 1,000 held-out newspaper lines it has a character error rate (CER) of 0.477%2: 13.0× fewer character errors than the best of the 28 existing OCR systems and vision-language models we ran on the same lines (Surya OCR 2, 6.22%3). Surya OCR 2 is itself a vision-language model; the other 17 vision-language models, run off the shelf, scored between 19.27%4 and 129.1%5 CER.

The model is a 15.9M-parameter1 CTC line recogniser for Kraken 7.1, fine-tuned from Kraken's PP-OCRv6 medium model on 62,3296 line images of the Weekly Hindkowan newspaper whose labels are the publisher's own typeset text. It reads one line image at a time and runs on CPU or GPU.

Results at a glance

Comparison with existing systems

Every system read the same 1,000 frozen dev lines and was scored by the same scorer. The existing systems ran off the shelf, with no Hindko training. The axis is logarithmic because the CERs span more than two orders of magnitude; some systems exceed 100% because they insert text. The full ranking with kinds, licences, no-space CER and Hindko-letter recall is in comparison_table.md (vector chart: comparison_dev1000.svg).

Results

Line-level accuracy

Headline CER, lower is better; every row is scored by the same scorer on line crops. Full dev: 95% page-cluster bootstrap CIs. Where each number comes from: the CTC models' dev-1000 CER from their trainer's evaluation (rec/ctc/evaluate.py, the jobs/eval_lines.py computation at batch 1) and their full-dev CER from the G3 evaluation (jobs/eval_lines.py); the base model's rows from G3; B3 from its own VLM evaluation; E1 from the line-by-line combination of the A3 and B3 readings (jobs/e1_combine.py); the best existing system from jobs/baselines.py.

• The dev-1000 list was used to pick checkpoints and recipes, so dev-1000 numbers are slightly optimistic. The full-dev numbers come mostly from the 15,381 dev lines outside dev-1000, which played no part in that selection; the sealed test is untouched.
• E1 combines the A3 CTC reading and the B3 VLM reading line by line; its single bonus parameter (b = +0.1037) was tuned on the dev lines outside dev-1000, so its full-dev number includes the tuning lines. E1 and B3 are research results and are not part of this release.
• The base model scores 6.30%38 on dev-1000 through the baseline harness (the chart) and 6.29%31 through our reader (this table): the two read paths differ slightly; the scorer is the same.
• This model was trained on the dev lines outside dev-1000, so it has no held-out full-dev number; dev-1000 and the sealed test stay held out.

Sealed test

Scored once by jobs/test_once.py (experiment T1) after the models were frozen; the ledger results/test_once/ledger.jsonl records the single opening. Claims use the upper end of each CI.

How to use

The weights are a Kraken 7.1 recognition model (safetensors). Lines are read whole, right to left, and returned in logical order (NFC).

pip install "kraken>=7.1.1" huggingface_hub

Whole pages (command line)

With the HindkoPrint-OCR code (not public yet; until it is, use the "One line with Kraken only" path below, which needs only these weights), from the repository root (on Windows set PYTHONUTF8=1):

hf download uzair0/lakir-hindko-ocr lakir_hindko_ocr.safetensors --local-dir .
python demo/hindko_ocr.py page.jpg issue.pdf --out out/ --model lakir_hindko_ocr.safetensors --overlay

All options:

python demo/hindko_ocr.py PAGE.jpg [MORE.jpg|.pdf ...] --out out/ [--mode fast|max] [--model SPEC]
[--formats txt,jsonl,pagexml] [--overlay] [--scale-norm] [--device auto|cpu|cuda:0]

Per page it writes <page>.txt (one line per printed line, in reading order), <page>.jsonl (text, polygon, baseline, confidence, needs_review per line), PAGE-XML and, with --overlay, a picture of the segmentation. --mode max (the CTC + VLM combination) needs the VLM adapter, which is not part of this release.

Python

from huggingface_hub import hf_hub_download
from rec.v1 import make_reader                   # HindkoPrint-OCR code on PYTHONPATH
from rec.page_ocr import load_pages, ocr_page

weights = hf_hub_download("uzair0/lakir-hindko-ocr", "lakir_hindko_ocr.safetensors")
reader = make_reader("fast", model=weights, device="cpu")
for page in load_pages("page.jpg"):              # an image, or a PDF (one entry per page)
    result = ocr_page(page["bgr"], reader, page["page_id"])
    for line in result["lines"]:                 # reading order: regions, blocks right to left, lines
        print(line["text"], line["confidence"], line["needs_review"])

One line with Kraken only

A line image must be cut the way the training crops were (the line's bounding box plus 6 px, other lines' ink whited out); rec/page_ocr.py does this for whole pages.

import unicodedata
from huggingface_hub import hf_hub_download
from PIL import Image
from kraken.configs import RecognitionInferenceConfig
from kraken.containers import BBoxLine, Segmentation
from kraken.tasks import RecognitionTaskModel

model = RecognitionTaskModel.load_model(hf_hub_download("uzair0/lakir-hindko-ocr", "lakir_hindko_ocr.safetensors"))
im = Image.open("line.png").convert("RGB")
seg = Segmentation(type="bbox", imagename="line", text_direction="horizontal-rl", script_detection=False,
                   lines=[BBoxLine(id="l0", bbox=(0, 0, im.width, im.height), base_dir="R")])
cfg = RecognitionInferenceConfig(num_line_workers=0, batch_size=1)
record = next(iter(model.predict(im, seg, cfg))).logical_order()
print(unicodedata.normalize("NFC", record.prediction))

This is the reading path the evaluation used (rec/v1.read_images, the same as jobs/eval_lines.py).

Model details

• Architecture. Kraken's PP-OCRv6 medium line recogniser (PaddlePaddle's PP-OCRv6 design, adapted for Kraken by the base model's author): a convolutional backbone and a non-recurrent sequence-modelling neck with a CTC head; 15,857,5271 parameters; input lines scaled to 96 px54 height.
• Output classes. 1,62855: the 1,62356 of the base model's codec plus 557 added for the Hindko tone letters (U+08BE, U+08BF, U+08C0, U+08C1, U+08C2, Arabic letters with small v).
• Base model. PP-OCRv6 (medium) multilingual handwritten and printed text recognition model by Benjamin Kiessling, licence Apache-2.058.
• Fine-tuning. Our own trainer (rec/ctc): CTC loss only, BatchNorm statistics frozen, AdamW with learning rates per part (backbone 1e-4, neck 1e-3, head 1e-3, new rows 1e-3), 500 warmup steps then cosine decay to 0.05 of the peak, weight decay 0.01, gradient clipping 1.0, bf16 autocast, batch 32, 16 epochs (32,41660 steps), seed 1234; augmentation with probability 0.5 per line (blur, jpeg, contrast, brightness, stretch).61
• Run. 2.1 h59 on one NVIDIA RTX PRO 6000 Blackwell Server Edition with kraken 7.1.1 and torch 2.11.0+cu130; code 391d369cb4, config sha256 010c2779d7f0. Reloaded from the exported file, the weights give the same dev-1000 CER as in training (export round trip: match).

Training data

• 62,3296 line images (62,35262 exported; dropped: 23 too wide) from the 11063 training issues of Weekly Hindkowan in the frozen split (e18b325d) and the dev lines outside dev-1000 (dev-1000 and the sealed test stay held out). No synthetic lines.
• Labels are the publisher's own typeset text: the InPage files of each issue, decoded by our in-house InPage decoder and aligned to the printed lines (a zero-shot Kraken reading of each line is matched against the text of its issue). No OCR output and no output of any other model is used as a label.
• Leakage guard. The trainer checked all 53,14464 training lines against the split: 0 from held-out issues, 0 overlapping the evaluation lists.

Evaluation protocol

• Splits. Whole issues are assigned to train, dev, test and degraded test once and frozen (split e18b325d): 11063 / 2665 / 2266 / 467 issues. The test and degraded-test issues are sealed: every loader refuses them, and they are scored once (jobs/sealed.py, jobs/test_once.py).
• dev-1000 is a frozen list of 1,000 dev lines (sha256 bd9c8f35f41af9cd…, 4068 pages); full dev is every labelled dev line: 16,38169 lines on 9870 pages.
• Scorer. eval.metrics headline CER: total edit distance divided by total reference characters (micro-averaged) after NFC, the Hindko normaliser (hp.normalize v1.0.1), kashida removal, single spaces and a print-equivalence fold of code points that print identically (LABEL_SPEC §2, §5). No-space CER also removes spaces, separating letter errors from word-spacing errors.
• Confidence intervals. Page-cluster bootstrap: pages are resampled, not lines (10,00071 resamples, seed 0, 95% percentile intervals).
• Existing systems ran off the shelf on the same lines (jobs/baselines.py; the table names each system's version and prompt or backend) and were scored by the same scorer. Left out: Qwen3.8-27B (run failed).

Limitations

• Clean print only. Every number here is measured on clean, born-digital newspaper print from 2023–202672 (Weekly Hindkowan, Noori Nastaliq). One publisher and one typeface family.
• The evaluation lines skew easy. Dev and test lines exist only where the round-0 aligner, using the zero-shot reader, matched a printed line to the publisher's text: 16,38173 of 34,48374 segmented lines on 10575 dev pages (47.5%76). Lines that reader could not handle are under-represented, so these CERs understate the error on all printed text.
• Some label noise, mostly spacing. On full dev, 21%77 of the B3 VLM's remaining errors are on lines where it and the A3 CTC model give the same reading and both differ from the label (84478 lines, 63379 of them differing only in spacing): probably label noise, which inflates the measured CER a little. No label was changed.
• Whole pages are harder than lines. End to end (segmentation, crops, reading) on 2012 dev pages the CER is 0.540%10 against 0.538%80 for the same lines read from the stored crops; finding the lines is the main source of the difference.
• Rare letters are untested. The 5 small-v tone letters (U+08BE–U+08C2) have output classes, but they occur only 1481 times in the training labels and are not counted separately in dev-1000.
• Not tested. Phone photos, scans, other presses and typefaces, books, and handwriting. Commercial OCR services and proprietary multimodal APIs (for example GPT, Gemini or Google Vision) were never benchmarked, so no claim is made about them.
• Confidence flags are uncalibrated. The per-line needs_review thresholds of the page tool are placeholders until a calibration run sets them.

Acknowledgements

Lakir was trained on pages of the weekly newspaper Weekly Hindkowan, shared with permission by the Gandhara Hindko Board. Thank you to the Board for opening their archive.

Attribution and licences

• InPage decoder. The InPage decoder was developed for this project. It builds on the open-source glyph table of salmanasmat/InPageToUnicode (GPL-3.0, which ports ltrc/inPageToUnicode and umer0586's converter). The glyph table is not part of these weights or of this repository; code that bundles it is GPL-3.0.
• Base model. Kraken PP-OCRv6 medium by Benjamin Kiessling (https://doi.org/10.5281/zenodo.21788410), Apache-2.058. Kraken itself is Apache-2.0.
• VLM experiments (not in these weights). B3 and E1 fine-tune Qwen/Qwen3.5-9B (Apache-2.082) with LoRA through Unsloth (unsloth/Qwen3.5-9B).
• This model card and the weights. CC BY-NC 4.0: free for research and non-commercial use with attribution.

Citation

@misc{uzair2026hindkoprint,
  title        = {Lakir (HindkoPrint-OCR): OCR for Printed Hindko},
  author       = {Muhammad Uzair},
  year         = {2026},
  howpublished = {\url{https://huggingface.co/uzair0/lakir-hindko-ocr}}
}

Contact

Muhammad Uzair. Questions, error reports and permission requests: open a discussion on this repository.

Sources

Every number above is read from the project's results dataset when this card is generated (release/hf/make_model_card.py, 2026-10-02, from the private results dataset); the superscripts point here.