Actually, Radeon Overdrive is almost identical in principle to overdrive. It is possible TCON-level overdrive can do overvoltages to boost below black or above white, but it's not really being done in principle. It was often simply done via reduced dynamic range to allow overshoot room. Once that's removed, there's no difference between a BenQ/Zowie overdrive and a Radeon Overdrive, except for a little more input lag by doing it via the GPU.RealNC wrote:I don't think it was real OD though (no way to boost voltages.) From what I could tell, it calculated a delta between the current and the previous frame and displayed a modified version of it with the colors modified in such a way that it would cancel out trailing/ghosting.
I had it, and it actually worked on one of my monitors. It really looked good on that one. It added better-quality overdrive than some monitor overdrives I have seen. It was, however, useless on LCD displays that already had overdrive and made that worse.RealNC wrote:Sounded better in theory than it worked in practice.
So it was only useful and impressive for a brief time in its history. It wasn't a "didn't work in practice", it was just a happenstance of being introduced in a small window of time when LCDs finally began to introduce overdrive, but wasn't yet widespread.
Mathematically, it's identical. If you need to go from RGB (0,0,0) -> RGB(128,128,128), the next refresh cycle might be temporarily RGB(140,140,140) for one refresh cycle to speed up the transition to RGB(128,128,128). If you time it right, the color never finally reaches RGB(140,140,140) but it reached RGB(128,128,128) faster. That automatically creates extra voltage anyway, so you're doing the same thing.
Today, the best generic common way to do this in a high performance way is to precompute an overdrive lookup table (256x256 or 1024x1024, greyscale) from either a formula or an automated photodiode measurement run, and run the LUT on every subpixel (independent R/G/B separately).
Do that for every pixel, and viola.
Now to improve whites and blacks, you can simply reduce dynamic range a little bit (e.g. squeeze 8-bit into the equivalent of RGB(16,16,16) through RGB(235,235,235) to create the needed headroom. However, many LCDs do achieve transitions very fast to fullwhites and fullblacks without needing overdrive, so the need for expanded dynamic range becomes a little attenuated. Overvoltaging slightly is supported by some LCDs, but it usually applies only to one end of the range (not both ends).
The 480Hz mode I have, seems to do white-to-black very fast (easily 1ms) but very slow in black-to-white. So i'd only reduce dynamic range at the top end, e.g. 0-224 and use the headroom as overdrive overshoot room.
I may create a TestUFO Software Overdrive test to try and milk the 480Hz clarity to its max. Long term, this may let open source modders generate their own overdrive formulas or lookup tables to upload into open-source firmware LCDs (that has enough previous-refresh-cycle memory for lookbehind overdrive)! Web motion tests are getting good enough to help generate overdrive lookup tables. The Zis LCD does not have enough memory for overdrive, but this isn't the final frontier in tweaking of the future.
I prefer overdrive be done at the monitor level as it can be done on a line-buffer-based way with only lookbehind data -- for lagless overdrive. And works in all apps. To do it on the GPU, you need to buffer the current refresh cycle instead of just realtime scanning-out to the GPU right away. That adds at least a frame of lag.