NEC PA271Q - wstępne wrażenia

[Tom01]

Ilościami bitów nie należy się zbytnio jarać. W tej chwili siedzę na EA275UHD-CT i spójrzcie, 10 bitów jak drut.

[NocnyJastrzab]

Nie chodzi o jaranie, bo nie w tym rzecz. Napisałem, że obraz jest ok. Tylko sam sposób podawania informacji w systemie jest lekko mylący.

[max]

Ja mam Asusa R9 270X, 2GB DDR5. Sterowniki oryginalne AMD sprzed kilku miechów (wyłączyłem już kompa, więc nie podam Ci teraz wersji).

[Kocur]

Na moim BDM3270 i GTX1070 jest 10 bitów i to robi różnicę. Po przełączeniu z 8 na 10 bitów gradienty stają się perfekcyjnie płynne i bez przekolorowania po kalibracji DisplayCal.

[Henioo]

Zapraszam. Co mogłem, to opisałem

viewtopic.php?f=42&t=3683

[Henioo]

Szanowni Forumowicze,

Problem liniowości TrcG w monitorach PA271Q jest nam znany i wspólnie z kolegami odpowiedzialnym za SVE oraz SVII pracujemy nad jego rozwiązaniem. Problemem jest wartość oczekiwania TrcG przez SVII w stosunku do podawanej przez SVE.

Dla wyjaśnienia i przypomnienia zasady działania kalibracji w monitorach wyposażonych w SVE (silnik SpectraView).

Po wybraniu przez użytkownika parametrów kalibracyjnych oprogramowanie SVII żąda od SVE wywołania danej Trc zgodnej z pomiarem referencyjnym fabrycznym. Wywołana Trc jest mierzona za pomocą kolorymetru przez SVII, a wynik podawany jest w formie graficznej.

Pomiary referencyjnym spektroradiometrem PR-670 dają wyniki poprawne pod względem oczekiwanej przez SVII TrcG.

Dodatkowo w oprogramowaniu SVII istnieje możliwość aktualizacji fabrycznej linearyzacji o pomiary pochodzące z urządzenia użytkownika niemniej jednak na tą chwile taka możliwość jest wyłączona z poziomu SVII (z powodu błedu o którym pisze wcześniej).

Fabryczna linearyzacja monitora jest prawidłowa i proponuję na tą chwile nie kalibrować monitora SVII, a jedynie ustawić za pomocą oprogramowania MultiProfiler posiadającego dostęp do SVE lub poprzez menu OSD - ustawione parametry będą praktycznie odpowiednikiem kalibracji.

No czyli dobrze czułem, że tak realnie to gamma nie jest kalibrowana przez SVII, i to z zasady. Nie to, że to jakaś tragedia, bo skoro jest idealna z silnika SV to w sumie nie potrzebuję jej sobie psuć. Ale czekamy na SVII któa pokaże w tej kwestii wierny jej obraz

Natomiast - czy w monitorach wyposażonych w silnik SV normalnym jest też, że gamutu SVII nie kalibruje? Bo sytuacja wygląda identycznie jak z gammą! Czy tu też z założenia bazujemy tylko na tym, co nam wytyczy silnik, czy może jednak SVII z naszym czujnikiem będą w stanie wymusić na monitorze ustalenie takich xy dla R G i B które odpowiadają odczytom czujnika? Póki co to silnik sobie wyznacza swoje (z odchyłami), a program SVII może tylko spuścić głowę i pokazac użytkownikowi ze skruchą pomiary dla R G B gamutu, które odbiegają od targetu...

[Henioo]

Każdy monitor z serii P/PA/SV ma taką funkcjonalność, więc nie o to chodzi. Do kalibracji i profilowania zawsze jest potrzebny duet: soft + urządzenie pomiarowe. PA271Q da się jak najbardziej skalibrować, tylko nie osiągnie się optimum. Proszę zwrócić uwagę, że ustalony target został osiągnięty oprócz TRC, które wykazuje brak idealnej zgodności oraz zbyt duże deltaE. Jak wspomniał Wojtek, na ten moment wystarczą ustawienia z menu OSD (brak finalnego profilu ICC) lub poprzez MultiProfiler.

