Skip to main content

Blog

The Long Tail of OCR: Reading Headers off Scanned Logs

Reading the printed header off a scanned well log is the part of digitisation everyone calls easy, and for most of the page they are right. The trouble is that the same job is also where a surprising amount of the engineering quietly goes, because the headers do not fail on average. They fail in a long tail of rare malformed cases: faded carbon copies, sheets scanned off-square, vendor abbreviations that collide, stamps printed over the title block. This is a tour of that tail, and of why it is a separate concern from the much-debated question of whether to OCR the header at all.

Tannistha MaitiQuamer Nasimby Tannistha Maiti, Quamer Nasim13 min read
EarthScan insight

Ask a room of engineers how hard it is to read the header off a scanned well log and you will get a shrug. The header is printed text. There are mature recognizers for printed text. Point one at the title block, collect the track labels and the depth scale and the column names, move on to the genuinely hard problem of tracing the plotted curves. On most sheets that shrug is completely earned: the recognizer reads the header, the strings come back clean, and the header costs you nothing. The catch, and the reason this is worth a piece of its own, is that the header does not cost you anything on average. It costs you almost nothing on the overwhelming majority of sheets and an alarming amount on a small minority, and the engineering hours follow the minority. Reading log headers is roughly ninety percent trivial and ten percent career-ending, and a team that budgets for the ninety percent ships late.

This is a deliberately narrow topic. There is a separate, well-worn debate about whether the header is even an optical-character-recognition job or whether it should be folded into the same learned model that reads the curves, and we have written about that routing decision elsewhere; the short version is that the header is finite-vocabulary printed text and a recognizer wins it. Take that as settled here. The question this piece asks is what happens after you have decided to read the header with a recognizer, when you actually run that recognizer across a real archive and discover that the easy decision did not make the work easy. The work hid in the tail.

The shape of the problem is a cliff, not a slope

The instinct that makes header reading feel cheap is an averaging instinct. You imagine a representative sheet, picture the recognizer reading it, and quietly assume the rest of the archive looks like that one. Archives do not work that way. The distribution of header difficulty is not a gentle slope where each sheet is a little harder than the last; it is a cliff. A large, flat plateau of sheets are so clean that the recognizer reads them with no help at all, and then a short, steep drop into a set of sheets where every additional one costs more than the last.

The head of that distribution is genuinely effortless. Crisp printed units sit at the very top: a recognizer reads API, ohm.m, grams per cubic centimetre, and feet without breaking stride, because those are short tokens from a tiny closed alphabet set in clean type [1]. The depth-scale numerals are nearly as easy, a column of digits in a predictable margin. The standard measurement-column names are a touch harder only because the vocabulary is larger, and even here there is a public reference for how small that vocabulary really is: the FORCE 2020 release of Norwegian-Sea wells, widely taught through a tutorial slice of 118 wells, fixes a naming convention whose electrical-measurement channels number just 22, the gamma-ray, calliper, spontaneous-potential, the shallow, medium, and deep resistivities, the neutron and density porosities, and the rest [6]. Twenty-two tokens is not a hard recognition problem. The head of the curve is a solved problem dressed up as work.

Then the cliff. Below the clean column names sit the sheets that do not cooperate, and they do not cooperate in ways that have nothing to do with one another, which is precisely why they are expensive. There is no single fix that recovers the tail, because the tail is not one failure mode. It is a collection of unrelated ones, each rare on its own and each demanding its own engineering, and together they consume the budget that the head left untouched.

A field guide to the rare and ruinous

It is worth naming the inhabitants of the tail, because abstraction hides how different they are from each other.

The faded carbon copy. A great deal of legacy log paper is not an original. It is the third or fourth carbon impression, or a photocopy of a photocopy, and the header text has lost most of its contrast against the page. A recognizer tuned for crisp modern print sees grey on grey and either returns nothing or invents tokens out of the noise. The fix is not in the recognizer; it is upstream, in contrast normalisation and binarisation that recover legible strokes before recognition runs, and sometimes in retraining the recognizer on the degraded distribution itself so that it stops expecting clean edges [2]. Every one of those is real work for a handful of sheets.

