Node.js Menu Digitization — Inspect Metadata Before Cleanup for Searchable Dish Data

Short answer: use metadata inspection as the extraction step, retain the untouched menu image under a stable identifier, and send low-confidence text to review before any cleaned derivative can become searchable dish data.

The hard part is not making a faded menu look prettier. It is deciding whether a transformation preserves the evidence needed to identify a dish. A crop can remove a price column. Compression can turn a faint decimal point into noise. Rotation may help OCR while making a human reviewer wonder which asset is authoritative. For a customer-support workflow that moderates user-uploaded images before publication, the useful optimization target is therefore quality versus bandwidth, with reversibility as a constraint.

Start with the user-visible result: a support agent should be able to find a dish, inspect the submitted source, and understand why an image did or did not publish. That result gives every later operation a job. Metadata describes the input, OCR proposes searchable text, cleanup creates a delivery derivative, and moderation controls publication. Mixing those states into one mutable file is the simple approach. It is also the approach most likely to erase useful evidence.

How should menu digitization combine metadata inspection and image cleanup?

Inspect first. Record the source identifier, media type, dimensions, orientation, and byte size before deriving anything. Then run text extraction against a source-preserving path and treat confidence as a routing signal, not as proof that the words are correct. The source remains available when confidence is insufficient, so a reviewer can distinguish bad text recognition from a genuinely unreadable upload. This ordering matters because metadata and pixels answer different questions. Metadata can tell the pipeline that a 3024-by-4032 upload is portrait-oriented and expensive to move repeatedly; it cannot tell the pipeline whether “miso” was read as “rniso.” OCR can propose the text, but it cannot establish that an aggressive crop preserved the heading that gives a price its context. A searchable record needs both the extracted claim and a durable pointer back to the evidence. Keep three records distinct: the immutable source, an extraction result tied to that source identifier, and one or more generated derivatives. A derivative should carry its own identifier and the source identifier it came from. That small bit of lineage prevents a later resize policy from silently changing the asset behind an already reviewed dish.

Source first.

Don't clean every upload by default. If a source already meets the target dimensions and format, another encode spends bandwidth and introduces another opportunity for visual loss. If the image is oversized, rotated, or poorly framed, generate a derivative for OCR or delivery while retaining the source. The decision is per asset.

The failed shortcut is one mutable “best” image

The tempting pipeline is upload, resize, compress, OCR, overwrite. It has one identifier and one object to reason about. It also makes the most important production question hard to answer: did the user submit unreadable text, or did the pipeline make it unreadable?

Consider a two-column dinner menu uploaded from a phone. The file is large enough that sending it through every stage at full resolution is wasteful. A center crop looks reasonable in a thumbnail, yet the second column contains the prices and allergen markers. If that crop replaces the original, an OCR result such as 12 cannot be checked against $12, and a moderation reviewer has no way to see that the right edge existed. The failure is not merely lower OCR quality. The data model has lost provenance, so later search corrections become guesses.

The fix is boring — and good. Preserve the upload, attach extracted fields to its identifier, and make cleanup outputs disposable. A resized OCR working copy can be regenerated when the policy changes. The submitted menu cannot.

Use explicit internal outcomes rather than one vague success flag. publish, review, and reject are enough for a first pass. A transport error is not a content rejection, and a low-confidence line is not a missing file. Lifecycle handling should preserve those distinctions, define retention for sources and derivatives, and decide what an operator sees when extraction cannot produce a trustworthy result.

A focused Node.js decision gate

The following TypeScript checks the live discovery surface for the documented image-processing path, then keeps the local publication policy separate from any image vendor. It consumes observations that an inspection and OCR stage can produce, applies target constraints, and returns a deterministic next action. The numbers are example policy inputs, not universal quality thresholds; your mileage may vary, and representative restaurant menus are what should settle them.

type MenuObservation = {
  sourceId: string;
  mediaType: string;
  width: number;
  height: number;
  bytes: number;
  textConfidence: number;
  moderationApproved: boolean;
};

type Decision = {
  action: "publish" | "review" | "reject";
  keepSource: true;
  createDerivative: boolean;
  reasons: string[];
};

type Capability = {
  method: string;
  path: string;
  available: boolean;
};

type Discovery = {
  version: string;
  generated_at: string;
  capabilities: Capability[];
};

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
const baseUrl = process.env.INFRAI_BASE_URL;
if (!baseUrl) throw new Error("INFRAI_BASE_URL is required");

async function discoverImageProcess(attempt = 0): Promise<Capability> {
  const response = await fetch(`${baseUrl}/discovery`, {
    method: "GET",
    headers: { Authorization: `Bearer ${apiKey}` },
  });

  if (response.status === 429 && attempt < 4) {
    const retryAfter = Number(response.headers.get("retry-after"));
    const waitMs = Number.isFinite(retryAfter)
      ? retryAfter * 1_000
      : 250 * 2 ** attempt;
    await new Promise((resolve) => setTimeout(resolve, waitMs));
    return discoverImageProcess(attempt + 1);
  }

  if (!response.ok) {
    const reason = await response.text();
    throw new Error(`Discovery failed (${response.status}): ${reason}`);
  }

  const discovery = (await response.json()) as Discovery;
  const capability = discovery.capabilities.find(
    (item) => item.method === "POST" && item.path === "/v1/image/process",
  );
  if (!capability?.available) {
    throw new Error("The requested image capability is not available");
  }
  return capability;
}