Target w kwestii gamutu został idealnie osiągnięty tylko dlatego, że w opcjach SVII kolega miał zaznaczone, żeby program sam decydował czy ma brać pomiary z czujnika czy z targetu. I przy kalibracji do innych przestrzeni niż natywna (a tu było do sRGB, widać na screenach) wybiera wartości domyślne, co też widać w oknie wyniku kalibracji pod CIExy dla gamutu, jest podane Factory Measurements. Niech teraz wejdzie w okno kolorymetru i ręcznie zmierzy wartości dla czerwieni, zieleni i błękitu i zobaczy, że wcale nie są idealne.

Pisze o tym, bo mam ten monitor i wg moich obserwacji, tak samo jak gammy SVII nie klaibruje tak samo i gamutu, a bazuje jedynie na wartościach silnika SV. Obszernie to opisałem w swoim wątku tutaj (rozdział Spectra-View - ciemna strona mocy):
viewtopic.php?f=26&t=3683&p=50886#p50882

Wg mnie to o czym tu mówi przedstawiocie NECa w kwestii gammy, ma miejsce tak samo w kwestii wytyczania gamutu innego niż natywny. Nie ma jak go ustawić z użyciem naszego czujnika poprzez SVII. To się niby dzieje, żadnych komunikatów nie ma, ale realnie to jest to tylko odczyt tego co sam ustalił silnik.

Pan Kosek piszę, że z gammą to normalne, że nie jest kalibrowana, a jedynie zadawana przez program kalibrującu silnikowi SV do wyznaczenia. Brzmi to dla mnie dziwnie, ale najwyraźniej takie jest w ogóle założenie! No ale ok, jeśli te gammy z silnikaSV są idealne (a u mnie na przykład są), to nie będę się złościł. O ile wierzyć, że ich nieidealna prezentacja w SVII to tylko błąd programu. CO jednak jest prawdopodobne, bo wizualnie nie widać zupełnie tych odchyłow gammy pokazywanych w SVII, wizualnie liniowośc jest igła.
Ale co z gamutem? Czy tam xy dla wierzchołków też domyślnie nie sa ustalane przez SVII i kalibrator?? Mnie to bardziej interesuje i niepokoi, bo o ile gamma wygląda ślicznie, to gamuty są wyznaczane z odchyłami! Wystarczy - jak pisałem - ręcznie je sobie zmierzyć w oknie kolorymetru. Zresztą, widać to wszystko na screenach w moim wspomnianym wątku. I tego nie ma jak automatem zmienić! Jedyna możliwośc to kalibrator w łapę, okno kolorymetry, a my ślinimy paluch i w menu ekranowym tak dłubiemy w xy dla R G i B, aż odczyt da nam wzorcowe wartości dla naszej przestrzeni, któą chcemy wyznaczyć. Chore, bo to robota softu kalibracyjnego przecież!
Także, mnie to ten gamut dużo bardziej interesuje tutaj... Dla niedowiarków, niech 2marekm zrobi tę samą kalibrację, ale w ustawieniach SVII zaznaczy, żeby program zawsze brał wartości xy z odczytu czujnikiem. I wtedy zobaczymy, że target z kalibracji mamy osiągnięty tylko w bieli i luminancji (czerni również, więc efektywnie w kontraście). Czyli w 3 z 5 skłądowych targetu. Gamma jest nie do ruszenia, ale za to łądna, tylko żle pokazywana w SVII, a gamut jest... i nie do ruszenia (nie wiem czy również zzałożenia) i niedokładny.

No. A silnika zrekalibnrować sami sobie nie możemy, bo ta funkcja się wykrzacza w monitorze. Sprawdziłem. A w SVII jest wygaszona. No bomba!

