Blur reduction possible on any monitor via software ?

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.
User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Blur reduction possible on any monitor via software ?

Post by Chief Blur Buster » 15 Nov 2017, 14:08

I "void" the video as being uninterpretable due to camera sensor behavior:

It's just not possible to correctly interpret a strobe backlight via only 120fps high speed video.

Think of it this way. If your strobe length is 2ms, you need 500fps to capture all 2ms timeslices with only 4ms fuzz margin (as strobe can overlap two high-speed-video-frames). If your strobe length is 1ms, you need 1000fps to capture all 1ms timeslices with only 2ms fuzz margin.

Additionally, camera sensor scan also interferes with interpreting high speed videography of strobe backlights.

Can you find a faster camera with at least 480fps or faster filming speed, preferably 1000fps, and measure at 60Hz, please? And if you're not filming 1000fps, please film at a distance further away (screen only ~1/3 or ~1/4 height of video frame). This will reduce camera-sensor-scan interference artifacts. The camera sensor scanout interferes with correct interpretation of screen scanout. (Workaround: Film upsidedown or sideways). Camera sensors are usually not global shutter, but has a rolling scan, and that makes it hard to correctly interpret when sensor scan is extremely slow like a screen scan. A 1000fps camera will at least scanout in 1/1000sec (or faster), but I can settle for 240fps.

___________________________

Alternative: If you don't have a high speed video camera, use a pursuit camera instead. Much easier! iPhone/Androids make good pursuit cameras if you configure them correctly, and slide them accurately at exact screen motion speed while taking photo.

You can analyze via just human eye, or if you want to share pictures -- then use pursuit camera photography on http://www.testufo.com/crosstalk .... Pan your camera sideways while taking a photograph. Keep repeating until the photo looks sufficiently WYSIWYG.

-- Does the crosstalk zone vibrate up/down? (Cause: strobe timing is varying)
-- Does the screen have random candlelight flicker? (Cause: strobe length is varying)
-- Is the crosstalk worst at center, or at top/bottom? (Cause: strobe timing position is wrong)

Candlelight flicker (strobe length varying problem) is easier to see in a maximized white screen -- such as a "Windows Notepad" window.

Also, can you test 60Hz with the dotclock of 106Hz (Basically a 60Hz mode with large Vertical Totals -- putting the extra dotclock room in adding extra pixels to a larger blanking interval -- vertical sync or porches).
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!

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Blur reduction possible on any monitor via software ?

Post by Chief Blur Buster » 15 Nov 2017, 14:22

Sparky wrote:Even in the 60hz video you can see 3 frames in a single exposure.
Yep.

This is often a problem for panels with overdrive that is not strobe-quality.
Just taking a static photograph (not video) with an exposure of a tiny fraction of a refresh cycle (e.g. 1/500sec photograph), and if you see multiple refresh cycles in that one photo -- your LCD is ghosting too much over refresh cycles and you cannot hide that kind of ghosting via a strobe backlight between refresh cycles.

You pretty much really need to clean up LCD GtG as much as possible (over 80% of it) in the VBI between refreshes -- not take your merry time doing LCD GtG pixel transitions over 3 refresh cycles!

The wizards at NVIDIA is very good at it, and some companies such as Samsung has turned this into quite a good piece of art. That said, modern "1ms TN panels" generally have sufficiently acceptable out-of-box behaviours for adequate strobe quality (via monitor firmware modification or monitor motherboard/microcontroller hack) via approximately ~3ms-4ms+ blanking intervals -- no special overdrive lookup tables.

Grab any good 1ms TN FreeSync compatible 144Hz unstrobed panel (generic) hack a microcontroller to allow its backlight to strobe, use large blanking intervals -- and you've got pretty usable strobing already, out-of-box, on a cheap panel, patent-free. But hacking cheaper 60Hz panels (like older TN or IPS panels, that don't have enough refresh rate headroom), is a lot harder to get ghosting-free -- especially for a panel where you are getting 3 refresh cycles streaking into each other at any instantaneous moment due to poorly-overdriven LCD GtG.

As always, Large Vertical Totals (long-duration VBLANK / VBI / VSYNC) can be forced by the computer side in many cases. This is achieved via a Custom Resolution Utility (e.g. ToastyX) if the LCD panel supports synchronous scanout from signal -- most VRR-compatible panels already support synchronous scanout (since VRR support essentially forces the panel to be able to support varying vertical totals -- which makes Large Vertical Total hacking much easier in theory -- which makes generic strobe backlights easier without too much crosstalk).

