Why is Refresh Rate Headroom Good For Strobing? [Low-Hz Strobe on High-Hz-Capable LCD]

[Chief Blur Buster]

Crossposted from another forum, because it's a good Blur Busters Area51 topic.

Why is that, that seems very counterintuitive, can you ELI5 (explain like I'm five)? Strobing at 120fps on a 240Hz screen looks better than strobing at 120fps on a 120Hz screen?

Where do you see the future of the TV industry going? Don't you agree with me that they should stop at 4K and not proceed to 8K, they should focus on 4K screens but with higher refresh rates? we need 4K 240hz as soon as possible. Also is there any problems with 8K or higher resolution at 1,000fps@1,000Hz like stuttering or anything?

Also are the executives at Samsung, Sony, LG, and TCL aware of this? Are they aware of the horrible motion blur lcd's have and that there are solutions to fix it, namely the solutions blurbusters has come up with? That's why I started this thread I'm trying to raise awareness about this!

Excellent Science Question:
Why is low-Hz strobing superior on high-Hz LCD?

It is only counterintuitive because of LCD.

LCD have a finite pixel response called a "GtG", which is Grey-to-Grey.

It's how an LCD pixel "fades" from one color to the next.

You can see LCD GtG in high speed video: High Speed Video of LCD Refreshing

phpBB [video]

Strobing at max Hz means you don't have enough time to hide LCD GtG between refresh cycles.

Not all pixels refresh at the same time. A 240Hz display takes 1/240sec to refresh the first pixel to the last pixel. Then GtG pixel transition time is additional to that above-and-beyond!

You want LCD GtG to occur hidden unseen by human eyes. See High Speed Video of LightBoost to understand.

Strobing only when the refreshing behavior is between refresh cycles:

phpBB [video]

Most GtG is measured from the 10% to 90% point of the curve, as explained at www.blurbusters.com/gtg-vs-mprt.



But that means 10% of GtG from black to white is a dark grey, and 90% of a GtG from black to white is a very very light grey. This can create strobe crosstalk (duplicate images trailing behind images):



Slow GtG can amplify strobe crosstalk, and we need almost 100% to be really fast. 1ms GtG 90% often takes more than 10ms to complete 99% or 100% of GtG transition.

Pixel colors coast very slowly to its final color value near the end, like a slow rolling ball near the end of its rolling journey -- that is a strobe crosstalk problem.

More advanced reading about this can be explained in Advanced Strobe Crosstalk FAQ, as well as Electronics Hacking: Creating A Strobe Backlight. (Optional reading, not germane to understanding ELI5, but useful if you want to read more)

Now, Imagine a 240Hz IPS LCD. It has an advertised 1ms GtG, but its GtG is closer to about 5ms real-world GtG for most color combinations. GtG speeds can be different for different colors, so you've got a "weak link of chain" problem!

Example 1: Strobe 240Hz LCD at 240Hz

1/240sec = 4.166 milliseconds.

.....Thus, repeat every refresh cycle:
T+0ms: Backlight is OFF
T+0ms: Begin Refreshing
T+4ms: End Refreshing (240Hz refresh cycle takes 1/240sec)
T+4ms: Wait for GtG to Finish before turning on backlight (ouch, not much time)
T+4.1ms: Backlight is ON
T+4.166ms: Backlight is OFF
.....Rinse and repeat.

Problems:
- Not enough time for GtG to finish between refresh cycles
- Not enough time to flash long enough for a bright strobe backlight
- We lose lots in strobe quality

Example 2: Configure 240Hz LCD to 100Hz and strobe at 100Hz

1/240sec = 4.166 milliseconds.
1/100sec = 10 milliseconds

T+0ms: Backlight is OFF
T+0ms: Begin Refreshing
T+4ms: End Refreshing (100Hz refresh cycle in approx 1/240sec, thanks to fast panel)
T+4ms: Wait for GtG to finish
T+9ms: Finally finished waiting for GtG (5ms in total darkness)
T+9ms: Backlight is ON
T+10ms: Backlight is OFF
.....Rinse and repeat.

Voila! We win!
- LCD GtG completely hidden by human eyes (in the backlight OFF period)
- Requires LCD that supports quick scanout at lower refresh rates (most do, if manufacturers bother)
- Only fully-refreshed refresh cycles are seen by human eyes (more perfectly complete GtG).
- Strobe crosstalk goes to zero (or almost zero)

Internally we call it the “Large Vertical Total” technique (large Vertical Blanking Interval aka VBI) because it's a large interval BETWEEN refresh cycles. The interval/pause between refresh cycles (VBI) can be several times longer (in milliseconds) than the visible refresh cycle, to allow more time for GtG to complete between refresh cycles!

Here is a comparision before/after for www.testufo.com/crosstalk




<Appendix: Advanced Optional Reading>

Sometimes GtG is not even 100% between refresh cycles, but the worst GtG incompletions can often be “pushed” into the top/bottom edges of the screen via special strobe phase timing delays relative to the LCD refresh cycles. So 7ms GtG can still be mostly hidden by a 5ms VBI with only small leakage into visibility. So the backlight timing phase is sometimes slightly overlapped with the refresh cycle, to account for the GtG lagbehind effects, measured using a photodiode oscilloscope.

Reminder: Not all pixels refresh at the same time. There isn't millions of wires to refresh all pixels at the same time. They use nanowire grids in digital panels. They can activate one vertical wire and activate one horizontal wire to refresh essentially one pixel at a time (where the wires meet) -- in ultra high speed fashion, left-to-right, top-to-bottom.

Displays have been raster-refreshing for a century, from the first analog TVs of the 1920s, through today's 2020s DisplayPort LCDs. Like the days of a calendar or book -- you start at upper-left corner, scan towards the right, then go to the next row. This is how two-dimensional images (refresh cycles) are delivered sequentially over a one-dimensional medium (over analog or digital video cable, or over a TV radio channel, or executing displays refreshing electronics). Pictures of a refresh cycles are metaphorically like building mosaic art one square at a time. And repeating it every single refresh cycles.

You can see that most displays refresh 1 pixel at a time in high speed videos. Otherwise, we'd end up having millions of miles of nanowires just to refresh all pixels of an 8K display simultaneously. Even "global" refresh displays (plasmas, DLPs) still sequential-refresh, just simply ultrafast sequential scanouts (e.g. 1/1000sec for DLP chip). Either way, to save money & engineering, thin digital displays only have wire grids, and they essentially (more or less) refresh one pixel row at a time. It takes time to refresh the first pixel through the last pixel.

Good strobing (during a long VBI that allows GtG to finish unseen by eyes) allows you to filter slow LCD GtG (hidden in total darkness with backlight OFF) while having short MPRT (the length of strobe flash), allowing certain LCDs such as Oculus Quest VR or Valve Index VR headset to have less motion blur than an average CRT.

Few people realize that a cherrypicked well-engineered strobed LCD can beat CRT in motion clarity (zero ghosting, zero blur, zero strobe crosstalk, zero afterimages, perfect clarity, no phosphor ghosting), especially during perfect framerate=Hz (VSYNC ON or similar technologies).

Nontheless, it is my belief that users should have the choice of strobing at max-Hz (lower lag but lower quality than CRT), or strobing at well-tuned lower-Hz strobe on high-Hz panel. I prefer manufacturers uncap the arbitrary strobe refresh rate presets/ranges, and let users choose.

</Appendix: Advanced Optional Reading>

Hope this helps explains (in sufficiently simple science) why refresh rate headroom is very good for LCD strobe backlights.

TL;DR: Refresh rate headroom gives more time for LCD GtG between refresh cycles at lower strobe Hz. This allows strobing to be MUCH more CRT motion clarity.

[MCLV]

I'm curious why scanning backlights implemented using full-array local dimming are not more popular. I tried to do some simulations and it seems that it should be able to bring benefits even though one should not probably expect the same decrease of persistence as with strobing. I used familiar test subject and some cross-hair variations for demonstration, see original image without motion blur in Figure 1. At first, I applied motion blur of 15 pixels in order to simulate screen with always on backlight, see Figure 2. The next step was to simulate scanning backlight using sine wave profile of light output, see Figure 3. One can clearly see that blur was significantly reduced.

Figure 1: Original image

original.png (22.11 KiB) Viewed 21905 times

Figure 2: Motion blur of 15 pixels simulating always on backlight

motion_blur1.png (45.25 KiB) Viewed 21905 times

Figure 3: Simulated result of scanning backlight with sine wave modulation

motion_blur2.png (55.98 KiB) Viewed 21905 times

[MCLV]

(continuation of previous post) However, as was mentioned in links in the first post in this thread, LCD screen above turned off dimming zones would be still partially lit by light from neighboring zones. Hence, I modified the scenario from Figure 3, where backlight intensity is modulated between 0% to 100%, by increasing lower limit of backlight intensity to 10% (assuming 10:1 contrast ratio achievable by local dimming). Result is presented in Figure 4. It looks almost the same as Figure 3 but the contrast of some features is slightly lowered due to crosstalk between dimming zones. However, this is only true if the fraction of time when backlight is on is not too short. If the scanning backlight would be turned on short enough to remove the motion blur (i.e. CRT like operation) but would have 10% light bleed to the rest of the screen, one would see sharp image with blurred halo underneath it, see Figure 5. Therefore, it is quite clear that order of magnitude reduction of image persistence is not achievable by scanning backlights without significant artifacts at local dimming contrast ratio of 10:1. However, reduction of image persistence by factor of 2 should be achievable. Compare images from Figures 3 and 4 with image with 7 pixels of motion blur in Figure 6.

Figure 4: Simulated motion blur with sine wave modulation between 10% and 100% backlight intensity

motion_blur3.png (57.73 KiB) Viewed 21904 times

Figure 5: Simulated motion blur with short illumination interval but with 10% backlight intensity during whole refresh cycle

motion_blur4.png (55 KiB) Viewed 21904 times

Figure 6: Motion blur of 7 pixels

motion_blur5.png (38.32 KiB) Viewed 21904 times

[Chief Blur Buster]

Excellent posts, MCLV!

You are correctly aware of scanning-backlight strobe crosstalk. You'd have a sharp strobe with some fainter strobe blur, just like this.



The Samsung CFG & CHG series had a 4-segment scanning edgelight, so you had a 1-strong-3-faint strobe crosstalk (like PWM artifact). It was pretty good for a scanning edgelight though, but there were still some problems. And you seem to already have already read my article Electronics Hacking: Creating a Strobe Backlight.

Blur Busters used to be www.scanningbacklight.com in year 2012 before we renamed to Blur Busters after the discovery of LightBoost, so there's the nearly 10-year-old Scanning Backlight FAQ. Some of this information, back in the hobby days, is now out of date. But it does cover some of the issues of scanning backlights of backlight diffusion too, as you've indicated.

Now....

TODAY: Why FALD Scanning Backlights Are Not Common

There are many reasons why FALD scanning backlights are not common.

1. Full array backlights are expensive. Goes without saying. It's easier to engineer a strobe backlight for only a few dollars increment to a panel's cost, and some good overdrive tuning (to ensure GtG completeness at moment of strobe).

2. Electronics controllers in off-the-shelf full array backlights often don't have the necessary sub-refresh programmable precision needed. This increases costs even more (turning a $2000 monitor into a $5000 monitor). Even a 10 microsecond variation in strobe length creates human visible flicker (1.0ms strobe vs 1.01ms strobe = 1% brightness variance) as seen in Amazing Human Visible Milliseconds.

3. You can eliminate 99.9% (instead of only 90%) of strobe crosstalk with a global strobe backlight. Two orders of magnitude superior. The Oculus Quest 2 VR headset is miraculous in perfect zero crosstalk (below human visibility noisefloor) for the entirety of top/center/bottom.

FUTURE: Scanning Backlights Probably Will Arrive Soon

However, the good news:

1. MiniLED / MicroLED sheets are getting cheaper and cheaper as time passes. LED has been commoditized in other industries, and 3-figure FALD desktop monitors should be able to come later this decade. Even a 1024-pixel (3072 LED chip) jumbotron building modules (32x32) goes for under $10 off Alibaba nowadays, so LED-count can be cheap.

2. Proper forethought in backlight controller design can simplify a FALD scanning backlight. As long as each row of LED can be controlled individually with appropriate electronics, with a two-rolling-refresh pattern (like the 2-concurrent scanout in Custom Scan Patterns), it can be precisely controlled with a phase adjustment (lagging sufficient behind the "LCD GtG fade zone" bar in high speed videos of LCD refreshing). You might need to combine HDR / FALD / scanning with complex logic (e.g. longer persistence for brightest pixels) which can cost more than 10x as much software engineering costs, pushing a screen to four figures. But some simplification can easily be done.

3. The high-LED-count MiniLED sheets can hug the rear of the LCD panel very closely, allowing at least 100:1 to 1000:1 contrast ratio between the OFF segment and ON segments, with far less diffusion with simpler optics.

[Chief Blur Buster]

However, this is only true if the fraction of time when backlight is on is not too short. If the scanning backlight would be turned on short enough to remove the motion blur (i.e. CRT like operation) but would have 10% light bleed to the rest of the screen, one would see sharp image with blurred halo underneath it, see Figure 5.

You probably easily figure this out, but I post this reply for other forum readers who don't quite understand the multiple causes of strobe crosstalk.

Also, since you're so good at understanding display motion blur physics, there's another monkey wrench in scanning backlights to understand too:

Strobe Crosstalk From LCD GtG Overlapping More Than One Refresh Cycles

If you see high speed videos of LCD refresh cycles, you will see that they tend to be somewhat incomplete, since GtG 100% doesn't manage to finish for all possible colors in the time interval between refresh cycles.

So this image is a somewhat more accurate picture of what happens with certain imperfect scanning backlights, a superimposition of the artifacts in your image AND cross-refresh-cycle strobe crosstalk, in a gaze-pursuit situation (eye tracking or camera tracking):

Worsened Scanning Backlight Behavior from Slow LCD GtG Overlapping Two Refresh Cycles

ScanningBacklightGtGcrosstalk.png (26.05 KiB) Viewed 21856 times

This is not a perfect simulation, but illustrates the problem of multiple causes of strobe crosstalk in a scanning backlight.

The separation distance between the cross-refresh-cycle-GtG-crosstalk and the internal-backlight-diffusion-crosstalk, will depend on how long the blanking interval is between the refresh cycles, and the intensity of the cross-refresh-cycle-GtG-crosstalk will depend on the speed of the LCD GtG in the panel.

Also because of scanning backlight having a consistent time distance between "strobe scanout" and "LCD GtG scanout", it will be a consistent strobe crosstalk from top-to-bottom depending on how bad GtG overlaps refresh cycles.

As seen in Pixel Response FAQ: GtG Versus MPRT, GtG is measured from 10% to 90%. So GtG 100% can take more than 10x longer than GtG(10%->90%). That causes crosstalk problems for both global-strobe backlights, AND for scanning-backlights.





So you've got extra crosstalk above-and-beyond internal backlight diffusion (ON segments of FALD bleeding into OFF segments), based off how complete the LCD GtG is between refresh cycles.

High Speed Videos of LCD Refreshing: Not All Pixels Refresh At Same Time

Back in year 2012, I created www.testufo.com/flicker which simply flickers between black and white every other refresh cycles. With a 1000fps camera almost ten years ago, I created these videos:

A slow LCD GtG creates refresh cycles blending-into-each-other

I created this video when this website was still named scanningbacklight.com in year 2012.

phpBB [video]

A fast LCD GtG creates refresh cycles with clear scanout.

phpBB [video]

If your GtG is too slow, it can even overlap 3 or 4 refresh cycles! Like a 33ms LCD or 50ms LCD in the old 60Hz days of 1990s. You can even have 3 refresh cycles overlapping (see number 6, 7 and 8 simultaneously despite this being a 1/480sec camera shutter):



However, if GtG is fast enough, this is where a scanning backlight generally needs to aim its strobing at any instant moment in time, requiring precision sub-refresh timing controllers in a FALD backlight:

The Precise Timing Of Flashing LEDs Properly In Scanning Backlight



Hope this proves educational to readers of this thread!

Quality of Global Strobe versus Scanning Strobe

There are many variables whether or not a scanning backlight becomes more/less objectionable than a strobe backlight. Sometimes you can tune a global strobe to be clearer at screen centre but with bad crosstalk top/bottom. Whereas with a scanning strobe, you have much more uniform crosstalk (top, center, bottom). There are three situations:

1. Scanning strobe is worse top/center/bottom than global strobe (happens with slow GtG + bad FALD optics)
2. Scanning strobe is worse center, but better top/bottom than global strobe (happens with faster GtG + okay FALD optics)
3. Scanning strobe is better top/center/bottom than global strobe (happens with very fast GtG + excellent FALD optics)

Situation #3 is unfortunately very rare to do cheaply. And global strobe is getting cheaper and cheaper -- especially with 240Hz VR LCDs being underdriven to 72Hz like the Valve Index LCD or Oculus Quest 2 LCD, which gains a perfect GtG100% heatmap (all 65536 pairs) with zero global strobe crosstalk top/center/bottom -- the Quest 2 is superlatively perfect strobe at 72Hz and 90Hz. And Quest 2 is only $299. Much cheaper to speed up the scanout and speed up GtG.

However, we need FALD for good blacks, good contrast ratios, and good HDR1000+ ability, so we must work on improved FALD technology with cheaper costs. Also, I've got in-house FALD timing algorithms / formulas available for hire if any display vendor requires consulting services to better understand why their scanning FALD is failing in crosstalk artifacts. That said, even a globally-strobed FALD may, in certain cases, actually be cheaper to design with currently-improving LCDs.

Applicable Study: Benefits of Refresh Rate Headroom / Large VBIs For Both Global Strobe & Scanning Strobe

• Faster GtG (pixel fading from one color to another) means more complete pixel transitions between refresh cycles
  Reduces crosstalk from slow GtG that overlaps multiple refresh cycles.
  This applies to both global strobe & scanning strobe.
  .
• Faster scanout (top-to-bottom sweep velocity) means more idle time (VBI) between refresh cycles at same refresh frequency (Hz)
  Reduces crosstalk from GtG still incomplete at bottom edge when top edge starts GtG sweep again.
  This can still affect scanning strobe because internal backlight diffusion can still reveal GtG incompleteness at opposite edge even if the backlight is OFF at that edge.

[MCLV]

Thank you for detailed reply! I'm not an electronics engineer so maybe I underestimated simplicity and cheapness of integrating such feature with existing backlight systems. However, let's hope that manufacturers take advantage of it in upcoming displays with mini LED backlights. Especially displays certified for HDR1000 or HDR600 should have no problem to provide sufficient brightness to enable this mode for SDR content.

I think that it makes sense to use scanning backlight in at high refresh rates when global strobing is not possible due to limited refresh rate of LCD panel or limited interface bandwidth. For example, using 50% duty cycle of backlight at 240 Hz would result in ~2ms persistence. Of course, GtG transition speed would need to keep up with this but maybe slightly more aggressive overdrive tuning could be used since potential overshoots would be (partially) hidden during the OFF phase of backlight?

[Chief Blur Buster]

Thank you for detailed reply! I'm not an electronics engineer so maybe I underestimated simplicity and cheapness of integrating such feature with existing backlight systems. However, let's hope that manufacturers take advantage of it in upcoming displays with mini LED backlights. Especially displays certified for HDR1000 or HDR600 should have no problem to provide sufficient brightness to enable this mode for SDR content.

The main problem to commoditization of FALD+scanning is cost cutting, the supply chain logistics, and off-the-shelf tech.

Commoditization
With electronics commoditization, you've got inexpensive LED lightbulbs, inexpensive LED ribbons, to things like inexpensive smart bulbs ($10 Tuya-chipped WiFi bulbs from Amazon). But often you're limited in a menu of customizability in inexpensive commodity electronics

Off The Shelf Code That Can't Be Rewritten
Many manuacturers look for off-the-shelf backlight systems but their "timing controls" may be incompatible. For example, brightness adjustment is usually done by PWM dimming, and going "PWM-free" is often done by capacitors to convert PWM to non-PWM. To pile a scanning strobe on top of this is essentially a complete complex source code rewrite.

The Desktop Monitor Supply Chain
Most engineers at display manufacturers don't think in Blur Busters temporal terms -- there's a supply chain where you have panel manufacturers (AUO, Samsung, LG) that hands panels to scaler/TCON vendors (AOC, TPV, NVIDIA(native GSYNC), MSTAR) who are working with OEMs (ASUS, ViewSonic, BenQ). Many parts of the supply chain communications have little awareness of the complex off-the-shelf requirements of a scanning backlight. The off-the-shelf backlight controllers may use an ASIC or an FPGA language programmed by TPV and then the OEM has to outsource a huge amount of consulting $$$ to the scaler vendor to do a custom scanning backlight firmware. This is easier to do if you're both panel manufacturer and scaler vendor (like Samsung's scanning edgelight in CHG70 series).