A ja mam takie pytanie - czy w PA272W też gamma była tylko zadawana do wyznaczenia silnikowi SV? A współrzędne CIExy wierzchołków gamutu? Jaka tam była filozofia? Z tego co pisze pan Kosek to z gammą jest to założenie działania silnika SV we wszystkich P/PA. A gamut? Czy jak posiadacze PA272W kalibrowali sobie do sRGB, to monitor tez im pokazywał wzorcowe współrzędne xy wierzchołków? A jak wtedy je ręcznie mierzą to co wychodzi? Wzorcowo (lub ew w granicach błędu czujnika), czy jednak inaczej? Bo jak inaczej, to znaczy ni mniej ni więcej jak to, że z gamutem jest taka sama filozofia, i ważniejsza tu jest precyzja silnikaSV (i ew jego rekalibracja) niż proces kalibrowania w SVII z naszym czujnikiem I jeśli tak, to dziwię się, że przez całe lata obecności go na rynku nikt na to nie zwrócił uwagi...?

[Henioo]

Misiak, ja już go mam i kończę pisać wieelkie kompendium jego cech - zaczekaj ze 2 dni i przeczytaj, będziesz miał odpowiedzi na wszystkie pytania

Co się stało, minęło już 2 dni, a obiecanego "kompendium"... brak.
Chcę dobrych wiadomości o PA271Q, a nie tylko złych

Robota szła powoli, bo testów nie było końca. Ale już wysmażyłem wszystko co mogłem z dostępną mi SVI w wersji 1.37.00. Już jest nowsza, zobaczę co z nią, ale nie oczekuję na razie tak szybko cudów. Czy nasze problemy zostaną rozwiązane? Póki co, to największym problemem na językach okazuje się być fakt, że SVII 'brzydko" prezentuje idealnie liniową skądinąd gamme, i pluje brzydkimi deltamiE. Które są znakiem tego nieprawdziwe. Więc to nie taki wielki problem, bo liczy się to jak świeci ekran, a nie jak go SVII mierzy (choc oczywiście wypadałoby mieć jak to zweryfikować). Ale poprawienie SVII i firmwareu pewnie w końcu to zniweluje.

Natomiast czy wyznaczanie gamutu zostanie w jakiś sposób poprawione? Ciekaweym bardzo, bo nikt o tym nie mówi, a ono nie dośc że tak samo niemożliwe do wyznaczenia przez SVII, to jeszcze niepoprawnie wyznaczane przesz silnikSV. Więc tu się dzieje coś więcej, niż tylko "niepoprawna prezentacja" współrzędnych CIExy wierzchołków gamutu. Jeśli filozofia jest taka, że to też ma sam silnikSV wyznaczać, to klops. To prawo producenta, ale pomysł średni jak dla mnie. Wtedy pomóc może już tylko rekalibracja silnika SV, co miałem w planach uczynić, ale na razie nie mogę, bo ta funkcja też jest zwalona na razie i czekamy, aż da się jej użyć w ogóle

Ale spoko luz, ja też mam ten ekran, też mam te same problemy, a do tego plamkę na dnie matrycy... a mimo to uważam, że monitor jest świetny. Spójrz na dobre strony, a nie fiksuj się na 5% ułomności
Teraz czekajmy na rozwiązanie i róbmy zamieszanie wokół sprawy. To możemy tylko. No i cieszmy się z tego, że ekran jest cupełnie piękny! Bo jest! Wyświetl sobie gradien szarości i zobacz jai jest idealny! Nie patrz na pogibaną gamme w SVII, bo okazuje się, że jest źle pokazana. Patrz na idealną liniowość w realu! A ona jest idealna. No u mnie jest. I z tego się cieszę. Podobnie jak ze wszystkich innych funkcjonalności tego monitora.

Głowa do góry.

Ale chciałeś kompendium, to masz:
viewtopic.php?f=26&t=3683

Pól dnia będziesz czytał

[Henioo]

