Page 1 of 1

Brand new TestUFO test -- demo for 480Hz and 1000Hz

Posted: 03 Aug 2017, 18:17
by Chief Blur Buster
I'd like your comments.

Here's a funky new TestUFO test.

Here's a brand new TestUFO test, embedded here.
It's a hybrid of and
Look at the top UFO (vertical lines), then look at the bottom UFO (a photo appears).

Full page:

At 960 pixels/sec, the double your refresh rate, the twice as sharp (half as pixellated) this TestUFO image becomes.


Brand new TestUFO test.

Posted: 07 Aug 2017, 18:41
by Chief Blur Buster
Note, this test looks better at 60Hz, 120Hz and 240Hz.

The image looks 4x sharper at 240Hz than 60Hz.

For 144Hz, try 1200 pixels/sec instead of 960 pixels/sec.

Brand new TestUFO test.

Posted: 07 Aug 2017, 19:46
by RealNC
Unfortunately, none of the tests are working at all on any Linux browser. I always make a mental note to test this on Windows, but when I boot into Windows, I forget :D

Anyway, I assume this is a comparison test to judge motion blur between different monitors on the same refresh?

Re: SECRET: Brand new TestUFO test.

Posted: 08 Aug 2017, 00:58
by Chief Blur Buster
No, not that kinda test --

It's one of the best-ever optical illusions that I have ever invented, I think.

More of an optical illusion to demonstrate a behavior that scales with higher Hz -- the image becomes progressively less pixellated as you go from 60Hz -> 120Hz -> 240Hz. It's one of the more creative TestUFO optical illusions that I have ever invented -- so I suggest you try it out sometime!

Chrome/FireFox might synchronize "well enough" despite the error message it displays in Linux -- as long as it syncs to 60fps. But it won't show the effect of doubling refresh rate as well. (e.g. if your Linux browser stubbornly stays at 60fps during 120Hz). If you track your eyes on the moving UFO, the vertical lines disappear (assuming your framerates are synchronized to VSYNC). If you are in Linux and it is stuck at 60fps, then temporarily switch to 60Hz, to test it out (it might not work perfectly, but better than 60fps @ 144Hz)

You can also try it on your Android or iPhone, too. On newer Androids/iPhones, it syncs perfect.

Brand new TestUFO test.

Posted: 08 Aug 2017, 08:22
by RealNC
This is the situation on Linux when using "better than 60Hz" displays:


It's a stutter-fest. Stutter in scrolling, stutter in video playback, and blurry as hell. :(

The worst part is that nobody seems to care. Chromium bug reports are not even looked at, it would seem.

Temporarily switching to 60Hz allows your new test to run as intended though. The effect is rather nice, and somehow reminded me of mechanical TVs from the very early times of TV (there's a mini-documentary somewhere on youtube.)

Brand new TestUFO test.

Posted: 09 Aug 2017, 14:19
by Chief Blur Buster
Yes, it uses the same principle -- like spinning LED bike wheels -- or Nipikow wheels (mechanical TVs).

I'm probably the first person to successfully implement this in pure HTML5 for onscreen demos, powered directly off a monitor's refresh rate. You'll notice that the "wide pixels" that show up at 60Hz, and the resolution doubles every time you double refresh rate. In fact when you change line separation, the pixel size stays the same for different motion speeds.

Line Separation 16
Line Separation 32
Line Separation 64

Notice that the pixellated horizontal resolution of the underlying image remains constant, regardless of separation between vertical lines? (Assuming Hz and motionspeed remains the same).

(It's much harder to track eyes at Separation 64, so I set motionspeed to 1920 pixels/second. Go into full screen mode or maximize your browser window. 60Hz is *extremely* limiting for this type of test.)

You'll notice that the "resolution" of the image that shows up for a specific motion speed and refresh rate, stays the same, regardless of the separation between vertical lines. The "resolution" of the image that shows up is much more dependant on the refresh rate of the display. I also was able to test on an experimental 480 Hz display (shhhhh....) and it still provided noticeable improvement over 240 Hz in this type of occulsion test.

When you reboot to Windows, please test this test again at 120Hz -- you'll see the image become half as pixellated as at 60Hz.

Just like a real Nipikow mechanical TV -- the higher the Hz you can flicker a bulb (neon lamp in the 1920s, or single LED for modern Nipikow wheel reproductions) -- the higher the resolution of the mechanically-generated image. Same for spinning-LED-rod displays/clocks/wheels/etc.

This TestUFO test, powered directly off the monitor's refresh rate, also reliably doubles in resolution (for a specific motion speed) at double the Hz.

Real world applications: Playing FPS games while looking through dense bush or cracks or fence slats. Or trying to peek through a very tiny crack in a door in a FPS game (millimeter-league cracks that are only a single or two pixels on screen) via turn/strafing left-right to "rapidly scan through the crack". (Admit it, you might even scan-peek through the crack of a bathroom stall door sometimes to check if a toilet stall is occupied!). In real FPS games the cracks are much bigger but let's assume a much tinier crack that are only a few pixels wide, and you're wanting to "scan" faster. The rapid occulsion-deocculsion effects look better the higher the refresh rate you go. This is increasingly important the closer in humankind, that we try to approach Holodeck realism during virtual reality situations. Fixing occulsion-effects limitations fully will require multi-thousand-Hertz to make things look analog-motion even in these types of occlusion scenarios (which are not interpolatable), and pass the "Holodeck Turing Test" in the "Wow, I didn't know I was wearing a VR headset instead of wearing a transparent ski goggles" type of blind-testing that would definitely require ultrahigh-Hz retina-resolution headsets... While it's nitpicking right now, it still underscores the need for ultra-high-Hz to approach Holodeck-quality analog motion with no visible side effects...

Also, set thickness to 1 and separation to 16, and watch how sharp the vertical edges are even at 60Hz:
Line Separation 16
Even on an IPS LCD, vertical edges are sharper than

The sharpness of the vertical edges is actually directly dependant on the LCD GtG. On LCDs where GtG is a tiny fraction of a refresh cycle, the vertical edges are extremely crisp and sharp. (And the faster the GtG, the squares at will also be crisper/sharper have little or no ghosting). So, this TestUFO test is one unexpected way to visualize LCD GtG directly to the human eyes, almost completely separately of persistence. Basically, this TestUFO test eliminates persistence motion blur from GtG motion blur. Displays with approximately 4ms GtG on a 16ms refresh cycle, will show approximately 25% motion blurring on the vertical lines.

So I've accidentally discovered that this type of test is a way to human-eye-visualize LCD GtG independently of LCD persistence. Whenever GtG is far less than persistence, the vertical edges will be much sharper than .... On an old 33ms LCD display (I have a 20 year LCD monitor here too...) there's almost no reduction in motion blur.

So, this type of motion test allows you to subtract persistence-related motion blurring from GtG-related motion blurring.

The low-resolution-looking (at lower Hz) "pixels" at have vertical edges that are almost CRT motion clarity on 1ms TN LCDs. Without needing strobing, since the 1pixel thick lines versus 15pixel blackness, gives you essentially the equivalent of 15:1 ratio black frame insertion (your eye tracking creates the needed strobing effect). Vertical edges during horizontal panning motion -- on non-strobed displays -- have over a 90% reduction of motion blur in this TestUFO animation --
compared to at the same motionspeed.

Very interesting side effect I've discovered. Vertical edges are almost razor sharp despite fast-panning non-strobed motion.

Re: Brand new TestUFO test -- demo for 480Hz and 1000Hz

Posted: 12 Aug 2017, 13:53
by Chief Blur Buster
This TestUFO test is now launched to the public.

Comments welcome!