DLP BFI for Consoles

Ask about motion blur reduction in gaming monitors. Includes ULMB (Ultra Low Motion Blur), NVIDIA LightBoost, ASUS ELMB, BenQ/Zowie DyAc, Turbo240, ToastyX Strobelight, etc.
BFI
Posts: 19
Joined: 23 Nov 2021, 01:25

Re: DLP BFI for Consoles

Post by BFI » 13 Jan 2022, 02:38

Chief, is it normal for total hardware latency to be higher at 60Hz than 120? I've been using a 330fps camera to compare input lag between a couple of DLP projectors and my XL27, and get these averaged results at 60Hz (midscreen measurements as best I can):

XL2720Z: 66ms
W1210ST: 72ms
HD29HST: 72ms

I've seen the monitor's midscreen lag reported at around 15, and the PJs are both advertised at 16.7, so this data checks out. But then at 120Hz I get these averages:

XL27: 36ms
W1210: 65ms
W1210 3D: 65ms
HD29: 43ms
HD29 3D: 61ms

The HD29 is advertised at 8.4, and since I don't believe the XL is 7 faster than that, I must be running into the limitations of my camera here (a fraction over 3ms between frames). But why the discrepancies between 60Hz and 120? I used a laptop with a 1000Hz polling rate for the mouse, kept it offline, and had as little running as possible. I set an LED for 45ms when I leftclicked (so it was lit for 15 of those 3ms frames).

If the HD29 is 8ms, engaging its 3D mode suggests around 25, and a touch higher than that for 3D on the W1210. But as you can see, the HD29 can't be 8ms of 43 and 16.7 of 72, nor can the XL27 be 30ms apart. Not unless the GPU (Vega 8) is also slower at 60Hz or something like that. Any ideas? I used Kulagin's test - http://plnkr.co/edit/Q8CzgCo451XKKFbdmJAH

Might you or someone else here be able to sell me a lag tester? I'd love to get accurate figures for the 3D mode on this Optoma, because I'd be quite happy with 25ms if I were able to confirm. The Leo Bodnar and Time Sleuth are limited to 60Hz and I can't find a 120 option for sale. The resolutions I've tested at 120Hz are 1280x800, 1440x900 and 1080p, so I don't need the bandwidth for 4K.

Thanks for all the info above by the way - I've been busy and forgot to check back. I did buy and return a Sony A80J because I was disappointed by its 60Hz BFI. It only has one option for 60, and your alien's three eyes were only clear at 240 pixels per second. At 480 its eyes turned into four Xs. I believe this is 8ms persistence? Its flickering isn't worth it for that level of blur reduction IMO.

This Optoma has both DLP Link and 3D Sync by the way, and I believe the latter works independently? On my camera footage I see black frames with the former mode but not the latter, which appears to have some kind of dithering applied? The colours from the BenQ's RGBRGB wheel are deeper.

If there were a BFI box I'd definitely pay a few hundred for one! Then I could run this PJ in its 8ms mode with full control over how much BFI latency I was adding. Turns out my single-strobe duty on the XL is 1:0:0:0, but I wouldn't need more than 1:0 from the PJ at 60Hz. The cool thing with PJs is that I don't notice any flicker, so it'd be amazing to play 60fps games with imperceptible BFI!

Yeah, I'd absolutely pay good money for an HDMI box that routed the incoming video to apply low-latency BFI to an output cable.
Last edited by BFI on 14 Jan 2022, 00:00, edited 1 time in total.

BFI
Posts: 19
Joined: 23 Nov 2021, 01:25

Re: DLP BFI for Consoles

Post by BFI » 13 Jan 2022, 23:58

Also Chief, I read an old post of yours from 2012 about an Arduino HDMI solution for monitors, where you proposed a much brighter backlight. I know that requires vsync timing, but my question relates to beamers.

I see my XL2720 has top-to-bottom scanout, but my DLP PJs have a much faster pixel response and their scanouts are beyond my ability to study. Can you explain why an Arduino BFI switch would or wouldn't work for them?

My idea is to run a console's cable to its input, and then inject a black frame for 4.666667ms after each 12ms of uninterrupted output (60fps content). Unless it wouldn't trip the hardware at either end to actually drop the video signal for that long? I'm thinking the Arduino box might need to keep the output video live.

I believe an Arduino has low enough latency for this, but would its floats have enough decimal points for precise timings, and would it work for beamers? At 120Hz it could be something like 6ms of video to every 2.33 of BFI, which sounds great to me in theory.

With my limited knowledge, the only flaw I'm aware of is the double image potential if the framerate dips below 60. Most console games stay reliably close to 60 now, so I wouldn't mind that, and I'd be happy to pay someone for this to find out how it performs for myself. If I were disappointed that's on me. But I could be overlooking a major inherent downside?

