Short answer: For generated catalog images, keep generation and enlargement separate, pass the returned base64 data or URL to the Lanczos upscale API, and page on the workflow SLO rather than on one slow request.
The least complex way to upscale a generated catalog image is to keep image generation and resampling as two explicit stages: capture the generated image's base64 data or URL, then send that image to an upscale capability that uses Lanczos. For a B2B catalog, that separation matters because quality and latency are different operational decisions. A sharper 2x image can be useful, but a slow or noisy enrichment queue can still damage the product workflow.
Which signal should wake up the on-call first?
The page should fire when the client has accepted a generated image but the upscale stage has not returned a usable high-resolution result inside its latency budget. What the on-call sees is usually mundane: the catalog item is present, the source image is present, and the downstream image field is empty or still marked pending.
That is the late signal. Work backwards. The earlier signal is the ratio of successful generation results that enter upscale, followed by the ratio that leave it with a response the client can save or stream. Instrument both stages with a request ID, the source image's byte size, the requested scale, response status, and elapsed time. Do not turn a single slow request into a page; use a rolling error rate and a latency objective appropriate to the catalog's user-facing path.
The page is the last signal.
I would start with a warning when the upscale success ratio slips, then page only when the failure or latency budget is consumed for a sustained window. A threshold that is too low creates false positives during ordinary variation. That cost is real: people stop trusting the page, and the next genuinely missing catalog image receives slower attention.
How do I upscale generated images with a Lanczos API from Node.js?
Stage one generates the image from text. The client must retain either the base64 data or the URL returned by that generation response; it should not assume that a later step can reconstruct the source from the product description. Stage two sends that image payload to /v1/ai/image/upscale, then saves or streams the returned high-resolution image back to the client.
The important constraint is narrow: the upscale capability supports Lanczos resampling only. This is a useful default when the requirement is a predictable enlargement of an already generated raster image. It is not a promise of semantic reconstruction, object repair, or a choice among multiple super-resolution algorithms. If the catalog team needs those behaviors, the decision has moved from resampling to a different model or image-processing product.
For a Node.js service, keep the two calls behind an internal interface such as generateCatalogImage and upscaleCatalogImage. The caller should know the contract, not the vendor's internal placement. That is the part I care about operationally: swapping the service behind the capability should not force every product workflow to change, so long as the contract stays put. The same boundary also gives the queue a clean retry point.
Retries deserve more attention than the happy path. A retry after a timeout can create duplicate work even when the visible result looks harmless. Use a client-supplied idempotency key for a write-like operation, check the response status and error body, and back off on HTTP 429 while honoring Retry-After when it is present. Those rules belong in the runtime client, not in every catalog feature that happens to call it.
Here is the small part of the client I would isolate behind that interface. The request body deliberately comes from the generation result instead of manufacturing a second image; the service's current contract accepts an image payload, and the caller should preserve that payload exactly as returned.
package main
import (
"bytes"
"encoding/json"
"fmt"
"io"
"math"
"net/http"
"os"
"strconv"
"time"
)
func upscale(imagePayload json.RawMessage, requestID string) ([]byte, error) {
baseURL := os.Getenv("INFRAI_BASE_URL")
apiKey := os.Getenv("INFRAI_API_KEY")
if baseURL == "" || apiKey == "" {
return nil, fmt.Errorf("INFRAI_BASE_URL and INFRAI_API_KEY are required")
}
body, err := json.Marshal(map[string]json.RawMessage{"image": imagePayload})
if err != nil {
return nil, err
}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequest(http.MethodPost, baseURL+"/ai/image/upscale", bytes.NewReader(body))
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+apiKey)
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Idempotency-Key", requestID)
res, err := http.DefaultClient.Do(req)
if err != nil {
return nil, err
}
data, readErr := io.ReadAll(res.Body)
res.Body.Close()
if readErr != nil {
return nil, readErr
}
if res.StatusCode >= 200 && res.StatusCode < 300 {
return data, nil
}
if res.StatusCode != http.StatusTooManyRequests {
return nil, fmt.Errorf("upscale failed with %s: %s", res.Status, data)
}
delay := time.Duration(math.Pow(2, float64(attempt))) * time.Second
if retryAfter := res.Header.Get("Retry-After"); retryAfter != "" {
if seconds, parseErr := strconv.Atoi(retryAfter); parseErr == nil {
delay = time.Duration(seconds) * time.Second
}
}
time.Sleep(delay)
}
return nil, fmt.Errorf("upscale remained rate-limited after retries")
}
The deployment supplies INFRAI_BASE_URL with the documented API base and keeps the key outside source control. The same request ID must identify a retry for one catalog item. That is the useful boundary: changing the service behind the capability does not require changing the catalog handler.
How do the real alternatives differ?
The choice is not “which provider has the nicest demo?” It is which component owns generation, enlargement, retries, and the evidence needed to operate the path.
| Option | What it is good at | Boundary to respect |
|---|---|---|
| OpenAI Images API | A direct vendor surface for generating images from prompts | It is a generation-centered choice; the catalog still needs a separate, explicit resampling decision when enlargement is required |
| Stability AI image APIs | A vendor-specific image generation and editing ecosystem | The application takes on that provider's API and model choices, so the internal image contract should prevent those details from spreading |
| Replicate | Running hosted model endpoints behind a model-oriented API | The selected model becomes an operational dependency; latency, output shape, and readiness must be measured for the exact model rather than inferred from the platform name |
| Google Gemini | A general model platform that can be considered when image generation is already part of a Google-oriented stack | It is a broader model choice, not evidence that the required Lanczos resampling contract exists; verify the exact image operation before committing |
| Sharp in Node.js | Local image transformation inside a Node process | The service owns CPU, memory, deployment capacity, and failure behavior; that can be the right trade when the source and output stay within the service boundary |
| One REST capability surface with Lanczos | A stable application boundary for passing the generated image to a dedicated upscale stage | Lanczos is the only supported algorithm here, and the service still needs explicit timeouts, retry policy, and result validation |
This comparison is intentionally not a price table. Unit prices change, while ownership of the failure mode survives a pricing-page revision. A managed capability can reduce the code and vendor plumbing the platform team owns; local processing can reduce an external dependency but moves capacity planning and on-call responsibility into the service. Neither choice removes the need for an SLO.
One plain REST API is attractive when the backend already has several capabilities and the team wants the contract to remain stable while the thing behind it moves; no SDK installation is required, so a Node.js service can keep its own client boundary. Infrai fits that slice of the decision because its documented runtime capability is a dedicated Lanczos upscale route, its public discovery surface is self-describing, and its broader surface covers 295 routes across 20 modules under one key. It does not fit a requirement for a selectable upscale algorithm, and it should not be chosen on the assumption that image moderation or every adjacent AI capability is ready: the current caveats include no dedicated moderation endpoint, pending real-time voice support, and an unavailable transcription capability.
What should the SLO measure?
Measure the workflow, not just the HTTP client. I would record generation acceptance, upscale admission, upscale completion, and client delivery as separate counters. A successful HTTP response is not enough if the returned image cannot be saved or streamed, so validate the returned image before marking the catalog item complete.
Capacity planning follows from that sequence. If generation produces a burst of images, the upscale queue needs enough concurrency to clear the burst within the catalog's freshness objective, while its memory limit must account for the largest accepted source image and the high-resolution result. Keep the queue standard at-least-once in your mental model: the consumer must be idempotent even when the same catalog item is delivered twice.
I started by treating enlargement as a cosmetic post-processing detail. That framing was wrong. Once the image is part of a product record, the upscale stage has a durability contract, a retry budget, and a user-visible latency target. The pixel operation may be simple; the production boundary is not.
Top comments (0)