Combining variable refresh rate and strobed backlight

From Display-Corner
Jump to navigation Jump to search

What is this about?

Variable refresh rate technologies like NVIDIA's G-Sync and AMD's FreeSync are on the market for quite some time now, as are motion blur reduction techniques like 2D Lightboost (NVIDIA), MBR (Benq), ULMB (NVIDIA), Motion 240 (LG), etc., which are all using strobed backlight that is synchronized to the refresh rate. Nevertheless, it is still not possible to use variable refresh rates with motion blur reduction techniques simultaneously. So far, it is either one or the other.

The problem is obvious. How to control the energy of the backlight strobe so that the average luminance does not change with the variable refresh rate, especially without knowing in advance how long it will take for the next frame to arrive?

What has been suggested already?

In October 2013, Mark Rejhon from www.blurbusters.com suggested a method that works by modulating the strobe energy (strobe luminance and/or duration) according to the duration of the previous refresh cycle (Strobing on variable refresh displays). He also suggested a way of reducing the perceived flicker at lower refresh rates by going gradually from strobed to steady-state backlight as refresh rates drop.

At the same time, NVIDIA applied for a patent (US 2015/0109286 A1, System, method, and computer program method for combining low motion blur and variable refresh rate in a display) which covers many possibilities of how the backlight should or can be controlled in order to achieve the goal of having a constant average backlight luminance. The patent includes Mark's suggestion regarding strobe energy calculation, but whether it also covers the method described below is not so clear. Even if it is, the relevant claim might be too unspecific to be authoritative, meaning the method described below would not be covered by the patent and, therefore, could be used for free.

How does it work?

The method described here is much simpler than what has been suggested already. This is because the method uses strobes of constant energy and keeps the strobe timing fixed with respect to the panel update. If the variable refresh rate is any lower than the maximum refresh rate, refresh cycles are prolonged by additional time gaps. During these time gaps the backlight is simply set to the average luminance of the maximum refresh rate case. This way the overall average luminance stays the same irrespective of the duration of the additional gaps. There is no complicated procedure necessary for estimating the refresh rate or for defining the time when and for how long the backlight has to be switched to which luminance level. When thinking about the order of events within a refresh cycle, most people – possibly knowing how CRTs work – would probably place the strobe first, followed by the "dark phase" during which the backlight is switched off completely, possibly followed by a time gap prolonging the refresh cycle due to a low refresh rate. But for understanding the implementation of the described method, it is more appropriate to actually place the dark phase first in a refresh cycle, followed by the strobe and possibly followed by an additional gap.

CombineVarRefresh+Strobe.png


The figure shows an example of a frame sequence. When, or shortly after, the monitor receives the first pixel of a new frame, the backlight is switched off for a while, until the strobe is flashed. The dark phase allows the pixels to be updated in the dark, plus some time for the pixels to settle to their new values before the strobe comes. So far, this is not any different from the standard motion blur reduction techniques. Even if the frame rate drops below its maximum, nothing changes regarding this dark phase timing, the strobe timing, and the strobe energy. After the strobe, however, the backlight is not switched off but is switched to a lower level until the next dark phase begins (see frames 4 and 5). This lower level is set to the average luminance of the dark phase and the strobe, that is, to the average luminance for the maximum frame rate case, as adumbrated in the figure by the dashed brownish rectangle following frame 2.

What are the upsides?

Leaving the parameters for the dark phases and strobes unchanged for all frame rates allows keeping things simple:

  • No look-ahead is needed which would add input lag.
  • No varying luminance levels are required for maintaining a constant average luminance.
  • No frame-by-frame adjustment of overdrive to different strobe parameters is necessary.
  • No on-the-fly calculations or statistics have to be performed in order to find the strobe parameters.

What are the downsides?

The downsides are minor and, presumably, of little practical relevance.

Adding a low luminance phase goes somewhat against the motion blur reduction idea, but for moderate frame rate changes, the effect is expected to be negligible. And for substantially lower frame rates, having the luminous energy spread a little bit wider across time might even be desirable for avoiding perceived flicker. Moreover, it might actually be disturbing (i.e. causing eye strain) if the strobe energies vary over time, especially if these energies are kind of misattributed to the wrong frames. Such misattribution would be a consequence of calculating the strobe energies based on previous refresh cycles, in an attempt of avoiding the need for looking ahead, which, in turn, would cause additional input lag.

Regarding input lag, the suggested method does not allow for trading input lag with cross-talk to an extent that is otherwise possible with standard motion blur reduction implementations. This is because the dark phase preceding the strobe for frame N cannot start before reception of frame N (i.e., not before VSync at the beginning of frame N). In the maximum refresh case, for example, this basically means that VSync has to occur during the strobe. Luckily, this is how the timing for the strobe would normally be chosen anyway in order to hide the panel update for the new frame while, at the same time, balancing the crosstalk artifacts between the top and the bottom of the screen.

How to implement it?

The LED driver must allow for being switched quickly between three luminance levels (mediated by different LED currents): high, low, and off. Normally, also current motion blur reduction implementations require the LED driver to be switched between three luminance levels, because the LED luminance in a steady-state picture mode cannot be as high as in the strobed mode. But normally this switching does not occur at frequencies as high as the refresh rates, so the LED driver might require some modifications to keep up with higher frequencies.

Controlling the backlight timing is straight forward and only requires VSync as a timing reference signal. Having the backlight control implemented in the scaler, although not necessary, is desirable because it allows making the parameters accessible through the standard OSD.