Recipe

Run the OCR pipeline end to end

Use when: You have a photographed or scanned document. You need its text as clean, structured output, not a pile of separate strings.

Goal: A structured result: a form's labeled fields, a table's rows and columns, or an ordered block of paragraphs. It's built from every region's recognized text, with low-confidence regions flagged rather than silently trusted.

Taught in The complete pipeline, worked end to end

1. 1

   Deskew the page, using Section 2's skew-angle calculation and Chapter 6's own rotation transform. Then binarize it: global or Otsu's method (Chapter 0) for even lighting, adaptive/local thresholding (Section 2) for a photo with shadows or glare.

   Example

   A photo of a receipt measures a 2.6^\circ skew from its own detected line boxes and has a shadowed corner. It gets rotated by -2.6^\circ, then binarized with adaptive thresholding rather than a single global T.

   Why: Detection and recognition both assume a clean, upright, high-contrast image. A crooked or unevenly lit input doesn't error out -- it silently produces bad boxes and garbled text.

2. 2

   Run a text detector over the preprocessed image, to find every region that contains text. This is Section 1's own machinery, built on Chapter 13's detection pipeline.

   Example

   The invoice from this section's own worked example detects 8 regions, from the header down to the footer's fine print.

   Why: Recognition can only read a region it has already been handed. Nothing downstream can recover text that a missed detection never found.

3. 3

   Crop every detected region, and read it independently with a sequence-model recognizer (Section 1). This produces a character string and a confidence score for each region.

   Example

   The blurred body-line region reads back "Rernit paymer,t w1thin 30 clays" at confidence 0.58. That's clearly garbled text, correctly scored low.

   Why: Each region is read on its own. So one damaged region's low confidence never drags down a clean region sitting right next to it.

4. 4

   Combine every region's recognized text into the final result, in the order the document's own structure calls for.

   Example

   This section's own worked example shows this: the two totals-table rows get grouped by Section 2's layout analysis before assembly. So "Subtotal" and "Total Due" each keep their own number, instead of running together into one line.

   • the document is free-flowing prose, no tables or forms — Assemble by simple top-to-bottom, left-to-right reading order. Layout analysis has no real grouping work to do here.
   • the document has a table or a form (rows, columns, or labeled fields) — Run Section 2's layout analysis FIRST, grouping regions by row, column, or field, before assembling. Skipping this doesn't crash the pipeline. It silently assembles the WRONG structured output -- a total landing in the subtotal's own slot.

   Why: Recognized text with no structure is just a pile of separate strings. Assembly is the step that turns it into something a program can actually use. It's the one step layout analysis feeds directly.