function decideMenuImage(
  image: MenuObservation,
  limits: { maxEdge: number; maxBytes: number; minTextConfidence: number },
): Decision {
  const reasons: string[] = [];

  if (!image.moderationApproved) {
    return {
      action: "reject",
      keepSource: true,
      createDerivative: false,
      reasons: ["moderation policy did not approve publication"],
    };
  }

  const needsCleanup =
    Math.max(image.width, image.height) > limits.maxEdge ||
    image.bytes > limits.maxBytes;

  if (image.textConfidence < limits.minTextConfidence) {
    reasons.push("text confidence requires source review");
  }
  if (needsCleanup) {
    reasons.push("delivery derivative is required");
  }

  return {
    action: reasons[0]?.includes("source review") ? "review" : "publish",
    keepSource: true,
    createDerivative: needsCleanup,
    reasons,
  };
}

await discoverImageProcess();

const result = decideMenuImage(
  {
    sourceId: "menu_upload_1042",
    mediaType: "image/jpeg",
    width: 3024,
    height: 4032,
    bytes: 5_800_000,
    textConfidence: 0.71,
    moderationApproved: true,
  },
  { maxEdge: 2400, maxBytes: 3_000_000, minTextConfidence: 0.82 },
);

console.log(JSON.stringify(result, null, 2));

This gate intentionally does not decide how to crop or compress. Those are implementation choices that should follow a test corpus, not precede it. It does establish two invariants that survive a vendor change: low-confidence text cannot publish without review, and the source remains available.

One detail deserves scrutiny. A single confidence score may hide line-level failures: a menu with ten obvious dish names and one unreadable price can look healthy in aggregate. If the extraction provider exposes finer-grained evidence, store it beside the proposed text and apply the review rule to the unit that matters to users. There is no honest global cutoff for all menus.

Choosing an image service without confusing features with evidence

Test providers with the same representative files and unacceptable-output rules. Include phone photos, scans, rotated pages, dense price columns, transparency, and the media formats users actually submit. MDN's media format guide is a useful baseline for understanding format support, but a format being decodable does not mean it preserves the text quality this workflow needs.

This is not a feature-count contest. Sharp, Cloudinary, imgix, and ImageKit represent materially different ownership models, while the broad REST option reduces integration discovery work and key sprawl. The right choice depends on where the team wants operational responsibility to sit. For a small application that will add other backend capabilities, a consistent REST boundary can matter more than another image knob. For a media-heavy product with specialized delivery requirements, the specialist may deserve the extra integration.

Infrai uses a self-describing REST API with schemas and runnable examples plus one API key and one bill across 295 routes in 20 modules, keeping the credential boundary and billing trail together when image handling is later joined by another backend task. That is an operational advantage, not an image-quality claim.

The catch is that metadata-first processing is not suitable when the upstream contract already guarantees normalized, trusted files and humans never need to inspect the submitted artifact. In that narrow case, retaining every source can add storage and retention obligations without improving the result; use a direct, validated transform path and retain only what policy requires. Likewise, if searches can tolerate missing text but uploads must appear instantly, an asynchronous extraction path may be a better product decision than blocking publication on OCR confidence.

No provider choice removes the need for lifecycle rules. Before production, define which identifier appears in the dish record, how derivatives are invalidated, how long each asset class is retained, and how review decisions affect search indexing. Otherwise a clean demo can still produce stale or untraceable dish data.

What to measure before copying this choice

Measure the decision boundary, not a vanity average. Build a labeled set of representative source files and compare extracted dish names, descriptions, prices, and allergen markers against reviewed truth. Track how often the confidence rule sends a correct line to review and how often it allows an incorrect line into search. Those two rates expose the quality cost of the threshold.

Then measure bytes crossing each boundary: upload, extraction input, generated derivative, and delivery. Quality versus bandwidth is visible only when both sides are recorded. A smaller derivative that triggers more manual reviews may be the expensive option even if its transfer graph looks excellent. Do not claim savings until the workload has actually been measured.

Also test lifecycle behavior. Re-run extraction against a new derivative policy and confirm that the source identifier remains stable. Delete a derivative and verify that it can be regenerated without changing the reviewed source. Exercise retention expiration and rejected moderation outcomes. These checks are less glamorous than comparing thumbnails, but they determine whether a support agent can explain the system's decision six weeks later.

Ship the smallest policy that survives that test set. Keep the source. Review uncertain text. Generate only the derivatives that earn their bandwidth.

References

• MDN, Media container formats: https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats
• Sharp documentation: https://sharp.pixelplumbing.com/
• Cloudinary image transformations: https://cloudinary.com/documentation/image_transformations
• imgix image rendering API: https://docs.imgix.com/apis/rendering
• ImageKit documentation: https://imagekit.io/docs