If your panel supports 106Hz, you'll definitely want to use 60Hz with the dotclock of 106Hz focussed in enlarging the VBI. Give me screenshots of your ToastyX timings for 60Hz and 106Hz (two screenshots: one of each), and I can create you recommended "special Large Vertical Total 60Hz" ToastyX numbers to try. It's really a simple mathematical calculation to me, to maintain dotclock but reduce refresh rate -- simply via converting the refresh rate bandwidth into blanking interval bandwidth instead. This technique greatly reduces double-image artifacts during homebrew strobing experiments, as long as the monitor successfully syncs to the large-VBI signal.

___________

While I'm still unsure that DDC/CI is precise enough to control the flashing of a backlight, I'm still very interested to see if this might succeed on at least some models of monitors. I hope you find a 1000fps camera and film your strobing, so I can better analyze this.

Monitor manufacturers read these forums too. Some of them has even learned a thing or two. (Even NVIDIA added "ULMB Pulse Width" to their menus because of Blur Busters -- LightBoost 10% vs 50% vs 100% -- when I reached out to some of their reps such as Brian Rizzo and his team almost five years ago to convince them to add a strobe-length adjustment!

And we're the ones who convinced BenQ/Zowie to add strobe phase / strobe length adjustments, which are now in all the service menus of all strobe-capable BenQ/Zowie gaming monitors ever made on the market (Since the very first XL2720Z).

I remember the days when LG's first strobe backlight was really terrible (very crosstalky -- original 24GM77 -- did not even try to "cram GtG into VBI") but they started getting much better on their next attempt (24GM79G-B when they finally figured out the "cram GtG into VBI" thing, finally). Huge improvement in strobe quality. Without me informing them about BlurBusters, they have advertised some of their stuff with TestUFO tests (cool).

There's more, but: It is pretty clear many manufacturers find BlurBusters a big help in getting their blur reduction modes quite usable enough (not as good as ultra-well-calibrated ULMB, but finally usable indeed).
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!

Curi0
Posts: 22
Joined: 12 Oct 2017, 09:07

Re: Blur reduction possible on any monitor via software ?

Post by Curi0 » 16 Nov 2017, 01:32

Chief Blur Buster wrote:
Sparky wrote:Even in the 60hz video you can see 3 frames in a single exposure.
Yep.

This is often a problem for panels with overdrive that is not strobe-quality.
Just taking a static photograph (not video) with an exposure of a tiny fraction of a refresh cycle (e.g. 1/500sec photograph), and if you see multiple refresh cycles in that one photo -- your LCD is ghosting too much over refresh cycles and you cannot hide that kind of ghosting via a strobe backlight between refresh cycles.

You pretty much really need to clean up LCD GtG as much as possible (over 80% of it) in the VBI between refreshes -- not take your merry time doing LCD GtG pixel transitions over 3 refresh cycles!

The wizards at NVIDIA is very good at it, and some companies such as Samsung has turned this into quite a good piece of art. That said, modern "1ms TN panels" generally have sufficiently acceptable out-of-box behaviours for adequate strobe quality (via monitor firmware modification or monitor motherboard/microcontroller hack) via approximately ~3ms-4ms+ blanking intervals -- no special overdrive lookup tables.

Grab any good 1ms TN FreeSync compatible 144Hz unstrobed panel (generic) hack a microcontroller to allow its backlight to strobe, use large blanking intervals -- and you've got pretty usable strobing already, out-of-box, on a cheap panel, patent-free. But hacking cheaper 60Hz panels (like older TN or IPS panels, that don't have enough refresh rate headroom), is a lot harder to get ghosting-free -- especially for a panel where you are getting 3 refresh cycles streaking into each other at any instantaneous moment due to poorly-overdriven LCD GtG.

As always, Large Vertical Totals (long-duration VBLANK / VBI / VSYNC) can be forced by the computer side in many cases. This is achieved via a Custom Resolution Utility (e.g. ToastyX) if the LCD panel supports synchronous scanout from signal -- most VRR-compatible panels already support synchronous scanout (since VRR support essentially forces the panel to be able to support varying vertical totals -- which makes Large Vertical Total hacking much easier in theory -- which makes generic strobe backlights easier without too much crosstalk).

If your panel supports 106Hz, you'll definitely want to use 60Hz with the dotclock of 106Hz focussed in enlarging the VBI. Give me screenshots of your ToastyX timings for 60Hz and 106Hz (two screenshots: one of each), and I can create you recommended "special Large Vertical Total 60Hz" ToastyX numbers to try. It's really a simple mathematical calculation to me, to maintain dotclock but reduce refresh rate -- simply via converting the refresh rate bandwidth into blanking interval bandwidth instead. This technique greatly reduces double-image artifacts during homebrew strobing experiments, as long as the monitor successfully syncs to the large-VBI signal.

