DIY Backlight Strobing [must read for experimenters!]

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

Re: DIY Backlight Strobing [must read for experimenters!]

Postby sharknice » 15 Jan 2014, 17:16

HeLLoWorld wrote:Just realized that randomized or algorithmic pattern order of the update of pixels in one frame (for multiplexed oled for example, crt is not doable and lcd-tft do not blink individually) (also suggested by Carmack if I remember) would unfortunately be very bad for this reason : it would randomly distribute the age of each pixel across the screen, while the picture is from an instant timeframe. When tracking a moving background it would be a mess, far more than top-down where at least you got some local spatio-temporal coherence.

Which is to say, top-down seems ugly because it's non-isotropous, but it's the least sucking way of doing it.


If you look into advanced video codecs they deal with similar issues of only updating parts of the frame. There are always going to be points where you'll still need update the entire frame and you can't compress anything without sacrificing video quality. Perhaps it would be worth it for having a higher frame rate when possible.
As of now I think it is a little too much processing to really put into displays.
User avatar
sharknice
 
Posts: 230
Joined: 23 Dec 2013, 17:16
Location: Minnesota

Re: DIY Backlight Strobing [must read for experimenters!]

Postby James Freeman » 16 Jan 2014, 03:23

Anyone knows how an LCD VBlank signal actually looks like?

Is it normally High and the actual blanikning intervals are low (dips) like on a CRT?
Or is it normally Low with short Highs like a clock pulse?


Accelerated scanout isn't needed for continuous backlight.
It does nothing to speed up individual LCD pixel transitions, and actually degrades color quality by spending less time juicing voltage into pixels (this is why 144Hz has lower color quality than 60Hz).


So, the lower the Total Pixels, the smaller is the Blanking, the longer the Voltage can work, the better are the Colors.
What are the "Front Porch (pixels)" and the "Sync Width (pixels)"?
How do they effect the picture and the synchronization?

Also, in terms of stability what would be a better/safer/stable setting?
User avatar
James Freeman
 
Posts: 14
Joined: 11 Jan 2014, 09:06

Re: DIY Backlight Strobing [must read for experimenters!]

Postby HeLLoWorld » 16 Jan 2014, 17:28

Hi, when I did this I was not the hardware expert guy so I can't provide experience or details :) but it was vga and the vbl signal was a clean short spike! I did not adjust offscreen pixels for that precise test. I am in a different physical place now so I don't do things now. Good luck :)
HeLLoWorld
 
Posts: 33
Joined: 07 Jan 2014, 18:44

Re: DIY Backlight Strobing [must read for experimenters!]

Postby Chief Blur Buster » 16 Jan 2014, 18:33

James Freeman wrote:So, the lower the Total Pixels, the smaller is the Blanking, the longer the Voltage can work, the better are the Colors.

Theoretically yes, but insignificant. Adjusting porch/sync only gives you a few percent more banwidth (about 5% difference). The difference between 60Hz and 120Hz (a 100% difference) is much bigger. So adjust sync/porch for different reasons, such as trying to enlarge the blanking interval for better strobing.

James Freeman wrote:What are the "Front Porch (pixels)" and the "Sync Width (pixels)"?
How do they effect the picture and the synchronization?

Depends on:
If your dotclock remains the same (refresh rate goes up); or
If your dotclock is slowed down (to maintain same refresh rate)

dotclock is number of pixels per second. It's (vertical total) times (horizontal total) times (refresh rate).

James Freeman wrote:Also, in terms of stability what would be a better/safer/stable setting?

Very monitor dependant. For strobing, you want to get Vertical Total as big as possible relative to Vertical Resolution before it becomes unstable. Unfortunately, you often can't make it big enough without the display going unstable, so you're possibly fighting against limitations. I was able to get to about a 1200 Vertical Total on some 1080p display, but was able to get beyond 1350 on a different 1080p display. It's sometimes quite fiddly and tricky.

You find you won't be able to enlarge your blanking interval (vertical sync pixels and/or vertical porch pixels) if your refresh rate is already very high, because you then hit against your maximum dotclock limit (the GPU limit, and/or the display limit). So you end up having to lower your refresh rate to use larger blanking intervals. That's why you want lots of bandwidth room to begin with, on a panel that can refresh at a high rate, in order to end up with something strobeable.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3250
Joined: 05 Dec 2013, 15:44

Re: DIY Backlight Strobing [must read for experimenters!]

Postby HeLLoWorld » 25 Jan 2014, 22:11