Relevance: Blur Busters Approved Program
P.S. Behind the scenes of Blur Busters Approved, I help communication between scaler vendors and OEMs to spec out improved backlight firmwares that can reduce strobe crosstalk without a new panel -- usually via a DDC-commandable tuning interface that allows the OEM to finish-off work that the scaler vendor no longer needs to do for OEMs -- I can reduce strobe crosstalk by 90% with just pure 100-level fine overdrive tuning, Y-axis variable overdrive gain along the vertical axis (to accomodate time differential between LCD scanout and the global strobe), strobe length and strobe phase tuning, similiar to Strobe Tuning Animations. More than 90% of developers at OEMs don't understand this, and don't know how to spec-out properly to their scaler vendor to have enough firmware programmability in the scaler/TCON (that chip on the rear of LCD panel), and then strobing is sabotaged -- sometimes an order of magnitude worse strobe crosstalk than it could have been with the same panel.

I think that it makes sense to use scanning backlight in at high refresh rates when global strobing is not possible due to limited refresh rate of LCD panel or limited interface bandwidth. For example, using 50% duty cycle of backlight at 240 Hz would result in ~2ms persistence.

Blur Busters opinion for LCDs (with the GtG issue) is you want at least a 75%-80%+ reduction in motion blur reduction in order for strobing to become worth being enabled (against disadvantage of strobing).

