Blur Busters Forums

Hi is it possible to write a program that turns off the backlight during refreshes giving blur reduction on any monitor ? Or does software have too much latency but I think it can be solved by implementing it at low level.Would be safe for the monitors (I think LED monitors should be ok since they already use PWM) ?

Would this also be possible via a monitor firmware mod ?

you can do black frame insertion in software, but it effectively halves your refresh rate. This is what that looks like: https://www.testufo.com/blackframes

As for firmware mods, that may or may not work, it depends on the specific implementation, and requires reverse engineering. I know there are some old threads and articles here that discuss backlight modding in more depth(https://www.blurbusters.com/faq/creatin ... backlight/), but if you value your time at all you're better off just buying a monitor that already has the feature.

What about turning off the backlight during refreshes similar to normal blur reduction ?

Curi0 wrote:What about turning off the backlight during refreshes similar to normal blur reduction ?

That's what the second link is about. It's more involved than it sounds.

Curi0 wrote:What about turning off the backlight during refreshes similar to normal blur reduction ?

Backlight-based blur reduction needs to be done in hardware. A backlight is hardware. And it needs to be timed practically to the microsecond (at least for strobe length).

(1) Monitor motherboard must have control over the backlight
(2) Monitor firmware must modulate the backlight at microsecond accuracy.
Alternative: Override the monitor's backlight with an Arduino-like attachment

Strobe phase can harmlessly jitter by hundreds of microseconds -- but strobe length must stay consistent to the microsecond.

A 1000us (1ms) strobe flash that varies in length by 10 microseconds, creates a 1% brightness change. (10 microseconds is 1% of 1000 microseconds). So if you have a timing error of 10 microseconds, you will get annoying flicker from the brightness change of varying strobe lengths. The current standard for strobe length accuracy is sub-microsecond. Only hardware can time a strobe backlight that accurately.

Software on a computer is not precise enough to accurately control a strobe backlight.

But it can be hacked fairly cheaply if you know how to. You can modify a computer monitor's motherboard with an Arduino, and have the Arduino drive a scanning backlight. Zisworks did this (open source scanning backlight) but you need to purchase the backlight controller from http://www.zisworks.com/shop

Also, you want to speed up the LCD scanout to create a longer pause between refresh cycles. This lets the LCD GtG pixel transitions finish at the bottom edge before you flash the backlight, before the next refresh cycle begins LCD GtG again at the top edge again. This is the "Large Blanking Interval" trick and is sometimes possible computer-side in a Custom Resolution Utility. Other monitors does it internally, however.

To hack your monitor's backlight:
1. Electronics Hacking: Creating a Strobe Backlight
2. Area 51: Display Science, Research & Engineering

Software can do nano-second accurate timing using the HPET. But the communication between the HPET and the display probably will have a bit of latency which will have to be compensated.

Curi0 wrote:Software can do nano-second accurate timing using the HPET.

No, that's impossible. Non real-time operating systems cannot do that.

Curi0 wrote:Software can do nano-second accurate timing using the HPET. But the communication between the HPET and the display probably will have a bit of latency which will have to be compensated.

There's a big difference between measuring time accurately, and executing code with accurate timing.

The code in question needs to run on the display's hardware, because there isn't a direct connection between your CPU and the backlight. Any commands sent over the display interface are at the mercy of the monitor's firmware and hardware. Even if you can control the backlight with software, it's a bit like trying to play a game of basketball by carrier pigeon.

Yeah the latency will cause problems and it will be different on each system so it will require to user to manually set the latency offset.

If this is implemented at a very low level the software shouldn't add too much latency.

If anyone knows how to do this write a POC if possible.