LCD/OLED Manufacturers: Cheap way to add 960Hz

Advanced display talk, display hackers, advanced game programmers, scientists, display researchers, display manufacturers, vision researchers & Advanced Display Articles on Blur Busters. The masters on Blur Busters.
Post Reply
User avatar
Chief Blur Buster
Site Admin
Posts: 7518
Joined: 05 Dec 2013, 15:44
Location: Toronto, Ontario, Canada

LCD/OLED Manufacturers: Cheap way to add 960Hz

Post by Chief Blur Buster » 28 Jan 2018, 19:31

My weblogs in this Area51 forum indicates fairly frequent visits from display manufacturers and some panel manufacturers:

Manufacturers, please read Blur Busters Law: The Amazing Journey To Future 1000Hz Displays to understand why BFI is a dead end techology (in a couple decade). This is because real life doesn't flicker/BFI/strobe. Low-persistence via blur-free sample and hold is better for real-life. Fully flickerfree low-persistence sample-and-hold (via ultra-high-Hz) should eventually become the new norm for display motion blur reduction for full-framerate HFR sources.

On the topic of cheaply adding 1000Hz to future OLEDs in the next ten years, I suggest additional scanout channels.


OLED pixels (And LCD pixels, too) needs a certain amount of time to send sufficient voltage to switch the pixels. If we didn't, then too brief a time is sent per line to create a good quality image. So a slower scanout helps to spend more time transmitting pixel voltage, maximizing OLED quality.

It's possible to do high-Hz via contiguous rows of pixels (scan faster), or even scan multiple pixel rows at a time (in contiguous blocks). But sometimes due to panel design, it just isn't possible without artifacts.

It also depending on how much current you can send down the grid of microwires, and how much crosstalk you can avoid switching those pixel-switching transistors (active matrix = transitors) behind each pixel.

So, one method of spending more time sending voltage to each pixel is multiple scanout channels. Imagine a theoretical CRT with multiple electron guns, doing chasing-scans after each other.

