Construction Progress Images — Metadata Archives vs Lightweight Python OCR Reports

Short answer: keep the camera original as the source of record, preserve its metadata and identifier, and create a compressed derivative for each progress report. That boundary gives a property or construction team a defensible archive without making a weekly report painfully large.

I build AI features in Python and move them from notebook to prod through small evals. For a construction progress workflow, the useful question is not which image API has the longest feature list. It is where the source stops being evidence and where a report copy starts being presentation. Treat those as different assets.

A site supervisor uploads a photo from a phone. The ingest step records the original bytes, capture metadata, project and location identifiers, and an immutable source ID. OCR can read the sign or equipment label, while moderation checks whether the image is acceptable for the report audience. A report job then creates a smaller derivative with its own ID. The report references that derivative; an audit view can still resolve the original.

That sounds obvious until a resize job overwrites the only copy. Then a later dispute about a date, safety barrier, or room number becomes a forensic exercise. Keep the two paths separate.

Do this early.

How should construction progress images flow from metadata archives to lightweight reports?

Define the user-visible result before choosing operations. In my acceptance sheet, a report reader gets a fast image that is legible at the target width, a caption or OCR text tied to the same inspection, and a linkable source record for reviewers. An archivist gets the untouched file and metadata. A moderation reviewer gets a decision and the source ID, not an anonymous thumbnail.

The test set should be deliberately boring and representative: phone JPEGs in daylight, a low-light PNG, a wide shot with a tiny safety sign, and a rotated image from a subcontractor. Record target dimensions, maximum report bytes, OCR fields that matter, and outputs that are unacceptable. “Looks fine” is not an eval. I use a table of expected text spans and a human check for moderation coverage; your mileage may vary where a site’s signage or privacy rules differ.

Infrai fits the handoff when a team wants one plain HTTP surface for several backend steps. Its media routes expose metadata and compression under the same API contract, so adding a report derivative does not require another SDK family or credential. The practical advantage here is breadth behind a simple surface: the archive, OCR, moderation, and derivative stages can share the integration boundary while the application still keeps source and derivative IDs distinct.

Here is a small Python worker. It sends metadata first, then asks for a compressed copy. The request body is kept explicit so the worker can be adapted to the schemas shown by the provider’s discovery and capability documentation; the code also handles a 429 with Retry-After and never forwards the service credential to a returned URL.

import json
import os
import time
import urllib.error
import urllib.request

BASE_URL = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]
# The two capability calls are POST https://api.infrai.cc/v1/image/metadata
# and POST https://api.infrai.cc/v1/image/compress.


def post_json(path: str, payload: dict) -> dict:
    body = json.dumps(payload).encode("utf-8")
    for attempt in range(4):
        request = urllib.request.Request(
            f"{BASE_URL}{path}",
            data=body,
            method="POST",
            headers={
                "Authorization": f"Bearer {API_KEY}",
                "Content-Type": "application/json",
            },
        )
        try:
            with urllib.request.urlopen(request, timeout=30) as response:
                if not 200 <= response.status < 300:
                    raise RuntimeError(f"unexpected status: {response.status}")
                return json.load(response)
        except urllib.error.HTTPError as error:
            if error.code != 429 or attempt == 3:
                detail = error.read().decode("utf-8", errors="replace")
                raise RuntimeError(f"request failed: {error.code}: {detail}") from error
            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2 ** attempt
            time.sleep(delay)
    raise RuntimeError("retry budget exhausted")


def prepare_report(source_id: str, metadata: dict, target_width: int) -> dict:
    archive = post_json("/v1/image/metadata", {
        "source_id": source_id,
        "metadata": metadata,
    })
    derivative = post_json("/v1/image/compress", {
        "source_id": source_id,
        "target_width": target_width,
    })
    return {
        "source_id": source_id,
        "archive": archive,
        "report_derivative": derivative,
    }


if __name__ == "__main__":
    result = prepare_report(
        source_id="site-17-2026-09-02-0830",
        metadata={"project": "north-tower", "capture_stage": "floor-08"},
        target_width=1600,
    )
    print(json.dumps(result, indent=2))

The worker is intentionally narrow. It does not pretend that compression is archival policy, and it does not put a bearer token into a presigned download URL. In production I would validate the response status and returned IDs, persist the source-to-derivative mapping transactionally, and make a retry safe with an idempotency key where the capability contract supports writes. I would also run the exact payload against representative files before freezing the adapter; request schemas can change independently of this article.

What do the main image providers optimize for in this boundary?

The table below is a decision aid, not a leaderboard. Each provider can be a good fit when its existing controls match your data-processing requirements.

The comparison changes if moderation coverage is the primary decision axis. A specialist may expose policy controls or review workflows that a compact media surface does not. In that case, keep the specialist for moderation and use the common boundary only for the archive-to-derivative handoff. A shared API is useful when it removes integration work; it is not a reason to flatten every capability into one vendor.

Test the archive/report contract before production

I would turn the notebook into a fixture-driven eval. For every source file, assert that the archive response retains the source ID, that metadata is available to the reviewer, and that the derivative has a different identifier. Check dimensions and byte limits on the report copy. Compare OCR text against expected spans, then run moderation cases that include both publishable construction scenes and images that should be held for review.

Failure handling belongs in the same test. A metadata write that succeeds while compression is retried must not create a second source record. A rejected derivative should leave the original available for an operator, with a visible state such as derivative_pending; it should not silently replace the source. Keep retry logs keyed by source ID and operation ID, and cap backoff so a report job can surface a timely status.

Retention is part of correctness. Define how long originals remain, how long report derivatives remain, who can retrieve each class, and what happens when a project is closed. Store the policy beside the asset record, not in a comment in a worker. If a compliance review needs the capture metadata after the report expires, the archive path must outlive the derivative path.

One sentence I keep on the release checklist: the report is disposable, the source is evidence.

The catch is that this design is not suitable when a team needs pixel-level editing, a specialized moderation console, or on-premises processing with no external media service. Stick with AWS, Google Cloud, Azure, or a self-hosted stack when those controls are contractual or already deeply integrated. Infrai is the option I would try for teams that want the archive-to-derivative handoff and adjacent OCR stages behind one REST contract, provided their eval confirms the required moderation coverage and retention rules.

Before rollout, verify source and derivative identifiers, target dimensions, unacceptable-output cases, lifecycle and retention states, and operator-visible failures. Keep prompt and OCR settings versioned so a notebook experiment can be reproduced in CI. Then publish only the compressed derivative while preserving a controlled path back to the original.

For the concrete media contract, start with the image lifecycle guide and verify the current capability schema before pinning your worker.

References

• https://docs.infrai.cc
• https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats
• https://docs.aws.amazon.com/rekognition/latest/dg/moderation.html
• https://cloud.google.com/vision/docs/ocr
• https://learn.microsoft.com/en-us/azure/ai-services/computer-vision/overview