The default instinct with upscaling is that 4x must beat 2x — it's all "make it clearer", so max it out. A few deliveries in, I stopped doing that. The multiplier isn't chosen by "how clear do I want it", it's chosen by what the image does next and what it's made of.
Start with something reproducible. I built an image with text and thin lines, shrank it to different ratios and interpolated back, then measured how much high-frequency structure survived. Shrink to 1/2: about 52% left. Shrink to 1/4: about 20%.
That number isn't about super-resolution quality, it's about the model's workload. A 2x upscale asks it to reconstruct the ~half that's missing; 4x asks it to reconstruct ~80%. The bigger the multiplier, the higher the fraction you're handing the model to guess. More guessing means more brilliance and more failure, at the same time.
So the first test is downstream use. If the image only ever shows at medium size on a web page or slide, 2x is usually enough — the extra resolution can't even display, you just pay compute and wait. Only print, large displays, or zoom-in inspection give 4x's extra pixels somewhere to land.
The second test is subject material, and it's the one people skip. Text, buildings, icons, line art — regular structure — gain clearly at 4x, because their "correct answer" is fairly determined: a straight line should be straight, the model hits it. Faces, hair, fabric, foliage — natural texture — are where 4x shows its seams: the model paints plausible detail the original never had, and at full zoom it reads as fake. ImgIng splits this across its tiers on purpose — fidelity leans to text and lines, the dual-model tier is the one that handles skin and background texture continuously.
The counter, so I'm not overselling 2x: when the subject is small, the original is genuinely low-res, and it does need to be enlarged, 2x can't reach a usable size and 4x earns its place — at the cost of a device that can handle it and a human checking the result. On mobile especially, if the final pixel count exceeds the device's stable ceiling the tool blocks the job outright; that's not a bug, it's crash prevention.
There's a quieter cost too: a 4x result is four times the pixels of 2x, so the file balloons. If the image still has to be compressed and shipped afterwards, you spent compute enlarging it and then bytes transferring it — I've had a 4x export bounced back by front-end for being too big, ending up worse than 2x would've been. So before enlarging, ask whether this image goes straight to use or gets compressed again down the line. The multiplier is a means, not a score.
Top comments (0)