So you want one-quarter duty cycle for LCDs or better (e.g. 2ms strobe on 8ms refresh cycles, aka 120Hz). OLEDs have fast GtG and no crosstalk so even smaller duty cycles benefit them with fewer tradeoffs, so half duty cycle is OK for them (e.g. LG CX television OLED BFI during 4K 120Hz is 50% duty cycle and still looks great).

Any less blur reduction from strobing, limited benfits usually becomes preferable to keep it disabled. Unless GtG is fast enough, since a longer strobe-flash length means less dark time between refresh cycles (2ms strobe at 240Hz = only 2ms between refresh cycles to complete LCD GtG). That's why it's easier to reduce strobe crosstalk at lower refresh rates + shorter flash duty cycles.

Also, strobing looks best at framerate=refreshrate=stroberate, which means 120fps@120Hz strobing looks so much more beautiful than 200fps@240Hz strobing. The lack of motion blur amplifies visibility of microstutters, not to mention the erratic duplicate image effects from repeat-refresh cycles of unsynchronized frame rates. Strobing decouples motion blur from refresh rate, since 1ms flash at 120fps@120Hz looks the same motion blur as 1ms flash at 240fps@240Hz -- motion blur is effective frame visibility time.

Of course, GtG transition speed would need to keep up with this but maybe slightly more aggressive overdrive tuning could be used since potential overshoots would be (partially) hidden during the OFF phase of backlight?

