USB real-time light sensor (or camera) with millisec precision? Testing lag/flicker.

[Mark Rejhon]

Hello all,

I want to test computer monitors, with such a sensor, and my own custom app.

-- Does any Spyder colorimeters have a high-speed capturing mode that allows real-time monitoring of light output from the computer monitor?
-- Alternatively, does any other light sensor have a high speed capture mode, capable of photometric light measurements timecoded at millisecond precision (or better)?
-- Something inexpensive (e.g. less than $300) is desirable, something that everyman/blogs/reviewers is easily able to purchase/borrow for themselves.

As a C/C++/C# programmer, I am presently researching the viability of a computer-based benchmark application, that can use an inexpensive off-the-shelf sensor, to measures: "motion resolution", "LCD lag", and "backlight PWM flicker" measurements. My ultimate goal (eventually) is to create a "Monitor Performance Benchmark" app that covers the following.

...Measure input lag.
The benchmark app can change image, and measure the amount of time elapsed before the sensor detects light (stopwatch measurement starts at the beginning of VSYNC).

...Measure backlight flicker
The benchmark app can use this to detect annoying PWM-dimming backlights (a frame would flicker several times in repeats), scanning backlights for gaming (a frame would flicker once), and black frame insertion for gaming (a frame would flicker once), and the ability to turn them off for flicker-free (steady light when scanning/BFI is turned off via OSD menu).

...Measure predicted motion resolution
The benchmark app would run a suite of tests, to detect the existence of scanning behavior (CRT or OLED or plasma or scanning backlight LCD or black frame insertion LCD), and then display a predicted motion-resolution score (e.g. "Your monitor has a computed motion resolution of 237").

The software would have other benchmarks, such as a fast-moving resolution test pattern, and simulated fast-smooth-scrolling browser window (human verification check of motion resolution) , to allow 60 Hz vs 120 Hz vs 240 Hz vs 480 Hz comparisions (simulated via some scanning/refresh mechanism, instead of motion interpolation), etc -- similiar to pre-existing Blu-Ray motion resolution benchmark tests that already exist in the home theater world.

