Page 5 of 7

Re: Asus 240hz native new screen

Posted: 23 Feb 2017, 14:34
by Chief Blur Buster
Comanglia wrote:
Chief Blur Buster wrote:One trick to bypass this is to compress dynamic range, e.g. lower Contrast Ratio. e.g. map 0-255 into range 0-192 (75% dynamic range). This eliminates a lot of ghosting/crosstalk for situations where there's massive GtG issues for certain transitions.

Also, GtG measurements are pretty much a curve, I'm assuming those numbers are milliseconds to 90% transition completion? I'm wondering what GtG measurement cutoff they are using (I'll have to ask Simon Baker). Even many 1ms panels take over >10ms to get to >99% GtG, even if they only take 1ms to finish 90% GtG.
How would you do this?

btw I found the answer to the gtg measurements
Thanks, that does answer my question, that's industry standard 10%-to-90%.

You simply play with your White Level/Black Level/Brightness/Contrast until the ghosting fades. It's sometimes tricky to figure out which setting does it properly, usually one or the other adjustment will brighten blacks or darken whites. You do reduce your contrast ratio to ~750:1 when you compress to 75% dynamic range, but that can be useful for greatly reduced ghosting.

But it might or might not be worth it -- it depends on how objectionable the real-world ghosting looks, in things like www.testufo.com/photo

Re: Asus 240hz native new screen

Posted: 24 Feb 2017, 08:51
by lexlazootin
Pixel response is very confusing to me because it's a problem that is very easy to spot but seems impossible for manufactures to get perfect.

I wonder if the calibration TFT does throws off the response time numbers. And if contrast matters, how much does it effect the end result?

Re: Asus 240hz native new screen

Posted: 24 Feb 2017, 14:21
by Chief Blur Buster
Electronic calibration is simply often remapping colors to colors, e.g. mapping pixel intensities 0-100% to pixel intensities 10-90% range (making blacks a little greyer, and whites a little darker). Electronic contrast adjustment does exactly this. The GtG behaviour of specific voltages (for source pixel value) to specific voltages (for destination pixel value) are unchanged, you have to think of the display as a processing pipeline of multiple layers that handles all kinds of things. Things like HDR displays does more advanced remapping stuff, where a signal might have a much more massive dynamic range (like pixel intensities below 0% and pixel intensities above 100%) that needs to get remapped to the dynamic range of the display.

<Advanced LCD Technology Explanation>

At the very end of the day, what really matters is how quickly to transition a specific pixel to another pixel color (specifically: subpixel gray value, that's covered by a red or green or blue filter -- but there's essentially 3 gray subpixels per LCD color pixel -- LCD crystals is just wristwatch grey -- but colors made possible using filters on each subpixel -- see color filter structure of an LCD).

Crystal in an LCD (Liquid Crystal Display) panel are moving objects of mass with momentum. It's impossible to make objects of mass move instantaneously. They can overshoot or undershoot (creating ghosting/coronas/overdrive artifacts -- LCD Motion Artifacts -- LCD Overdrive Artifacts). Imagine trying to drive a car from one parking space to a different parking space as quickly as possible, with the car precisely parked to 1 millimeter. If you're a razor margin too far your color is darker. If you're a razor margin too near, your color is lighter. Trying to move (rotate) the crystals from exact position A to exact position B as quickly as possible, creates problems. If you're even just 1% off, you see a greyscale banding difference -- you need to essentially be pretty much 99.9% perfect (i.e. 1 part in 1000) for EVERY possible grey color to EVERY possible grey color -- GREY to GREY, aka "G" to "G", or "GtG". (Remember: An LCD color pixel has 3 grey subpixels, each covered by a color filter).

Going from dark grey to light grey might be like moving a car a shorter distance almost instantly to an exact stopping position (not a millimeter too far, not a millimeter too near! Or you get a ghosting/overdrive artifact.) Going from full white to full black might be like moving a car as quickly further as possible all the way to the edge of a brick wall and stopping perfectly gently touching it, without accidentally bumping into it hard and wrecking the car. LCDs have to do accurate GtG at a billion subpixels per second (300,000,000+ pixels per second, times 3 subpixels) for a 144Hz 1920x1080p monitor, every subpixel on the screen, every refresh cycle. Behind the scenes, there's often multiple voltage pulses per pixel refresh, e.g. a GtG initiating pulse (begin momentum) and a GtG stopping pulse (end momentum). That's often how overdrive works, to transmit a sudden opposite voltage to a pixel approximately 1ms after the first pixel pulse. So there's often at least 1 chase scan shortely behind the current LCD scan. They are (very) approximately at the bottom edge and the top edge of the "blurry zone" you see in high speed video at http://www.blurbusters.com/lightboost/video ... (non-strobed portion) .... That's the gas-pedal pass (first G in GtG) and the brake-pedal pass (last G in GtG), often ~1/8th of a screen height apart (at 120-144Hz) for a ~1ms transition. The blurry zone scans rapidly top-to-bottom, like a CRT, the zone is blurry because of the GtG time. A 120Hz refresh cycle is 8.3ms, so the blurry zone for 1ms GtG is approximately 1/8th screen height, as seen in the high speed video. Now given the gas-pedal and brake-pedal pulses that needs to be impossibly perfectly exact to stop that metaphorical car in an exact stopping position... No wonder imperfections (ghosting, overdrive, coronas, etc) often happen, and for the more perfect ones, we often have to pay extra (e.g. NVIDIA technology, which often has very good overdrive -- not perfect, but average overdrive in GSYNC mode and ULMB mode is often better-than-industry-average). We know how more expensive GSYNC monitors typically are. Yes, it can be even better (but could be even more expensive, too!).

It's an engineering achievement that the world has mass-market LCDs capable of 1ms GtG nowadays, but there are still rather severe problems with accuracy. And the accuracy often changes between panel runs, panel factories, temperature, etc. Only a very few has done it so extremely well (Getting better GtG, but with pros/cons like less contrast ratio, for example) -- for many years, LightBoost had far less contrast ratio than non-LightBoost, in order to help more accurate GtG transitions.

There are many metaphors to explain an LCD, but hopefully this metaphor helps people appreciate how difficult it is to get very accurate _AND_ very fast GtG response (simultaneously).

Confused? Well, let's just say -- achieving perfect pixel transitions on any LCD is a very complicated problem for manufacturers to solve.
</Advanced LCD Technology Explanation>

Re: Asus 240hz native new screen

Posted: 24 Feb 2017, 14:41
by igluk
Tftcentral wrote:For our tests we will take a 10% allowance at either end of the scale which is the same process used by all panel manufacturers, and also incorporated at other sites using similar measurement techniques. So we will measure start point when the brightness has changed more than 10% and measure the end point when it reaches 90% of it's required brightness. Thankfully the oscilloscope software allows us to accurately mark these 10 and 90% positions, and we can then simply measure the response time from there.
Chief Blur Buster wrote: Thanks, that does answer my question, that's industry standard 10%-to-90%.
Here is a sample illustration from panel manufacturer datasheet

Image

Re: Asus 240hz native new screen

Posted: 24 Feb 2017, 18:25
by Chief Blur Buster
Coincidentially -- given the topic of GtG -- RTINGS just recently released a new video on response time.
Here's an easier & more layman's explanation of LCD response time (GtG):

phpBB [video]

Re: Asus 240hz native new screen

Posted: 25 Feb 2017, 13:25
by RLBURNSIDE
That's a great video, explains it really well.

Frankly makes me not all that interested in even working on LCDs any more.

The only thing that's truly compelling about LCDs these days is high peak brightness for Dolby Vision HDR (as opposed to HDR10 which 2017 OLEDs can fully max out 1000 nits dynamic range), and maybe for projection, using stacked LCDs for mega contrast being way cheaper than LCos.

The 10ms white-to-black or black-to-white transition time seems to be a strong argument in favor of not doing BFI by transitioning the pixels themselves and doing it only via backlight strobing exclusively.

FALD rolling scan seems to be even more ideal than uniform blanking, if it's timed to show black during pixel update periods.

Re: Asus 240hz native new screen

Posted: 25 Feb 2017, 15:30
by Chief Blur Buster
RLBURNSIDE wrote:The 10ms white-to-black or black-to-white transition time seems to be a strong argument in favor of not doing BFI by transitioning the pixels themselves and doing it only via backlight strobing exclusively.
Definitely better to use backlight means of bypassing GtG limits (as long as much of GtG is hideable in interval between strobes). You can get measured MPRT persistence millisecond numbers that are smaller than GtG response millisecond numbrrs, by virtue of MPRT measured during ON cycle and GtG occuring during the OFF cycle. In some fast response panels, over 99% of GtG response manages to be hidden in the black period betwen strobes, as in ASUS VG248QE LightBoost example.

(That said, BFI can still be useful on certain strobed LCDs as a workaround to arbitrary manufacturer restriction: Use of software-based BFI that does not affect LCD response is to simply block (black out) every other unwanted strobe, e.g. Convert a 120fps@120Hz artificially-enforced-minimum-rate strobe into 60fps@60Hz for 60fps applications/viceos while keeping exactly the same motion clarity/persistence of 120Hz)

Re: Asus 240hz native new screen

Posted: 06 Mar 2017, 13:28
by gbmaster
I've just bought one of these,
it says 240hz is only supported on certain monitors:


745(OEM),.
GeForce.
GTX.
750,.
GeForce.
GTX.
750Ti,.
GeForce.
GTX.
780,.
GeForce.
GTX.
780Ti,.
GeForce.
GTX.
TITAN,.
GeForce.
GTX.
TITAN.
Black,.
GeForce.
GTX.
TITAN.
Z,. GeForce.
GTX.
960,.
GeForce.
GTX.
970,.
GeForce.
GTX.
980,.
GeForce.
GTX.
980Ti,.
GeForce.
GTX.
TITAN.
X,. GeForce.
GTX.
1060,.
GeForce.
GTX.
1070,.
GeForce.
GTX.
1080.


unfortuatntely I have a GTX760 (though the 750 and 745 are supported, the '60 isn't listed)

is there any way to bypass this?

Re: Asus 240hz native new screen

Posted: 06 Mar 2017, 14:55
by Chief Blur Buster
The incredible amount of bandwidth needed for 240Hz is over a 500Mhz dotlock!

Which only works on DisplayPort -- DVI can't even do that many pixels per second.

AFAIK, the GTX 680 isn't even capable of pushing that many pixels per second on any of its video outputs. (1080p 240Hz is about half a billion pixels per second being output)

You _might_ be able to do it at a lower resolution (e.g. 1280x720) through Custom Resolution Utility tweaks, in order to stay within the dotclock of 1920x1080p 144Hz. I'm not sure what lower resolutions are supported at 240Hz, but it would be worth testing out.

Re: Asus 240hz native new screen

Posted: 07 Mar 2017, 04:36
by gbmaster
Chief Blur Buster wrote:The incredible amount of bandwidth needed for 240Hz is over a 500Mhz dotlock!

Which only works on DisplayPort -- DVI can't even do that many pixels per second.

AFAIK, the GTX 680 isn't even capable of pushing that many pixels per second on any of its video outputs. (1080p 240Hz is about half a billion pixels per second being output)

You _might_ be able to do it at a lower resolution (e.g. 1280x720) through Custom Resolution Utility tweaks, in order to stay within the dotclock of 1920x1080p 144Hz. I'm not sure what lower resolutions are supported at 240Hz, but it would be worth testing out.
I don't have a 680 though!

I have a 760, I can sell this on ebay and get the 750 which is actually cheaper !(and presumably a lower spec)
just seems weird to me that the 750 is supported but not the '60!