Na moim BDM3270 i GTX1070 jest 10 bitów i to robi różnicę. Po przełączeniu z 8 na 10 bitów gradienty stają się perfekcyjnie płynne i bez przekolorowania po kalibracji DisplayCal.

Ja u siebie na nVidia też mam możliwość ustawienia 8 i 10bitów przez DisplayPort z naszym tu PA271Q, ale żadnych różnic w precyzji kalibracji nie dostrzegłem. Gradienty też wyglądają u mnie tak samo dobrze (a wręcz idealnie) i na 8 i na 10 bitach. Nie wiem, nie znam się... ale u mnie jest tak i działa. Teoretycznie to dopóki program nie zutylizuje tych 10bit to nic nie ma prawa się zmienić czy poprawić. A i nie wiem na ile te 10bit w takiej nVidii dla graczy jest prawdziwe, bo gdyby było, to po co nVidia robiłaby karty Quadro, których jedną z głownych zalet jest możliwośc wysyłania 10bitowego sygnału na kanał...

[Henioo]

Proponuję sprawdzić najnowszą, nie jest jeszcze dostępna na stronach producenta. Ja jeszcze jej nie zweryfikowałem z PA271Q, najwcześniej będę to mógł sprawdzić w poniedziałek.
NEC SpectraView II 1.1.38 - https://cloud.mastiff.pl/index.php/s/DEZMA34w8n1xT6t

Niestety na najnowszym SpectraViewII 1.1.38 nic nie zmieniło się, czego można było się spodziewać po wypowiedziach P. Tom01 i Wojciech Kosek.

Moim zdaniem to nie wina monitora. Ustaw to co chcesz z menu monitora lub MultiProfilerem. Będzie dobrze.

Oczywiście, ze aktualnie będzie dobrze, ale czy będzie dobrze za rok, dwa jak monitor się rozkalibruje ?

Jeśli zostanie przeprowadzona "akcja naprawcza" jak to będzie przebiegało ?

Wg release notes z SVII w wersji 1.1.38 wynika, że wersja zawiera nowy firmware dla poniższych modeli. Naszego PA271Q tam nie widzę, także raczej żadnej poprawy w 1.1.38 nie zobaczymy

Release Notes
New Display Firmware
New firmware for the following display models is available which adds some functionality improvements.

P241W
PA231W
PA241W
PA271W
PA301W

EDIT: aa, czekaj, teraz widzę, że to info ogólne o tych firmware, wiszące tylko informacyjnie tam. Dla tej konkretnie wersji zmieniono co następuje:

V1.1.38: August 15 2018
Added support for P243W, EA271Q, EA271U, and EA241WU.
Discontinued support for the Datacolor Spyder2 color sensor.
Added support for the X-Rite i1Studio color sensor.
Discontinued support for Windows XP.

...no czyli, jak widzimy, zupełnie zmienia to postać rzeczy w naszym przypadku

[Henioo]

Przy okazji, tak realnie wygląda osiągnięty target kalibracji do gamutu sRGB na PA271Q:




Albo innym razem tak:

A tak dla przykładu wygląda realnie "osiągnięty" target fikcyjnego, testowego małego gamutu (target i zmierzone wyniki w ramkach). No ale lepiej nie będzie, skoro to silnik SV wyznacza te xy zamiast programu kalibracyjnego z czujnikiem. A precyzji silnika SV nie przeskoczymy. Dziwna ta filozofia.




Ach, ta precyzja

Dzicz.jpg (170.8 KiB) Przejrzano 2727 razy

[Crest]

Henioo - kawał dobrej roboty. Dzięki ze Twoje wpisy. Jestem zainteresowany PA271Q ale jest rzecz, która niepokoi mnie bardzo - prośba o weryfikację czy dobrze zrozumiałem:

1. Silnik monitora ustawia parametry wyświetlania na podstawie zadanych wartości z oprogramowania ale robi to nie wykorzystując na żadnym etapie informacji zwrotnej np. z i1dislayPRO żeby wprowadzić KOREKTĘ jeżeli z jakiegoś powodu odczyt z ekranu jest niezgodny z tym co rzeczywiście powinno się wyświetlić (nie jest istotne czy obecnie monitor z fabryki jest idealny)? Całość bazuje na AUTONOMICZNOŚCI i nieomylności silnika w monitorze który się nie liczy z rzeczywistym odczytem?
2. Nawet jeżeli obecny bug zostanie naprawiony to czy zestaw monitor + SVII będzie wykorzystywać czujnik zewnętrzny do wprowadzania korekt czy tylko do odczytania i zaprezentowania wyników?

[Tom01]

1. SpectraView Engine jest autonomiczny i na daną chwilę zaprogramowany w fabryce. Liniowość ma poprawną, co można nawet samemu sprawdzić. Jednak rekalibracja za pomocą SpectraView II jest niefunkcjonalna, bo jest rozbieżność pomiędzy parametrami podawanymi przez SVE a tym co się "spodziewa" dostać SVII. Mówiąc prosto, nie przekalibrujemy elegancko montora za pomocą SVII dopóki producent nie poprawi tego buga.

2. Przy poprawnie działającej komunikacji SVII zaprogramuje SVE.

[Crest]

Zakładam że to ja nieprecyzyjnie się wyraziłem

Wiemy już że "jest rozbieżność pomiędzy parametrami podawanymi przez SVE a tym co się "spodziewa" dostać SVII". Zostawmy to na chwilę czekając aż będzie to poprawione.

Mi chodziło o zasadę działania - przyjmujemy że buga już nie ma.
Czy SVE będzie korzystać z odczytów czujnika zewnętrznego, aby wprowadzić korekty np do liniowości gdyby ta okazała się nieliniowa? Czy nie będzie tak jak napisał Henioo (w innym wątku) że SVII zapodaje czego oczekuje, SVE "wie" co zrobić, ale nawet jak zewnętrzny czujnik wykaże że to co wychodzi jest niewłaściwe to trudno?

To jest ważne - inaczej kalibracja i profilowanie za pomocą SVII to tylko weryfikacja czy SVE jest OK ale już bez możliwości poprawy jeżeli dobrze nie jest.

[Tom01]

Czy SVE będzie korzystać z odczytów czujnika zewnętrznego, aby wprowadzić korekty np do liniowości gdyby ta okazała się nieliniowa?

Jak najbardziej! Tak to działa w wszystkich innych monitorach serii PA.

[Henioo]

Zakładam że to ja nieprecyzyjnie się wyraziłem

Wiemy już że "jest rozbieżność pomiędzy parametrami podawanymi przez SVE a tym co się "spodziewa" dostać SVII". Zostawmy to na chwilę czekając aż będzie to poprawione.

Mi chodziło o zasadę działania - przyjmujemy że buga już nie ma.
Czy SVE będzie korzystać z odczytów czujnika zewnętrznego, aby wprowadzić korekty np do liniowości gdyby ta okazała się nieliniowa? Czy nie będzie tak jak napisał Henioo (w innym wątku) że SVII zapodaje czego oczekuje, SVE "wie" co zrobić, ale nawet jak zewnętrzny czujnik wykaże że to co wychodzi jest niewłaściwe to trudno?

To jest ważne - inaczej kalibracja i profilowanie za pomocą SVII to tylko weryfikacja czy SVE jest OK ale już bez możliwości poprawy jeżeli dobrze nie jest.

Bardzo jasno się wyraziłeś, dobrze rozumiem o co ci chodzi!

