OCR & images

OCR has performed scaling and cropping; how is the recognition box mapped back to the original text

The bounding box returned by OCR is very accurate on the local image, but when rendered back into the PDF, it is offset overall. Do not immediately suspect the

阅读文本 / Reading text
This paper uses synthetic samples to demonstrate the processing method. The code has been verified using examples in an isolated environment; this does not guarantee effectiveness for all real files or products. Before processing important files, please retain the original copies and verify them against the boundaries and acceptance criteria specified in the text. The bounding box returned by OCR is very accurate on the local image, but when rendered back into the PDF, it is offset overall. Do not immediately suspect the recognition engine; instead, check the preprocessing sequence: was cropping performed first, followed by scaling, and then an additional white border added? Each step alters the coordinates, so the inverse transformation must undo them in the reverse order. uses a deterministic transformation instead of guessing the offset assumes that the original image points are first subtracted by the cropping origin, then multiplied by the scaling factor, and finally have padding added. The inverse process is to first subtract the padding, then divide by the scaling factor, and finally add back the cropping origin. If the horizontal and vertical scales differ, they must be stored separately; this also reminds us that arbitrarily stretching an image will alter the shape of text. enables round-trip testing to cover non-integer coordinates from math import isclose origin = (100.0, 40.0) scale = (2.0, 1.5) padding = (8.0, 12.0) def forward(point): return tuple((point[i] - origin[i]) * scale[i] + padding[i] for i in range(2)) def inverse(point): if any(s <= 0 for s in scale): raise ValueError("positive scale required") return tuple((point[i] - padding[i]) / scale[i] + origin[i] for i in range(2)) for point in [(100, 40), (125.5, 62.25), (200, 90)]: restored = inverse(forward(point)) assert all(isclose(a, b) for a, b in zip(point, restored)) assert forward((100, 40)) == padding assert inverse((58, 42)) == (125.0, 60.0) In this example, no OCR was performed; only the geometric formula was verified. Image resampling involves pixel centers and rounding conventions, so mapping to the true bounding box requires either unified continuous coordinates or pixel-boundary semantics. Do not round floating-point coordinates prematurely; instead, handle them according to explicit rules at the final rendering stage. The box does not always have only two points. transformation needs to save mapping note cropping origin offset restored to which version of the original image scaling aspect ratio prevents loss of precision in integer division rotates rotation center and matrix maps the four corners and then preserves the quadrilateral perspective correction homography A two-point rectangle is insufficient to represent the result uses manual anchor points to verify the display link marks known corner points on several anonymized samples and checks whether they coincide with their original positions after preprocessing and remapping. The mathematical unit tests pass, but this only rules out some computational errors; page rotation, display scaling, and the PDF coordinate system may still introduce new biases. Bilingual highlighting requires a trusted location around OmniDoc (Product Entry) When building a proofreading tool for translations, if source locations are to be displayed, the coordinate links should be validated alongside the content links. Highlighting on incorrect lines can make even correct translations appear unreliable. Maintaining transformation records is easier to manage than applying temporary compensations at the front end. Reference: Pillow Image Size and Transformation Interface 。 - 1 -
Updated 2026-10-08