Yes, that's part of the tuning work. Most panels have 100-level overdrive adjustability hidden within it, and this is key to milking a lot of strobe-backlight gains. You can even vary the ovedrive gain along the Y axis like LightBoost does -- see item 5 of How it Works at Marc Repnow's LightBoost reverse engineering. But other vendors do it too sometimes. However, if GtG is fast enough (1ms), you can forgo this and just tune global overdrive gain to the perfect level for a specific refresh rate.

The Overdrive Programming Rabbit Hole
Ideally, I prefer more custom overdrive tuning (generate my own 256x256 overdrive lookup tables), but most vendors simply use low resolution overdrive lookup tables (17x17) and interpolate in-between values. There's not much memory in the scaler/TCON chip in the panel, for overdrive tuning memory. That last 10% of improved overdrive tuning is 10x more complex than the first 90% of overdrive tuning (simple Overdrive Gain multiplier on a single panel-wide bog-standard common 17x17 interpolated OD LUT). For more information about the overdrive rabbit hole, check these out: overdrive LUT, Why VRR needs variable OD, VRR overdrive complexity. I can say all this outside NDA because all these are multi-vendor stuff that are already in research papers (like mention of 17x17 OD LUTs in univeral OD research paper). You can try to make OD universal, but making it panel-specific can improve strobing a fair bit -- however, going non-standard can be quite expensive. So I try my best within the standard tools available in scaler/TCON, and it's amazing how much I can improve panels with just the existing adjustment tools that I can adjust better than some vendors do at the factory...

