Page 1 of 1

I need help side by side testing my monitors.

Posted: 10 Jul 2017, 17:47
by open
I just got the pg258q and i swear it has more input lag than my old vg248qe. I want to side by side test them but all i have is a cellphone camera. Also i have just one displayport and one hdmi connection so hopefully i can test both at 120hz and swap connections to sperate any connection differences from my measurements.

You guys think this will work?

Re: I need help side by side testing my monitors.

Posted: 10 Jul 2017, 18:57
by Sparky
open wrote:I just got the pg258q and i swear it has more input lag than my old vg248qe. I want to side by side test them but all i have is a cellphone camera. Also i have just one displayport and one hdmi connection so hopefully i can test both at 120hz and swap connections to sperate any connection differences from my measurements.

You guys think this will work?
You should be able to get some results, it would be best if you can set the shutter time manually. If not you'll have to play around with the room lighting. If your phone has manual settings turn the ISO up and the shutter time down. This will make for a grainy image, but we're not looking for pretty pictures here.

Re: I need help side by side testing my monitors.

Posted: 10 Jul 2017, 22:38
by open
Test complete. The pg258q actually seems to have a lower input lag and response time sum. This was a very rudimentary test though.

Despite only being able to test at 60hz due to having to borrow my friends crappy hdmi cable, the pictures showed that the monitor using HDMI was about 1 frame behind the other. This was regardless of which monitor was the clone in nvidia display setup. But the PG258Q was partway updated every time while the VG248QE was an entire frame behind every time. Kindof impressed that I was able to measure anything using 60hz and a cellphone camera.

Re: I need help side by side testing my monitors.

Posted: 13 Jul 2017, 15:32
by Chief Blur Buster
This is the SMTT 2.0 technique of lag testing -- the same method of what TFTCentral uses.

There is a brand new TestUFO display lag test coming that has same (or sometimes better) accuracy as SMTT. Not yet published -- the TestUFO input lag test is partially complete, and now undergoing beta testing. I am pleased pleased to say I invented a VSYNC-locked test pattern (no 1000fps needed like SMTT) that achieves same millisecond accuracy as SMTT. As the inventor of specially designed test patterns (e.g. Eye Tracking and Pursuit Camera Sync Track), this is a new invention of ours that achieves millisecond-accuracy lag differentials from coarse refresh cycles (even at 60Hz = 16.7ms per refresh cycle / frame time).

SMTT-type lag tests are not as accurate as the gold standard (laboratory oscilloscope attached to a photodiode, timed to ~50% GtG point), but it works well as a low-budget method of display lag testing.

Maximizing accuracy also includes figure out your camera sensor's scan direction (top-bottom versus left-to-right) and properly orient your camera with the two monitors tightly coupled in the middle of your image, to minimize sensor scanout time. Use opposing camera scan direction (bottom-to-top scan) relative to display scan direction (top-to-bottom). Rolling shutter delay should be configured as short as possible (preferably 1/1000sec, manually configured, use a 3rd party camera app if using a smartphone).

Once configured properly, and setting your screens to maximum brightness, usable lag comparisions can be achieved with a smartphone camera (only when oriented in one 90-degree orientation, however -- to minimize "camera rolling shutter" interference to lag results -- smartphone cameras often use a very slow rolling shutter but there are tricks to reduce that problem).

The upcoming TestUFO lag tester is specially designed to be easy to calculate the millisecond differences between two adjacent displays (i.e. CRT vs LCD, or between two LCDs), in an SMTT 2.0 style manner. Stopwatch displays can only have an accuracy of a refresh cycle, but SMTT can go roughly millisecond-accurate (as does the upcoming new TestUFO display lag test).

Regardless of what test pattern you use (SMTT, or stopwatch display, or future TestUFO display lag test, etc) -- the lag-test-by-photo process is generally universally following instruction procedure:
  1. Use two displays. You're measuring a lag differential. If you're measuring absolute lag, make one of the display a CRT. Or using a reference LCD display with a known exact lag result (compared to CRT).
  2. Use lagless video cloning. That means a DVI splitter is best. However, display cloning can still provide usable results provided you pre-test two identical displays, and/or do separate lag test runs with inputs swapped (the lag differentials will suddenly change), to ensure cloning isn't adding lag.
  3. Set displays to maximum brightness. This makes it easier to photograph using fast shutter.
  4. Use a camera with a very fast shutter (1/1000sec). If using smartphone, use an app with custom configurable shutter length.
    Lag inaccuracy will be fudged by the shutter length. e.g. 1/250sec shutter will add 4ms error to your lag differential, potentially worse. If camera aperture is adjustable, such a Nikon/Canon SLR, set camera's aperture to maximum size (lowest F-stop) to absorb maximum light during short exposures.
  5. Run a test pattern like a clock (inaccuracy of one refresh cycle) or SMTT pattern (can be millisecond accurate when done properly).
  6. If using slower cameras such as smartphone, you have to work a bit harder to bypass rolling shutter interference to lag results. This can improve precision of even slightly slower shutters too. Align displays side-by-side (use vertically-scanning rolling shutter, not horizontally-scanning -- usually you have to photographing while in landscape mode -- and it's easier to interpret lag results if you use opposing scan direction -- bottom-to-top camera sensor scan with top-to-bottom refresh displays). Photograph from a far-than-usual distance, with the two side-by-side displays taking minimum vertical height of the photograph. That means the camera sensor scan will take less time to cover the reduced vertical distance in the photograph. Don't go too far away, or the reduced resolution will make it harder to interpret lag results