The sheet scanned off-square. Old logs are long, awkward to handle, and frequently fed into a scanner at an angle. A header block rotated even a couple of degrees breaks the foundational assumption every line-oriented recognizer makes, which is that text sits on horizontal lines. The recognizer's line finder fragments, characters split across imagined rows, and accuracy collapses. The remedy is a deskewing step, estimating the dominant text angle and rotating the page back to square before recognition, a problem the document-image community solved decades ago with projection-profile methods but which you still have to detect, parameterise, and wire into the pipeline for the small fraction of sheets that need it [3].

The colliding abbreviation. This one is insidious because the recognizer succeeds and the system still fails. Two vendors abbreviate two different curves with the same short token, or one vendor reuses a token across tracks. The recognizer reads the glyphs perfectly and hands back a string that is correct as text and ambiguous as meaning. No amount of better recognition fixes this; it needs a disambiguation layer that knows the vendor, the era, and the track context to map a read token to the curve it actually denotes. The error has moved out of vision entirely and into domain logic, which is a different team's expertise and a different kind of cost.

The overprint. Stamps, "CONFIDENTIAL" banners, handwritten well names, and margin annotations land directly on top of the printed title block. The recognizer now faces two layers of ink occupying the same pixels, and it cannot tell the wanted text from the noise printed over it. Separating overlapping ink layers, or detecting and masking stamps before recognition, is a genuinely hard segmentation-and-layout problem in its own right, closer to the table-and-structure recovery work in heterogeneous documents than to plain text reading [4]. It is also, mercifully, rare, which is exactly what makes it easy to under-budget.

What unites these four is not a technique. It is a shape: each is uncommon, each is unrelated to the others, and each costs many times what a head-of-distribution sheet costs. That is the long tail, and it is where the header-reading engineering actually lives.

HEADER OCR IS A STEEP DISTRIBUTION: A CHEAP MAJORITY, A COSTLY TAIL76%of header items recoveredAT 11% OF THE ENGINEERING EFFORT SPENTDrag the effort budget; watch the cheap rungs clear before the tail drains itEach rung is a cohort of header items, ranked easiest to worst. Bar width is item count.Spend the budget top-down: the head clears almost free, the malformed tail eats the rest.HEADER ITEM COUNT (BAR WIDTH, ILLUSTRATIVE)Crisp printed units and ticksAPI, ohm.m, g/cc, ftrecoveredDepth-scale numeralsclean printed depth gridrecoveredStandard column names22 electrical columns, 118 NO-Sea wellsrecoveredFaded carbon-copy textlow-contrast nth-generation printtail, unfundedSkewed / rotated header blocksheet off-square on the platentail, unfundedColliding vendor abbreviationssame token, different curvetail, unfundedHandwritten and stamped overprintsmargin notes, stamps on the title blocktail, unfundedMALFORMED LONG TAILRECOVERY VERSUS EFFORTitems recovered76%effort spent11%65 points more recovered than spent: the head is cheapWHAT THE HEADER DISAMBIGUATESTrack 1 and Track 2: 3 curves each (GR/SP/CALI; shallow/medium/deep res)Track 3: 2 curves (NPHI, RHOB). 8 plotted curves the segmenter owns.a missed header item leaves a track count ambiguous for the segmenterWHERE THE BUDGET IS GOINGStill in the head: 76% of items for 11% of effort.The cheap majority clears for roughly 11% of total effort.ENGINEERING EFFORT BUDGETnoneevery cohort fundedEFFORT SPENT 11% · ITEMS RECOVERED 76%drag the orange budget on the right; arrow keys nudge it along the axisrecovered cohortdraining nowtail, unfundedThe 3+3+2 curve taxonomy (8 plotted curves) is theengagement's own; the 22 columns across 118 Norwegian-Sea wells are the public Xeek / FORCE 2020 set; counts, effort weights and recovery geometry illustrative.
A recovery ladder that walks header-extraction accuracy from the easy majority into the failure tail. Each rung is a cohort of header items, ranked easiest to worst, with bar width set by item count: crisp printed units, the clean depth-scale numerals, and the 22 standard electrical-measurement column names of the public Xeek / FORCE 2020 tutorial slice (118 Norwegian-Sea wells) sit in the cheap head; faded carbon copies, skewed sheets, colliding vendor abbreviations, and handwritten or stamped overprints sit in the malformed long tail. Drag the orange engineering-effort budget and the ladder funds cohorts top-down: the head clears for a sliver of the budget and the recovered-share meter jumps near ninety percent, while the effort meter barely moves; push into the tail and the budget drains fast for a handful of extra items. The right panel reads out the recovery-versus-effort gap and the payload at stake, since every recovered header item disambiguates the track taxonomy the segmenter must honour: Track 1 and Track 2 carry three curves each (GR/SP/CALI; shallow/medium/deep resistivity) and Track 3 carries two (NPHI, RHOB), eight plotted curves in all. The 3+3+2 taxonomy and the 22-column, 118-well figures are sourced; the per-cohort counts, effort weights, and recovery geometry are an illustrative ordering, not measured extraction rates.