Each concurrent screen-height top-to-bottom scanout channel is assigned its own full unique frame (so it's different from multi-scanning that LED jumbotrons uses).

This is largely different from treating it like 8 separate thin-slice monitors (multimonitor approach) since the top-to-bottom scan is temporally contiguous with its own full uninterrupted refresh cycle as a unique frame in 960Hz (or 1000Hz).

Top to bottom scan is still 1/120sec, but there's 8 concurrent scans rolling all the way down from top-to-bottom in an uninterrupted pass. Each pixel is temporally refreshed 960Hz (or 1000Hz) at exact temporal intervals.

The OLED panel and substrate can be largely unmodified except for adding scanout channels (modified edge connections) + a much more powerful TCON + higher bandwidth processing on monitor motherboard.

The 8-channel approach for achieving 8x refresh rate on a 120Hz OLED:

  • True 960Hz or 1000Hz refresh rate
  • 1ms persistence, with no BFI, and no light loss
  • HDR + low persistence at same time!
  • Same voltage time on transistor gates on each pixel, as a 120Hz scanout
  • More realistic 120Hz scanout velocity
  • No sawtooth tearing artifacts during pans (like with traditional multi-scanning)
  • Large distance between scanouts
    easier to reduce voltage crosstalk, easier to engineer panel mods/partitioning
  • Scanout input lag of 120Hz (but that's still low!).
  • Need to add extra scanout channels to a panel
  • More powerful processing needed (TCON, motherboard, etc).
Note: If you're already using multiple concurrent channels (e.g. 2 channels) to achieve 120Hz refresh rate (via refreshing two contiguous rows simultaneously) instead of 60Hz, then you need 16 concurrent scanout channels instead of 8 channels. The number of concurrent scanout channels needs to proportionally go up for same per-pixel driving time for proportionally higher higher Hz.

But What If Voltage Crosstalk Won't Fully Disappear!

Potential voltage crosstalk may occur for simultaneous scanout channels. Such as 4 bright white pixels and 4 grey pixels, the white pixels may cause a darkened vertical streak on the grey pixels (that are being concurrently refreshed). To fix this type of streaking issue, one can use a crosstalk compensation algorithm (similar to overdrive/underdrive), to eliminate the vertical-lines artifact caused by voltage crosstalk caused by simultaneous-pixel-refresh techniques.

Basically, microwires are not zero resistance, and Ohm's Law may mean some pixels in other scans may darken/brighten depending on how much current is being used to drive during the other concurrent scanout channels (since vertical-grid microwires will be shared among all channels). The low-resistance pixels (bright pixels) will steal power from the high-resistance pixels (dark pixels). This may create the vertical-lines streak issue. Other issues may be crosstalk between adjacent conductors (greatly lessened with distance between concurrent scanout channels)

This is not altogether dissimilar to the vertical streak artifact problems of old passive matrix displays. Active matrixes tend to be mostly immune to this -- until you try to do concurrent scanouts -- whereupon this sort of problem can reappear even with active matrixes.

To fix the vertical-lines streak effect of crosstalk caused by simultaneous-drive techniques, one might theoretically need use a crosstalk-optimized overdrive/underdrive algorithm -- to fix this. One may need to use an FPGA to pull this off at 960Hz, but it's not impossible. Essentially it's just simple realtime calculations of Ohm's Law (per pixel) based on known microwire resistance (for a specific X,Y pixel co-ordinate) and the known electrical resistances of black through white -- by algorithmically compensating for crosstalk, you can disappear the crosstalk of simultaneous-pixel-drive.

Max nits of simultaneous white pixels will also be dependant on the current-carrying capacity of shared microwires that trigger the pixel transitions, so your maximum nits may be influenced by the vertical-lines crosstalk reducing algorithms.

Depending on the current carrying capacity of the shared pixel transition controlling microwires, and the design of the OLED technology, this might reduce dynamic brightness range of 1000Hz by a few percent (e.g. 3% or 5% guesstimate) compared to 120Hz, but this is far less than the dynamic range reductions of BFI-based blur reduction (e.g. 80% - 90% nit loss) for the same 8:1 extent of blur reduction. If the vertical microwires are engineered with sufficient current-carrying capacity, then no brightness reductions for 960Hz (one-eighth the motion blur) will occur relative to standard 120Hz. Your crosstalk-compensating algorithm will need to be capped at this nits, to eliminate crosstalk for all possible pixel voltage combinations of all simultaneous scanout channels.

Also, BFI can remain an option (as a separate mode), with this additional high-Hz blur reduction mode (using either a high-Hz source, high-Hz HFR, or high-Hz interpolation), depending on user preference.

Algorithm is free for any manufacturer to use

If any manufacturer wishes to run with this (even if just 4-channels to achieve 480Hz on 120Hz OLEDs), in order to dramatically lower the cost of ultra-high-Hz OLED refresh rates, I release this Hz-raising technique at no extra charge, Creative Commons by SA 3.0, credit Mark Rejhon of Blur Busters.

(I do low-persistence advice consulting work, and related work, as I have already been. I have had contracts with display manufacturers to educate them about low-persistence. I also understand overdrive algorithms. However, I have also given a lot of advice for free because of my eager interest in pushing the art of lowering display persistence, also as a personal goal.)

Need Help?

For any more advanced stuff, or other consulting work, if you need low persistence ideas, education, algorithms and advice, I am available at mark[at] ...

I also was the world's first person to open-source a 3:2 pulldown deinterlacing algorithm (back in 1999 to 2000) for a program called "dScaler" almost twenty years ago. With this, I successfully worked with an assembly language developer to help them implement my algorithm to successfully deinterlace NTSC (480i 60Hz) to extract the original 480p 24Hz movie frames and display them in a time-sequential manner (e.g. 72Hz). I often help develop algoirthmic techniques, and I help a low-level programmer (assembly, FPGA) implement it for real. I also may have references to other FPGA programmers.

While I don't do FPGA programming myself, I do work with other FPGA programmers (or GPU programmer, or ASIC designer) implement algorithms. We're different nuts and bolts in the display improvement chain. Metaphorically, the people who make rocket nozzles and fuel piping don't necessarily understand the ARM assembly language that goes into a rocket-engine control unit. Similarly, I have educated many display engineers on low-persistence and the art of reducing display motion blur, even though I don't know FPGA programming or chip design or panel substrate design. I can provide time-saving algorithm advice that can battle ghosts, crosstalk, other problems associated with attempts to lower display persistence.

Today, I invent motion tests for Blur Busters, and have a peer reviewed conference paper on a display-testing technique. I also develop motion tests that turn a complex blur-reduction strobe-backlight calibration job into a much simpler single-afternoon "Strobe Phase, Strobe Length, Vertical Total" work session (Crosstalk FAQ). And lots of other time-saver custom motion tests.
Head of Blur Busters - | | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

Post Reply