Is Local Dimming/Quantum Dots Really a Good Thing?

[jorimt]

Thanks for the backup and additional facts @BattleAxeVR, very informative!

I would have corrected @darzo on quantum dots myself, but I must have missed that comment.

As a side note, there are two entirely different quantum dot technologies. The first you already mentioned, the second is an emissive alternative to OLED, but has no set date for production (e.g. it is currently in the theoretical/conceptual phase for practical mainstream mass production in consumer displays).

[Chief Blur Buster]

In theory, it's possible for an LCD TV to start scanning out when fed with RGB signals line-by-line, and I assume many "gamer" monitors already do this to get sub-frame latency levels

Yes, they already do.

More than half of TN-panel "Better Than 60Hz" monitors already do, yes. VA has more problems with it, but both IPS and TN has been scanned in near-realtime (line-buffered) with cable input. Allowing a few lines of line buffering for DisplayPort micropacket jitter.

Most processing (overdrive, picture, etc) can be done (and already are) in a line-buffered way.

but when you feed an HDR image over HDMI 2.0a, you need to pass it via YCbCr 4:2:2 at best, which is a planar format instead of a packed format, i.e. the chroma planes are located after the luma plane in each frame.

Not all methods of transmitting luminance/chrominance are planar. Framebuffers collecting YCbCr data have been historically packed as YVYU so you can transmit YCbCr as a packed format over a cable (and I believe, AFAIK, historically has been...). Then it'd be compatible with realtime scan-out.

However, I am not currently familiar with how HDR10 is transmitted over HDMI, if it's planar/packed at cable transmission level. I'll need to look up the specifications. If it is packed, then HDR can in theory be displayed nearly laglessly.

Also, planar-and-packed are sometimes different at cable level versus framebuffer level. From an input-lag perspective, we're chiefly concerned about the cable level -- that full picture info is fully transmitted for a full row of pixels (scan line). This is fully compatible with top-to-bottom sequential-scanout technologies (e.g. CRT, LCD, OLED, etc) for near-lagless sync between cable and panel, regardless of how the framebuffers are internally stored (planar or packed, on GPU or display end).

Also, don't forget decoupling of video signals from display dotclocks, via accelerated frame delivery techniques.
HDMI 2.1 has a new feature called Quick Frame Transport (QFT) which reduces latency. It's essentially the same trick that G-SYNC/FreeSync users can do now. For example, 240Hz GSYNC monitors playing 60fps games -- each "60Hz" refresh cycle is delivered in 1/240sec -- this is the concept of Quick Frame Transport (QFT). Accelerated frame delivery will help reduce lag of planar formats (if planar is being used as a cable-delivery mechanism). The QFT concept is exactly the same: Deliver a refresh cycle at the cable's maximum dotclock (which can sometimes be independent of the GPU/display).

Also, in addition, this concept is also the same as the "Large Vertical Totals" tricks that Blur Busters Forums users talk about. Basically, using a higher dotclock for a lower refresh rate, and padding the time between refresh cycles with a larger VBI. Visible frames delivered faster, followed by longer VBI waits between refresh cycles.

You can even deliver faster than the maximum Hz, if the chips can decouple the dotclock from the display (it has been done before). HDMI 2.1 is also capable of delivering a 1080p frame in less than 1/1000th of a second, if you transmit the frame at full wire speed.

Even five years ago, there are some 60Hz displays (not-capable of 75Hz or 120Hz without frameskipping) that I found was able to accept a 75Hz-derived-dotclock or 120Hz-derived-dotclock "60Hz" signal, which allows them to display a 60Hz refresh cycle a little sooner than a regular 60Hz. I'm glad that this old accelerated-delivery trick is now officially becoming part of HDMI 2.1 and VRR technologies.

Pushed to its extreme, QFT can deliver fully planar 1080p over HDMI 2.1 in less than 1ms.

So input lag of planar frame delivery doesn't actually necessarily correspond to the refresh cycle time, if using any variant of Quick Frame Transport (or its similar predecessors, like using G-SYNC/FreeSync + 60fps for a low-lag "60Hz" signal, or using Large Vertical Totals as an input-lag-reducing trick).

Using a Large Vertical Total via large Front Porch instead of large Back Porch/Sync is a very old undocumented QFT technique -- it even reduced 60Hz VSYNC ON lag on high-Hz CRTs twenty years ago, but almost nobody knew about this very old-fashioned lag-reducing trick that was hard to measure (But now we have lag testers). It can reduce input lag (especially for VSYNC ON) of a lower refresh rate on certain displays.

