Low resolution images in video: fix the source art, not the export
Quick answer
Low resolution images in video are source files that carry fewer pixels than the frame they land in, so they look soft or blocky in an otherwise sharp export. Raising the bitrate does not help, because the render is faithfully reproducing small artwork. The fix belongs to the source image.
Why do low resolution images in video survive a clean export?
A render engine scales what it is given. Hand it a 640 pixel wide logo and ask it to fill a 1920 pixel frame, and it will do exactly that, honestly and at full quality. The result is a crisp video of a blurry picture.
This is why the export dialog is the wrong place to look. Codec, bitrate, and container all describe how faithfully the render is preserved. None of them add information that was never in the file.
The confusion is understandable, because every other quality complaint in video does get solved downstream. Audio levels, colour, captions, aspect ratio. Resolution is the one that has to be solved before anything is built.
Where do low resolution images in a deck come from?
A slide deck is the most common carrier. Images arrive in a deck by being pasted, dragged from a browser, or screenshotted from another document, and every one of those paths quietly resamples the picture down to something that looked fine at slide size.
Nobody notices, because a deck is viewed at slide size. The picture only fails once it is asked to be a video frame.
Our own solutions team ran into this recently on a customer build. The images embedded in the customer's PowerPoint came in below 1080p, and the finished video looked fuzzy on exec facing slides no matter what the pipeline did with it.
How do you tell a source problem from an export problem?
Look at one frame at full size and ask which elements are soft. This table covers the split.
| What you see | Likely cause | Where the fix lives |
|---|---|---|
| One image soft, text and motion sharp | That source file is below frame resolution | Replace or upscale the source art |
| Everything soft, evenly | Export or delivery settings | Render and encode settings |
| Soft only after a platform upload | Platform recompression | Delivery spec for that platform |
| Sharp at 16x9, soft at 9x16 | Crop is enlarging a region of the source | Source resolution, or reframe at capture |
| Soft on motion only | Frame rate or shutter, not resolution | Capture settings |
The first row is the one that gets misdiagnosed most often, because it presents as a video problem and is an artwork problem. The fourth row is worth flagging separately, since a vertical crop enlarges whatever it keeps, which means a source that passed at 16x9 can fail the moment you build resizes from the master.
What does an AI upscale actually fix?
An upscale model invents plausible pixels. That is a real limitation and worth being honest about, because an upscaled photograph of a product is a reconstruction rather than a record of the product.
For the case that keeps appearing, it is the right trade. Customer supplied slide art, already compressed, already small, needed at frame size, where the alternative is asking the customer to find the original file that nobody has. On the build above, an image upscale script rescued the slides for under two dollars.
Where I would not reach for it is anything carrying a legal or factual burden. A chart, a regulatory mark, a screenshot of a real interface. Those need the original asset, because an invented pixel in a chart is an invented number.
Who should own image resolution before a video build starts?
Put it in the intake step, next to the other things you already check. A brief that asks for scripts, brand files, and a deadline can also ask for source images at frame resolution or better, and the person who asks is whoever owns intake.
This is the same argument as treating static assets as a video production input rather than as decoration. The moment a still picture becomes a frame, it inherits the frame's requirements.
When you are turning a deck into video on a regular cadence, the check is worth automating: read the embedded image dimensions out of the file at upload and flag anything under frame height before a single scene gets built.
A worked example
A solutions team receives a twenty slide customer deck on a Tuesday for a Friday delivery. Six slides carry screenshots and product photography. Under the old process, the build runs, the review call happens Thursday, and someone says the video looks cheap.
Under the new process, a script reads the embedded image dimensions on Tuesday afternoon and returns six files under 1080p. Four get replaced by the customer within a day because they still have the originals. Two get upscaled, for a couple of dollars, and the build starts Wednesday morning with nothing soft in it.
FAQ
What are low resolution images in video?
They are source files with fewer pixels than the video frame they are placed into, so the render enlarges them and they appear soft or blocky while the rest of the frame stays sharp.
Will a higher bitrate fix a blurry image in a video?
No. Bitrate controls how much of the render is preserved during encoding. It cannot add detail that was missing from the source file before the render started.
What resolution do images need to be for 1080p video?
At least 1920 by 1080 for a full frame image. Anything that will be cropped, panned across, or scaled up during the edit needs more, because those moves enlarge a region rather than the whole picture.
Is AI upscaling good enough for a customer facing video?
For photography and illustration in a slide build, usually yes, and it is inexpensive. For charts, regulatory marks, and interface screenshots, no, because an upscale model invents detail and an invented number is a factual error.