Modern Hebrew document line recognition (printed and handwriting-style), trained from scratch on synthetic pages; recognizer of the HeOCR R4d + A1 + R3h pipeline
Year: 2026
Type: article
Abstract: HeOCR R3h: Hebrew document line recognition (kraken) R3h is a kraken text recognition model for lines of modern Hebrew documents. It reads printed and handwriting-style lines, including digits, Latin letters and typographic punctuation. HeOCR trained it from scratch on synthetic pages only. R3h is the recognition step of HeOCR's three-model pipeline: - R4d finds the lines (segmentation); - A1 puts them in reading order; - R3h reads them. The three are released together, as separate records that link to each other (see The pipeline). It is a research baseline, not a production transcriber. All of its evaluation is on synthetic pages; no reviewed evaluation on real scans exists yet. File heocr-r3h-recognition.safetensors (trained as best_0.9959.safetensors), 16,167,536 bytes sha256 f76affa84e29536aa1d41f89d3507183c104f1620ca953fdfa5dd4b7a00ba6be Model type recognition (line-level, CTC) Format kraken safetensors; trained and tested with kraken / ketos 7.0.2 Licence Apache-2.0, Copyright (c) 2026 HeOCR maintainers (see LICENSE and NOTICE) Training record r3h_training_run.json (heocr_engine_training_run.v1) Code HeOCR/heocr-engine The pipeline Step Model Record Segmentation: baselines, line polygons, typed regions R4d, heocr-r4d-segmentation.safetensors (d32cd1a8…) 10.5281/zenodo.24023070 Reading order: line order from each line's region type A1, heocr-a1-reading-order.safetensors (69aa1946…) 10.5281/zenodo.24023072 Recognition R3h, this model 10.5281/zenodo.24023074 A1 needs heocr-engine. kraken 7.0.2 cannot run A1 by itself, for two reasons: - its neural reading order passes the segmenter's line types to A1, while A1 was trained on region types. kraken rejects the class-mapping mismatch; - its text output ignores a learned line order (mittagessen/kraken#820). Run the whole pipeline from a heocr-engine checkout (pip install '.[kraken]'): sh heocr-engine kraken --api python --segmentation-model heocr-r4d-segmentation.safetensors --reading-order-model heocr-a1-reading-order.safetensors --reading-order-classes region --recognition-model heocr-r3h-recognition.safetensors page.jpg page.json Architecture R3h uses ketos 7.0.2's default recognition network, unchanged: [1,120,0,1 Cr3,13,32 Do0.1,2 Mp2,2 Cr3,13,32 Do0.1,2 Mp2,2 Cr3,9,64 Do0.1,2 Mp2,2 Cr3,9,64 Do0.1,2 S1(1x0)1,3 Lbx200 Do0.1,2 Lbx200 Do0.1,2 Lbx200 Do] Input lines are scaled to a height of 120 pixels, in greyscale. The model expects baseline segmentation (seg_type: baselines). Codec (117 symbols): - the 27 Hebrew letters, final forms included, with geresh ׳ and gershayim ״; - the digits 0–9 and the Latin letters A–Z a–z; - space and ASCII punctuation: ! " % & ' ( ) + , - . / : ; ? @; - typographic punctuation: – — ' ' " " " …; - the shekel sign ₪. There is no niqqud (vowel points) and no cantillation. Uses Line recognition for modern Hebrew documents: letters, notes, archive cards, ledgers, forms and notices, in print or handwriting-style fonts. It is best used in the R4d + A1 pipeline. A research baseline for Hebrew OCR: comparing segmenters, line geometries and later HeOCR models. Out of scope Unsupervised transcription of real documents. No reviewed real-page evaluation exists, and the scores below are on synthetic pages only. Medieval, liturgical or other historical Hebrew scripts. Niqqud, which is not in the codec. Real handwriting. "Handwriting-style" means one handwriting font, not human hands. Documents that are not mainly Hebrew. Transcription guidelines, normalization and transformations Ground truth is Unicode NFC text in logical order. Training reorders it to display order, kraken's convention, with a right-to-left base direction. At inference, run kraken with --reorder --base-dir R to get logical-order text back. Without it, the output is in display order. Punctuation: quotes, dashes and ellipses are typographic where the text used them. Gershayim ״ and geresh ׳ are distinct from ASCII " and '. Digits and Latin words keep their left-to-right order inside the logical-order line. How to get started with the model The full pipeline (R4d + A1 + R3h). This is the configuration the headline figures below come from. A1's order is applied by heocr-engine's in-process kraken stage. In a checkout of heocr-engine, run pip install '.[kraken]', then: heocr-engine kraken --api python \ --segmentation-model heocr-r4d-segmentation.safetensors \ --reading-order-model heocr-a1-reading-order.safetensors --reading-order-classes region \ --recognition-model heocr-r3h-recognition.safetensors \ page.jpg page.json page.json is a prediction record. Its text holds the page in logical order, one line per row. Tested end to end with kraken 7.0.2 on CPU (about 8 s for one seed-101 page). The text matched the scored prediction for that page exactly. kraken alone. Kraken 7.0.2 cannot use A1: - A1's classes are region types, and kraken's own pipeline gives it the segmenter's line types instead, so kraken rejects the pair. - kraken's text output also ignores a learned line order (mittagessen/kraken#820). With kraken alone, R4d + R3h runs in kraken's heuristic line order. No figure is reported here for that configuration. kraken -i page.jpg page.txt segment -bl -d horizontal-rl -i heocr-r4d-segmentation.safetensors \ ocr -m heocr-r3h-recognition.safetensors --reorder --base-dir R -d horizontal-rl reads lines that share a row right to left. --reorder --base-dir R returns logical-order text. With segment -bl and no -i, kraken uses its default blla segmenter instead (see below). kraken 7.0.2 sometimes aborts on exit ("recursive_mutex lock failed") after writing its output. Retrying works. Training details Training data All synthetic. Nothing was scraped, and no real document or third-party text was used. Pages: 3,000 pages from hocrsyngen at 88ba5e6, seed 7201, over seven templates: archive card, faded archive card, handwritten note, worn handwritten note, ledger, printed letter and heavily scanned printed letter. The split is 2,850 training pages (47,633 lines) and 150 validation pages (2,706 lines). It is assigned per page by hash. Fonts: Alef (2,143 pages) and Gveret Levin (857 pages), both SIL OFL 1.1. Credits are in NOTICE. Text: The hocrsyngen corpora S10b, S13a and S13b (932,130 bytes; sha256 7c2a62b8…). They are original text authored by AI agents (Claude Opus 5.5 sessions) for HeOCR, with no third-party text, and dedicated to the public domain under CC0 1.0. The register is administrative letters, notes, archives, ledgers, forms and notices; procurement and technical text with Latin terms, digits and codes; and typeset prose with typographic punctuation. Line geometry: Each line is cropped in one of three ways, chosen by hash: 3/4 with kraken's polygonizer around the true baseline; 1/8 with the generator's exact line polygon; 1/8 with the polygon's bounding box, its height adjusted by a pad of −0.14 to approximate Tesseract line boxes. The mix is meant to cover the line geometry of different segmenters. Training procedure and hyperparameters Initialisation: from scratch. No third-party weights were loaded. Trainer: ketos 7.0.2 through heocr-engine train-kraken (heocr-engine 55b0f7d). Optimiser and data: AdamW, learning rate 0.001, constant schedule; batch size 16, padding 16, augmentation on. Stopping: early stopping with lag 3 (minimum 5 epochs). It stopped after 8 epochs; the best was epoch 4. Validation: character accuracy 0.9959, on its own validation split with the same geometry mix. Run: seed 42, on Apple mps. Not deterministic, and the bytes are not reproducible. Evaluation Testing data, factors and metrics Testing data Batches: hocrsyngen batches rendered from evaluation corpora that are kept apart from the training text, with the same two fonts. None was trained or tuned on. seed-101 (the long-running benchmark); held-out; eval-mixed-heldout (mixed Hebrew/Latin/digits); eval-typo-heldout (typographic punctuation); eval-layout-heldout (archive cards and ledgers, plus the four benchmark templates). hocrgen fixture: hocrgen's fixture batch, a development set. A1's reading order was tuned on it. Gold: all gold is synthetic. Metrics The metric is CER under hocrgen's primary.v1 normalisation profile, pooled over the pages of each batch. The pipeline: R4d + A1 + R3h (the released models; headline figures): Batch CER seed-101 0.020 held-out 0.010 eval-mixed-heldout 0.017 eval-typo-heldout 0.009 (269 of 308 typographic marks kept) eval-layout-heldout 0.124 (mostly the ledger gold convention; see below) hocrgen fixture (development set) 0.130 kraken's default segmenter: blla + R3h (segment -bl -d horizontal-rl, then ocr --reorder --base-dir R, kraken 7.0.2): Batch CER seed-101 0.168 held-out 0.238 eval-mixed-heldout 0.230 eval-typo-heldout 0.291 eval-layout-heldout 0.498 hocrgen fixture (development set) 0.404 The blla rows are much worse because of blla's segmentation, not the recognizer. On these layouts it splits and merges lines, and it reads them out of order. Use R4d and A1 for HeOCR's figures. Given lines (a diagnostic, not a pipeline: the recognizer alone, on lines it is handed): Batch true line polygons Tesseract line boxes seed-101 0.014 0.116 held-out 0.004 0.088 This is one training run. The paired intervals in heocr-engine's docs/baselines.md (R3h section) resample pages, not training runs. A second training seed of an earlier model moved eval-mixed-heldout by about 0.005. Bias, risks and limitations The synthetic gap. The evaluation pages use the same two fonts and the same kinds of degradation as training. These scores overstate accuracy on real scans, possibly by a wide margin. Ledgers on eval-layout-heldout: Most of that batch's error, 2,432 of 2,611 edits, is on ledger pages. Most of that is a gold convention, not misreading.
Authors: Palachy Affek, Shay, HeOCR maintainers
Language: English
Subfield: Computer Vision and Pattern Recognition
Field: Computer Science
Domain: Physical Sciences
Open Access status: green
OpenAlex ID: W7225377301