A lot of the eqiupment used to be expensive, but it appears there are a lot of cheap sensors now, and now I'm interested in which computer-connectable light sensors are fast enough to allow me to do this C/C++/C# project using DirectX API's. As I'm okay with a soldering iron, I'm sure I could do it within a week using Digikey/Arduino parts for under $100, but I want a mass-market thingy (e.g. commandering a Spyder sensor for a purpose it wasn't originally intended for) so that everybody else can get the sensor easily, for use with the benchmark program I want to write.

There are existing testers, such as Lagom.nl and Softpedia instructoins, side-by-side CRT-and-LCD monitor test with high speed camera, as well as manual measurements with a digital camera -- but I want something easy and automated, connect a Spyder sensor, suction-cup it to the centre of a monitor, and just run the benchmark and get scores fairly accurate (+/- 1ms) to CRT+LCD side-by-side testing that is often used by some testers.

A computer-connected SLR camera (capable of 1000 fps, even if it's just a 16-pixel-tall image), is an alternative option, but those would be more expensive than building your own USB-connected photodiode sensor, or hacking a Nintendo Zapper lightgun (1980's technology has sufficient precision! It was designed to measure light precisely enough to catch a CRT in mid-horizontal-scan; it's far better than 1/100,000sec precision!), or building an Arduino+photodiode USB accessory for my PC. I'm just wondering if there's off-the-shelf photodiode sensors that have sufficient speed & resolution, to allow "out-of-the-box" monitor performance benchmarking today.

(P.S. I wouldn't mind teaming up with others, free, charitable, open-source, commercial, or proprietary -- for this. As long as the benchmark can be made publicly available and the sensor is publicly available.)

Thanks,
Mark Rejhon

 

[IanM]

A UK forum that has an editorial staff doing HDTV reviews recently started using this device for lag testing: http://www.leobodnaroundar.com/products/LagTest/

I'm not too sure if it's any good - the results seem to be about the same for everything tested and quite high at something over 40ms. I'm a bit sceptical and would like to see some extensive tests using known monitors with ~zero lag to see if the device actually is reliable.

 

[Mark Rejhon]

A UK forum that has an editorial staff doing HDTV reviews recently started using this device for lag testing: http://www.leobodnaroundar.com/products/LagTest/

I'm not too sure if it's any good - the results seem to be about the same for everything tested and quite high at something over 40ms. I'm a bit sceptical and would like to see some extensive tests using known monitors with ~zero lag to see if the device actually is reliable.

That device might fit what I need -- I would need to verify measurements with the CRT-next-to-LCD test, to verify accuracy, before beginning to trust it. I'd also test with my HDTV (with features turned on/off, like Game Mode, motion interpolation, etc), and see if the lag increases/decreases as predicted.

The software they're using might not be using a proper reference lag timing standard. The software that they are using for the meter might need to be re-calibrated to account for several factors:
- Begin the stopwatch beginning at VSYNC. Don't just display an image and start stopwatch; you must time it from VSYNC
- Compensate for double-buffering and DirectX lag (usually at least +16ms lag on 60Hz), we don't care about this -- that's software lag, not monitor lag. So subtract software lag from score.
- Alternative lag measurement test: Turning off VSYNC is one method too, then wait for the graphics card to finish refreshing mid-screen (e.g. refreshing line 512 for a 1024-pixel-tall display), then suddenly change the whole screen from black to white, and measure when the sensor detects light. This would require access to the graphics card register for what rows of pixels is currently being output (for DVI / HDMI), and what scan line is being output (for VGA). Possibly Microsoft DirectX object "RasterStatus.ScanLine" already gives that data through an API means. One could even attach the sensor to the screen surface on a 'cross hairs' test pattern generated by software, so the sensor is a few scan lines underneath the center of the screen. Doing this vsync-off (tear test) on CRT would be less than 1ms lag in this situation. This could be an alternate method of measuring input lag, that's more accurate.
- Test with a CRT (for reference measurement). This will calibrate the sensor to sensor lag (e.g. USB lag, and whether processor load/different GPU's induces lag).
- Reference monitor lag would be CRT.
- Subtract reference monitor lag from future measurements, to determine LCD lag compared to CRT lag.
- There could be multiple configurable methods of starting measurement (e.g. VSYNC on and VSYNC off methods, and repeat-averaging methods)

The question of standardization of lag may need to be answered. Is it lag for the completion of a full frame? (If so, CRT is 16.6 millisecond at 60Hz). Is it a lag for pixel scanning? (If so, CRT is 0 millisecond) The lag timing MUST be standardized, for proper comparision.

That said, this device sounds a little specialized, but it might be usable for the other tests too, including measuring backlight PWM and scanning mechanisms. I'll drop them an email and point them to this thread, though it would be nice to do the same thing with a cheaper, more mass-market component. Using a Spyder colorimeter could theoretically work, if I'm able to use it for high-speed measurements, though its electronics might not be designed for it.

It's a shame that such equipment is not more widespread/easy to access -- all it is, is basically 1980's Nintendo Zapper technology (the light gun was capable of better than 1/100,000sec precision, because it had to catch a CRT raster in mid-scan horizontally)

 

[Mark Rejhon]

Also, an important part of input lag, is that some LCD panels have different input lag for the top edge of the screen and the bottom edge of the screen.

For example, some 120 Hz TV's buffer the incoming 60 Hz images, and then display the frame in an accelerated manner (1/120th second). This means the input lag of the top edge of image becomes decoupled from the input lag of the bottom edge of the image, since the bottom edge gets displayed within 1/120th second, rather than the signal rate (1/60th second). Obviously, the buffering adds an increment of a refresh.

So different test patterns will be needed for the top edge, and bottom edge, to measure input lag in different parts of the display, to compute an average input lag. This is very important, too. If the numbers differ, then it is a buffered refresh output at a different refresh speed than the signal. If the numbers is the same, it's a synchronous top-down raster-style refresh. Two meters connected simultaneous, would automate testing even further, and announce additional information, and the two separate sensors would essentially "verify each other's measurement", as well as allow testing lag differences between two different displays.
- "Average Input Lag"
- "Top edge input lag"
- "Bottom edge input lag"
- "Your display has continuous illumination. This can be bad for motion blur."
- "Your display is flickering at 180 Hz (e.g. PWM backlight)" (display white screen and count the number of light flickers per second)
- "Your display is behaving like a CRT. It seems to be a flicker-refresh technology such as plasma or scanning backlight LCD."
(an algorithm would distinguish it from flicker backlights, by making sure there's only one pulse per refresh, rather than repeated pulses of light per refresh.)
- "Your display is currently using motion interpolation"
(Measurement of this is possible using a simple photodiode: Motion test pattern involving a serial series of moving alternating white/black squares or lines, and the sensor would measure more changes in light than the number of refreshes per second, then compare to reference test pattern signals like generic lag, to verify that the measurement is probably correct.)
- "Your display is currently NOT using motion interpolation"
- "Your display seems to be buffered. Bad for input lag. I'm detecting a different refresh rate of ___ Hz"
(Measurement of this is possible using two sensors at the top and bottom, if the measurement is less than 8ms apart, it is probably a framebuffered image refreshed at near 120Hz, even if the Radeon/Geforce is outputting only 60Hz -- for 120Hz HDTVs that tend to buffer the image before re-outputting at native refresh rate)
- "Your display has motion resolution equivalence to ___ Hz" (CRT would measure about 1000, plasma potentially near 600, most LCD's under 60)
(This is accomplished by measuring light pulse lengths and number of light pulses, for various test patterns, as part of an integrated test)
- "Dual Monitor test: Monitor B is lagged by X milliseconds after monitor A"

Each test would tell you where to put each sensor, and then a test would commence.

I'm smart enough to write a benchmark program to be able to do that stuff -- all I need is a millisecond (or better) precision meter, that's easy to program by API. Preferably 1/10,000sec, which is even better. Might not be able to make it a huge project all at once, but I could get some of the above metrics done quickly, with the rest taking more time eventually as the software is expanded.

 

[Mark Rejhon]

Still waiting to hear back from Leo Bodnar. Does anyone have any alternate contact info for him?