Upscale a Blender render — after you have checked the settings

When you render an animation, the frame size in the output settings is a choice, and so is the resolution percentage beneath it. Rendering below 100 percent is a time-saving habit — half the width and half the height is a quarter of the pixels and roughly a quarter of the render work — and it is entirely sensible while you are iterating on timing, camera moves or lighting. The problem appears at the end. A frame rendered at a reduced percentage was never computed at full size: the renderer evaluated the image on a smaller grid and stopped. Everything above that grid is missing from the file, not merely hidden in it.

That makes a reduced-percentage render a different kind of source from a camera original. In both cases an upscaler is predicting pixels it cannot see, but here the missing information was never generated at all — it was discarded by a setting you can still change. If the project file still opens, the honest fix is to render again at full resolution, and no post-processing beats that. An AI pass is for the renders you cannot redo.

The same logic applies to a deliberately small delivery. If a client asked for a small file, the small thing is the encode, not necessarily the render. Check whether the full-size frames still exist somewhere before paying to guess at detail you already have on a disk.

If you still have the project, a re-render costs wall-clock time and electricity; an upscale pass costs credits for every submitted second regardless of whether the result is usable. For most laptop-scale animations the re-render is the better trade, and it fixes the other things that were wrong at the same time: a noisy low-sample render, motion blur switched off to save time, a heavily compressed preview encode. Re-rendering addresses all of those with real data instead of a model's estimate of it.

Be concrete about what to change. Raise the resolution percentage to full rather than upscaling a partial-size render. Raise the sample count if the frames are noisy — grain is one defect an upscaler handles well, but it is cheaper to render clean than to clean up afterwards. Check the output format too: a quick preview encode is not a master, and re-encoding a compressed preview gives you the worst of both.

Re-render only what needs it. If three shots in a two-minute animation are soft, render those three at full quality and leave the rest alone. A re-render does not have to be all or nothing, and a partial re-render plus a re-edit is still cheaper than a full upscale pass over footage that was fine to begin with.

The natural output for an animation is an image sequence — a folder of numbered frames — and this service does not accept one. It takes a single video file. So the sequence, or the movie file the render wrote directly, has to become one encoded video first: encode at the frames' native size with a high-bitrate codec, and do not let the encoder scale anything. If you scale during the encode you have inserted an interpolation step that the model will then treat as real image data.

Encode once, from the frames, not from an earlier encode. A high-bitrate H.264 file is usually adequate; a lightly compressed intermediate codec is better if you have the disk and the time, because every generation of lossy compression removes detail the model would otherwise have to work from. Keep the file within the upload limit, or host it and paste a public HTTPS URL — a long animation is better split at a cut than compressed harder to fit.

Decide about audio before you encode. The request carries video, model, output tier and billed duration; it does not handle a soundtrack. If the animation has sound mixed elsewhere, keep the audio in that project and re-attach it when the enhanced file comes back. Settle colour and bit depth at encode time as well: a dark, high-contrast render with subtle gradients is exactly the material that shows banding if the encode is careless.

The case that justifies the pass is an animation already delivered: the edit is signed off, the client has the file, the project is gone or the machine that rendered it is gone. Here the goal is to swap the picture and keep everything else. Run the delivered file through the pass, then put the result back where the original lived — same filename, same folder, same duration and frame rate — so anything that references it picks up the new version without being touched.

If the animation still lives in an editor, replace the source clip rather than the timeline instance, so cuts, transitions and effects survive the swap. Match the sequence timebase: a file whose frame rate does not match will be conformed, and conforming can wobble motion that was frame-accurate before. If the enhanced file has a different pixel size, set the sequence's scaling deliberately rather than letting the default crop it.

Keep the original. Store the pre-upscale file next to the new one until someone has watched the whole thing at full size, and note which version went to whom. An upscale changes fine texture everywhere, and a client who approved the old look may notice the new one on a close-up even when nothing is objectively worse.

Three defects respond well. Noise left in a low-sample render: a model can suppress grain while holding edges, which is hard to do with a plain denoise filter. Compression from a cheap delivery encode: blocky gradients and mosquito noise around high-contrast edges are the classic artefacts of a fast encode, and a pass can rebuild plausible texture underneath them. Genuinely small source frames — an animation rendered small on purpose, or an old commission whose only surviving copy is small — are the case where there is no better original to go back to.

A stylised look is the risk. Flat-shaded or painterly animation carries its character in texture that is deliberately not photographic: visible brush work, paper grain, hard cel edges, dithering used as an aesthetic. A model trained to predict photographic detail can smooth those into something cleaner and more generic — the frame looks more modern and less like the thing the artist made. On that material, test one representative shot and compare at full size before committing a whole piece.

Hard edges and fine linework are the second risk. Thin lines can shimmer or thicken, and high-contrast edges can develop halos. If the animation is line-heavy, test across a moving cut rather than on a single still, because artefact that is invisible on one frame often crawls in motion.

Billing is on submitted duration. At the Standard model, 1080p bills 540 credits per minute of source video, which is 32,400 credits an hour, and 10 is the per-second figure behind that. The frame count is irrelevant: the same wall-clock length bills the same whether it was rendered at a low or a high frame rate, and a render that took all night costs exactly what a ten-minute render of the same length would.

That changes how you submit. Cut the animation into the pieces that need the pass and submit those, rather than the whole film. A ten-second shot is a ten-second charge; the other ninety seconds cost nothing if they were fine to begin with. At the Creator yearly rate of $0.0093 per credit, a minute of 1080p Standard work is about $5.01, and an hour about $300.

Compare that with the re-render honestly. If the project still opens and the machine still works, the render is the better spend, because it produces real detail instead of predicted detail. The credit figure matters mainly for the case where re-rendering is impossible. Creator's 106,800 credits cover roughly 197 minutes of 1080p Standard footage, or about 53 minutes at the 4K tier — a useful way to size a restoration job before starting it.