No worries! Discussions can get quite complex on Blur Busters.skrueck wrote:We were almost exactly on the same page and then I think we drifted apart again. Probably my fault for poor explanation and improper terminology used. If so, my apologies. I'll try one last time if you will indulge me.
This does go back 180 degrees back to the http://www.testufo.com/interlace -- you notice that the top UFO is temporally accurate since new positional information occurs even during subsequent interlace passes. But this gets temporally messed up (by the eye-tracking motion) if you don't run at framerate matching the refresh rate (number of interlace passes per second).skrueck wrote:In other words, "stream" temporally accurate image fragments (rows, for example) into the eye instead of trying to flash entire images with much longer black intervals in between as we do now. Do this in order to greatly reduce overall latency of rendering, transmitting and displaying pixels.
At 350cd/m2 during full persistence (16.7ms) for a typical computer monitor, you can still get ~50cd/m2 during 2ms persistence. A bit dim, but usable at night in a dark room. You could also use boost voltage pulses to compensate (like done in some strobe backlights), but that may not be safe for OLEDs. LightBoost hits almost 100cd/m2 while Turbo240 hits about 250cd/m2.skrueck wrote:Could an OLED display currently handle 500 Hz? I think it probably could. If not, I think it could be made to if light output is already good enough that persistence is possible at 2 ms.
Yes, you could do 4-way interlacing at 480Hz over HDMI, or 2-way interlacing at 480Hz over DisplayPort. There's enough bandwidth. You don't even need to stoop as low as 6-way interlacing during 450Hz.skrueck wrote:Can a current PC or transmission technique (HDMI cable, for example) handle this?
Yes, that's what I call 6-way interlacing.skrueck wrote:At 1/450 seconds: render, transmit and display only rows 1, 7, 13, ...
At 2/450 seconds: render, transmit and display only rows 2, 8, 14, ...
At 3/450 seconds: render, transmit and display only rows 3, 9, 15, ...
At 4/450 seconds: render, transmit and display only rows 4, 10, 16, ...
At 5/450 seconds: render, transmit and display only rows 5, 11, 17, ...
At 6/450 seconds: render, transmit and display only rows 6, 12, 18, ...
At 7/450 seconds: render, transmit and display only rows 1, 7, 13, ...
A slow motion software-based equivalent of this would be http://www.testufo.com/interlace#interleave=6
which does exactly this, but at a slower refresh rate than 450Hz.
(If it doesn't look correct, make sure you use a supported web browser)
The 450Hz equivalent would be 7.5 times more rapid than this running at 60Hz, or 3.75 times more rapid than this running at 120Hz. It certainly would produce usable high-framerate, low-latency, low-persistence.
When you try to do the same thing for vertical motion, you get some resolution-loss artifacts when vertical motion goes close to the same speed as the interlacing. Imagine motion going 450 pixels/second vertically; you're going to have times where you never display certain rows of pixels.skrueck wrote:Concern was also expressed with vertical motion if using rows of pixels. I'm not sure how bad that would be at 450 Hz rows compared with 75 Hz full frames? But I would assume there might be some ways to alleviate this if it were much of a problem.
The slow motion equivalent (60 pixels/second at 60Hz or 120 pixels/sec at 120Hz) would be the following:
www.testufo.com/#interleave=6&test=interlace&direction=vert&pps=60
So you still the vertical motion interlace artifact problem when vertical motionspeed in pixels per second matches near a multiple of the refresh rate. In this situation, certain parts of the objects never get rendered, and thus, never become visible.
You're welcome!skrueck wrote:Again, apologies if I was not clear in my explanation or if I used any terms improperly. And thank you Chief for your time and to anyone else who reads this or comments.