Blur Busters can make strobe good at all refresh rates
I use an algebra method to extrapolate strobe tuning to all refresh rates based on just measuring 10 different refresh rates, and then using a Cubic Regression Formula to curve-fit the "overdrive gain"-vs-"refresh rate" graph. Then a separate graph for different vertical totals, then a simple linear interpolation based off the vertical total. Which means Blur Busters can strobe ALL refresh rates at ALL vertical totals, likely more cheaply than many vendors can tune only 3 strobed refresh rates -- with similar or better strobe quality, and only needing a fast 1ms-GtG LCD (like a 2020-or-newer high-Hz "Fast IPS") and a global Overdrive Gain.

While Blur Busters specializes in global strobe, I also want to see scanning strobe succeed in the future!

[MCLV]

Blur Busters opinion for LCDs (with the GtG issue) is you want at least a 75%-80%+ reduction in motion blur reduction in order for strobing to become worth being enabled (against disadvantage of strobing).

You got me thinking about this since one would naively expect that any reduction would be good especially since it would hide the worst part of GtG transition. So I tried to include GtG transition in my simulation. It is not perfect (blending with previous and next frame is not handled correctly, it behaves like they would have been black) and uses simple exponential decay function to model GtG but I think it is enough to see what happens.

Figure 1: Motion blur of 32 pixels

