Hommasimme io-techin testiin markkinoiden edullisimmat 144 hertsin Full HD- ja Quad HD -resoluution pelinäytöt, jotka Suomesta löytyy. Full HD -näytöksi valikoitui 189 euron hintainen 24-tuumainen IPS-paneelilla varustettu AOC 24G2U, joka oli Verkkokauppa.comissa Black Friday -tarjouksessa 149 euron hintaan. Quad HD -näyttönä mukana on Samsungin 250 euron hintainen 27-tuumainen VA-paneelilla varustettu C27JG50QQU.
Tutustumme artikkelissa molempien näyttöjen ominaisuuksiin ja pyrimme selvitämme, miten valmistajien kalliimmat lippulaivanäytöt eroavat näihin halvimpiin pelinäyttöihin nähden, kun kriteerinä on 144 hertsin virkistystaajuus. Suoritimme molemmilla näytöille kattavat testimittaukset Spyder 5 Elite- ja Xrite i1 Display Pro -näytönkalibrointilaitteilla.
Lue artikkeli: Testissä Suomen edullisimmat 144 hertsin pelinäytöt (1080p & 1440p)
Jännä, mulla just toisinpäin, just vaihdoin 100hz ultrawiden 32" 144hz paneeliin ja mulle tuo näytön kaventuminen ei ollut mikään dealbreaker, ennemmin hämmästyin siitä, miten iso ero tuli 100hz -> 144hz hyppäyksestä.
Ah, oikein kunnon viritelmä, eli se ns. ”parsa” ratkaisu mittaamiseen.
Jos samaa ratkaisua on tarkoitus käyttää myös noille vielä nopeammille näytöillä, ja toki myös hieman halutusta mittatarkkuudesta tarkkuudesta riippuen: laittaa suosiolla sen ledin aina samalle korkeudelle sen (oletettavasti älypuhelimen) kameran kuva-alaa kuin mistä katsoo sen ruudun muutoksen. Noissa on yllättävän hitaasti sen sensorin skannaava sähköinen ”suljin”. Kuvan alareuna on sen puoli millisekuntia eri ajassa kuin kuvan keskikohta.
10 toistoa ei välttämättä riitä hyvään keskiarvoon, eikä jakauma muutenkaan välttämättä ole sellainen, että keskiarvo kuvaisi hyvin sitä mitä tapahtuu. Mutta tämän toki näkee sitten siitä datasta.
Hihasta: Miksi keskiarvo eikä suosiolla mediaani? (Tuon vaihteluvälin kun olettaisi olevan nätti parin tasajakauman summa: pelin FPS sille että peli näkee hiiren painalluksen + näytön virkistystaajuus siihen että se pelin reaktio näkyy uudessa kuvassa.)
Tavallaan ihan mielenkiinnosta onkin, että miten esim. XXX-sync vaikuttaa tuohon tyypilliseen puhumattakaan tuohon maksimiviiveeseen (jonka pitäisi järkeiltynä olla noin ”1 ms + 1/FPS + (N+1) × 1/virkistystaajuus”, missä N on näytön kuvapuskurin syvyys). Minimissään hyvällä tuurilla tuon 1/FPS osuuden saa tasan nollaan, samoin kuin tuon 1 ms (hiiren päivitystaajuus) ja kuvapuskuristakin säästänee yhden ruudun jos nuo on kivasti synkassa juuri sillä hetkellä. Keskimääräinen viive sitten olisi toki jotain näiden väliltä.
Jos kaikki muu laitteisto pysyy samana ja softa on lyhytviiveinen ja ennustettavasti käyttäytyvä (nopeatahtinen ja hyvin koodattu räiskintäpeli lienee parhaasta päästä), niin ledi + suurnopeuskamera on hyvä ja yksinkertainen tapa.
Hiiren simuloiminen ja kirkkausmuutoksen mittaaminen Arduinolla ei nähdäkseni tuo juurikaan lisäarvoa testiin. Siinä on edelleen kuitenkin tietokone softineen välissä ja Arduinon koodin toimintaakin joutuu miettimään. Lisäksi valoanturin käyttö asettaa omat haasteensa, ja jos sen takia pitää käyttää jotain erityistä testisoftaa kun esim. CS:llä ei onnistukaan, sen laatuun pitää kiinnittää huomiota.
CRT-näyttöön vertaaminen on ihan mielenkiintoinen idea, mutta miten onnistuu korkeampien virkistystaajuuksien tai varsinkin G-syncin/Freesyncin testaus?
Tarkempi mittaaminen vaatisi tarkoitukseen tehdyn signaalilähteen, jossa olisi integroituna mittaus tai lähdöt oskilloskoopille.
Toisaalta etuna arduino+valosensoriratkaisussa on merkittävästi parempi temporaalinen resoluutio kuin juuri missään suurnopeuskameroissa, hinnan pysyessä todella pienenä. Mitään erityistä testiohjelmaakaan tuskin tarvitsee jos valoanturin asettaa vaikkapa aseen suuliekin kohdalle, lokittaa arvot vaikkapa miljoona kertaa sekunnissa ja katsoo niistä jälkikäteen tarkan hetken kun valon määrä alkoi muuttua. Ajan mittaamisenkin saa hoitumaan aidosti siitä hetkestä kun se klikkauksen sisältävä HID paketti lähtee liikenteeseen tietokoneelle päin. Ledillä ja 1000fps suurnopeuskameralla tulee vähintään 2ms jitteriä jo päivitysnopeuksien takia.
Bonuksena tällä setupilla voidaan verrata viiveen osalta keskenään myös vaikkapa prosessoreja ja/tai näytönohjaimia, kunhan vastaavasti näyttö pidetään vakiona. Myös joku ”nollataso” voidaan tälle järjestelmälle kalibroida näyttöjen osalta näyttämällä sille kertaalleen crt näyttöä.
Jos täältä löytyy joltain kiinnostusta toteuttaa esim. tuollainen arduino+valosensoriratkaisu + softa näytön inputlagin mittausta varten niin maksan mielelläni kulut.
Tosta sais varmaan hyvän AMK lopputyön aikaiseksi. Tiedä sitten että onko täällä paljonkin asiasta kiinnostuneita sopivassa vaiheessa opintoja olevia ihmisiä.
Näytöissä kun on useita valmiita väriasetuksia (yleensä tyyliin media, pelit, esitys tms.) niin olisi kiva tietää, mitä asetusta käytettiin mittauksia tehdessä.
Tarkoitus on, että kaikki mittaukset tehdään näytön tehdasasetuksilla eli myös väriprofiilina käytetään sitä joka näytössä on oletuksena valittuna. Yhden näytön kanssa tähän piti tehdä poikkeus, koska oletuksena oli profiili, joka sotki mm. väritarkkuuden mittaamisen täysin ja tällöin asiasta mainittiin artikkelissa erikseen.
Noi Sampat näyttäs olevan aina kehnoja >_<