While I'm at it, I think the line aliasing test isn't correct from a rendering standpoint, it's not symmetrical, the moving sampling artifacts are not the same at all on the left and on the right as it moves.
I'm interested in line drawing and subpixels, that's why I tell.
HeLLoWorld
 
Posts: 33
Joined: 07 Jan 2014, 18:44

Re: DIY Backlight Strobing [must read for experimenters!]

Postby Chief Blur Buster » 26 Jan 2014, 03:26

Mechanical shutter related stuff moved to this thread: viewtopic.php?f=7&t=253
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3250
Joined: 05 Dec 2013, 15:44

Re: DIY Backlight Strobing [must read for experimenters!]

Postby blargg » 20 Sep 2014, 04:58

I've been following this work for a while and I recently got my first LED-backlit LCD, an Acer S271HL bid. After repairing the backlight driver board's vias, I hated how bright it was and while modifying it to lower the PWM rate, I figured I'd try a pulsed backlight, not expecting it to work very well. I've been amazed at how well it worked, and how little artifacts there are. This is a 60Hz monitor and the pulsed backlight flickers like crazy with lots of bright windows open, but is hardly noticeable for retro video games full-screen.

I'm very surprised that the LCD updates things so quickly. At first when I tried it, I just had a 1ms strobe at 60Hz without sync. Even then the glitchy tear when showing full-screen horizontal scrolling images was less than 10% of the LCD height. It's as if the LCD is refreshing everything in a ms or two. Colors/white point don't seem any different than normal, as I had read can occur with short LED strobes and LCDs not being fully refreshed.

I took some pursuit pictures by repeatedly manually moving the camera along with the UFO and finally getting a well-tracked photo. You can see by the four after-images of the text below in both that tha camera (iPhone 4) was using a 1/15 sec. shutter.

Image

Image

Image

It seems mainly that the overdrive is leaving (slight) artifacts, but there's no option to disable them, even in the service menu. BTW, to access the service menu, turn off monitor, and whole holding left-most button down, press power. Release button when picture appears. Then press left-most button again. Only slightly useful option is RGB gain/offset controls.

