Why a restored photo can be a larger file than the scan
A user observation started this one: the restored download was bigger than the photo they uploaded, which intuitively feels wrong for a “repair.” Measurement found two independent causes — one is the product working as intended, the other was genuine waste we then removed.
Cause 1: the output really carries ~6× the pixels
Restoration includes whole-image enhancement: a typical 821×1024 scan (0.84 megapixels) comes back at 2052×2560 (5.25 megapixels) — 6.25× the pixel count, with real synthesized detail in those pixels, not stretched copies. More information, more bytes. This part is the feature.
Cause 2: browser PNG encoders are 20–40% bloated
The wasteful part: the app originally encoded downloads in the browser with the canvas API's built-in PNG encoder. Compared against a proper optimizing encoder at maximum lossless settings, the canvas encoder produced files 20–40% larger for pixel-identical output. PNG is lossless either way — the extra bytes bought nothing.
The server now encodes the result PNG once at maximum lossless compression, and the client reuses those exact bytes for the download instead of re-encoding through the canvas. The reuse is correct by construction — the downloaded blob is the same one the canvas was painted from, so the pixels cannot differ.
What we deliberately did not do
We did not add lossy output formats to chase a smaller number. A restoration is an archival copy, so the download button hands you PNG and nothing else — there is no free lossless win left to collect in JPEG or WebP. And photos processed in the on-device fallback mode keep the browser encoder — those runs never touch our servers at all.
Practical takeaway
If your restored file is larger than your scan, check its pixel dimensions before assuming waste — at 6× the pixels, a somewhat larger file is the expected result, and a smaller one would mean detail had been thrown away.