To już mówię: z moich obserwacji i pomiarów wynika, że silnik działa autonomicznie w kwestii Gammy i wyznaczania gamutu. Tylko (i na szczęście) w tych dwóch kwestiach. Bo już temp bieli wyznacza prawidłowo podczas kalibracji w SVII, bazując na odczycie z naszego czujnika, czyli tak, jak być powinno. Za to ręczę, bo to sam sprawdziłem i mam właśnie przed nosem (i dzięki temu że tak się dzieje, to wiem jakie xy zapodać w monitorze w innych trybach, żeby mieć poprawną biel z pomiaru czujnikiem, bo po kalibracji monitor sam mi je pokazał ).

Biel oraz luminancję (i bieli i czerni, czyli efektywnie kontrast) SVII ustawia w monitorze w sposób logiczny, racjonalny, posługując się odczytem zwrotnym z czujnika. Natomiast gammę ustawia autonomicznie sam silnik (program SVII potem pokazuje ją kiepsko, pluje losow brzydkimi deltami, ale realnie ona kompletnie "nie wygląda" na te delty, bo gradient jest idealny - gdyby te delty były prawdziwe, to gradient wyglądałby jak na moim starym NECu , czyli tak sobie; potwierdza to też pan Kosek z NECa kilka postów wyżej, mówiąc, że choć SVII pokazuje odchyły gammy, to jej referencyjny pomiar wzorcowymi sprzętami potwierdza to, co widać na gradientach, że gamma jest bez pudła, a to tylko SVII ją tak niekorzystnie przedstawia). Także obecnie, największy problem jest wg mnie z wyznaczaniem gamutu. Bo to w największym stopniu (z tych dwóch problematycznych kwestii) wpływa na obraz (skoro gamma realnie nie jest wcale zła).

Pytasz o filozofię. I to jest bardzo dobre pytanie. Ja też się nad tym zastanawiam. Bo do niedawna jeszcze wydawało mi się, że wszystko w kalibracji bazuje na odczycie zwrotnym z czujnika. Ale odkąd mam ten monitor to przekonuję się, że z gammą i gamutem to tak tu nie jest. Co do gammy, to już zupełnie potwierdził to pan Kosek (2 strony wcześniej w tym wątku, zajrzyj), że idea. filozofia jest taka, że gammę wyznacza sam silnik. Niby zonk... ale jeśli ta gamma z silnika jest taka idealna, to jeszcze nie taka tragedia. Jest duże prawdopodobieństwo, że wyznaczona w SVII na podstawie pomiaru naszym, domowym czujnikiem wyszłaby gorsza, i wtedy pewnie sami wolelibyśmy już tę silnikową Niemniej, co kiedy za rok, dwa, pięć silnik SV już nieco się rozjedzie? Ano własnie... zważywszy na tę filozofię działania NEC'a z silnikiem SpectraView (bo pan Kosek napisał, że wszystkie z silnikiem mają te zasadę, czyli wszystkie dotychczasowe, osławione PA272W TEŻ! to miały, tylko nikt po prostu nie krzyczał, bo może nawet nie było jak tego zauwazyć, jak braku 3DLUT w Eizo ) - no więc z ważywszy na tę zasadę, niezwykle istotne wydaje mi się zrekalibrowanie silnika SV! A przynajmniej taka możliwość! Bo realnie, to jest JEDYNA możliwośc fizycznej korekty gammy w monitorach z silnikiem SV! Cały szkopuł w tym, że obecnie ta funkcjonalnośc również jest skopana, czego doświadczyłem próbując i co myślałem że jest związane z faktem braku posiadania czujnika NEC (myślałem, że ten i1 w wrsji NEC ma może jakiś lekko inny firmware i stąd mi to nie działa).