I took a couple of a Game Boy Advance game on an emulator full-screen (so it's around 7x normal size). This is when scrolling, where the overdrive leaves artifacts. These occur regardless of where the moving object is vertically, so it doesn't seem to be an LCD response time issue.

Image

Image

The modification is really simple. I cut the PWM control signal between the signal board and the LED driver board, then connected four wires: GND, +3.3V, PWM out on signal board (so I can read the brightness set in the menu, and determine vsync), and PWM in on driver board, and threaded them through the back of the monitor to a breadboard. I'm using an attiny85 (8-pin IC) to process the signals, and when polished it'll go back inside the monitor, and shouldn't need any support components besides a decoupling capacitor.

As for vsync, I was fortunate that the monitor's PWM signal re-synchronizes itself at the beginning of each frame. There is a slight timing abnormality in the PWM period at vsync that I watch for every frame.

At this point after working on this for the day, the brightness control at 50-100 gives normal 1kHz PWM dimming, with 50 giving a really dim display, and 100 full brightness. Brightness 49 gives a really dim display, but is in strobed mode (1ms strobe). Brightness 0 gives maximum strobed brightness (5ms strobe).
blargg
 
Posts: 66
Joined: 20 Sep 2014, 03:59

Re: DIY Backlight Strobing [must read for experimenters!]

Postby Chief Blur Buster » 22 Sep 2014, 19:29

blargg wrote:I've been following this work for a while and I recently got my first LED-backlit LCD, an Acer S271HL bid. After repairing the backlight driver board's vias, I hated how bright it was and while modifying it to lower the PWM rate, I figured I'd try a pulsed backlight, not expecting it to work very well. I've been amazed at how well it worked, and how little artifacts there are.

Excellent, you are one of the few DIY strobe backlight modders to have successfully followed the HOWTO: Electronics Hacking: Creating a Strobe Backlight.

blargg wrote:This is a 60Hz monitor and the pulsed backlight flickers like crazy with lots of bright windows open, but is hardly noticeable for retro video games full-screen.

The single pulse per refresh is the major piece of the puzzle to eliminate LCD motion blur. But as you know, at 60Hz, that can flicker like crazy! That's why the commercially developed strobe backlight often recommend running at 120Hz, and some of them don't even let you use a lower refresh rate.

blargg wrote:I'm very surprised that the LCD updates things so quickly. At first when I tried it, I just had a 1ms strobe at 60Hz without sync. Even then the glitchy tear when showing full-screen horizontal scrolling images was less than 10% of the LCD height. It's as if the LCD is refreshing everything in a ms or two.

Modern TN LCDs refresh fast enough to gain stunning benefit from strobe backlights nowdays, so it is not surprising.

If your LCD controller is very flexible with timings -- try playing with PowerStrip/ToastyX/NVIDIA Custom Resolution and enlarge the vertical blanking interval. You can completely hide this by using a large vertical blanking interval, a vertical blanking interval of 2-3ms will ofte completely hide 99%+ the GtG transitions of a typical 1ms TN display. Assuming your LCD scanout is synchronized to the dotclock (like on some modern TN monitors like the BENQ Z-Series), you get an accelerated LCD scanout followed by a longer pause between refresh cycles.

This is the "Vertical Total" trick. You may have seen other forum posts about this elsewhere in Blur Busters Forums; This is called the "Vertical Total 1350" trick used by BENQ Z-Series monitor users, to reduce this strobe crosstalk. That's because 1350 scanlines are output -- 1080 visible scanlines of pixels and 270 blanking interval scanlines (1080 + 270 = 1350), for a dummy delay of 270/1350ths of 1/120sec (this turns out to be ~2ms) which is good for letting GtG pixel transitions settle before the next refresh cycle begins. Your display may work with smaller or larger vertical totals, but it's excellent for hiding strobe crosstalk (fuzzy/glitchy tearline) on LCD controllers/displays that refreshes in sync with the dotclock (and accelerates scanout at higher dotclocks, making longer pauses bewteen refresh cycles convenient for letting GtG settle before flashing the backlight).

If you have control over strobe timing -- then you actually want to strobe a little bit late; e.g. turn on after the vertical blanking interval already started, and turn off after the vertical blanking interval already ended. An approximately +0.5ms offset works well. This is because of the 'lag' of visible pixel transitions after the electronic actuation of LCD pixels. So if you're able to adjust the timing (phasing) of the PWM pulses, make them strobe ON roughly halfway into the VBLANK, then strobe OFF roughly ~0.5ms after VBLANK finished and next refresh already started. In the real-world, this strobe timing plus the GtG lag will align the blurry tearline in the middle of the blanking interval, rendering it invisible.

blargg wrote:I took some pursuit pictures by repeatedly manually moving the camera along with the UFO and finally getting a well-tracked photo. You can see by the four after-images of the text below in both that tha camera (iPhone 4) was using a 1/15 sec. shutter.

Good job with the pursuit photos! You will find it easier to do the pursuit photos if you turn on the temporal test pattern (Pursuit Camera Sync Track) -- http://www.testufo.com/ghosting#pursuit=1
Even if you don't use a rail, the sync track still makes iPhone hand pursuits much easier because you can line-up the 'tickmarks' and more easily verify your resulting photo is an accurate pursuit if the tickmarks lines up in the photo. Try it! HOWTO: Pursuit Camera with Blur Busters Motion Tests (still appliable for hand pursuiting a camera -- even using an iPhone).

But good job on hand-driven pursuit camera!

blargg wrote:It seems mainly that the overdrive is leaving (slight) artifacts, but there's no option to disable them

Overdrive is extremely hard to calibrate for strobe backlights, as without overdrive, pixels may not transition fast enough, but with overdrive, you get razor-sharp ghost afterimages (clear overdrive artifacts) instead of motion-blurred overdrive artifacts).

Specialized strobe backlight monitors often use custom overdrive algorithms optimized to strobe backlights, and some of them do a really good job.

blargg wrote:As for vsync, I was fortunate that the monitor's PWM signal re-synchronizes itself at the beginning of each frame. There is a slight timing abnormality in the PWM period at vsync that I watch for every frame.

That is quite convenient; so it's simply modding the PWM to do one pulse per refresh. Your next challenge is to try to shift the phasing of the PWM pulses; see if you can make the first PWM pulse overlap the end of the blanking interval (ON somewhere during VSYNC, OFF early during next refresh cycle). This will hide most of the strobe crosstalk (blurry tear effect) between refresh cycles. Is there a way to have the electronics let you do it easily, perhaps via inserting an adjustable trigger delay circuit?

blargg wrote:At this point after working on this for the day, the brightness control at 50-100 gives normal 1kHz PWM dimming, with 50 giving a really dim display, and 100 full brightness. Brightness 49 gives a really dim display, but is in strobed mode (1ms strobe). Brightness 0 gives maximum strobed brightness (5ms strobe).

