- Eye versus camera: The eye integrates light continuously; a camera samples it in short exposures, exposing artefacts
- The chain: Refresh, frame rate and the control system sit in a chain, and the weakest link is what the camera records
- Dimming trigger: Dimming changes how LEDs are modulated, so artefacts can appear only at lower brightness
- Rolling shutter: Phone and broadcast cameras with rolling shutters are the usual revealers of banding
- Prove it: Only a test with your real cameras and settings proves a configuration, not a headline figure
- Whole chain: Refresh behaviour is a property of panel, control, content and camera together
Why cameras see problems the eye does not
A display can look perfectly stable to everyone in the room and still produce dark bands, flicker or a washed-out frame the moment a camera is pointed at it. The reason is that the eye integrates light continuously, while a camera samples it in short exposures. Anything that varies within a single exposure becomes visible as an artefact.
That matters for broadcast studios, event filming, retail content that visitors record on phones, and any installation where the screen is expected to appear in marketing footage. Once the display will be captured, refresh behaviour stops being a footnote on a datasheet and becomes a genuine buying criterion.
What refresh rate actually describes
Refresh rate describes how often the driving electronics update the image on the panel. It is not the frame rate of the content, and it is not the capability of the control system or the media player feeding the screen. Those three sit in a chain, and the weakest link is what the camera records.
Because of that chain, a headline figure tells you very little on its own. The useful questions are how the panel drives its LEDs, how the control system handles the incoming signal, and whether the whole chain has been demonstrated together under the conditions your project will actually use.
Where flicker and banding come from
Most visible artefacts come from a mismatch between how the screen emits light over time and how the camera samples it. A rolling shutter, a fast shutter speed, a dimmed panel and a mismatched frame rate can each produce moving bands, dark stripes or brightness steps between parts of the image.
Dimming is a common trigger. When a panel is dimmed, the way it modulates its LEDs changes, so artefacts that are invisible at full output can appear at the level the room actually needs. This is why a demonstration at maximum brightness does not answer the question.
How to evaluate a display before you buy
Test with the real equipment. Bring the cameras, lenses and settings the project will use, including phone cameras if visitors or staff will record the screen. Shoot at the shutter speeds and frame rates that matter, at the brightness the room requires, and review the footage on a large monitor instead of on the camera screen.
Test dimmed as well as at full output, and test the content you actually intend to run. Fast motion, large areas of flat colour, small text and high-contrast graphics each stress the panel differently, and a clip that looks fine on one may fail on another.
Repeat the test after any change to the control system, the player or the signal path. A change in one link can reintroduce a problem that a previous configuration had already solved.
What to put in the written specification
Write down the operating brightness range, the cameras and shutter settings the display must tolerate, the frame rates it must accept, and who carries responsibility if artefacts appear after installation. A specification that only names a refresh rate figure leaves every one of those questions open.
Confirm what happens if content, control hardware or firmware changes later. Refresh behaviour is a property of the whole chain, so the document should name the configuration that was demonstrated instead of a single component.
| Test element | Why it matters | How to do it |
|---|---|---|
| Real cameras | Phone and broadcast shutters differ | Bring the actual devices the project will use |
| Operating brightness | Dimming can trigger artefacts | Shoot at the level the room needs, not peak output |
| Real content | Motion and flat colour stress the panel | Use your run loop, not a demo clip |
| After any change | A link change can reintroduce faults | Re-test on control, player or firmware changes |
Clean at full, broken when dimmed
A wall looked fine at full brightness but flickered on camera once dimmed for the room. Testing only at full brightness missed the failure the client actually saw.
A phone exposed the banding
A supplier demoed with a broadcast camera that hid banding. The client's phone showed it clearly; writing the phone into the test caught what the demo hid.
Steps for a project: refresh rate and camera flicker
- Treat refresh as a chain property Refresh behaviour depends on panel, control system, content and camera together. Judge it as a whole, not a single number on a sheet.
- Test at the real brightness Flicker and banding appear when the wall is dimmed, not at full brightness. Evaluate at the level the room will actually use.
- Use the real cameras Test with the cameras the project will actually use, including phones if those shoot the screen. A demo on a different camera hides the problem.
- Write the requirement into the quote State the acceptable behaviour with the actual cameras and brightness in the specification, so suppliers are measured against your conditions.
Misconceptions about refresh rate and camera flicker
“A higher refresh rate always removes flicker.” — Refresh interacts with control, content and camera. A high number on paper still flickers if the rest of the chain is not matched to the real conditions.
“Refresh rate is the same as frame rate.” — Refresh is how often the panel repaints internally; frame rate is the source's playback speed. They are different links in the same chain and must be judged together.
A short verification list for refresh rate and camera flicker
- List the cameras, lenses and shutter settings the wall must tolerate
- Test at the operating brightness, not only at full output
- Test with the real content you intend to run
- Require the demonstrated configuration named in writing
- Re-test after any change to control hardware, player or firmware
- Decide who carries responsibility if artefacts appear after install
A note for the supplier: refresh rate and camera flicker
Treat refresh behaviour as a property of the whole chain: panel, control system, content and camera. Test it at the brightness the room will actually use, with the cameras the project will actually use, and have the demonstrated configuration named in writing. If you are planning a capture-heavy installation, share your camera list and room conditions on the contact page before you commit to a specification.