It just feels like DLPs might be a unique platform for success, where I've enough brightness to lose a quarter of output time. 8-)

User avatar
Chief Blur Buster
Site Admin
Posts: 11648
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: DLP BFI for Consoles

Post by Chief Blur Buster » 26 Jan 2022, 15:54

BFI wrote:
13 Jan 2022, 23:58
I see my XL2720 has top-to-bottom scanout, but my DLP PJs have a much faster pixel response and their scanouts are beyond my ability to study. Can you explain why an Arduino BFI switch would or wouldn't work for them?
An Arduino BFI injector via a rolling-scan spinning-wheel slit shutter (in sync with LCD scanout) would work much better with LCD and LCoS with a software-based (GPU shader based) overdrive.

Remember that DLP images are 1-bit monochrome images displayed about a thousand times per second, to temporally dither into full 24-bit color or better.

Adding DLP reduces this temporal dithering color depth, since you're interrupting the temporal dithering (high speed flickering of pixels to generate color)LCD

DLP color depth will be decimated because of DLP's temporal dither, and the time offsets of a rolling scan versus DLP global refresh, will create some odd contouring artifacts. A fast shutter may work well with DLP but you will halve color depth for 50%:50% ON:OFF BFI, and quarter color depth for 25%:75% ON:OFF BFI. Since LCD is already temporally complete instantaneously, BFI will work better with LCD as long as you can get LCD GtG fast enough. The problem is a lot of LCD based projectors are only 60Hz, and only a few high end LCoS projetors such as Sony SXRD can do 120Hz... So BFI will have strobe crosstalk.

So you have an artifacts pick-poison effect
- DLP color depth loss
- LCD crosstalk

However, the great news is you can adjust BFI mechanically by slit size / pieslice size on the spinning wheel in front of the projector. Keep wheel symmetrical weight, so might want to spin wheel half the speed and equal slits on opposite edges of projector.

You may also want a high speed camera (Samsung Galaxyx) to determine refresh pattern of your projector to help design your wheel-spin direction necessary to be in sync with scanout (appliable to LCD and LCoS only).

You can use refresh rate headroom with a 120Hz LCD, to hide LCD GtG in the VBI (interval between refresh cycles). Refreshing a 60Hz refresh cycle in 1/120sec scanout, allowing long idle time between refresh cycles to hide LCD GtG in dark periods. 8ms scanout, 8ms idle (long enough to hide most LCD GtG). So a 120Hz LCD can do 60Hz refresh cycles with 8ms of scanout time kept in dark, greatly lowering strobe crosstalk. Kind of like doing a large vertical total VT2160 or thereabouts, to zero crosstalk top/center/bottom. The larger the vertical total, the better -- you want to scanout faster and idle longer between refresh cycles (more time to keep backlight turned off while LCD GtG pixel transitions in total darkness).

It's possible to get perfect zero strobe crosstalk with a strobed LCD, given sufficient refresh rate headroom (e.g. ViewSonic XG2431 at VT4000+ sizes, or an Oculus Quest 2 VR LCD), as LCDs can often go perfect zero crosstalk at approximately 3:1 refresh rate headroom and better -- which is why I am a fan of running a 240Hz LCD at 60-100Hz if you want the most CRT-clarity LCD possible. However, the problem is consoles don't emit large VBI's (custom timings) so that's part of the problem that makes things challenging.

In this case, it full circles back to pick-poison of compromises because of console limitations (outputting a 60Hz signal slowly in 1/60sec, with not enough time to hide LCD GtG in VBI).

But where this limitation is not an issue, LCD strobing outperforms DLP strobing by a significant margin (when the LCD technology is correctly cherrypicked, the Large Vertical Total is properly tuned with the right Overdrive Gain / Strobe Phase / Strobe Length setting, and there's enough refresh rate headroom above the Hz you're strobing at).

DLP is amazing and has fast refresh cycle but it has a major disadvantage of color depth decimation effects at higher refresh rates
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
Chief Blur Buster
Site Admin
Posts: 11648
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: DLP BFI for Consoles

Post by Chief Blur Buster » 26 Jan 2022, 16:07

That being said...

A mechanical BFI injector will still work "okay" with a DLP projector if the wheel is properly configured. You want a very fast slit-sweep with a long ON/OFF duration. This will minimize interference with interrupted temporal dither patterns, and reduce color distortions. You will need precise control over speed and sync, to make sure you get at least 1 each of the color wheel.

Another method is modifying the color wheel to black out all segments except only for one R/G/B section -- but that is a more destructive modification that interferes with everything that the DLP will do.

