iApp Image Upscaler

Enlarges an image 2× or 4×, up to 16.8 megapixels, reconstructing edges, texture and lettering rather than blurring them.

POST/v3/store/image-generation/image-upscaler/upscaleTry it

Price1 ICper request
Measured196/200
Capacity1,500 images/hour
Served18.4Kcalls

Input

file: product.jpg
scale: 4
output_format: png

OutputPOST /v3/store/image-generation/image-upscaler/upscale

status: success
model: photo
scale: 4
input: width: 800 height: 800
width: 3200
height: 3200
mime_type: image/png
bytes: 9871234
time: model: 0.61 total: 1.42
iapp: images: 1 version: 1.0.0-20260907

Every field, under Response

Request

curl -X POST https://api.iapp.co.th/v3/store/image-generation/image-upscaler/upscale \
  -H "apikey: YOUR_API_KEY" \
  -F "file=@product.jpg" \
  -F "scale=4" \
  -F "output_format=png"

Response

200OK. The fields are explained under Response.

{
  "status": "success",
  "model": "photo",
  "scale": 4,
  "input": { "width": 800, "height": 800 },
  "width": 3200,
  "height": 3200,
  "mime_type": "image/png",
  "bytes": 9871234,
  "image_base64": "iVBORw0KGgoAAAANSUhEUgAADIAAAAyACAIAAAB...",
  "time": { "model": 0.61, "total": 1.42 },
  "iapp": { "images": 1, "version": "1.0.0-20260907" }
}

Request

multipart/form-data, one image per request. 1 IC per image whatever its size or scale; a rejected or failed request is free.

Headers

apikeystringrequired

Your API key, created under API Keys in the control panel.

Body

filefilerequired

The image: JPEG, PNG or WebP, up to 10 MB and 16.8 megapixels. EXIF orientation is applied and transparency preserved. Not needed if image_base64 is sent.

image_base64string

The image as Base64, a data: prefix accepted, in place of file.

scaleinteger

4, the default, or 2. At 4× the input may be up to 1024 × 1024; at 2×, up to 2048 × 2048.

modelstring

photo, the default, for photographs; anime for illustrations and flat artwork; fast when throughput matters more than detail.

output_formatstring

png, the default and lossless, jpeg or webp. A 4096 × 4096 photograph is 10 to 20 MB as PNG and 1 to 3 MB as JPEG at quality 92.

qualityinteger

1 to 100 for jpeg and webp. Default 92.

responsestring

json, the default, returns the object in the panel with the image as Base64; image returns the bytes with the matching Content-Type.

GET /v3/store/image-generation/image-upscaler/models lists the models and limits, free.

Response

The model and scale used, the input size, the output width and height, mime_type, bytes, image_base64, and time: model for the enlargement, total including decoding the upload and encoding the result. Every success carries the headers iapp-input-images: 1 and x-iapp-output-size.

Status codes

Code	`error_code`	Meaning
400	`invalid_image`	Not a readable JPEG, PNG or WebP
400	`input_too_large`	The input is over 16.8 megapixels
400	`output_too_large`	Input × scale would pass 16.8 megapixels; the message gives the largest input for that scale
400	`invalid_scale`, `invalid_model`, `invalid_output_format`	A field outside the values above
413	`file_too_large`	The upload is over 10 MB
503	`starting`	The service is starting; retry after 30 seconds

Details

Measured

On the production service, 28 October 2026, against 200 public reference images (Wikimedia Commons featured pictures, 1,024 px on the longer side), each reduced 4× or 2× and enlarged back with the photo model.

Measure	Bicubic	Upscaler
LPIPS at 4×, lower is closer to the original	0.403	0.221
Images where the upscaler is closer, 4×		196 of 200
LPIPS at 4×, from JPEG input at quality 75	0.531	0.251
LPIPS at 2×	0.196	0.148
PSNR at 4×, higher is better	27.98 dB	26.65 dB

LPIPS is a perceptual distance: it measures how different the result looks from the original, and lower is closer. PSNR rewards the safe blur of a resize, so an upscaler that reconstructs texture scores lower on it by design; judge it on LPIPS and the examples, not on PSNR alone. The gain is largest on compressed web images and smallest at 2× from clean input, where bicubic was the closer of the two for 38 of 200 images. Method, all four conditions and example crops: the benchmark (PDF).

Time, production service, median of 5, JPEG output	Model	Total	Fast model
512 × 512 to 2048 × 2048, 4×	0.26 s	0.28 s	0.05 s
1024 × 1024 to 4096 × 4096, 4×	1.16 s	1.25 s	0.24 s
960 × 540 to 3840 × 2160, 4×	0.57 s	0.61 s	0.11 s
1920 × 1080 to 3840 × 2160, 2×	0.50 s	0.55 s	–
2048 × 2048 to 4096 × 4096, 2×	0.97 s	1.06 s	–

At the largest 4× output that is one image every 1.25 s, about 2,887 an hour; beyond that, requests queue. The fast model is 4× only. PNG, the default, takes longer to encode: in the September 2026 measurement PNG encoding took 1.37 s at 4096 × 4096, for about 1,500 images an hour, and the illustration model took 0.32 s at that size. Through the public API from Bangkok, a 4× request with a 1,024-pixel output took 0.51 s at the median, upload and download included.

Limits

Rate limits per key: 5 per second, 60 per minute, 1,200 per hour.
Fine detail absent from the source is invented, not recovered: a face or small text at 40 pixels comes out sharp but not necessarily true, so the output is not evidence of what a low-resolution source showed.
Compression and blur in the source are cleaned up; motion blur and out-of-focus areas stay soft.

Data handling

Images are processed in memory and returned in the response; nothing is written to disk or kept. The model runs on iApp's own GPUs in Thailand, and no image goes to a third party. Consent and notice under PDPA and GDPR remain with you as the data controller.

Changelog

Version	Date	Changes
v1.0.0-20260907	7 Sep 2026	First release: 2× and 4× with the photo, illustration and fast models, PNG, JPEG and WebP output up to 16.8 megapixels with transparency preserved, at 1 IC per image.

Request​

Response​

Details​

Request

Response

Details