___________

While I'm still unsure that DDC/CI is precise enough to control the flashing of a backlight, I'm still very interested to see if this might succeed on at least some models of monitors. I hope you find a 1000fps camera and film your strobing, so I can better analyze this.

Monitor manufacturers read these forums too. Some of them has even learned a thing or two. (Even NVIDIA added "ULMB Pulse Width" to their menus because of Blur Busters -- LightBoost 10% vs 50% vs 100% -- when I reached out to some of their reps such as Brian Rizzo and his team almost five years ago to convince them to add a strobe-length adjustment!

And we're the ones who convinced BenQ/Zowie to add strobe phase / strobe length adjustments, which are now in all the service menus of all strobe-capable BenQ/Zowie gaming monitors ever made on the market (Since the very first XL2720Z).

I remember the days when LG's first strobe backlight was really terrible (very crosstalky -- original 24GM77 -- did not even try to "cram GtG into VBI") but they started getting much better on their next attempt (24GM79G-B when they finally figured out the "cram GtG into VBI" thing, finally). Huge improvement in strobe quality. Without me informing them about BlurBusters, they have advertised some of their stuff with TestUFO tests (cool).

There's more, but: It is pretty clear many manufacturers find BlurBusters a big help in getting their blur reduction modes quite usable enough (not as good as ultra-well-calibrated ULMB, but finally usable indeed).
CRU Timings
106hz
Image
60hz
Image

I recorded the video using a smartphone at 120fps and slowed it down to x0.125.

Looking at the radeon driver radeon_set_backlight function (http://elixir.free-electrons.com/linux/ ... ders.c#L89) it writes to IOMEM.

Still even with the crosstalk a strobed backlight should have advantages. In games my monitor doesn't have ghosting but I think the motion blur must be hiding it.

Should I flash the backlight on during the long VBI or have a short as possible VBI and flash the backlight just before the next frame (probably less input lags with this method)

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Blur reduction possible on any monitor via software ?

Post by Chief Blur Buster » 17 Nov 2017, 19:24

Curi0 wrote:I recorded the video using a smartphone at 120fps and slowed it down to x0.125.
I know, but the video is useless -- because it won't allow me to correctly scientifically analyze the video.
You need finer granularity for strobe-backlight analysis.

If there is no way to get 1000 frames in 1 second (1000 frames per second) high speed camera, then it won't work well enough for strobe-backlight analysis. The frame length must be equal to strobe length or less, so that some frames in between flashes are completely black in between fully-illuminated frames. 120fps won't allow you to do that. You need a camera that takes more pictures faster so you can have completely black video frames in between strobe backlight flashes. It's not possible to analyze your video, I'm sorry -- your video is useless for scientific analysis. If you can borrow some camera capable of at least 1000fps (or even ~480fps minimum). Slow-motion speed is not important. Number of frames per second is important for high-speed-video analysis of strobe backlights.

That said.... let's do a "spot check":
You could also test using the finger-wave test on white background. Does your backlight look like it is flickering successfully?

Another alternative is to use photograph (while pursuiting the camera sideways) instead of video camera. You can do it with any smartphone. A pursuit camera is simply a moving camera (taking a photograph, not video).

You can practice pursuit camera via http://www.testufo.com/ghosting -- wave your camera sideways while taking a photograph. The ladder track should show up in the photo. There are instructions at http://www.blurbusters.com/motion-tests/pursuit-camera but you can also hand-wave the camera for makeshift analysis. Once you've practiced successfully, do the hand-wave at http://www.testufo.com/crosstalk

Take a pursuit photo without strobing, then another pursuit photograph with strobing -- and you can post to compare the before/after.
Curi0 wrote:Looking at the radeon driver radeon_set_backlight function (http://elixir.free-electrons.com/linux/ ... ders.c#L89) it writes to IOMEM.
That doesn't guarantee timing-precision nor latency-jitter precision.
Curi0 wrote:Still even with the crosstalk a strobed backlight should have advantages. In games my monitor doesn't have ghosting but I think the motion blur must be hiding it.
Many games have software-based motion blur turned on.
Curi0 wrote:Should I flash the backlight on during the long VBI
Yes, during long VBI, not HBI.
You made a mistake with your 60Hz ToastyX -- you're using a large horizontal interval instead of a large vertical interval.
Curi0 wrote:or have a short as possible VBI and flash the backlight just before the next frame (probably less input lags with this method)
That's nonsense:
Anytime a monitor is outside a VBI, it is actively changing pixels on the screen.
Anytime it is actively changing pixels on screen, it's outside VBI.

A monitor refreshes pixels in a very rapid calendar-style fashion, left-to-right, top-to-bottom. Pretend your 1600x900 screen is like a massively big calendar of 900 weeks (vertically) of 1600 days-long (horizontally) each. If you had a one-million-frame-per-second high speed camera, you would actually see the pixels refresh in a calendar-style fashion (scanned sorta like a CRT). A refresh cycle is like a calendar month. Horizontal blanking intervals is like the gap between Saturday and Sunday (like adding a 100-hour pause between Saturday and Sunday) -- like pausing time between weeks. Vertical blanking intervals is like the gap between months (adding several weeks of pausing between months) -- like pausing time between months..

Liquid crystals are moving molecules. Molecules have momentum. An LCD pixel takes time because it takes time for the liquid crystals to rotate (blocking or unblocking polarized light). That's why after a pixel is refreshed, the pixels still have momentum (it's coasting "Grey to Grey" from one pixel value to the next. A pixel may be white, and the next refresh cycle wants the pixel to become grey. When the refresh cycle hits that pixel, there's a very brief rapid voltage pulse (nanoseconds) to that pixel. While the monitor is refreshing subsequent pixels (subsequent pixels in the calendar-style "scanning" of the pixel matrix), the previous pixels are in a GtG momentum -- the liquid crystal molecules still taking 1ms or 2ms to rotate pretty close to their new positions. Basically a pixel "fades" from one color to the next. The calendar style scanning is very rapid -- over 100 million pixels ("calendar day" matrix equivalent) per second, called the "dot clock" -- 1 dot clock is the refreshing of 1 pixel, and the next dotclock cycle is the refreshing of the next pixel (immediately to the right of it). Once the pixel refreshing reaches the end of a row of pixels, it begins immediately pausing the amount of horizontal blanking interval, before beginning the next row of pixels. Once the bottom edge of screen is reached in a refresh cycle, it begins pausing the amount of vertical blanking interval before the next refresh cycle.

The reason why you want to pause after a refresh cycle is to allow the bottom edge of the screen (most recently refreshed pixels) to finish as much of their "GtG transition" momentum as possible (remember, LCD pixels are essentially molecules being rotated into a new position to change color -- they are behaving as shutters to partially block/unblock polarized light (in combination with polarized sheets & color filters) to generate all that colorfulness. An LCD monitor is still exactly like a 1980s LCD wristwatch -- it's essentially black and white pixels that's been turned to do greyscales, then subpixelled (into red, green, blue) to be combined to give you the full color pixels. So the exact same technology, in an old wristwatch, is being used to create all that beautifulness on a colorful LCD screen! All that molecules in motion.

(It's actually much more complicated than that, but I'm trying to explain the process of how it all works, in just a forum post)

Anyway, back on topic:

Trying to flash the strobe backlight while the pixels are in the middle of their transitions, creates more multi-image effects (called strobe crosstalk). So if your goal is to find the "point of minimum strobe crosstalk", you need to flash the LCD pixels BETWEEN refresh cycles instead.

Whenever a monitor is in VBI, it means the monitor is not actively refreshing LCD pixels. The longer the VBI is, the more completely finished the image on the LCD panel is (thanks to the momentum of the LCD pixels finishing, thanks to the longer VBI pause). The more clear the LCD screen image is (in total darkness) before flashing the backlight to allow the refresh cycle to be seen by human eyes.

So.... The bottom line is you want to flash the backlight between physical refresh cycles.

Due to the GtG lag, you do want to adjust the phasing of a strobe backlight flash slightly later -- basically roughly 1/2 a GtG transition forward in phasing. If you mathematically calculate your VBI is exatly 3ms long (it will vary depending on CRU numbers) then normally an engineer might think you'd flash for 1ms in the center (dark for 1ms, on for 1ms, dark again for 1ms, for a 3ms VBI). But that's not ideal, because of the GtG lag. If your GtG is 1ms, then you want to add half a GtG -- approximately +0.5ms offsetting. So a 3ms VBI might be: dark for 1.5ms, flash for 1ms, dark for 0.5ms.

Now, not everybody has the luxury of such a long VBI. You might only have a 2ms VBI and you want to flash for 2ms. So normally you'd think you want to turn on the backlight for the entire VBI. But because of the GtG momentum lag (if you have 1ms GtG) then you'd want to turn ON +0.5ms after beginning of VBI (the time it finished refreshing the last pixel of the previous refresh cycle) and then turn OFF +0.5ms after end of VBI (the time it begun to refresh the first pixel of the next refresh cycle).

Remember:
Instant of beginning of VBI: The moment right after finishing refreshing the pixel of last refresh cycle.
Instant of end of VBI: The moment the first pixel of the new refresh cycle is begun to be updated.

The best video camera to analyze a strobe backlight is called a "Phantom Flex" high speed camera or similar. However, I will settle for a 1000fps or 480fps high speed camera (some of these can be purchased for ~$200 off eBay).

Anyway:
Bottom line:
Shorter VBI is always worse crosstalk. It's law-of-physics like the speed of light.

The bigger the VBI, the more time the screen is waiting between refresh cycles instead of trying to "fade a pixel from one color to the next" (LCD Grey-To-Grey pixel transitions). This looks like a hazy vertical screen wipe in high-speed-video (480fps+ and 1000fps+).

The higher speed the video, the easier it is to see the LCD GtG in action. 1ms GtG on a 1/120sec (8.3ms) refresh cycle shows up as a "GtG Zone" approximately 1/8th screen height. But this only works if you have a high speed camera fast enough to capture the 1ms GtG (1000fps = 1ms per video frame). Or if you have a 1ms strobe length or 2ms strobe length. That's why 120fps is 100% useless for high-speed-video analysis of LCD GtG / strobe backlights. You really need a faster camera that can capture 1ms-granularity frames, one full thousand photographs per second (1000 frame per second) video camera, to capture all the 1ms timeslots, for proper analysis. Regardless, for high speed analysis, true video frames need to be a tiny fraction of a refresh cycle, no matter how fast or slow GtG is, but having a camera with frames far briefer than GtG aids in analysis greatly.

Nontheless, a high speed video camera is optional -- it only makes it easier to give you technical support for strobe backlight hacking. It just means it'll be much harder to help you remotely (without high speed video footage) unless you can teach yourself how to do a static photograph with a camera-in-motion (panning camera in sync with motion, while taking a photograph), as an alternative method of strobe crosstalk analysis.

Nonteheless, let's work on your ToastyX numbers.

I'll follow up with new ToastyX calculations for you. Keep tuned.
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!

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Blur reduction possible on any monitor via software ?

Post by Chief Blur Buster » 17 Nov 2017, 19:52

Curi0 wrote:CRU Timings
106hz
Image
60hz
Image
You're using large HORIZONTAL blanking interval, which is useless for strobe crosstalk reduction. You need to transfer that bandwidth into a large VERTICAL blanking interval. I explain why you need to use vertical (VBI) instead of horizontal (HBI) in my previous reply.

Make sure your porches are not zero.
While it's possible to use a zero Back Porch, it is not recommended -- but apparently it must work with your specific display.

Instructions on converting a high refresh rate into a "larger blanking interval" lower refresh rate:
1. Start with your successfully-working "Highest-Hertz" mode
2. Lock your dotclock (click the radio button on "Pixel Clock"
3. Lock your total (click the radio button on "Total"
4. Keep Horizontal unmodified. Don't touch the horizontal numbers!
5. Instead, increase your Vertical blanking interval (by adjusting "Total" upwards in the "Vertical" column) until Refresh Rate falls to 60Hz. Everytime you increment your Vertical Total, your Refresh goes down (if your "Pixel Clock" is locked).
6. Now you've successfully traded-off VBI with refresh rate. Lower Hz in exchange for a larger VBI.
7. UNCHANGED: Everything except "Vertical Total" and "Refresh Rate"
8. CHANGED: "Vertical Total" bigger, "Refresh Rate" smaller. Only two numbers change!
9. Resulting screenshot:

Image

No guarantee this will work properly, but this is the easiest/most reliable way to attempt a large vertical total.

*** IMPORTANT NOTE TO OTHER READERS, DO NOT USE THESE NUMBERS. You must have successfully working initial high-refresh-rate numbers before you can successfully do "After" numbers (low Hz with large VBI). The "Before" numbers varies from monitor to monitor and is subject to experimentation beyond the scope of this forum post***

Try these numbers. Assuming panel scan is synchronous with signal scan, the strobe crostalk should go down (provided it's strobing successfully: which may be another problem altogether because if the monitor is buffering the DDC/CI MCCS/VCP backlight register, and only updating the actual hardware backlight state once a refresh cycle -- that makes proper strobing impossible because of your monitor's unwanted potential buffering of backlight state updates.... that is why we need a 1000fps camera to accurately analyze successful strobe backlight operation..... but one could also simply do the finger-wave test in a fully-maximized Windows Notepad window -- you'll see a stroboscopic effect if the backlight is successfully strobing).
Attachments
cru.png
cru.png (25.51 KiB) Viewed 4471 times
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