- OLED TV topic
- AMD GPU-k jövője - amit tudni vélünk
- Mindennél nagyobb: tesztpadon a Ryzen 9 9950X3D CPU
- RAM topik
- Fejhallgató erősítő és DAC topik
- AMD APU (AM4 és AM5) topik
- Megkapja az FSR 4-et a PlayStation 5 Pro
- Feltűnt Kínában az AMD Radeon RX 9070 XT referenciadizájnja
- AMD Navi Radeon™ RX 9xxx sorozat
- AMD Navi Radeon™ RX 7xxx sorozat
Új hozzászólás Aktív témák
-
válasz
general
#5461
üzenetére
- Az a baj, hogy egy RGB->YCC->RGB konverzió 10 integer bit-el nem reverzibilis.
+ Amit elpusztít a konverzió, azt más semmi nem hozza vissza, főleg nem egy kalibrálás.
- Másrész sajnos vannak eszközök, amik rossz konstansokat használnak a konverzióhoz.
+ Ezt részben tudod kompenzálni kalibrálással, de rengeteg pontot kell lemérned és 3DLUT korrekciót használni. Namármost a MacOS csak 1 görbe + mátrix profilt támogat.
= Összeállt a kép, hogy miért az RGB->YCC->RGB konverziót kéni kiiktatni...?
Vezesd le, hogy miért nem...A kalibrálás előzménye, 0. pontja kiiktatni az ilyen problémákat, mint a RGB->YCC->RGB.
Viszont a gyakorlatban alternatív opció egy megbízható, dedikált jelgenerátort használni, amiből tuti, hogy RGB-Full megy ki egy PC monitorra, visszakötni a felhasználó gépére, majd ellenőrizni. Ha nem jó, akkor helyre kell kalapálni a forráseszközt, míg úgy viselkedik, mint a megbízható dedikált jelgenerátor.Láttál már ilyen jelgenerátorokat? [link] [link]
Ezek azért léteznek, hogy egy megbízható alapot adjanak, amivel ki lehet zárni a hibákat, mint a hülyén működő forráseszköz, mert mikor legelőször leülsz egy újonan összerakott gép elé, először el kell kezdened valahol sakkozgatni, hogy a monitor nem színhelyes semmiképp beállítva, vagy a forráseszköz van rosszul konfigurálva.A saját story-m, amiből indult a vita, ott is csak meg kéne vennie a colorist-nak a edikált DeckLink eGPU-t, amit egyébként is javasol a BlackMagic, és kész.
Az a baj, hogy a GUI monitora is hiába hardware-kalibrálható, az is YCC-t kap, és még rosszabul kezeli a Dell monitor az YCC-t, mint az LG TV. Na azt már nem lehet a DeckLink-ből etetni. Már eGPU-ról igen, de az már megint egy új ThunderBolt eszköz lenne, és nyilván nem akarunk annyira elszállni. Ezért kéne egyszerűen rávenni az M1 iGPU-t, hogy küldjön ki RGB-t, és akkor a két hardware-kalibrált kijelző --- amit egy ismert, jó forráseszközzel kalibráltam és azzal ellenőriztem is --- máris jól működne.Ez egy konfigurációs hiba, az orvoslása a kalibráció része, de nem konkrétan egy ICC/ICM, vagy akár egy 3DLUT feladata, hanem OS konfigurálás. Ez vagy a 0. pont a műászeres kalibrálás előtt, vagy a legutolsó, ha előbb ismert forráseszközzel kalibráltál, visszakötötted a Mac-re, és ámultál, hogy "de sz@r". De ez csak azt jelenti, hogy hegeszteni kell a MacOS-t, esetleg venni egy eGPU-t, stb.
Ha egy autóban szarul fog a fék padlóig nyomva, akkor nem egy másik fékpedált akarsz berakni mellé, hogy ha mindkettőt padlóig nyomod, akkor megáll az autó.
Így már érthető valamennyire?
-
válasz
janos666
#5457
üzenetére
A nem-lineáris, 3D-s dource hibákat csak sokzer patch lemérésvel lehet kompenzálni, de az akkor sem optimális megoldás, mert precizitásvesztéssel jár.
Ezerszer egyszerűbb és jobb kierőltetni a forrásból a bitperfect Full-RGB kimentet. (Még akkor is, ha ehhez eGPU kell. Minden más psedu-science hókuszpókusz, ACIDtrip.)
[Drops MIC.]
Ha szeretnétek ezt megvitatni, gyertek el ide: [link] -
válasz
general
#5455
üzenetére
TI biztos, az intelligens Neadrathall pedig max ELLENŐRIZ. [Mikrofont eldob. PEICE.]
Minden OS update után veszel egy új spektrométert és colorimeter-t, mert nincs új driver?
Minden monitor ki/bekapcsolás után újrakalibrálsz?
Gondoljuk már végig, hogy elvileg minden a problámákat a gyökerüknél kell kezelni.
Tehát pl. áterőltetni a MACOS-t és az Mx chip GPU-t Full-RGB-re, és kész.
A kalibrációs LUT nem arra való, hogy kijavítsuk a host hibáit, hanem arról szól a kalibráció, hogy kijavítsuk a hibákat, mindenütt és mindenhol.
Ennek része pl. "hack-elni" a MacOS-t, vagy venni DeckLink kimenetet a MacBOOK-hoz, amiből kimegy a bitperfect Full-RGB, és kész. -
válasz
karoli9
#5452
üzenetére
Elvileg teljesen mindegy bármi, mert minden eszközből ugyan annak a képnek kellene kijönnie. Bár én magam is panaszkodtam, hogy nem tudom hogy állítsam át a MacOS-t, hogy HDMI-n ne YCC-t küldjön ki, hanem RGB-t, mert egyik kijelző sem szereti az YCC-t.
De amíg mindkét gépből RGB-Full megy ki, addig nyugodtan újrahasznosítható az ICC.
Még annyi, hogy a MacOS csak egy bizonyos ICC verziót kezel jól, így visszafelé nem biztos, hogy működne a dolog, de ami jó a MacOS-nek, az jó a Windows-nak is. -
Az egyik egy LG C3 TV, amin csak HDMI 2.1 bemenet van (elvileg a notin is 2.1-es a HDMI kimenet, mégsem enged neki 120Hz-et választani a MacOS, csak 24-60 Hz-et).
A másik egy Dell monitor, amire szerintem pusztán azért megy HDMI, mert épp az van a Type-C HUB-on, ami már ott volt, mikor új kijelzőket vett.
De mIndkettőre RGB-Full kéne menjen (és hosszabb távon néha talán jó lenne kihasználni a HDMI 2.1 sávszélt is, mikor nem munkára használja a TV-t --- ami jellemzően 2160p25 --- bár engem az már nem érint, csak egy érv a HDMI port mellett).
A TV max úgy mehetne DP-ről, ha két DP port lenne egy HUB-on, és passzív adapterrel DP->HDMI Alt-Mode menne az egyik DP port. De Windows-on az ugyan úgy viselkedik, mint a natív HDMI, és mindkét kijelző 4k(60+)10bit.
Szóval inkább HDMI-re kéne valami rendszerszintű megoldás, akár parancssorból. -
MacOS-nél még az lehet a gond, ha RGB-Full helyett YCC(-Limited) megy ki, mert azt sok kijelző bár fogadja, de nem szereti.
Erre én is keresek most épp valami jó megoldást, mert van egy fél-profi kliensem, akinél kalibráltam, nyilván RGB-Full módban, mint mindenkinek (a saját notimat használva), és most Apple-kerülő révén nem tudom hogy segítsek neki átrakni RGB-be a kimenetet az M1 chip-es gépén, én is csak Google-ről küldök neki linkekeket.
Persze nála megoldás lenne az is, ha megvenné a DeckLink monitorozó hardware-t a Davinchi-hez, nem CleanFeed-et tolna ki az M1 GPU-ból (az is OK, amíg jó, csak épp itt ugye nem az, mert a MacOS erőlteti az RGB->YCC konverziót, és egyik kijelző sem úgy néz ki, ahogy kéne, mert mind RGB bemenetre van optimalizálva... az oda-vissza RGB->YCC->RGB konverzió nem veszteségmented és bug-prone).
Tud esetleg ebben valaki segíteni? Van rá valami tuti általános megoldás? -
Próbálj kalibrálni konkrét célértékekre (D65, gamma 2.2 relative, out offset 100%) és ezt a testchartot használni az 1c+m profilozáshoz: minimal.ti3
-
#5431
janos666
nagyúr
Hieronymus
#5430
válasz
Hieronymus
#5430
üzenetére
Ja hát igen, a legtöbb laposban elég vacak LCD van és nincs semmi batch-kalibrált gyári képmód se, csak amit még az eredeti kijelzőgyártó "beleéet" a vezérlőbe.
De az ArgylCMS + DisplayCAL sokkal jobban kezeli ezt a kütyüt is (mint mindent, amit támogat). Ez pl. kiiktatja az olyan gondokat is, ha a skála egyik/másik végén van egy "luk" (összemosódnak az árnyalatok egyformába). Erre a Spyder is jó, a jobb műszer elsősorban a pontosabb fehéregyensúlyhoz kell, a szaturált színeken kevésbé veszed észre a pontatlanságát. -
#5429
janos666
nagyúr
Hieronymus
#5428
válasz
Hieronymus
#5428
üzenetére
Más szoftver kell hozzá, pl. HCFR, de ez amúgy egy elég buta és pontatlan műszer.
-
válasz
umfrider
#5425
üzenetére
1440i, mint Interlaced? Az valami hatalmas hülyeség, a kijelző biztos tud 1440p75-öt (progressive). Ha HDMI-n nem engedi ezt beállítani a videókártyád (RGB-vel, nem YCC-vel, és valószínáleg még 10bit-et is fogadnia kéne, nem csak 8-at), akkor vegyél egy DisplayPort <> Type-C kábelt, és kösd be azzal (ha van szabad DP port a gépen, vagy ha nincs, próbáld meg 3.2-es Type-C <-> Type-C kábellel).
Az ICC-t elvileg elég telepíteni, és hozzárendelni a kijelződhöz Windows-ban. Gyakorlatilag jobb külön szoftver használni, ha nem statikus a rendszer (pl. ki/be húzgálod/kapcsolgatod a monitorokat, pl. laptop esetén).
A videókártyának minimális jelentősége van (csak a ditherelés változik, de azon rugózni olyasmi, mint ha egy 20 méteres acélrúd 1 mm-el rövedebb, mikor átveszed, mert picit más a hőmérséklet vágáskor és ellenőrzéskor). Mondjuk én általában és is úgy szeretek kalibrálni, hogy átmenetileleg letiltom a ditherelést, de az már csak OCD/maximalizmus. Sokkal több múlik a kijelző és műszer, illetve szoftver képességein, a ditherelés ezek mellett eltörpül.
A felbontásoknak sincs különösebb jelentősége.
-
válasz
Goblin12
#5421
üzenetére
Az alapján, amit a tesztek mutatnak róla, otthoni célokra és/vagy buta (vagy bután haszált) szoftverekkel kár is piszkálni azon túl, hogy SDR és HDR módban is a gyárilag legpontosabb módba állítod.
Ha kicsit visszaolvasol, kiderül, hogy HDR-t még nem is nagyon lehet szoftveresen kalibrálni Windows-on (Linux-on pedig kb. eleve nem nagyon van HDR dekstop).Esetleg annyit érhet meg csinálni, ha van egy jó műszered, hogy a CIE 1931 helyett az új "ArgyllCMS OLED CMF"-el állítod be a fehéregyensúlyt. Ennek az alapjait a Samsung pénzelte (leültettek ~10 embert W-OLED, QD-OLED, RGB-OLED és még pár más új generációs kijelző elé, és állítgatniuk kellett, míg szemre egyeztek a színek, aztán Gremme, az ArgyllCMS fejlesztője csinált az általuk publikált adatokból egy új CMF-t, amit közvetlenül a régi CIE 1931-ben definiált koordinátákkal lehet etetni, ami egyedi és praktikkus megoldás, mert a legtöbb CIE 1931 utáni alternatív CMF-el az a gond, hogy más és más koordináták jönnek ki bennük D65 fehérre, a Rec709, Rec2020 R,G,B koordinátákat pedig nem is lehet olyan egyszerűen átszámolni, mert azokat úgymond önkényesen/hasraütésszerűen definiálták CIE 1931-ben, nem úgy, mint a D65-öt, ami a napfény spektrális méréseiben van eredetileg definiálva, így bármilyen CMF-hez kiszámolhatók hozzá az x,y koordináták).
-
Csak annyi értelme van, hogy $$$, semmi más. Ilyen előfizetős modellben is az lenne "tisztességes", ha hibajavításokat kapnál még évekig ingyen, csak az új funkciókhoz nem férnél hozzá. Tehát pl. a 2019-ben vásárolt Home frissülne, és ha azóta javult a kalibrálás minősége, akkor a 2019-est szebben húzná be, csak épp a 2020-as TV-t már egyáltalán nem lenne hajlandó kalibrálni. De nem, ha volt valami geb@sz a szoftverrel, mikor megvetted, és nem méltóztattak 12 hónapon belül ovsolni, akkor is vedd meg újra, ha kell a hibajavítás/minőségjavítás. Ugyan így, ha pl. 3 éven át nem volt képes hozni, amit vártál tőle, de hallod hírből, hogy most már jó, akkor is fizesd csak ki a köztes éveket (bár lehet, hogy adnak ilyenkor valami kedvezményt a köztes évekre, illetve igen, gondolom nagy kegyesen megengedik, hogy megvedd újra, ha a szumma több lenne, mint egy friss alap license, és talán van refund, ha rögtön vásárlás után meg X ideig azt mondod, hogy "bocs, de nem működik minden eszközön úgy, mint vártam, de pl. Studio/Ultimate license-nél simán lehet, hogy a 11. hónapban derül ki, hogy X eszközön nem jó...).
-
Minden CalMAN verzió csak éves előfizetés, az ő megfogalmazásuk szerint az első éves díj ajándék az alap license mellé (ajándék, nem benne van az árban!). Viszont a Home-tól magasabb license-ek esetén már olcsóbb az éves hosszabbíztás, mint az első vásárlás (ugyanakkor meg kell venni a kimaradt éveket is, ha később hosszabítanál).
De amit ír, az alapvetően inkább monitor, mint TV, hiába "smart" és Tizen OS fut rajta Tudtommal nincs CalMAN integráció. Ezt PC monitorként lehet kalibrálni.
-
Most vettem észre, hogy a Microsoft saját képnézegetője is hülyeséget csinál, ha a Store-os HDR profil be van töltve. A sima sRGB képeket nagyon kéken nyitja meg. Ugyan így, ha a készítek egy screenshot-ot egy HDR játékról, és PhotoShop-ban hozzárendelem azt a HDR profilt, amit a Store-os kalibráció gyárt, akkor SDR-ban rózsaszín lesz absolute intent módban (tehát augyan úgy reagál, csak az ellenkező irányba, ami alapvetően rendben is lenne, ha egyzser input, egyszer output profil, csak épp mindkét esetben rossz az eredmény...).
A PS nem meglepő, mert a Mirosoft egy speciális profilt használ az OS HDR-hoz, amit nagyon kevés szoftver támoagt (nyilvános, consumer szoftver szerintem még egy sem). De az már kicsit fura, hogy a Win11 23H2 saját "Windows Photo Viewer"-e sem boldogul vele.
Nem tudom, hogy milyen szoftverrel készülnek a monitor gyártók által kiadott ICM file-ok, amik kompatibilisek a Win11 OS HDR-al (léteznek ilyenek). Valószínűleg, mivel azok csak "névleges" / szintetikus profilok (nem egyedi mérésekből állítják őket elő, hanem a hardware specifikációk alapján), így valami Microsoft által adott editorral, vagy valami Microsoft SDK-val készült belső, egyedi szoftverrel. -
Mennyit tud a kijelződ a gyakorlatban? Mert elvileg azt kéne megadni akárhogy születik a profil.
Ha magasabbat adsz meg, akkor lehet, hogy magasabb értéket küld ki a Windows, mint metadata (szerintem jelenleg nem csinálja ezt a Windows, még sohasem néztem meg HDFury dobozzal, hogy ilyenkor mit művel a Win11 >=22H2), és ha nincs letiltva a roll-off (alapértelmezetten ez sokszor be van kapcsolva), akkor ez sötétebb képet eredményez.OLED-en nagyon egyszerű lefuttatni a Windows saját profil generátorát, mert a fekete az tényleg fekete, így csak le kell húzni a csúszkát nullára, és kész. LCD-vel még sohasem próbáltam.
De LCD-n pont nem is dob sokat az Auto-HDR, mert az LCD-nek szar a natív dinamikatartománya. Csak szaturációban tud érdemben többet produkálni az LCD HDR módban SDR-hoz képest, de azt szerintem nem nagyon próbálja fentebb tolni az Auto-HDR.Illetve az Auto-HDR csak egy post-processing. Lényegében csak tippelget, hogy nézett volna ki a kép HDR-ben. Attól elvileg jobbat ki tudsz hozni a képből a "SpecialK"-vel (ezzel magasabb bitmélységre lehet erőltetni a játák által használt buffereket és tweak-elhető a tone mapping, akár szaturáció boost, stb), bár nekem az sem volt meggyőző, mikor tesztelgettem, illetve pont azokkal a játékokkal nem akart működni, amikkel szerettem volna (van játék, amivel úgy kapásból eleve nem működik jól a SpecialK, HDR hack ide vagy oda).
AutoHDR-ra visszatérve, lehet hogy akkor sem húzná ~250 a jelenet csúcsát, ha 10000 nit képes csodamonitorod lenne. A HDR filmekben is sokszor ilyen ~350 a valódi csúcsfény olyankor is, ha 1000 nit a névleges csúcs (van szoftver, ami úg elemzi a képet, hogy talál egyetlen pixelt 1000 nit-el, máris az a metadata csúcs).
Mivel elemzed, hogy meddig megy el az AutoHDR? Screenshot, profile tagging és képszerkesztő picker?
-
A filmeket pedig rec1886 vagy rec709-en masterelik
A Rec709 görbét senki sem használja (igazából nincs is: ugyan van egy encode görbe a doksiban, de nem írják, hogy annak az inverzét használd decode görbének, és ha mégis kipróbálod az inverzét, mint decode, akkor egyértelmű lesz, hogy nem lesz jó), gamma 2.4 (esetleg 2.2) vagy újabban Rec1886 görbével kombinálják. Előbbiből kerülnek ki az R,G,B,W koordináták, utóbbiból a TRC görbe.
Én személy szerint inkább preferálom azt, hogy vesszen el egy kis információ a sötét tartományban, mint hogy fel legyen húzva, mert az agyontömörített és/vagy régi analógból scan-elt filmek/videók abban a tartományban általában eléggé blokkosak/zajosak, tehát tulajdonképp sokszor csak a zajt aplifikálod.
Itt van egy eltúlzott példa (1:10 kontraszt), amin jól látszik, hogy meredeken emelkedik ki.
Én személy szerint örülök, hogy már PDP-ken sem kellett ezzel foglalkoznom itthon, és most már a hazai colorist-ok is, akikkel van dolgom valamilyen OLED-et használnak, szóval már el is felejthettem, hogy van/volt ez a Rec1886 kérdés.
-
Ezt leírtam lentebb, szinte mindenki a 2.2 vagy esetleg 2.4 relatív gammát használja (a kijelzőgyártók is a gyári preset-ekhez, és a legtöbb kalibráló szoftver is).
A Rec1886 direkt LCD-khez alkalmaz korrekciót, OLED-en pontosan gamma 2.4-et ad (de még a drága fizetős szoftverek is sima relatív gammát állítanak alapértelmezésképp, és nem is minden szoftvertől tudsz kérni igazi Rec1886-ot az LCD korrekcióval együtt). -
Legjobb tudomásom szerint nem volt igazán szabványosítva SDR fényerő Rec709/sRGB-hez. Sőt, igazából a gamma se nagyon.
A 120n és g2.2 régen is "irodai fényviszonyokhoz" volt, és maradt is javasolt.
Én régen 80-at javasoltam sötét szobába gamma 2.4-el nagy kontrasztú kijelzőkre (ami akkoriban a PDP-t, avagy plazmát jelentette).
Később jött a Rec1886, ami azt mondta, hogy legyen 2.4 a gamma, viszont egy korrekcióval kontraszt függvényében (az LCD-k miatt).
PDP-n elhanyagolható volt ez a korrekció, LCD-n viszont szerencsétlen módon pont a másik irányba tolta a Rec1886 a sötét árnyalatokat, mint ahogy a gyártók és elterjedt monitor kalibráló szoftverek szokása volt előtte hosszú éveken át. Amiket ma LCD-ken találsz Rec1886 az is általában nem Rec1886, hanem a szokásos/hagyományos gamma kezelés, csak nem 2.2, hanem 2.4 exponensel.
Aztán jött a HDR, amiben már egyértelműen definiálták azt, hogy 100 a "paper white", illetve hogy ez lesz a 100%, mikor HDR-ből SDR-ba konvertálsz. Ezzel kvázi visszamenőlegesen szabványosítva lett az SDR-hoz a 100.
SDR-hoz maradt az, hogy sötétben gamma 2.4, világosban gamma 2.2 (és +20 cd/m).
HDR-ben az volt az ötlet, hogy abszolút kell kezelni a fényerőt, így erre nincs annyira elterjedt gamma korrekció (de kontrollált környezetben, mint pl. egy stúdió, meg lehet tenni, hogy egy úgymond "gamma 2.4 PQ"-t használsz, ha feltehetően világos szobában nézik majd a tartalmat, pl. webböngészőben nappal, sötétítés nélkül, és nem sötétített szobában TV-n, illetve a TV gyártók is szoktak betenni "Home" módot, ami mondjuk úgy "gamma 2.0 PQ" szerűséget csinál a képből, bár ez inkább random).Nem használom a madVR ezen funkcióját, úgyhogy lehet, hogy így van, de akkor ez szerintem bug, nem feature. Mint ha régen ott is lett volna négyzet, amit bepipálhatsz, hogy "send HDR metadata", de nem látom. Annyi rémlik, hogy a fél-publikus beta verziókban pont a HDR post-processt csiszolgatta még madshi, de lehet, hogy már csak a pixel shader-essel foglalkozott.
Ha nagyon akarod, kereshetsz használt HDFury dobozt, ami ráteszi a jelre a metadata-t. De lehet, hogy van már erre szoftveres megoldás is. -
Lehet madVR-al color manage-elni a HDR képet. A devices / [monitorneve] / HDR alatt lehet betallózni a Rec2020 sorba (ha ehhez készítesz 3DLUT-ot).
De profilozáshoz nem kell semmi LUT-ot betölteni (sőt, nem "szabad", hacsak nem valami kacifántos dolgot csinálsz).A HDR tartalom valószínűleg még akkor is szebb lesz érzésre HDR módban, ha számszerűleg pontatlanabb ez a mód, mint az SDR (kivéve, ha olcsó WRGB kijelző, mert ott a W alpixel deszaturálhatja a sötét színeket is).
-
Nem tudom, hogy honnan jött a 200, mert a szabvány "paper white" 100 (ez a peak white is, mikor HDR-ből visszakonvertálsz SDR-ba, tehát úgymond 100 felett kezdődik "a HDR extra infó"). A monitorokra érvényes VESA szabványok pedig emlékeim szerint 300-ról indulnak (legalább 300-at kell tudnia egy monitornak csúcsfényben, hogy HDR-nek nevezhessék). A szabvány 10'000-ig megy, tehát gyakorlatban limitálni sohasem kell azt, amire a monitor képes (= told nyugodtan csutkára, esélytelen elérni a 10'000-ret).
De igen, röviden feltolod maxra, beállítod D65-re, aztán profilozod és 3DLUT-ot készítesz a mért csúcs fehérrel, mint target.
-
Papírforma szerint 100 cd/m^2 a "paper white" (a filmesek SDR-ra is ezt szokták beállítani 100% fehér fényerőnek), de HDR10/DV kalibrálásnál nem ezígy most számít.
Maga a kijelzőpanel általában gamma 2.2-ben marad, és a belső processzora (valós időben matekkal és/vagy vagy LUT-al) konvertál PQ-ból gamma 2.2-be (és Rec2020-ból natív gamut-ba).
Ha nem tudod programozni a belső processzort (LUT-o[ka]t feltölteni és/vagy peak white fényerőt megadni numerikusan magába a kijelzőbe), akkor egyszerűen hagyd a háttérvilágítást és digitális kontrasztot maximumon, mérd le, készíts ICM profilt, aztán abból készíts a madVR-hoz 3DLUT-ot úgy, hogy a target peak-nek beírod azt, amit profilozáskor mértél. Illetve ha nem állítottad / tudod beállítani a fehérpontot D65-re, akkor kell egy extra iterációs lépcső: ismét visszaméred, hogy Absolute Render Intent 3DLUT aktiválása után mi lett a 100% peak white fényerő (csökken, ha számottevően korrigálja a fehéret a 3DLUT), és visszaírod a DisplayCAL-be, mint target peak, frissíted a 3DLUT-ot, és futtatsz egy ellenőrzést, ha szeretnél. -
#5381
janos666
nagyúr
Albert.Tamas
#5380
válasz
Albert.Tamas
#5380
üzenetére
Nam, DisplayCAL, olvass vissza. (Vagy drága fizetős programok, ha komoly dologra kell.)
-
EIZO VG-ker már 10 éve is volt ilyen. Egy ideje külső spektróval is lehet kalibrálni ezt a beépített colorimeter-t. De alapvetően elvileg nem kéne, mert a gyárban egy méregdrága labor minőségű spektróval kalibrálhatják elő, így ha nem kopnak el a beépített colometer szűrők, akkor elvileg jobb is, mint ha csak egy olcsóbb külső eszközt eresztesz rá.
-
válasz
Teasüti
#5270
üzenetére
Alapvetően ugyan annyi kontrasztot kapsz akkor is, ha neutrális állapotban (50-50-50, 100% 100% 100%, stb) hagyod az R, G, B csatornánkénti kontrasztot a monitor OSD-jében, mint ha ott állítod be a 100% fehér pontot, csak egyszer a monitor processzora vágja meg, máskor a VGA LUT.
-
válasz
Teasüti
#5246
üzenetére
Tömörre fogva a kérdést: Van bármi egzakt bizonyítékod arra, hogy akár a consumer (Radedon/Geforce) és/vagy profession grade (Quadro/RadeonPro) VGA kártyákból nem bit-perfect kép jön ki (a megfelelő driver control panel beállítások mellett, ahol letiltasz mindenféle post-process effect-et, ami esetleg aktiválva van alapból)? Az esetleges ditherelést most hanyagoljuk el, mert azt nem hiba, csak "szükséges/kisebb rossz"
Szabványos digitális kimenetek esetén (DVI, HDMI, DP, stb., de akár HD-SDI) elméletileg nem kéne, hogy bármi különbség legyen a kimenetet biztosító hardware-ek közt (legyen az két különböző generációs AMD, vagy nVidia, akár e kétféle gyártmány egymás mellett; vagy olyasmi, mint a BlackMagic DeckLink kártyák), ha mind "neutrális" kimenetre van konfigurálva (ami általában az alapbeállítás mindegyiknél).
Sokan állítják, hogy az nV és AMD kártyákból sem referencia jel jön ki (legalább is nem Windows driverrel és Windows asztalkezelővel). Ugyanakkor én erről még sohasem láttam konkrét egzakt mérést, és nehéz elképzelnem a dolgot, mivel nagyon sok nyersanyag készül úgy, hogy ilyen (AMD/nV) VGA-k kimenetein nézik a készítők a félkész, majd végül publikált munkájukat (talán már a vágónál, de a fényelőnél valószínűleg van egy DeckLink szerű kártya [dedikált HDMI és/vagy HD-SDI port(ok) egy külön PCI-e kártyán, amikről külön garantálja a gyártó, hogy "bit-perfect" a kimenő jel - legalább is addig, míg a gyártó saját driverét/szoftverét használod], vagy hasonló, de aki még a nyers CGI részt készíti egy filmhez, az inkább DisplayPort-on [vagy HDMI-n] köt be egy sima PC monitort (nem ~10M HUF-os professional monitort, csak 'valami "már épp használható" ~0.2M HUF monitort -> ami kb. egy nagyságrenddel olcsóbb...). Innentől pedig már nem fog olyan sokat belenyúlni a későbbi művész abba, amit a korábbi munkatársa odapakolt (csak "beleilleszti a környezetbe", de nem építi újra...).Szó, mi szó... Szerintem minden kijelzőt egy elméletben referencia képkimenettel kéne kalibrálni (most mindegy, hogy mire bökünk rá, mi nekünk az igazi referencia - 'csak egyetlen igazán pontos óra van az egész Földön'), nem valamilyen véletlenszerűen kiválasztott valamihez. Tehát ha úgy gondolod, hogy a te VGA-d torzít az elméleti referenciához képest, akkor azzal nem is szabad kalibrálni (másik oldalról: 'Mi van, ha hamarabb cseréled le a VGA-d, mint a kijelződet, vagy fordítva?, Akkor úrjra-kaliblálod?'). A kijelzőt lehetőég szerint egy "etalonhoz" kéne beállítani: meg kell próbálni gondoskodni arról, hogy a monitor és a VGA is minél közelebb legyen egy etalonhoz (ami bit-perfect bemenetet és az abszolút referenciához legközelebb komparált mérőműszer legpontosabb alkalmazását jelenti).
Tehát szó, mi szó, nekem fel áll a hátamon a szőr ettől, hogy XY megjelenítő eszközhöz kalibráljuk a ZW bemeneti/forrásseszközhöz". (Főleg akkor sem, ha egyik eszközről sincs okunk azt hinni, hogy az egy kvázi-etalon).
-
válasz
jozsi252
#5209
üzenetére
Úgy néz ki, hogy egy DataColor eszközzel, és annak gyári szoftverével kalibrálták.
Kritikus munkára nem használnám, de hobbi munkára már elég lehet.
Viszont így, hogy natív színtérben van a kijelző, csak olyankor lesznek helyesek a színek, ha valami olyan programot futtatsz, ami beolvassa és használja az ICC profilt, amit a program készített (képszerkesztő, és bizonyos képnézegető programok, pár videólejátszó és webböngésző, ha külön beállítod, de pl. játékok alatt már nem). -
válasz
kuyarashi
#5201
üzenetére
"Természetesen spektroval össze kellene kalibrálni a monitort a nyomtatóval."
Nem egymáshoz kell őket kalibrálni, hanem külön-külön a monitort (spektróval, vagy spektróval profilozott colorimeter-el) és a nyomtatót is (adott papír és festék pároshoz spektróval).
Arra vigyázz, hogy nyomtatáskor ne legyen duplán kivetve a profilból származó korrekció, tehát pl. PhotoShop esetén vagy a PhotoShop intézze a színkezelést, és a nyomtató driver-ben legyen letiltva, vagy fordítva.
És igen, ideális esetben CMYK alapú profilt kéne kreálni és CMYK módban nyomtatni, de ezt csak a PostScript-et támogató nyomtatókkal tudod megcsinálni, hagyományos nyomtatókkal csak RGB-t tudsz a nyomtatóra küldeni. -
válasz
kuyarashi
#5199
üzenetére
A papírhoz (és a hozzá tartozó tintához) van mentve ICC profil? Akkor a forrásanyag lehet szinte bármi, mert a CMS megoldja, hogy mindent láss, amit a papír elbír azon belül, amiben a dokumentumot mentetted (akkor is ha szaturáltabb, akkor is, ha inkább kevésbé szaturált az, amit a nyomtató tud produkálni). Persze néha jöhet ki fura eredmény (azokon a területeken, ahol nem igzán passzol a source és target gamut).
-
válasz
robi1979
#5193
üzenetére
Van egy validation tab a pfrofiling mellett. Ott szedd ki a pipát a szimulációk mellől (ha bent vagy), és futass első körben egy alapértelmezett "extended" chart-ot, mint visszamérs.
A műszer abszolút pontoságáról ez persze semmit sem mond el, csak arról, hogy becsúcsott-e valami hiba a workflow-ba, illetve hogy a műszer saját véletlenszerű szórása kb. mekkora lehet (mennyire mér közel kétszer ugyan ugyan az a műszer ugyan azon a patch-en).
Szóvsl ez inkább csak egy ilyen "sanity check". -
válasz
robi1979
#5191
üzenetére
Nézz meg egy profile validation report-ot, az többet elárul, mint a profil információk, bár az is csak a műszerered mérési pontosságán belül lesz érvényes (hacsak nem használsz külön műszert a kalibrálásra és a validálásra), szóval inkább csak azt árulja el, hogy minden úgy futott-e le, ahogy kellett neki, nem csúszott be véletlenszerű mérési hiba, vagy software bug, stb...
-
#5173
janos666
nagyúr
rhunseeker
#5172
válasz
rhunseeker
#5172
üzenetére
Az Oázisban tényleg megint ezzel a szoftverrel kalibrálnak?
-
Azt lenne érdemes megnézned, hogy milyen dE értékek vannak az R,G,B szaturált patch-eken, ha a gyári sRGB profil van betöltve és be van lőve a driver clamp. Abból derülne ki, hogy mennyire pontos a clamp. Aztán ugyan ez a gyári sRGB móddal, és akkor látnád, hogy melyik végez jobb munkát.
-
Előfordul olyan, hogy az alapértelmezett kontraszt picit túl magas.
Ezt egy gradiens tesztábrával tudod ellenőrizni, hogy úgymond "leszakad-e" a 100% fehér árnyalat a mellette levő világos szürkék sorából. Ilyenkor indokolt visszavenni a kontrasztból, amit megtehetsz vagy a központi Kontraszt csúszkával, vagy a színcsatornánkénti kontrasztokkal is (ezek az RGB csúszkáid). Ha mindhárom (RGB) csúszkát lentebb viszed együtt, az ugyan olyan, mint ha a Kontraszt-ot vinnéd lentebb (nem feltétlenül ugyan annyival).És két különböző 1dd3 műszer sem fogja pontosan ugyan azt mondani.
-
-
Az i1Pro2-est használd, az készült helyesen a natív gamut módban, a ColorMunki-s sRGB módban készült, ami nem ideális.
A Refresh mód miatt ne aggódj. Igen, azt az i1Pro2 tulaj szúrta el, de nyugodtan maradhat a beállítás Refresh-en, sample-and-hold kijelzőn az is jól fog működni (visszafelé ez már nem lenne igaz).
-
Én X-Rite műszert ajánlanék és DisplayCAL szoftvert. Vagy hívj valakit házhoz, akinek spektrophotometer-e is van, nem csak colorimeter-e, mert akkor pontosabb is lesz.
Szerintem tedd be sRGB preset-be, és onnan bízd rá a szoftverre a LUT-os fehéregyensúlyt.
Mi tud 12 profilt eltárolni?
-
-
Érdemes úgy kalibrálni, ahogy használni fogod. Valószínűleg úgy kalibrálnák, ahogy automatikusan beállítja magát a driver, vagy ahogy kéred.
A gyári profilról ki kéne deríteni, hogy melyik gyári képmódhoz való. Valószínűleg a Standard-hoz, ami valószínűleg wide gamut, tehát a color management-es szoftvereken kívül pontatlanabban lennén a színek, mint a profil nélkül sRG módban (ahol a monitor kezeli a gamut-ot szoftverek nélkül).
Az az ICM kalibrálás nélkül, csak profilozással készült. Tehát csak a color management-es szoftverek tudják haszosítani.
Ha sRGB módban kalibrálod, akkor az 1DLUT (ami mindig rajta lesz a képen, nem csak color management-es szoftverekben) helyre teszi a fehéregyensúlyt (amit az RGB csúszkák csinálnak) és a gammát.
Nem ismerem a programot, hogy mit csinál. De ehhez ismerni kell a natív színteret, hogy map-elhess natív és sRGB közt. Nem elég ismerni az sRGB-t, a monitor színterét is ismerni kell valahonnan, hogy a kettő közé mátrix-ot számolj, amit aztán rápakolhatsz a képre. Ez a program talán az EDID-ből olvassa ki a gyártói paramétereket, ami valószínűleg a Standard képmód tág színtere.
Ezért mondtam, hogy használd sRGB-ben. De próbáld azt a szoftvert Standard-el.
-
Ha monitornak szeretnéd használni, akkor használd az sRGB módot.
A Kontaszt-ot általában nem kell bántani. A fényerőt a fényerő csúszkával kell belőni.
A szemre kalibrálás is működhet valamennyire az RGB csúszkákkal, de miért nem kalibráltatod műszeresen?
Monitorhoz használj mindig RGB-t (az új TV-khez is), és ne aggódj a 10/8 bit miatt, nem valószínű, hogy elmászna bármi. Amúgy is valószínűleg mindig 8 bites képet nézel, csak 10 bit-et küld ki a VGA. Bár a Hz váltáskor a kijezőpanelben kapcsol ki az FRC, így a belső képfeldolgozás 10+ bit eredményét is csak 8 bit-el jeleníti meg, ezért igen, kicsit "sávosabb" lehet a gradiens tesztábra (és ezzel együtt ici-picit elmászhat a szín is, de ezt ne aggódd túl). -
válasz
Dagidög
#5128
üzenetére
HDR-nél 100 cd/m^2 a paper white, vagyis kb. annyira lesz világos egy szabványosan fényelt HDR anyag átlagos jelenetének legnagyobb része, mint ha 100-ra lenne kalibrálva az SDR. De a csúcsfények fel fognak menni akár 1000 fölé (attól függ, hogy milyen TV-t veszel), amik nyilván "vakítóak", ha belenézel, de ezek általában nem a képernyő közepén szoktak lenni. Összességében szerintem jó élmény HDR-ben filmet/sorozatot nézni. Szerintem jobb, mint SDR-ban. Én személy szerint az OLED-et preferálom (LG, Pana, Sony, mind jók).
-
válasz
Dagidög
#5126
üzenetére
Van a menüjében CMS (színkezelés), és azokat a csúszkákat is használtad?
TV-k közt van olyan, ami egyszerűen semmilyen beállítással nem lesz színhelyes. Olyan is, amin hibásan működnek a kalibrálási opciók (ha megmozgatod a csúszkákat a menüben, akkor úgymond "összeomlik" az egész színkezelés,) és rosszabb lesz beállítva mint, ha nem lenne kalibrálva (az összes színre nézve, nem csak azokra, amiket közvetlenül állítgatsz). -
válasz
Dagidög
#5103
üzenetére
Milyen TV? Az LG WOLED-eket (és valószínűleg a Samsung QLED-eket is, de olyat szerencsére nem nagyon szoktak venni monitornak olyanok, akik érzékenyek a színhelyességre) alternatív WP-re kell kalibrálni, ha azt akarod, hogy jobban hasonlítson a standard sRGB gamut-os LCD-kéhez a fehér. Standard D65-re kalibrálva mindig melegebb lesz a WOLED fehér, mint a WLCD fehér. (A wide gamut LCD-nél ez szintén így van, a WG foszforos háttérvilágításúak zöldek szoktak lenni a WLED LCD-khez képest.)
-
A PC VGA GPU-jának 1DLUT-ját fogod programozni, a többi nem érdekes.
Vagyis akkor működik ez, ha külön HDMI portokon megy ki a kép a két kijelzőpanelre. Ha stereo 3D formátum megy ki egyetlen HDMI-n, akkor ez így nem fog működni (akkor mindkét panel ugyan azt az offset-et kapná).
Vegyél / bérelj /rendelj ki valakit legalább egy i1Display3-al (i1d3). -
Alapvetően épp erre való a kalibrálás (hogy minden random kijelzőt ugyan ahhoz a standard-hez próbálj igazítani), és a szürkeskálát viszonylag egyszerű rendbe tenni 1DLUT-al, amit rá tud tennni a GPU a HDMI kimenetre (ha a szaturáció is más lenne, ahhoz 3DLUT kéne, amit csak erre felkészített szoftver kezel, vagy esetleg a kettő közé kötött "LUT box", a GPU direktben nem).
Valószínűleg az lenne praktikusan célravezető, ha szétszerelve kalibrálnád be úgy a kijelző paneleket, mint sík képernyők, majd visszahelyeznék őket a sisakba (a színeken szerintem torzít annyit a lencse, hogy gond legyen, illetve ha az fontosabb, hogy egyformák legyenek a kijelzők, akkor is egyformán fogja őket színezni a lencse [ha színezi], tehát egymáshoz leszenek igazítva).
-
Csak annyit toldanék még hozzá a korábbi hsz-emhez, mielőtt félreérthető leszek:
A monitorodat azt persze abszolút módban kell korrigálni 3DLUT-al (hardware-be töltve, ha tudja, vagy szoftverből, ha csak úgy megy). Különben nem lesz jó, amit szemre behúzgálsz...
(Ha érdekel, én elég sokat pepecselgettem már monitorokkal egy colorist-nak is.) -
Lehet, csak rendszeresen használnod kell a ColorChecker-t és többször generálnod 3DLUT-ot.
De amúgy, lehet hogy kielégítő eredményt kapsz, ha csak nyári, dél környéki napfényre lövöd be egyszer, abszolút helyett relatív módban készíted a link profilt, aztán hagyod egyetlen 3DLUT-al, és utána hagyományosan szemre állítod ezen felül a fehéregyensúlyt a jelenet világításának és a megálmodott képélménynek megfelelően. Mert ugye utóbbi sem mindegy, attól függ mit csinálsz... Ha pl. dokumentumfilmet (teszem azt múzeumokban festményekről, vagy szabadban állatokról), akkor talán szeretnél abszolútban dolgozni, de ha játékfilmet (tegyük fel valami sci-fi, aminek köze nincs a valósághoz), akkor úgyis az a lényeg, hogy a végén mit szeretnél látni, nem azt, hogy mi mit láttál eredetileg a forgatáskor a szemeiddel. -
El lehet rontva a full/limiet range converzió. A lejátszó által használt renderer-ben kell beállítani. Használj MPC-HC mellé madVR-t.
Lehet. Rögzíted a ColorChecker-t, kimentesz egy képkockát a RAW képből (mindenféle processing nélkül), készítesz róla ICC profil-t (egyéni döntés, hogy matrix+gamma, vagy LUT alapút, de előbbivel próbálkoznék), aztán egy link profilt alapján (ami a camera RAW térből valamilyen szabvány cél színtérbe map-el, pl. Rec709-be, vagy abban, amiben a project fut, akár pl. ACES) egy 3DLUT-ot, amit rá tudsz húzni a képre.
De nem lesz egyszerű. Csak arra az egy szenzor+lencse+világítás együttesre lesz érvényes (bár a lencse cserélgetést szerintem még elhanyagolhatod, ha nincs rajtuk eltérő szűrő). Tehát alapvetően különböző profil kell napfényre, neoncsövekre, LED-es lámpákra, stb (főleg, ha a fehéregyensúlyt is a profillal akarod kezelni), vagyis akár minden új jelenetnél rögzíteni kell a ColorChecker-t (úgy, hogy ne legyen rajta tükröződés, egyenetlen árnyék, jól legyen exponálva, stb), és új profilokat generálni. -
-
Az az új Home, ami TV markánkként van. Nyilván elég nagy lehúzás, hisz egy átlagos családi házban is lehet akár 2-3 féle TV. De a Spectracal általában ilyen.
#4877Joshi -> Kellemes meglepetés volt számomra, de olyan Sony TV-ken is működik, amik nincsenek a listán. Csak töltsd le a Store-ból és futtasd, aztán kiderül (de az OLED-ednek szerintem rajta kéne lennie).
-
#4871
janos666
nagyúr
Stauffenberg
#4870
válasz
Stauffenberg
#4870
üzenetére
Ha neked ~20 év egy pár év... Szóval nem áll. A profil a monitoré, nem a VGA-é. (Csak ne legyen elállítva semmi egyik VGA driver-nél se.)
-
-
-
Lehetséges DisplayCAL-al, de olyan, mint villával enni a levest (már csináltam, egyedi referencia ICM file-t és validation report template-et raktam hozzá össze és mindig végigmértem, állítottam, mértem).
Egyszerűbb pl. HCFR-el (sourceforge-os újabb fork, bár azt hiszem az sem frissül már).
LG OLED-hez pedig kvázi kötelező a CalMAN (esetleg LightSpace). -
DisplayCAL-al valószínűleg működni fog, de az X-Rite szoftverrel, vagy mással, ami annak az SDK-ját használja, már nem biztos. (Azt hiszem a CalMAN kakukktojás, mert elvileg az X-Rite SDK-ra épül, de mégsem egészen a saját OEM i1d3 verziójuk miatt, ami gyorsabban mér, mint bármelyik, illetve lehet saját black/white-listája, hogy mit hajlandó működtetni.)
-
válasz
Archttila
#4776
üzenetére
Azért is szeretem, mert kiírja a végén a dE értéket WRGB színekre, és mutatja, hogy mit mért a két készülék, vagyis van benne "sanity check".
A GUI nem enged RGB-ből generálni, de lemérheted vele a ti1 file-t és a comman line tool megeszi a készült ti3 file-okat. RGB kijelzőn működik is, csak WRGB-n nem tetszik (bár ez nyilván szubjektív). -
válasz
Archttila
#4772
üzenetére
Bedobod ide a regelős linket?
Retail, nem OEM. De lényegében ugyan az.
Nem, az OLED topic-ban az LG WOLED volt, nem Samsung QLED LCD.Én DisplayCAL-an szoktam csinálni a mátrixot, egyrészt a HiRes mód miatt.
Az engedi variálni a ti1 file-ban, hogy miből dolgozzon, de úgy tűnt, hogy jobb a WRGB szett a WRGB OLED-hez. Ha csak RGB-ből gyártom, akkor RGB-n kisebb a hiba, ami WRGB-nél eloszlik, viszont fehéret mérve nagyobb. Szerintem inkább dE 0.5 több színen, mint dE 0.1 hármon és dE 1 a fehéren.Tudom, pont azután jött ki ez a CalMAN verzió, ami említi a Rev B dolgokat, miután lejárt az Access-em (és irracionálisan drága lenne fellépnem magasabb level-re, amúgy pedig EOL a régi alap kulcsom).
-
válasz
Archttila
#4769
üzenetére
Na neeeee.... Náluk vettem pár hete egy ugyan ilyet és nem kaptam HDD-t, pedig épp elromlott egy itthon. 2 dolog került ki:
1: A CalMAN 2019 nem támogatja teljesen (ugyan olyan neki, mint a régi Rev A, nincs AIO)
2: Pont ugyan azt (a hülyeséget) mérte a Samsung QLED-en HDR módban, mint a régi Rev A (amit most az aprón hirdetek), tehát nem az volt a gond, hogy ne mért volna el a régi is ~1500 nit-ig (ha garantált azon, ha nem), hanem egyszerűen fura a EU Q90 2019 HDR színkezelése. -
Ha 1903-ad van és 445-ös driver-ed, akkor passz.
Az új nevén nem 2004és 2009lesz, hanem 20H1 és 20H2 (és a H2 idén is ugyan olyan kamu frissítés lesz, mint 1903-ról a 1909, tehát igazából akármikor felteheted rá az "engedélyező csomagot", hogy átváltson H1-ről H2-re anélkül, hogy Insider-ré válna).
Ha megnyomod kézileg a keresést, szerintem felajánlja minimum a 1909-et, vagy talán már a 2004-et is. -
Hagyd frissülni a Win10-et, ameddig magától szeretne (kattints rá egyszer manuálisan is, hogy keressen frissítéseket és nyomd meg, hogy szeretnéd feltenni azt is, ami opcionális), aztán tedd fel a legújabb VGA driver-t is a gyártó weboldaláról.
Ha ez már megvolt, és 20H1-en vagy, akkor várd meg a (vélhetően) jövőheti WDDM 2.7-es GameReady driver-t (>450 series).
A 20H1 korai verzióval is volt újra valami gikszer, de nem tudom, hogy melyik oldotta meg: a CU-k, vagy az, hogy idő közben feltettem a stabil helyett a developer preview driver-t (most épp 451.22).Futtattad DisplayCAL-ban a kalibrálás (nem a profil!) validálást, hogy tényleg más?
-
válasz
skippper
#4755
üzenetére
A WLED EDR-el valószínűleg közelebb leszel, mint a generic-el.
Ezt gondolom tudod, de a lenti mondatod alapján nem biztos: ezeken a report-okon nem látod, hogy abszolút értelemben milyen közel vagy a célhoz, mert ilyen értelemben mindig saját magát ellenőrzi vissza a műszer (teljesen relatív a saját abszolút értelmű pontosságához), csak magát a profilt ellenőrzöd, hogy milyen jól írja le a kijelző színterét. -
Én úgy láttam (legalább is korábban, mikor még figyelgettem, hogy mi az), hogy a legközelebbi kerek Kelvin értékre húz (vagy 100-ra, vagy akár 500-ra kerekít).
De amúgy meg tudnánk nézni, nyílt forráskód (sőt, azt hiszem ott van benne a HTML file-ban, nem csak a DisplayCAL-ban, annak idején babrálgattam magamnak, míg betette, amit hiányoltam, le van mentve a report file-ba a nyers mérés és ott rakja össze egy script a grafikont a böngészővel, ha jól rémlik, PHP vagy ilyesmi). -
A hsz-em lényege az volt, hogy bármilyen körülmények közt kijöhet egy ugyan ilyen DisplayCAL report, példaképp akár egy frissen hardware-3DLUT kalibrált professzionális kijelzőn is, ha pl. szándékosan választottál olyan WP célértéket kalibráláskor, ami utána messze esett attól, amit a DisplayCAL tippelt.
Ebben az is nagyon fura, hogy az ICM file-ba is el vannak mentve a beállításaid, ha DisplayCAL-al készült, mégsem azt olvassa ki, hanem tippel.
Pl. az új WCG kijelzőkön (QLED, OLED, stb) sokan használnak perceptuálisan a "hagyományos" (CCLF LCD, PDP, stb) kijelzőkön látott fehérhez eltolt WP célértéket (a Sony RGB OLED monitorhoz van kvázi-standard, a gyártó által javasolt WP offset is). Én nem vagyok a híve (mert ez nem a kijelző hibája, hanem a rendszeré, amiben szabványosítanak, így még akkor sem tűnik számomra helyesnek, ha az egész 3D színteret tolják el perceptuális tarszformációval, nem csak nagyzolva a WP-t), de van aki használja olyanok közt, akik pontosan tudják, hogy mit csinálnak (mindkét félét, a csak WP-t és a 3D-set is).
-
Az nem feltétlenül hiba. A "Measured vs. Assumed", igazából egy hülyeség, mert megpróbálja kitalálni, hogy milyen színre tervezted kalibrálni a kijelzőn a 100% fehéret, aztán megmondja milyen messze vagy attól. Pedig igazából az egész kalibrálás rész abszolút opcionális a profilozás előtt, ez pedig profil ellenőrzés, nem kalibrálás ellenőrzés. Ez csak egyfajta "bolond biztosíték", hogy segítsen kiszűrni, ha véletlenül nem azt sikerült beállítanod, amit vélhetően szeretne a legtöbb felhasználó, de még akkor sem kell abszolút érvényűnek venni.
Szóval, ha tudod, hogy mit csinálsz, akkor nyugodtan hagyd figyelmen kívül.
Ha nem tudod, hogy mit csinálsz, akkor írd le, hogy mit szerettél volna elérni és mutasd meg a felette lévő sorokat is (és esetleg a beállításokat is, amikkel nekifutották). -
- Nem, LG TV-n LUT programozáskor nem tudsz (egy képmód : egy LUT [set, 1D + 3D])
- Nem, az iTPG ezek után van, nem hat rá a HDMI Feketeszint kapcsoló (és hasonlók)
Tesztelgettem alaposan, és nem tudom reprodukálni a C9-emen, amit ő tapasztal.
Szerintem olyan bug-ba futott bele, hogy a kalibrálás végén lementi a TV a LUT-okat, de nem olvassa be őket. Néha elég átváltani másik képmódba és vissza, de van, hogy áramtalanítani kell a készüléket (míg kattan a reléje) és visszakapcsolás (teljes reboot) után jó lesz.Frissen reset-eltem egy képmódot és bekalibráltam gyorsan csak egy ~100 pontból készült 3DLUT-al, és nem látok semmi eltérést attól függően, hogy a belső lejátszó, vagy HDMI1 (PC címke nélkül, alapértelmezett név+címke) van kijelölve forrásnak, vagy akár ha HDMI-n keresztül megy ki a tesztkép az iTPG helyett:
[calmanps_hdmi_sdr_rgbfull8bit_noallm] (HDMI-n megy a tesztjel, iTPG inaktív)
[itpg_internal_sdr] (a belső generátor dolgozik, "mögötte" a belső lejátszó pörög)
Ami hat az iTPG-re HDMI oldalról az a VRR / GSync / FreeSync, de ez ismert hiba és "csak" a gamma csúszik el tőle, a színek nem (valószínűleg a panelvezérlő tehet a gamma torzulásról, mikor VRR módba vált, nem a SoC használ más feldolgozást):
[itpg_hdmi_sdr_rgbfull8bit_vrr] -
#4535
janos666
nagyúr
Johnny Cage
#4533
válasz
Johnny Cage
#4533
üzenetére
Passz, sohasem használtam Spyder-t, de amit olvasni/hallani lehet róla, korrekció ide vagy oda, a puszta várható pontossága miatt vélhetően az i1d3 jön ki elől (még akkor is, ha a Spyder-hez van pontosan a kijelzőhöz készült korrekció, az EyeOne-hoz pedig nincs semmi hasonló).
A saját i1d3-am pl. durván dE 1 mértékben tér el a "generic"-től bármilyen gyári EDR-el és hasonló mértékben korrigál rajta az i1Pro2. A Spyder-ekről lehet hallani +/-2 eltérést is simán (két random Spyder közt akár dE 5, egy spektróhoz 2-3, gyári profil nélkül akár több).
-
A próba sem olyan egyszerű, mert a B rev is csak hitelesített 2000-re, ami nem jelenti, hogy véletlenszerűen ne lehetne jó egy A rev is 2000-ig, csak garancia nincs rá (bár még nem próbáltam, hogy van-e egy pont, ahonnan error-t dob akármelyik Rev, ahogy azt sem, hogy hol kezdi el ugyan azt mérni a fényerő további növelése után is a saját Rev A-m). Bár lehet, hogy a gyári spektrális érzékenység profilozáshoz is van köze, és akkor valószínűleg pontatlan lesz (nem lineárisan, hanem csak egy pont felett), ha az 1000-ig skálázható (de ez most csak felvetés, nem tudom - ezt már nehéz lenne otthon letesztelni), mert szoftveres mátrix korrekció esetén (saját spektró mellett) sem kapcsolható ki az a korrekció (nincs valódi RAW mód, hiába írja ki néhány szoftver, az egy "generic" profil, ami nem no-op, nem semleges az sem).
De amúgy miért olvastad te az ő gyártási évét 16-nak? Én 18-nak látom.
-
#4510
janos666
nagyúr
Alvin_ti4200
#4509
válasz
Alvin_ti4200
#4509
üzenetére
A drágább verzió gyakorlati előnye a gyorsabb mérés (de ez is függ az aktuális integrációs időtől, ami sötét árnyalatokon nem lehet túl alacsony), az újé az AIO mód X-Rite SDK-val is (adaptív integrációs idő és frekvencia-szinkronizálás, ami nagy kontrasztú és villogó kijelzőkhöz hasznos).
Ha időben stabil és hagyományos LCD-n használod otthon, nem sokat érsz a gyorsabb méréssel, mert mindegy, hogy 10 vagy 20 perc egy kalibrálás (most erősen túlzok példaképp), nem fogsz hetente több kört lefuttatni (és nem szöszölnek a vállad felett, hogy mikor lesz kész).
Még esetleg azt nézd meg, hogy az X-Rite SDK-ra épülő third-party software (pl. CalMAN, NEC, EIZO, stb szoftverek) kellenek-e neked és támogatják-e az olcsóbbik kivitelt (azt hiszem a Rev-A esetén csak a Pro-t támogatják, a CM-et nem).
Ja, és van még egy harmadik opció, árban a kettő (Studio és Pro Plus) közt: a Rev-B Pro OEM kiadásai (az megy pl. CalMAN-el és ArgyllCMS/DisplayCAL-al is, de az X-Rite szoftverrel már nem biztos, bár ez utóbbit én amúgy is erősen hanyagolnám). A LightIllisuion talán árulja LightSpace license nélkül is (a SpectraCAL nem hiszem) és talán fellelhető Ebay-en ("zacskós" verzióban szoftver nélkül).
Negyedik opció, a létező legdrágább, a custom Spectracal C6-HDR, aminek csak CalMAN mellé lehet némi értelme. -
#4508
janos666
nagyúr
Alvin_ti4200
#4506
válasz
Alvin_ti4200
#4506
üzenetére
Elvileg a régi Pro dobozban is lehet véletlenszerűen Rev-B anélkül, ahogy előre tudnál róla (hamarabb kezdték gyártani az új Rev-et, mint hogy átalakították a kínálatot), de a Studio már biztos az (és nem tudom, hogy a gyári szoftver engedélyezi-e a Rev-B képességeket a régi Pro-ként eladott Rev-B modelleken, vagy csak azokon, amiket már az új termékskála szerint adtak el). Utóbbi lassabb, a korábbi Rev-A olcsóbb/lassabb kivitelű utódja (azt hiszem ColorMunki néven futott), de a Rev-B változások miatt mégis inkább azt választanám (és pusztán azért is, mert valószínűleg fiatalabb gyártmány, nem kaphatsz pl. egy 2017-es csomagolású régi dobozt, bár az i1d3 elvileg már nem öregszik úgy, mint a régebbiek, mert üveg szűrős [vagy üvegbe zárt műanyag? már nem emlékszem...]). Bár ha nem a gyári szoftverrel, vagy az X-Rite SDR-ra, hanem ArgyllCMS-re épülő szoftverrel használod, akkor a Rev-A is legalább olyan jó lehet, mint a Rev-B (ez esetben nincs igazi előnye a B-nek az adaptív AIO mérési móddal, a Pro-nak viszont marad a sebessége, mert az hardware szintű korlátozás).
~1000 cd/m alatt nem érdekes, hogy HDR vagy sem, addig elmér a Rev-A is, a Rev-B pedig ~2000-ig. Az AIO mód az érdekesebb, amihez nem kell HDR (egy jobb plazma TV, FALD-LCD, TV, vagy SDR OLED is problémás az ArgyllCMS féle adaptív mód, vagy gyári szoftverrel az AIO mód nélkül), de LCD monitoroknál a HDR-el kezdődötött a local dimming (amivel igazán sötét "feketébe" futhatsz egy LCD-n). -
válasz
thomasrc
#4496
üzenetére
>>> Mi ez a "black level compensation"?
Van olyan, hogy "Black level" (célérték a feketére), "Black level correction", ami azt szabályozza, hogy mennyit szabad világosítani a "feketén" annak érdekében, hogy az megüsse a célzott fehéregyensúlyt (ennek nyilván akkor van értelme, ha a 0% nem valódi fekete, mint CRT-n vagy OLED-en, hanem "tejfekete", mint egy hagyományos LCD-n, vagyis igazból szürke, tehát annak is van színe, fehéregyensúlya, mint az összes többi szürke árnyalatnak, amit kalibrál a szoftver), van egy "Black point compensation", a profil fülön, ami majdnem ugyan ez, csak a kalibrációs 1DLUT helyett a profilos 3DLUT-ra vonatkozik (de itt már nem a "fekete" színéről van szó, csak a fényességéről, mikor az nem abszolút 0, de a profilban alapvetően szintén tökéletes feketéből indulnának a dolgok) és van végül egy "Black drift compensation", ami kalibrálás közben méri feketét, hogy elmászott-e (PDP-ken és LCD-ken is el tud a hőmérséklettől, pl. ha sokáig világos ábra van egy PDP-n, akkor fényesebb lehet utána kicsit a fekete, míg eltűnik az IR, vagy jobban felhősödhet az LCD, ha a mögötte lévő táp/SoC, stb felfűti a kijehelzőpanelt, ilyesmik).
Ezek számbavétele után elképzelésem sincs, hogy *Ropi* miről beszélt.
-
válasz
Teasüti
#4424
üzenetére
Van némi értelme, hogy miért így működik, de laikusoknak néha talán részben félrevezető lehet, hogy a DisplayCAL alapbeállításokkal az egyedileg készült profilból számolt, és a frissen visszamért értéket veti össze ellenőrzéskor, nem pedig valamik szabvány profilt és/vagy a kalibráláskor megadott célértékeket. Szóval csak magát a profilt ellenőrzi, hogy passzol-e a kijelzőhöz.
A profilba pedig a kalibrálás utáni mérések alapján ment fehéret (és a többit, de nem 1:1, hanem különböző interpoláció, zajszűrés, stb után, ha sok pontot használtál, nem csak a lehető legkvesebbet).
De ami szerintem már rossz döntés, hogy a végén a report nem is a profile WP-hez (a most készült profilba mentett WP-hez) képest ad dE értéket, hanem a legközelebbi 100-ra kerekített Kelvin értékhez képest, amit "assumed target"-nek hív (betippeli, hogy mi volt a kalibrálási célérték). Ide szerintem legjobb lenne átmenteni valahogy az eredeti kalibrálási célértéket (pontosan, nem tippre), vagy inkább más alapértelmezést használni: be tudsz pipálni a report-ban egy olyat, hogy "use basolute values" [*], amivel a profil WP-t használja referenciának (a betippelt célérték helyett). Ez talán többet mondd el, mint hogy hol vagy a tippelt célhoz képest... (* Ezt annak idején még én nyaggattam ki Florian-ból.)
A másik opció, ami még hasznos lehet, ha emulálni próbálsz egy szabvány színteret a report-hoz (itt is működik majd később az abszolút pipa is). Ilyenkor azt is látod, hogy milyen pontosa lehetnek majd a színek, ha használja egy CMS a profilt valami szabványos színterű anyagokhoz.Ha jól emlékszem, a "validate calibration" report hasonló furcsaságokkal bír. Az is egy betippelt, kerekített értékhez képest ír ki dE értéket, nem az eredeti beállításodból olvassa. És mellé kiír többféle számot is, mert a Kelvin nem egyértelmű szám, mint a CIE x,y koordináta pár. Itt ugye legjobb lenne, ha x,y számokkal adod meg a célt is Kelvin helyett és azt használná a "validate" (ha Kelvin-t használtál, figyeld, hogy melyiket, DayLight vagy BlackBody, és a report-ban is azt nézd). Itt nincs is "use absolute" opció.
Persze, ha nem homogén a kijelző, sokat változhat a mérés a mozgatástól. Akkor is, ha a szög változik (mikor nem "felcuppantod", hanem állványon van és azt mozgatod el közben) és rossz a kijelző betekintési szögfüggősége.
-
válasz
Teasüti
#4422
üzenetére
Próbaképp futtass le egy lassabb kalibrálást, az kisebb dE értéket céloz az iteráció során (azon túl, hogy több ponton iterál, de az a 100%-ot, ami minden ponthalmazban benne van, nem érinti).
Én gamma+matrix profilt javasolnék a lehető legkisebb test chart-al (mentsd le a file-t és tallózd be a profil beállításoknál), ha azzal is elég alacsony a validation report-ban minden szaturált szín dE értéke (a LUT elvben sokkal többféle hibát tud korrigálni, de ezzel együtt sokkal könnyebb elrontani is magát a profilt, pl. a ponthalmaz kiválasztásával, szóval nem csak azért tarthat sokkal tovább egy jó XYZ profilt összehozni, mert ahhoz általában sok pontot kell mérni, hanem lehet, hogy többször neki kell futni többféle 1000+ pontos mérésnek, ami egy mezei RGB kijelzőnél sokszor teljesen felesleges és legfeljebb a report-ban lesznek szebb számok, de szabad szemre nem lesz jobb a színhelyesség, sőt, alapvetően nem garantált, hogy ne lehetne rosszabb, ha nem vagy óvatos).
-
válasz
Teasüti
#4419
üzenetére
Ne várj el abszolút pontosságot. Rengeteg apró kis véletlen ingadozás van a műszerben és kijelzőben is, de a legnagyobb korlátozó tényező itt valószínűleg az, hogy a panel gondolom 6-8 bit precizitású (laptop esetén leggyakoribb a 6bit + dither, néha van valódi 8bit, és elenyészően előfordulhat 8bit + dither, nem is tudom van-e valós 10bit "mezei" hordozható gépekben, még komolyabb monitorokban és TV-kben is elég rika), így a legkisebb lépés fel/le egy-egy csatornán (pl. 255,245,235 helyett 255,245,236) lehet ~100K eltérés is (és a szoftver sem iterál a végtelenségig, hogy melyik a legjobb a közeli értékek közül, általában egy bizonyos dE célértékig keresgél csak, ami a "speed" beállítástól is függ).
-
válasz
Teasüti
#4414
üzenetére
A black és white level-t hagyd "As measured"-nek, a hardware beállítást pedig célozd oda, ahol a szemednek kellemes a leggyakoribb használati fényviszonyok közt (akár 80 nit-ig lemehetsz éjjeli sötétséghez, nappalra pedig ami kell a jó olvashatósághoz), ezt később is tologathatod kicsit (nem szokott tőle változni a szín, vagy csak minimálisan a fehéregyensúly az egész tartományban egyenletesen, de a gamma, szaturáció, stb nem csúsznak el ettől egy sima LCD-n, esetleg PDP-n vagy OLED-en csúszik el a gamma és torzul kicsit a szürke skála fehéregyensúlya is, de ott sem katasztrófa).
A gammát próbáld előbb 2.2-re kalibrálni, ne sRGB-re. A gyakorlatban legtöbben ezt használják tartalomkészítésre is, mint decode gamma nem a valódi sRGB görbét (avagy az encode inverzét, mert mint decode gamma nincs is ez nagyon definiálva, a fényviszonyoktól is függne, ha ebbe nagyon bele szeretnél menni).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
ph Rendhagyó tesztünkben egyik, teszteléshez használt készülékünket és annak kistestvérét mutatjuk be: a GretagMacbeth monitorkalibrálóit.
- OLED TV topic
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Ford topik
- AMD GPU-k jövője - amit tudni vélünk
- Lost Records: Bloom & Rage – Tape 1 teszt
- Jövedelem
- AliExpress tapasztalatok
- Alternatív kriptopénzek, altcoinok bányászata
- Mindennél nagyobb: tesztpadon a Ryzen 9 9950X3D CPU
- Ukrajnai háború
- További aktív témák...
- SAMSUNG LC49G95TSSRXEN 125CM 5K GAMER 240HZ MONITOR ! AKCIÓ
- Eladó Dell G3223Q - 4K, 144hz, 32" gaming monitor!
- LG (38WR85QC-W.) 38" 4K GAMER 144Z PRÉMIUM LED MONITOR ! AKCIÓ!
- Újszerű Samsung Odyssey G8 OLED smart gaming monitor - 34" UWQHD (3440x1440px), 175Hz
- SAMSUNG (LH75WADWLGCXEN) FLIP PRO 190CM 4K ÉRINTŐS SMART MONITOR ! AKCIÓ!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest