Zisworks open-source firmwares & strobe backlight tweaking

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: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Zisworks open-source firmwares & strobe backlight tweaking

Post by Chief Blur Buster » 09 Sep 2017, 19:20

Open Source Firmware for Display Motion Blur Reduction

This post is targetted to open-source display firmware programmers that are programming generic motion blur reduction similiar to ULMB" / "LightBoost", programmed completely from scratch by Zisworks. It is important to note, none of this firmware includes any of the patented strobe-optimized LCD overdrive algorithms. This will require other kinds of tweaks, such as Large Vertical Totals (large VBI output from GPU) to help assist in higher-quality full-screen strobing via "cram-LCD-GtG-into-VBI" approaches.

Image

People are already tweaking backlight firmwares for strobing already (see ZIswork's "Making Of" and example HardForum thread that also contains an older version of this post which is now crossposted here, relevant for strobe-backlight tweakers. There is now open-source motion-blur-reduction firmware available (http://www.zisworks.com/shop ...) which we tested -- see 4K120 display with bonus low-rez 240Hz and 480Hz modes.

Blur Busters used to be named www.scanningbacklight.com in year 2012, and we originally got its start due to scanning backlight research (published at blurbusters.com/faq/creating-strobe-backlight ... this early research (which got shelved/delayed when LightBoost was discovered as a mass-market alternative) helped Zisworks create his a 4K120 strobed display ahead of manufacturers.

If you're tweaking the source code of a motion-blur-reduction backlight to have extra adjustable features:

You'll want to become familiar with:
1. High speed video of a typical strobe backlight
2. Strobe Crosstalk and its causes
3. HOWTO: Creating a strobe backlight for LCD motion blur reduction
4. TestUFO Crosstalk Motion Test (for testing strobe backlights)

This post is useful for
-- Writing your own firmware from scratch (separately of Zisworks); or
-- Wanting to enhance the open-source firmware code for Zisworks backlight controller; or
-- Figuring out how to handle multi-segment edgelight that can be used in scanning-backlight (scanning-edgelight) mode:

You'll want multiple adjustments:
-- Scanning versus full-strobe mode (there are pros/cons, so you should support both)
-- Strobe phase adjust / Scanning begin phase adjust (first segment flash at top, timing relative to VSYNC pulse)
-- Strobe flash length adjust / Scanning flash length adjust (how long each is pulsed)
-- Scanning velocity adjust (how fast the scanning backlight is pulsed top to bottom, can be different velocity than LCD scanout).

Strobe phase ajdustment
For Scanning backlights, phase relative to VSYNC when first segment begins to flash
For Strobe backlights, phase relative to VSYNC for global flash

Usually you want the start phase to be roughly 180 degrees to the GtG midpoint of LCD scanout. This is where you get the point of minimum strobe crosstalk with a scanning backlight. This won't be exactly 180 degree phase relative to the LCD scan pulse, since the GtG (pixel response) is "lagged" relative to that. So you'd probably want to eyeball the adjustment while viewing the "TestUFO crosstalk" test. You'd adjust until the minimum strobe crosstalk occured. A common temptation by homebrew is to try to math-calculate the strobe phase relative to VSYNC, when it's actually best to eyeball the adjustment with a realtime phase adjustment while watching horizontally panning motion. You can see the GtG double-image (or in your case, quadruple-image/octuple-image zone) zones shift in-and-out of visibility as you adjust phase. Often LCD GtG behaves in totally unexpected ways, e.g. most of the GtG occurs at the beginning of GtG, but certain color pairs might be extremely slow/bad (e.g. VA panel dark greys) which might force a little biasing in your strobe phase to try to compensate for reducing the strobe-crosstalk-visibility of some of these very-bad colors.
Calibration of phase is easy using a slider to adjust this in realtime while staring at http://www.testufo.com/crosstalk
Strobe mode: "crosstalk double-image band" to move up/down in TestUFO. If you have a very large VBI, you can hide most of this crosstalk band offscreen between refresh cycles.
Scanning mode: "global crosstalk" globally fades in/out (But never fades completely)


Real Time Manual Adjustment is the fastest & easiest homebrew method of calibrating high quality strobing
Back in 2013, we created a utility for BenQ/Zowie monitors at http://www.blurbusters.com/strobe-utility and it has been found that this is a very easy way to manually optimize the quality of motion blur reduction strobing/scanning. Adjusting is easy using a slider to adjust this in realtime while staring at http://www.testufo.com/crosstalk ... However, this adjustment principle is quite generic, and out-sources the difficulty to advanced end users -- it can be time-consuming for the creator of a monitor (whether homebrew or monitor manufacturer) to create a very high-quality pre-calibrated strobe backlight.
Tip: Ideal strobe phase is very dependant on monitor processing lag & GtG lag & signal timings (especially size of sync interval -- i.e. Using a Custom Resolution Utility with Large Vertical Totals can reduce strobe crosstalk). One may be tempted to simply mathematically automatically calculate strobe phase based on lag/GtG guesswork. But better quality results occur with manual calibration via eye via a test pattern (which is surprisingly quick & easy, once familiar). With the creation of an appropriate compatible "Strobe Calibration Utility", much better results can be achieved fairly quickly once you are familiar with the Strobe Crosstalk motion test.

Flash length ajdustment
For Scanning backlights, flash per segment (can diverge from flash sequencing speed)
For Strobe backlights, length of whole flash

This is a brightness-versus-blurring tradeoff. The longer the flash length, the brighter -- but more motion blur. Also, you may want the flashes of the next scanning backlight segment to overlap from the previous flash, or not -- depending on the multi-image strobe crosstalk effect caused by the backlight diffusion (light from ON segments diffusing into the OFF segments). Strobe crosstalk looks different (worse, better). At short flashes, a segment will turn off long before the next segment illuminates. At longer flashes, segment illumination will overlap. This is acceptable, and these have pros/cons from a strobe-crosstalk appearance perspective. So an adjustment is favourable.
--> Strobe mode: "crosstalk double-image band" will thicken with longer strobe flashes, motion (especially faster, 1920pps) becomes blurrier, screen becomes brighter. You have a brightness-versus-motion-clarity tradeoff.
--> Scanning mode: Same, except "global crosstalk" globally fades in/out (But never fades completely), assuming scanning is in sync with LCD scanout. Low-granularity of scanning backlight/edgelight (e.g. only 4 segments) will show as "soft-tearing" artifacts during fast horizontal motion, that sometimes looks herringbone-gapped during fast motion when strobe length is shorter than sequencing time (the scanning flash-by-flash sequencing). -- very hard to explain except staring at motion test.


Scanning velocity adjustment
Logically, you may want to scan synchronously with the LCD scanout. However, visually, this isn't always ideal all the time, depending on LCD GtG factors + backlight diffusion factors. From a strobe crosstalk perspective, if you use large blanking intervals (long pauses between fast LCD scanouts), global flash backlights have a big advantage over scanning backlights -- you don't have to worry about backlight diffusion between OFF segments and ON segments -- which creates amplified strobe crosstalk artifacts. However, if you do a tradeoff between a full-strobe (infinite scan velocity) and a sequential scan (scan synchronously with LCD scanout), you can actually balance the pros/cons of global-strobe strobe crosstalk versus the pros/cons of sequential-scanning-backlight strobe crosstalk (the crosstalk artifacts look extremely different).

Scanning versus strobe mode
Without testing it out, it is hard to say whether the strobe crosstalk of global-strobe is better/worse than the strobe crosstalk of a sequential-scan. But as a general rule of thumb, if you can achieve better than 100:1 contrast ratio [usually not possible with edgelight, without FALD array] between the OFF versus ON segments, then a synchronous sequential scanning backlight is usually easier. Thus, it's good for a homebrew strobe backlight to have a scanning mode versus strobe mode, since the crosstalk apperance may be preferable in one mode or other. Also, if it is a panel that does not support large vertical totals (accelerated scanout + long pause between scanouts), then it's more likely strobe crosstalk artifacts are more preferable in scanning mode than strobe mode.

Strobe crosstalk appearance of global strobe
Pictures are available at http://www.blurbusters.com/crosstalk
Usually very clear in one screen part, and very ugly double-image effects in another screen part. Getting better overdrive, speeding up pixel response, and squeezing pixel response into the VBI, and using a Custom Resolution Utility to use large VBI (e.g. Vertical Total VT1500 or VT2000 is extremely favourable for 1080p) -- for example, the Zisworks display supports over VT2200 for 1080p120Hz, using 240Hz scanout velocity with 120 refresh cycles -- 4.1ms scanout and 4.1ms VBI. That makes it easy to squeeze the 1ms TN GtG in the VBI, letting the pixels settle between refresh cycles, which can greatly reduce strobe crosstalk for a global-flash strobe backlight.

Flicker at lower Hz
Also, for 60Hz (low-strobe rates), scanning backlights "appears to flicker less" because the human eye is seeing at least some light continuously (just like a CRT), so 60Hz scanning backlight may be less painful of a flicker than a 60Hz global-flash strobe backlight (even if the latter has less strobe crosstalk artifacts). There are users here who do not mind 60Hz strobe flicker, while other users find this strobing very painful. Many manufacturers artificially prevent 60Hz single-strobe (this is why ULMB 60Hz is not available by default without a hack) due to flicker/epilepsy concerns. That said, some displays (Specific Sony HDTV's containing a 60Hz blur-reduction mode) simply display a warning message about flicker for their 60Hz strobe. We believe end users should have a choice of 60Hz single-strobe mode (after a stern warning, of course) as this is useful for consoles, emulators, 60fps videos, and other content that benefits from 60Hz single-strobe (like a 60Hz CRT).

Strobe crosstalk appearance of scanning:
Consistent crosstalk from top to bottom. Usually worse than the clearest zone of a strobe backlight, but better than the worst zone of a strobe backlight. You will usually get multi-image effects from internal diffusion of a scanning backlight, e.g. the ON segments leaking into the OFF segments. This creates 4-image or 8-image effects with a 4-zone scanning edgelight. It takes a contrast ratio of well over >100:1 between the ON versus OFF segments in order to really make the strobe crosstalk much more invisible. I generally only see that sort of numbers being barely approached in FALD implementations of scanning backlights, rather than edgelight-implementations, but often, when well done (with a slight scanning-velocity speedup relative to LCD scanout to "compress"/"unify" the multi-image crosstalk artifacts a bit) it may actually be very preferable to the overall artifacts of a global-flash strobe backlight.

Fixing erratic flicker in homebrew scanning backlight:
This was observed to be a common issue with complex homebrew scanning backlight logic. Also, you need precision control over strobe flash length. Strobe phase can more safely jitter (e.g. +/- 0.1ms) but strobe flash length should not vary by more than ~0.1%. This is because if the strobe flash length varies by 1%, you're getting 1% modulations in brightness. Which means for a 1ms strobe backlight, a 10 microsecond variance in strobe flash length creates a brightness flicker of 1%! Even 0.25%-0.5% flicker is sometimes still noticed: Open a full-white window (Windows Notepad -> Maximize) and then defocus into it, that amplifies your sensitivity to erratic flicker of a microcontroller-driven backlight. It's surprising how important microseconds are in preventing flicker. So try to get your strobe length variances to less than 1 microsecond. Which means turning off interrupts and stuff like that, when using microcontroller logic to time the strobe flash length.

Commanding of adjustability
The zisworks open-source scanning backlight controller (which recently became available) uses serial commands to do some of the above adjustments such as strobe phase. One solution that the Zisworks display did for the commanding of adustments (strobe phase) was to disable serial interrupts until only a very specific tight period every blanking interval (and read the serial buffer only during these times). Most microcontrollers have a small hardware serial buffer, so keep commands very short if you're writing your own custom backlight controller firmware.

Input lag with computer gaming
Less with scanning backlight than a full-strobe backlight. This is applicable if you play videogames. Also, lag uniformity with VSYNC OFF is better with a scanning backlight (e.g. cable scanout versus strobe flash), while lag uniformity with VSYNC ON is better with a full-strobe backlight. This is very subtle and only of interest to those people who care about lag uniformity of the screen (e.g. lag differentials of top edge versus bottom edge, relative to GPU scanout).

Tip
Check out http://www.zisworks.com/shop -- you can get Zisworks' scanning backlight controller (4-segment compatible) and use that as a research & development base for creating your own custom strobe backlight, since you'd get most of the above adjustments, without all the hard trial-and-error work. The scanning backlight open source code is available for Arduino 1.8.2 IDE that way. Or even repurpose the Zisworks source code for your controller, in exchange for contributing your source code improvements back to Zisworks display users.

Testing for Strobe Crosstalk
Regardless, the TestUFO Strobe Crosstalk test (or a similar test) will probably be your best friend in calibrating your scanning backlight.

If you do choose to write your own microcontroller code though, hopefully you will publish the source code to your scanning backlight for others to tweak...

Enjoy tweaking!
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Post Reply