The ladder above makes the economics legible. Spend a sliver of the engineering budget and the head cohorts light up almost for free; the recovered-share meter races toward ninety percent while the effort meter barely moves. Then push the budget into the tail and watch it drain fast for a handful of additional items. The recovered count and the effort count cross over: early on you recover far more than you spend, and late you spend far more than you recover. That crossover is the whole argument. It is also the number that does not survive an averaging summary, which is why "header OCR is easy" is both true and misleading in the same breath.

Why the cheap part of the page still deserves the attention

A reasonable objection is that the curves are the hard problem, so why spend a piece on the header at all. The answer is that a missed header item is not a cosmetic loss; it removes information the downstream model depends on, and it does so silently.

The plotted curves are read by a learned pixel segmenter, and that segmenter benefits enormously from being told, in advance, what it is looking at. The header carries exactly that information. In the system we built for raster-log digitisation, which we call VeerNet, the track taxonomy the segmenter has to honour is fixed and specific: Track 1 and Track 2 each plot three curves, the gamma-ray, spontaneous-potential, and calliper in one and the shallow, medium, and deep resistivities in the other, and Track 3 plots a porosity pair, the neutron and density curves, for eight drawn curves in total. When the header is read correctly, the segmenter knows that the second track is a three-curve problem and the third is a two-curve problem before it labels a single pixel. When a header item is lost in the tail, that certainty is gone: the segmenter is left to guess how many curves a track holds, and a wrong guess propagates into every value it extracts. The cheap part of the page conditions the expensive part. A failure in the head of one problem becomes a failure in the body of the next.

This is also why the tail cannot simply be ignored as a rounding error. If the malformed sheets were uniformly worthless you could discard them, but they are not; they are ordinary wells whose headers merely scanned badly, and they carry the same eight curves as every clean sheet. Dropping them is not a ten-percent loss of header reading, it is a ten-percent loss of wells, and no operator working a real archive will accept that. The tail has to be recovered, which means it has to be budgeted, which means it has to be understood as a separate line item from the head it averages with.

What the classical toolkit still earns

It would be easy to read this as an argument for throwing a bigger model at the header until the tail submits. That reading would be wrong, and the reason is instructive. Most of the tail fixes named above are not learned at all. Contrast normalisation and binarisation are deterministic image operations. Deskewing is a projection-profile estimate with a closed form [3]. Stamp masking is layout analysis. Abbreviation disambiguation is a lookup against vendor and era. The recognizer itself, the one learned component, mostly needs to be fed better input rather than replaced, and where it does need adapting, the adaptation is retraining on degraded examples rather than a new architecture [2].

This mirrors a pattern the document-image and well-log communities have leaned on for a long time: deterministic methods own the regular, enumerable parts of a page, and learned models are reserved for the genuinely open-ended parts. A whole line of well-log digitisation work recovered plotted curves from scanned parameter graphs with morphology alone and no learned component at all, which is a useful corrective to the assumption that every hard scan needs a network [5]. The header tail is, in the same spirit, mostly a preprocessing-and-layout problem with a thin recognition layer on top, not a modelling problem. The engineering is real, but it is plumbing engineering, the unglamorous kind that does not produce a publishable metric and does produce a pipeline that survives contact with a real archive.

Budget for the ten percent, or the ten percent budgets you