Ideally you want the BFI done electronically at the pixel level, such as the BFI done automatically when the projector is in 120Hz 3D mode.
That essentially make it simulate a kind of black frame insertion because 3D glasses benefit from a form of BFI (to allow the LCD shutter to fade open/closed while the projector image is black frame'd). So the 120Hz 3D mode of a DLP projector is already motion blur reduced (4ms persistence - 1/240sec blur). So no Arduino BFI injector is needed for the 120Hz 3D mode of a DLP projector (though unfortunately you don't get these benefits during 60Hz).

Another idea is an external software-based BFI injector by a video processor box -- capture the 60Hz HDMI output of a console and its full 16.7ms persistence, upconvert to 120Hz by displaying a frame followed by a black frame, and output 8ms persistence. There will be a video processor lag for this, but this would allow it to work with the 120Hz 3D mode of a DLP projector (reduce persistence even further to 4ms -- 75% blur reduction for 60fps material), or 120Hz regular mode (reduce persistence by 50%). This would in theory be a 2nd PC with a HDMI capture card with a video processor app. Or some kind of custom built HDMI input/output device with capability to do real time processing on the frames.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

BFI
Posts: 19
Joined: 23 Nov 2021, 01:25

Re: DLP BFI for Consoles

Post by BFI » 30 Jan 2022, 23:47

Chief Blur Buster wrote:
26 Jan 2022, 16:07
capture the 60Hz HDMI output of a console and its full 16.7ms persistence, upconvert to 120Hz by displaying a frame followed by a black frame, and output 8ms persistence. There will be a video processor lag for this, but this would allow it to work with the 120Hz 3D mode of a DLP projector
That's a cool idea, but the 3D mode has an input lag of 25ms, versus 8 in game mode. So if I did that I'd settle for the 8ms persistence.

My main wish is BFI at 60Hz for 60fps games from a PS5. Secondary wish is 120Hz BFI that beats the 25ms input lag of 3D mode. I think 1:1:0 might be the best compromise between luminance, blur and lag. I'd also really like to try 1:1:1:0.
Chief Blur Buster wrote:
26 Jan 2022, 15:54
DLP is amazing and has fast refresh cycle but it has a major disadvantage of color depth decimation effects at higher refresh rates
Is this because bitplanes have less time to display colours at higher hertz?

I believe the wheel in my Optoma HD29 is RYGCWB, like this — https://m.media-amazon.com/images/I/51T ... SY450_.jpg

I can only record low res at a high framerate and don't have my screen up yet, but here's a quick recording of 3D mode — https://i.imgur.com/th93plJ.mp4

To replicate this with a wheel mod I see I'd need to darken some of the white segment (can possibly compensate a little with BrilliantColor), but since I've only just bought this PJ I don't want to void its warranty. Else I could buy a replacement wheel to mess around with.

So to do this with an Arduino I'd need to synchronise with white, and I've no idea how to do that. A programmable internal shutter might be another option, but that's beyond my abilities for sure.

My ideal solution would be to plug my PS5 into an Arduino box with a very short HDMI cable, and then run the regular HDMI from that to the projector. When you say that LCD's a superior tech for BFI, I understand some of the reasons why, but gaming projectors are all DLP at the minute. The laser ones have at least twice the input lag, and with a small amount of BFI, I love DLP motion.

It doesn't sound like there's a fairly simple mod for this, though? If Nvidia or AMD added BFI to their drivers I'd swap my PS5 for a gaming PC. Likewise, if Optoma would just allow game mode and 3D at the same time I could use 1080/120. I don't need keystone unlocked! But unfortunately most console games are 60fps, and the Optoma has no option for that.

I realise the easiest answer is to wait until the warranty's up and replace the wheel, but it'd be much nicer to have the adaptability of an Arduino box. Plus it came with a long warranty!

User avatar
Chief Blur Buster
Site Admin
Posts: 11648
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: DLP BFI for Consoles

Post by Chief Blur Buster » 31 Jan 2022, 20:50

BFI wrote:
30 Jan 2022, 23:47
Is this because bitplanes have less time to display colours at higher hertz?
DLP pixels are binary ON/OFF cycling at about 1440Hz or 1920Hz or thereabouts. So 1440 Hz divided by 24 equals 60. So on a 1440Hz DLP, you're getting 24bit at 60Hz (8bpc), 12bit at 120Hz (4bpc), and 6bit at 240Hz (2bpc!). So for 4ms persistence you are stuck to 2bpc and 8ms persistence you are stuck to 4bpc. You are turning on/off pixel full-on versus full-off to generate full color. Basically it's per-pixel PWM to generate color.,

The color wheel is not the only temporal -- even when the color wheel is on one color, the DLP pixel is still binary-flickering temporally to generate those shades (dark reds, pinks, mauves, taupes, browns, and whatevers)

