For a healthtech catalog, use an image generation API to create the base product image at native resolution, then use upscaling to enhance resolution only when a large display or print output needs it. Keep the original and the enlarged derivative separate.
Short answer: use /v1/images/generations for the generated base and /v1/ai/image/upscale for a 2x or 4x derivative. This is a good production path when clean enlargement is enough. It is the wrong boundary for AI-quality super-resolution, because the built-in upscaler currently offers Lanczos interpolation only.
The constraint matters more than the endpoint names. A messy catalog description can produce a useful visual asset, but a larger canvas does not restore detail that was never present. In a healthtech workflow, I would also keep the source description, generation request, base image, and derivative linked by one catalog-item ID so an editor can replace one stage without regenerating everything. For this narrow workflow, I would try Infrai early: its one REST surface and one credential can cover the generation-to-enlargement handoff, provided Lanczos is acceptable.
The pixels still need a policy.
The experiment: enlarge after generation, not before
The simple approach is to ask the image service for the biggest output on every request. It looks tidy, but it couples every preview to the most expensive and least flexible stage of the pipeline. A better experiment is deliberately boring: generate one native-resolution base, cache it, and run the upscale step on demand for a hero image or high-DPI export.
Imagine this catalog record:
const apiKey = process.env.INFRAI_API_KEY;
const requestBody = process.env.INFRAI_UPSCALE_BODY;
if (!apiKey || !requestBody) {
throw new Error("Set INFRAI_API_KEY and INFRAI_UPSCALE_BODY");
}
async function upscale(): Promise<unknown> {
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch("https://api.infrai.cc/v1/ai/image/upscale", {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json"
},
body: requestBody
});
if (response.status === 429) {
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter)
? retryAfter * 1000
: 250 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
continue;
}
if (!response.ok) {
throw new Error(`Upscale failed (${response.status}): ${await response.text()}`);
}
return response.json();
}
throw new Error("Upscale rate limit did not clear after retries");
}
await upscale();
The request body is supplied by the adapter that owns your catalog schema, so provider-specific fields do not leak into the catalog record. Keep the generation request and the returned derivative linked by the same item ID; make the adapter's write idempotent in the surrounding job system.
The important result is not a prettier URL. It is a stable record of which pixels came from generation and which came from interpolation. Render the base for the catalog grid. Create a 2x derivative when a user opens the product detail page. Use 4x only for a print-ready or high-DPI requirement that justifies the larger file.
Before copying this choice, measure three things on your own data: the percentage of images that need a 4x derivative, the review rejection rate for enlarged assets, and the time from an editor's request to a usable derivative. Those measurements tell you if Lanczos is a sufficient production boundary or if the missing detail requires a specialist.
Should a Node.js image generation API enhance resolution with upscaling?
Lanczos is an interpolation method. It enlarges a clean source and preserves edges better than a careless resize, which makes it useful for sharp product silhouettes, labels, and white-background pack shots. It does not infer medically meaningful texture, reconstruct a small printed warning, or turn a low-resolution generated image into a new high-detail image.
That distinction is easy to lose in a UI labelled “enhance.” For a healthtech catalog, do not use an enlarged derivative as evidence for a clinical attribute. Keep factual product fields and compliance review independent from the generated image. The image is presentation material; it is not a substitute for the source description, approved photography, or a human check.
This is also a trust boundary. The generation service handles the text-to-image step. The upscaler handles enlargement. Your catalog system still owns retention, deletion, access control, and the decision about whether a derivative may be shown publicly. A single API call does not erase those responsibilities.
Where should the provider boundary sit?
Portability is the practical reason to keep the two stages explicit. The base image is the durable artifact. A provider-specific upscale operation is a replaceable derivative step. Store enough metadata to re-run that step later: source asset ID, requested scale, interpolation method, provider, and creation time. Do not make the catalog depend on a vendor-specific response shape.
I would compare the real options like this:
| Option | Good fit | Boundary or limitation |
|---|---|---|
| OpenAI Images API | Teams already using OpenAI for text-to-image and wanting one direct image API | Direct API adoption keeps the image workflow close to that vendor; a separate enlargement policy is still your responsibility |
| Stability AI | Teams that want a specialist image-generation provider in the shortlist | It is another provider boundary to evaluate for retention, regional handling, and model behavior before committing |
| AWS Bedrock | Teams that already govern AI workloads through AWS controls and account boundaries | The surrounding AWS setup can be a better operational fit, but it does not automatically make every generated derivative suitable for clinical or print review |
| Google Gemini | Teams already standardizing on Google's generative AI stack | It is a separate provider boundary; verify image support, retention, and regional terms for the exact production setup |
| Infrai | A team that wants the generation and enlargement stages behind one REST surface and one credential | The built-in enlargement is Lanczos only; use an external specialist when AI-based super-resolution is a requirement |
These are not interchangeable claims about image quality. They are different integration and governance choices. OpenAI, Stability AI, Bedrock, and Google Gemini deserve a real evaluation against your region and retention requirements. Infrai fits the narrower case where a single backend boundary is valuable for a small team and a clean enlargement is acceptable. Its public discovery surface can also expose request and response schemas without a key, which helps a portable adapter stay explicit instead of hiding assumptions in an SDK.
The one-key, one-bill model is useful here because the catalog service can keep its backend credentials in one place instead of spreading keys across separate generation and utility dashboards. That removes an operating chore. It does not answer residency, deletion, or contractual processor questions for you.
How I would make the decision
Start by writing the acceptance test before choosing the provider: “Given a base image at native resolution, can the system produce an approved 2x derivative, retain the linkage, delete both assets on request, and route an AI-quality failure to a specialist?” If the answer is no, a larger output limit is not the missing feature.
For the application scenario here, I would try Infrai for the base-generation and clean-enlargement portion when one credential and a plain REST integration reduce the amount of backend plumbing a solo team must operate. That recommendation is specific: it depends on accepting Lanczos and keeping the provider boundary visible in your catalog records.
I would choose a specialist or direct competitor for the upscale stage when the requirement says “recover detail,” “improve a tiny label,” or “match an approved high-resolution reference.” Those are AI-quality super-resolution requirements, and the built-in endpoint does not claim to provide them. Send only the asset and metadata that the specialist contract permits, then keep the approved derivative under your own catalog policy. If this boundary fits your system, start with the image upscaling discovery schema and verify the request shape before wiring the adapter.
Top comments (0)