I am tinkering with an idea wherein I create some github repositories for testing tools/scripts/checklists for testing all sorts of things. I’ve talked about my desire to totally automate everything, similar to but entirely different from the Phoronix test suite, for all types of testing.
So, to small and see if it catches on, I’m going to start drafting a markdown checklist for monitor testing. Eventually I plan to put all this on bitbucket or github and accept pull requests for changes.
This is a draft of what I was thinking for monitor testing. This checklist will also help me adhere to full and complete testing, and this is something I want to be shared in the community so that tests anyone would do would follow these checklists.
Monitors are both easy and hard. There is a lot of low-hanging fruit for testing. Just because a monitor accepts 144hz input signal does not mean that it displays the 144hz signal accurately.
EDID Refresh Rates:
Confirmed No Frame Skip @ EDID Refresh Rates:
High Speed Footage: black to white
High Speed Footage: 64 to 192 (gray to gray)
Input Latency Measurement: (ms)
Testing – Colors
Spyder5 Pro Report PDF: _________ displaycal.net Report PDF: ________
Downloadable ICM Color Profile: ___________
Conclusion
Impressions, Gaming testing, productivity testing, other features, discussion, conclusion.
I love the idea and hope it expands in scope and to other devices.
When I used to do architectural engineering it was always handy to have a standardized checklist because even though I was supposed to be an “expert”, it’s easy to forget something and it’s good to have a consistent measuring stick.
Now if only I could afford a monitor worthy of testing.
That’s a good comprehensive checklist. I’d certainly contribute to this project when I’m available.
I used to do monitor calibrations for photo studios
So I thought I’d add something that’s oft forgotten:
Physical:
Panel surface: Matt or Glossy, does it fare well in a brightly lit room or is it best reserved for the IT dungeon.
Power cable length - this one can be annoying.
There’s a few more here, but I don’t deem them relevant in this case.
UI:
The monitor’s menu interface
How usable is it? Buttons/Menu Layout. (This is usually impossible to find out when buying a monitor online)
Can you adjust white balance in Kelvins, or does it just have warm/cool presets. (really useful for the photographers who calibrate out there)
Testing
Control for Ambient Light
Avoid direct sunlight. The spyder colorimeters make use of an ambient light sensor to bias(steer) their profile.
Don’t test in the dungeon, have a well, evenly lit room. Avoid ‘off-white’ light that’s straining to the eye.
Don’t point spotlights at the monitor(or really dont even have them in the room), especially when testing while filming.
DisplayCAL and Colorimeters
DisplayCAL supports A LOT of colorimeters, however it has a few catches.
Colorimeters have color profiles too to correct for sensor innaccuracies, and manufacturers usually embed/load those in their own software.
If you use it, make sure it loaded in the color profile for the colorimeter. It may ask you to provide one from your driver CD. So if you still notice a large offset in the sRGB/aRGB coverage in the results from DisplayCAL/Spyder Pro software, then one of those isn’t handling the colorimeters output quite right.
DisplayCAL is really great software which I use myself, so a note: if you’re going to make a test with it, you’re going to need buckets of patience. It’s really slow err… thorough.
May I suggest testing that attention is paid to the actual behaviour on the various inputs? There can be problems arising from power saving features or switching between input sources. For example, sometimes ports go to sleep; it possible to turn the monitor off and then back on again without the input not being recognised and requiring physical reconnection or system reboot? Likewise with switching between multiple inputs where the hosts have display power management enabled?