Now, the problem is that even if the Arduino BFI is precise enough to sync properly with a color wheel accurately (even a 360Hz color wheel), the arduino BFI system will ne interrupting the precisely-computed temporal 1440Hz or 1920Hz 1-bit dither sequence at the very wrong moments, so you'll have randomly chosen bits per color channel out of the original 24bits the DLP is generating if you try BFI. So you try to 75%:25% BFI (off:on) a 60Hz DLP for 4ms persistence, you're truncating 75% of the color depth, 8bpc to 2bpc! You're interrupting the temporal dithering at non-synchronized intervals, as the mechanical BFI won't be 1/1440sec accurate to the correct most-significant bits of the temporal dithering, so you may have very weird shimmering effects, color flicker effects, and/or weird variable contouring effects for non-electronic (e.g. not in the DLP''s ASIC/FPGA, and not in a video processor) black frame insertion.

Motion blur goes down, but color depth goes crap (with some nasty temporal color-shift and color-depth-variance artifacts from minor imprecision in color wheel)

Analog-mechanical black frame insertion (rolling mechanical shutter) works wonderfully well for fully-formed refresh cycles that are not temporally generated (in a subrefresh way). So mechanical BFI works wonderfully well for truer sample-and-hold technologies for LCD, LCoS, OLED, and uOLED type technologies that do not generate color by PWM, but terribly for DLP.

Strobe timing is not as critical for LCD sample and hold; it can safely vary by even a full millisecond -- often the only effect is a crosstalk band shifting up and down slightly (1ms strobe phase drift in an analog mechanical strobing rolling shutter = crosstalk band moves vertically 1/8th of screen height at 120Hz 8ms refresh cycle)
BFI wrote:
30 Jan 2022, 23:47
The laser ones have at least twice the input lag, and with a small amount of BFI, I love DLP motion.
Even ignoring the color modulation, you're forgetting the mirror modulation problem with BFI artifacts. With the mirrors cycling binary full-bright / full-off, even interrupting 1/1440sec too early or 1/1440sec too late, because of an imprecise slit size in rolling shutter, or imprecise realtime motor speed control in an Arduino-driven rolling-scan BFI motor.
BFI wrote:
30 Jan 2022, 23:47
It doesn't sound like there's a fairly simple mod for this, though?
Alas, unfortunately, no...

Anyway, if anybody wants to do mechanical BFI with an Arduino, this is kind of the concept of a spinning mechanical shutter when used with an LCD or LCoS projector:

Image

An Arduino connected to the motor would precisely modulate the motor speed to sync with the refresh rate, with an adjustable phase offset (to allow strobe phase adjustments).

In reality, there should be slits on both sides of the spinning rolling shutter, and the spinning going half speed. This reduces vibrations.

You could even do 4, 6 or 8 slits, to reduce wheel spin speed requirements -- since 60Hz would require a very fast 3600 RPM spinning wheel, which would be dangerous when unbalanced with an offset slit.

You also want to sync the slit scanout speed with the panel scanout speed (e.g. top-to-bottom sweep in 1/60sec) to stay away from the crosstalk zone. The strobe wheel may need to be made bigger and somewhat further away from the lens (About 6-12 inches away) to create a very clear rolling-shutter zone (sharper shadows with objects further away from projector lens). This will require lots of experimentation with mechanical strobe wheels, but with cheap cardboard, and a flexible motor/Arduino, you can simply trial-and-error your way.

So 6 slits means the wheel would only need to spin 10 times a second, or 600 RPM, which is doable with simple cardboard with precisely exacto-knifed slits -- sufficiently precise enough for LCD BFI but not DLP BFI, since LCD generates fully formed pixels that persists for multiple milliseconds between refresh cycles, rather than DLP's rapid cycling of pixels (no pixel stays continuously for a full millisecond, when generating halftones at 60Hz).

Remember, not all pixels on an LCD refresh at the same time (neither on DLP either - though time deltas between first/last pixel will be much tighter, like 1/1440sec between first and last, rather than 1/60sec between first and last pixel), but let's focus on LCD. You can see high speed videos of LCD refresh cycles at www.blurbusters.com/scanout

Even with a mechanical strobe wheel in front of an LCD projector, strobe crosstalk calibration can easily be done visually with www.testufo.com/crosstalk

Adjusting the strobe phase (mechanical slit sync offset to VSYNC/VBI) would create this easy-to-calibrate artifact:

Image

Varying strobe phase would simply jitter the crosstalk zone up/down -- or due to momentum of a mechanical motor, slowly drift the crosstalk zone.

Now, overdrive is needed to zero-out crosstalk as much as possible too, because of LCD GtG being too slow to be hidden between strobes. Good overdrive can make crosstalk invisible or near invisible, no cheap chinese LCD projectors (the bottom barrel type) use any overdrive at all unfortunately, but the expensive Sony SXRD I believe does (and also does 120Hz) and has a pixel response sufficiently fast enough to be mechanical-BFI-friendy.

