Nice. I actually experimented with this myself, but far less sophisticated (so it seems)Chief Blur Buster wrote:-- I am thinking of eventually writing an online TestUFO motion blur modelling program (TestUFO Motion Blur Modeller/Emulator/Predictor). Much like the custom motion blur modeller in PixPerAn, but modernized for the 21st century reality of faster LCDs and strobe-backlights.
-- Basically, one can tweak sliders, and see algorithmically simulated motion blur that matches what you preceive (or photographed by tracking pursuit camera) and contains some easy-select presets of known motion blur variables (e.g. typical 1-2ms 60Hz, typical 1-2ms 120Hz, CRT, LightBoost 10%, LightBoost 100%, Blur Busters Strobe Utility 0.5ms, Blur Busters Strobe Utility 2.0ms, Blur Busters Strobe Utility 4.0ms, etc.). Basically a motion blur simulator that factors in persistence/duty cycle. I know how to create a very accurate one, although I might need some help with the formulas (e.g. GtG often has pixel ripple, and I'm not sure how to simlate that -- I might need to ask for some formulas). CRT phosphor decay would also even be easy to emulate in this same application if I just get a formula that approximates phosphor -- it's simply a sudden-ramp-and-slow-decay (phosphor trail) rather than a squarewave (linear motion blur), and simply run different blurring formulas for R/G/B (G has the slowest decay, so that's why there's green trailing effect). So the same modelling program can easily simulate motion blur of sample and hold LCD (of varying GtG response speed for a specific pair of colors in both directions), simulate motion blur of short-to-long persistence CRT, simulate motion blur of strobe backlight (of varying strobe lengths). Factoring in persistence (and for each channel of color separately) automatically makes the application compatible with accurately modelling of motion blur of persistence of CRT, persistence of LCD, persistence of strobe backlights, and persistence of many other display technologies. If one add high-frequency subpixel effects, I can also accurately model motion blur of plasma/DLP (including the "noise" in motion blur too!) -- all one would need is the error-diffusion math formulas for each pixel color, and then of a sudden one would be easily emulating the plasma banding effects in software!! It's really a simple matter of emulating per-pixel motion blur based on the PWM duty cycle of each pixel individually, where each of the pixels individually motion blur for each different lengths, and patterns in error diffusion interact with each other, creating artifacts like the noise/band artifacts found in plasma/DLP motion blur. But I wouldn't bother per-pixel for the first version of the TestUFO Motion Blur Modeller if I created one. I'd simply focus on simple squarewave persistence first (easiest to model), followed by ability to manually enter an algebriac formula (or presets for CRT fast phosphor, CRT slow phosphor, 1ms LCD, 2ms LCD, for 8ms IPS -- if formulas approximating those can be come up, e.g. logarithmic, gaussian, sine, squarewave, etc), perhaps three different formulas for R/G/B (since the three CRT phosphor primary colors have different decay behaviors), and viola -- one can accurate emulate tracking-based motion blur (visual-based and camera-based) of virtually any possible single-strobe display like CRT/LCD/OLED/etc (displays that didn't modulate pixels multiple times indepedently of each other, like plasma/DLP -- that'd require per-pixel modelling). Ideally something HTML5 based, so I could integrate it as part of TestUFO; it may be a project I may do later in 2014, though I'm also open to collaborative efforts (in Javascript/C#/Java/C++).
-- This app wouldn't be factoring in things like judder/stutter/temporal aliasing effects/low framerates on strobed, but could theoretically be easily updated to also include blurring/doubleimage effects caused by those effects.
How are you handling the characteristics of the HVS/display the simulation is running on? Are you assuming a 'perfect display' and are you considering slow-mo / increased size to bring frequencies below nyquist or are you including the characteristics in your models (with limitations)?