How can the OCR upload interface be designed to prevent a single image from consuming the entire machine’s memory

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 outlined in this document. uploads a file that is only a few megabytes in size, yet after decoding it may require far more memory than expected. Highly compressible images, in particular, can easily render size estimates unreliable. The OCR entry point must simultaneously impose limits on both the number of bytes uploaded and the pixel dimensions, while also enforcing constraints on runtime memory usage, execution time, and concurrency levels. Do not disable protection just to eliminate warnings. Pillow has a pixel-count protection mechanism against potential decompression bombs. Directly MAX_IMAGE_PIXELS is set to None Although it can eliminate warnings, it also removes an important line of defense. Budgets should be defined based on business requirements, and it must be clearly specified which warnings are to be escalated to rejections. An entry check protected by a reserved library from io import BytesIO import warnings from PIL import Image def inspect(raw, max_bytes=4096, max_pixels=1000): if len(raw) > max_bytes: raise ValueError("upload byte budget") with warnings.catch_warnings(): warnings.simplefilter("error", Image.DecompressionBombWarning) with Image.open(BytesIO(raw)) as im: if im.width * im.height > max_pixels: raise ValueError("pixel budget") im.load() return im.size stream = BytesIO() Image.new("RGB", (40, 30), "white").save(stream, format="PNG") raw = stream.getvalue() assert len(raw) < 4096 assert inspect(raw, max_pixels=1200) == (40, 30) try: inspect(raw, max_pixels=1000) except ValueError as exc: assert "pixel" in str(exc) else: raise AssertionError("pixel budget not enforced") budget values are intended solely for synthetic testing. The example processes a single frame and does not account for total multi-frame throughput, encoder vulnerabilities, or peak concurrent decoding rates. The official entry point also requires frame-count and cumulative-pixel limits, and it handles untrusted files within an isolated execution environment. has responsibilities distinct from those of isolation controls primarily constrains still needs to be supplemented with upload byte limit network and storage overhead decoding scale maximum number of pixels per page Common large-image risks multi-frame accumulation scale Memory and Time Limits actual execution consumes interpretable error feedback concurrency limit total resource consumption queue and backpressure budget overrun is not synonymous with a bad file Even legally compliant large-scale engineering drawings may exceed the default budget; therefore, they should be routed through a well-defined large-file workflow rather than having all safeguards quietly disabled. Users must be informed whether the threshold is being exceeded in terms of pixels or bytes, so they can decide whether to split pages, reduce the capture resolution, or select a specialized processing method. translation entry point should explicitly state the input risks in advance in OmniDoc (Product Entry) Adding a proprietary input pre-check before integration allows for earlier feedback on large images that are not supported. The pre-check cannot replace the platform’s own restrictions, nor should it falsely claim that the platform has already implemented the strategies outlined in this document; rather, it serves as an interpretable layer of assurance between upload and delivery. Reference: Decompression Protection Instructions for Pillow Images 。 - 1 -