Image

With LCD-based scanout (sync'd between cable and panel, unlike DLP!), they are capable of a trick called Quick Frame Transport to reduce strobe crosstalk - e.g. a 60Hz refresh cycle scanned-out in only 1/120sec. Which means more time for LCD GtG to finish between refresh cycles, which makes the VBI big enough to hide the strobe-phase crosstalk band offscreen (during calibration)

Image

At a certain point, when calibrated properly, the best BFI'd LCDs greatly outperforms DLP. (If you've seen an Oculus Quest 2 VR LCD headset, you already know that LCD sometimes outperform DLP, when calibrated by a star calibrator such as John Carmack (Quest 2) or myself (Blur Busters Approved).

The main problem with LCD projectors is that most of them have terrible overdrive not strobe-calibrated, but that can be sort of theoretically solved with a video processor or a GPU-shader (like yesterdays "ATI Radeon Overdrive"), perhaps via a windows indirect display driver. But, a lot of 120Hz-to-240Hz-scanout-capable LCDs can in theory (with correct superstar OD calibration) go CRT-clarity with zero or near-zero crosstalk at 120Hz, using the refresh rate headroom trick where the 240Hz ViewSonic XG2431 with Large Vertical Totals can outperform CRT motion clarity at ~75Hz-85Hz. (But most reviewers don't know this, most reviewers only test max Hz strobing). Most strobed LCDs have crappy calibration, though.

Now that being said, DLP is superior for easy high performance and brightness -- if you don't care about low persistence operation. DLP is currently terrible for low-persistence-high-color-depth operation due to its inherent binary nature of pixel modulation.

LCD can scale better, as LCD has no motion clarity limitation once LCD GtG is successfully 100% hidden in VBI, then motion clarity is unbounded (that's why a 0.3ms strobe on the Oculus Quest 2 creates a perfect real-world measured 0.3ms MPRT persistence) -- usable brightness it's simply limited by Talbot-Plateau Theorem, a law of physics effect where you need to strobe twice as bright for half persistence, for the same brightness. But you can simply use an overkill light cannon (high end Sony SXRD) -- just costs a lot of money.

I've been hoping to find some overclockable chinese LCD projector that can do 120Hz, and use large vertical totals + GPU shader based overdrive with it -- to create excellent low-persistence 60Hz (of Oculus Quest 2 quality). Theoretically this should not even be expensive at all (sub-1ms persistence with LCDs is no longer that terribly difficult, just fairly complex tuning to get high quality).

Another bonus of mechanical strobing is that it can be done near-laglessly (lag simply becomes a function of strobe phase offset), for a downwards rolling-scan mechanical shutter.

Colors and blacks will be always better with DLP for the moment until we have ultra-high-count LED local dimming, which isn't an ideal fit for projector based operation. Long-term, we may have MicroLED displays in place of projector bulbs someday (there's a 2 million nit MicroLED prototype -- screen as the projector bulb!) but until then, LCD is the best candidate for high-color-depth low-per75sistence operation, as long as you're willing to forgo contrast ratio, in exchange for uncapped low persistence flexibility (persistence on mechanically strobed LCD is just simply slit size -- you can do 0.1ms MPRT at ~1/167th brightness, 1ms MPRT at ~1/16th brightness, 2ms MPRT at 1/8th brightness). There is no color depth loss for shorter persistence on LCD, so your only artifact worry is strobe crosstalk and dimness.

Obviously, you've gotta pick your poison with LCD vs DLP, etc. But, bottom line, mechanical shutter experiments with projectors work far better with LCD and LCoS, especially fast-GtG models.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

BFI
Posts: 19
Joined: 23 Nov 2021, 01:25

Re: DLP BFI for Consoles

Post by BFI » 07 Feb 2022, 01:00

Thanks so much for all this info - it's great!

I'm guessing the wheel on my PJ runs at 4x at 60Hz, so if I darkened one of its clear segments I might see... trail ghosting? Since 120Hz strobing gives double images at 60fps, and I think this is 240.

I downloaded - https://github.com/squeaksci/desktopbfi - and found it's actually really good for locked framerates, with the major downside of flashes when it loses them (or is that maybe just a program flaw?). Happens when I'm watching your UFO and the framerate dips, for example. The loss of colour depth isn't as bad as I expected, and it's a trade I'd happily take for reduced blur.

So because the majority of PS5 games run at locked 60 in performance mode, I've renewed interest in a hardware solution. Is there anyone you know I could pay to build one for me? Given a hardware list and a wiring diagram I could put an Arduino in a 3D-printed box, but I'd be lost on coding it! I'm only good for writing a few lines in C.

Or is there no way to sync an Arduino and it'd flash like crazy?! I've no idea if it could adopt the incoming timings from a PS5 to forward to the PJ.

And just going back to your idea of capturing 60fps to output at 120 with alternate black frames, do you know of any devices capable of doing that? My old Hauppauge PVR didn't add much latency on the console side, but there was a huge delay for it to appear on my PC because of encoding, which makes me think there'd be too much lag for gaming. If it were possible in a few ms that'd be amazing.

User avatar
Chief Blur Buster
Site Admin
Posts: 11648
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: DLP BFI for Consoles

Post by Chief Blur Buster » 07 Feb 2022, 15:56

BFI wrote:
07 Feb 2022, 01:00
Thanks so much for all this info - it's great!

I'm guessing the wheel on my PJ runs at 4x at 60Hz, so if I darkened one of its clear segments I might see... trail ghosting? Since 120Hz strobing gives double images at 60fps, and I think this is 240.
Ghosting does not change. But color depth does. So you see banding/contouring/gradients suddenly appear in the existing DLP persistence motion blur you got at 60Hz without BFI.

After all, you cannot read street name labels at www.testufo.com/map on almost all DLPs unless you manage the low persistence operation modes (e.g. 120Hz+BFI).

Here’s a good example. View www.testufo.com/photo at 60Hz. Looks mostly fine, doesn’t it? Now view www.testufo.com/photo at 120Hz+BFI (3D Mode). Now you see banding in the sky of the default Quebec City skyline (Blur Busters is based in Canada…). That’s called contouring, a common artifact also found on cheaper plasma displays too. You do see ghosting/motionblur size (blur trail length) is completely unchanged, just that the number of colors change (continuous gradient versus banding in gradient).

Now, if you interrupted it mechanically, you will see variable number of bands flickering in and out, as well as color-tinted bands along the vertical axis (since the colorwheel spins faster than the Arduino BFI wheel, as colorwheel is out of sync with persistence lowering operations as colorwheel is often 6x higher than refresh rate). These annoying distracting artifacts are much worse than simple LCD strobe crosstalk.

Now in theory if you spent 100 hours trial and ereroring to create a perfect BFI wheel for DLP with perfect sync, you may get something acceptable. But it’s so fiddly because of the 1/1440sec precisions required, plus the need to scanout the slits at the same velocity of the DLP scanout to avoid any banding artifacts.

This is stock photograph, but mechancial BFI on a DLP creates artifacts similiar to these kinds of horizontal tint-banding artifacts because of the inability to precisely sync (like software BFI or electronic-based firmware-based hardware BFI).
DF1647F8-DDF1-42B6-8132-257C2800711E.jpeg
DF1647F8-DDF1-42B6-8132-257C2800711E.jpeg (12.86 KiB) Viewed 7440 times
BFI wrote:
07 Feb 2022, 01:00
I downloaded - https://github.com/squeaksci/desktopbfi - and found it's actually really good for locked framerates, with the major downside of flashes when it loses them (or is that maybe just a program flaw?).
Software-based BFI is superior to mechanical BFI for DLP for sure.
BFI wrote:
07 Feb 2022, 01:00
Happens when I'm watching your UFO and the framerate dips, for example. The loss of colour depth isn't as bad as I expected, and it's a trade I'd happily take for reduced blur.
You’re now completely misunderstanding the problem. Software BFI never does sub-refresh BFI like hardware BFI or mechanical BFI. Software BFI doesn’t interrupt hardware refresh cycles. That’s why it looks correct. Also the problem with software BFI is mandatory refresh rate headroom — you mandatorily require 120Hz to do software-based 60Hz BFI, and you mandatorily require 60Hz to do software-based 30Hz BFI. You’re seeing half the framerate of your DLP’s Hz.

That is why you don’t have color depth loss with software BFI because you’re not interrupting to a sub-refresh worth. A more proper, accurate test is comparing 60Hz versus 120Hz on your existing DLP using www.testufo.com/photo — you will see color depth loss behaviors correctly.

It’s important to fully understand this before continuing to ask the next question about mechanical BFI. If you have any confusions, please ask pre-requisite learning questions first on this sub-topic — it must be throughly covered completely before you attempt any form of mechanical BFI, as it’s like Grade 9 pre-requisites to Grade 10 class.

Software BFI is like grade 6 and mechanical BFI on DLP is literally like first-year university to do acceptably. The tolerances are much tougher.

Now, masking-out colorwheel spots will definitely lead to color depth decimation. Blacking out half of the wheel will cause banding artifacts to appear much like the 60Hz->120Hz experiment.

So to be clear:

Q: Why Don’t I Get Color Depth Loss With Internal/Software Means of BFI?
A: That’s because you’re not interrupting refresh cycles in a sub-refresh manner. You’re timing BFI at the signal level, which means you no longer need to worry about scanout differences, nor the temporal dither sequence. Your complex 6D math problem suddenly becomes a simpler 1D or 2D math problem. THe DLP projector retains its full temporal dithering per Hz. Your eyes are seeing fewer frames per second (e.g. 30 BFI frames per second at 60fps 60Hz). That can make 30fps material look much smoother and less blur, but 60fps material will have no blur difference with and without BFI, and will look better/less flickery with software BFI turned off. Blur Busters Law is “1ms of frame visibility time is 1 pixel of motion blur per 1000 pixels/sec”. Adding software BFI at 60Hz is just downconverting your 60fps to 30fps, without adding any motion blur, while improving look of 30fps.

Remember, I sometimes teach classrooms on display physics, so you need to improve your understanding of the learning pre-requisites as just because software BFI works, does not automatically mean mechanical BFI works.

If your smartphone is a Samsung Galaxy S9 or newer, you already have a 1000fps high speed camera, point it at a fast LCD (www.testufo.com/scanout) and point it at DLP too (www.testufo.com/scanout) and study why DLP is much harder than LCD to mechanically strobe,just from the sheer results of the high speed video from, say, a Samsung Galaxy phone — it becomes more obvious.

You need to *precisely* interrupt a refresh cycle in a sub-refresh manner — now imagine trying to do that on the kaleidoscope result (1/1440sec weird flashings) you just saw in your high speed video versus the LCD result (predictable 1/60sec “Fade wipes” like the videos uploaded to www.blurbusters.com/scanout …).

Don’t have a Samsung Galaxy? Does any family member have one? Get it. Or buy a used Sony Xperia XZ/XZ2 Premium for a couple hundred bucks as your display-analsys camera — even a phone with a cracked screen. That will speed up your analysis and help you mathematically design the slits on your DLP wheel to fit the unique behavior

The LCD has almost two orders of magnitude more forgivable mechanical-BFI-timing margin than DLP has, and you will be doing lots more trial and error trying to experiment — if you’re doing it yourself — or paying someone the equivalent of one month’s full time job (to do trial and error in a much less experienced way than Blur Busters does) — when you could instead be using the same money to paying for a newer projector that’s easier to BFI-experiment with.
BFI wrote:
07 Feb 2022, 01:00
Or is there no way to sync an Arduino and it'd flash like crazy?! I've no idea if it could adopt the incoming timings from a PS5 to forward to the PJ.
You’re completely misunderstanding the problem.
You’ve got multiple simultaneous complex temporal problems to solve:
1. The refresh rate
2. The temporal dithering
3. The scanout (not all pixels refresh at the same time)
4. The multipass scanout per Hz behaviour of DLP
5. The colorwheel
6. The sweep velocity of colorwheel boundaries on the DLP chip(if DLP is refreshing on both sides of the sweep — there are some algorithms that does this — and if the scanout is different from the DLP chip scanout velocity). For simplicity, most DLP just blacks the chip during the colorwheel-edge sweep, but there are algorithms that exist to take advantage of projector-bulb illumination time during the colorwheel-boundary sweep (e.g. same DLP field showing two colors (e.g red and green) simultaneously, on both sides of the colorwheel boundary sweeping past the DLP chip).

Count the number of bullets above. At the miinimum, it’s almost essentialy a 5-dimensional problem you’re having to compensate for.

An Arduino would likely not be able to *know* all of the 6 factors simultaneously, so you would have to analyze high speed camera footage (preferably at a frame rate far higher than pixel rate, but a frame rate higher than colorwheel rate will still be helpful) and design something custom that made sure you were interrupting an equal count of RGB’s rather than only interrupting an unequal amount of R/G/B (color flickers) as well as trying to use the same subset of temporal dither (e.g. a refresh cycle’s first 1/4th Hz of its algorithmic pre-computed temporal dither). Using a variable timeslice of temporal dither will create some other odd artifacts, e.g. you try to capture a temporal dither sequence +1/1440sec or -4/100sec or +0.0013257sec later, it may be a totally different temporal dither sequence than if you made sure to sync the beginning of your BFI exposure at the beginning or the end of a specific temporal dither sequene. So you are interrupting different bits of the bits of color depth, because of those uknown time variances, since you’re not syncing to the temporal dither mechanically. Plus, you also may have a mechanical slit shadow scanout velocity different from exactly 1/60sec (refresh rate) or exactly, say 1/1440sec (DLP chip scanout velocity), or the colorwheel boundary-scanout velocity. Syncing those scanout velocities with the slit shadow from the mechanical BFI, will be hard without a proper high speed camera, even if you’re not paying attention to the other variables of this highly complex six-dimensional math problem.

You’re doing an extreme 5-dimensional multitasking problem in deciding how to design the mechanical color wheel as well as the precision specifications of the Arduino program.

It can be done, but are you willing to spend 100x the man-hours getting it to look good, compared to a much simpler BFI work (e.g. video processor, 3D mode, software BFI, etc)

Now, blacking out all the segments of a colorwheel except one, may work far better than an external mechanical strobing wheel but may be problematic on most DLPs that does multiple revolutions of the colorwheel per refresh cycle. So you got multi-strobing artifacts (double images, in addition to also the color depth loss).

The software BFI as well as electronic-based BFI (inserting black frames on a refresh-precise manner) solves multiple issues of the above because that is always Hz-sync’d and it doesn’t require learning/knowing the temporal dithering pattern of the specific DLP to make custom compensations for. So you only need to worry about the refresh rate only — a much simpler 1D or 2D math problem (one or two variables) rather than a 5D or 6D math problem (five or six variables before it looks good).
BFI wrote:
07 Feb 2022, 01:00
And just going back to your idea of capturing 60fps to output at 120 with alternate black frames, do you know of any devices capable of doing that? My old Hauppauge PVR didn't add much latency on the console side, but there was a huge delay for it to appear on my PC because of encoding, which makes me think there'd be too much lag for gaming. If it were possible in a few ms that'd be amazing.
Video processors always add latency but I used to program video processors — I used to work for Runco, Key Digital, TAW, as well as the HOLO3DGRAPH (Faroudja chip in a PCI card). I’ve worked on 3:2 pulldown deinterlacers.

If you have a good budget, theoretically you can do it in a raster beam-raced manner, e.g. outputting simultaneously as input, if you can genlock the input Hz and output Hz somehow (or use VRR), and do it laglessly. But that is harder to program than going through the usual interfaces (e.g. DirectShow, etc) which requires full frames, so you have a latency issue. However, you get a lot more flexibility.

Doing it at the software layer is superior, capturing 60Hz and then outputting 240Hz (with 3 black frames and 1 visible), will produce a 75% persistence reduction.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

BFI
Posts: 19
Joined: 23 Nov 2021, 01:25

Re: DLP BFI for Consoles

Post by BFI » 08 Feb 2022, 23:45

Chief Blur Buster wrote:
07 Feb 2022, 15:56
because of the inability to precisely sync (like software BFI or electronic-based firmware-based hardware BFI).
You're absolutely correct about my lack of knowledge in several areas, but HDMI seems the most pertinent. So probably the best question I can ask is: When you had your idea of Arduino BFI for an LCD monitor, how did you plan to achieve vsync?

Software BFI is obviously able to control timings at source, and it sounds like my mistake might've been in thinking these could be extracted from the clock channel? So for example if the Arduino detected a pixel clock of 173MHz, it could say Ah! You want 60Hz BFI!, locking and maintaining sync thereafter.

But from what you've said I'm now imagining continuous visual data, with the clock reporting requirements but not carrying the necessary timings to synchronise BFI from? Does the projector receive continuous video and chop it up to match its scanouts, or is there HDMI data informing its processing? This raises the question of how VRR works. If received blind by display from console, I'd understand why extracting video allows it to be updated to sync with BFI.

I can actually enable frame-sequential 3D at 60Hz on this projector, but it still gives double images so I guess it only runs at 120. I wish someone could reverse engineer its firmware and release a custom. Same with TVs, where we only get one 60Hz mode!

BFI
Posts: 19
Joined: 23 Nov 2021, 01:25

Re: DLP BFI for Consoles

Post by BFI » 14 Feb 2022, 23:44

In summary, if HDMI is raw video without any timing data (clock channel is just for EDID reading and bandwidth allocation), a blind BFI box isn't a good idea. I finally understand why if that's the case.

Nor is modding the wheel any good, because of triple images. While capturing HDMI would add at least 50ms, because I don't believe there's a faster HDMI>USB converter than that.

I'd happily pay a few hundred dollars for custom firmware, but that's too involved unless someone was already thinking about it as a personal project.

The only other thing I can think of is piggybacking a mechanical shutter to the wheel's wiring (if there's a way to synchronise them that way), but that's beyond my skills. On reflection I'm quite happy with non-BFI 120Hz on this projector (I imagine its pixel response helps), and only wish I could have the same performance for 60fps console games.

Subjectively, 8.33ms persistence on this HD29 seems a touch clearer than 60Hz BFI did on Sony's A80J. Possibly thanks to a lack of flicker. I really wish there were a method of taking 60Hz input and outputting at 120 with alternate black frames for a 1ms cost. :(

I emailed Optoma to ask if they've any BFI plans and they said no, not at present. If I could enable their game mode at the same time as frame-sequential 3D I'd be set, but they said it isn't technically possible? I mentioned the other 3D modes having obvious processing requirements that preclude game mode.
Last edited by BFI on 15 Feb 2022, 00:05, edited 1 time in total.

Post Reply