NATOMIAST, czy ta filozofia również tyczy się wyznaczania xy wierzchołków gamutu?? Tego jestem BARDZO ciekaw, ale o tym pan Kosek nic nie pisze. OBECNIE tak jest. Ale nie wiem, czy to jest w oczach NEC'a błąd i to się poprawi i zmieni, czy może to tak samo jak z gammą, jest rozmyślna filozofia postępowania? Jeśli tu też mamy takie samo podejście, to to już jest dla mnie kuriozum, bo co jak co, ale z kolorami kolorymetr nie ma problemów i wyznacza jes bardzo dokładnie i nie widzę NAJMNIEJSZEGO powodu, że nie pozwalać mu tego robić podczas kalibracji w SVII. TYM BARDZIEJ, że w przypadku CCT bieli to robi i robi poprawnie i na to mu jakoś silnik SV pozwala!! Dlaczego zatem z gamutem nie jest tak samo???? Ki grzyb... ? No i tutaj znowu z pomocą przyszłaby rekalibracja silnika SV, bo dzięki niej mógłbym np sobie wyrównać biel (żeby to co wyznacza silnik lepiej zgadzało się z moim odczytem), oraz jednocześnie tym samym to wyznaczanie gamutu, bo to ten sam mechanizm wyskalowanie współrzędnych przecież (i gamut i biel jest wyznaczana po CIExy). Ichoć wtedy nadal byłbym zły na to podejście i filozofię NECa, to jednak miałbym bardzo precyzyjnie określane xy przez silnik, czego obecnie nie moge powiedzieć, żeby było (vide screeny w moim wątku o PA271Q - odchyły xy bieli i odchyły gamutów).

No ale niestety, rekalibracji silnika nie zrobimy na razie. Bo nie działa. W SVII tę opcję wygaszono, a w samym monitorze się odpala, ale przy pierwszych odczytach wywala błąd. Tyle. Taki jest stan obecny. Czekamy co dalej. Poradzić sobie jakoś można, jak ma się czujnik i trochę chociaż oleju w głowie, to nawet w obecnym stanie można uzyskać idealny obraz - jak to zrobić pisałem w swoim wątku o PA271Q, trzeba po prostu zrobić to ręcznie wpisująć xy do silnika (menu monitora) tak długo próbując, aż ręczny odczyt (okienko kolorymetru w programie SVII) da nam co trzeba (z bielą mamy gotowca po kalibracji, tylko gamut zostaje, jeśli chcemy inny niż natywny pełny). Robota benedyktyńska, ale metoda prosta. I będzie idealnie. Nie ma tylko jak się tym poprawnym ustawieniem pochwalić w wynikach kalibracji se SVII, bo tam jest akurat brzydko ) Ale proste i wygodne to nie jest i to nie tak powinno wyglądać, to na pewno...

[Henioo]

Czy SVE będzie korzystać z odczytów czujnika zewnętrznego, aby wprowadzić korekty np do liniowości gdyby ta okazała się nieliniowa?

Jak najbardziej! Tak to działa w wszystkich innych monitorach serii PA.

To jak to się ma do wypowiedzi pana Koska z kilku postów wyżej, że (cytuję):

"Dla wyjaśnienia i przypomnienia zasady działania kalibracji w monitorach wyposażonych w SVE (silnik SpectraView).

Po wybraniu przez użytkownika parametrów kalibracyjnych oprogramowanie SVII żąda od SVE wywołania danej Trc zgodnej z pomiarem referencyjnym fabrycznym. Wywołana Trc jest mierzona za pomocą kolorymetru przez SVII, a wynik podawany jest w formie graficznej. "

Nie korygowana, ale jedynie MIERZONA. ??

[max]

Uuuuuch, aaaaach, co za opis. Imponujący. I spis treści. Tego tu jeszcze nie grali.

PS. Takie moje małe sprostowanie układu DUC. Wydaje mi się, że to nie do końca tak jak opisałeś. Aby po włączeniu DUC utrzymać tą samą jasność bieli (przyciemnioną w potrzebnych miejscach nieco matrycą) monitor musi po prostu trochę (ok. 20%) zwiększyć moc podświetlenia. Dlatego rośnie również jasność czerni, a nie dlatego, że jest ona jakoś tam wyrównywana. Wyrównywana jest tylko biel, a jasność czerni rośnie na skutego rozjaśnienia podświetlenia, czyli taki "efekt uboczny".

