jts888 wrote:It looks like Mark and I reached the same fundamental conclusions, but we appear to differ on whether strobe sequences are purely additive over the baseline holding levels, and his diagrams indicate a desire to dynamically alter hold brightness under rising Hz input.
(For new visitors without previous reading, see
variable-rate strobing chapter via
Electronics Hacking: Creating A Strobe Backlight)
<AREA51 type="display engineering">
I think both your idea and my idea would work -- it's both different means of accomplishing the same effect.
They aren't purely additive (due to non-linear response of vision). But it definitely behaves additively over high-frequency timescales (say, 10KHz) -- they most definitely behave additively. There's actually a scientific law associated with this:
Talbot-Plateau Law covering average brightness over flicker in an additive fashion, and this also stays true with non-regular flicker, whether full cycle (0-100%) or partial cycle (brightness curves), too. Roughly speaking, it's number of photons hitting the eyeballs in a specific time period, at sub-flicker-detection thresholds (and that any averages over multiple timescales (e.g. 1/100sec, 1/200sec, 1/300sec, etc) averages equal each other with average variances below detectability thresholds, and all the timescales are far below flicker detectability thresholds). My diagrams are compliant with this law, and I think a properly implemented version of what you described would also follow this law too. So whatever works, works.
A super extreme case of this is blackbody radiation from incandescent sources (ultra, ultra, ultra high frequency random emission of photons). A lesser extreme case is persistence adjustments of monitors (strobe duty / strobe phase adjustments). A middle case would be a microcontroller intentionally algorithmically "randomly" flickering an LED. Random 10,000Hz flicker can be made to look consistent brightness, as long as the outliers are precisely pulse-shaped (otherwise it shows as faint flicker caused by fluctuating average). Human detectability of brightness changes can be less than 1% when you're paying attention to it (1% difference in an 8-bit palette is 2.5 shades apart, comparing say, RGB 255 versus RGB 253, which can be detectable on a properly adjusted monitor), but even that threshold varies depending on the frequency of flicker and human (some will be more annoyed by random flicker than others) so we'd need to target a rough baseline.
So, any random-strobing will probably need to be slightly pulse-shaped on the leading edges and trailing edges of strobes, if doing PWM-based strobing (increasing/decreasing strobelengths away from persistence target at microsecond timescales) to ensure trailing averages are consistent. Even 10 microsecond error can lead to noticeable flicker; I've witnessed it: 1.0ms persistence versus 1.01ms persistence is a 1% brightness change! Some beta monitors with less accurate PWM, flickered randomly during regular strobe mode, because persistence was randomly changing by 10 microseconds! When 10us variance outliers occurs in 1.0ms strobing, about twice a second, you see about two major random flickers per second of 1% brightness change. Especially in a full-screen Windows Notepad window, and especially in peripheral vision. Ouch. Let this be a lesson to monitor manufacturers in precision needed to prevent human-visible flicker (IRQ interrupts during microcontroller-code-driven PWM is enough to cause human visible modulations in brightness!!)...
Over low-frequency flicker, things get more complicated. A random 70Hz flicker is far more noticeable than a non-random 70Hz flicker. But a random ~10,000Hz-ish flicker would be hard to tell apart from a regular synchronous 10,000Hz flicker, for stationary non-eye-tracking--situations, assuming that any random segment (over a short timescale that's sub-flicker-fusion-threshold such as 1/200sec; but all thresholds should be tested so that 1/200sec averages equal 1/500sec averages, if possible) is exactly equal to any other random segment of the same random flicker. That's the engineering challenge; making sure it's pretty consistent over reasonable flicker-fusion-threshold timescales. That may mean shimmying with leading edges and trailing edges a little bit to keep things consistent over varying time periods. It's the same number of photons hitting the eyeballs over human perceptual timescales.
However... side effects such as wagonwheel effects and phantom-array effects of variable flicker, would actually cause different artifacts, and even beat-frequency artifacts as the flicker Hz varied past thresholds (e.g. beat-frequencying with RPM speed of on-screen wheels) and non-regular PWM artifacts with variable spacing (
pursuit camera capture of PWM artifact) which is witnessed during non-eye-tracking situations.
A big problem is that variable refresh rates often go as low as 30Hz, which definitely fall very far within flicker detectability thresholds, and people's sensitivity to flicker will vary (and even people's thresholds of detecting randomness of flicker may also even vary independently too, even if it definitely follows the Law beyond a high Hz). This is where the big engineering challenges probably is, accomplishing as low-frequency-as-possible variable rate strobing. So a power user adjustment of where the blending threshold occurs (e.g. at a lower or at a higher Hz). And even a second adjustment, the amount of blending (how many Hz it blends over -- e.g. flickerfree sample-and-hold at 53Hz through fully flicerking at 87Hz, versus flickerfree sample-and-hold at 75Hz through fully flickering at 80Hz). Regardless of what blending algorithm is used (yours or mine), since it definitely needs to avoid single-dominant-strobe at 30Hz, while we definitely want single-dominant-strobe at 120Hz, if we're doing motion blur reduction strobing during variable-refresh-rate modes...
Pure OLED, in theory, should be much easier to do variable-rate-strobing. Rolling-scan strobes are done on fixed-refresh OLEDs (pixel-row-off passes chase-scanning behind pixel-row-refresh passes,
high speed video). The rolling scan can be dynamically modulated during variable refresh rates -- since it is theoreteically simply dynamic adjustment of the rolling scan windows. Of course, OLED pixel response is a limiting factor especially in
AMOLEDs -- due to transitor latency -- individual OLED pixel response can be a limiting factor as it can take several hundred milliseconds for the active matrix transitor behind an OLED pixel, to fully activate the OLED pixel (
see graph), passive matrix OLEDs are much faster without this transitor switching latency as LEDs themselves can switch in less than a microsecond. Also phosphor-backed OLEDs (e.g. white OLEDs driving colored phosphors), found in certain models of OLED HDTVs, will have phosphor latency (typically <1ms, CRT-style). So, for good low-persistence AMOLED, you want OLEDs with primary colors, and accelerated active matrix transistor switching, and then it could be fast enough for on-the-fly rolling-scan-window adjustment (longer distance between ON/OFF passes) or by doing faster/slower scanning of OLED pixel rows -- to accomplish dynamic-rate strobing on OLEDs.
The closest thing to variable-speed flicker is plasma subfields on an ultralow-persistence plasma (e.g. certain Panasonic NeoPlasma panels, like found on the Panasonic VT50). During some scenes, the plasma flickers at a different frequency (due to multiple subfield impulses versus fewer bright subfield impulses, per refresh cycle) than when during bright scenes, by the way it compresses the bright impulses to reduce persistence. You can actually visibly see the flicker increase/decrease dynamically on the Panasonic VT50 television, but it's not always too annoying. The large black frame duty cycle between the surge of flickers, however, is the main factor in the flicker detectability, I believe. Either way, plasmas is the closest real-world modern case study of variable flicker behavior (at least from a dynamic duty cycle perspective). This can be used as an example case study of flicker tolerances, especially during variable-refresh-rate operation.
</AREA51>