ours (row-major) dict | naive top-to-bottom dict | column-major dict | kraken dict | tesseract dict | htrflow (their own) dict | PP-StructureV3 (plain OCR) dict | PP-StructureV3 (table-rec) dict | Table Transformer (TATR) dict |
|---|---|---|---|---|---|---|---|---|
{
"tau": 0.688,
"detF": 1,
"cov": 1,
"valid": 198,
"n": 198
} | {
"tau": 0.664,
"detF": 1,
"cov": 1,
"valid": 198,
"n": 198
} | {
"tau": 0.208,
"detF": 1,
"cov": 1,
"valid": 198,
"n": 198
} | {
"tau": null,
"detF": 0.128,
"cov": 0.095,
"valid": 0,
"n": 198
} | {
"tau": null,
"detF": 0.03,
"cov": 0.019,
"valid": 0,
"n": 198
} | {
"tau": null,
"detF": 0.012,
"cov": 0.006,
"valid": 0,
"n": 198
} | {
"tau": 0.878,
"detF": 0.337,
"cov": 0.339,
"valid": 165,
"n": 195,
"ours_same_subset": 0.854
} | {
"tau": 0.639,
"detF": null,
"cov": "GT-lines",
"valid": 127,
"n": 127
} | {
"tau": 0.677,
"detF": null,
"cov": "GT-lines",
"valid": 198,
"n": 198
} |
Reading order in historical documents
A small, reproducible study of one question: on a historical page with more than one column, the hard part is usually not finding the text lines, but deciding the order to read them in, and that order is what a text recogniser is ultimately given.
- Live results (every page browsable, side by side): https://valhtrdata01.z1.web.core.windows.net/
- Code and data: https://github.com/AbhiPandit1/historical-table-reading-order
What is measured
For each page and system: detection (did it find the lines? F and coverage at IoU ≥ 0.5) and reading order (Kendall τ between the system's order and the ground-truth document order, on matched lines). A validity guard reports τ only where a system matched at least 15 lines and 30% of the page.
Data
- Court hands (columns): Göta hovrätt and Trolldomskommissionen, from Riksarkivet's own open datasets.
- Handwritten tables: HisClima (log of the USS Jeannette Arctic expedition, 1879-1881, CC-BY-4.0), 198 pages with row/column cell ground truth.
Results on the tables (198 pages)
| System | Reading-order τ | Detection F / coverage | Pages scored |
|---|---|---|---|
| PP-StructureV3 (plain OCR) | 0.88 | 0.34 / 34% | 165 |
| A small row-by-row step | 0.69 | full coverage | 198 |
| Table Transformer (Microsoft) | 0.68 | given the lines | 198 |
| Naive top-to-bottom | 0.66 | full coverage | 198 |
| PP-StructureV3 (table recognition) | 0.64 | given the lines | 127 |
| Column-major (wrong mode) | 0.21 | full coverage | 198 |
| kraken | few lines found | 0.13 / 9% | 0 |
| Tesseract | few lines found | 0.03 / 2% | 0 |
| htrflow | few lines found | 0.01 / 0.6% | 0 |
A few honest observations:
- On these dense handwritten tables, most detectors find very few of the lines. Detection, not ordering, is the harder problem there.
- PP-Structure's plain-OCR order shows the highest τ, but only over the 34% of lines it finds. On those same lines the simple step scores 0.85, about level. It reflects coverage, not a better order.
- Among methods that order every line, the simple step is level with Microsoft's Table Transformer and a little above the others. They all reach the same ceiling (τ ≈ 0.68), because about 86% of neighbouring rows overlap vertically on these wide handwritten pages. That is a shared open problem, not a weakness of one method.
On the two-column court hands detection is easy for everyone and only the order differs: htrflow's out-of-the-box pipeline reads across the columns on about half the pages, while reading down each column first matches the ground truth.
Author
Abhishek Jha. MIT licensed. Comments and collaboration welcome.
- Downloads last month
- 30