motion_blur6.png (54.76 KiB) Viewed 21729 times

Figure 2: Motion blur + GtG transition, backlight always ON

motion_blur5.png (84.38 KiB) Viewed 21729 times

Figure 3: Motion blur + GtG transition, backlight 75% ON, 25% OFF

motion_blur4.png (88.97 KiB) Viewed 21729 times

[MCLV]

(continuation of previous post)

Figure 4: Motion blur + GtG transition, backlight 50% ON, 50% OFF

motion_blur3.png (81.57 KiB) Viewed 21722 times

Figure 5: Motion blur + GtG transition, backlight 25% ON, 75% OFF

motion_blur2.png (69.95 KiB) Viewed 21722 times

Figure 6: Motion blur + GtG transition, backlight 10% ON, 90% OFF

motion_blur1.png (54.36 KiB) Viewed 21722 times

It is clear that artifacts appear in the image already at small reduction of ON time, see Figure 3. However, reduction of motion blur is not significant at this stage so the overall image quality does not improve. One can look at the figures and assess what would his/her personal threshold would be but it is obvious that the image quality is not monotonously improving with decreasing ON time but there is some area where image is degraded instead. And that basically confirms your point.

[Chief Blur Buster]

You got me thinking about this since one would naively expect that any reduction would be good especially since it would hide the worst part of GtG transition.