The practical conclusion is a planning one rather than a technical one. When a digitisation effort is scoped, the header is almost always estimated from the head of its distribution, because the head is what a demo shows and what a representative sheet looks like. That estimate is not wrong about the head; it is wrong about the existence of the tail. The honest schedule treats header reading as two work items with wildly different unit costs: a high-volume, near-free pass over the clean majority, and a low-volume, high-cost campaign against a handful of failure modes that share nothing but their rarity and their expense. Name the carbon copies, the skewed sheets, the colliding abbreviations, and the overprints as distinct tasks up front, and the tail becomes a planned cost. Leave them folded into an average and they become the reason the project slips, one rare sheet at a time.

Key takeaways

  1. Reading the header off a scanned log is genuinely easy on the majority of sheets and genuinely hard on a small minority. The cost follows the minority, so an average-case estimate ('header OCR is easy') is true about the head of the distribution and misleading about the project, which is paced by the tail.
  2. The difficulty distribution is a cliff, not a slope. Crisp units, depth numerals, and the 22 standard electrical-measurement column names of the public FORCE 2020 / Xeek 118-well slice sit on a flat, near-free plateau; below them the cost rises sharply across unrelated failure modes.
  3. The tail is not one problem with one fix. It is at least four unrelated ones: faded carbon copies (a contrast and binarisation problem), sheets scanned off-square (a deskewing problem), colliding vendor abbreviations (a domain-disambiguation problem that vision cannot solve), and stamped or handwritten overprints (a layout and ink-separation problem). Each is rare and each is expensive.
  4. Most tail fixes are deterministic preprocessing and layout work, not a bigger model. Normalisation, deskewing, stamp masking, and abbreviation lookups carry the load; the one learned component, the recognizer, mostly needs better input or retraining on degraded examples, not a new architecture.
  5. A missed header item is not cosmetic. The header tells the curve segmenter how many curves each track holds (Track 1 and Track 2 carry three each, GR/SP/CALI and shallow/medium/deep resistivity; Track 3 carries two, NPHI and RHOB), so a header lost in the tail forces the downstream model to guess and propagates the error into extracted values. The tail must be budgeted as its own line item, not averaged into the head.

References

[1] Smith, R. An Overview of the Tesseract OCR Engine. ICDAR (2007). The open-source recognizer whose line-finding, character classification, and dictionary-driven decoding define the cheap, reliable end of printed-text reading, and the baseline a header pipeline starts from. https://ieeexplore.ieee.org/document/4376991

[2] Smith, R., Antonova, D., and Lee, D. Adapting the Tesseract Open Source OCR Engine for Multilingual OCR. Proceedings of the International Workshop on Multilingual OCR (2009). On retraining and adapting a recognizer when the input drifts away from clean modern print, which is exactly the condition a degraded log header presents. https://dl.acm.org/doi/10.1145/1577802.1577804

[3] Baird, H.S. The Skew Angle of Printed Documents. Proceedings of the SPSE Symposium on Hybrid Imaging Systems (1987). The projection-profile method for estimating and correcting page skew, the deskewing step a header block needs before a line-oriented recognizer can read it. https://link.springer.com/chapter/10.1007/978-3-642-77281-8_14

[4] Shafait, F. and Smith, R. Table Detection in Heterogeneous Documents. Proceedings of the 9th IAPR Workshop on Document Analysis Systems (2010). On recovering tabular and ruled layout structure under heterogeneous, degraded conditions, the layout problem a multi-track log title block poses to a recognizer. https://dl.acm.org/doi/10.1145/1815330.1815339

[5] Yuan, B. and Yang, Q. Digitization of Well-Logging Parameter Graphs Based on a Gridlines-Elimination Approach. Journal of Petroleum Exploration and Production Technology (2019). A morphology-first pipeline for scanned well-log graphs, a reminder that the deterministic toolkit still owns the regular parts of the page. https://link.springer.com/article/10.1007/s13202-019-0700-3

[6] McDonald, A. Using the missingno Python library to identify and visualise missing data prior to machine learning. Towards Data Science (2021). A tutorial on the FORCE 2020 / Xeek slice of 118 Norwegian-Sea wells carrying 22 electrical-measurement columns, the public vocabulary of standard log header names. https://towardsdatascience.com/using-the-missingno-python-library-to-identify-and-visualise-missing-data-prior-to-machine-learning-34c8c5b5f009

Go to Top

© 2026 Copyright. Earthscan