Thank you so much! I wanted an opinion from you because I have got inspired of "http://www.testufo.com/blackframes
" before doing this. I love your website and hope that it will gain attention from developers because almost no one cares about motion blur and realize how bad it really is!
While it is only a small bit -- this is slowly changing thanks to virtual reality -- at least among VR developers.
Strobing is used on Oculus and HTC Vive (as well as Samsung GearVR which forces Android phones into a 60Hz flickermode) since motion blur creates lots of headaches in virtual reality!
fuzun wrote:On Samsung C24FG70 VA panel @ 144hz without built-in monitor strobing, r_strobe 1 or -1 results low motion blur (not as low as r_strobe 2 or 3) but very bad image quality (like it makes the frame drawn with 8 bit color palette but zero flickering!). I suppose that this is because it is a VA panel. I think with c24fg70@144hz and r_strobe 1 it is not worth to trade picture quality and motion blur. But r_strobe -2, 2 and 3 (or 1 with increased frame latency with gl_swapinterval cvar) works pretty well because it somehow does not degrade picture quality as much as r_strobe 1 (only lowers brightness. Does not make it like 8 bit).
That is because of something called LCD inversion. See www.testufo.com/inversion
or run odd-pixel-steps at www.testufo.com/ghosting
(use motionspeeds that uses odd numbers for "Pixels Per Frame". LCD inversion occurs every other refresh cycles to prevent burn-in.
-- every LCD does this to prevent burn-in. Rapidly alternate positive/negative voltages to keep things balanced
LCD inversion artifacts
-- Normally LCD inversion logic is invisible but sometimes there are artifacts.
More Information about normal LCD inversion operation
- Lagom Inversion Article
- TechMind Inversion Article
- TestUFO inversion patter ntest
(pattern optimized for common TN, not VA)
Software-BFI sometimes defeats this burn-in-prevention logic (on certain displays, not all of them). So that's why I programmed www.testufo.com/flicker
to alternate by adding one frame once every few seconds to allow it to flicker in the opposite order (to undo the burnin). So basically it's ON-OFF-ON-OFF-ON-OFF for a few seconds, then suddenly it does an ON-OFF-ON-OFF-OFF
-ON-OFF to re-balance the voltage inversion.
Burn In Prevention in software-based BFI
This will reduce or fix flicker problems after exiting game
You should swap phases once every few seconds. Basically you need to make sure (over the period of one minute) that all even-numbered refresh cycles and odd-numbered refresh cycles have the same number of black frames. That means even-numbered blackframe insertion needs compensation to rebalance things. Also, frameskips will make it hard to resync, but you could monitor the timing of pageflips and try to detect dropped frames. So that you can correctly guess how many black frames occured during odd refresh cycles, and how many black frames occured during even refresh cycles. That will prevent burn-in. You could keep a counter of black frames for even refresh cycles and a counter of black frames for odd refresh cycles. When one counter becomes massively too big compared to other, automatically adding 1 extra black frame to force the rebalancing. I'd suggest swapping phases once every few seconds. Some monitors don't mind a phase-swap every 60 seconds, but some monitors will do better with a phase-wap every 5 or 10 seconds. Make this configurable.
The separate phases (positive, negative -- even/odd numbered refresh cycles) of inversion essentially have independent image retention, so that's why you see flickering after you exit the game -- one inversion phase is burnt-in with bright images and the other inversion phase is burnt-in with dark images. Fixing this flicker (caused by inversion-logic-defeating software-based BFI) upon game exit can also be done by playing a very high-action full-screen YouTube (no letterbox bars). That resets all the pixels. But if you add an occasional phase-swap (extraneous black frame) you'll reduce or eliminate the flicker that you get upon game exit!
Not all monitors look very bad at even-numbered BFI ratios (e.g. 60fps at 120Hz). For 240Hz monitors (that can do custom refresh rates), you can do 60fps at 180Hz, for a burnin-free black frame insertion of 60fps content (e.g. emulators). And for 144Hz, you can do 48fps at 144Hz just like you're already doing.
fuzun wrote:I want to make this implementation adaptive and change gamma and brightness settings according to the current frame for example if the current frame gets darker, gamma can get boosted. This will however make flickering more apparent but who cares if motion blur gets eliminated this much!
As long as the person is motion-blur-sensitive. Not everyone is motion-blur-sensitive -- everybody's vision is different -- some sees colors more, others see blur more, yet others see stutters/tearing more. People are super picky about vastly different things. So make sure this is optional. Let people play with settings. Some people will never like flicker, but that's OK -- that doesn't mean it's a problem for a different person (like you or me).
fuzun wrote:On Samsung S22B350H TN Panel overclocked to 76hz, r_strobe 1 or -1 and 2 results low motion blur and not bad image quality compared to C24FG70. Ideal setting would be 1 for this monitor I think because it is not high refresh rate and making r_strobe more than 2 makes the flickering almost unbearable.
Very good! That's very flickery, but at least LCD GtG kind of soften the flickers by fading it out (sorta like a phosphor fade).
On B156HAN06.2 AHVA
laptop panel overclocked 104hz
(from 60hz), r_strobe 1 or -1 gives the best result (Motion blur gets eliminated very much. I can read texts while moving
). Not very much noticeable flickering or picture quality. Increasing it will make flickering apparent. However the panel gets darker over time and image retention/burning happens!. Even after closing the game the screen continues to flicker for some time
. Therefore r_strobe 2 or -2 may be used for this panel or gl_swapinterval 2 may be used.
For flicker fixing, see above algorithm
This may break the game engine but I want to know if this method (black frame replacement) better or for example r_strobe 1 + capping the fps to half and inserting black frames. The latter is used on emulators but I do not know how it would work on this. Probably worse I think.
fuzun wrote:And there is gl_swapinterval thing which basically sets the duration of a frame. I do not have any testing equipment to see if r_strobe 2 + gl_swapinterval 1 is better or if r_strobe 1 + gl_swapinterval 2. The second set fixes the bad picture quality that C24fg70 produces but also increases flickering.
Shorter flashes are darker but has lower persistence. I think what you're doing is trading "ON-OFF-OFF" versus "ON-ON-OFF" I suspect. The "ON-ON-OFF" BFI cycle probably looks brighter and have less inversion artifacts, but have more motion blur than the BFI cycle.
fuzun wrote:Lastly, one good thing about this engine is that even with GTX 670 I can get more than 300 fps. This makes testing these kind of things pretty easy. So I recommend for you guys to use this engine for testing things.
Yes, that means you can do super-reliable BFI. You pretty much need pretty much perfect frame rate (and VSYNC ON) for comfortable BFI.
fuzun wrote:I can not read the PM btw it says "You are not authorised to read private messages.".
Oops! I sometimes keep forgetting forum members need 5 posts before they can read/send PMs.
This is because we keep having spammers sign up and try to send PM. By forcing them to post publicly first, we can catch them before they begin sending mass-PM's to everybody on Blur Busters. Apologies about this -- eventually we'll have a better system to filter spammers, so that newbies can send PMs more to heart content. But for now, just email me at mark[at]blurbusters.com