Some people hate the artifacts of strobe crosstalk enough to prefer gaming with more motion blur.

People are picky about different things. Stutter? Tearing? Blur? Trailbehind/Trailahead artifacts such as ghosting/coronas/crosstalk?

Figure 3: Motion blur + GtG transition, backlight 75% ON, 25% OFF

That looks ugly. And that's a relatively accurate approximation of what happens with long strobe lengths + slow GtG. I prefer to play with more motion blur than to see that, actually.

If the crosstalk was removed, then even slight blur reduction is fine.

Longer black time is needed anyway to hide LCD GtG more completely between refresh cycles.

Much better. The busy graphics of a game will make it hard to see the crosstalk of this game. Also, black-to-white and white-to-black is generally very fast (so the bottom won't have as much crosstalk as seen), it's usually black-to-intermediate-color, or intermediate-color-to-black that are slowest (especially on VA panels). The GtG heatmap (ala HardwareUnboxed style) is very inconsistent with hot zones at different parts of the heatmap, so you see more crosstalk with certain colors and less crosstalk with other colors.

And that basically confirms your point.

As usual, your simulations are relatively accurate simulations of what I actually see in real-life (with some very minor omissions not worth nitpicking over; the photoshop blur filter behaves slightly differently from display persistence constant linear-blur; but not meaningful enough to wreck the simulation).

The increasing OFF time hides more GtG, which makes crosstalk fainter while making the image sharper.

For displays like OLED, this is not an issue (it doesn't crosstalk like an LCD at any duty cycle ratios).

Strobe crosstalk is a quirk specific to LCD as an interaction between panel response and backlight response. Strobing only becomes really good at brief backlight duty cycles (long OFF versus short ON time).

BTW, some interesting old talk about LCD GtG interactions with strobe backlights:
viewtopic.php?f=7&t=418&start=10