Catalogue upscales rarely fail because the model is weak. They fail because someone set the scale factor out of habit, pushed eighty thousand images through, and discovered two days later that the CDN bill had tripled and half the outputs look like watercolour at 100% zoom. Scale is the cheapest decision in the pipeline to get right and the most expensive to get wrong, because every choice is baked into files you then have to store, serve and re-derive for years.
What follows is a practical way to choose between 2x and 4x before you commit a catalogue: how the parameter behaves, how to segment a messy library, and how to run a pilot small enough to stay cheap and large enough to settle the argument with file sizes instead of opinions.
What the Scale Parameter Actually Changes
On a Real-ESRGAN-style endpoint, scale is a per-request field rather than a different model. Y-PAD’s real-esrgan model runs Real-ESRGAN x4plus and documents a scale of 2 or 4, defaulting to 4. Same weights, same BSD-3-Clause licence, same accepted inputs — png, jpeg or webp up to 25 MB — and the same output formats (png by default, or jpeg and webp). The only thing that changes is the enlargement factor applied to the result.
That has a pricing consequence worth internalising early: the fare keys off input megapixels, not output pixels. As of 7 November 2026 the published rate is $0.0010 per image up to 1 MP of input, pro rata above that and capped at 2 MP, with list and launch prices identical. Those are provisional beta fares, so confirm current numbers on the live pricing page before you budget. The practical upshot is that asking for 4x does not cost more per image than asking for 2x on this model — the decision is not a cost question at the API line. It is a storage, delivery and quality question downstream.
Geometry does the rest. A 4x pass multiplies each edge by four, so the pixel count grows sixteenfold; a 2x pass multiplies each edge by two and the pixel count by four. Two catalogues with the same input spend can therefore differ by a factor of four in stored bytes, and that ratio compounds across derivatives, backups and cache fills. A default-output PNG at 4x from a dense source is the heaviest artefact the endpoint can hand you; jpeg or webp is often the sane delivery choice if nothing downstream needs lossless.
Alpha channels deserve their own line. The documentation states that an image with an alpha channel takes a second pass and is charged the same again. For a catalogue of cut-out product shots on transparency, that effectively doubles the per-image fare — and doubles the byte problem, since a 4x transparent PNG is both the heaviest and the most expensive output you can request from this model.
Match the Factor to the Destination, Not to the Model
The common mistake is picking one global factor for the whole library. Catalogues are rarely homogeneous: they mix studio hero shots, partner-supplied JPEGs of unknown provenance, mobile uploads from a marketplace flow, and legacy scans. Each has a different destination, and the destination — not the source — should set the factor.
2x is usually the right default for anything that ends up as a listing tile, thumbnail, search result or email asset. If the source is already a few hundred pixels on the long edge and the display surface caps out around 800–1,200 px, doubling clears the retina threshold at the sizes that matter at a quarter of the output pixels of a 4x pass. Storage stays predictable, derivative pipelines stay fast, and you avoid generating 4x files that your own delivery layer immediately downscales.
4x earns its keep where the image is the product — zoomable detail views, print or packaging proofs, large-format signage, or any surface where a user can pinch in and inspect texture. It is also the sensible arm for genuinely small sources: a 200 px supplier thumbnail destined for an 800 px gallery image needs a 4x pass, because 2x simply does not reach the target size.
The inverse case matters just as much. A 4x pass on a source that already carries plenty of real detail, or on synthetic and heavily recompressed imagery, mostly enlarges the artefacts. Detail does not come from the factor; the factor only decides how much room the artefacts have to spread out. If a sample looks plasticky at 4x under 100% inspection but is indistinguishable at display size, you are paying bytes for something nobody sees.
There is a hard boundary to respect: the documented input ceiling is 2 MP. A modern phone photo at 12 MP is not a job this endpoint accepts, so the 2x-versus-4x conversation only applies inside that envelope — another argument for segmenting rather than looping the entire library through one call and logging the rejects.
Wiring the choice into a pipeline is straightforward, because scale travels with each job. You can route by folder, by measured source dimensions, or by a tag your CMS already stores. The image upscale api page lists the accepted values alongside input limits, output formats and the alpha-pass behaviour, which is the reference to hand to whoever writes the router.
Run the Decision as a Pilot Batch, Not a Meeting
Everything above is theory until you have looked at your own images. The workflow is short: upload files, submit a batch, poll for status (there are no webhooks), download results. Upload links last one hour, outputs stay available for seven days, and a single call takes up to 100 files with up to 2,000 items per batch. Expect a cold start of roughly 10 to 30 seconds, occasionally longer; later items in the same batch ride on that same start, so queue the whole comparison at once rather than trickling it in.
Pick 40 to 60 images that represent your real distribution — the studio shots, the ugly partner exports, the transparent cut-outs, the 220 px orphans. Submit two batches with identical inputs, one at scale 2 and one at scale 4. At the published $0.0010 per image for inputs at 1 MP or under, fifty images per arm is about five cents, so the experiment costs roughly a dime. Re-check that figure against the live pricing page before quoting it to anyone, since beta fares can move.
Billing mechanics favour this kind of trial run. At submit, Y-PAD holds the sum of maximum units multiplied by list price; at settlement only succeeded units are charged, and the unused hold returns. Failed and cancelled items cost nothing. One nuance: because Real-ESRGAN’s list and launch prices are identical, the launch-seat programme does not change the upscaling fare — seats move pricing on the models that carry a list-versus-launch gap, not this one. Budget the upscale line at the flat rate.
Then measure, in this order: the byte-size distribution of each arm, a 100% crop review on a decent display, alpha fidelity on the cut-outs, and whether your delivery pipeline re-encodes to a fixed width anyway — if it does, the 4x arm may be discarded bytes. Also time your own thumbnailing and transcode step, because decoding a sixteenfold-larger image is where surprise latency hides. Once the numbers land, encode the rule as code: source long edge, destination surface, transparency flag, and the chosen scale. Re-run the pilot whenever your supplier mix changes, and read the live pricing page each time before you sign off on a budget line.