Ja mam od samego początku ustawiony DUC=5, czyli na maxa i nie zaprzątam nim sobie głowy. Moim zdaniem oczywistym jest, przynajmniej na logikę, że najpierw należy sobie wybrać tryb DUC, a dopiero potem robić pomiary i ustawienia. Bo zmiana DUC jednak trochę zmienia obraz (zwiększa moc podświetlenia i jednocześnie zwiększa cięcie matrycą, aby na końcu wyszło mniej więcej na jedno).

Oczywiście czujnik RGB podświetlenia też cały czas włączony. Po to jest, aby wprowadzał korektę.

Metameryzm to też dość ciekawa funkcja. Robiłem porównanie do starego CCFL sRGB NEC LCD1990SXi i w takim przypadku funkcja ma chyba zastosowanie. Wynika to po prostu z różnego postrzegania (na czym polega mechanizm to już nie będę wchodził, Czornyj to kiedyś tłumaczył) różnego widma podświetlenia.

Response Improve - to dopalacz ciekłych kryształów, ze swoimi plusami dodatnimi i ujemnymi. Ja i tak nie widzę różnicy.

Moim zdaniem lag z komunikacją monitora wynika z dużej ilosci danych do przesłania. 3D LUT 17 x 17 x 17 to po prostu sporo danych, do tego opóźnienia czujnika RGB, przeliczenia DUC, odczyt temperatury, mocy podświetlenia, opóźnienia samego procesora itd itp. Sporo tego, to i opóźnienia są duże. Ja na szczęście rzadko coś zmieniam, poza jasnością.

Czujnik RGB w czasie rzeczywistym reguluje barwy monitora wynikające z:
* zmiany jasności podświetlenia, a co się z tym wiąże, różnych proporcji świecenia luminoforu względem diody niebieskiej
* temperatury otoczenia
* pozycji ekranu, a więc i odprowadzenia ciepła z podświetlenia
* starzenia i zużycia luminoforu

Oczywiście wszystko dzieje się w oparciu o informacje zapodane monitorowi podczas kalibracji fabrycznej (wysterowanie tzw. silnika monitora).

To moje tylko przeczucie, a potwierdzają je blokady dostępu w niektórych miejscach, są po prostu jeszcze jakieś błędy w oprogramowaniu. Przedstawiciel NECa nie zdradził nam wszystkich szczegółów (a być może wszystkiego nie wie), ale coś tam po prostu na razie nie działa, wyłączyli to, i na razie najprościej zastosować się do jego wskazówek, czekając na rozwój sytuacji.

[Tom01]

To jak to się ma do wypowiedzi pana Koska z kilku postów wyżej, że (cytuję):

"Dla wyjaśnienia i przypomnienia zasady działania kalibracji w monitorach wyposażonych w SVE (silnik SpectraView).

Po wybraniu przez użytkownika parametrów kalibracyjnych oprogramowanie SVII żąda od SVE wywołania danej Trc zgodnej z pomiarem referencyjnym fabrycznym. Wywołana Trc jest mierzona za pomocą kolorymetru przez SVII, a wynik podawany jest w formie graficznej. "

Nie korygowana, ale jedynie MIERZONA. ??

Najpierw jest pomiar, potem programowanie a potem wywołanie z pamięci procesora i porównanie z teoretycznym przebiegiem trc. Na tym ostatnim etapie jest nieprawidłowość. W sumie przecież odchyłki odnoszą się do idealnego przebiegu funkcji.

[Henioo]

Max, zo z DUC to mniej więcej chyba tak.

Natomiast do wskazówek typu: zaufaj silnikowi a kolorymetr schowaj do szuflady to ja nie zamierzam się stosować. Nie po to kupiłem ten monitor, żeby teraz nic z nim nie robić! Wg tych sugestii w tej chwili miałbym przed nosem biel 6219K zamiast 6500K i ślepo wierzył, że silnik mówi mi prawdę o wyświetlanym obrazie. Także... wolę jednak skontrolować co się dzieje