Adaptive Document Tiling

How long receipts and large scans are read in overlapping regions without losing small print.

On this page

When a page is cut
How the reading is put back together
Cut for the recogniser that reads it
Control it
See what happened

A long supermarket receipt photographed whole is three or four times as tall as it is wide; an A4 page scanned at 600 dpi is about 5000 × 7000 pixels. A text recogniser that shrinks either to its own working size loses the small print: the VAT line, the total, the footer. Adaptive Document Tiling cuts such a page into overlapping regions, reads each region at full resolution, and puts the lines back together in the whole page's coordinates.

When a page is cut#

Each recogniser declares the longest side it reads at full detail. With tiling: auto, the default, a page is cut only when it is larger than that, when the recogniser would otherwise shrink its print. A page the recogniser takes whole is sent whole, so it is not read, and paid for, several times over.

A tall page, at least 1.7 times as tall as it is wide, is cut into horizontal bands: two below an aspect of 2.6, three below 3.5, four below 4.4, then one more for every further 0.9, up to eight.
A wide page, at least 1.7 times as wide as it is tall, is cut into columns the same way.
A page that is simply large is cut into a grid, so that each region's long side fits what the recogniser reads at full detail.

Every region overlaps the next by 6% of the page, and a page has at most 16 regions. For a tall receipt the bands are the ones the capture SDKs' on-device reader uses, with the same thresholds and the same overlap, so a phone and ReceViz cut a long receipt identically.

How the reading is put back together#

The shaded strips are where regions overlap. The dark row crosses region 1's lower edge, so region 1 reads only part of it; its centre lies below the dashed line, so the line is taken from region 2, which read it whole.

Every line read in a region is mapped back to the whole page, so a field's bounding_box is always in the page's coordinates, never the region's.
Each region owns the page up to the middle of its overlap with the next. A line is kept only from the region that owns its centre, so a line cut by one region's edge is taken from the neighbour that read it whole.
Any duplicate the ownership rule could not settle, the same text in the same place read by two regions, is dropped, keeping the larger reading.

The regions of a page are read at the same time, up to four at once, within the request's single deadline.

Cut for the recogniser that reads it#

Because the decision depends on the recogniser's own size, the same photograph may be read whole by one recogniser and in regions by another. In the hosted service:

Recognisers and their full-detail size
processing.ocr_provider	Reads at full detail up to	What that means
`document_ai`	6,000 px on the long side	Phone photos and long receipts are almost always read whole.
`gemini`	about 1,600 px	Used only where the data policy allows language models; larger pages are cut for it.
`client`	Not applicable	Text read on the device is never tiled again.

PDF pages are rendered at up to 2,800 px on their long side before they are read, so they are cut only for a recogniser that reads less than that. A PDF handed whole to a recogniser that reads PDFs itself is not cut.

Control it#

Set options.tiling on a request, or a default on the application in the console:

auto: cut a page only when it helps. The default.
off: never cut.
force: always cut into at least two regions, for testing or for documents you know need it. It needs the adaptive_tiling capability.

Tiling runs only for credentials that hold adaptive_tiling (new organizations are granted it); without it, a page is always read whole. See Capabilities.

See what happened#

processing.tiling says whether any page was cut, and how, page by page (pages counted from 1): {"applied": true, "pages": {"1": {"tiles": 3, "rows": 3, "cols": 1, "reason": "long"}}}. The reason is long, wide, large or forced. What the planner chooses for three pages:

json

{
  "long_receipt": {
    "tiles": 3,
    "rows": 3,
    "cols": 1,
    "reason": "long"
  },
  "large_scan": {
    "tiles": 6,
    "rows": 3,
    "cols": 2,
    "reason": "large"
  },
  "read_whole": {
    "tiles": 1,
    "rows": 1,
    "cols": 1,
    "reason": "single"
  }
}

That is a 1000 × 3400 receipt for a recogniser that reads 1,600 px (three bands), a 5000 × 7000 scan for one that reads 3,000 px (a grid of three rows and two columns), and the same receipt for one that reads 6,000 px (read whole).