Moin,
We’re a PRO customer and are seeing non-deterministic behaviour with OCREngine=2 + isTable=true on both PRO endpoints.
Setup — all parameters sent as multipart form-data fields, file uploaded via file:
OCREngine=2
isTable=true
scale=true
detectOrientation=true
language=auto
filetype=pdf
Input: a single-page A4 German invoice scan, PDF, ~230 KB, containing a header block, an address block, a line-item table and a footer.
Symptom — the same file with the same parameters returns one of two clearly distinct results:
response time TextOverlay.Lines words ParsedText
good 1.27–1.58 s 65 259 complete
degraded 0.64–0.95 s 10 89 middle section missing
In the degraded result, ParsedText contains only lines from the very top and the very bottom of the page. The entire middle of the document — the line-item table and the totals block — is absent.
The most telling difference is in the overlay. In the good result each word has its own bounding box. In the degraded result all words of a line report one identical box:
// degraded: four words, identical Left/Top/Height/Width
{“WordText”:“WordA”,“Left”:87,“Top”:1305,“Height”:31,“Width”:311},
{“WordText”:“WordB”,“Left”:87,“Top”:1305,“Height”:31,“Width”:311},
{“WordText”:“WordC”,“Left”:87,“Top”:1305,“Height”:31,“Width”:311},
{“WordText”:“WordD”,“Left”:87,“Top”:1305,“Height”:31,“Width”:311}
Line-level geometry differs too — the first line of the page is reported as 1493/107/173/795 in one class and 1482/105/184/821 in the other. That looks like two different processing paths rather than a filtering step.
Already ruled out:
- Parameter casing — isTable and istable both produce both outcomes.
- Endpoint — occurs on apipro1 and apipro2; two consecutive calls to the same endpoint returned different classes.
- Caching / repeated submissions — the degraded result also occurs on a cold first request for a document not submitted before.
- Error signalling — OCRExitCode: 1 and IsErroredOnProcessing: false in both cases, so there is nothing to branch on.
Response time is the only external predictor we found (4/4 in local tests; a degraded production case returned in 0.625 s).
Because both responses are reported as success, we currently cannot distinguish them without heuristics such as the duplicate-bounding-box check above. Is this a known issue in the Engine 2 table path, and is there a reliable way to detect or avoid the degraded result?
Sadly we are not able to share the document as it contains customer data. We currently try to replicate the behaviour with test documents.
Kind regards
Tim