When strobing a backlight at one strobe per frame/refresh, strobe length equals display persistence. It will follow the what I now call the Blur Busters Law Of Persistence -- 1ms of strobe length equals 1 pixel of motion blurring during 1000 pixels/second. This is easily observed during http://www.testufo.com/blurtrail -- moving line becomes 1 pixel thicker for every 1ms extra you add to the strobe length, during the default motion speed (960pix/sec, similiar to 1000pix/sec). Obviously, you end up having a brightness-versus-persistence tradeoff.

A really good test is the TestUFO Panning Map Test at very fast motion speeds; the street names become more readable at shorter strobe lengths (lower brightness), and is completely unreadable when not strobing.

BTW, 1ms strobe length is not even the final frontier! At 3000 pixels/second, I am able to visually tell apart 0.5ms and 1.0ms which is rather impressive. (This translates to 1.5pix versus 3.0pix motion blurring during 3000 pixels/second panning speed, which is roughly the fastest panning speed my eyes can accurately track on a 1080p display at 1:1 view distance -- see for yourself in the TestUFO Panning Map Test (3000 pixels/sec) if you don't believe you can tell apart 0.5ms and 1.0ms strobe length). Based on this, and according to my math calcuations, motion clarity benefits will still occur all the way down to 0.1ms-to-0.2ms strobe length, especially when we strobe wide-FOV 4K displays (e.g. 4K virtual reality goggles covering a wide FOV) that allow accurate eye tracking all the way to 10,000 pixels second (0.1ms per pixel = 1 pixel of motion blurring). At such short strobe lengths, massive amounts of brightness is required in the strobes to compensate for the long dark periods -- otherwise it's quite unusaby dim! But when you're emulating old 8-bit games, often low resolution, a good 1ms or 2ms strobe length is all you need, because you have very few pixels to motion-blur at typical maximum eye-tracking speeds.

BTW, congratulations on your successful DIY strobe backlight modification of a cheap computer monitor! As you can see, it's simpler than you expected.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3250
Joined: 05 Dec 2013, 15:44

Re: DIY Backlight Strobing [must read for experimenters!]

Postby flood » 22 Sep 2014, 20:11

would it be possible to diy a strobed gsync backlight?
flood
 
Posts: 880
Joined: 21 Dec 2013, 01:25

Re: DIY Backlight Strobing [must read for experimenters!]

Postby Chief Blur Buster » 22 Sep 2014, 20:44

flood wrote:would it be possible to diy a strobed gsync backlight?

I think so, yes. It would have artifacts and side effects (variable strobe crosstalk effects that gradually got worse as you hit the maximum framerate), but it *could* be usable at 70Hz+ ...

First step though, is create an Arduino flickering LED (don't destroy a GSYNC monitor at first) and write software that transitions stroberate as seamlessly as possible, and design a strobe at a high Hz that blends to a non-strobe at low Hz. Then once you've successfully made a random-frequency LED strobe a consistent brightness (over all cases of varying frametimes and frametime transitions), then you can risk modding an expensive GSYNC monitor -- the exact same strobe algorithm could drive the pulsing of the backlight instead of a standalone LED can be used for the backlight of a GSYNC monitor. The flicker threshold could be adjustable.

The strobe algorithm for a variable-rate flicker designed to look constant brightness, would be similar to:

Image

In addition, you may have to dynamically adjust the phase of the strobe to be optimized to the current refreshrate(framerate) to keep strobe crosstalk hidden. The fact that scanout is constant, at all framerates, helps things a lot, and there should be almost no strobe crosstalk at lower framerates. Variable strobe crosstalk effects can be kept down to a minimum by using 144Hz GSYNC (fastest scanout) and then using an in-game framerate limiter (fps_max 120Hz) to keep pauses between scanouts long enough to let GtG pixel transitions finish between scanouts before strobing. Heck, you could drive the original Arduino circuit (pulsed from some spot on the GSYNC board, and attached to the backlight of the LCD panel) once you've verified the Arduino circuit is successfully making a random flicker consistent-looking brightness.

Could be an excellent exercise for a rich hardware modder that knows how to modify electronics. It would definitely be an interesting (albiet expensive) exercise. If anyone attempts this, please contact me, I'd love to give you Blur Busters coverage.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
User avatar
Chief Blur Buster
Site Admin
 
Posts: 3250
Joined: 05 Dec 2013, 15:44

PreviousNext

Return to Area 51: Display Science, Research & Engineering

Who is online

Users browsing this forum: No registered users and 1 guest