Blur Busters Forums

Who you gonna call? The Blur Busters! For Everything Better Than 60Hz™ Skip to content

ULMB(lighboost) & G-sync? [What are technical challenges?]

Advanced display talk, display hackers, advanced game programmers, scientists, display researchers, display manufacturers, vision researchers. The masters on Blur Busters.

Re: ULMB(lighboost) & G-sync? [What are technical challenges

Postby StrobeMaster » 01 Nov 2016, 03:52

Sparky wrote:There are a bunch of techniques that might work, but the hard part is human. It's going to take a lot of testing to figure out which artifacts people notice, and how to tune everything to avoid noticeable flicker(which is nasty because different people have different sensitivity to it).

And your point being? Do you seriously think that we don't see any solutions implemented because manufacturers are stuck with testing? Well, that would be a first. Given that different users have different sensitivities, preferences, and use cases, the testing should be done in the field anyway. So if a method can be easily implemented as an optional feature and if this method is not any less promising than others, I don't see why it shouldn't be implemented just like that, an optional feature - and leave it to the user to evaluate the practical benefits.

Sparky wrote:As for the artifact caused by your suggested method(for the moment lets say you can tune it to completely eliminate visible flicker), say you your eyes track something across your screen, with pure low persistence it's a sharp image, with pure sample and hold it's a continuous blur, with your low framerate mode you'll get a sharp image with a trail that looks like ghosting. Maybe that's a benign artifact, maybe people will find it more annoying than sample and hold. only way to find out is to try it.

I think the potential problems are clear. I completely agree that it just has to be tried, as it is very difficult to foresee the perceptual effects of one or the other method. But if that is so, I'd rather start with something simple. And nothing speaks against combining different methods.
As far as flicker goes, people have to realize that one cannot have all: Low frame rates (allowing for higher spatial resolutions and more complex sceneries), no motion blur, and no flicker. Except for having low frame rates in the first place, this does not come from technical limitations but from laws of physics (or psychophysics). And people have lived with CRT flicker for decades. So I am more concerned about the perceptual effects of variable refresh rates per se. That G-Sync and FreeSync seem to be beneficial in many cases is promising already, but it could well be that strobed backlight will make the variability of refresh rates apparent enough to become just too annoying.
StrobeMaster
 
Posts: 43
Joined: 25 Apr 2014, 01:31

Re: ULMB(lighboost) & G-sync? [What are technical challenges

Postby masterotaku » 01 Nov 2016, 07:25

I'm pretty happy about how the G-Sync + ULMB trick I discovered works. There are only two problems:

- Double strobing happens at 40fps (more or less. I've seen some 1-2fps inconsistency) and lower, and it can't be changed. Some people would prefer more and some would prefer less (I'd like to play 30fps games with single strobing).

- Brightness variance. It isn't bad when your fps stay within a not too big range. However, loading times are a flicker fest (40Hz strobing I guess. Not even double strobing can fix this if fps are lower than 20) and bad frame pacing can cause a fast brightness flicker at intervals. Games like Dark Souls, which has perfect frame pacing, are perfect in this regard.


I don't know how my monitor knows when to strobe. But if it knows when, maybe it could be programmed to change the strobe length per frame. I wonder if this secret mode was created on purpose by Nvidia but rejected it before putting it in the drivers.
CPU: Intel Core i7 7700K @ 4.9GHz
GPU: Gainward Phoenix 1080 GLH
RAM: GSkill Ripjaws Z 3866MHz CL19
Motherboard: Gigabyte Gaming M5 Z270
Monitor: Asus PG278QR
User avatar
masterotaku
 
Posts: 421
Joined: 20 Dec 2013, 04:01

Re: ULMB(lighboost) & G-sync? [What are technical challenges

Postby Chief Blur Buster » 02 Nov 2016, 15:18

StrobeMaster wrote:Except for having low frame rates in the first place, this does not come from technical limitations but from laws of physics (or psychophysics).

The solution to blur-free full persistence without strobing -- is where the refresh cycles are equivalent to strobe length, and there's no delay between visible refresh cycles.

Which means...

(Drum roll...)

To have zero strobing with 1ms persistence -- each refresh cycle would need to be adjacent each other without a black interval. To achieve 1ms MPRT persistence without strobing -- would require 1000fps @ 1000Hz to achieve strobefree motion blur elimination. This would achieve the same perceived motion blur as 1ms strobe flashes.

For equal motion blur to 0.5ms strobing, you would need 2000fps @ 2000Hz for blur-free full persistence with 0.5ms MPRT measurement.
For equal motion blur to 1.0ms strobing, you would need 1000fps @ 1000Hz for blur-free full persistence with 1ms MPRT measurement.
For equal motion blur to 2.0ms strobing, you would need 500fps @ 500Hz for blur-free full persistence with 2ms MPRT measurement.
etc.

You'll also need a GPU (and/or interpolation) powerful enough to create distinct frames for each refresh cycles, no repeated frames. Framerate matching refreshrate (and matching stroberate, in the case of strobed monitors).

(To clarify terminology.... Full persistence = zero flicker = zero strobing = continuous illumination = no dark/black de-illumination periods for any pixel between refresh cycles.)

Needless to say, we have difficulties running such high refresh rates to achieve equivalent blur reduction without needing black/dark/decay intervals between refresh cycles (whether the pixel is strobed, scanned, CRT, backlight flashing, BFI, or *any* kind of *any* technology of de-illumination cycle between frames).

The low-persistence titans of the industry (including John Carmack, Michael Abrash, various engineers at NVIDIA, etc) all confirm this, and I can also concur from past Blur Busters testing, as well, too.

So we're stuck with strobing for the foreseeable future.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3761
Joined: 05 Dec 2013, 15:44

Re: ULMB(lighboost) & G-sync? [What are technical challenges

Postby Chief Blur Buster » 02 Nov 2016, 15:32

Chief Blur Buster rarely talks, but gives sage advice:

masterotaku wrote:I don't know how my monitor knows when to strobe. But if it knows when, maybe it could be programmed to change the strobe length per frame. I wonder if this secret mode was created on purpose by Nvidia but rejected it before putting it in the drivers.

Yes, that's one of the possibilities. On the other hand, this could be done by a monitor hacker instead (writing an external power driver to the monitor's LED edgelight, with customized strobing)...

Variable strobe rates need to be greatly improved, like a plateau-off to full persistence at lower refresh rates, with average-trailing-brightness intelligent logic. Strobe length could be one of the techniques (though strobe crosstalk becomes a huge problem with long strobe lengths). As a compromise, it could instead blend from full-persistence at 40fps, all the way to strobing at 120fps+, completely avoiding double-strobing, simply by analog-like dynamically brightening the black part of the curve and dimming the fully-illuminated part of the strobe cycle -- depending on the current framerate.

I've written about algorithms for variable-rate strobing in year 2013.
http://www.blurbusters.com/faq/creating-strobe-backlight/#variablerefresh
-- Both the strobe length idea and the strobe/dark-curve ideas are mentioned.

If someone could wire this to a high-performance microcontroller (some turbocharged Arduino), perhaps with-trigger a VSYNC wire to the GPU or monitor circuit, and a separate power wire to the monitor's LED edgelight -- then a hobbyist monitor hacker might be able to design a third-party way of manipulating backlight strobing dynamically during GSYNC (overriding the monitor/GPU-controlled strobing).

You'd need plenty of adjustments (strobe phase adjustment for multiple points of refresh rates, and a curve-fitting algorithm designed for it, set lower refresh rate that becomes full persistence, set higher refresh rate that becomes fully strobe). A user can adjust their threshold, like full-persistence below 70fps and full-strobe above 100fps, with a blending algorithm between 70fps and 100fps (by lowering the brightness of strobes & starting dim illumination during the blacks at 100fps -- gradually blending down -- till the strobe peaks levels with the dark valleys, at 70fps). You'd have perhaps memorized presets for the newbies who just want to "Set and Forget", while advanced users can tweak these thresholds to their heart's contents.

IMPORTANT TIP: Microseconds matter. A single 1us variation in a 500ms strobe cycle is a 0.2% brightness variation. Some humans are actually sensitive to a 0.2% variation in brightness. _Please_ use a high-performance microcontroller to compensate.
IMPORTANT TIP #2: In addition, power to LED isn't always perfectly linear (e.g. ringing in squarewave power), and at these microsecond leagues, you've got illumination delay and white-LED-phosphor-decay delay that actually starts to become significant factors in human perceived consistency of brightness during variable-rate strobing. When we're talking about microsecond precision, you may find it necessary to add an additional algorithm to compensate for these behaviours in your attempt to keep brightness modulations consistent during variable-rate strobing.

Throw in a very good average-brightness-maintenance algorithm that keeps track of how much light has been emitted from the monitor in the preceding, say, X milliseconds (300 milliseconds), and adjusting the current strobe to attempt to maintain average amount of photons hitting human retinas, to the best of the algorithm's ability. Some of this is easily mathematically done by keeping strobe length proportional to refresh cycle length. But will likely need algorithmic compensation due to not knowing how long the next refresh cycle will be.

Especially in the low-latency situation of needing to strobe before knowing how long the next refresh cycle will render -- a catch-22 -- so if you've strobed slightly too short or too long (before finally realizing how long the current refresh cycle needs to be displayed) -- then you have to compensate strobe length the next refresh cycle to mathematically maintain average brightness. If you are willing to add 1 frame of latency (wait until the next refresh cycle begins arriving BEFORE strobing the current refresh cycle), the variable-rate strobe algorithm becomes mathematically MUCH, MUCH simpler (and you can probably even skip trailing-average-brightness-history) but you may not have that luxury simultaneously trying to do low-latency strobed variable-framerate.

TL;DR: This catch-22 means buffered (1-frame-latency) variable framerate operation will be much easier to create a strobe algorithm for, to mitigate the variable-brightness artifact of strobed variable framerate.

Doing all the above techniques, I _bet_ this will reduce approximately 80-90% of the side effects of variable-refresh-rate strobing. There will still be problems, but it will be much better. There will likely be more dramatic changes to motion blur, and possibly ghosting artifact modulations, during variable frame rate operation, but flicker will be dramatically reduced, and you've got beautiful zero motion blur during variable-framerate operation above 100fps. But instead of stutters or double strobes, my algorithm simply will mean a brief sudden variance of motion blur -- but with zero stutter. In my (And many people's opinion), this will be the lesser of evil artifact -- and far better for most than the unoptimized variable-rate strobing today.

I leave this to the exercise of an advanced monitor hacker (such as cirthix, et cetra), who's does amazing stuff.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3761
Joined: 05 Dec 2013, 15:44

Re: ULMB(lighboost) & G-sync? [What are technical challenges

Postby StrobeMaster » 02 Nov 2016, 16:02

Chief Blur Buster wrote:
StrobeMaster wrote:Except for having low frame rates in the first place, this does not come from technical limitations but from laws of physics (or psychophysics).

The solution to blur-free full persistence without strobing -- is where the refresh cycles are equivalent to strobe length, and there's no delay between visible refresh cycles.

Yes, yes. What I meant is that complaining about flickering or motion blur at low refresh rates does not make too much sense, as you cannot get rid of both simultaneously - at low frequencies, mind you. At the currently available high frequencies you can get rid of both but need strobing. And that we don't have any of these problems in the >500Hz regime (or higher, whatever) is trivial but not helpful, sorry. Technology is just not ready for it and will not be for the next couple of years.
StrobeMaster
 
Posts: 43
Joined: 25 Apr 2014, 01:31

Re: ULMB(lighboost) & G-sync? [What are technical challenges

Postby Chief Blur Buster » 02 Nov 2016, 16:06

Agreed. Just providing explanations, as some monitor hackers are reading this thread -- brainstorming -- but it is also an advanced topic to them that needs a little explaining to understand.

Many display hackers understand refresh rates, but not necessarily the subtleties behind variable-rate strobing, for example. Or why 2ms MPRT (not GtG) full persistence without strobing _requires_ 500fps@500Hz.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3761
Joined: 05 Dec 2013, 15:44

Re: ULMB(lighboost) & G-sync? [What are technical challenges

Postby Falkentyne » 02 Nov 2016, 22:18

Just so we can get clarification, can you please clarify what you mean by "
Strobe Crosstalk"?
Because from what I've seen, there may be two forms of crosstalk.

The strobe crosstalk I think most people are familiar with are caused by strobes being *TOO SHORT*, because then the strobe completes faster, way faster, than most pixel color transitions can be completed, (e.g. at 6.9ms at 144hz), so then the next frame begins, the strobe is done for the next frame, but most of the current frame's color pixel transitions aren't completed. So then you wind up having the "next frame's" beginning color transition patterns blended in with the previous frame's later color transitions, which creates a very ugly double image of crosstalk and ghosting overlays. At 120hz, the crosstalk is less due to 8.3ms strobes taking more time. At 60hz, the crosstalk is exactly half as much as 120hz (coming from the bottom of the screen as screens are refreshed top to bottom).

So there is substantially less crosstalk on TN monitors and ULMB/Benq blur reduction at lower refresh rates than at higher refresh rates.
Falkentyne
 
Posts: 2367
Joined: 26 Mar 2014, 07:23

Re: ULMB(lighboost) & G-sync? [What are technical challenges

Postby Chief Blur Buster » 03 Nov 2016, 15:50

Falkentyne wrote:Just so we can get clarification, can you please clarify what you mean by "
Strobe Crosstalk"?
Because from what I've seen, there may be two forms of crosstalk.

The strobe crosstalk I think most people are familiar with are caused by strobes being *TOO EARLY OR LATE*, because then the strobe completes too soon or too late, than most pixel color transitions can be completed, (e.g. at 6.9ms at 144hz), so then the next frame begins, the strobe is done for the next frame, but most of the current frame's color pixel transitions aren't completed. So then you wind up having the "next frame's" beginning color transition patterns blended in with the previous frame's later color transitions, which creates a very ugly double image of crosstalk and ghosting overlays. At 120hz, the crosstalk is less due to 8.3ms strobes taking more time.

Minor fixes to make this correct.

Strobe length actually has fairly little to do with strobe crosstalk, except as a side effect -- longer strobes create more strobe crosstalk simply because they're longer than the time the previous refresh cycle finishes and before the next refresh cycle begins.

It's important to not confuse "faster" with "higher rate" or "briefer strobe".

A good strobe crosstalk measurement test pattern is TestUFO Moving Photo, Alien Invasion. Make sure it's animating at full framerate (try different web browsers; not all browsers work properly on all systems).

An early strobe or a late strobe can create strobe crosstalk. A strobe that is too early creates strobe crosstalk (double-image-effect) at the bottom edge of the screen, and a strobe that is too late creates strobe crosstalk (double-image-effect) at the top edge.

Naturally, adjusting strobe timing (phase) moves the strobe crosstalk vertically -- the "double image ghosting band" -- moves vertically. The name of the game is time it in a way to push strobe crosstalk off the bottom edge of the screen but without reappearing again at the top edge. Sometimes it's mathematically impossible (laws of physics).

An LCD is refreshed top-to-bottom (as seen in high speed videos), so the moment the backlight is flashed, you want to time it when the LCD refresh (preferrably done in total darkness) finishes to the bottom edge of screen, but before the next refresh cycle begins refreshing the top edge. So a strobe that's timed a little early will create crosstalking at bottom edge, and a strobe that's timed a little late will create crosstalking at top edge.

The end of the previous refresh -- often ends the last pixel row at bottom of screen. The beginning of next refresh cycle -- often begins on the first pixel row at top of screen. Now you want enough time between refresh cycles. That's the blanking interval (ala VSYNC, or VBLANK, or sync interval, many terminology exist). The blanking interval can be short or long. A large Vertical Total means you've got a longer blanking interval.

How many milliseconds is VSYNC? Depends. If Vertical Total is 1/4th of the visible vertical resolution (say, 1080p visible + 270 pixel blanking interval, for a Vertical Total of 1350), the display is spending 1080/1350th of its refresh cycle actually refreshing the LCD pixels (initiating their beginnings of GtG transition), and the other 270/1350th of the refresh cycle is spent pausing between refresh cycle (which is also useful for waiting for the momentum of any remaining GtG transitions to complete, as well as the strobing).

If the refresh rate is 120Hz (8.33ms per refresh) and using VT of 1350 means 270/1350th of 8.33ms equals ~1.7 millisecond pause between refresh cycles when you're using a Vertical Total of 1350 on a 1080p LCD at 120Hz (1080 visible vertical resolution + 270 of blanking interval). Increasing the Vertical Total while keeping refresh rate the same, speeds up the LCD scan -- but does not speed up pixel transitions. When I say "LCD scan", I mean initiating the pixel transition of each pixel.

For a Vertical Total of 1350, it simply means the display will take 1/1350th of 1/120th second to finish initiating the pixel transitions of the first row of pixels of the screen. Then the next 1/1350th of 1/120th of a second is spent initiating the pixel transitions of the second row of pixels on screen. And so on. LCD's are refreshed top-to-bottom in terms of initiating the pixel transitions.

(Replace "1350" with whatever Vertical Total is being used)

Obviously, once you're finished electronically refreshing the bottom row of pixels, that doesn't mean you're visually finished yet. It still takes another ~1ms to finish pixel transitions (give or take). In high speed videos -- like www.blurbusters.com/lightboost/video -- LCD pixels simply "fade" from one color to another. Most of the transition (fade) is complete in 1ms.

Now, many modern TN LCD's will finish most pixel transitions in 1ms. This is a good response time acceleration of 1ms for all possible transitions between any shades. Obviously, 1ms is not a hard-and-fast number, as pixels may only be 99% completed in 1ms -- meaning you might have a faint ghost (1% intensity).

Note: Vertical Total is not always controllable by users with all monitors.
Many displays will artificially use internal large vertical totals (accelerated scan for long intervals between refreshes) -- LightBoost does this automatically. The great thing is BENQ XL2720Z's (and compatibles) are one of the few monitors that lets end users manually adjust the speed of the LCD scanning via the Vertical Total trick.

However, strobe backlights are often running at very tight tolerances, so you don't always have

General rule of thumbs (not always hard-and-fast, but usual):

Strobe crosstalk factors:
-- The "double-image" horizontal band of strobe crosstalk is taller at higher refresh rates and/or on slower LCDs (longer pixel transitions).
-- If you strobe too early, you get more strobe crosstalk at bottom edge of screen
-- If you strobe too late, you get more strobe crosstalk at top edge of screen
-- If your strobes are too long for blanking interval, you get strobe crosstalk at both top and bottom edge of screen.
-- Reducing strobe length, lowering refresh rate, longer blanking intervals(via large Vertical Totals) or doing 2 or 3 combined -- can reduce the Catch-22 situation of having strobe crosstalk at both top/bottom edges of screen.

Techniques of longer blank intervals
-- Longer blank intervals can be done manually (e.g. via large Vertical Totals) or automatically (e.g. LightBoost firmware in monitor)
-- Automated large blank intervals (e.g. LightBoost) will override & render manual Vertical Total adjustments useless. (frustrating sometimes).
-- Lower refresh rates

The bottom line, is.... Getting good strobing in a monitor, is very fiddly.

At 60hz, the crosstalk is exactly half as much as 120hz (coming from the bottom of the screen as screens are refreshed top to bottom).

Not necessarily exactly half. It's usually half simply because there's twice as long between refresh cycles, but you can compensate by using a large Vertical Total. For example, well-tweaked 120Hz with large Vertical Total can produce better results than 100Hz at default Vertical Total setting.

Also, pixel transition speed can distort the mathematics behind this, to the point where 60Hz might actually result in 3x less strobe crosstalk than 120Hz, especially if pixel transitions are slow (e.g. you're using a 1.6ms blanking interval and pixel transitions are 2-3ms). In this situation you're stuck with strobe crosstalk at both top edge and bottom edge of screen, even with instant strobes (e.g. 0.001ms strobes). This is because if pixel transitions take longer than the blanking interval (e.g. 3ms pixel transitions and a 1ms blanking interval), the monitor is initiating refresh of the top row of pixels long before the bottom row of pixels have finished their pixel transitions.

I hope this is not too confusing to readers, but this is quite advanced stuff for the layperson, to understand the double-image motion ghosting artifacts (strobe crosstalk) of a strobe-backlight monitor.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3761
Joined: 05 Dec 2013, 15:44

Re: ULMB(lighboost) & G-sync? [What are technical challenges

Postby Chief Blur Buster » 11 Feb 2017, 19:05

StrobeMaster wrote:I have written down a pretty simple idea of how to combine variable refresh rate and strobed backlight, also implementation-wise pretty straight forward. It might well be that this idea is not exactly new, but at least I never saw it clearly spelled out like that. And if the idea is not new, I wonder what the manufacturers are waiting for. It is too simple for not being implemented.

NVIDIA has a pending patent regarding the topic (US 2015/0109286 A1, System, method, and computer program method for combining low motion blur and variable refresh rate in a display), but I don't think it includes my idea. The patent covers at least part of Chief Blur Buster's ideas though (Strobing on variable refresh displays), which he posted just one day after NVIDA filed the patent.

Can't believe I missed clicking this link. But it also all boils down to my not spending much time on Blur Busters. Even Chief Blur Buster is limited as a know-it-all Oracle around here, given that time spent on Blur Busters currently plays second-fiddle to a primary job that has nothing to do with Blur Busters monitors, but hopefully this will change in the future [keep tuned]!

Great stuff about variable refresh rate, and another excellent suggestion about flicker-mitigated backlight strobing curves -- for strobed variable refresh rate:

Image
(Credit: StrobeMaster)
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3761
Joined: 05 Dec 2013, 15:44

Previous

Return to Area 51: Display Science, Research & Engineering

Who is online

Users browsing this forum: No registered users and 2 guests