Native resolution versus content resolution
A wall has a native resolution set by its pixel pitch and size: so many physical pixels across and down. Content has its own resolution, and the two are rarely identical.
When content resolution differs from the wall, the controller scales it, which can soften detail or introduce artefacts if the mismatch is large. Matching source to panel keeps the image crisp.
Thinking in physical pixels, not screen size, avoids the common mistake of building content for a generic rectangle and wondering why it looks soft on a specific wall.
Scaling and where it happens
Scaling happens in the sending and receiving hardware that drives the panels. Good scaling preserves detail and aspect ratio; poor scaling stretches or blurs the image.
Content built at the wall's exact pixel count needs no scaling and looks best. Content built close to it scales cleanly; content built far from it loses more with every step away.
Agree the target resolution with the operator who authors content, because the benefit of a sharp wall is lost if the source is prepared at the wrong size.
Aspect ratio and cropping
Walls are not all the same shape. A square-ish wall and a long banner need different content frames, and forcing one into the other crops or letterboxes the image.
Plan content per wall shape and avoid reusing one master blindly. A clip that fits a wide wall may crop key text on a near-square one, or leave bars that look unfinished.
Keep a library of correctly sized masters per wall type. The small effort up front prevents a launch where every piece of content needs last-minute rework.
Pixel pitch and perceived detail
Finer pitch packs more physical pixels into the same area, so it shows more content detail at close range. Coarser pitch shows less, which is fine when viewers stand far back.
Resolution planning and pitch planning are the same decision seen from two sides. Specifying pitch without the content detail, or content without the pitch, leaves one of them wrong.
Match the two to the closest viewer. A fine-pitch wall fed low-resolution content wastes its capability; a coarse wall fed ultra-high-resolution content gains nothing visible.
Acceptance and the source check
During acceptance, show the real content, not a test pattern, and confirm it reads correctly at the intended size and distance. That is the true resolution test.
Agree the content spec before build so authors deliver at the right pixel count. A wall accepted on a demo reel and then fed mismatched content will disappoint in use.
Record the target resolution with the project file so future content stays sharp and the wall's capability is used as designed.
Revisit the source spec whenever the wall is repurposed, because content built for one shape or pitch can look soft when moved to another, and the limit travels with the asset.
A 4K master on a low-pixel wall
Content built at 4K was shown on a wall with far fewer native pixels. The extra detail was lost and scaling softened the text edges.
An aspect mismatch that cropped faces
A square wall received 16:9 content; the processor cropped the sides and cut off people's faces in the key frame.
A workable order of work: content resolution and scaling
- Build masters at the wall's native pixel size Author content at the resolution the wall actually shows, per shape, so the detail is used as intended and nothing is wasted to scaling.
- Avoid large scaling mismatches If source and native differ a lot, plan scaling at the processor, not by hoping the wall absorbs the difference.
- Confirm with real content at acceptance Play the actual content on the wall and check legibility and cropping before sign-off, because a render can hide a real mismatch.
Frequent errors in content resolution and scaling
“The wall will sharpen any content.” — A wall shows its native pixels. Content far above that resolution loses detail to scaling, and content far below looks soft.
“Aspect ratio is just a black-bar issue.” — A mismatch can crop the image and cut off important content, not merely add bars. Confirm the shape before authoring.