All these QFT tricks (whether via Large VT's, or via G-SYNC/FreeSync high-Hz-low-fps, or via HDMI 2.1 QFT) are all similar in concept in "Custom Resolution Utility" arithmetic, differences are simply semantics. All the above are simply "full wire-speed transmission of a refresh cycle" under different techniques.

Some emulator users now use G-SYNC/FreeSync monitors to reduce 60Hz input lag, because G-SYNC/FreeSync are essentially natural QFT systems (60fps delivering frames in 1/240sec on a 240Hz GSYNC monitor).

This doesn't work when you're using the max Hz (you're forced to use Reduced Vertical Totals for 144Hz, for example) but monitors capable of >60Hz can have lower-lag 60Hz via these little-known old QFT hacks. Basically trading high-Hz room as a low-Hz-refresh-cycle accelerator. This is mostly useful for reducing lag, of say, 60Hz VSYNC ON applications.

But now that it's open, we'll be writing more in 2018 about QFT techniques, and how to take advantage of "QFT equivalents" on non-QFT systems, even dating back to 20-year-old PowerStrip/CRU tricks, and more publicizing about how to carefully calculate lag-reducing Large Vertical Totals for VSYNC ON applications (e.g. emulators, etc).

[RealNC]

There is no reason why FALD would have any more latency than edge-lit, as the entire frame must be present inside the buffer prior to calculating the overall frame's luminance for dynamic (local or global) dimming. The processing time for such calculations is trivial, and won't add anywhere near a full frame of latency if it's done competently.

I meant latency vs non-HDR content. So you'd say dimming does need to buffer at least one frame?

[darzo]

Would local dimming and/or quantum dots eliminate the bleeding and other such issues associated with IPS? I've also heard some things about what it would take to do 4k at 144hz over DisplayPort 1.4, mentioning that xx ratio and compression.

I.e. are there areas of concern with these monitors? What are the ghosting/artifact effects of the 4ms IPS response time? Are they on the negligible side for a first person shooter?

[Chief Blur Buster]

There is no reason why FALD would have any more latency than edge-lit, as the entire frame must be present inside the buffer prior to calculating the overall frame's luminance for dynamic (local or global) dimming. The processing time for such calculations is trivial, and won't add anywhere near a full frame of latency if it's done competently.

I meant latency vs non-HDR content. So you'd say dimming does need to buffer at least one frame?

Not mandatory.

Technically, local dimming can be line-buffered up to roughly the height of the LED zone. If the local dimming LEDs cover, say, 20 scanlines tall, you only need to line-buffer 20 scanlines. At, say 220KHz scanrate (1440p@144Hz), that's only 20/220,000th of a second of lag -- less than one-tenth of one-millisecond.

Software engineering limitations may enforce a frame of lag, but it shouldn't.

The question is.... What is the monitor firmware actually doing?

[jorimt]

Would local dimming and/or quantum dots eliminate the bleeding and other such issues associated with IPS??

Again, quantum dots in this specific context would do nothing to lessen backlight bleed. Local dimming will, but as I stated previously, there may be "blooming" artifacts; their severity depends on the amount of zones and the panel type being used.

The question is.... What is the monitor firmware actually doing?

Good question, and I'm sure the functionality and effectiveness varies from implementation to implementation.

As per the TFT Central review I linked earlier, there was a visible delay between the content change on-screen, and the adjustments the local dimming made after the change. My FALD TV does not have this issue, so I can only conclude firmware technique/quality can vary.

[darzo]

384 zones and IPS. Blooming artifacts?

[jorimt]

384 zones and IPS. Blooming artifacts?

I posted the link to the TFT Central review earlier in the thread:
http://www.tftcentral.co.uk/reviews/del ... 8q.htm#hdr

See emboldened text below:

The effectiveness of this local dimming depends on how the backlight is operated. The most basic HDR capable screens might attempt this local dimming simply through edge-lit dimming where the panel is backlit by LED's along the sides of the screen. While you can do some level of dimming through the adjustment of the edge-lit LED's it gives limited control over the zones on a screen and its very tricky to pick out small areas effectively. A far better approach to achieving accurate and reliable local dimming is to provide a backlight split in to hundreds of small zones, where each zone is lit by a small set of LEDs. The higher the number of zones the better, as it gives more finite control over the image on the screen. Dark areas can be dimmed, while bright areas are accentuated and made brighter. This gives rise to the higher active contrast ratio of 20,000:1 or more in the HDR spec requirements but done in an optimal way.

On the Dell UP2718Q the panel is paired with a 384-zone LED backlight which offers a much better control over local dimming zones than an edge-lit option. The above image is taken from the forthcoming Acer Predator X27 display, but that too has a 384-zone FALD backlight unit so gives a good idea of how the panel is lit here on the Dell. Many HDR displays in the market will go for the simpler, and cheaper edge lit dimming where larger areas of the screen must be dimmed at once, and so the fact this model has a FALD backlight is what helps to separate it from the others and provide more optimal HDR experience on an LCD screen. This is why the screen has a thicker profile and ultimately a higher retail price as well.

You still need to keep in mind that the screen is not being individually lit at a pixel level, and so there is still some impact in varying the brightness of different zones, even when there are quite a lot of small zones like here on the UP2718Q. Depending on the content shown on the screen, you may seem some "blooming", where the bright areas have a halo or glow around them as zones bleed over in to one another. The smaller the bright point on the screen, the more tricky it is to correctly light it in an HDR environment without this blooming and haloing occurring.

We don't have to imagine what the performance of a 384-zone FALD IPS (albeit 60Hz) would be, they've already tested it. It's superior to edge-lit, but it's far from perfect.

As for the appearance of "blooming artifacts" themselves, these images from a DisplayMate review of the 2017 LG OLED series show worst case (stress test conditions) for both FALD and edge-lit (partial) local dimming:

2017 LG OLED (left), 2017 edge-lit local-dimming (right):


2015 LG OLED (left), 2015 FALD LCD (right):


And before you go thinking OLED is the holy grail for PC monitors, you've got image retention (with possibility of permanent burn-in) and uneven brightness (a form of vertical banding) on darker, more uniform images.

There's no perfect solution, and there likely never will be.

[Chief Blur Buster]

<Blur Reduction Related Tech Talk>
While we're talking about technical aspects of Full Array Local Dimming (FALD) -- many FALD backlights also double as scanning backlights (motion blur reduction ala ULMB, but illuminating only part of screen at a time, rather than globally). Where you can illuminate a row of LEDs far away from the pixel-transitions, to strobe only part of the LCD at a time.

The goal being, you illuminate completely refreshed part of panel, while keeping a still-refreshing part of panel in dark, by scanning a row of LED's out-of-phase with the LCD GtG zone...

But scanning backlights have the internal-diffusion problem -- exactly the same kind of problem as local dimming blooming. Except it's worse, because you'll be leaking out through unilluminated non-black LCD panel parts (between flashes), so the blooming issue is more extreme with scanning backlights than when only used with pure local dimming. So the cards are often stacked against scanning backlights in motion clarity.

Internal diffusion (Blooming) amplifies strobe crosstalk in scanning backlights.

Only full-strobe-mode can get really close to CRT-clarity (for screen centre) unlike for scanning, because of GtG now being able to be mostly crammed into total darkness -- e.g. 1ms GtG (TN) and 8ms-long refresh cycles (120Hz), and flashing only when fully refreshed.

Generally, it has now become easier to have strobe backlights outperform scanning backlights (provided VBI takes longer than GtG - this is where large VBIs come into play, to give enough time for pixel transitions to settle between refresh cycles). On the other hand, they're not mutually exclusive -- FALD can either do full-strobe or scanning-backlight (partial strobe at a time). which increases screen-center strobe crosstalk in exchange for equalizing top=center=bottom (similar amount of strobe crosstalk throughout the screen). Many FALD's use a scanning-backlight mode, but it's useful to have a FALD strobe-mode versus FALD scanning-mode (same monitor can strobe versus scan). Since the strobe crosstalk for TOP/CENTER/BOTTOM becomes "OK-OK-OK" (scan mode) versus "BAD-GOOD-BAD" (full-strobe-mode), and screen-center is usually the most important to keep free of strobe crosstalk...
</Blur Reduction Related Tech Talk>

[darzo]

I've already read the Dell monitor review. It's understandable but conveyed little to me in practice. Likewise I find those images virtually nonsensical.They remind me of Amazon reviews about how basically monitors emit light. Black screens with light all over them. See the same thing when I turn off my computer, make no connection to what appears on the screen when something is actually there because it's so different and normal looking.

I.e. is blooming actually something to be concerned about, something that would stand out and bother someone?